►
From YouTube: CNCF Notary Project 2020-07-31
Description
CNCF Notary Project 2020-07-31
B
D
Yeah,
I'm
really
glad
it's
cool
today
kind
of
raining,
because
my
ac
is
busted.
A
D
Well,
I
mean
just
just
make
sure
the
the
life
of
luxury
includes
two
two
aircons
redundancy.
You
will
be
fine.
B
B
B
So
I
added
two
items
to
the
agenda.
I
looked
through
a
lot
of
the
comments
on
the
pull
requests.
I
unfortunately
didn't
have
enough
time
this
past
week
to
add
in
the
the
deployment
admin
the
deployment
user
rule
as
well
as
the
diagrams
which
we
talked
about
last
week,
I'll
take
a
crack
at
adding
that
in
this
weekend,
but
I
think
there
is
enough
conversation
in
the
comments
or
there
are
two
key
items.
I
think
that
are
worth
discussing.
B
The
first
one,
I
think,
is
on
the
having
the
multiple
root
keys
and
the
second
one
is
just
looking
at
cue,
revocation
larger
in
general.
I
think
we
can
start
off
with
multiple
root
keys
shashank.
I
think
you
and
marina
both
went
back
and
forth
on
that,
and
I
think
miloslav
also
had
some
comments
and
but
he's
not
here
today,
but
we
can
kind
of
discuss
some
of
those.
B
So
I
think,
from
my
perspective,
I
kind
of
share
some
of
miloslav's
concerns
in
that,
even
if
we
have
multiple
keys
as
a
requirement
for
the
root
key.
Typically,
what
we're
seeing
is
that
those
keys
are
all
being
stored
in
a
similar
fashion,
so
a
compromise
of
multiple
keys
is
just
as
likely
as
a
compromise
as
a
single
key.
B
So
what
we
were
kind
of
moving
more
towards
was
something
similar
to
a
two-factor
authentication.
If
you
will
well
there
where
there
is
a
separate
route
to
kind
of
like
share
what
your
trusted
keys
are,
which
is
what
we're
envisioning
notary
v2
would
look
a
little
bit
more
like,
but
I
think
this
this
this
one
we
can.
We
can
kind
of
like
look
at
the
pros
and
cons
of
each
approach
and
decide
pretty
quickly
on
sort
of
like
you
know
what
approach
you
want
to
move
forward
with.
D
Oh
yeah,
I
totally
agree
I
mean
so
so
I
think
there's
two
separate
issues
here.
Right
that
we
should
we
should
take
some
pain
to
try
to
distinguish.
One
is
that
I,
I
think
it
was
wrong
to
lead
with
multiple
root
keys
that
neces.
That's
not
that's
a
good
idea
to
multiple
keys,
but
I
I
don't
think
that's
what
we're
trying
to
emphasize
here
what's
more
important.
Is
that
even
if
you're
one
rookie,
that's
fine,
that's
what
you
want
to
do.
You
should
have
a
way
to
rotate
the
keys.
C
Yeah,
I
think
that
before
we
go
too
much
further,
I
think
that
I
had
a
question
actually
about
the
what
we're
talking
about
when
we
talk
about
root
keys,
because
now
going
through
the
document,
it
seems
like
there's
like
a
lot
of
different
root
keys
in
the
system,
and
I
think
that
if
we
can
kind
of
clarify
you
know
who
needs
to
make
these
boot
keys
and
what
they're
doing
with
them,
then
I
think
it
might
be
easier
to
figure
out
what
kind
of
management
is
reasonable.
B
Yeah,
I
think
we
can
clarify
some
of
that.
So
essentially
the
way
I
was
envisioning
the
root
key
as
working
is
the
same
way
that
we
have
the
root
key
currently
working
in
notary,
the
first
implementation,
in
which
case
it
would
essentially
tie
into
being
like-
and
I
like,
the
the
root
of
like
what
what's
this
used
to
establish
someone's
identity
right.
So
each
developer,
that's
trying
to
identify
themselves
as
a
developer
or
each
entity
like
you
know,
could
set
up
their
own
root
key
and
then
all
the
time
stamps.
B
If
we
decide
to
use
snapshot
keys,
like
you
know,
delegate
keys.
These
would
all
change
from
that
single
root
key.
So
the.
B
Would
be
analogous
to
what
we're
currently
using
in
nodrique,
but
this
would
essentially
be
the
root
of
trust
that
chains
into
like
a
single
identity,
that
you're
saying
that
I
trust
this
identity.
C
Okay,
that
makes
sense,
but
I
think
so.
I
think
that
that
was
part
of
my
confusion
actually
was
that
I
kind
of
was
envisioning
a
system
where,
like
there's
a
single
group,
key
that
then
delegates
to
these
developers
and
other
users
of
the
system,
and
so
I
think
that
you
know
because
there's
less
of
them,
I
think
that
more
management
is
reasonable.
But
if
there's
going
to
be
one
for
each
developer,
then
yeah.
I
totally
agree
that
the
multiple
offline
keys
will
probably
be
harder
in
that
case.
C
B
Yeah
we
want
to
make
a
distinction
there
between.
I,
I
misspoke
and
I
don't
want
to
kind
of
have
that
great
confusion
as
well,
so
I
use
developers
pretty
loosely,
so
I'm
considering
kind
of
like
use
cases
where
you
have
individual
developers
like
pushing
sort
of
like
containers
and
that
want
to
be
identified
versus
sort
of,
like
maybe
large
enterprises
that
have
multiple
developers.
B
I
would
envision
an
enterprise
having
either
a
single
group,
key
per
sort
of
like
organization
or
potentially
sort
of
like
multiple
root
keys
per
sort
of,
like
smaller
teams
that
they
want
to
have
individual
routines
for
right.
So
taking
sort
of,
like
you
know,
a
a
large
sort
of
like
company,
they
may
have
like
one
sort
of
like
route
for
their
windows
business,
one
sort
of
route
for
their
linux
sort
of
like
containers.
B
So
I
think
what
we
want
to
tie
the
route
to
is
sort
of
like
an
identity
that
someone
else
wants
to
verify
whether
that's
an
individual
developer,
whether
that's
sort
of
like
a
legal
entity.
I
think
we'd,
let
sort
of
like
the
the
designing
admins
decide
how
they
want,
how
many
routes
they
want
to
use
and
what
those
routes
would
tie
into.
C
Okay,
I
think
my
concern
there
is
like
would
be
like
how
do
you
figure
out
which
of
these
root
keys
to
trust,
because
if
there's
no,
like
centralized
group
that
you
know,
clients
start
with
that,
they
can
find
these
other
keys
from.
I
just
don't
know
how
they
would
figure
out.
You
know
which
of
these
developer
routes
to
use.
So
there's
a
lot
of
background
noise.
B
Right-
and
I
think
this
is
where
the
key
sharing
service,
if
you
will,
which
is
what
I
think
notary
can
morph
into
comes
in,
is
sort
of
like
a
a
service.
That's
telling
you
that
could
either
be
stood
up
by
the
individual
organizations.
It
can
be
something
that's
a
bit
of
a
shared
service
as
well.
If
you
will
have
like
trusted
providers
where
you
can
kind
of
go
in
and
check
what
the
root
key
for
sort
of
an
identity
is.
B
This
is
kind
of
similar
to
sort
of
like
where
companies
are
sort
of,
like
you
know,
putting
on
their
websites
what
their
public
keys
are,
and
so
I
think
that's
that's
where
we
look
for
sort
of
like
an
out-of-band
key
sharing
service
that
isn't
necessarily
tied
into
how
containers
are
signed
and
propagated.
It
would
be
a
second
service.
That's
managing
that
that
that
key
sharing
mechanism.
E
D
Oh
thanks
thanks.
I
was
just
going
to
say
I'm
kind
of
curious
about
the
design
of
this,
this
external
key
service,
because
we
know
from
experience
that,
if
you,
if
you
don't
you,
don't
want
to
tightly
couple
everything
of
course,
but
when
it
comes
to
designing
secure
systems,
if
you
don't
carefully
integrate
them,
you
might
run
into
unexpected
security
issues,
but
but
we
can
discuss
that
separately.
B
Yeah,
I
think
that's
one
of
the
things
we
definitely
want
to
dive
into
once
we
get
into
the
detailed
design
at
a
high
level,
what
the
sort
of
like
the
deployment
administrator.
If
you
will,
they
have
two
options
right
right
now
they
can
manually
sort
of
like
write
in
the
public
keys
that
they
trust.
So
whether
this
is
like
hey,
I
have
like
an
internal
private
repo
set
up.
I
know
what
keys
I'm
using
there
or
sort
of
like
you
know.
B
I
trust
these
large
companies,
here's
the
private
keys
that
they
published
on
their
website.
These
are
the
keys
I
want
to.
I
want
to
add
into
my
repository
that's
one
route
and
then
the
other
one
is
that
if
there
is
an
automated
service
that
can
get
that
information
for
you,
then
that's
where
the
key
ma
the
key
sharing
service
comes
in.
That
you're,
able
to
kind
of
like
say
here
are
the
key
sharing
services
that
I
trust
for
these
entities.
You
know
automatically
get
the
keys
from
there.
B
I
think
we
would
want
to
kind
of
dive
into
sort
of
like
what
the
auth
mechanism
there
looks
like
what
are
sort
of
like
potential
threat
models
that
we
need
to
kind
of
address
there
there's
always
kind
of
like
concerns
around
sort
of
like
you
know
what
happens
if
a
key
sharing
service
gets
compromised,
what
are
sort
of
like
their
mediation
steps?
Those
are
things
we
need
to
address
in
sort
of
like
the
design
and
threat
model,
but
at
a
high
level.
B
I
think
what
this
addresses
is
that,
in
the
event
of
a
key
compromise,
you're
not
necessarily
kind
of
like
at
risk,
because
you'd
also
need
the
key
sharing
service
to
be
compromised
and
you'd
also
need
the
registry
to
also
have
like
your
upload
credentials
to
be
compromised.
So
there's
three
different
things.
I
think
that
you
need
to
compromise
at
this
point.
In
addition
to
just
a
key
compromise
happening.
G
B
Yeah,
I
think
this
would
be
a
very
lightweight
service.
It
definitely
wouldn't
be
as
heavyweight
as
the
current
notary
implementation
is.
I
think
here
the
goal
would
be:
can
we
focus
on
what
the
how
we
establish
the
office
to
connect
to
that
service
and
what
are
sort
of
like
some
remediation
steps
if
that
service
were
compromised?
I
think
those
are
the
two
things
that
go
into
consideration
for
that
service.
Yeah.
G
So
so
what
I
was
thinking
about
is,
if,
if
you
let's
say
you
have
your
own
notary
server
and
you
want
to
configure
which
routes
are
trusted,
you
can
just
configure
one
or
many
urls
where
routes
can
be
retrieved
from
with
some
appropriate
authentication
mechanism
in
between
that
at
least
prevents
people
from
having
to
check
if
roots
have
been
replaced
or
changed,
or
things
like
that.
A
B
Yeah,
that's
kind
of
in
line
with
what
I
was
thinking
steve
did
you
wanna?
Did
you
have
a
comment
there.
E
Yeah
I
mean
so
I'm
coming
at
it
from
a
usability
perspective
and
asking
the
security
experts
here.
What
the
implications
of
it
are,
because
we
certainly
want
to
make
sure
that
people
can
find
keys.
You
know
and
treat
and
achieve
acquire
them
in
a
reasonable
fashion
is
since
they're
going
to
a
particular
registry
to
get
the
content.
E
Is
it
considered
unsafe
to
have
a
discovery
or
even
an
acquisition
model
that
happens
through
the
registry
apis,
even
though
it's
delegated
to
another
underlying
service?
I
I'm
trying
to
figure.
I
guess
I'm
trying
to
figure
out.
How
does
the
where
the
keys
are
stored
and
secured
and,
of
course
uploaded
is
a
completely
different
thing
than
retrieving
them?
E
B
I
I
I
was
kind
of
striving
more
for
was
decoupling
the
registry
from
that
process,
in
the
sense
that
you
know,
registries
can
tell
you
where
to
go,
buying
keys.
They
can
also
potentially
redirect
you
to
to
other
locations
as
well
right.
So
what
guarantees
you
have
the
url
you're
going
to
is
the
url
you
wanted
to
go
to
right.
B
So
in
that
regards,
I
think,
that's
kind
of
where
I
think
like
if
you're
going
to
say.
I
trust
this
publisher.
You
should
know
who
that
publisher
is
and
why
you're
trusting
them.
That
was
kind
of
like
one
of
the
actions
I'm
starting
off
with.
E
E
B
Even
for
retrieval
keys,
let's
take
this
scenario
right,
like
you
have
company
a
that
has
their
key
set
up
and
you.
B
B,
that's
taking
in
sort
of
like
you
know,
containers
from
company
a
and
running
them
now,
if
they're
going
through
a
registry
right
and
if
the
registry
it
decides
to
kind
of
like
has
has-
has
a
mechanism
to
kind
of
like
point
to
a
url
that
has
a
key-
that's
not
used
by
company
a
but
says
this
is
used
by
company
a
then
company
b
can
potentially,
you
know,
use
a
key
that
doesn't
belong
to
company
a
to
verify,
container
images
right
and
so
the
the
the
way
that
company
b
is
defining
that
we
trust
company
a
they
need
something
from
company
a
to
kind
of
say.
B
This
is
what
we're
going
to
use
to
trust
your
your
images
with
right
like
unless
it
comes
from
company
a,
I
think,
if
you're
getting
it
from
any
other
source,
there's
always
a
question
of
how
do
we
know
this
comes
from
there.
One
route
to
do
this
is
using
sort
of
like
public
cas,
which
I
think
is
something
this
model
can
extend
into
where,
if
you
have
sort
of
like
trusted
entities
like
if
you
have
like
a
public
ca
that
you
trust
and
they're
telling
you
this
is
something
that
belongs
to
company.
E
Yeah
the
this
is
where,
like
having
those
requirements
listed,
you
know
kind
of
help,
scopes
on
this
or
help
figure
out.
How
do
we
answer
the
question?
I
guess
is
a
better
way
to
say
it.
So
if
company
b
is
well
so
what
we
consider
continually
see
is
customers
want
to
be
able
to
lock
down
their
registries
to
certain
data
endpoints
and
they
can't
be
sent
to
other
ones.
We
see
this
with
the
windows
foreign
layers.
E
We
see
this
with
when
registries
had
two
different
data,
urls
the-
but
I
guess
the
key
and
air
gapped
environments
where
I
can't
go
to
that
vendor.
But
I
guess
the
acquisition
of
the
key
in
those
kind
of
environments
could
be
done
out
of
band,
because
the
assumption
is
locked
down
that
type.
They
probably
don't
want.
I
don't.
E
E
Because
is
it
really
that
I
can
create
another
key
that
looks
the
same
or
I'm
creating
content
new
content
that
looks
like
it's
signed
by
mike
microsoft,
but
it's
actually
signed
by
microsoft
or
something
like?
Can
you
really
create
a
fake
key,
or
can
you
you're
creating
content
that
looks
like
the
same
content
that
points
to
a
different
key.
B
Well,
so
keys,
don't
have
any
information
associated
with
them
right.
It's
because
I've
gotten
a
key
from
like,
let's
say
microsoft.com,
that
I
know
that
this
key
belongs
to
microsoft
right,
but
by
looking
at
a
key
directly,
there's
really
nothing
there.
That
tells
me
when
I
look
at
a
root
key
specifically,
there's
really
nothing
there.
B
That
tells
me
that
this
key
belongs
to
microsoft,
for
example,
if
we-
and
I
think,
that's
kind
of
where
sort
of
like
using
a
public
ca
becomes
slightly
different
because
in
the
public
ca
scenario,
the
root
key
is
essentially
coming
from
a
public
ca,
and
so
you
trust,
let's
say
digicert
for
example,
or
let's
encrypt,
and
then
that's
the
public
key
you're,
trusting
and
then
you're,
relying
on
let's
encrypt
or
digit,
to
verify
that
any
intermediate
or
any
other
cert
that
they're
issuing
is,
is
actually
being
requested
by
microsoft.
B
But
when
we
go
down
to
sort
of
like
establishing
like
which
routes,
we
trust
you
only
the
only
mechanism
you
have
to
validate
that
this
route
belongs
to.
Someone
is
by
trusting
the
source
you're,
getting
it
from.
G
G
It
might
even
be
that
you
have
those
discovery
services
where
those
keys
are
available,
that
you
have
those
forgiven
departments
within
a
company.
So
so,
when
I
look
at
the
way
phillips
is
currently
organized,
there
is
a
chance
that
certain
departments
or
certain
businesses
want
to
manage
their
own.
G
G
Then,
to
to
to
keep
this
separate
from
the
registry
also
adds
the
advantage
that
yeah
people
can
deploy
this
in
different
networks.
So,
let's
say
if,
if
I'm
publishing
my
keys
in
my
my
own
secured
network
environment
either
within
the
company
or
or
across
companies,
I
I
can
keep
basically
the
service
which
is
able
to
retrieve
them
and
provide
them
to
to
the
registry.
G
I
keep
that
can
keep
that
more
close
to
each
other
and
and
then
it's
more
or
less
like,
like
niaz
was
mentioning
you
just
redirect
the
traffic,
it's
basically
http
traffic,
so
you
can
just
reverse
proxy
those
kind
of
things
so
from
a
flexibility
point
of
view
in
a
deployment.
B
I
think
I
I'd
go
rather
than
having
the
registry
expose
it.
This
could
potentially
also
be
a
part
of
the
signature
where
it
tells
you
what
the
discovery
url
is
that
way,
we're
not
necessarily
relying
on
the
registry
kind
of
maintaining
a
list
and
trusting
the
registry
to
maintain
a
proper
list
right.
I
think,
like
one
of
the
things
I'd
be
concerned
about
is
like,
and
if
a
registry
was
maintaining
the
list
they
could
potentially
like
you
know,
redirect
from
microsoft
to
microsoft.
B
Right
like
have
a
microsoft
url
and
that's
usually
like
you
know
something
that
could
get
easily
missed,
but
if
it's
in
the
signature
then
you've
actually
kind
of
you
are
proving
that,
like
you
know,
you
have
control
of
this
domain
that
you're
pointing
to
and
that
your
key
information
is
going
to
be
there,
and
if
this
isn't
a
discovery
url
you
already
trust
you
can
actually
validate
who
this
url
belongs
to
and
decide.
B
C
I
would
actually
be
really
concerned
about
having
the
discovery
mechanism
in
the
signature
itself,
because,
basically,
it's
kind
of
at
that
point-
it's
self
validating
itself,
because
it's
telling
you
where
to
go
to
verify
itself.
So
I
feel
like
we
want
some
sort
of
kind
of
cryptographic
mechanism
around
the
discovery,
so
that,
like
you,
have
to
verify
a
separate
signature
before
you
can
go
to
this
discovery
mechanism
like
if
there's
some
kind
of
route
on
the
registry
that
could
just
point
to
these
discovery
mechanisms.
C
B
Yeah,
I
think
the
the
discover
your
url
like
if
it's
present
in
signatures,
I
don't
think
it
should
be
used
to
automatically
trust
the
image
you're
absolutely
right.
I
think
that,
like
kind
of
leads
to
sort
of
like
you
automatically
trust
anything,
I
think
there
would
be
some
we.
We
would
want
some
manual
intervention
there,
where
this
is
saying
that,
like
you
know,
this
registry
isn't
trusted,
here's
the
url
go
validate
this
before
you
put
it
into
sort
of
like
your
trust,
config
right,
I
think
that's
the
that's
the
work.
B
That's
that's
the
manual
step
we
kind
of
expect
there
for
someone
to
go
in
this
potentially
could
go
into
something
like
an
error
message
rather
than
kind
of
just
saying,
like
you
know,
you
can
automatically
use
the
client
to
validate
this
based
on
whatever
url.
This
is
sharing
with
you.
D
So
I
have
to
go
soon,
unfortunately,
but
I
wanna,
I
want
to
raise
the
meta
question
and
and
encourage
us
to
think
about
it.
One
is
it's
not
obvious
to
me
so
at
least
I'm
not
aware
fully
aware
of
the
context
not
obvious
to
me.
So
what
is
the
context
here?
Is
it
that
we
trust,
or
is
there
one
registry?
Are
there
multiple
registries,
partly
because
these
private
images
right
so,
is
that
the
reason
for
decentralizing
key
discovery
like
this
like?
D
B
I
think
part
of
it
was
that
we,
when
we
look
at
sort
of
like
you
know
today,
the
model
has
kind
of
been
that
you're
publishing
to
a
single
registry
and
you're
signing
for
that
single
registry,
and
that
registry
is
maintaining
that
signature
information
for
you,
and
so
one
of
the
goals
of
this
was
to
make
it
easy
to
move
containers
from
registry
to
registry
and
potentially
allow
anyone
to
set
up
a
registry
to
host
any
images
they
want
to.
B
I
think
this
leads
to
a
concern
around
sort
of,
like
you
know,
depending
on
who's
setting
up
a
registry
if
they're
also
responsible
for
sort
of
like
maintaining
some
of
the
trust
information.
You
know
if
this.
B
If,
if
anyone
is
setting
up
a
registry,
can
we
at
that
point
trust
registry
owners
to
maintain
this
trust
mechanism
as
well,
so
relying
on
a
registry
in
that
scenario,
to
me
kind
of
like
breaks,
the
trust
model-
and
I
think
that's
part
of
been
sort
of
like
have
been
looking
at
a
very
high
level-
is:
can
we
decouple
sort
of
like
sharing
of
containers
versus
like
trusting
who
actually
wrote
the
container.
D
A
I'm
also
gonna
have
to
drop
off
in
a
moment,
so
I
wanted
to
remove
a
kind
of
I
think
related
issue.
So
if
you're
going
and
you're
having
a
system
where
you
go-
and
you
have
these
urls
that
you
then
go
to
and
you
rely
on
the
ca
system
to
provide,
you
trust
that
the
thing
you're
going
to
that
url
is
correct.
A
A
So
I
I
don't
really
understand
yet
like
why
the
why
this
way
of
doing
indirection
is
a
is
a
better
way.
I
understand,
if
you're,
just
assuming
that.
A
Like
you
know,
we
don't
want
to
look
deep
into
those
mechanisms,
we're
just
going
to
try
to
use
them
as
tools.
I
can
see
why
this
is
something
that
would
be
thought
of,
but
I
don't
know
if,
if
you
peel
back
the
mechanism
and
think
about
it,
a
little
bit
that
you're
getting
anything
better
by
putting
urls
there
than
you
would
be,
but
just
putting
the
keys.
B
So
I
think
the
what
we're
looking
at
is,
you
can
put
both
right.
You
can
put
you,
can
both
put
keys
and
urls,
so
it's
what
you
can
put
one
or
the
other.
So
if
for
especially
for
air
gap
environments,
I
think
that's
where,
like
you
know,
you
want
to
put
in
keys
rather
than
urls
and
have
an
administrator
do
there.
B
The
urls
is
really
more
of
like
saying
that
hey
if
I
want
to
be
able
to
automatically
get
like
you
know,
if,
when
keys
are
being
rotated
or
updated
or
they're
being
revoked
like
I
want
that
information,
a
url
gives
you
some
degree
of
automation
in
pulling
that
information
in
it's
one
where
I
think,
like
you
know,
if
you're
without
that,
without
that
url
then,
like
you,
know,
you're,
essentially
relying
on
sort
of
like
getting
an
update
from
company
a
and
knowing
that,
like
you
know,
their
keys
have
been
compromised
and
revoked,
and
you
need
to
kind
of
have
like
some
kind
of
manual.
B
G
So
from
from
a
management
perspective,
I
can
manage
those
keys
in
one
place
instead
of
different
locations
in
the
system.
I
I
think
you
can
still
use
it
as
a
proxy
as
well.
B
Yeah,
I
think,
having
both
gives
sort
of,
like
you
know,
deployment
administrators
choices
and
how
they
want
to
do
how
they
want
to
implement
that.
I
don't
think
they're
necessarily
like
mutually
exclusive
right.
G
So
I
I
also
have
another
question
so
in
this
multi-registry
world,
I
think
the
root
keys
have
to
be
known
by
registries,
because
when
I
derive
from
a
image
from
registry
a-
and
I
push
the
new
layer
on
my
registry,
of
course,
I
might
want
to
check
some
validity
on
the
other
layers.
G
Is
that
a
correct
understanding
from
my
side,
because
that
that
means
you,
you
would
need
to
manage
those
routes
on
registries
as
well
on
clients
consuming
those
images.
B
Right
so
I've
added
that
in
as
a
requirement
for
registries
to
have
so
every
time
you're
generating
a
new
root
key
one
of
the
steps
you're
taking
is
uploading
it
to
the
registries
where
you're
distributing
containers
to
that
ties
it
in
with
sort
of
like
your
identity,
and
so
it
is
one
word
that
you
can
continue
publishing
images
there
so
for
for
uploads
there.
You
would
need
to
do
that,
but
that
that
is
something
that
the
registry
would
would
validate
for
subsequent
uploads.
G
E
I
like
that,
a
little
bit
is
just
where
you,
where
you
get
what
registries
you
connect
to
and
pull
the
content
shouldn't
really
be
tied
to
the
the
key
of
their
certificate.
In
other
words,
I'd
pull
the
debian
image
that
originally
is
built
by
the
debian
corp,
let's
just
say,
and
it
gets
pushed
up
to
docker
hub
and
then
I'd
move
it
into
my
registry
and
then
I
move
into
another
registry
in
the
air
gapped
environment.
It's
going
to
keep
on
moving.
In
that
case,
maybe
deputy
is
not
the
best
image.
E
B
I
think
the
the
the
thing
here
is
that,
are
you
also
validating
images
as
they're
being
uploaded
to
the
registries
right
and
what
is
that
mechanism
there?
So
let's
say
that,
like
you
know,
you're
you're
getting
an
image
from
webbit
networks,
you've
gotten
the
root
key
from
webbit,
and
you
know
what
the
root
key
is,
and
you
can
verify
any
images.
I
think
the
question
here
is
more
that
you
know.
If
I
am
uploading
to
a
registry.
B
Let's
say
you
know
wabid
and
I
will
do
a
registry
a
or
docker
hub,
then
docker
hub
can
also
potentially
validate
that
this
came
from
wabit
and
kind
of
like
have
managed
sort
of
like
a
set
of
root
keys,
and
I
think
they're
actually
having
the
same
verification
mechanism
that
that
the
client
has
just
adds
two
layers
of
validation
right.
It's
more
defense
and
depth.
B
It
kind
of
ensures
that
registries
themselves
are
validating,
whether
sort
of
like
anything,
that's
uploaded
or
sort
of
re-uploaded
over
that
it
came
from
a
legitimate
source
and
and
meets
the
sort
of
like
you
know
like
there
wasn't
any
tampering
or
any
issues
with
that.
I
think
it's.
It's
it's
one,
I'm
tracking
like
we.
G
G
B
B
The
other
mechanism
would
be
that
in
in.
If
we
have
a
key
sharing
service,
you
can
potentially
configure
sort
of
like
what
keys
you're,
putting
in
that
key
sharing
service
and
using
that
as
a
proxy
as
well.
So
I
think
that's
kind
of
where
I
envisioned
notary
v2
kind
of
like
the
notary
server
kind
of
like
being
revised
to
is
being
sort
of
like
more
like
a
repository
of
trusted
group
keys
and-
and
that's
that's
why.
B
I
think
something
that
we
can
look
into
sort
of
like
the
additional
component,
but
at
least
for
now,
like
the
url,
I
think
would
at
least
give
you
that
that
information.
C
Yeah
I
have
on
that
kind
of
a
similar
note.
I
think
that
key
revocation
is
also
a
time
when
you
need
to
kind
of,
like
immediately
update
the
keys
that
you
trust,
I
just
kind
of
wonder
how
that
could
be
handled
or
like,
and
also,
similarly,
a
compromise
of
whatever
urls
or
servers
that
are
hosting
these
public
keys.
So
how
are
those
all
protected
kind
of.
B
Yeah,
I
think
this
is
one
where
we'll
we'll
need
to
do
sort
of
like
a
detailed
thread
model
next,
in
terms
of
what
are
the
potential
ways
these
could
be
compromised
and
we'll
need
to
kind
of
break
those
down
into
like
what
are
things
we're
addressing
in
the
design
to
address
that?
But
the
the
thing
here
would
be
that
you
know
if,
if
the,
if
the
url
itself
is
compromised,
then
you
know
it
does
it.
B
It
does
lead
to
the
fact
that,
like
you
know,
if
someone
else
puts
in
you
or
urls
or
something
then
you
would
be.
That
is
something
that
you
know
you'd
be
you'd
have
to
kind
of
like
protect
against.
I
think
this
is
one
where
we
want
to
think
through
sort
of
like
in
each
one
of
these
breaches
like
what
actions
would
people
be
taking
like
a
euro
breach
is
potentially
something
that
you
know
would
be
recognized
as
like.
B
B
So
what
I'll
do
is,
I
don't
think,
we've
quite
settled
on
a
decision
in
how
we're
going
to
have
the
the
key
sharing
service
work,
but
I
think
we've
talked
through
a
little
bit
more
detail
here.
I'm
going
to
take
try
and
take
a
stab
at
updating
the
dock
over
the
weekend
and
I'll
try
and
highlight
sort
of
like
a
short
doc
on
what
sort
of
like
some
of
the
considerations
here
are.
So
we
can
potentially
review
that
in
the
monday.
B
E
Yeah
yeah
absolutely
yeah.
E
What
the
thoughts
are
so,
for
instance,
what
we're
we're
actually
recording
the
kubecon
talk
today
for
notary
v2
status.
E
It
was
supposed
to
be
a
working
session,
so
we're
going
to
joke
about
that,
because
now
it's
recording
and
we're
basically
just
going
to
say
here's
the
things
we're
at
and
here
is
the
open
questions
and
I
think
it
kind
of
helps
people
understand
what
what
people
feel
fairly
confident
on
moving
forward
and
they
can
agree
or
disagree
and
then
they
feel
confident
that
yeah
they
haven't
figured
this
one
out
and
I'm
glad
they
haven't
figured
it
out.
E
And
I
think
the
key
discovery-
and
maybe
there's
you
know,
there's
the
whole
key
lifecycle
management
that
you're
you
know
driving
as
part
of
this.
I
think
there's
a
subsection
of
what
exactly
does
key
discovery
and
acquisition
mean
not
just
key
management
when
you
take
in
consideration
that
multiple
registries
as
content,
moves
between
registries
and
content
moves
into
air-gapped
environments.
What
is
the
right
model?
E
E
So
I'm
just
I'm
echoing
what
I
think
I'm
hearing
are
easy
for
free
and
you
know
the
community
can
use
them,
and
maybe
they
don't
give
that
you
know
high
trust
because
there's
no
domain
or
ca
associated
with
it
and
then,
if
larger
software
vendors
want
to
use
a
ca
base,
then
they
can,
and
that
gives
them
more
confidence,
but
they
have
to
unfort.
You
know
the
model
is
they
have
to
pay
for
because
there's
another
service
that
gets
validated.
B
Gpg
trust
model
is
that
you
would
have
to
have
keys,
go
back
and
forth
and
you
do
end
up
trusting
the
registry
at
that
point,
and
so
that
one
has
some
other
repercussions
but
want
to
think
through
and
so
gpg
potentially
is
a
solution,
but
there
you
do
need
to
trust
the
registry
itself
to
a
certain
extent
and
if
the
x-509
or
the
ca
model
is
another
one,
we
can
look
at
where
I
think
the
concern
comes
in
around
sort
of
like.
B
B
So
I
like
that,
because
you
can
support
both
both
formats
and
you
don't
necessarily
need
to
trust
a
registry,
but
I'll
elaborate
a
little
bit
more
on
that
on
the
gpg
side,
and
you
know
we
can
have
a
another
discussion
on
that
as
well.
I
think
the
gpg
that's
509
versus
the
ad
hoc
that
will
probably
take
me
like
a
week
to
write
up,
so
maybe
we
can
discuss
it
in
the
monday
after
the
shorter
one.
B
I
think
we
can
have
next
monday
in
terms
of
like
the
decision
process
we're
going
through
here
right
now,.
E
What
I
might
suggest
is
because
you
know
with
each
one
of
these
pr's
the
the
the
comments
endlessly
go
on
and
it
churns
and
churns
and
you
can
ever
get
a
merge,
is
maybe
do
a
separate
one
on
key
options
like
a
separate
markdown
and
a
separate
pr
for
pros
and
cons
of
keys
of
what
we
might
support.
E
On
that
document,
and
maybe
as
a
separate
document
for
the
key
acquisition
model-
and
you
know
maybe
once
off-
let's
assuming
at
some
point-
we
can
actually
get
agreement
on
these
three
things
right.
Your
scenarios
that
you
have
here,
the
types
of
keys
we
would
use
the
separate
one
separate
pr,
then
the
third
one
is
the
acquisition
and
once
all
three
are
done,
everybody's
comfortable
with
them,
then
we
just
merge
them
into
the
spec.
Because
remember
this
whole
thing
is
a
is
a
sketching
and
iteration
model.
E
B
Yeah,
I
agree.
I
think
I
can
separate
that
out
into
a
separate
pull
request.
So
I'll
definitely
keep
that
in
mind
cool.
E
All
right
so
yeah,
if
you
want
to
put
something
on
monday's
schedule,
just
that
you're
going
to
take
and
we're
back
to
10
a.m.
Our
time,
pacific
time.
I
just
put
something
on
the
agenda
that
says:
hey
I'll.
Do
a
quick
recap
of
these
topics
or
whatever
you
want
to
talk
about.
B
Sounds
good
I'll
go
ahead
and
do
that
all
right,
I
think
that's
all
we
had
to
discuss
today.
I
think
the
key
revocations
in
there.
You
will
probably
want
to
wait
till
next
week
to
dive
in
until
we've
settled
on
the
key
sharing
components
and,
and
potentially
that
gets
dressed
in
the
threat
model
as
well.
So
I
don't
think
we
we
want
to
jump
into
that
today
and
I
think,
having
shashank
and
justin,
for
that
conversation
would
also
make
sense.
Okay,
marco,
thank
you
for
taking
notes.
B
It's
definitely
very
helpful.
I
totally
was
going
to
have
to
spend
another
15-20
minutes.
Writing
them
up.
So
thank
you
for
doing
that.