►
From YouTube: Digital Identity Attestation WG (March 17, 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
Yeah
just
created
a
section
at
the
top,
please
sign
in
oh
we've
got
shamrock
emojis.
Now.
That's
awesome.
B
Feel
free
to
add
some
topics
at
the
end,
I
don't
really
have
a
plan.
I've
got
a
presentation
that
I'll
probably
be
jumping
around
randomly
between
that
and
a
whole
bunch
of
demos,
of
some
of
the
cool
stuff
we've
been
up
to
in
the
sig
store
project,
so
yeah
feel
free
to
jump
in
and
ask
questions
at
any
time.
B
A
B
So
today
I'm
going
to
be
talking
about
sig
story.
Six
store
is
a
new
project
luke,
and
I
and
a
bunch
of
others
from
this
call
and
from
outside
of
this
call,
have
been
working
on
as
part
of
the
linux
foundation.
B
It's
a
bunch
of
different
things
and
I've
had
a
hard
time
actually
explaining
all
of
them
all
at
the
same
time.
So
I
think
it's
easier
if
we
explain
it
in
different
pieces,
I'm
gonna
here's
the
website,
though
sigstor.dev
take
a
look.
B
B
Cosine
is
the
first
one
that
I'm
going
to
start
with,
probably
it's
a
tool
to
sign,
container
images
and
then
I'm
going
to
show
how
that
works
with
a
whole
bunch
of
cool
technology
like
transparency
logs,
like
the
recore
transparency
log,
as
well
as
a
pki
and
root
ca
service.
We're
also
working
on
here
called
full
co
to
manage
keys
and
identities
and
all
of
that
stuff
sound,
good,
okay,
I'll
take
silence
as
a
yes.
C
Dan,
if
I
could
interrupt
where
are
the
slides,
so
we
can
stick.
B
That
into
the
notes,
good
question:
let
me
figure
out
how
to
share,
and
I
think
I
have
to
do
this
funny
dance
to
share
them
publicly.
So
let
me
switch
that
up.
B
Share
what
do
we
call
this
this
one?
If
I
share
with
here,
everybody
in
this
group
can
see
it
so
join
this
group.
Rather
than
hitting
the
request
button
there
we
go.
I
can't
just
share
it
with
the
internet,
I'll
link
into
that
sorry.
I
should
have
done
this
before
and
we'll
get
that
added
to
the
minutes
too.
After
all,
right
so
sig
story,
the
idea
is,
we
want
to
make
it
easy
for
people
to
start
signing
their
code.
B
Why
code
signing
is
good,
but
it's
hard.
We've
seen
this
before
in
this
group,
with
all
the
different
open
source
projects
and
language
package
managers
coming
and
talking
about
how
they
support
code
signing
how
they
don't
support
code
signing
why
they
don't
and
all
of
that
stuff.
This
is
what
it
looks
like
for
language
package
managers
and
we've
had
some
of
these
people
like
the
pie,
pie,
maintainers,
come
and
present.
B
We've
had
people
talk
about
signing
containers
specifically
too,
but
this
is
kind
of
just
a
quick
survey.
If
you
go
to
all
of
the
package
manager
websites
and
see
how
stuff
is
signed
or
not,
signed,
piper's
got
signatures
supported,
but
they're
not
really
documented.
You
can
kind
of
just
upload
a
pgp
text,
signature
next
to
your
artifact
and
then
tell
your
users
what
public
key
to
use
and
where
to
find
that
signature,
and
sometimes
it's
there.
I
haven't
found
many
of
them
and
pm
doesn't
support
signatures
today.
B
Maven
central
requires
signatures
in
a
lot
of
places.
I've
seen
people
use
pgp
and
x509,
but
I
don't
know
exactly
how
that's
enforced
or
what
you
do
with
those
keys.
I
think
you
can
just
use
self-signed
stuff.
If
you
want
to
containers,
we
had
a
presentation
last
time
about
some
work
going
on
there.
They're
not
really
signed
today
is
the
tl.
Dr
go
doesn't
really
have
a
package
manager,
so
it's
not
really
applicable.
You
can
sign
commits
if
you
want
to,
but
there's
no
real
plumbing
through
the
go
to
link
for
that
stuff.
B
Ruby
supports
them.
It's
actually
got
a
pretty
cool
system
where
you
can
put
certs
into
your
packages
and
then
configure
routes
that
are
trusted
as
part
of
installation,
but
nobody's
really
using
it,
and
the
only
stuff
I've
seen
is
self-signed,
certs,
etc.
So
it's
it's
not
really
there.
Yet,
instead
of
languages
we'll
talk
about
why
and
some
stuff
we're
going
to
do
to
fix
that
in
a
bit
other
projects
that
aren't
languages,
we've
had
people
from
the
linux
kernel
and
you
know
js
come
talk
to
us.
B
This
is
how
they
sign
their
releases.
They've
been
doing
this
for
a
little
bit
longer
than
the
languages
and
the
trade-offs
are
a
bit
different
and
they
all
have
kind
of
elaborate
systems
in
place
that
they've
developed
on
their
own.
The
linux
kernel
releases
are
kind
of
just
source
releases
that
are
signed
usually
by
linus
or
greg,
and
you
can
find
the
keys
in
a
bunch
of
different
places
that
constantine
set
up
and
pointed
us
to
in
his
presentation,
but
it's
mostly
trust
on
first
use
after
you
get
their
keys
node.js.
B
Has
this
really
well
thought
through
system
that
supports
their
huge
list
of
maintainers?
But
it's
got
a
couple
problems
which
I'll
show
after
this,
despite
them
trying
harder
than
anyone.
I've
ever
seen
to
support
pgp
signatures
in
a
giant
open
community
project.
It
causes
a
bunch
of
problems.
B
Kubernetes,
nothing
is
signed
in
that
project
at
all.
They
want
to
start
signing
and
can't
figure
out
how
and
we're
trying
to
help
them
python,
open
ssl.
If
you
go
through
all
of
these
projects
and
read
how
to
verify
stuff,
it's
usually
just
a
couple:
pgp
keys
with
the
public
keys,
either
on
the
site
next
to
the
artifacts
or
somewhere
else,
and
you
can
find
it
there
and
verify
releases
if
you
want
to.
B
B
The
primary
keys
used
for
everybody
that
is
authorized
to
do
a
node.js
release
on
this
page
and
then,
if
you
scroll
down
a
little
further,
you
see
the
list
of
all
of
the
other
keys
that
might
have
been
used
to
sign
other
releases
and
they
have
a
verify
script
to
help.
You
verify
your
release
and
basically
what
it
does
is
pull
the
trust.
B
Every
single
one
of
these
keys
that
might
have
ever
been
used
to
sign
an
order,
release
into
your
key
ring
and
verifies
their
use
against
any
of
these.
So
if
any
of
these
get
compromised
or
need
to
be
revoked
or
anything
like
that,
you're
out
of
luck,
because
you
don't
know
which
one
is
supposed
to
be
used
at
any
given
time,
so
it
means
that
anybody
that
was
ever
part
of
the
node.js
trust
trusted.
Releasers
is
now
part
of
it
forever.
It's
a
big
burden
to
place
on
people.
B
Distros,
these
are
usually
in
much
better
shape.
The
ones
I've
looked
at
debian
has
a
really
cool
system.
We
heard
about
here
too
on
how
they
manage,
which
keys
get
signed
by
their
rootkeys.
B
They
have
been
experimenting
with
different
ways
to
onboard
maintainers,
but
historically
they've
required
you
to
meet
other
maintainers
in
person
and
get
your
key
signed
by
a
whole
bunch
of
them.
That
obviously
hasn't
worked
out
throughout
the
past
year
with
no
one
meeting.
Anybody
in
person
so
they're
working
on
some
different,
more
distributed
ways
to
do
that
pretty
much
everybody
here
again
uses
pgp,
but
nobody
is
really
using
trust
on
first
use
or
nobody's
really
using
web
of
trust
they're
all
using
some
other
key
distribution
mechanism.
B
B
They
also
have
this
pretty
cool
system
where
they
generate
the
set
of
keys
that
will
be
used
to
sign
the
next
release
at
the
time
they
cut
this
release,
and
then
they
put
the
public
keys
for
the
next
release
into
the
current
release
and
sign
that
so
they've
got
this
kind
of
trusted
chain
of
public
private
keys.
So
you
can
go
all
the
way
from
one
you
see,
release
up
to
the
current
one.
That
kind
of
scares
me
a
little
bit
for
some
other
reasons
like
you're.
B
C
A
quick,
quick
interrupt
did
I
heard
second
hand
that
the
debian
folks
during
the
pandemic
are
using
various
video
call,
which
you
know
obviously
can
be
fooled,
but
the
theory
is
that's.
You
know
at
least
raises
the
bar.
B
Yeah,
I'm
sure
they
figured
something
out.
The
presentation
we
had
in
this
group
was
a
while
ago
and
they
were
working
on
different
mechanisms
to
like
use
keys
for
a
while
and
have
people
vouch
for
each
other
and
a
more
pseudo-pseudo-name-friendly
method
by
building
up
reputation
over
a
long
period
of
time
too.
But
it's
possible.
That's
changed
that
was
probably
four
or
five
months
ago
when
they
presented.
B
So
that
was
also
kind
of
specific
to
open
source,
and
this
is
where
things
get
a
lot
different
and
I
promise
we'll
jump
into
some
demos
pretty
quickly,
but
the
walled
gardens
the
app
stores,
the
marketplaces
all
handle
code
signing,
but
they
do
it
completely
differently
from
open
source.
It
doesn't
look
anything
like
the
open
source
signing
stuff
at
all.
B
Windows,
drivers
and
authenticode
in
the
microsoft
store,
probably
the
most
widely
known
example
of
this,
where
they
use
x509
code
signing
certs,
which
are
a
specific
type
of
x5
online
certificate
you
can
buy
and
you
can't
ship
windows
drivers.
You
can't
install
a
windows
driver
unless
it's
been
signed
with
one
of
these
search,
that's
trusted
by
the
windows
system
and
even
require
the
enhanced
validation
search
for
a
lot
of
these
windows
drivers,
which
cost
a
ton
of
money.
B
So
that
said,
why
is
signing
hard
and
then
we'll
jump
into
some
demos,
there's
always
different
ways
to
sign
things
abstractly.
This
is
kind
of
what
a
signature
is,
though,
take
an
artifact,
a
person's
got
a
private
key.
You
create
a
signature
from
those
two
things
and
then
you
can
hand
that,
to
your
end
users,
once
they
have
that
artifact,
the
signature
and
the
public
key,
they
can
verify
that
it
was
signed
by
the
person
with
the
private
key.
B
We
talked
all
these
projects
about.
Why
they're
not
signing
a
lot
of
people
think
it's
hard.
It
turns
out
signing
actually
isn't
that
hard.
It's
just
that
the
tooling
is
all
pretty
bad
and
archaic
and
hard
to
use.
Today
we
started
it's
kind
of
the
reverse
order.
Actually
we
wrote
all
these
tools,
but
the
easiest
way
to
explain
how
they
work
together.
So
we
were
kind
of
focused
on
containers
first,
because
I
know
a
lot
about
containers
and
I
wanted
to
make
a
signing
tool
for
containers.
B
B
The
first
version
of
this
tool
actually
took
less
time
to
write
than
it
took
me
to
make
this
little
gift
showing
how
it
works.
So
this
stuff
is
really
simple.
Signing
can
be
really
simple.
The
tooling
is
just
kind
of
bad,
because
it's
all
general
purpose
and
does
a
bunch
of
other
stuff.
Today,
let's
do
some
actual
demos.
Instead
of
watching
a
skip,
though,
and
show
how
cosine
can
sign
containers
today,.
C
B
Nope,
I
can
sign
blobs
today
too.
The
challenge
is
really
about
what
you
do
with
those
signatures
after
and
the
keys
containers
have
a
couple
challenges
to
sign
them,
but
they
also
have
some
really
cool
properties
that
allow
us
to
automatically
store
the
signatures
next
to
the
container
and
find
them
and
retrieve
them
later.
I
actually
have
some
really
cool
demos,
though
after
the
container
basic
one
showing
some
stuff,
you
can
do
by
signing
blobs
with
cosine.
So
I'll
do.
B
Stop
go
ahead
I'll.
B
No,
so
I
just
cleaned
everything
up
from
the
last
set
of
demos.
So,
let's
start
signing
containers.
This
has
the
experimental
mode
turned
on
so
there's
some
extra
output,
and
I
don't
want
to
try
to
remember
what
the
environment
variable
is.
So
there's
some
extra
output
we'll
ignore
for
now,
but
I'll
explain
it
later.
B
So
this
is,
let's
get
rid
of
the
annotation.
This
is
a
public
container
image.
You
can
look
it
up
gcr.io.
This
is
just
the
one
I
use
for
all
testing,
but
yeah
it's
shared
publicly,
I'm
the
only
one
that
can
push
to
it.
Probably
more
people
can,
but
anybody
can
look
at
it.
So
I've
got
the
key.
Actually,
first
I'll
show
the
keys.
There
is
a
cosign
generate
key
pair
command.
I
showed
in
the
gif.
B
B
This
is
the
private
key
on
disk
it's
stored
encrypted
by
a
passphrase
which
you
see
we
need
to
enter
to
do
the
actual
signature.
It's
encrypted,
so
you
can
actually
just
store
this
right
in
your
repo.
You
don't
have
to
worry
about
committing
these
and
that
allows
you
to
do
some
pretty
cool
release
flows
that
I'm
going
to
talk
over
in
a
minute.
The
public
key
is
in
here
too.
B
This
is
what
a
public
key
looks.
Like
I
mean
you
can
do
added
support
for
kms
systems
and
stuff
too.
So,
if
you
don't
want
to
store
this
and
do
the
signatures
locally,
you
can
point
at
like
a
gcp
or
another
cloud
providers
kms
and
do
that
stuff.
But
now,
let's
sign,
talked
about
that
enough
already
we'll
get
rid
of
the
annotation
part
for
now
flags.
Just
the
thing
you
want
to
sign
in
the
key
enter
the
password.
B
Now
we
generated
a
signature
with
that
and
uploaded
the
signature
to
the
container
registry
right
next
to
the
container.
So
that's
the
part
that
we
can't
really
do
for
blobs
david
that
you're
just
asking
about.
If
it's
just
a
binary
blob,
we
don't
really
know
where
to
stick
that
signature.
B
Certain
artifact
types
have,
you
know,
well-known
places,
for
that,
like
jars
have
a
place,
you
can
stick
a
signature
inside
of
them,
ruby,
gems,
something
similar,
and
we
do
want
to
support
that
stuff.
It
probably
doesn't
make
sense
to
all
be
in
the
same
cli
and
then
forget
about
this
transparency
log
part.
For
now,
we'll
come
back
to
it.
B
We
can
look
at
the
signature
if
you
know
anything
about
containers
or
care
about
how
things
get
stored
in
the
registry.
This
might
be
interesting,
but
the
way
we
do
this
linking
of
the
signature
to
the
container
is
a
little
tricky,
but
it
does
work.
B
B
So
we
make
a
kind
of
virtual
image
to
hold
the
signature
that
is
named
after
the
digest
of
the
thing
it
is
referring
to
right
here.
So
that
is
the
digest
of
the
container
we
signed,
and
then
we
stick
a
little
cosine
suffix
on
there,
because
other
people
are
doing
the
same
thing.
B
So
we
can
take
a
look
at
what
actually
got
uploaded
here
with
the
crane
tool
and
another
trigonometry
pun
to
calculate
that
munching,
the
command
is
called
triangulate,
so
that
will
just
print
out
this
image
name
that
I
just
showed
and
we're
gonna
look
at
the
manifest
around
that
through
jq.
B
So
this
is
the
thing
we
actually
uploaded
to
the
registry.
It
refers
back
to
the
image
by
its
name,
and
then
it's
got
the
signature
and
stored
right
here
in
the
annotation.
B
You
can't
sign
a
container
itself.
A
container
is
kind
of
like
a
virtual
concept
until
it
gets
represented
somehow
on
disk.
So
what
we
sign
is
actually
a
little
attestation
about
that
container.
It's
a
little
json
wrapper
that
contains
that
digest
of
the
container.
This
thing
here
as
well
as
it's
got
some
other
fields
where
you
can
stick
in
optional
stuff,
which
was
that
annotation
flag.
I
showed
we
can
see
what
one
of
those
looks
like
when
we
verify
get
rid
of
the
annotation
thing
again.
B
So
this
is
going
to
download
the
signature
from
this
image,
not
through
demo,
it's
going
to
download
the
signature
from
an
image
and
do
a
bunch
of
checks
on
it.
So
this
is
the
actual
thing
we
signed.
We
generated
this
json
payload.
This
is
called
red
hat,
simple
signing
format,
they've
been
kind
of
the
only
ones
red
hat,
citing
containers
for
a
while.
Now
they
made
up
their
own
protocols
to
do
it,
because
there
wasn't
really.
B
Else
out
there
and
here's
that
digest
inside
of
this
that
I
mentioned,
if
you
don't
check
this
digest,
there's
nothing
actually
that
guarantees
the
signature
was
tied
back
to
the
image
because
the
naming
convention
can
be
faked
and
it
isn't
really
verifiable.
So
you've
got
to
make
sure
to
check
this.
That's
what
this
little
log
statement
is
and
forget
the
transparency
stuff
for
now,
so
that's
signing
containers
you
can
do
the
dash
a
equals
bar
and
you
can
tack
on
some
annotations
that
get
stuck
in
this
optional
section
here.
B
B
So
you
can
use
this
assigned
containers
today,
you
can
do
some
cool
stuff
with
the
optional
tags
here
like
stick
in
science
time
stamps.
If
you
want
to
build
up
something
like
the
update
framework,
you
can
sign
git
commits,
which
is
pretty
cool
for
releases,
I'll
show
how
that
works,
and
then
we
can
pause
for
questions,
because
I've
said
a
lot.
B
A
little
example
workflow
I
put
together,
uses
github
actions
to
build
and
release
a
container
from
github.
This
one
uses
the
flower.
We
just
check
both
keys
into
the
repo
and
then
every
time
something
gets
merged
to
main
we
build
and
sign
it
with
an
annotation
about
the
commit
that
we
built
at
all
inside
of
github
actions.
So
what
this
actually
lets
you
do,
which
is
kind
of
cool,
is
from
a
container
image.
B
If
you
find
one
on
a
registry
summer,
you
can
look
up
the
signatures,
see
that
it
was
signed
at
this
commit
come
back
to
the
github
repo
at
that
commit,
and
the
public
key
is
present
in
this
repo.
So
you
can
find
the
right
public
key
to
use
for
each
commit
in
the
repo
which
is
part
of
the
go
itself
and
the
commit.
B
So
it's
kind
of
self-verifying
in
a
little
cycle
there
and
then
it
makes
rotation
pretty
easy,
because
if
you
want
to
rotate
and
set
a
new
key
for
the
next
release,
you
just
update
it
and
get
before
you
do
the
next
release
and
then
people
can
verify
each
commit
as
they
go
along
with
each
build
all
right.
A
lot
of
stuff
about
containers.
B
Okay,
so
we
don't
sign
a
git
commit
here.
What
we
actually
do
with
this
demo
is
that
we
stick
the
git
commit
into
the
using
that
dash
a
flag
right,
so
this
flow
just
uses
the
annotation
flag
as
like
a
little
primitive
that
you
can
stick
anything
into.
So
if
you
find
that
signature
like,
if
I
wanted
to
do
that
here,
instead
of
dash
a
foo
equals
bar,
we
would
do
something
like
bit
shot
equals.
B
B
B
So
what
we're
signing
here
is
a
json
wrapper
that
includes
the
git
commit,
so
the
geek
commit
itself
is
kind
of
signed.
It's
just
stored
with
the
container.
Now,
if
we
do
a
verify,
see
that
come
out.
So
what
that
claim
kind
of
says
is
that
I
claimed
that
I
built
this
container
with
that
git
commit.
Does
that
make
sense?
This
is
actually
part
of
the
thing
that
is
signed
with
the
key.
B
B
B
B
G
Yeah,
possibly
a
bad
question:
what
is
an
example
of
optional
stuff
to
add.
B
Yeah,
so
the
the
field
is
called
optional.
I
didn't
name
it
that,
but
yeah,
that
is
kind
of
what
I
was
showing
here
with
the
git,
commit
that's
one
example
with
this
flow.
I
have
another
one
here
that
does
a
release
build
where
we
stick
in
the
git
commit
to
get
signed,
as
well
as
the
get
tag
that
the
release
happens
at
so
when
you
create
a
release
in
github
actions,
this
will
automatically
do
all
of
that
stuff.
B
The
private
key
is
in
the
repo,
so
I
forgot
to
mention
this.
The
only
thing
that
we
do
is
we
stick
the
password
into
a
github
secret,
so
this
flow
is
really
designed
for
the
claim
is
kind
of
coming
from
github's
builder.
This
is
coming
from
github's
build
system
saying
that
we
executed
this
with
this
password,
and
this
is
what
came
out
at
the
end.
G
B
Yes,
and
so
that's
yes,
a
good
question,
yes,
and
so
that's
one
of
the
challenges
with
cosine.
You
can
sign
things
multiple
times
and
the
let
me
find
the
section
that
explains
the
challenges.
B
You
can
sign
something
multiple
times
so
as
long
as
they
come,
both
companies
have
access
to
push
these
signatures,
which
probably
isn't
true,
but
if
you
copy
the
container
normally
the
way
this
works,
is
the
company
publishes
the
image
and
then
somebody
copies
it
to
their
own
repository
where
they
do
have
access,
they
would
copy
the
original
signature
and
then
they
can
append
their
own
onto
it
in
their
own
repository.
B
It's
a
little
bit
racy.
That's
kind
of
the
challenge
with
the
way
the
registry
works
today
is
you
have
to
download
the
thing
append
your
signature
into
the
list,
and
then
you
push
it
back
up.
So
if
two
people
do
that
at
the
same
time,
it's
last
one
wins.
There's
some
ongoing
proposals
to
add,
like
http
tag,
semantics
to
the
registry
api,
so
you
could
do
optimistic,
concurrency
and
detect
and
prevent
that
yeah
multiple
people,
multiple
companies,
can
sign
things
and
verify
them
all
later.
B
All
right
so
now
we'll
do
the
transparency
log
stuff
here
quickly
and
then
we'll
go
to
the
signing.
Git
commits
that
constantine
wants,
because
that's
pretty
cool
all
right,
so
the
transparency
log
piece.
We
saw
some
of
that
output.
Here
I
mentioned
when
we
do
assign.
B
B
We
do
the
sign
we
are
going
to
see
some
a
little
output
saying
that
we
also
uploaded
the
signature
to
a
transparency
log
and
got
an
index.
So
this
is
this
transparency.
Logging
referring
to
is
called
recore
here
and
then
show.
Hopefully,
the
demo
works.
Yeah
just
did
awesome,
so
transparency
logs
are
pretty
cool
concept.
You
can
think
of
them
as
a
public
append
only
log,
so
we're
operating
one
of
these
as
part
of
this
project
called
recore,
I
mean
it
stores
signatures.
B
These
are
used
across
all
of
the
web
today
for
certificate
transparency
they're.
How
browsers
can
prove
that
certificate
authorities
are
behaving
correctly
record
lets
you
store
signatures
in
here,
and
so
anybody
can
look
through
this
log
to
find
all
signatures
that
have
been
created.
We
actually
store
is
kind
of
a
triplet
of
the
signature
bytes,
the
public
key
that
was
used
and
then
the
hash
of
the
thing
that
got
signed.
It's
kind
of
all
the
elements.
B
We
need
to
verify
that
it's
a
valid
signature,
so
one
of
the
cool
use
cases
here
is
that
you
can
detect
if
you
can
use
this
to
help,
detect
key
compromise,
and
so
what
I
mean
by
that
is,
if
you
have
a
private
key
somewhere
that
you're
using
to
sign
releases,
you
have
to
protect
that
private
key.
If
you
lose
it,
somebody
might
use
it
to
sign
stuff
on
your
behalf
and
trick
your
users
into
thinking
it
came
from
you
today.
B
You
really
have
no
way
to
detect
that
or
mitigate
mitigate
against
that
happening
other
outside
of
just
protecting
your
key
as
closely
as
you
can
this
transparency
log,
what
you
do
is
actually
pretty
cool
and
it
lets
you
monitor
the
log
for
your
for
signatures.
That
came
from
your
private
key
and
we
have
a
little
demo
here
that
shows
how
that
works.
I
have
a
something
running
on
my
own
little
cluster
there's
an
example
checked
in
I'll
show
you
where
the
code.
B
Is
it's
still
in
a
pull
request
just
a
couple
days
ago?
So
this
is
a
log.
Anybody
can
run
themselves
or
a
little
service.
Anyone
can
run
themselves
that
tells
the
log
it's
just
a
100
lines
of
ghost
or
so
a
couple
hundred
lines
ago
to
watch
the
log,
verify
the
log
and
then
uses
send
grid
to
send
myself
an
email
anytime.
My
key
got
used
and
then
I
can
make
sure
that
it
was
something
that
I
actually
intentionally
signed.
B
So
I've
got
this
running
right
now
and
the
these
are
all
the
emails
I
got
during
the
demo.
Every
time
I
use
those
keys,
so
you
can
see
here
it
looks
safe.
This
is
answering
the
log,
I
got
a
little
email
and
it
shows
you
the
command
to
check
it
out
and
see
what
got
signed
and
how
that
is.
So
if
we
run
this
we'll
see
the
entry
stored
here
rjq.
B
This
is
the
hash
of
the
thing
we
sign.
We
don't
store
all
of
it
in
transparency,
log,
because
that's
kind
of
scary,
we
can
never
delete
stuff,
the
signature
itself.
This
is
just
a
64,
encoded
bytes.
This
is
the
key
type.
We
also
support
pgp
all
the
different
ways
of
signing
things.
We
just
have
to
know
how
to
verify
the
signature
is
a
real
signature
and
then
the
content
of
the
public
key
for
later.
So
this
is
how
we
can
make
sure
and
detect
our
public
key
being
used.
B
This
is
kind
of
complicated
and
there's
a
lot
of
subtleties
with
transparency
logs
any
questions
on
this
one.
Before
I
go
a
little
further
and
get
to
constantine's
cool,
get
signing
question.
B
All
right
so
now
signing
blobs
david's,
original
question
and
assigning
git
commits.
Actually,
let
me
do
one
more
demo
here
first
and
then
we'll
get
to
that.
So
with
all
this
so
far,
you
still
have
the
question
of
getting
and
managing
keys,
communicating
those
keys
to
your
users,
not
losing
the
private
key.
Even
if
you
leak
it,
if
you
leak
it,
we
can
help
you
detect
that.
B
But
if
you
lose
it
and
no
longer
have
access
to
it,
then
you've
still
got
to
come
up
with
a
new
one
figure
out
some
way
to
securely
communicate
that
new
one
to
your
users
and
for
users
they
have
to
find
they
need
a
way
to
find
out
which
keys
should
be
used
for
a
given
person,
and
so
we
thought
for
a
while
about
how
to
help
solve
this
problem
and
came
up
with
a
pretty
cool
flow.
I'm
going
to
show
here
next
if
you've
got
the
experimental
mode
turned
on
in
cosine.
B
You
can
try
this
today,
but
we
can
do
a
signature
here
that
same
image
delete
clean
up
quick.
First,
we
call
this
keyless
signatures,
so
we're
actually
going
to
sign
this
image
with
no
keys
verify
it
with
no
keys,
see
no
keys
on
the
command
line.
We're
going
to
sign
this
image
all
right.
So
if
you've
got
the
experimental
mode
turned
on
this
pops
up-
and
let
me
fix
my
browser
windows
I'll
rio
over
here
all
right.
So
this
is
a
little
off
flow.
B
We'll
go
back
to
the
terminal,
though
this
got
popped
open
when
I
ran
this
command,
so
this
is
keyless
signatures.
What
we
actually
do
here,
if
you
don't
pass
a
key,
is
that
we
generate
an
ephemeral
key
pair,
so
this
happens
right
in
memory.
It's
sitting
there
in
memory
right
now
they
never
touch
disk.
We
generate
a
private
key
and
a
public
key,
and
then
we
get
a
certificate
for
that
talked
about
how
web
certificates
and
transparency
lies,
help
with
that
a
little
bit
earlier.
B
B
We're
essentially
doing
the
same
thing,
except
for
a
person
I'm
going
to
do
that
for
a
person
we're
using
email,
addresses
and
there's
already
a
challenge
protocol
that
exists
for
that
called
open
id
connect.
So
the
browser
pops
open
to
the
open
id
connect
provider.
In
this
case,
it's
google,
I
verify.
I
click
this
button,
give
it
access
and
prove
to
the
ca
that
I
do
own
this
email
address
at
this
time.
The
auth
happens.
B
We
come
back
here
and
now
we
sign
with
that
private
key,
throw
it
all
the
way,
so
it
never
touches
disk
and
enter
all
of
that
into
the
transparency
log,
so
the
certificate
authority
also
issued
they
issued
that
public
certificate
and
stuck
that
on
a
transparency
log
too.
B
B
What's
in
here,
see
a
certificate
we'll
pretend
that
worked,
the
demo
didn't
quite
work
yeah,
so
we
store
the
full
certificate
here,
which
you
can
download,
look
up
and
verify,
and
the
signature
itself
to
figure
out
what
happened
after
and
so
in
this
flow.
What
we
do
is
we
download.
This,
which
should
have
happened,
is
that
we
should
have
downloaded
the
certificate
verified
that
it
signed
the
artifact
the
public
key
in
here
and
then
pulled
out
the
email
address
and
printed
out
my
email
address.
B
Let's
say
I
signed
it:
does
that
kind
of
make
sense?
Everybody
can
pretend
that
the
demo
worked
for
me.
I
do
have
some
gifts
around
of
it.
B
B
It's
fine,
any
random
thing
you
can
do
with
a
key
or
you
can
leave
the
key
off
and
do
the
cool
transparency,
log,
stuff
and
certificate
authority
stuff.
What
we
realize
here
is
that
we
can
actually
you
know,
sign
anything
with
this.
We
just
don't
have
a
way
to
store
the
signatures
places
in
some
cases.
The
transparency
log
might
be
enough
and
that's
where
I'm
going
to
show
the
get
signing
stuff
go
back
to
cosine.
B
I
called
this
fun
dot,
md
and
just
wrote
in
some
good
signing
stuff
here,
there's
one
more
that's
sitting
in
a
pull
request,
I'll
jump
to
the
very
bottom
that
shows
all
this
together,
but
this
shows
a
couple
different
ways
to
sign.
Git
commits
we've
seen
a
bunch
of
different
proposals
in
this
group
about
ways
to
improve
the
way
git
handles
signatures.
B
I'm
gonna
see
how
much
we
could
do
without
having
to
change
git.
If
you
thought
you
know,
git
is
kind
of
hard-coded
today
to
use
pgp
gpg
throughout
all
the
signing
and
verifying
commands.
This
shows
that
it
might
not
need
to
be
so
this
first
one
here
just
cosign
to
sign
a
blob,
except
instead
of
a
blob,
we're
just
going
to
assign
the
text
of
the
git
command
itself
that
hash
with
the
key.
B
It
shows
what
that
looks
like
and
we
spit
out
this
signature
at
the
end.
So
if
you
want
to,
you
can
send
a
signature
to
someone
and
they
can
verify
that
you
signed
the
hash
of
the
git,
commit
that
git
commit
shot.
You
can
check
it
here
like
this
and
it
verifies
okay.
B
This
still
leaves
you
on
your
own
for
communicating
the
public
key
and
signature
to
people
because
we're
not
storing
it
in
the
git
repo.
Now
this
might
be
what
you're
asking
about
constantine
git.
Has
this
way
to
attach
notes
a
lot
of
people
don't
know
about
this
command
the
get
notes
command
lets
you
attach
messages
or
files
or
objects,
or
anything
to
another
commit
in
git.
B
So
we
can
actually
just
stick
this
right
in
the
git
repo
instead
of
having
to
use
another
storage
mechanism.
This
shows
that
same
thing.
It's
an
old,
commit
of
using
git
notes
to
stick
the
signature
in
that
we've
generated
with
the
kms
or
any
other
system.
We
want
to
just
attach
it
to
the
head
commit
and
then
you
can
verify
it
and
look
it
up
later
with
get
notes,
show
and
the
commit.
B
If
you
want
to
make
the
repo
kind
of
meta
and
self-verifying,
you
can
again
check
the
public
keys
into
the
repo
at
each
commit
and
ensure
that
you
used
the
right
key
to
sign
each
one
at
the
right
time
and
you
can
do
revocation
and
rotation.
That
way.
Does
that
sort
of
make
sense
constantine.
F
Yeah
it
does
the
there's
two
comments.
One
do
not
use
the
default
ref
for
those
notes.
You
can
actually
create
your
own
rev,
since
those
refs
notes
something
specific
to
you.
Otherwise,
you're
very
likely
just
clash
with
somebody
else's
notes.
Right
and
two
is
generally
developers,
don't
really
like
git
notes,
because
they
are
a
weird-ish
database
that
lives
in
its
own
riff
and
doesn't
get
unless
you're
cloning
with
mirror
nobody
actually
going
to
get
them.
B
Yeah,
exactly
you
have
to
push
you
have
to
remember
to
push
them.
You
have
to
remember
to
pull
them,
so
nobody
actually
has
them.
There's
one
cool
use
case
I've
seen
in
this,
which
is
like
the
get
appraised
project.
I
don't
know
if
anyone's
seen
that
where
it
actually,
they
built
this
whole
code
review
system
on
top
of
get
notes.
B
F
B
Our
footsteps,
sort
of
yeah,
but
the
constant
things
that
don't
store
things
you
can
get,
so
we
don't
actually
need
to.
Let's
show
hard
mode
here.
If
you
turn
on
our
transparency
log
stuff,
what
you
can
actually
do
is
just
upload
that
signature
to
our
transparency
log,
you
upload
the
public
key
bytes,
the
signature
itself
and
then
the
thing
you
signed.
So
in
this
case
the
only
thing
you're
really
uploading
is
the
git
command
itself.
Because
that's
the
thing
we're
signing
you
don't
need
to
store
it
in
git.
B
If
you
don't
mind
sending
us
the
commit
hash
to
the
transparency
log,
you
can
actually
go
backwards
and
look
stuff
up
in
the
transparency
log
later.
So,
if
you
don't
want
to
store
it
in
get
notes
or
somebody
forgot
to
pull
it
from
a
mirror
or
something
like
that,
you
can
look
it
up.
So
this
shows
how
to
use
the
record
command
to
look
up
using
the
search
thing
instead
of
an
artifact.
We
can
sign,
you
know.
Tarball.
All
we
sign
is
the
git
command
itself.
B
We
can
get
all
the
signatures
that
are
in
our
transparency
log
attached
to
that
artifact.
So,
instead
of
get
notes
show
we're
using
a
transparency
log
search
to
do
the
same
thing
and
from
that
you
can
pull
out
the
signature
and
use
the
public
key
that
you
got
or
email
or
was
in
the
repo
at
that
right
time,
and
so
you
can
verify
all
this
stuff
without
having
to
store
anything
in
the
git
repo,
too
you're
uploading.
B
No
questions
all
right,
so
level
11.
I
need
to
merge
the
last
pull
request,
but
I've
got
a
self
verifying
keyless
assign
git
commit
here.
B
So
what
I
actually
did
here
is
used
the
keyless
mode
to
sign
these
two
commands.
The
first
one
had
a
test
failure
that
I
heard
a
link
to
error.
I
had
to
fix
so
I
assigned
both
of
these,
but
I
put
it
here
in
the
pull
request
message,
so
this
commit
was
signed
with
the
whole
keyless
root
ca.
The
signature
is
stored
in
the
transparency
log,
so
anybody
can
look
this
up
later
and
check
it
against
my
email
address
that
I
went
through
the
two-factor
author
flow
for
and
stored
in
the
other
transparency
log.
B
So
you
can
run
this
to
search
for
the
commit.
There
were
two.
This
is
the
first
one
find
that
entry
and
you
can
download
that
entry
and
you
see
the
certificate
that
was
generated
at
that
time.
I
think
santiago
fixed
this
up
a
bit.
I
don't
know
enough
open
ssl
to
do
this
on
the
command
line,
but
it's
pretty
simple
to
do
and
go
to
actually
do
all
the
verification
pieces
here.
So
you
can
run
this
through
open
ssl.
B
B
I
think
that
one's
pretty
cool
there's
some
subtlety
to
the
way.
This
works
that
I
kind
of
glossed
over
around
the
short-lived
certificates
and
time
stamps,
and
if
the
demo
had
worked,
we
would
have
seen
some
of
that
output
that
I
could
have
talked
about,
but
the
whole
way
that
we
we
issue
these
certificates
is
that
we
expect
them
to
be
very,
very
short-lived
and
the
private
keys
to
never
touch
disk.
B
B
We
checked
that
they
were
in
the
transparency
log
and
then
there's
this
subtle
piece
that
I
glossed
over,
but
that's
kind
of
what
ties
it
all
together
and
then
we
see
the
email
address
should
have
been
spit
out
if
the
demo
hadn't
worked,
but
the
time
stamping
piece
is
actually
pretty
critical
to
making
sure
all
this
works.
If
you
generate
these
keys
and
throw
them
away,
you
want
to
make
sure
they're
really
thrown
away
and
can't
be
used
later.
B
Let's
encrypt
does
the
same
kind
of
thing:
the
issue
certs,
for
I
think
it's
like
two
months,
and
then
you
have
to
have
a
system
that
keeps
getting
new
ones
and
refreshing
them
that
works
with
browsers,
because
their
certificate
is
expected
to
be
valid
when
you're
accessing
the
web
page
that
stops
working
a
little
bit
for
code
signing
and
that
causes
a
ton
of
trouble
because
you
sign
the
code
and
then
it's
got
to
keep
running
for
years.
B
Solarwinds
is
a
good
example
of
this,
not
to
pick
on
them.
It's
more
a
problem
with
the
current
authentic
code
stuff,
but
their
keys
were
compromised
back
in
december
and
they've
been
unable
to
revoke
them
and
switch
to
new
keys
still
because
if
they
did
that,
all
of
the
non-compromised
builds
would
stop
working.
So
they
need
to
first
track
down
all
of
the
bills
of
solar
rinse
that
they
don't
want
to
break
and
re-sign
those
with
the
new
keys
before
they
can
revoke
the
old
ones.
B
So
we're
coming
up
on
four
months
since
the
compromise
and
they've
still
been
able
unable
to
revoke
so
what
we
do
is
short
live
certificates
they're
only
instead
of
being
valid
for
years
and
making
sure
that
they're
always
valid.
When
you
want
to
use
the
code,
we
took
a
pretty
different
and
somewhat
new
approach
for
code
signing
where
this
we've
we
required
that
the
signature
was
created
when
the
certificate
was
valid,
not
that
the
certificate
is
still
valid.
B
You
can
do
it
with
openssl
there's
like
an
open,
ssl
ts
command,
where
you
can
generate
a
timestamp
request,
just
like
a
certificate
request,
send
it
to
one
of
these
authorities
and
then
they
hand
some
payload
back
to
you,
which
is
where
it's
signed
with
their
public
key
or
signed
with
their
private
key,
the
timestamp
itself.
So
and
the
hash
of
the
thing
you
sent
them
so
that
can
kind
of
serve
as
evidence
that
you
generated
the
signature
at
least
before
a
certain
time,
which
is
all
we're
really
doing
here.
B
B
B
So
if
we
can
show
that
the
signatures
were
entered
into
the
log
while
the
certificate
was
valid,
that's
good
enough,
and
so
we
can
ensure
that
the
certificates
don't
get
reused
later
that
all
this
happened,
while
the
certificate
was
valid.
G
There's
a
couple
questions
in
the
chat,
I
think
maybe
I
missed
one,
I'm
not
sure
if
you
already
answered
these
are
multiple
container
image,
manifest
formats
supported
for
the
input
to
the
container
signing
process.
A
B
Multiple,
okay,
I
don't
know
if
you're
still
on
the
call.
Do
you
have
an
example
of
other
types
of
container
image
manifest
formats?
D
B
Yeah,
so
that's
a
something
we
have
to
change
in
the
payload
format
itself:
get
rid
of
the
docker
format
that
came
from
the
original
red
hat,
simple
signing,
spec
that
they
started
years
ago
and
docker
was
kind
of
the
only
one
there's
nothing
docker
specific.
Actually
in
there,
that's
just
the
name
of
the
key
that
they
expect
the
signature
to
be
located
at
so
we're
hoping
to
get
that
some
new
format
to
stick
this
stuff
in
it's
not
quite
as
custom
json
with
names
like
that
in
there.
B
So
what
we're
actually
signing
is
the
oci
manifest
well
the
digest
of
the
oci
manifest.
We
then
just
stick
it
in
another
json
thing
that
says
docker
in
the
name.
D
D
D
B
That
mode
of
signing
uses
a
gpg
key,
it's
a
little
weak
with
github.
I
don't
really
like
it.
It
doesn't
do
a
ton,
because
what
github
does
is
they
show
a
badge
that
something
was
signed
as
long
as
it
was
signed
with
a
key
that
is
uploaded
on
the
user
account
profile,
the
user
account
profile
is
protected
by
you
know
normal
password,
so
anybody
with
the
password
can
just
change
the
keys
that
are
stored
in
github
to
match,
whatever
they
have.
B
Yeah,
that's
what
you
said
in
the
second
half
there
dumb
question
lack
of
familiarity
with
open
id
connect.
How?
How
is
it
exactly
that
verifiers
are
able
to
trust
the
signature
in
the
key
to
the
signing
process?
The
email
address
is
legitimately
associated
with
the
signature
yeah.
B
So
that's
where
the
transparency
logs
come
in
our
service
and
mike
can
probably
explain
this
better
than
I
can,
because
I
don't
really
understand:
openid
connect
a
ton
but
yeah,
so
our
service
basically
verifies
that
google
or
whoever
the
authentic
the
identity
provider
in
this
case
is
says
that
you
know
this
key
is
actually
associated
with
this
email
address.
There's
this
whole
identity,
token
system
and
then
what
we
do
is
we
stick
that
on
a
log,
a
transparency
log?
So
anybody
can
look
that
up
and
see
all
the
certificates
we've
granted.
B
B
You
know
we're
putting
a
whole
bunch
of
trust
into
your
password
on
your
email
address
and
your
two-factor
auth
and
anything
else
you're
using
to
protect
that
account,
but
we
can
provide
transparency
on
all
of
this
so
that
if
anybody
does
screw
up
in
that
process,
it's
on
the
record
and
then
you
can
tie
that
certificate
all
the
way,
through
the
record
log
to
everything
that
was
signed
with
it.
So
you
don't
have
to
go
through
this
huge
emergency
resign.
Everything
you
might
have
ever
built.
D
B
Yeah,
we
kind
of
that
is
one
of
the
big
pieces
of
this
trust
model.
We
assume
you
can't
keep
private
keys
private
and
we
assume
you
can't
keep
private
keys
without
losing
them
long
term,
but
you
can
probably
keep
access
to
your
email
address
most
of
the
time.
There's
existing
mechanisms
to
get
that
back
and
if
you
do
lose
it
we
can
recover
from
it
and
detect
all
the
bad
stuff
that
happened
when
somebody
did
have
your
password.
H
I
I
have
sort
of
a
broad
question,
you
sort
of
showed
a
few
different
ways
of
storing
the
signatures,
and
then
you
mentioned
in
passing
that
for
most
cases
the
transparency
log
is
enough
for
sort
of
storing
the
signature
for
an
artifact.
In
what
cases
is
it
not
enough?
Couldn't
for
basically
any
artifact,
I
just
take
it,
take
a
shot.
H
Look
it
up
in
the
transparency
list
and
get
all
the
signatures.
Why
would
I
ever
need
to
store
it
elsewhere,
yeah,
so.
B
There's
a
couple
questions
a
couple
things
there
and
I
think
you
probably
know
the
answers,
and
you
just
want
me
to
talk
about
it,
but
I'll
do
it
anyway.
Yeah.
If
you
some
reasons
it
might
not
be
enough.
If
you
don't
want
to
store
and
upload
your
stuff
to
our
transparency
log,
because
you're
signing
in
a
private
environment
doesn't
have
network
access
or
something
like
that,
you
can
come
up
with
your
own
way.
B
It's
kind
of
meta,
though,
if
you
don't
want
to
put
it
there,
then
it's
not
you
can't
rely
on
putting
it
there
searching
logs
is
also
not
the
fastest.
You
have
to
tell
the
log
and
go
through
each
index
if
you
want
to
do
that,
search
command,
we're
running
an
index
to
make
that
quicker
ourselves,
so
we're
indexing
those
three
keys
that
index
itself
is
not
verifiable.
So
when
you
run
that
search
command,
it's
pretty
subtle
the
the
problem
there.
When
you
run
that
search
command.
B
If
we
give
you
a
result,
you
know
that
result
is
correct
and
it's
in
the
log,
but
there
could
be
something
wrong
in
that
index
where
we
don't
give
you
all
the
results
or
we
don't
give
you
any
results.
But
if
you
do
get
a
result,
you
know
that
that's
on
the
record,
you
can't
rely
on
that
set
being
the
list
of
all
results,
though,
which
does
have
some
implications.
B
You
could
run
your
own
index,
though,
and
we've
got
some
examples
showing
how
to
do
that.
If
you
want-
and
there
are
ways
to
make
indexes
like
this
verifiable-
we
just
haven't
done
it.
Yet.
This
is
all
based
on
the
trillion
open
source,
transparency,
log
project
and
we're
using
transparent
logs.
They
also
have
things
like
transparent
maps
where
you
can
make
those
guarantees
quickly,
but
they
have
some
other
trade-offs.
We
have
to
work
through
there's
one
more
though,
which
is
like
you
said.
B
B
Powerstation
is
kind
of
a
weird
word.
What
I
think
of
it,
as
is
a
signature
with
about
an
artifact
with
a
bunch
of
other
metadata,
the
payload
that
we
actually
sign
in
cosine
for
a
container
image,
isn't
at
a
station
we're
not
signing
the
container
image
itself,
we're
signing
a
little
json
wrapper
with
a
reference
back
to
that
container
image,
and
then
some
random
claims
that
you
can
type
in.
B
So
the
hash
in
the
log
is
not
actually
the
container
anymore.
It's
the
hash
of
that
json.
So
if
you
have
a
container
and
didn't
have
that
funny
little
naming
scheme
to
find
those,
then
you
wouldn't
be
able
to
look
up
all
signatures
for
that
container
because
we
don't
store
the
whole
json.
We
only
store
the
hash
of
the
json
and
you
can't
reverse
the
hash
function.
B
So
we
have
some
other
cool
ideas
too
on
how
to
start,
storing
the
attestations
completely
in
a
way
that
we
can
index
and
do
all
sorts
of
cool
thinking
throughout
the
log.
But
that's
scary,
because
we
don't
want
to
allow
people
to
put
anything
they
want
in
the
log,
because
then
they
can
put
bad
things
in
the
log
and
we
can't
delete
it.
So
there's
some
ideas
on
storing
those
in
a
separate
content,
addressable
store
referenced
by
their
index,
so
we
can
blow
stuff
away
if
we
ever
have.
F
B
Yeah,
I'm
sure
we're
not
perfect.
The
only
things
we
store
in
the
log
right
now
are
signatures,
public
keys
and
hashes.
B
We
store
a
whole
bunch
of
different
types
of
public
keys
if
it's
just
like
an
ed25509
public
key,
it's
pretty
short
and
just
bytes,
and
then
we
do
verify
that
the
stuff
actually
signs
with
it.
So
you
can
come
up
with
some
way
to
encode
bad
stuff
in
the
number
of
bytes
that
we
allow,
then
yeah
that's
bad.
I
think
we
do
support
other
stuff
like
pgp
signatures,
which
are
always
sort
of
the
pgp
public.
Key
santiago
has
told
me
some
horror
stories
about
different
ways.
B
B
It
could
be
anything
right,
yeah
in
pgp.
You
can
do
some
crazy
stuff.
We
do
try
to
canonicalize
and
strip
stuff
out,
so
we're
just
looking
at
the
bytes
themselves,
but
I
don't
know
the
pgp
protocol
that
well
and
I'm
sure
we're
making
some
mistakes
we've
dropped
in
some
of
the
other
types
we
support
too.
F
B
Yeah,
I
don't
think
anybody
really
knows
the
answer
there.
You
can
do
the
same
thing
with
certificate
transparency
today
too,
because
they
store
entire
certificates
and
you
can
get
a
certificate
sign.
You
can
get
a
lot
of
stuff
in
an
x509
thing.
I
don't
know
how
they
handle
it.
B
I
think
kind
of
what
they
would
do
is
stop
stop
it
as
soon
as
you
know,
cut
off
the
log
at
that
point
and
start
a
new
log
from
there
without
the
thing
if
they
really
had
to
but
yeah
for
now
we're
not
making
any
promises
about
keeping
this
log
around
forever.
It's
just
a
sandbox
playground
and
we
do
want
to
get
a
little
stricter
there.
If
you
can
think
of
ideas
on
how
to
stick
stuff
in
the
log,
please
try
and
tell
us
and
we'll
try
to
fix
it.
F
How,
how
would
how
would
it
scale
to
somebody
doing
it,
for
example,
a
thousand
signatures
a
minute
whatever
how
fast,
how
large
is
it
going
to
get
and
how
easy
it's
going
to
be
search?
It
is
going
to
be
progressively
slower
and
slower.
B
Great
question:
basically
we're
not
inventing
anything
here,
we're
kind
of
just
copying
web
pki,
which
scales
pretty
well.
I'm
not
I've
looked
at
a
bunch
of
the
numbers.
I
haven't
done
any
other
tests
myself,
but
unless
encrypt
shared
you
know
the
cost
and
operation
of
their
transparency,
log
for
certificates
and
it,
it
all
seems
pretty
reasonable.
They
cut
off
once
a
year
and
start
again
with
a
log
of
zero.
So
you
know
which
one
to
look.
B
If
you
know
what
year
the
thing
happened
in,
but
their
bill
was
incredibly
reasonable
for
all
the
certificates
they've
issued
on
an
annual
basis,
and
they
just
did
something
like
200
million
in
a
day
a
couple
weeks
ago
and
wrote
a
whole
blog
post
about
it,
because
they
had
to
resign
things
a
bunch
of
different
ways
to
make
them
keep
working
with
old
versions
of
android
or
something
like
that.
So
200
million
a
day.
I
don't
know
what
that
comes
out
to
per
second,
but
that
stuff
all
works.
Fine
without
any
concerns.
F
E
There
is
in
so
certificate,
transparency
sits
on
top
of
trillium,
so
ct
is
called
a
personality
and
recourse
of
personality.
E
So
it's
a
sort
of
a
front-end
interpretation
of
of
trillium
and
they
got
a
project
called
or
some
code
rather
in
trillium
called
a
ct
hammer
which
they
use
for
load,
testing
and
that's
hit
thousands
of
seconds.
But
that's
dealing
with
certificates.
But
it's
not
too
different.
What
we
do
I
mean
we're
doing
the
same
sort
of
thing,
we're
validating
the
signing
and
then
cueing
the
leaf
for
entry
and
then
ensuring
that
it's
actually
entered
into
the
log.
B
D
Sure-
and
you
may
have
covered
this
already-
I'm
kind
of
just
diving
in
here,
but
you
showed
a
good
example
of
how
you
would
take
a
container
image
and
do
the
whole
signing
and
verification
process.
How
does
this
end
up
getting
applied
to
other
deliverable
formats
like
different
language,
ecosystems
and
that
sort
of
thing.
B
Yeah
we've
just
started
looking
into
this
ruby,
I
think,
is
actually
just
going
to
be
plug
and
play
almost
because
they
have
this
cool
way
to
stick
certificates
and
signatures
into
a
gem
and
then
configure
all
their
tooling
to
look
at
different
routes
and
do
verifications
against
that.
So
we
have
to
try
it,
but
they
already
have
this
in
place.
Java
does
as
well.