►
From YouTube: Sigstore: Using Transparent Digital Signatures to Help Secure the Software SupplyChain- Bob Callaway
Description
Sigstore: Using Transparent Digital Signatures to Help Secure the Software Supply Chain: Bob Callaway, Tech Lead & Manager, Google Open Source Security Team, Google
---
Open source software is pervasive in data centers, consumer devices, and applications. Securing open source supply chains requires a combination of automated tooling, best practices, education, and collaboration.
Join the growing list of organizations supporting the advancement of securing open source technology and funding the development and adoption of OpenSSF initiatives. https://openssf.org/
A
Well,
thanks
for
your
patience
and,
as
was
often
said,
Teamwork
Makes
the
Dream
work.
So
thanks
for
the
help
to
the
other
folks
here
so
as
crop
said,
I'm
Bob,
Callaway
I'm,
the
chair
of
the
attack,
as
Brian
mentioned,
as
well
as
a
tech
leader
manager
at
Google.
A
Given
the
time
here,
I'll,
unfortunately,
with
not
being
able
to
use
my
laptop
I
won't
be
able
to
show
you
my
demo
that
I
had
prepared
but
we'll
go
through
the
slides
anyway,
but
happy
to
show
it
to
folks
afterwards
as
well.
So
I
won't
bore
you
with
a
a
ton
of
information
about
why
we're
all
here.
Hopefully
it's
glaringly
obvious
with
the
intro
talks
as
well
as
just
what's
been
going
on
in
the
broader
Market
supply
chain.
A
Security
is
super
critical
to
not
only
open
source
but
the
overall
software
industry
at
large,
and
so,
if
you
think
about
you,
know
the
sonotype
reports
that
are
great,
that
have
great
information
in
them
and
people
love
to
quote
them
point
that
attacks
have
been
going
up
into
the
right,
and
these
are
not
the
types
of
up
and
to
the
right
charts.
You
want
to
present
to
your
execs.
These
are.
A
These
are
bad
right,
but
solarwinds
code
of
again
not
trying
to
throw
shade
at
anybody
doing
this
stuff
is
hard,
and,
unfortunately,
attackers
are
taking
advantage
of
it
and
kind
of
the
last
Point
here
is
there's,
unfortunately,
probably
more
to
come.
But
that's
why
we're
here
today
and
the
open
ssf
is
trying
to
do
what
we
can
to
solve
this
so
in
the
in
the
market.
If
you
guys
read
blogs
or
look
at
Twitter
or
are
trying
to
figure
out,
how
do
you
actually
secure
your
supply
chain?
A
You'll
hear
a
lot
about
the
terms
on
the
right,
like
a
s.
Bombs
play
a
role
in
this.
How
do
I
do
salsa?
How
do
I
generate
build
provenance
I've
got
these
artifacts
themselves.
How
do
I,
secure
them
and
digital
signatures
often
come
up
as
a
technique
to
verify
the
integrity
and
the
authenticity
of
things
that
we
look
at,
which
is
totally
true.
A
Digital
signatures
have
been
around
for
decades,
but
they're
not
really
widely
used
across,
certainly
the
open
source
landscape,
but
also
the
a
fair
bit
of
the
commercial
landscape
as
well,
and,
if
you
think
about.
Why
is
that
the
case?
It's
not
necessarily
that
we
need
new
crypto
outside
of
post
Quantum
concern
turns,
but
it's
really
around
the
usability
of
the
tools
and
many
of
the
other
problems
that
are
associated
with
using
digital
signatures,
namely
Key
Management.
A
What
I'll
talk
about
here
in
a
second
but
just
to
think
about
this
in
the
context
of
in
order
to
solve
your
supply
chain?
Not
only
do
you
have
to
generate
all
of
these
things,
you
have
to
figure
out
how
do
I
sign
them?
How
do
I
transmit
them
securely
to
the
consumers
of
what
I'm
building
and
then
figure
out?
How
do
I
tie
that
all
together
and
that's
a
really
challenging
problem
statement?
In
addition
to
that,
I
mentioned
the
the
key
material.
That's
associated
the
digital
signature.
A
You
need
a
it's
based
on
public
key
cryptography
right,
so
I
need
a
private
key
that
I
keep
to
myself
and
I
need
a
public
key.
That
I
then
distribute
out
to
any
of
the
consumers
of
of
the
thing
that
I've
signed
well
Distributing
that
artifact
you'd
think,
oh,
that
should
be
pretty
easy.
Well
turns
out
it's
not
as
straightforward
off
it,
as
you
might
think,
and
we've
seen
Innovation
coming
out
of
the
pgp
community
several
decades
ago
to
try
to
solve
this
with
key
servers.
A
We've
seen
a
key
material
posted
alongside
you
know,
artifacts
on
a
website
server
and
allow
people
to
download
at
the
same
time
those
are
all
approaches
they
have
drawbacks
to
them
and
even
figuring
out
how
do
I
store
the
private
key
that
pairs
with
that
public
key
that
I
might
distribute
is
also
hard
if
I
just
put
it
on
my
laptop
here
that
didn't
work.
Well,
what
happens
if
that
gets
stolen
right,
all
of
a
sudden,
now
I've
been
compromised.
A
Somebody
may
have
that
private
key
and
maybe
using
it
to
act
as
if
they're
they're
me
they're,
taking
over
my
digital
identity,
to
make
assertions
about
the
Integrity
of
of
artifacts
that
I
might
be
generating
so
figuring
out.
How
do
I
store
that
you
know
there
are
UB
keys.
There
are
hsms.
There
are
different
approaches
to
this,
but
fundamentally,
when
you
again
going
back
to
all
of
these
documents
and
all
the
user
experience
and
the
tooling
around
this
leaves
quite
a
bit
to
be
desired
and
with
Sig
store.
A
We
really
wanted
to
take
a
step
back
and
really
look
at
this
problem
holistically
around
digital
signatures,
not
invent
new
crypto
algorithms,
but
really
take
a
look
at
some
of
these
other
challenges.
Around
developer,
experience,
user
experience
and
say
how
can
we
make
this
fundamentally
better,
but
as
we
got
into
that,
and
we
start
to
look
at
a
lot
of
the
proliferation
of
things
like
containers
and
kubernetes,
you
know
you
start
to
break
this
apart.
You
even
go
like
the
trivial
example
of
Bob
signing
something
that
you
put
onto
the
web.
A
Who
actually
operates
the
repository
and
maintains
the
credentials
so
when
I
say
identity
all
of
a
sudden,
it
becomes
really
complicated,
because
now
I
have
multiple
actors
that
I
need
to
Ultimate
I
need
to
understand
their
relationships
to
one
another
and
I
need
to
know
how
do
I
empirically
verify
that
they're
doing
what
they
should
be
doing
in
the
context
of
you
know
signing
all
of
this
content.
That's
out
there.
So,
ultimately,
when
you
look
at
this,
it's
it's
super
complicated.
A
The
good
news
is
is
that
the
industry
has
been
evolving
in
multiple
different
threads
over
the
past.
You
know
decade
plus,
and
so
some
of
the
things
you
see
here
called
out
in
the
in
the
circles
are
just
examples
of
of
technical
innovations
that
are
largely
being
driven
out
of
Open
Source.
That
Sig
store
has
gone
and
looked
at
evaluated
and
said:
hey.
A
There
might
be
a
way
that
we
can
actually
integrate
these
different
technology
pieces
together
to
fundamentally
reinvent
the
user
experience
and
the
developer
experience
around
digital
signatures,
and
so
when
we
look
at
everything
from
that
last
slide,
where
I
have
all
of
those
containers
with
all
of
those
identities.
How
about?
If
I,
actually
just
remove
the
human
element
completely
and
I
could
actually
identify
the
workload
itself,
give
it
a
cryptographic
identity
that
I
could
then
track
against
taking
humans.
A
Out
of
the
equation,
obviously
has
a
lot
of
benefits
from
a
privacy
perspective,
so
there's
some
goodness
there
there's
been
a
lot
of
innovation
at
the
hardware
layer
of
putting
TPMS
and
computers
and
having
the
ability
to
remotely
attest
to
the
state
of
a
server.
That's
operating
a
particular
workload.
So
there's
some
goodness
there
certificate
transparency,
a
project
started
out
in
the
open,
Google
and
cloudflare,
and
many
other
companies
have
contributed
to.
This
has
done
a
lot
to
actually
bring
light
to
how
TLS
certificates
are
issued
for
the
web.
A
So,
if
you
think
about
your
popular
next-gen
car,
that
has
a
ton
of
software,
that's
being
downloaded
and
updates
are
done
over
the
air,
we
need
to
figure
out.
How
do
we
update
that
car
securely?
You
can
think
of
a
lot
of
Doomsday
scenarios
where
an
update
might
go
bad
and
catastrophic
things
might
occur
in
relation
to
that.
So
when
we
look
at
the
market
again,
don't
need
new
crypto,
but
we
have
all
of
these
new
pieces
and
with
sigstore.
A
And
really
we
took
inspiration
from
let's
encrypt,
who
did
an
amazing
job
in
helping
to
proliferate
the
use
of
encryption
across
web
traffic
and
the
way
that
they
did
that
was
through
what
I
would
argue
is
three
main
principles:
one
they
recognize
that
they
needed
to
issue
certificates
in
a
completely
frictionless
way,
the
the
existing
certificate
Authority
Market
that
was
out
there.
You
could
get
a
certificate.
It
was
expensive.
A
A
I
had
to
wait
weeks
in
in
some
circumstances
in
order
to
get
a
certificate
pushed
back,
and
so
what
the
folks
at
let's
encrypt
did
was
really
try
to
re-envision
the
TLs
market
and
say
how
do
I
make
it
super
easy
to
get
a
cert?
A
So
there's
a
lot
of
benefits
that
came
that
let's
encrypt
brought-
and
we
said
hey
if
we
could
do
for
software
signing
what
let's
encrypt
did
for
TLS,
the
world
would
probably
be
a
lot
better
place.
So
that's
really
what
was
our
inspiration
here,
and
so
let
me
go
next
and
say
like
what
is
Sig
store,
the
easiest
way
to
think
about
it
is
it's!
It's
not
just
one
thing:
it's
an
umbrella
term
that
describes
a
set
of
projects,
a
set
of
services,
as
well
as
a
community.
A
That's
working
on
both
of
these
different
groups
of
things.
We've
got
a
couple
different
projects
that
I'll
go
through
in
a
little
bit
of
detail.
We
have
several
services
that
we
are
running
as
public
good
instances.
They
are
again
in
the
spirit
of
let's
encrypt
they're,
free,
easy
to
use,
automatable
and
Community
operated,
which
is
another
interesting
twist
to
this,
because
if
we
were
trying
to
set
up
a
centralized
trust
route
that
only
one
company,
whether
it
be
Google
or
Intel
or
anybody
else,
people
would
be
rightfully
skeptical
around.
How
does
that
model
actually
scale?
A
Why
should
I
trust
one
corporate
entity?
So
we
knew
from
the
very
early
on
that
we
needed
to
do
this
in
a
fundamentally
Community
Driven
way
and
be
very
neutral
about
how
we
actually
operate
these
services.
So
we've
taken
that
that
spirit
and
actually
built
out
a
cross
vendor
operations
team
with
sres.
We
have
an
on-call
system
that
we're
building
out
we're
trying
to
get
to
the
formalizing
slos.
A
Hopefully,
we'll
have
some
big
announcements
coming
later
this
year
around
that,
but
we're
really
trying
to
again
do
this
in
the
community
way,
because
we
think
that
again,
open
source
will
shed
light
on
this
problem.
We'll
bring
be
able
to
bring
transparency
to
this
problem
space,
but
we'll
do
it
together
as
a
community
and
learn
a
lot
and
ultimately
hope
to
raise
the
tide
for
everybody
else
as
a
part
of
this
and
what
we've
seen
in
the
community
after
joining
the
open
ssf,
this
project
has
just
exploded.
A
We're
now
ranked
in
the
top
25
projects
across
the
entire
Tia
of
the
Linux
Foundation,
which
again,
we've
haven't
even
been
alive
really
for
two
years
yet
and
we're
getting
very
close
to
the
two-year
birthday.
So
it's
been
a
pretty
aggressive
set
of
folks
that
have
joined
in
donated
code
donated
their
their
ideas
and
input,
and
we
have
a
set
of
you
know
a
very
Vibrant
Community.
We've
got
several
cigs
that
exist,
so
I
would
do
my
final
call
to
action.
A
I'll
encourage
you
to
go,
take
a
look
and
if
there's
an
area
that
you
would
love
to
get
engaged
with,
certainly
we
would
love
to
have
your
love
to
have
you
as
part
of
the
community.
So
where
again,
I
talk
about
six
door,
it's
a
set
of
tools.
It's
a
set
of
clients.
It's
all
these
different
things.
Okay,
cool,
we'll
go
into
detail
in
terms
of
all
the
minutia
and
the
crypto
and
everything
behind
it
in
a
second,
but
where
is
it
being
used
today
and
so
I've?
A
Given
you
a
little
bit
of
a
snapshot
as
to
different
parts
of
the
ecosystem
that
are
coming
in
independently
evaluating
what
is
going
on
in
the
state
store
community
saying
hey,
does
this
make
sense
to
integrate
in
with
what's
going
on
with
kubernetes
or
what's
going
on
with
python,
the
maven
Central
folks
are
taking
a
very
deep
look
at
figuring
out.
How
do
they
integrated
with
their
package
repository?
A
We
have
the
npm
community
that
recently
posted
a
request
for
comments
to
say,
let's
evaluate
how
we
could
use
Sig
store
as
the
fundamental
signing
and
verification
Logic
for
the
entirety
of
what's
served
out
through
npm.
So
these
are
not
onesie
2z
projects.
These
are
major
communities
that
serve
a
massive
amount
of
substrate
for
the
the
open
source
ecosystem
at
large
they're
engaged
in
looking
at
what
we're
doing
with
Sig
store.
A
We
also
see
a
number
of
corporate
entities
productizing
the
work
so
I
mentioned
here,
red
hat
nirmada
or
the
this
is
the
company
behind
caverno,
as
well
as
VMware,
are
just
three
examples
of
different
companies
that
have
productized
capabilities
out
of
Sig
store
so
again
tons
of
stuff
going
on
in
terms
of
both
corporate
entities,
other
other
open
source
ecosystems
all
coming
together
to
to
figure
out.
How
can
we
really
use
digital
signatures
in
a
much
more
way?
A
So
let
me
quickly
go
into
the
architecture
and
unfortunately,
with
the
laptop
snafu
I'm
not
going
to
be
able
to
show
the
demo,
which
would
make
it
I
think
a
fair
bit
clearer,
but
for
all
the
projects
and
things
that
we
have,
it
really
comes
down
to
a
couple
principles.
Number
one.
Like
we
learned
from
certificate
transparency.
We
need
a.
A
So
you
can't
modify
any
single
node
that
exists
in
the
tree
without
altering
the
computation
of
the
entire
tree
itself.
So
it
gives
you
some
assurance
that
this
Ledger
or
this
this
transparency
log
as
it's
called,
is
has
fundamental
properties
being
that
the
entries
that
are
already
there
can't
be
edited
I
could
only
append
to
the
last.
A
You
know
the
last
note
of
the
tree,
and
anybody
who
has
access
to
the
log
can
independently
compute
the
Integrity
of
the
log
so
you're
not
having
to
trust
me
to
say
yeah
I
didn't
edit
anything
you
just
take
my
word.
It's
good.
You
could
actually
independently
go
through
and
make
sure
that
you
see
the
exact
same
thing
that
everybody
else
sees
and
that
it's
it's
it
isn't
not
only
valid,
but
its
Integrity
has
not
been
violated.
So
that's
our
recore
project
that
holds
that
information
about
digital
signatures
at
large.
A
Now
again,
any
of
those
items
that
I
listed
in
my
earlier
chart,
s-bombs
artifacts
themselves,
build
provenance
statements,
get
commit
information,
anything
that
you
can
sign.
You
can
ultimately
wrap
a
digital
signature
around
and
upload
the
information
about
that
signature
into
recore.
One
thing
I
want
to
call
out,
though,
is
that
we're
not
with
with
very
few
exceptions
around
some
attestations,
we're
not
actually
storing
the
content
in
itself
we're
not
trying
to
distribute
software
across
the
entire
internet.
A
We're
trying
to
store
metadata
about
this
digital
signature
surrounding
that
piece
of
software
that
artifact
or
that
document.
So
we're
not
trying
to
be
a
concert,
content,
distribution
mechanism
for
the
net,
we're
simply
just
saying
we
want
to
make
sure
that
people
have
a
shared
view
as
to
the
the
again
the
the
digital
signature
metadata.
That's
around
it,
the
other
thing
that
let's
encrypt,
did
was
they've
made.
A
It
really
really
easy
to
get
a
certificate
and
in
the
digital
signature
landscape,
it's
a
slightly
different
type
of
certificate,
in
that
it's
meant
for
code
signing
rather
than
for
web
traffic
and
encryption.
So
we
need
to
actually
have
a
what's
called
a
certificate.
Authority
be
able
to
issue
code
signing
certificates,
and
whenever
you
issue
a
certificate,
you
fundamentally
have
to
marry
key
material.
The
public
key
that's
used
as
well
as
the
identity
of
who
holds
the
possession
of
the
private
key
that
is
paired
up
with
that
public
key.
A
The
code
signing
certificate
contains
that
pairing
and
allows
people
to
understand
the
relationship
for
who
signed
what
artifact,
with
which
key,
and
so
the
code
signing
search
certificate.
Authority
that
we
have
within
Sig
store
is
called
fulsio,
and
so
simply
it
marries
in
identity
information
that
is
actually
represented
in
the
open.
Id
connect,
identity,
token
format.
This
is
the
same
exact
format
if
you've
gone
to
a
website
and
you've
said:
hey
I
want
to
log
in
with
Google
log
in
with
Facebook
log,
in
with
whatever
provider.
A
A
Is
this
concept
of
workload,
identity
and
it's
been
really
nice
to
see
the
cloud
providers
as
well
as
a
broader
security,
Market,
really
rally
to
reusing
this
openid
connect,
identity,
token
format
to
represent
the
identity
of
workloads,
so
in
the
same
way
that
we
can
support
developers
going
and
getting
a
token
from
Facebook
or
Google
or
Microsoft.
We
can
also
support
going
to
a
gcp
workload,
identity
provider
or
an
AWS
identity
provider,
getting
a
same
token
and
putting
that
information
into
the
code
signing
certificate
so
instead
of
saying
Joe
signed.
A
This
document
is
actually
this
CI
workflow
running
on
GitHub
actions
signed
this
document,
which
again
you
can
start
to
put
other
information
with
which
is
which
run
on
which
repo
actually
generated
this
signature.
What
git
commit
was
associated
with
what
triggered
this
run.
To
start
on
this
CI
system,
I
can
now
actually
have
a
much
richer
set
of
information.
That's
cryptographically,
cryptographically,
secure,
issued
in
within
a
code
signing
certificate
from
folsio
that
then
anybody
who
comes
along
and
looks
at
my
artifact
can
see.
A
This
thing
was
signed
by
the
appropriate
GitHub
action
that
was
managed
by
the
community
associated
with
this
artifact.
Not
some
random
email
address
on
the
internet,
so
we
have
the
flexibility
to
adapt
to
different
models,
and
projects
are
at
different
points
in
their
life
cycle.
Some
projects
still
want
to
be
able
to
associate
to
humans
that
are
the
release.
A
We
don't
want
to
actually
trust
that
there's
a
human
in
the
loop
here
at
all,
there's
too
many
risks
of
tampering
in
that
model,
so
we
actually
support
driving
that
that
flow
again
through
the
workload
identity
construct
and
then
finally,
to
pull
all
of
this
together
to
address
this
usability
challenge
with
pgp
and
openssl,
and
if
you've
ever
used
those
tools,
you're,
probably
nodding
along
with
me,
they're,
not
the
most
usable
things
in
the
world.
A
A
We
saw
that
that
was
a
huge
opportunity
to
try
to
pull
digital
signatures
into
that
ecosystem,
and
so
we
built
cosine
to
be
able
to
take
sign-in
containers
store
that
information
inside
of
an
oci
compliant
registry,
and
that
project
has
gone
off
like
wildfire
and
it's
starting
to
be
widely
used
across
much
of
the
container
ecosystem.
But
in
addition
to
that,
it's
written
and
go
it's
a
80.
Something
Meg
binary
at
this
point
like
all
go:
binaries
tend
to
be
a
little
bit
beefier
than
others.
A
If
you
go
to
the
Java
community
and
you
go,
we
have
the
software
signing
solution
for
you
and
it
involves
a
90,
Meg
golang
binary.
You
can
imagine
how
that
conversation
goes.
It
doesn't
go
very
far
and
they
go
thanks.
Cool
idea
next,
please!
So
what
we
recognize
is
we
started
engaging
with
these
communities.
A
Is
we
need
to
meet
people
where
they're
at
we
need
to
meet
the
Java
Community,
where
they're
at
the
rust
Community,
where
they're
at
and
so
we've
built
out
a
set
of
ecosystem,
specific
clients
that
all
implement
the
same
fundamental
logic
of
how
to
go?
Get
a
certificate?
How
to
put
that
certificate
into
the
log
how
to
actually
sign
the
artifact,
how
to
publish
it
to
the
distribution
system
for
that
ecosystem,
but
do
it
in
their
native
language,
and
so
we
have
clients
built
around
rust,
Java
go
with
cosine.
A
You
know
when
we
have
many
more
that
are
already
under
development.
Python
is
another
one
that
I
would
have
shown
you
in
the
demo
today,
but
in
in
general,
we
see
a
massive
amount
of
ecosystem
clients
being
generated
to
meet
each
of
these
individual
communities
where
they're
at
and
adapt
to
the
trust
models
that
they're
comfortable
with
so
again
we're
trying
to
bring
the
same
fundamental
principles
but
make
sure
that
they're
addressable
in
a
very
open
and
interoperable
way.
A
Here's
where
I
would
have
kicked
to
the
demo
and
shown
you
this,
unfortunately
I'll
just
quickly
talk
to
the
two
things
I
would
have
shown
you
one
is
that
just
last
week
the
python,
the
latest
release
of
of
python,
the
actual
programming
language
was
signed
with
Sig
store.
And
if
you
go
to
download
the
python
distribution,
you
can
actually
cryptographically
verify
that
signature.
Verify
that
there's
an
entry
in
the
public
record
transparency
log
associated
with
that
and
again
a
huge
step
forward.
A
A
So
what
this
was
is
I
have
a
very
simple
go
program
that
just
basically
said
hello
from
Dublin
I
pushed
up
a
change
to
that
program
and
I
allowed
GitHub
actions
to
actually
compile
that
go
binary.
Put
that
inside
of
a
container
sign
the
container,
publish
that
to
a
container
registry
as
well
as
publish
the
signal
signature
out
to
a
recore
instance.
A
So,
if
I
drill
into
this
GitHub
action
here,
there's
a
couple
different
steps,
I
install
a
couple
different
tools:
I
use
a
really
nice
tool,
called
KO,
which
takes
a
golang
binary,
puts
it
into
a
container
in
a
really
simple
and
straightforward
manner
off
of
a
very
minimal
base
image.
So
you
get
some
added
security
there.
It
also
generates
you
an
s-bomb
as
part
of
that
which
is
kind
of
cool
too.
So
now
we
have
this
Rich
container.
That
has
an
attestation.
It
has
the
actual.
A
You
know
binary
again
wrapped
in
a
distro-less
image,
and
we
then
call
out
to
cosign
to
sign
that
container,
but
not
with
any
human
key,
not
with
a
physical
Ubi
key.
We
actually
use
the
identity
of
this
CI
run
on
top
of
GitHub
to
marry,
together
with
the
full
SEO
service,
get
a
code
signing
certificate,
and
even
though
it's
a
lot
of
text
up
here,
what's
happening
at
the
end
of
the
day,
is
I
have
a
container
in
a
registry
that
is
the
signed.
A
So,
if
you
think
about
how
do
I
write
web
hooks
that
can
ultimately
make
Dynamic
decisions,
we
have
examples
of
examples
of
that
within
the
six
door.
Community
and
new
products
even
coming
to
Market
that
are
based
on
this
sort
of
pattern.
So
I
think
it's
a
pretty
exciting
capability
and
to
be
able
to
do
this
without
actually
ever
touching
keys.
There
is
a
public
and
private
key
used
in
this.
A
It
turns
out
that
they're,
ephemeral,
I
can
throw
them
away
after
I've
used
and
the
certificates
actually
have
extremely
short
lifestyle
times
associated
with
it,
and
so
that
really
you
don't
have
to
worry
about,
revocation
of
key
material
when
you
do
that
as
well,
which
is
a
super
powerful
construct,
because
again
I
don't
have
to
worry
about
how
do
I
manage
that
after
the
fact
so
quickly,
just
going
back
to
a
couple
slides
one
thing
I
wanted
to
stress
is
that
while
we
do
have
that,
let's
encrypt
Mission
and
spirit,
these
are
a
set
of
projects.
A
You
can
go
run
any
subset
of
this
infrastructure
that
you
like
inside
your
own
company
inside
your
own
data
centers.
If
you
choose
not
to
use
like
again,
you
don't
have
to
use
let's
encrypt
to
get
on
the
internet,
you
can
still
go,
buy
a
certificate
from
digisign
or
another
vendor.
We
fully
would
interoperate
with
that,
because
again,
all
of
this
is
built
on
open
source
and
Open
Standards.
A
So
while
we
try
to
make
it
easy
and
addressable
for
open
source
developers
across
the
web,
there's
no
requirement
that
you
have
to
use
our
services,
you
don't
have
to
log
in
with
Facebook
or
log
in
with
Google.
That's
not
a
requirement
to
take
advantage
of
the
benefits
that
Sig
store
brings
to
bear.
I
mentioned
this
cool
like
ephemeral,
key
construct,
which
has
a
lot
of
benefits
associated
with
it.
If
you
still
like
you're
like
hey
Bob
I,
get
it
I
got
a
UV
key
I
know
I.
A
Think
I
can
take
care
of
my
UB
key.
Thank
you
very
much.
You
can
still
use
it
with
our
stuff
again.
It
has
a
public
key
and
a
private
key
in
it.
There's
nothing
fundamentally
preventing
you
from
using
this,
and
we
actually
have
the
capability
within
our
tooling
to
be
able
to
to
interface
with
those
Hardware
Key
modules
hsms
and
pull
all
that
together
and
then.
Finally,
a
lot
of
what
I
showed
in
the
in
the
brief
snippet
there,
the
demo
it
does
show
an
online
verification
model.
A
We
do
recognize
that
not
everybody
is
always
going
to
have
a
constant
connection
to
the
internet
and
be
able
to
public
reach
out
to
public
services.
So
we
also
have
the
ability
to
do
offline
verification
of
these
of
this
information.
So
if
you're
able
to
import
a
public
key
that
you're
known
to
trust
in
a
route
that's
associated
with
that
public
key,
you
can
actually
do
the
verification
of
all
of
our
signatures
in
a
totally
offline
construct
as
well,
which
is
a
super
powerful.
A
The
last
couple
things
I
want
to
mention
is
that,
as
I
said,
this
community
is
going
like
growing
like
wildfire.
We
actually
have
our
first
user
Community
event
coming
up
here
in
a
little
over
a
month,
co-located
with
kubecon
in
Detroit
we're
going
to
have
a
mix
of
speakers,
some
introductory
level
content,
some
overviews
of
different
use
cases
where
different
communities
and
companies
have
started
to
play
with
the
technology
and
they're
going
to
give
their
experience
in.
A
In
doing
so,
and
then
we
also
have
a
couple
talks
that
are
really
technical,
deep
Dives
around
how
different
components
within
the
infrastructure.
If
you're
able
to
join
us
in
Detroit,
we'd
love
to
have
you
if
you're,
not
all
the
recordings
will
be
available
on
YouTube,
so
I
would
encourage
you
to
take
a
take
advantage
of
of
that
and
then
finally,
you
know
we
are
a
growing
Community,
a
wide
set
of
companies,
a
wide
set
of
diverse
individuals
that
are
there.
We
have
folks
from
Academia,
we
have
just
sold.
A
You
know
interested
programmers
from
along
the
web.
We
may
have
the
live,
Nebraska
or
Nebraska
person,
I,
don't
know,
but
in
general,
like
we're
a
fun
fast,
growing,
diverse
community
that
is
making
good
stuff
happen,
and
so
I
would
strongly
encourage
you
to
take
a
closer
look
at
what
we
have
with
six
store.
We
have
great
documentation,
blogs
a
set
of
projects
under
GitHub,
so
lots
of
ways
to
get
in
touch
with
us
and
engage
and
with
that
I.