►
From YouTube: IETF-SCITT-20230123-1600
Description
SCITT meeting session at IETF
2023/01/23 1600
https://datatracker.ietf.org/meeting//proceedings/
B
A
A
A
D
A
F
A
D
A
A
A
But
in
any
case,
I
I
think
it's
four
minutes
past
the
hour,
so
we
should
better
get
started.
So,
as
you
know,
from
our
agenda
discussion,
we'll
have
a
presentation
today
about
six
store
and
Zachary
is
going
to
talk
about
it,
and
then
we
have
a
couple
of
other
items
that
we
will
come
to.
Hopefully,
if
time
permits
afterwards,
secretary
should
I
give
you
the
presenter
token.
A
B
A
A
B
B
Great
and
I'm
presenting
this
one
with
Joshua,
so
our
plan
is
to
try
to
keep
it
pretty
high
level.
We
we're
gonna,
you
know,
keep
it
abstract,
but
we
have
a
little
bit
of
time.
Hopefully
then
for
questions,
and
then
we
have
a
lot
of
you
know,
backup,
slides
in
case
any
anything
in
particular
comes
up
that
we've
we've
prepared
for
Joshua.
Are
you
on
the
call
and
able
to
able
to
speak.
C
C
Sure
yeah,
so
my
name's
Joshua
and
you've
all
heard
from
Zach
and
we're
just
going
to
present
kind
of
a
brief
introduction
to
six
store.
Yeah
next
slide,
please
like
so.
This
is
our
agenda.
For
today
we
really
want
to
talk
about
the
common
goals
between
six
door
and
skits,
give
a
high
level
overview
of
the
six
door
projects.
C
Then
Zach's
gonna
spend
a
few
minutes
just
talking
about
some
of
the
pieces,
hopefully
giving
a
high
level
understanding
of
how
it
all
works
and
then
we'll
just
have
a
brief
summary.
At
the
end,
we've
got,
as
I
mentioned,
some
kind
of
bonus,
slides,
prepared
on
points
of
departure
and
frequently
asked
questions,
but
we
aren't
intending
to
present
those
today
they're
just.
F
A
F
C
So
next
slide.
Please
attack
just
a
brief
overview
of
the
six
door
project.
It's
impressively
widely
used
running
code
that
achieves
We
Believe
many
of
Skip's
goals.
The
60
project
started
with
a
mission
to
sign,
verify
and
protect
software.
The
project
exists
within
the
open
source
security
Foundation,
the
openssf,
which
is
a
Linux,
Foundation,
I,
guess
sub
Foundation
I'm,
not
100
clear
on
the
organizational
hierarchy.
It's
an
open
source
project
with
which
is
very
active.
C
There
are
on
approximately
kind
of
250
commits
to
the
six
star
projects
each
week
from
a
fairly
wide
set
of
developers.
Working
for
a
bunch
of
different
organizations
in
different
kind
of
geographies
sixer
also
has
a
a
free
to
use
public
good
infrastructure
instance,
which
has
seen
quite
impressive
adoption.
It's
hosting
at
least
seven
million
entries
and
its
transparency
service.
C
B
Yeah,
so
here's
here's
where
I'll
take
over
so
we're
gonna
we're
gonna
start
with
a
10
000
foot
overview
and
again
you
may
you
may
notice.
Some
of
these
words
are
words
we
made
up,
but
you
may
recognize
a
lot
of
the
concepts
from
from
skit,
so
the
participants
in
the
ecosystem
are
going
to
be
developers
maintainers
and
monitors,
I'm,
forgetting
the
language
that
gets
used
in
the
skit
world
for
monitors,
but
basically
third
parties
who
are
kind
of
keeping
an
eye
on
the
log
they.
B
They
may
not
be
quite
consumers,
but
they're
they're
sort
of
parties
in
the
ecosystem
who
are
auditing
and
making
sure
that
you
know
things
stay
honest,
so
maintainers
are
going
to
be
signing
and
Publishing
artifacts
and
we
envision
this
kind
of
in
an
open
source
setting,
but
there's
a
number
of
of
other
use
cases
so
you're
a
maintainer
of
an
open
source
project.
You
it's,
you
know,
release
day,
you
sign,
you
build
a
release,
you
sign
it.
You
publish
it
and
you
sign
it.
B
Using
a
key
pair
that
is
in
in
the
pub
looking
at
keypad
is
going
to
be
in
a
certificate
from
our
certificate,
Authority
and
so
I
think
there's
some
overlap
potentially
with
the
Acme
group.
This
is
sort
of
an
automated
certificate,
Authority
and
I'm
I'm,
quite
interested
in
some
follow-up
there
on
the
ca
side
of
things,
I
think
it's
a
little
bit
external
to
to
this
working
group,
but
I
think
they
play
together
quite
nicely.
B
So
we're
going
to
publish
those
signing
certificates
into
a
signature,
transparency,
log,
very
vanilla,
just
just
as
in
certificate,
transparency,
transparency,
log
and
then
the
signatures
themselves
are
also
going
to
go
into
a
transparency
log
of
its
own
and
folks
are
going
to
keep
an
eye
on
that.
So
you
don't
have
to
internalize
all
that
we'll
kind
of
go
through
it
in
in
a
little
bit
more
detail.
But
that's
that's
a
high
level.
B
You
have
a
source
of
identity
and
you
have
a
log
of
all
of
the
the
signatures
and
that
log
is
kind
of
where
I
think
I
see
the
most
overlap
with
what's
what's
proposed
in
skit
yeah.
So
that's
that's
the
idea.
Right
we
want
to
sign
with
digital
identities,
that's
kind
of
the
certificate,
Authority
angle
on
things,
and
then
we
want
that
all
to
be
transparent.
B
So
it's
auditable
and
and
easy
to
reason
about,
and
everything
is
in
the
open
and
so
usability
I
think
has
been
a
key
concern
from
from
day
one
for
us
I
think
we're
we're
very,
very
interested
in
you
know.
If
the
software
consumer
has
to
do
literally
anything
different
to
benefit,
we've
done
something
wrong
right.
This
is
this
is
something
we
see
time
and
time
again
in
usability
research
on,
for
instance,
webpki
right.
You
know
years
of
telling
folks
to
look
for
the
you
know.
B
Lock
icon
in
the
browser
didn't
do
a
whole
lot,
and
it's
only
once
we
basically
had
https
in
in
almost
every
case
that
folks
were
were
actually
you
know
getting
that
benefit
when
we
don't
need
those
consumers
to
check.
So
that's
that's.
A
major
goal
of
ours
is
is
to
have
zero
impact
on
the
life
of
a
consumer.
Unless
something
goes
wrong,
in
which
case
we
stop
them
from
from
installing
something
malicious
or
something
that
isn't
up
to
enough
for.
B
For
some
other
reason,
yeah
and
then
from
the
maintainer
side,
we
want
that
to
be
usable.
You
know
just
as
well
I
think
there's
a
long
history
of
usability
research
on
the
issues
with
key
management.
It's
you
know,
kind
of
a
joke
in
the
usable
security
Community,
there's
a
there's,
a
papers
with
titles.
You
know
why
Johnny
can't
encrypt,
why
Johnny
still
can't
encrypt,
why
Johnny's
still
still
can't
encrypt
in
and
so
on,
and
we're
trying
to
avoid
a
lot
of
those
pitfalls
exactly.
F
A
B
E
B
G
B
B
B
Users
authenticate
using
open,
ID
connect,
so
they're
going
to
present
a
JavaScript
web
token.
There's
a
couple
of
other
authentication
mechanisms
that
we
have
support
for
spiffy
is
one,
but
this
is
really
feels
extensible.
You
know
it
feels
like
you
could
pretty
easily
plug.
You
know
centralized
identifiers
in
there.
You
could
plug
saml
into
there,
whatever,
whatever
sort
of
a
source
of
authentication,
you're
you're
interested
in,
and
so
once
you
authenticate
with
the
ca.
B
It's
going
to
issue
you
an
x509,
you
know
code
signing
a
certificate,
for
you
know
you
as
a
client
and
the
subject
of
that
certificate
is
going
to
correspond
to
the
account
that
you
used
to
authenticate.
You
could
also
imagine
this
working
for
machine
identities
as
well.
So
one
popular
use
case
is
in
CI
and
CD.
Github
actions
has
support
for
openib
connect,
and
so
you
can
get
a
certificate
from
Sig
store
that
says
a
GitHub
actions.
B
Job
running
you
know
this
workflow
signed
off
on
this,
which,
which
kind
of
looks
like
a
lightweight
version
of
you,
know
remote
attestation
from
from
trusted
Hardware.
It's
not
that
the
hardware
is
actually
trusted,
but
if
you
trust
GitHub
as
a
runner,
then
that
that
signature
is
going
to
have
to
come
from
a
GitHub
Runner
running
the
job
that
it
says
it
was
running.
B
So
that
was
a
little
bit
of
a
circular
sentence,
but
the
idea
is
that
we
can
give
machines
identities.
We
can
give
users
identities
and
when
machines
have
identities,
we
can
tie
those
identities
to
the
code
that
the
machine
is
running
and
then
those
certificates
are
going
to
be
ephemeral.
Right,
we've
seen
a
lot
of
success
in
the
past.
You
know
decade
with
really
shorter
and
shorter
lived
certs
for
for
kls.
B
In
our
case,
we're
gonna
we're
gonna.
Take
that
really
to
the
extreme.
Our
certificates
are
going
to
be
valid
for
only
10
minutes
and
that's
you
know,
got
some
pros.
It's
got
some
cons,
I
think
the
the
pros
outweigh
the
cons
here,
but
what
it
gets
you
is
that,
as
the
the
key
pair
that
you're
using
is
effectively
one-time
use.
So
even
if
you
know,
for
whatever
reason,
those
keys
happen
to
leak,
they
shouldn't
right.
B
You
can
shred
them
at
the
end,
but
even
if
those
keys
happen
to
leak
unless
an
attacker
got
their
hands
on
them,
within
that
10
minutes,
you're
not
going
to
be
able
to
you're
not
going
to
be
able
to
exploit
that
and
and
we'll
see
on
the
next
slide.
The
time
scanning
component,
Keeps
Us,
honest
there
yeah
so
time
stamping.
So
we
have,
we
have
a
service
called
recore.
The
idea
of
time.
Stamping
signatures
on
a
short-lived
certificate
is
not
new.
B
Rfc
3161
proposes
a
Time,
stamping
Authority,
and
this
is
one
of
the
main
motivating
use
cases
in
3161.,
but
it
remains
a
good
idea.
We
built
our
own
because
you
know
you
got
to
build
you,
gotta,
n,
plus
one
everything,
but
but
largely
because
we
were
interested
in
having
an
extra
metadata
and
having
search
ability
and
having
transparency
which
we'll
get
to
in
the
next
slide
and
and
I.
Think
again,
the
skit
effort
seems
to
have
reached
a
similar
conclusion
that,
yes,
counter
signatures
are
really
great.
B
But
if
you
want
transparency,
if
you
want
discoverability,
you
kind
of
have
to
supplement
that
a
little
bit
and
that's
that's
sort
of
what
we've
done
there
yeah,
and
so
this
this
allows
us
to
check
that
a
signature
was
made
before
the
certificate
expired.
So
if
we
have
a
short-lived
certificate,
we
should
be
in
in
pretty
good
shape
yeah.
So
the
final
aspect
is
is
sort
of
the
transparency
angle,
and
so
here
we're
inspired
very
much
by
certificate.
Transparency
I
think
much
much
as
the
skit
effort
is.
B
We
have
a
Merkle
tree,
so
cryptographically
you're
going
to
get
some
tamper,
resistance
and
you're
going
to
be
able
to
check
if
items
are
actually
in
a
log,
so
we're
going
to
store
our
certificates
in
a
certificate
transparency,
log
that
looks
identical
to
the
ones
that
are
running
kind
of
for
webpki
and
certificate
transparency,
because
it's
also
storing
x509
certificates,
we're
going
to
put
signatures
and
metadata
in
our
artifact
log
or
our
signature
log
or
whatever
you
want
to
call
it.
That's
that
recore!
So
that's
got
some
additional
metadata.
B
That's
got
those
time
stampings
and
so
it's
you
know.
Transparency,
logs
I
think
are
a
nice
sweet
spot
for
this
use
case.
We're
not
you
know
totally
tied
for
it
and
I
know
in
at
least
the
draft
of
the
skit
architecture
that
I've
seen.
There's
some.
You
know
openness
to
other
verifiable
data
structures.
Yeah
on
you
know,
kind
of
Merkle
trees
as
they
look
like
in
CT.
B
But
you
know,
blockchain
like
is
is
an
another
obvious
candidate,
but
but
for
us
I
think
it's
a
really
nice
sweet
spot.
In
terms
of
being
you
know,
it's
centralized,
so
it's
pretty
fast,
but
the
transparency
gives
us
the
accountability
that
makes
us
comfortable,
trusting
it,
and
so,
on
top
of
all
that,
you
know,
once
you
have
transparency
now
you
can
have
auditing.
Now
you
can
have
monitoring.
So
there
are
a
number
of
potential
applications
here.
B
One
thing
you
can
do
as
a
signer
is,
you
can
monitor
and
every
certificate
that
gets
issued
for
your
name.
You
can
go
and
get
I,
don't
know
a
text
message
whenever
that
happens,
and
that
would
be
able
to
be
easy
to
implement
third
party
from
a
source
that
wasn't
running
the
transparency,
log
and
so
you're
kind
of
in
a
different
trust
domain
there,
and
so
think
of
this.
As
being
analogous
to
you
know
the
text
messages
you
get
when
a
new
account
logs
into
Amazon
or
some
other
web
app
for
you.
B
B
All
of
these
things
are,
are
you
know,
options
and
I
again,
I
think
the
skip
project
seems
to
have
recognized
the
benefits
of
transparency.
Once
you
have
the
stuff
exposed,
you're,
not
prescribing,
what's
done
with
it,
you're
opening
up
a
lot
of
different
security
applications,
so
yeah,
so
tying
it
all
back
together
right.
This
is
roughly
how
it
works.
You
get
a
certificate
from
the
certificate
Authority
you
you
know,
stick
the
certificate
in
the
transparency
log.
B
C
C
We
also
think
that
most
of
the
differences
are
fairly
easily
resolved
and
perhaps
with
a
little
abstraction,
and
we
think
the
modularity
of
both
Solutions
really
helps
with
that,
and
so
we
have
this
kind
of
question
here
whether
we
should
leverage
more
of
Acme
for
the
identity
questions
specifically
there's
this
retired
draft
of
an
Acme
extension
for
client
certificates
and
one
of
the
slated
uses
is
code.
Signing
so
I
think
there's
some
good
good
potential
there
yeah.
C
So
that's
that's
the
whole
kind
of
prepared
content
we
had
and
I'll
just
mention
for
folks
that
aren't
following
the
chat.
There
was
a
question
in
the
chat
whether
social
media,
like
Facebook,
is
used
for
the
registration,
Authority
vetting
functions,
and
that's
that's
not
true,
specifically
like
we
use
60
uses,
oidc,
open
identity,
connect
for
that
registration
functionality
and
the
public
good
instance
is
configured
to
support
GitHub
identities
and
Google
accounts
and
Microsoft
accounts
today.
I
think
it's
just.
Those
three
is
that
is
that.
B
Right
there
yeah
it's
that
for
open,
ID,
connect,
yeah
and
sorry.
The
Facebook
example
was
was
a
little
bit
silly,
but
you
know
I
think
a
lot
of
folks
are
familiar
with
the
login
with
Facebook
button,
and
that's
that's
often
how
we
explain.
Openid
connect
for
to
the
unfamiliar
but
yeah
as
Joshua
was
saying.
Those
are
not
we're
not
in
general,
suggesting
that
folks
are
are
signing
their
software
with
their
Facebook
account,
though
there's
nothing
stopping
them.
It's
just
not
supported
on
the
public
instance.
A
H
The
thing
that
bothers
me
about
this
is
this
ephemeral
certificate
I've
heard
that
this
then
winds
up
leveraging
just
somebody's
email
address
it's
okay,
so
if
it's
ephemeral
and
it
goes
away
in
10
minutes,
how
do
you
check
do?
Are
you?
Let
me
ask
this:
are
you
able
to
check
it
later
that
that
I
mean
if
it
goes
away?
How
can
you
monitor
that,
and
doesn't
this
wind
up
being
a
very
low
level
of
security
just
about
anybody
with
a
a
login
somewhere
can
start
signing
things?
B
B
I,
look
at
that
certificate
that
that
website
presents
me
and
the
current
time
better,
be
inside
of
that
validity
period,
and
so
I
didn't
dwell
on
this
and
and
perhaps
I
Could
Have
Spent
A
Little,
More,
Time,
On
It,
when
you're
verifying
a
digital
signature.
There's
a
different
question.
You're
asking
one
thing
you
could
do
right
is,
you
could
say
I'm
going
to
apply
the
same
rule
right
I
am
going
to
have
my
signatures
from
this
certificate
be
valid
for
the
duration
of
the
certificate.
B
I'm
also
going
to
give
you
the
certificate
and
you're
going
to
be
able
to
validate
that
certificate
up
to
the
certificate.
Authority
I'm,
also
going
to
give
you
that
signed
time
stamp
from
the
transparency
log
and
those
things
together
are
going
to
be
enough
to
convince
you
that
the
signature
happened
during
the
duration
of
the
of
the
during
the
validity
period
of
the
certificate,
and
so
I
think.
In
fact
this.
This
actually
winds
up
being
in
some
in
some
sense,
is
more
secure.
B
H
Yeah
basically,
it
sounds
like
I
understand
that,
because
you're
relying
upon
the
other
signature
that
happens
with
the
other
trusted
signature,
certification,
Authority
so
you're
see
here.
Let
me
repeat
it
back
to
you.
So
during
the
time
when
you're
transacting,
with
this
one
person
you
they
say,
here's
who
I
am
they
say:
here's
my
temporary
certificate
and
I'm
signing
this
and
all
that
is
being
signed
by
this
other
entity
as
well
during
this
time,
stamping
period
and
but
my
certificate
disappears.
H
H
You
know
that
that
identity
service
that
you're
using
to
say
yeah.
This
is
a
we've
identified
this
entity
or
this
person
and
and
here
so
then
you're
relying
upon
that
as
well
I
understand
the
the
certification
part
is
all
fine
and
dandy,
but
but
you're,
relying
upon
a
very
minimalistic
view,
I.
Think
of
of
the
identity
of
that
person.
Correct.
B
You
know
to
a
legal
office
and
check
that
you
had
paperwork
on
file
there
and
check
your
driver's
license
and
all
of
that-
and
it
turns
out,
we
had
a
lot
of
you-
know,
scaling
problems
with
that
and
so
I
think
the
the
beauty
of
let's
encrypt
and
Acme
is
that
we
decided
to
really
narrow
the
claim
that
we
were
making
in
a
certificate.
When
you
know,
let's
encrypt
hands,
you
a
certificate
that
says
example.com
on
it.
It's
not
saying
anything
about
who
you
are.
B
It's
just
saying
the
person
I'm
getting
the
certificate
to
has
proven
conclusively
to
me
that
they
have
the
right
to
serve
traffic
from
example.com
and
I.
Think
that's
exactly.
What
we're
trying
to
do
here
is.
Is
that
we're
not
not
trying
to
suggest
that
if
I
give
a
certificate
to
you
know
Zach
example.com,
that
you
should
trust
that
I'm
just
trying
to
suggest
that
things
signed
by
that
something
with
that
Associated
certificate
are
attributed
at
all
to
me
and
then
it's
up
to
kind
of
external
policies.
B
Why
you
know
whether
you
trust
a
particular
Identity
or
not,
and
we
have
we
have
some
worked
examples
and
and
kind
of
the
package
repository
settings
so
think
about.
You
know:
you're
you're,
installing
something
a
python
package
from
the
python
package
index
the
what
you'd
want
to
do
there
is
you'd
want
to
figure
out
if
I'm
trying
to
install
package
Foo,
who
is
the
owner
of
package
Foo
and
then
does
the
signature
that
I
see
have
an
identity
corresponding
to
the
person.
B
I
expect
to
be
the
owner
of
that
package,
so
I
I
definitely
concede
that.
You
know
it's
pretty
easy
for
someone
evil
to
get
a
you
know
to
get
a
certificate
in
the
system.
I
I
think
that
our
protections
against
that
need
to
happen
at
a
at
a
different
kind
of
policy
layer
separately
there
and
that's
something,
tends
to
be
a
little
more
opinionated
on
and
something
we
tend
to
abstract
out
a
little
bit,
and
so
that's
a
discussion.
I'd
love
to
really
really
continue
on
is
where
those
policies
get
enforced.
H
B
H
B
B
I
Sure
so
Zach
I
was
trying
to
picket.
Why
do
you
think
sync
store
is
doing
notarization
and
to
me
notarization?
Is
a
signature
check
cosine
on
top
of
something
else?
Now
you
can
argue
that
time,
secure,
timestamp,
he's
a
notary
but
you're
not
telling
the
timestamp
server
to
go,
validate
the
identity.
So
that's
really
not
notarization
I
treat
more
six
door
as
a
the
first
signer
of
a
piece
of
content.
They
would
submit
it
off
to
something
like
Sig
store
to
to
be
the
report.
You
know
the
way
to
extend
it.
I
B
Yeah
I
guess
I
guess
this
is
sort
of
all
boils
down
to
what
you
think
the
word
notarized
means
and
and
I
think
you
know
it's
it's
easy
to
have
different
lenses
on
that.
So,
rather
than
try
to
argue
whether
six
door
is
or
isn't
doing
it
I'll
tell
you
what
I
think
it
is
doing
and
I'll
tell
you
what
I
think
it's
not
doing
so
yeah,
so
six
store
is
in
some
sense.
B
I
You
know
exactly
you're
not
taking
the
same
content
right
you're,
taking
The
Unsung
content.
Your
ca
is
the
one
that's
signing
it
and
you're
stack
pushing
a
timestamp
on
top
of
that.
So
it's
really
not
notarization
you're,
not
watching
somebody
else's
signature,
you're,
not
validating
somebody
else's
signature,
you're,
putting
the
first
signature
on
the
content
correct.
Oh.
I
But
that's
a
certificate.
You
issued
them
right,
so
you're
the
backbone
for
giving
them
the
signature
you're,
basically
acting
as
a
femoral
CA,
to
give
them
the
ability
to
sign
it,
you're
not
validating.
This
is
back
to
Ray's
question
of
you're,
not
double,
checking
that
the
email
address
they
gave.
You
belongs
to
them,
you're,
you're,
being
part
of
the
pipeline,
and
just
be
careful
here
to
me.
Notarization
is
like
a
human
notary
they're
watching
you
sign
something
in
put
a
stamp
on
top
of
it
saying
yep.
That
was
that.
I
I
No,
no,
no!
That's
not
what
I
said:
yeah
I'm
not
saying
that
Zach
I'm,
fine
with
saying
hey,
you
guys
are
CA.
We
we
walk
the
chain
and
all
the
rest
of
it
when
I'm
arguing.
That
is,
if
I
want
audit
to
say
that
Rey
was
Rey.
I
can't
get
that
completely
from
the
Sig
store
case.
I
have
to
walk
back
through
the
token
you
were
provided
with
to
see
hey
what
evidence
does
the
pat
have
in
this?
If
it's
oadc
that
Rey
was
Rey
right.
B
And
that
is
correct,
and
we
have
we're
doing
this
because
in
general
those
those
IDC
tokens
aren't
in
any
way
safe
to
publish
right.
In
theory,
you
could
publish
a
maybe
after
they
expire,
but
in
practice
there's
enough
I
wouldn't
be
comfortable.
You
know
putting
those
those
tokens
out
there,
so
it
is.
It
is
correct
that
that
that
link
is
not
something
that
is
auditable.
B
And
I,
don't
think
oidc
is
a
is
great
at
this
point,
for
making
that
auditable
there
are
some
interesting
extensions
proposed.
Depop
is,
is
one
of
them.
That
would
that
would
enable
us,
in
some
cases,
to
publish
those
tokens
and
have
the
tokens
themselves
be
auditable,
but
at
this
point
know
that
that
is
that
link
is,
is
sort
of
severed.
I
B
E
B
Not
not
quite
so,
the
the
signature,
transparency,
log
or
the
artifact
transparency
log
is
has
support
for
plugable
different
types
that
you
can
put
in
it.
So
you
want.
You
know.
One
of
those
types
is
just
sort
of
plain
signature
over
an
artifact.
Another
of
those
types
is
here,
and
I
may
even
have
something
on
this.
E
B
A
D
Yes,
thanks
for
the
presentation,
I'm
also
trying
to
map
the
two
approaches,
I
I
think
there
is
a
lot
of
commonalities
in
the
transparency
technology
underneath,
but
I
also
believe
that,
at
least
from
the
presentation
are
quite
this
time.
So
so,
in
effect,
you
are
very
much
focused
on
supporting
your
IDC
and
e7i
as
mechanisms,
while
in
the
case
I
think,
for
that
is
the
identification
that
we
delegate
to
Deeds.
D
We
don't
have
to
consolidate
it
with
timestamps
to
guarantee
that
it
was
within
the
right
window
for
the
certificate.
So
so,
in
a
sense,
we
assume
maybe
a
bit
fast,
that
the
problem
of
signing
from
the
issuers
you
bite
is
served
are
more
precisely
that
it
is
someone
else's
problem
and
maybe
from
that
Viewpoint
we
can
have
issues
and
the
record
timestamp
signature
as
a
mechanism
for
sending
claims
as
an
issuer.
D
Conversely,
I
think
that
the
transparency
we
are
looking
at
is
more
like
the
constancy
of
a
claim,
as
part
of
the
connections
followers
to
Black
channels,
so
the
whereas
the
dam
stop
is
Universal
registration
services.
Just
put
the
time
stop
and
accepted.
No
question
ask
I
believe
in
skit
we
are
trying
to
have
a
application
specific
or
supplementation
specific
semantics
to
that,
so
that
the
collection
of
claims
makes
sense,
and
so
we
may
have
a
registration
policies.
You
may
want
to
look
at
versions.
D
A
timestamp
will
be
one
policy,
but
that's
really
not
the
same.
So
you
know:
songs
I,
believe
that
we
are
aiming
to
provide
enough
flexibility
to
capture
some
of
the
semantics
of
The
Sibling
shine
into
registration,
predicate
that
you
apply
before
something
that
notarized
and
so
so.
In
a
sense
we
can
notarize
with
the
damn
storm,
but
do
more
guarantees.
D
You
cannot
first
before
you
can
you
notarize
the
stronger
ounces
you
have
if
something
has
been
notarized
and
is
presented
to
you
and
so
I
think
in
a
sense,
we
can
see
a
six
star
as
a
way
of
securing
issuers
and
that
then
you
would
have
to
figure
out
or
to
reconcile
these
under
8679
versus
using
your
time.
Something
else
I'm
quite
intrigued
by
how
you
can
customize
the
transparency
log
to
include
more
of
the
application,
synoptics
and
I
I
think
you
will
be
doing
that
for
foreign.
B
Tracks
for
me
for
sure
and
I
think
I
think
the
slide
to
some
extent
addresses
the
kind
of
difference
here.
Right.
Skit
is
much
more
opinionated
when
it
comes
to
policies.
You
know
they.
There
are
domain
specific
policies.
You
know
you
have
your
your
Baseline
policies
that
have
everyone's
going
to
support.
There's
a
registry
of
common.
You
know,
well-known
policies,
distinct
ones
can
sort
of
bring
their
own
policies
yeah
and
in
the
six
door
end
of
things
is
is
much
more
minimal
right.
B
D
B
Yeah
I
I
absolutely
agree
that
I
think
I
think
it
is.
You
know,
useful
and
brings
a
lot
of
complexity
and
it's
it's
something
we've
chosen
not
to
do.
My
thinking
here
has
been
informed
a
lot
by
conversations
with
some
of
the
folks
from
the
certificate
transparency
world
who
told
me
about
their
experiences
effectively
thinking
about
yeah.
Can
we
put
much
more
interesting?
B
You
know,
policies
on
submission,
blocking
blocking
specific
certificates
from
being
submitted,
and
one
of
their
big
worries
here
and
I
think
this
depends
on
the
exact
setting
you're
in
whether
this
is
Meaningful
or
not.
But
one
of
their
big
worries
is
that
the
more
checking
that's
done
by
The
Ledger,
the
more
folks,
are
going
to
use
a
heuristic
that
something
in
The
Ledger
should
be
secure
and
to
do
less
of
their
own
validation
and
vetting.
B
So
in
the
issuer
model
right
when
you
know
in
the
issuer
transparency
model,
if
I
think
an
artifact
is
secure,
because
you
know
two
different
people
signed
it
and
a
third
person
signed
that
they
ran
a
tool
on
it
and
the
output
was
positive
or
something
like
that
for
me
to
validate
that
I
would
have
to
validate
that
entire.
You
know
check
that
entire
policy
myself
at
verification
time
and
so
moving.
You
know
these.
These
checks
closer
to
the
verifier,
has
some
pros.
You
know
in
in
terms
of
it
sort
of
minimizes.
B
The
amount
of
of
you
know,
trust
you
you
need
to
have
in
in
kind
of
the
the
system,
with
the
exception
of
the
identity
component,
and
it
also
allows
for
more
Dynamic
policies
that
change
over
time.
I
think
there
are
a
lot
of
interesting
policies
that
you
might
want
to
enforce.
Let's
say
you
know,
like
I,
don't
know
a
container
image
was,
has
a
scan
and
that
scan
has
no
vulnerabilities
in
it,
but
the
vulnerability
database
gets
updated
every
day
and
and
so
just
because
that
was.
B
Might
might
not
mean
it's
true
today
and
so
for,
for
you
know,
artifacts
that
are
kind
of
good
now,
but
bad
tomorrow,
you
know
under
a
particular
policy.
I
I
feel
that's
one
of
the
big
settings
that
I've
had
a
hard
time.
Wrapping
my
mind
around
and
and
one
of
the
things
we
want
to
support,
but
I
I
agree.
You
know,
there's
there's
potentially
some
some
room
for
that
here
and
I.
B
Those
signatures
and
applying
a
policy
and
then
you
can
audit
that
right
and
sort
of
you
know
I
think
both
these
layers
are
interesting.
I
think
there's
a
lot
of
benefit.
You
know
a
lot
of
games
you
can
have
by
just
sort
of
starting
with
the
simplest
part
of
that
problem
and
then
building
on
top
of
that,
as
opposed
to
you
know,
I
I
don't
want
to
say
that
the
skip
proposal
lumps
them
together
because
I
think
did
in
some
sense.
B
You
know
cover
the
issue
or
transparency
side
of
things,
but
but
you
know
sort
of
introduce
at
that
level
and
then
and
then
kind
of
build
those
policies
on
top
yeah
I
agree.
This
is
an
interesting
discussion
and
I
think
you
know
there
are
pros
and
cons
to
different
techniques.
Here
and
that's
that's.
You
know
something
I'd
love
to
continue
discussing
the
the
relative
merits.
I
B
B
These
are
operated
by
the
same
party,
but
you
could
certainly
imagine
them
being
operated
by
different
parties
and
I
think
the
more
narrow
you
can
make
the
trust
you
have
to
place
in
in
someone
in
in
general,
the
better
and
then
and
then
building
on
top
of
that
right.
Any
any
sort
of
policy
validation,
checks
that
have
to
happen
by
a
third
party
being
being
extremely
explicit
about
who
is
authorized
to
do
that.
J
B
It
does
not
have
a
CSP
in
in
sort
of
the
RFC
prescribed
format.
We
do
document
a
lot
of
the
practices
around
the
management
of
that
and
I'd
be
happy
to
follow
up
on
the
mailing
list
and
and
send
a
pointer
to
some
of
that
documentation
there.
So
we
don't
follow
the
format
and
I
think
that's.
You
know
to
some
extent
acceptable.
J
Okay,
so
I
I
I'll
just
go
ahead
and
share
with
you
that
this
would
never
fly
within
the
energy
industry,
because
there
are
regulations
that
require
more
vetting
than
that.
But
my
other
question
is:
let's
say:
I
already
have
a
signed
artifact
like
I
I,
have
a
software
package
called
seg
PM.
If
I
wanted
to
submit
that
to
Sig
store,
could
I
do
so
and
if
I
and
if
I,
could
how?
How
would
I
do
it.
B
Yeah,
absolutely
and
so
I
focused
on
this.
This
kind
of
ephemeral,
CA
use
case,
but
the
signature
transparency
log
actually
doesn't
rely
on
that
right
and
and
sort
of,
if
you're,
really
just
interested
in
getting
signatures
in
public
somewhere,
where
you
can
walk
the
the
log
of
all
the
signatures
and
and
see
which
ones
apply
to
your
artifact.
B
We
can
do
that
now,
and
so
the
idea
is,
you
just
have
to
format
it
in
you
know
format
your
signature
in
one
of
the
formats
that
we
accept,
which
you
know
there's
a
number
of
standard
formats
like
gpg
envelopes,
or
we
even
support
cozy
envelopes,
send
that
up,
and
then
you
can
do
that
if
you
have
your
own
CA
ecosystem
that
you
trust
right.
If
your
industry
has
Cas
that
are
used
within
that
industry,
those
those
can
go
right
in
there.
B
J
B
J
A
A
G
There
we
go.
Can
you
hear
me
yep,
oh
boy,
okay,
thank
you.
I'm
gonna
distill,
this
down
to
the
shortest
version.
I.
Can
what
can
I
and
can
I
not
know
about
an
object
with
six
store?
Can
I
know,
for
example,
who
owns
it
at
this
time?
Who
is
responsible
for
maintaining
the
certificate?
I
mean
what
what
can
I
what
information
can
I
get
and
then
what
information
can
I
not
get?
Can
I
not
get,
for
example,
the
status
of
that
at
the
current
time?
If
it's
a
past
certificate,
that
kind
of
thing.
B
Yeah
yeah,
so
that's
that's
a
a
really
good
question
and
I
think
I'll
try
to
answer
as
narrowly
as
possible
and
I
think
I
think
you'll
find
we
can
do
quite
a
lot
with
that.
So
what
you
can
know
is,
assuming
that
you
know
the
the
certificate
Authority
is,
is
doing
its
job
properly.
You
can
know
who
said
what
about
an
object
right
you
can
know.
You
know
this.
B
You
know
someone
who
authenticated
with
this
email
address
made
this
claim
about
this
object
at
this
time,
and
you
can
you
know
view
those
statements
in
you
know
in
totality
altogether
and
make
your
own
judgment
According
to
some
policy
as
discussed.
You
know,
the
policy
is
something
that
we've
focused
a
lot
less
on
in
this
case,
and
we've
we've
sort
of
left
in
in
general
to
to
third
parties
to
do
that
policy,
and
especially
trying
to
push
that
as
much
of
that
to
clients
and
clients
doing
verification
as
possible.
A
G
I
think
there's
a
just
comment:
there
I
think
that
it's
pretty
lightweight
compared
to
what
we're
envisioning
for
skit.
If
my
perception
of
the
two
is
correct,
so
we
would
need
to
come
up
with
you
know,
sort
of
a
narrow
interoperability
and
maybe
a
narrow
commonality
statement
and
then
go
from
there,
because.
G
C
A
Again
for
the
presentation,
I
think
that
was
triggered
there,
a
couple
of
very
good
discussions
and
we'll
have
to
discussions
on
how
to
continue
discussions
on
a
meeting
list
or
maybe
in
in
future
meetings
as
well.
Good
I
think
those
are
good
data
points
also
when
we
talk
about
the
architecture
itself,
unfortunately,
because
it
took
a
little
bit
longer
than
I
thought.
I
didn't
want
to
stop
the
discussion
because
it
was
good
we
weren't
able
to
get
to
talk
about
some
of
our
other
agenda
items.