►
From YouTube: Sigstore: How We Started, Where We Are, Where We are Headed - Bob Callaway & Dan Lorenc
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Sigstore: How We Started, Where We Are, Where We are Headed - Bob Callaway, Red Hat & Dan Lorenc, Google
sigstore is a project under the Linux foundation to provide a non profit , public good software security cryptographic signing service. You can think of it like the 'Lets Encrypt' for software signing. If you have not heard of it yet, you certainly will soon. sigstore is used to protect kubernetes release container images and verify them directly in kubernetes release infrastructure. Many other communities are also in the process of looking at how they can implement sigstore (python, rubygems, wasm, maven). The sigstore community is made up of security experts from the communities such as TUF, Kubernetes, in-toto and engineers from Red Hat, Google, Smallstep, VMWare and many more.
A
B
A
Awesome
so
thanks
for
joining
us
right
before
lunch
today
and
delaying
your
lunch
a
little
bit
we're
gonna,
be
talking
about
sig
storage.
Sig
store
is
a
new
linux
foundation
project
to
help
improve
software
supply
chain
security
through
transparency,
we're
going
to
talk
a
little
bit
about
supply
chain
security,
but
this
is
one
of
like
100
talks
about
that
topic,
this
kubecon.
So
I
don't
think
we
need
to
spend
too
much
time
on
that
was
anybody
here
at
supply
chain
security
day
a
few
days
ago.
A
Okay,
a
lot
of
familiar
faces
here
in
the
back.
We're
gonna
be
going
over
the
history
of
state
store
where
it
started
a
few.
It
was
earlier
2021
but
yeah.
It
feels
like
a
couple
months,
but
it's
been
a
long
time
now.
Some
of
the
work
we've
done
along
the
way
and
we're
gonna
do
some
demos
showing
how
all
the
different
components
of
stick
store
fit
together
and
can
be
used
with
a
couple
real
world
examples
relevant
to
kubecon
we're
going
to
cover
some
of
the
architecture.
A
A
These
things
aren't
slowing
down.
I
think
the
eu
predicted
another
400
percent
increase
next
year.
Lots
of
attacks
are
happening.
This
is
very
scary,
but
thankfully
a
whole
bunch
of
projects.
A
whole
bunch
of
people
here
at
kubecon,
a
whole
bunch
of
people
in
the
cloud
native
ecosystem
are
working
on
helping
protect
open
source
and
protect
software
supply
chains.
A
So,
like
I
said,
cycler's
mission
statement
is
to
really
help
improve
software
supply
chain
transparency,
we're
doing
this
through
software
signing
and
provenance.
When
we
originally
started
the
sig
store
project,
we
took
a
lot
of
inspiration
from
let's
encrypt
how
many
people
here
use
let's
encrypt
every
day,
pretty
much
everybody
here.
If
anybody
remembers
what
the
internet
was
like
before,
let's
encrypt
most,
does
anybody
remember
that
no
a
little
bit
okay,
yeah,
nothing
was
encrypted.
Everything
was
insecure.
A
It
was
because
you
had
to
go:
buy
complicated,
x,
509
certificates
from
certificate
authorities.
You
had
to
pay
with
credit
cards,
it
was
expensive.
You
had
to
email
things
back
and
forth.
You
had
to
figure
out
what
folder
to
drop
them
in
in
your
server,
the
giant
pane,
and
so
let's
encrypt
came
along
and
thought
we
can
solve
this
with
automation.
We
can
solve
this
with
transparency
and
we
can
solve
this
with
open
source,
and
so,
let's
encrypt
pushed
the
new
standards.
A
They
built
a
whole
bunch
of
tooling
infrastructure
and
made
it
free,
easy
and
automatic
to
get
secure
certificates
for
your
website,
and
so
now
you
can
drop.
You
know
one
config
line
into
your
kubernetes
ammo
pretty
much
and
get
encrypted
traffic
over
the
internet
and,
as
a
result,
pretty
much
everything
is
encrypted.
Now
I
don't
remember
the
last
time
I
saw
one
of
those
red
x's
in
chrome
when
I
hit
a
website.
A
A
A
So
mistakes
happen.
The
point
of
transparency
allows
is
to
capture
those
mistakes
on
record,
so
you
can
find
them
later
recover
from
them
and
mitigate
from
the
bad
things
that
do
happen.
We
can't
prevent
mistakes
from
happening.
It's
about
getting
these
things
on
the
record,
so
you
can
detect
them
and
recover
from
them
quickly.
A
A
couple
years
later,
google
team
open
source
trillion,
which
is
a
database
that
uses
transparency
logs
as
a
core
primitive.
So
there
are
a
bunch
of
applications
of
trillion,
but
many
of
them
are
powering
the
exact
transparency
logs
that
are
used
when
you
request
certificates
in
your
browser.
Today,
shortly
after
that,
people
started
thinking
about
how
to
use
transparency
logs
for
things
other
than
internet
traffic
and
x509
certificates.
A
Mozilla
published
a
paper
called
binary.
Transparency
for
firefox
firefox
is
a
very
popular
web
browser.
It
was
at
the
time
and
mozilla
was
taking
it
seriously
five
or
six
years
ago
way
before
anybody
else
was,
and
they
were
working
on
some
techniques
to
use
transparency
logs
the
same
way
they
were
used
for
certificates
actually
protect
the
firefox
browser
update
process.
So
there's
a
white
paper
here
and
it
had
some
pretty
cool
ideas
on
how
to
do
this
by
piggybacking
on
the
existing
certificate
transparency
logs.
So
it
wouldn't
need
to
run
any
extra
operational
infrastructure.
A
A
So
brandon
started
on
a
couple
other
ideas
here
and
we
worked
with
him
to
start
a
more
general
transparency.
Log
called
recore.
That
was
really
the
start
of
the
six
store
project,
mid
2020
mid
to
early
2020..
So,
instead
of
piggybacking
on
the
existing
infrastructure,
we
ran
our
own
instances
of
trillion
as
a
public
benefit.
A
So
anybody
can
put
entries
in
here-
and
anybody
can
verify
entries
in
this
instance
of
trillion-
put
a
bunch
of
other
pieces
and
tools
together
around
march
of
2021,
so
some
tooling,
to
interact
with
that
transparency,
log
and
some
container
specific
tooling
as
well.
That
we'll
do
some
demos
of
later.
A
A
So
here's
some
stats
on
the
community,
the
activity
that
we've
seen
it's
really
been
amazing.
All
of
the
support
from
everybody
in
advancing
the
c
store
project
across
all
the
different
repositories
and
projects
we've
had.
Basically,
since
just
march
of
this
year,
there
have
been
820
commits
over
100
contributors
as
of
yesterday
20
different
organizations
or
companies
participating.
A
A
So
here's
the
very
complicated
spaghetti
and
wavy
drawing
that
I
talked
about
before
we're
going
to
break
this
down
into
the
three
different
pieces.
So
you
don't
need
to
understand
everything
right
now
and
with
some
demos
too,
I'm
going
to
do
some
demos
showing
how
to
assign
a
container
and
then
verify
that
container
all
the
way
back
to
the
source
code.
It
came
from
even
through
a
base
image.
A
A
All
right,
so
here's
the
first
demo,
let
me
get
out
of
here-
I've
got
a
couple
tabs
open.
First,
this
is
a
simple
go
application.
That's
in
the
github
repo
here.
This
is
a
basic
hello
world
go
application,
just
prints
hello
world.
It
is
containerized
using
a
tool
called
co,
so
anybody
use
co
to
build,
go
application,
cool,
co-fan
club
in
the
back,
so
this
runs
into
github
action.
It
builds
a
container
in
co
and
publishes
it
to
ghcr.io.
A
This
whole
process
is
signed
and
verified
using
ambient
credentials
that
are
present
in
the
github
action
itself.
Using
an
awesome,
github
sig
store
integration
that
we
work
together
on.
So
you
don't
need
any
secrets
in
here.
There
are
no
credentials.
This
is
all
short-term
stuff.
That's
handled
automatically
by
github.
A
One
of
the
cool
benefits
of
this
is
that
the
credentials
are
bound
to
the
exact
run
of
the
action
itself,
so
this
github
action
can
run
every
time.
Something
is
committed.
It
can
run
manually.
Each
run
will
get
its
own
unique
set
of
credentials
that
are
signed
by
github,
and
so
we
can
track
things
down
not
just
to
the
repo
they
came
from
to
the
exact
invocation
of
the
actions
we
can
figure
out
when
it
ran
exactly
which
commit
triggered
it.
Who
pushed
that
commitment?
A
A
Even
if
you
don't
know
that
you
use
it
you're,
probably
using
it,
because
our
friends
here
in
the
kubernetes
release
group
moved
the
kubernetes
images
over
to
distro
list
by
default.
So
if
you're
running
a
kubernetes
cluster,
you
probably
have
distrolus
in
there,
whether
you
know
about
it
or
not,
and
luckily
enough,
these
distrolus
images
are
also
built
and
signed
and
have
all
the
provenance
associated
with
these
builds
inside
of
the
recore
transparency
log.
A
A
A
We
can
see
that
it
was
signed
by
this
subject.
So
this
is
the
fancy.
Github
sig
store
direct
integration
that
I
was
talking
about
before.
So
we
can
see
that
this
is
a
token
that
was
signed
by
github
down
to
this
exact
github
repository
the
exact
action
inside
of
it,
and
it
ran
on
main-
and
this
is
the
exact
commit
that
it
ran
at.
A
A
Back
to
the
terminal,
now
we're
going
to
take
a
look
at
that
image
itself,
using
the
crane
tool
which
is
designed
for
working
with
registries,
we're
going
to
look
at
the
manifest
the
actual
oci
manifest
of
that
image
itself,
pipe
that
to
jq
as
well,
and
this
is
how
we're
going
to
find
the
base
image.
So
the
oci
specification
recently
added
a
standard
annotation
where
build
tools
can
place
the
base
image
that
an
image
was
built
from.
So
we
see
these
two
things
here,
so
this
was
built
from
the
distrolus
static
image
at
this
digest.
A
A
A
So
the
reason
there's
a
bunch
of
entries
here
is
because
the
distrolus
images
are
actually
reproducible,
there's
about
50
images,
50
variants
of
the
images
for
different
architectures
that
are
built
from
the
same
repo
and
they
all
rebuild
every
time
my
commit
is
pushed
since
it's
reproducible,
we
get
the
same
exact
digest
unless
something
actually
changed
for
that
specific
image.
So
here
we
actually
have
a
bunch
of
runs
reproducing
that
image
itself,
which
is
pretty
cool.
A
This
is
hitting
the
transparency
log,
a
couple
more
jq
incantations
and
we
can
see
a
lot
more
json
here,
but
this
is
the
exact
provenance.
So
the
providence
contains
information
about
how
the
image
was
built
and
this
is
captured
by
the
build
system.
So
this
is
an
automatic
build
system
using
tekton
cd.
A
A
But
why
stop
there?
We
can
actually
start
to
look
up
signatures
on
the
commits.
Do
people
sign
their
commits?
How
many
people
sign
commits
exactly
not
too
many,
because
it's
really
hard
to
do
and
it's
hard
to
look
up
the
signatures
and
actually
do
anything
with
them.
So
there's
some
cool
demos
and
hacks
that
we've
done
with
sigstor
we
can
actually
sign
commits
and
instead
of
putting
them
in
the
git
repository
you
can
put
those
signatures
in
the
transparency
log
as
well.
A
This
apart
a
bit,
we've
got
a
certificate,
we're
going
to
pipe
that
through
open
ssl,
and
we
should
see
a
subject.
Information
awesome-
and
that
is
my
gmail
address
here.
This
is
the
rest
of
the
certificate.
This
was
issued
by
the
certificate
authority
that
we
operate
for
free
as
part
of
the
sig
store
project,
so
my
personal
account
signed
the
commit
in
the
distrolus
repository
and
we
verified
that
backwards.
A
A
B
Oh
thanks
dan.
So,
as
dan
mentioned,
there's
many
moving
pieces
involved
here,
I'm
going
to
kind
of
do
a
deep
dive
into
three
of
those
components
and
the
first
one's
called
full
co,
and
so
this
is
the
certificate
authority
that
is
serving
as
a
couple
different
roles
but
number
one.
It's.
It
is
the
the
ca
that
you're
going
to
go
to
to
get
a
code
signing
certificate
and
it's
going
to
have
that
identity
information
that
dan
just
showed
off
with
his
gmail
address,
embedded
in
that
certificate.
B
So,
rather
than
just
having
the
bare
public
key
to
verify
the
signature
you're
actually
going
to
have
this
certificate
that
will
contain
extra
information
about
whose
identity
was
who
was
the
signer
who've?
Actually
vouched
for
that
signer
and
in
the
case
of
his
email
address,
it
was
actually
google,
but
we
also
do
integrations
with
spiffy
spire.
So
we
can
actually
have
the
workload
identity.
B
Actually,
you
know
be
recorded
in
the
certificate
as
well,
so
there's
kind
of
a
there's,
a
obviously
with
oidc
it's
built
on
top
of
oauth
and
so
there's
a
multi-legged
flow
that
happens
behind
the
scenes.
But
in
essence,
fulcio
is
issuing
certificates
and
it
actually
has
a
transparency
log
that
runs
as
a
part
of
its
deployment
as
well.
So
you
can
think
of
that
as
providing
key
transparency
to
say
hey
at
this
point
in
time
we
have
a
certificates
of
being
granted.
B
We
had
a
valid
identity,
token,
which
was
vouched
for
by
a
particular
provider,
and
all
of
that
is
now
stored
in
an
immutable
ledger.
So
we
can
walk
that
back
at
any
point
in
time
to
verify
the
validity
of
the
signature,
the
validity
of
all
the
time
stamps.
All
of
that
can
be
put
together
and
full
co
acts
as
that
authority
that
can
tie
all
this
together.
Now
we've
got
kind
of
two
different
modes.
B
One
is
you
know
if
anybody
here
has
ever
tried
to
manage
their
own
pgp
keys,
it's
not
the
easiest
thing
to
do
in
the
world,
and
I
think,
frankly,
that's
one
of
the
biggest
inhibitors
to
actually
people
signing
software
is
just
key
management's
too
darn
hard.
So
you
know
one
of
the
things
that
the
the
team
has
been
working
on
is
something
we
like
to
call
keyless
mode.
Now,
obviously,
there
are
still
keys
involved
because
we're
doing
crypto
but
think
of
these
more
as
ephemeral
keys.
B
So
if
I
have
a
ledger
that
stores
all
this
information-
and
I
can
walk
that
back
and
prove
that
these
things
existed
in
a
point
of
time-
I
actually
don't
need
to
store
a
key,
the
private
key
forever.
I
can
actually
just
throw
it
away
and
treat
it
as
an
ephemeral
object.
So
we
do
full
co
operates
in
both
modes.
If
you've
got
your
own
keys
and
you
want
to
use
them
great,
knock
yourself
out.
If
you
want
to
go
to
the
keyless
route,
we
can
support
that
as
well.
B
But
overall,
this
this
architecture
allows
us
to
bind
that
identity
without
having
to
have
a
key
signing
ceremony,
or
you
know,
like
a
little
party
and
build
your
web
of
trust.
That
way,
we're
actually
relying
on
on
these
primitives
that
exist
on
the
internet.
To
make
that
happen,
the
second
component
is
the
transparency
logger,
what
we
call
project
recore
as
dan
mentioned
this-
is
based
on
the
trillion
project
from
google
and
we've
developed
what
the
trillion
developers
would
call
a
personality.
B
One
thing
to
note
is
that
while
we
are
signing
artifacts
we're
signing
containers
or
blobs,
the
transparency
log
does
not
actually
store
the
blob
or
the
container
itself.
It
is
only
storing
the
digest
of
what
it
was
signed,
the
signature
itself
and
then
the
public
key
that
was
used
to
verify
that
signature
and
recore
actually
does
signature.
B
Verification
before
ever,
making
an
entry
into
a
log,
so
the
things
that
are
in
the
log
are
were
proven
to
be
have
valid
signatures
at
the
time
that
they
were
written
now
I
said
we
don't
store
content.
There
is
there's
two
exceptions
to
that
rule
number
one
recore
actually
also
acts
as
a
timestamp
authority,
because,
again
part
of
unwinding.
This
whole
route
of
trust
is
just
saying.
I
have
a
signed.
Artifact
here
is
great,
but
if
I
don't
know
when
it
was
signed
and
who
signed
it,
then
that's
not
enough.
B
B
So
when
dan
showed
kind
of
the
the
long
json
document
of
all
the
chains,
output
from
from
tecton
chains,
that
actually
is
persisted
in
the
log
as
well,
so
we're
not
trying
to
serve
as
a
new
content
store
for
the
internet
where
anything
that's
signed
is
downloaded
from
the
log.
That's
not
the
intent
here
at
all,
only
the
think
of
it
as
a
metadata
store
for
information
about
the
signing
in
provenance
there.
Another
thing
to
note
that
happens
with
certificate
transparency.
All
the
time
is,
there
are
actually
entities
that
monitor
these
logs.
B
That
will
sit
there
and
do
the
cryptographic
proofs
and
walk
that
merkle
tree
to
make
sure
that
nothing's
actually
been
changed.
We
expose
that
full
information
through
our
api
set.
We
actually
encourage
people
to
develop
monitors
against
our
public
logs.
So
again,
the
aim
of
this
is
to
not
just
have
a
central
source
of
truth
that
only
you
know
the
you
know
a
handful
of
developers
will
ultimately
maintain
and
control.
This
needs
to
be
open
and
transparent
in
order
for
people
to
trust
it.
B
So
we
need
monitors
to
play
that
role,
so
we
have
purdue
university,
a
shout
out
to
professor
santiago
from
there
he's
had
his
team
working
on
building
a
monitor
and
we're
encouraging
others
to
to
build
those
as
well,
and
then
finally,
dan
showed
off
the
the
verify
capability
of
cosign,
but
this
is
a
think
of
it
as
a
a
swiss
army
knife
that
allows
you
to
do
many
things
primarily
with
containers,
but
it
also
has
some
support
for
blobs
as
well.
This
is
actually
interacting
behind
the
scenes
with
either
key
management
providers.
B
So,
if
you've
used,
you
know
kms
from
aws
or
from
google.
This
actually
can
talk
to
their
apis
and
use
those
signing
systems.
In
addition
to
having
native
rsa
or
elliptic
curve
keys
on
your
desktop,
that'll
works
as
well,
and
that's
also
going
to
be
the
the
entity.
That's
contacting
and
communicating
with
the
oci
registry
to
actually
pull
down
the
container,
verify
the
digest,
compute
the
signature
and
go
back
and
store.
B
You
know
that
information
in
in
an
artifact
in
the
registry
as
well,
so
all
of
these
systems
are
talking
to
one
another.
But
one
point
I
want
you
to
take
away
is
that
this
is
fundamentally
modular
again
like
if
you're
using
aws,
you
can
use
the
key
management
service
from
there
if
you're
using
google.
These
things
are
very
interchangeable,
very
modular,
so
again
we're
not
trying
to
solve
this,
and
you
have
to
only
use
our
tool
and
nothing
else.
We
realize
that
that's
not
probably
the
most
effective
path
forward.
B
The
last
thing
it
does
is
once
it
signs
the
container.
In
this
case,
it's
actually
going
to
call
out
to
record
through
the
rest
api
and
make
the
entry
in
the
log
and
return
that
back
as
part
of
the
artifact
as
well
for
verifying
artifacts
in
a
transparency
log
there's
really
two
ways
to
do
it.
One
is
you
can
query
that
log
in
real
time?
That's
not
always
practical,
so
very
similar
to
what's
done
with
ssl
certificates.
Is
we
actually
can
create
what
we
call
a
sign
entry
timestamp?
B
This
is,
if
you're
familiar
with
certificate
stapling.
That
process
is
essentially
what
can
be
tacked
on
to
have
a
verification
or
a
cryptographic.
Proof
that
hey
this
ca
issued
this
certificate.
At
this
particular
point
in
time-
and
I
can
walk
that
all
the
way
back
without
having
to
make
several
round
trips
to
a
certificate
of
authority
as
you
open
your
browser,
so
we
do
the
same
exact
thing
in
cosine.
B
So
another
quick
demo
here,
I
know
again
another
spaghetti
diagram
with
lots
of
moving
parts,
but
I
do
want
to
kind
of
walk
it
through
the
through
the
steps
of
what
does
this
really
look
like
if
you're
not
using
our
nice
cli
or
you
know
in
many
ways
we're
using.
You
know
we're
standing
on
the
shoulders
of
giants
of
people
that
have
worked
on
ssl
and
many
other
technologies
in
the
past,
but
trying
to
tie
this
together
to
make
this.
You
know
this
process
as
simple
and
as
easy
as
we
can.
B
All
right,
so
the
first
thing
I'm
going
to
do
is
generate
an
ephemeral
key
pair,
so
I'll
just
use
the
elliptic
curve.
Dsa
algorithm
good
practice
is
to
not
show
your
private
key
to
the
public
internet,
so
I
won't
actually
echo
that
out
here,
but
if
you
wanted
to
see
it,
it
was
there.
I
will
show
you
the
public
key,
because,
obviously,
without
that
you're
not
going
to
be
able
to
verify
the
certificate
or
verify
the
signature
rather
so
now
we
have
this
public
private
key
pair.
That's
great!
B
It
has
nothing
to
do
with
my
identity.
It's
just
random.
You
know
bits
off
of
prime
numbers
that
have
been
written
to
the
disk.
Now
I
gotta
have
that
linkage
to
who
I
am
as
an
individual
to
be
able
to
tie
identity
to
this
overall
flow.
So
what
I'm
going
to
do
is
I'm
now
going
to
initiate
an
open
identity
flow
to
actually
get
an
open
identity?
B
B
And
so
what
we'll
do
here
is
we'll
just
start
that
open
identity
flow
and
when
I
hit
enter
here.
My
browser
is
going
to
pop
up,
and
it's
going
to
ask
me
to
log
in
if
you
ever
have
seen
one
of
these
like
log
into
this
website
using
google
facebook,
whatever
same
exact
thing,
is
happening
under
the
covers
here,
so
in
this
case
I'll
choose
to
log
in
with
google.
B
I
I'm
logged
in
with
two
different
accounts
here,
one
from
red
hat,
where
I
work
and
my
own
personal
gmail
in
this
case
I'll
sign
it
with
my
red
hat
account.
I
click
on
that.
It
says
cool
successful,
come
back
to
the
command
line,
let's
actually
look
at
what
is
inside
of
an
open
identity
token.
So
this
is
a
a
json
web
token
or
jot,
as
people
will
informally
refer
to
it.
As
so.
The
contents
of
a
jot
is
this
json
object.
That's
signed,
you've
got
some
information
in
the
header
about
the
algorithm.
B
That's
used
to
sign
that
content.
You've
got
a
payload
content
here
inside
this
payload
you've
got
an
actual
url
for
the
issuer.
That
has
generated
this
token.
In
this
case,
since
we're
using
a
federated
identity
provider,
this
is
actually
the
sig
store.
Oauth
is
the
issuer,
but
again
this
came
from
google,
since
it
was
a
federated
scenario
and
again
it's
got
my
email
address
inside
of
it
here
as
well.
So
now
I've
got
some
ad.
B
B
B
We
have
a
all
of
our
stuff
is
written
through
open
api,
so
our
our
specs
are
totally
open.
We
have
swagger
interfaces
for
all
of
this
as
well.
So
if
you're
curious
to
see
what
the
interface
actually
looks
like
at
a
http
level,
all
of
that's
documented
on
our
on
our
github
site,
but
since
again
we're
doing
this
through
curl
and
not
nice
uis
we're
now
going
to
type
a
very
long
curl
command
with
inline
json,
setting
content
type
and
accept
headers.
B
I
would
highly
recommend
you
don't
do
this
if
you
don't
have
to
we'll
keep
going
and
now
I'm
finally
done-
and
I
can
type
perfectly
if
you
guys-
haven't
noticed
no
mistakes
as
I
go
forward
here
so
now,
I've
called
out
to
folsio
everything's
good
to
go.
Let's
look
at
the
the
certificate
that
came
back.
You
know
what
I
talked
too
long
and
the
token
is
wasn't
valid
long
enough.
So
the
joys
of
internet
demos-
and
we
can
recreate
this
very
quickly.
B
B
Gotten
at
this
all
right
now,
let's
look
at
the
certificate
coming
back
all
right,
so
now
I
see
the
actual
code
signing
certificate
chain,
that's
coming
back
from
folso,
very
similar
to
what
dan
showed
actually
coming
out
of
the
log.
Because
again
this
is
going
to
be
the
public
key
that
you're
going
to
pass
along
to
people,
not
just
the
actual
ec
bits,
but
actually
the
the
x
500
certificate
that
has
the
identity
information
in
it
as
well.
B
So
we
have
an
issuer
here
of
six
store
and
we
have
my
red
hat
email
address
that
was
attested
to
by
google
listed
in
the
certificate.
So
the
next
thing
I'm
going
to
do
really
quick.
Is
I'm
just
going
to
make
sure
that
I
can
actually
verify
this
that
signed
string?
That's
my
email
address
using
this
code
signing
certificate,
because
if
I
can't
then
something's
wrong,
because
the
public
key
should
be
able
to
be
used
that
comes
back
and
says
it's
verified.
B
Okay,
so
we're
all
good
there
and
just
to
be
triple
sure,
I'll
extract
the
public
key
bits
out
of
the
code
signing
certificate
and
just
do
a
quick
diff
and
the
echo
does
not
return,
which
means
those
binary
bits
are
totally
equivalent.
So
now
I've
got
a
code
signing
certificate
from
full
co.
I've
still
got
my
key
pair
sitting
on
my
laptop.
What
do
I
need
to
do
next?
B
Well,
I
need
something
to
sign,
so,
let's
generate
something
to
sign,
we'll
just
throw
128
random
bits
into
a
file
right
for
this
case,
we'll
just
keep
it
simple
and
short
and
sweet.
So
next
thing
we'll
do
is
we'll
actually
call
out
to
open
ssl,
ask
it
to
actually
sign
it
using
our
private
key
and
we'll
store
that
that
signature
in
a
detached
file,
so
we're
not
using
pkcs
bundles,
we'll
just
have
this
totally
separate
into
a
into
a
separate
file.
B
That's
super
quick
and
just
to
make
sure
that
everything
went
well,
we'll
ask
it
to
verify
using
our
public
key
that
that
was
all
good
and
it
says
yes,
we're
all
good
next
thing.
We'll
do
is
we'll
generate
a
timestamp,
and
so
openssl
has
a
built-in
utility
to
do
this.
So
what
we'll
do
is
we'll
use
the
actual
digi,
the
detached
signature
and
we'll
we'll
attest
to
hey
at
this
particular
point
in
time.
B
This
signature
was
created
so
we'll
pass
that
data
in
and
we
will
create
a
binary
artifact
that
needs
to
get
sent
to
the
record
timestamp
service.
We'll
actually
then
send
that
curl
over
to
that
rest.
Api,
just
putting
that
content
in
the
payload
hit
enter.
That
takes
a
second
to
come
back,
and
the
next
thing
we'll
do
is
we'll
need
to
pull
down
the
full
certificate
chain
to
be
able
to
verify
the
signature
on
the
timestamp
itself.
So
we'll
again
call
that
over
the
rest,
api
that
works.
B
Pretty
quick
and
the
next
thing
we
can
do
is
call
out
over
using
the
openssl
tool
to
verify
the
timestamp
signature.
So
again,
like
I'm
most
of
the
way
through
my
demo-
and
you
guys
are
probably
all
like
man-
that's
a
lot
of
commands
right
like
this
is
part
of
why
nobody's
signing
anything,
because
this
is
very
complicated
in
the
sequence.
Here,
it's
easy
to
mess
it
up
and
if
you
don't
have
the
type
my
typing
skills,
it's
easy
to
make
mistakes.
B
So
again,
part
of
echoing
this,
as
I
go
through
the
rest
is
again.
What
we're
trying
to
do
here
is
really
simplify
this
and
make
sure
that
this
is
very
addressable
to
the
developers
of
any
skill
set
to
where,
ideally,
if
we're
doing
this,
the
right
way,
all
of
this
is
just
hidden
behind
the
scenes
and
I
don't
have
to
think
about
supply
chain
providence
anymore.
I
mean.
Hopefully
you
know
we
don't
have
these
attacks
anymore.
B
We've
built
this
capability
into
our
infrastructure
and
we
can
go
back
to
writing
code,
which
is
all
what
we
like
to
do
anyway.
So
we'll
verify
this
timestamp
really
fast.
Openssl
says
that's
good.
We'll
also,
then,
just
quickly
check
to
make
sure
that
the
timestamp
that
we
got
back
from
recore
was
actually
in
the
valid
period
for
the
code
signing
certificate.
So
if
I
scroll
back
up
here,
I
have
a
20
minute
window,
at
least
that's
how
we
have
it
coded
up
right
now
on
today,
between
1928
and
1948
and
at
1930.
B
I
signed
this
so
for
people
to
go
back
and
walk
to
make
sure.
Did
this
person
have
possession
of
this
key
during
the
valid
the
validity
period
of
the
certificate?
I
now
have
an
artifact
that
can
prove
that
cryptographically
as
well.
So
now
I've
got
all
these
pieces.
I
need
to
put
them
in
the
transparency
log,
so
I
can
go
back
and
refer
to
that
in
the
future.
So,
as
I
mentioned,
record's
got
a
rest.
Api.
That's
well
documented.
Again,
writing
json
on
the
command
line
is
really
painful.
B
So
once
I
call
out
to
recore,
I
say
cool,
let's
actually
look
at
the
output.
That's
come
back
and
with
a
little
bit
of
jq
trickery,
I
can
now
look
at
the
actual
object
that
comes
out.
It's
got
a
unique
identifier.
This
is
the
merkle
tree
leaf
hash
for
those
of
you
who
are
merkle
tree
fans,
and
then
we
have
the
actual
content
that's
stored.
Here,
we've
got
a
version.
We've
got
a
kind
if
you,
if
you've
ever
seen
the
typical
you
know
specs
for
using
a
crd
in
coupe.
B
This
looks
and
feels
much
like
everything
else
that
is
being
done
these
days
in
cloud
native,
we've
got
the
hash,
we've
got
the
signature,
we've
got
the
key
and
then
finally,
as
we
mentioned,
as
I
mentioned
before,
we've
got
this
artifact
that
we
can
kind
of
staple
on
for
offline
verification.
That's
what
the
signed
entry
timestamp!
That's
this
base64
encoded
stuff,
now
cool!
Now
it's
in
the
transparency
log
we're
all
good.
The
last
thing
I'm
going
to
show
is
the
inclusion
proof.
B
So
I
know
that
was
a
ton
and
we'll
actually
post
all
the
gist
for
this
as
well
on
a
blog
post,
we'll
publish
after
the
event,
but
so,
if
you
guys
actually
want
to
manually
run
through
those
commands,
you
can
be
more
than
happy
to
do
that.
So
then
one
one
quick
wrap-up
chart.
I
know
we're
about
at
a
time
in
terms
of
what's
next
in
the
six
store
community
as
dan
showed
you
with
the
the
stars
and
the
commit
track,
I
mean
it.
B
We
have
a
an
amazing
community
that
are
generating
prs
left
and
right,
but
if
I
were
to
break
down
kind
of
our
road
map
in
three
different
areas
signing
stuff,
we
got
to
sign
more
things
in
order
for
the
supply
chain
to
be
secure,
so
we're
going
to
continue
to
work
in
the
container
ecosystem,
we're
going
to
continue
to
work
with.
Where
do
you
put
containers
right?
You
put
it
in
cube,
you
put
it
in
docker,
you
put
it
in
pod
man
right.
B
B
So
that's
where
the
role
of
policy
ultimately
comes
in,
so
we're
working
with
a
variety
of
upstream
communities
that
are,
you
know,
so
you
shout
out
to
the
opa
folks
and
the
caverno
folks
and
many
others
that
I'm
forgetting
but
we're
working
with
with
many
of
those
teams
to
actually
prove
out
that
we
have
that
tie
back
to
policy
and
then
finally,
we
are
running
this
as
a
public
good
service.
We
dan
alluded
to.
We
want
to
be
the
let's
encrypt
for
code.
B
Signing
and
part
of
that
is
actually
standing
up
this
infrastructure
so
that
people
can
use
it
without
cost.
So
we're
trying
to
get
these
services
robust
and
hardened
and
audited
to
where
we
can
be
confident
that
what
we're
putting
into
production
is
something
that
the
community
can
ultimately
trust
and
then
stand
up.
These
additional
monitors
to
where
people
can
verify
that
and
keep
us
honest
as
we
go
forward.
So
with
that.