►
From YouTube: Digital Identity Attestation WG (March 3, 2021)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
B
A
C
B
B
B
All
right
start:
where
did
you
want
to
cool.
A
Yeah,
let
me
just
remind
real
quick
once
no,
you
got
that
set
up.
Let
me
do
my
homework
and
remind
people
to
sign
in
the
document
drop
the
link
into
chat
and
all
of
that
stuff,
and
then
let
you
kick
off.
Yeah.
D
A
Here's
the
agenda
doc,
I
just
dropped
it
into
the
chat.
People
should
have
access
to
it.
It
is
march
3rd.
Please
sign
in
here
kim
is
the
only
one
that
signed
in.
A
Yeah
and
the
only
thing
on
the
agenda
today
is
this
notary,
v2
presentation
and
discussion
so
add
other
topics
there
to
cover
at
the
end.
If
we
have
time
and
then
we
will
turn
it
over
to
steve's,
introduce
yourself
and
jump
in
steve
yeah.
B
Hi,
so
thanks,
this
is
kind
of
a
last
minute,
but
a
well-timed
discussion.
So
thanks
for
having
me
so
I
work
at
microsoft
for
the
container
registries
at
microsoft,
which
includes
our
acr
content
for
customers
to
use
on
azure
and
ncr
for
how
we
ship
our
software
as
a
micro.
B
You
know
it's
microsoft
as
a
software
company,
not
just
a
cloud
so
that
kind
of
brought
some
interesting
questions
to
us
is
how
do
we
ship
software
in
a
container
and
have
it
pulled
and
run
on
other
clouds,
because
we
like
to
get
revenue
for
our
software
to
run
on
other
clouds
as
well?
That's
fine
or
on-prem
or
wherever.
But
how
do
we
gain
trust
in
that
and
or
not
we
but
the
customer?
Sorry,
we
as
users,
so
the
notary,
v1,
stuff
or
docker
content.
Trust,
as
it's
known
I
was
you
know.
B
Docker
did
some
amazing
things
and
there's
some
places.
They
didn't
get
a
chance
to
really
finish,
and
this
is
one
of
those
there's
challenges
with
notary
v1,
which
we'll
talk
about,
and
our
goal
is
to
make
notary
v2
the
answer
to
be
able
to
move
signatures
across
all
clouds
and
we'll
talk
about
that
in
detail.
So,
as
part
of
that,
as
you
heard
me,
talk
about
that,
you'll
see
that
it's,
it's
really
our
need,
even
as
microsoft,
for
this
to
run
on
all
clouds.
B
So
that's
why
we've
been
going
through
this
process
to
have
it
part
of
an
open
standard
that
any
registry
can
run
so
so,
if
you
kind
of
were
to
sum
it
up,
what
is
it?
It
really
is
a
mean
design,
artifact
and
what
I
mean
by
artifact
is
we
can
put
anything
in
a
registry
in
all
major
clouds
and
registry
projects,
also
support
artifacts.
Now,
where
you
can
take
this
infrastructure
with
all
the
v-nets
and
security
and
availabilities
and
all
the
ideas
and
store
other
content,
including
vms
in
it.
B
So
you
want
to
be
able
to
put
these
artifacts
in
a
registry,
and
we
want
our
users
to
have
confidence
in
the
content
they
consume.
Is
the
content
that
was
produced
from
the
authors?
You
trust
so
that's
kind
of
our
headline.
If
you
will,
I
just
made
it
up
yesterday
so
we'll
see
if
it
sticks,
I-
and
we
would
like
said
we
want
to
make
it
available,
but
in
any
oci
artifact
registry,
and
we
want
to
make
it
easy
for
the
signatures
to
travel
with
the
artifacts.
B
Of
course,
we're
talking
majority
of
images,
but
there's
a
lot
of
other
things
in
there
as
well
to
get
a
feel
of
the
workflow
kind
of
paint
a
little
picture
of
how
we're
thinking
about
this.
So
we
have
this
wabbit
network
software
company
right
they
make
some
network
monitor
software
and
they
have
a
build
system
in
that
build
system.
You
know
in
their
complete
air
gapped
private
environment
having
nothing
to
do
with
anything
on
the
internet
or
maybe
it's
on
the
internet.
It
doesn't
matter,
but
it's
their
private
environment.
B
B
They
want
to
consume
some
software
and
you
know
they've
never
heard
of
this
company,
but
they
want
to
be
able
to
know
that
the
software
they
bring
into
their
environment
is
trusted,
and
you
know
sound
so
to
speak
now.
The
problem
is
they
don't
really
know
of
wabit
networks?
Small
company?
That's
fine!
B
There's
lots
of
great
companies
out
there,
so
they'll
go
to
docker
hub
and
say:
look
I'm
looking
for
you
know,
content
here
and
acme
rockets
has
a
policy
that
says:
they'll
only
allow
software
to
come
in
that's
signed
from
approved
vendors
or
docker
certified
content.
Let's
just
say
so,
weber
networks.
They
can
push
their
software
to
docker
hub.
They
can
work
to
get
into
the
certification
program.
B
Whatever
that
means
right,
that's
the
point
is
we're
enabling
the
business
opportunity
and
a
trust,
so
docker
decides
they're
going
to
certify
some
content,
and
now
it
passes
acme
rocket's
trust
list.
So
now
they
can
find
that
content
and
bring
it
into
their
environment.
And
one
of
the
things
we
want
to
enable
is
that
on
import
of
content,
does
it
match
a
set
of
signatures?
Does
it
match
a
set
of
keys?
B
So
in
this
case
acme
rockets
might
say
I
I
don't
know
who
why
but
networks
is,
but
I
trust
docker
hub,
so
it's
allowed
in
now,
once
it's
brought
into
the
acme
rockets
environment,
you
know
we
want
to
be
able
to
say
it
was
scanned.
It
was
reviewed,
it's
been
stamped
and
the
analogy
here
that
I've
been
following
is
you're
going
into
the
airport
when
we
used
to
do
that,
you
have
some
id
you've
got
a
driver's
license
a
passport
or
something,
and
you
present
it
to
the
security
guard.
You
know
the
tsa
agent.
B
That's
there
now
they're
not
going
to
go
and
look
to
see
if
your
passport,
you
know
all
the
documents
you
use
to
get
your
password
they're,
not
asking
for
a
birth
certificate,
they're
not
asking
for
all
those
details.
They're
assuming
the
passport
that
you
got
is
valid.
They
double
check
it's
valid
by
scanning.
It
basically
checking
a
revocation
list
and
as
long
as
that's
good,
they
will
then
take
your
boarding
pass
and
stamp
it
with
agent
22
whatever.
That
means
right.
So
that's
effectively.
B
What
we've
done
here
is
acme
rockets
now
stamped
check
that
software
as
it
came
in
they've,
stamped
it
with
their
stamp
and
now
as
that
software
is
roaming
around
the
terminal.
You
know
as
you're
walking.
If
you
get
on
the
plane,
they
don't
check
your
passport
and
driver's
license.
They
look
at
your
boarding
pass
and
does
it
have
the
you
know
the
acme
rocket
stamp
on
it
and
if
it
does,
it's
allowed
to
be
used.
So
there's
that
multiple
lines
of
defense,
but
it's
got
all
the
lineage
of
what
happened
there.
B
So
if
there's
a
problem-
and
I
don't
know
the
tsa
agents
working
for
the
deep
state
or
whatever
you
know
fun-
con
conspiracy-
you
want
to
make
you-
can
go
back
and
double
check
and
like
you
might
have
been
working
for
the
deep
state,
but
it
turns
out
those
signatures
were
valid,
so
everything's
fine,
now
acme
rockets
now
wants
to
deploy
this
software
create
a
deploy
script
whatever.
That
means
helm,
chart
pod
spec,
some
other
container
deployment
script
terraform
whatever,
and
they
signed
that
also.
B
B
The
idea
is
that
you
can
do
a
deployment
and
on
the
deployment
it
can
see
the
deployment
you
know
what's
being
referenced
and
says
well,
is
it
signed
and
we
want
to
do
this
in
a
way
that
kind
of
a
non-trojan
horse
kind
of
way.
We
want
to
be
able
to
query
the
registry
for
the
artifact,
that's
being
asked
to
be
to
be
deployed
and
it
could
be
deployed
by
the
digest
or
the
tag
it
will
go.
B
B
So
that
is
part
of
the
you
know
the
workflow
that
we've
discussed-
and
you
know,
as
with
many
software
projects,
there's
lots
of
great
designs.
People
love
to
start
something
in
code,
and
I
know
what
this
is:
here's
some
code
and
look
at
my
code
and
look
at
this
design
and
what
we
found
is
there's
lots
of
great
designs.
B
B
So,
like
I
said
the
first
thing
is
we
wanted
to
solve
some
problems
with
notary
v1,
and
that
is
when
I
push
something
to
a
registry
and
I
pull
it.
If
I
pull
it
with
or
without
signing
or
content,
trust
or
notary
enabled,
I
should
get
the
same
content
and
that's
not
the
case
with
notary
v1,
so
we
want
to
make
sure
they're,
collated,
co-located
and
secured
in
that
registry.
B
It's
got.
You
know
all
of
the
authentication
and
certification
and
another
piece
of
this
is
the
ephemeral
clients.
You
know
we
saw
with
the
solarwinds
exploit
and
others
having
a
build
machine
stick
around
for
a
long
time
can
be
problematic
right.
If
I
can
get
on
that
machine
on
monday,
and
it's
there
all
week
or
for
many
months,
you
know
booyah,
I've
got
I
own
that
machine.
It
has
to
get
built
an
instance
every
time
that
certainly
makes
it
harder.
B
Now
you
got
to
get
into
the
infrastructure
knows
how
to
provision
that
vm
or
whatever.
That
client
is
every
time
we
want
to
get
rid
of
trust
on
first
use
because
trust
on
first
use
says
if
I
injected
something
bad
now,
you've
owned
it
from
first
use
forward.
So
we'll
you
have
to
have
an
implicit
permissions
on
acquiring
keys
and
so
forth.
B
As
I
mentioned
earlier,
we
want
to
make
sure
these
are
work
across
all
registries
from
your
pure
business.
This
is
required
and,
quite
frankly,
we
see
our
customers
are
multi-tenant
multi-uh,
multi-cloud
scenarios
and,
as
you
saw
through
that
workflow
there's
multiple
signatures
that
got
attached
to
that
same
artifact.
B
Wabbit
network
signed
it
originally
dockerhub
added
another
one,
acme
rockets
added
a
third,
and
you
can
imagine
fifth.
Fourth,
fifth,
sixth,
we
don't
see
hundreds
but
there's
multiple
signatures
that
can
be
added
to
it,
multi-tenant
multiple
cloud
providers.
We
want
to
make
sure
that
we're
not
trying
to
do-
I
don't
say
not
trying
to
key
manager
we're
trying
to
we're
not
trying
to
store
keys
in
a
registry.
The
registry
is
great
for
what
it
does
and
there's
great
cloud
provider.
B
Sorry
key
vault
providers
available
and
we'll
integrate
with
those
we're
not
going
to
try
to
replace
any
of
those,
whether
it
be
a
cloud
provider
or
hashicorp
for
open
source
projects
or
whatever
airgap
is
not
just
the
submarines
and
oil
platforms.
We've
all
seen
our
customers
that
were
working
great
on-prem
in
their
private
network.
They
want
to
lift
that
into
the
cloud
and
have
no
public
access
ingress,
no
egress,
no
nothing!
B
B
Usable
is
pretty
important.
I
like
using
the
analogy
you
can
have
a
really
super
safe
door
with
20
locks
on
it
and
magic,
crypto
keys
and
if
you've
got
to
walk
through
it,
a
lot
user's
just
going
to
hold
the
door
open
with
some
piece
of
wood
or
a
brick
right.
It
has
to
be
a
very
usable
fashion.
Super
secure,
unusable,
not
used
or
bypassed.
We've
got
to
find
that
right
balance.
That's
always
very
important.
B
B
The
other
thing
that
I
get
asked
a
lot
is
compatibility
with
notary
v1.
We
actually
don't
see
a
lot
of
usage
of
notary
v1.
We
see
people
trying
to
make
it
work
because
it's
really
the
only
thing.
It's
not
the
only
thing,
but
it's
one
of
the
few
things
that
actually
works
across
multiple
clouds,
but
it
doesn't
meet
pretty
much
any
of
these
requirements
so
we're
not
promising
any
compatibility,
and
we
kind
of
use
the
bar
that
if
it's
not
super
simple
to
sign
with
v2,
then
we
failed
and
it's
irrelevant
anyway.
B
This
is
kind
of
broken
out
into
three
major
areas
of
focus
that
we've
been
taking
in
the
team.
One
is
obviously
defining
what
exactly
is
a
signature,
and
we
have
a
pretty
good
form
of
that
today.
B
Then
it's
great
to
have
signatures,
but
how
do
you
get
them
to
go
with
the
content?
We
thought
about
making
registries
know
very
specifically
around
signatures,
and
we
just
didn't
think
that
that
was
a
very
good
scalable
idea.
B
We
went
through
this
when
we
did
the
oci
artifacts
approach,
where
we
were
trying
to
add
helm
capabilities
specific
to
a
registry
and
before
we
could
even
finish
thinking
about
it.
We're
already
asked
about
terraform
and
oppa
and
cnab,
and
I
don't
know
a
bunch
of
other
types
and
we
didn't
want
to
go
chase
each
one.
B
If
you
think
of
a
file
system,
you
know
on
your
computer,
it
doesn't
know
about
the
different
types
right
you
can
save
any
file.
You
want
make
the
extension
anything
you
want
whatever
you
know,
however,
you
register
with
your
operating
system.
What
the
the
thing
is,
the
operating
system
doesn't
know
anything
about
it.
It
just
knows
how
to
store
stuff,
and
it
knows
how
to
link
stuff
too.
B
So
that's
what
we've
really
designed
here
is
and
signature
is
just
another
thing:
that's
going
to
go
in
a
registry
and
we'll
talk
about
an
extra
piece
of
that
and
then,
of
course,
key
management.
We're
less
worried
about
the
signing
part
for
private
key
management,
then
that
companies
already
have
great
ways
to
to
do
that.
In
fact,
some
are
super
secure
and
you
know
and
others
it
can
take
a
little
more
of
a
trusting
model,
but
that
we're
not
as
worried
about
it
we're
more
worried
around
the
consumption.
B
So
how
do
I
just
if
we're
not
going
to
do
trust
and
first
use?
How
do
I
discover
what
the
key
is,
so
I
can
can
get
it.
B
So
we
broke
down
the
pieces
of
the
projects
that
we're
working
with
here.
Obviously,
there's
the
registry:
that's
going
to
store
all
this
stuff.
We
have
the
artifacts
whatever
that
thing
might
be.
We
have
our
signature,
we'll
have
some
kind
of
nv2
client,
which
will
more
than
likely
be
a
set
of
libraries
that
will
have
a
client
that
basically
implements
libraries,
but
we
want
those
libraries
to
be
able
to
be
implemented
in
all
the
different
container
projects
or
all
the
artifact
projects.
B
And
then
we
have
an
auras
client,
which
we
use
as
part
of
this,
also,
which
again
is
also
another
set
of
libraries
for
working
with
registry,
and
whereas
is
just
oci
registry
as
storage,
I'm
gonna
go
do
a
demo,
but
before
I
drill
into
them,
were
there
any
questions
that
anybody
wanted
to
ask
on
that
framing.
B
Okay,
just
get
to
the
demo
already
all
right.
So
what
we
have
here,
what
I'm
going
to
do
is
I'm
going
to
walk
through
a
bit
of
the
the
walk
through
walk
flow
that
we
had
in
that,
and
this
demo
is
the
demo.
Steps
are
actually
up
on
our
env
in
the
nv2
site,
so
I'm
just
going
to
walk
through
this.
B
B
So
what
we've
done
is
we?
We
didn't
actually
change
the
docker
client,
yet
what
we've
done
is
we've
taken
advantage
of
the
plug-in
model
and
if
you
notice,
there's
two
plug-ins
that
we've
added
here
and
they're
captured
on
that
page,
that
I'll
show
later
and
there's
a
docker
generate
and
there's
an
nv2
plug-in
and
those
both
will
enable
us
to
do
this
experience.
B
So
if
I
say
docker,
nv2
notary
you'll
see
just
a
framing
of
a
couple
of
commands
that
we
use
now,
instead
of
having
to
type
docker
in
v2
every
time,
I'm
just
going
to
alias
this.
So
now
I
can
say
docker,
notary
and
it'll
be
fine
and
then
the
other
thing
I'm
going
to
do
is
not
have
to
type
the
long
register.
This
is
the
image
name
that
I'm
going
to
be
signing
and
pushing
and
pulling
so
it's
just
the
registry
name
the
image
and
the
tag
right.
So
that's
the
main
thing
there.
B
So
we'll
start
with
you
know
in
the
build
environment
right.
This
is
some
ephemeral
client
that
we're
saying
and
we're
just
gonna
do
a
build,
and
if
you
say
it's
a
femoral
client
in
a
private
network,
then
how's
it
getting
out
to
github.
So
I
skipped
the
clone
part.
You
know
anyway,
point
is
we're
building
an
image,
there's
nothing
magic
about
it.
It's
just
a
plain
old
image.
B
Now,
the
next
part,
as
I
mentioned,
is
I
would
want
to
acquire
these
private
keys.
Now
you
could
say
the
ephemeral
client
might
have
been
provisioned
and
then
knew
how
to
go
reach
out
to
its
key
vault
with
a
security
token
and
acquire
those.
So
the
point
of
this
I
have
actually
already
have
the
keys
on
the
machine
that
that
secure
handshake
has
already
been
done.
B
I
could
sign
if
I
can
copy
paste,
so
all
we're
doing
is
taking
we're
talking
about
resign
use
the
web
network's
key
the
cert
and
sign
this
image,
and
if
we
look,
we
can
see
that
it
is
part
of
this
flow
because
remember
I
didn't
push
anything
yet.
I'm
still
working
completely
offline
and
today
the
generation
of
that
manifest
is
kind
of
built
into
the
push
scenarios.
B
B
And
that's
a
jwt
and
we'll
go
into
the
signature
details
in
a
minute
and
if
I
wanted
to
look
at
the
manifest
that
we've
actually
signed,
this
is
the
manifest
for
that
net.
Monitor
image.
I've
purposely
kept
it
small,
it's
a
single
layer,
it's
basically
just
alpine,
it's
a
single
layer
and
it's
got
a
media
type.
So
there's
basically
two
blobs
in
it.
This
manifest
has
a
diet.
Well,
it's
got
digest
for
the
things
it
references
and
the
manifest
itself
has
a
digest.
So
there's
digest
upon
digests,
that's
what
we're
actually
signing.
B
B
So
that's
the
important
part,
because
we
don't
want
users
to
be
changing
their
workflow
to
have
to
think
about
signatures
per
se
like
we
don't
want
them
to
query
a
signature.
They
want
to
query
the
thing
they're
trying
to
deploy
or
use,
and
then
the
workflow
knows
how
to
get
the
signatures
associated
with
that
artifact
in
this
case
an
image.
So
that's
the
important
right
there
all
right
so
now.
Let's
imagine
we're
on
a
different
machine,
actually
hold
on
docker
images.
B
B
B
Now
let
me
get
rid
of
it
and
I'm
also
going
to
get
rid
of
any
of
those
signatures.
So
this
is
effectively
another
another
machine
all
right.
So
where
did
I
do
that
cat
anyway?
Trust
me,
the
cat?
I
don't.
I
won't
go
back
there,
but
now
this
machine
has
no
images,
no
signatures
on
it.
Yet
so,
I'm
going
to
say,
docker
pull
image,
so
it
went
and
looked
for
that
image
right.
So
that's
what
it
went
to
go.
Look
for!
B
B
B
The
way
that
the
current
configuration
right-
this
is
just
part
of
the
prototype
is
we've
got
a
a
config
file
under
it's
under
docker.
It
doesn't
really
matter.
There's
an
nv2
json
file
notary
is
enabled,
and
then
here
is
the
location
of
where
the
cert
is
so
I
happen
to
have
this
cert
location
here
and
I'm
running
it
locally,
so
it's
insecure.
B
Now
because
I
have
the
signature,
it
said
found
a
signature
found
a
valid
signature
and
then
it
notices
where
it's
the
signature.
The
image
originated
from
it's,
went
and
looked
at
all
the
details,
so
it
says,
look
I
found
it.
It's
got
a
good
signature,
I'm
going
to
pull
the
image;
basically
it
hands
it
back
to
docker
and
says,
go
and
now
I
now
have
that
image
here
again.
B
That
demonstration
pieces
of
this
workflow
yeah
go
ahead.
David
yeah.
D
So
it
looks
like
the
signatures
are
being
maintained
separately,
so
you
could
rebuild
the
docker
image
and
verify
that
it's
identical
without
having
to
muck
with
or
deal
with
signatures,
because
they're
embedded
in
is
that
correct.
B
B
Sure
in
theory,
if
you
built
the
exact
same
content
on
the
exact
same
machine
and
every
package
you
pulled
was
the
exact
same
state
in
theory
that
would
generate
the
same
digest
and
manifest
in
practice
when
you've
gone
that
far
to
complete
to
really
do
a
full
docker
build
again
assuming
you've
done
it
pulling
all
the
content
like
if
you
do
a
docker
build
of
the
same
exact
content
over
and
over
you're
right,
completely
completely
valid.
What
the
notary
v2
model
is,
is
it's
signing
the
digest
of
the
manifest?
D
Well,
if
you're
pulling
in
different
components,
then
it
is
different
and
it
should
be.
It
should
produce
a
different
result,
but
it's
just
I
was
just
checking
about
the
signatures
are
separate
and
therefore,
if
it's
repeatable
there's
no
problem
and
if
it's
not
repeatable
well,
it's
not
repeatable.
B
B
No
we're
not
completing
a
new
repeat
about
the
repeatability
problem,
but
we
haven't
spent
enough
time
to
be
fair
thinking
about
the
how
the
repeatable
builds
will
merge
with
this.
I
think
the
repeatable
builds
will
have
to
probably
lean
into
more
to
the
s-bom
model.
To
explain
like
does
the
is
the
is
the
s-bomb
that's
generated,
including
the
compiler
settings
right.
All
those
different
pieces
is,
are
those
exactly
the
same
and
I'll
talk
a
little
about
s-bombs
here
in
a
moment.
B
So
what
are
we.
D
B
So
so,
just
a
quick
cause,
this
kind
of
leads
into
this,
so
this
is
the
manifest
for
that
particular
net,
monitor
image
and
that's
the
digest.
So
when
we
look
at
the
signature,
we're
actually
signing
this
digest.
B
So
if
we
look
here,
here's
a
little
more
detail,
it's
a
formatted
of
the
signature,
it
gets
turned
into
a
jwt,
so
we
could
actually
round
trip
that
because
the
whole
canonicalization
challenges
that
we
keep
hearing
about.
B
So
we
have
cert
references.
We
are
focused
in
x-509,
there's
the
oci
descriptor
of
the
artifact,
and
that
in
this
case
happens
to
be
a
docker
image
that
could
be
a
helm
chart.
It
could
be
other
things
we'll
talk
about
that.
We've
also
included.
This
is
an
experimental
part
of
this
that
we're
looking
at.
Basically
when
you
want
to
validate
a
signature,
validate
an
artifact
right
now,
we're
thinking,
there's
two
levels:
one
is
the
key
valid
right,
so
the
the
public
key
that
I'm
comparing
against
the
cert.
Is
that
valid?
That's
good.
B
So
let's
say
that
dockerhub
didn't
resign.
The
image
and
acme
rockets
didn't
resign
the
image,
but
they
followed
the
best
practices
of
don't
depend
on
public
content
in
your
environment
right.
You
should
not
have
deployments
based
on
public
polls,
put
them
in
a
registry
that
you
own,
that
you
have
control
over
it's
in
your
network
control
and
not
subject
to
the
fun
of
the
eight
million
connection
points
in
the
internet.
B
So
you
pulled
it
into
your
private
registry,
so
this
one
I'm
actually
going
to
deploy
from
acme
registry.acme
rockets,
but
this
particular
content
is
signed
from
where
it
was
originally
pushed
to.
So
I
could
make
a
choice
and
say
the
weapon
network.
Signature
is
good,
so
I
trust
it,
but
I
don't
allow
anything
to
be
deployed
from
anything
other
than
the
registry
that
then
there's
a
specific,
the
registry
that
it's
signed
from.
B
D
B
A
subtlety,
I'm
not
understanding
and
to
be
fair.
I
haven't
practiced
this
a
little
bit
better.
To
do
the
talking
points
when
I
want
to
validate
a
signature.
The
first
thing
is:
is
the
key:
is
the
public
key
still
valid?
Was
it
revoked
and
is
the
content
signed
with
that
key
and
is
the
content
you
know
signed
against
the
signature?
So
that's
the
standard
things
we
all
think
about.
So
that's
the
the
kind
of
table
stakes.
B
There's
a
second
piece
that
we
see
customers
saying
is:
I
don't
want
to
deploy
content
to
this
cluster
to
this
host.
Unless
it
comes
from
specific
registries,
they
want
to
block
things
coming
from
docker
hub
from
quay
from
sorry
gcr.
If
it's
not
in
azure
in
azure
in
google,
you
should
be
blocking
stuff
coming
from
acr
for
that
matter,
right
put
it
in
a
customer's
private
registry.
B
E
D
B
B
So
then,
there's
just
and
then
there's
details
of
the
the
signature
itself,
all
right!
So
that's
you
know,
for
the
sake
of
time
here
so
dan
said,
make
sure
I
leave
time
for
questions
so
where
we're
at
is
prototype.
What
I
just
demoed
was
prototype
one.
We
did
that
last
september.
B
We
completely
hacked
the
registry
to
make
this
work.
We
took
cncf,
what's
now
cncf
distribution
and
we
basically
jacked
in
some
stuff
related
to
how
storage
gets
done.
The
way
we
do
the
linking
now
that
we've
proven
this
model
works.
B
We're
basically
been
focusing
mostly
on
getting
the
changes
to
registries,
to
support
what
we
call
linked
artifacts.
So
that's,
and
this
is
kind
of
a
little
inner
tangle
there.
So
prototype
one
is
done.
Prototype
two
is
now
focused
on
first.
How
do
we
do
the
right
integration
with
something
like
gatekeeper
with
policy
managers
and
we're
looking
for
people
to
help
us
out
to
actually
dig
into
opengatekeeper
and
test?
B
How
does
nv2
interact
with
notary
v2
act
interact
with
something
like
open
gatekeeper
and
we're
now,
like,
I
said,
formalizing
how
this,
how
us
as
registry
operators,
would
actually
be
willing
to
ship
this,
like
nobody,
would
be
willing
to
ship
what
we
did
for
the
prototype,
one,
the
hacks
we
did
to
the
registry
now
that
we
know
the
model
we're
going
to
be
doing
some
changes
to
cncf
distribution
and
the
distribution.
B
Well,
the
oci
artifacts
spec
to
enable
that-
and
that's
what
you
see
here
in
the
second
bullet
and
the
details
of
that
to
get
a
sense.
So
today,
a
registry
knows
how
to
take
a
manifest
that
references,
a
thing:
the
net
mono
image.
It
says
that
manifest
has
a
config
and
one
or
more
layers.
Does
this
downward
pointer
kind
of
thing?
B
But
signatures
are
the
opposite.
So
if
you
remember,
we
said
we
cannot
change
the
digest
or
the
tag
of
something
we
want
to
deploy.
David's
team
has
a
deploy.
Script
that
says,
deploy
net,
monitor
colon
v1
or
deploy
netmonitor
at
sha1234
and
that
deployment
script
shouldn't
change
just
because
I
had
a
signature,
so
we
need
to
be
able
to
add
content
to
a
registry
and
says
by
the
way
I
am
enhancing
this
other
thing
and
multiples
of
those
and
those
signatures
individually
must
be
immutable.
B
So
you
kind
of
see
lots
of
new
things
of
new
references
pointing
up
so
that's
been
the
changes
we've
been
doing
with
oci
artifacts.
To
enable
all
of
this,
the
the
last
picture
is
simply
this
model.
This
interactive
model
of
doing
prototyping
has
been
really
key,
be
key.
Well,
okay,
because
we
have
key
management
experts,
because
we
have
registry
experts,
because
you
have
artifact
experts
and
if
you've
ever
had
a
chance
to
have
been
sagrada
familia.
You've.
B
B
That's
been
critical
to
how
this
development
has
been
working
is
once
you
can
see
and
touch
it
and
play
with
it.
We've
been
able
to
see
where
different
people
would
plug
in
so
there's
obviously
going
to
be
a
spec
coming
out
of
it.
I
touched
a
little
bit
on
the
the
signature
spec,
but
we
you
know
we
wanted
to
experiment
with
it
and
make
sure
that
the
spec
is
actually
implementable.
B
So
that's
where
we've
been
at
this
presentation
itself
is
located
there,
the
notary,
v2
folks.
We
we
meet
every
week
on
mondays
at
9
a.m.
Pacific
time
I
got
just
justin
couldn't
make
it
today.
Usually
we
co-present
these
and
that's
the
talk
so
questions
comments,
thoughts.
C
Is
the
a
question
about
the
the
schema
for
the
manifest?
Is
that,
based
on
work
that
this
particular
you
know,
project
is
defining
or
is
it
looking
at
other
industry
efforts
to
define?
You
know
standardized
schemas
for
a
manifest,
oh
so,
which
manifests.
C
For
example,
the
iso
defines
something
called
squid
tags,
there's
something
in
ietf
called
coswid,
which
is
just
a
sea
boring
seaboard,
json
encoding
of
the
iso
definition,
which
is
an
xml
encoding.
C
B
Question,
let
me
put
some
context
to
that,
because
what
the
manifest
is
a
generic
word.
So
what
I'm
talking
about
here
when
I
say
manifest,
is
how
do
you
persist?
Something
in
a
registry
and
registries
have
a
well-known
format
for
how
they
interact
with
things.
So
this
is
not
meant
to
be
an
s-bomb
art,
manifest.
It
isn't
meant
to
be
an
image
manifest
or
anything
else.
It's
just.
How
does
this?
How
does
this
infrastructure
that
we've
all
implemented
the
distribution
spec
know
how
to
persist
things?
B
B
So
this
is
the
pr
for
the
new
manifest
that
we've
been
working
on
and
what
it
does
is
it.
Where
do
I
have
it?
I
wasn't
prepared
to
talk
about
this.
That's
fine!
So
an
oci
mata,
no
oci
image
manifest
has
blobs
and
which
is
the
config.
Object
is
stored
as
a
blob
and
the
layers
are
stored
as
blobs,
and
then
the
manifest
is
the
other
objects.
There's
really
two
object
types
that
are
stored
in
a
registry.
B
B
So
what
we're
saying
is
in
yeah
this
is
the
one
there's
an
a
third
manifest.
There's
two
manifests
that
registry
support
today
a
standard
oci
image
manifesto,
which
is
what
you
do
for
a
single
docker
image.
If
you
have
what's
called
a
multi-arc
image
where
it
might
be
windows
and
linux
or
arm
or
whatever
you
can
actually
say,
you
know:
docker
pull
hello
world
and
the
client,
the
wherever
the
host
is,
will
figure
out.
What
am
I.
B
Am
I
linux
and
my
arm
hey
registry,
by
the
way?
This
is
what
I
am
do
you
have
my
version,
so
that's.
The
second
type
of
manifest
registries
know
how
to
persist.
What
we're
adding
is
a
third
manifest.
That's
very
registry,
specific
that
says:
here's
the
the
same
config,
here's
layers,
we've
renamed
them
blobs,
because
layers
is
specific
to
the
way
image
layers
work.
So
everybody
wanted
to
rename
it
blobs
anyway.
B
So
this
is
just
a
rename
of
what's
already
there,
but
this
is
the
new
element
that
says
this
signature
points
to
the
net
monitor
image.
So
that's
that's
kind
of
the
level
of
detail.
When
I
talk
about
manifest
here,
how
somebody
wants
to
persist
in
s-bomb
how
somebody
wants
to
persist
a
turn
or
anything
else
of
that
matter.
That's
just
content
that
gets
stored
in
the
blob.
C
Yeah,
it
looks
like
it's
sort
of
sort
of
pieces
of
the
solution
where
this
manifest
structure
has
a
digest,
but
the
signature
isn't
defined
in
this
structure
directly
correct
yeah.
B
What
we're
doing
here
with
this
oci
artifact
manifest,
is
we're
enhancing
the
way
registries
can
store
stuff
right.
We
don't
we
don't
work
with
the
file
system
to
know
how
to
store.
You
know:
powerpoint
documents,
the
power,
the
office
and
powerpoint
team,
look
to
the
file
system
team
and
say
hey:
how
do
I
store
stuff
in
it?
By
the
way
I've
got
a
new
extension
who
cares
go
for
it?
This
is
enhancing
the
way
registries
can
store
stuff.
It
just
happens
to
be
this
reference
stuff,
such
as
a
signature
or
an
s-bomb.
B
C
C
B
How
do
you
differentiate
whether
you
pulled
some
content
from
a
git
repo,
a
file
share,
a
blob
storage
or
a
registry?
This
is
really
just
yet
another
storage
solution
that
has
a
way
to
sign
the
content.
So,
as
the
content
goes
into
that
storage
solution,
the
registry
and
as
it
gets
moved
across
registries,
I
can
say
that
that
content
that
went
into
this
registry
is
coming
out
and
going
to
others
is
the
same
content.
That's
the
boundary
by
which
we're
trying
to
manage.
C
And
I
guess
the
the
way
to
make
that
statement
believable
by
a
third
party
is,
you
know,
providing
enough
context
for
them
to
essentially
prove
to
themselves
that
that
the
statement
that
you
just
made
is
true.
B
Yeah
yeah
like
this
is
one
of
the
things
that
we've
said
that
the
key
will
not
be
in.
We
don't
believe
that
registry
is
going
to
store
the
public
keys.
Even
the
public
certainly
won't
store
the
private
keys,
but
the
word
we
haven't
figured
out
what
we're
going
to
do
about
public
key
discovery,
because
we're
not
going
to
do
a
trust
in
first
use
model
but
you'll
have
at
least
some
element
of
I'll
call
it
two-factor
auth.
What
do
you
want
to
call
it?
B
You
know
two
elements
that
have
to
be
trusted
together,
so
you
can't
just
hack
the
registry
and
hack
the
public
key.
You
would
have
to
kind
of
hack,
multiple
things
to
get
that
to
get
access.
D
It
sounds
like
it's
a
way
to
verify
that
information
is
what
you
think
it
is
whether
you
decide
to
then
bring
it
into
the
tcb
is
a
separate
question.
You
might
ask
that
question.
First,
I
had
a
separate
question
about
interactions
with
some
other
things
you
mentioned.
You
know
you
obviously
demoed
with
docker.
Have
you
given
any
thought
to
supporting
rocket.
B
So
the
the
way
we're
thinking
about
it
is
a
registry
is
just
storage.
The
registry
is
just
a
another
cloud
file
system,
a
very
specialized
highly.
You
know.
We've
all
had
to
harden
these.
You
know
registry
support
massive
scale
and
requirements.
What
you
stick
in
it,
don't
care
how
you
build
an
image,
don't
care
the
I
and
that's
why
I've
mentioned
is
that
we
want
to
make
sure
that
the
notary,
v2
libraries
are
available,
whether
it's
in
the
right
language
or
not,
we'll
see
but
there'll,
be
a
spec.
B
We'll
have
some
libraries
for
some.
You
know
core
languages
that
we
think
will
need
mass
adoption
and
then
the
idea
is
you
go
build
it
into
your
thing
that
you
want
whatever
you
want
to
store
in
the
registry.
Here's
the
way
that
you
can
do
it
party
on
where
we
want
to
really
enable
those
and
not
get
into
the
details
of
it.
B
And
we're
hoping
you
know
when
I
mentioned:
are
we
not
only
just
trying
to
get
this
working
with
opa
the?
If
we
can
get
it
working
with
opa,
then
that's
the
next
part
of
the
validation,
the
next
the
next
part
of
it
will
obviously
be
okay.
Let's
go
get
this
in
container
d.
Let's
go
get
this
in.
You
know
the
docker
client
into
build
x
and
all
of
these
build
and
all
the
other
different
things
into
helm
into
node.
Sorry
into
you
know,
singularity
or
whoever
wants
to
put
stuff.
B
The
way
I
think
about
this
is
if
you're,
if
you're,
building
a
large
scale
project,
because
there's
a
couple
different
business
models
right,
if
you're
doing
customer
intimate,
then
you
know
all
your
customers
and
they
know
you
by
name
you
take
them
out
to
lunch
whatever
in
any
kind
of
scalable
solution,
you
can't
possibly
know
all
your
customers,
so
this
definition
of
successes-
I
can't
I
don't
know
them
all.
I
might
know
a
few.
I
don't
know
them
all.
B
B
At
the
same
time,
we're
not
trying
to
boil
the
ocean
right
like
we're,
we're
not
trying
to
replace
every
last
solution.
That's
out
there
for
persistence,
we're
just
trying
to
say
there's
any
new
artifact,
it's
kind
of
hard
there's
a
separate
talk.
I
make
around
the
oci
artifacts
approaches
you
know
do
I
need
yet
another
storage
solution.
Why
not
just
use
this?
So
that's
that's
kind
of
a
different
conversation.
A
You
had
the
whole
meeting.
Basically,
I
don't
think
there's
anything
else
on
the
agenda.
So,
okay,
any
no.
Nothing
else
got.
F
Oh
okay,
yeah,
it's
something!
We've
talked
about
a
bunch
in
in
the
group.
It's
sort
of
a
generalization
of
the
certificate,
transparency
stuff
that
exists
for
web
pki.
Where
effectively
for
a
browser
to
trust
an
issued
certificate.
You
need
to
staple
a
signed
assertion
from
these
third-party
transparency
authorities.
Basically,
and
their
job
is
to
maintain
a
record
of
every
certificate
that
was
ever
issued.
So
it's
addressing
a
detection,
it's
a
detection
mechanism,
so
suppose
a
sign,
a
code,
signing
key
were
compromised.
F
The
owner
of
that
key
could
monitor
this
transparency
list
potentially
to
detect
any
malicious
signatures.
So
this.
B
Is
an
example:
I'm
standing
on
the
shoulders
of
other
giants,
the
maybe
I'm
the
general
contractor
and
there's
a
bunch
of
our
key
management
experts,
and
it's
it
sounds
like
this
is
part
of
our
key
management.
You
know
in
example,
areas.
So
I
definitely
encourage
you
to
you
know,
help
and
contribute
I'll
bring
it
up,
but
the
idea
is
that
I
I
would
have
to
defer
to
them
to
answer
your
question.
B
And
you
know
to
that
sense:
I'd
we'd,
love,
more
engagement,
whether
you
can
attend
the
meetings
on
mondays,
we
record
them
all
they're
posted
up
on
youtube.
You
can
there's
a
hack
doc
you
can
get
to
on
those
there's
issues
that
we're
tracking.
I
mean
it's
a
standard
open
source
project,
so
we
really
we're
trying
to
make
sure
we're
addressing
all
of
the
needs
that
people
have
while
maintaining
our
scope.
B
So
we
can
actually
ship
this
thing,
but
what
you
described
sounds
very
much
of
what
you
know
how
somebody
would
just
manage
the
keys
and
so
forth.
We're
not
trying
to
reinvent
a
new
key
management
system,
we're
trying
to
leverage
the
existing
ones.
E
Hey
steve,
quick
question
about
the
the
manifest
format,
so
is
that
something
like
are
you?
Is
there
an
existing
format
that
you're
just
extending
okay?
All
right,
because
I
was
I
was
thinking
that
there's
you
know
we
could
just
think
of
that
as
another
type
of
software
bill
of
materials,
but
you,
but
that's
what
you're
saying
yeah
and
the
anyway,
because
the
software
bill
of
materials
is
building
also
this
concept
of
links
to
external
components,
but
but.
B
B
Like
this
is
in
this
group,
it's
probably
way
too
much
detail
to
even
talk
about
it's
in
the
group
of
people
that
are
running
registries
and
building
artifact
types
like
tools
that
would
interact
with
the
registry.
It's
really
important
to
them,
outside
of
that,
it
is
not
usable
for
things
outside
of
that
like
it
is
a
very
tailored
thing
for
how
you
persist
things
into
a
registry
unless
you're
authoring
artifacts,
including
the
s-bomb,
to
be
fair,
and
it's
not
the
s-bomb
format
itself.
B
It's
when
you
want
to
save
whatever
you
guys
just
find
is
your
schema
and
as
long
as
you
can
persist
it
as
some
files
or
blobs,
then,
when
you
want
to
tell
the
registry
to
save
it,
there's
some
internal
gu.
That
says
by
the
way.
This
is
how
you
tell
me
tell
the
registry
how
to
store
it.
It's
not
meant
for
anything
outside
of
that.
C
Since
you,
you
know,
you
have
an
internal,
essentially
have
an
internal
format
with
a
digest
that
matches
when
you,
when
you
export
out
of
the
registry
into
cns,
nsbom
or
a
switag,
if
you,
if
you
could
reuse
those
digest,
computations
some
way,
that
would
maybe
be
a
more
efficient
way
of
doing
things
in
the
kind
of
in
the
big
picture.
B
B
It's
got
a
separate
thing,
then
there's
this
part
where
it
goes
on
to
the
truck
and
it
goes
through
registries
and
it
gets
to
the
other
end
and
it's
going
to
leave
the
registry
and
have
a
life
outside
of
it.
We
want
to
make
sure
that
you
can
put
the
thing
that
you're
verifying
independent
of
that
in
the
registry
as
well,
we're
just
putting
a
separate
secondary
stamp
that,
while
it's
going
through
the
registry
and
across
registries,
there's
a
seal
on
it.
That
says
this
is
verifiable.
B
So
I
that
and
that's
some
of
the
stuff
that
in
the
s-bomb
working
group
that
kate's
been
working
on,
is
I've
been
trying
to
keep
an
eye
on.
How
does
that
hand-off
happen,
because
I,
what
you're
kind
of
getting
at
is
at
least
what
I'm
hearing
and
trying
to
make
sure
I'm
accounting
for
it
is
you're
going
to
create
s-bombs
and
you're
going
to
sign
those
completely
independent
of
registries
right.
You
want
to
make
sure
that
when
I
look
at
this
s-bond,
it's
it's
true.
It's
it's!
B
You
know
it's
accurate
and
I
can
trust
it
that
hap
that
needs
to
be
done
before
it
even
goes
into
a
registry.
It
just
so
happens
to
be
able
to
ship
that
s
bomb.
From
point
a
to
point
b,
we
want
to
make
sure
that
the
the
the
seal
on
the
package
doesn't
get
broken.
So
that's
an
extra
signature
on
it.
If
you
want
to
use
that
signature
as
part
of
it
and
that's
good
enough,
that's
great
too,
because
the
to
your
point
the
manifest
is
a
way
to
kind
of
compute
that.
B
C
B
C
So
so
the
sort
of
brief
tutorial
really
brief
tutorial
on
swift
tags.
They
they
essentially
use
the
model
where
they
represent
a
file
system
in
their
schema.
So
you
can
essentially
compute
a
digest
based
on
a
pointer
into
a
file
system
as
sort
of
identifying
the
thing
that
you're
digesting
and
that
works
great.
C
If
you
have
a
you
know
typical,
you
know
linux
file,
system
structure,
but
I
don't
think
it
works
for
registries,
but
it
would
be
an
interesting
exercise
to
walk
through
that
to
see
if
there
was
a
way
to
do
that,
and
then
then
you'd
have
a
sort
of
an
external
representation
of
an
industry
standard
schema
for
software
that
can
point
into
a
registry
and
if
it
makes
sense
there
could
be
some
performance,
optimization
accommodation
for
the
digest.
That's
already
there
to
just
copy
it
instead
of
re-compute
it.
B
That's
a
good
question.
The
thing
that
I've
been
also
wrestling
a
little
bit
with
is
we're
seeing
registries
store,
there's
different
optimizations
in
how
you
compress
and
store
stuff.
In
a
registry
like
today,
we
use
targeez.
For
the
most
part,
the
oc
artifact
approach
says
don't
care,
but
if
you
look
at
some
of
the
stuff
we're
doing
with
our
project
teleport
in
azure,
we
decompress
the
layers.
B
The
signature
is
based
on
the
compression
format,
so
we
were
looking
at
in
other
ways
of
how
could
you
sign
the
content
as
it's
expanded,
because
the
the
kind
of
like
when
I
bring
the
when
I
start
with
the
content
outside
I
put
in
the
registry?
I
get
it
out
on
the
other
side
in
container
d
and
others,
the
layers
are
expanded.
B
How
do
I
know
that
that
expanded
layer
didn't
get
messed
with
so
there's
some
interesting
things
there
that
we're
trying
to
figure
out
is
how
to
how
does
that
get
accounted
for
as
well,
especially
if
registries
are
going
to
be
storing
multiple
compression
formats.
There's
some
talk
about
star,
gz
and
and
various
other
format,
types
that
you
know
might
be
project
performance,
specific
that
we're
trying
to
figure
things
figure
out.
B
How
did
we
store
that
so
the
the
right
now
there
is
a
standard
that
an
artifact
is
compressed
and
put
in
a
registry
and
we're
trying
to
make
sure
that's
at
least
covered
and
then,
as
these
expand
additional
scenarios
come
up.
We'll
try
to
figure
that
out
as
well.
E
A
Oh
well
thanks
steve
and
you
you
sent
the
link
to
these
right.
Let
me
find
it
make
sure
I
can
get
them
into
the
agenda
if
possible.
A
A
B
Well,
thank
you
really
great
thanks
for
the
opportunity
you
know
been
trying
to
keep
up
with
all
the
stuff
you
guys
are
doing
here.
It's
it's
there's
a
lot
of
moving
pieces.
So
if
you
see
something
you
need,
you
don't
see
covered
or
think
we
need
to
adjust
or
the
problems
like
as
the
as
a
somebody
working
on
it.