►
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. 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.
"Keyless" Code Signing Without Fulcio - Nathan Smith, Chainguard
Sigstore's certificate authority Fulcio has popularized the idea of "keyless" signing. The keyless method makes signing hassle free by removing the need to manage private keys. Do you need to run Fulcio yourself if you want the same convenient signing flow, but you want your own trust root? No! In this talk, we'll walk through the what keyless signing really means and how to configure existing PKI solutions like Vault and stepca to use it.
A
B
A
A
We're
going
to
talk
about
keyless,
signing
without
fulsio,
so
keyless
signing.
Is
this
the
signing
pattern
that
was
popularized
by
Sig
store
where
you
don't
have
to
think
the
end
user
doesn't
have
to
think
about
managing
their
their
or
their
keys
and
I
want
to
sort
of
demystify
what
keyless
dining
is
and
show
that
you
can
also
create
the
same
flow
without
having
to
U6
store?
You
can
use
off-the-shelf
components
and
get
the
same
kind
of
experience.
A
Okay,
so
if
you
love
this
talk
or
if
you
hate
this
talk,
here's
how
to
get
a
hold
of
me
afterwards.
I
have
the
kind
of
pleasure
of
working
with
chain
guard.
So
I
get
to
think
about
this
kind
of
thing.
Throughout
the
day
for
work,
which
is
wonderful
and
then
you
can
find
my
GitHub
or
Mastodon
handles
there
to
to
say
hello
or
whatever
you'd
like,
and
so
here's
how
this
is
going
to
go
down.
A
But
we
don't
want
to
use
six
store
for
whatever
reason,
we're
going
to
take
a
look
at
keyless
signing
step
by
step
and
understand
the
components
that
we
need
to
run
ourselves
to
get
the
same
experience
for
for
our
users.
If
we
don't
want
to
use
the
the
public
good
instance
or
for
whatever
reason,
we
don't
want
to
use
all
the
components
of
Sig
stores,
open
source
services,
okay,
so
the
first
bit
about
keyless
signing
being
fun.
A
It
is
it's
it's
fantastically
easy,
especially
if
you've
gone
through
the
Alternatives
of
signing
any
other
way
in
the
past,
we're
going
to
see
some
examples
with
cosine.
This
is
six
stores,
CLI
client.
That
just
makes
it
a
lot
easier
to
use
these
these
services
to
sign
things
and
really
all
you
need
to
do
to
sign
a
container
with
cosine
is
to
just
type
cosine
sine
and
the
digest
of
the
container
that
you
want
to
sign
like
that's
it,
the
user
experience
that
happens
right
after
this.
A
If
you
haven't
done
this
before
is
if
you're
a
person
you're
going
to
get
you
know,
a
browser
is
going
to
pop
open
and
prompt
you
to
log
in
with
an
identity
provider,
Google
GitHub
Microsoft.
That
list
might
grow
in
the
future.
But
basically,
how
do
you
want
to
sign
this
image
which
identity
you
want
to
use
and
just
prompt
you
to
log
in
and
that's
the
identity?
That's
going
to
be
attached
to
the
signature
on
this
this
container.
A
There
are
some
variations
on
this.
If
you're
running
the
same
command
inside
of
some
kind
of
workload,
cosine
is
going
to
kind
of
look
around
and
try
to
figure
out
who
you
are.
Maybe
if
it
looks
an
environment
variable
and
sees
GitHub,
ID
token,
environment,
variable,
okay,
we're
in
GitHub
actions,
and
it's
going
to
use
that
identity
to
sign.
If
it's
in
kubernetes
it
might
find
the
service
account
token
and
use
that
identity.
A
So
if
you're
a
workload,
it's
not
going
to
prompt
you
to
log
in
it's
just
going
to
try
to
figure
out
who
are
we
essentially
and
there's
some
other
yeah?
Okay?
So
so
this
is
it
and
then
a
smaller
side
soon,
you'll
have
to
use
a
digest
because
signing
a
tag
doesn't
really
mean
anything.
The
content
can
change,
and
then
what
are
we
even
talking
about
on
the
signature?
So
that's
going
to
be
a
required
thing
soon
and
I
think
the
magic
of
this
keyless
signing
is.
A
Is
really
this
part
when
you
verify
a
signature.
The
aspect
that
you
want
to
sort
of
look
at
here
is,
we
can
just
say,
cosine
verify
we
point
to
the
same
image
digest
and
then
we
talk
about
the
signer.
We
don't
talk
about
keys
in
this
case,
if
I
was
signing
with
my
Google
login,
we
talk
about
my
email
address,
that's
the
Alias
for
for
me,
oh
sorry,
and
we
talk
about
according
to
who,
according
to
accounts.google.com,
there's
variations
on
this,
obviously
you
could
say:
I
want
it
to
be.
A
According
to
the
GitHub
actions,
identity,
provider
and
I
care
about
the
specific
workflow
to
have
signed
the
image
soon,
there'll
be
support
for
a
couple
other
providers
like
gitlab
and
build
guide
in
the
works.
So
hopefully
this
will
be
ubiquitous
across
CI
providers
and
other
workload
identities
soon.
A
There's
some
variations
on
this
verification
process.
You
can
run
this
as
a
kubernetes
admission
web
hook,
so
there's
Governor,
support,
I,
believe
gatekeeper
might
have
support
now,
I'm,
not
sure,
but
there's
also
a
a
controller
called
the
policy
controller
from
six
door
itself.
That
can
help
you
check.
You
know
signatures
and
reject
images
that
don't
match
a
policy
essentially
right.
A
This
is
really
awesome
as
an
end
user.
If
you
don't
know
anything
about
public
key
cryptography,
you
still
didn't
need
to
do
anything
and
know
anything
about
public
heat
cryptography
and
you
can
hold
it
right
and
not
mess
up,
not
switch
the
private
key
in
the
public
key
or
store
something
incorrectly.
You
don't
need
to
know
that
the
keys
even
exist
in
this
case,
so
there's
nothing
to
mismanage,
which
is
really
wonderful,
but
if
you've
never
had
to
manage
Keys,
you
might
not
know
how
bad
that
can
be.
A
So,
let's
take
a
look
at
managing
keys
and
see
what
that
experience
is
like,
so
cosine
can
can
also
sign
things
with
a
with
a
key
pair
and
the
first
thing
you
need
to
do
whether
you
use
cosign
or
not,
is
to
generate
a
key
pair
private
in
public.
If
you
use
cosine
to
do
it.
It'll
look
kind
of
like
this.
Ask
you
for
a
little
password
to
encrypt
the
private
key
and
then
it'll
write
out
two
files.
A
The
public
key,
it's
cosign.pub
here,
and
the
private
key
cosine.key
is
the
name
of
the
file
here.
The
private
key
is
the
kind
of
sensitive
bit
there's
some
variations
on
this
too.
The
private
key
can
be
managed
in
like
a
cloud
KMS
system
where
you
can
only
access
to
sign
over
an
API
instead
of
having
an
actual
key
content
on
disk,
but
some
of
the
pain
points
end
up
being
kind
of
similar.
A
Even
in
that
use
case
when
you're
not
managing
that
and
there's
different
tools,
you
can
use
like
openssl
or
add
a
step
CLI
to
generate
these
kind
of
key
Pairs
and
use
them
for
signing,
and
the
experience
of
signing
always
kind
of
looks
a
little
bit
like
this.
So
here
using
cosine,
we
point
to
the
same
kind
of
image
and
then
we
pass
in
the
private
key
to
sign
with.
A
That's
the
verification,
that's
happening
and
like
it
doesn't
look
like
that.
Bad
really,
like
it's
just
make
sure
that
you
handle
the
private
key
and
stick
it
where
you
want
to
sign
and
then
take
the
public
key
wherever
you
want
to
verify
right.
It's
it's
not
bad.
When
it's
one
key
one
key
is
actually.
This
is
like
the
Temptation
that
leads
you
down
the
path
of
like
despair.
A
You
only
really
need
to
know
a
little
bit
about
the
keys.
You
know
always
verify
with
public
always
sign
with
private
and
don't
leak
the
private
one
out
there,
otherwise
people
could
sign
with
it
right.
So,
let's
ask
a
couple
questions
to
kind
of
move
Beyond,
just
like
one
key
pair
right.
This
is
maybe
a
situation
that
you
have
like
I
want
to
verify
that
the
things
I
run
in
my
production
systems
were
built
in
my
build
system.
Right
like
we
should
all
be
able
to
answer
that
question.
A
That's
that's
like
entry
points
to
software
security,
software
supply
chain,
security
right
and
the
way
that
you
would
solve
this
to
kind
of
fix
this.
This
with
key
management
is
okay.
Well,
we'll
generate
a
key
pair.
Let's
take
the
private
key
over
in
your
build
system,
sign
stuff
in
your
build
system
by
accessing
it,
maybe
from
some
Secret
store
or
something,
and
then
you
tick,
your
public
key
and
wherever
you're
about
to
run
your
containers
or
your
software
verified
before
running
and
then
reject
stuff
that
that
isn't
signed.
A
But
if
you
want
to
act
like
slightly
more
nuanced
language,
around
verification
like
in
this
kubernetes
namespace
I
would
like
to
make
sure
that
that
it
was
built
and
signed
by
a
particular
CI
workflow.
The
only
way
that
you
can
discriminate
between
the
different
signers.
In
this
case,
the
different
CI
workflows,
is
to
give
them
all
different
private
keys
to
sign.
Otherwise,
your
statement
can't
be
verified
because
you
can't
distinguish
between
the
different
signers
right.
A
At
this
point,
you
better
start
to
kind
of
like
track
them
somehow,
because
just
by
looking
at
the
key
material,
you
don't
know
where
you
stuck
it
and
which
Pipeline
and
it
gets
to
be
a
little
bit
chaotic
tracking.
Where
you
put
each
one
right,
you
might
have
a
lot
of
pipelines
too.
Okay,
like
your
CI
provider,
also
probably
is
going
to
get
jacked
at
some
point,
and
people
will
take
your
private
keys
right
like
no
one
is
immune.
If
you,
if
you
create
a
Secret
store,
people
will
attack
it
right.
A
The
tough
bit
here
is,
you
need
to
make
sure
you
create
a
new
key
pair.
Put
the
new
public
key
in
place
to
verify
against
both
public
Keys
sign
with
the
the
new
private
key
distribute.
You
know
a
build
for
everything
and
then
get
the
new
builds
everywhere
and
then
remove
the
the
old
public
key
from
the
verification
policy.
It's
it's
work,
but
you
know
it
happens.
Right.
A
But
you
were
maybe
signing
things
for
customers
and
they
were
verifying
with
those
keys.
It
starts
to
get
rough
now
like
talk
to
PR
right.
You
have
to
do
the
same
thing,
but
you
also
have
to
deal
with
the
fact
that
you
just
kind
of
busted
your
customers
trust
a
little
bit
and
they're
just
kind
of
thinking
like
how
long
until
it
happens
again,
I
mean
the
news
cycle
is
rough
right.
A
It
just
kind
of
keeps
on
going
on
like
this.
You
know
if
you
have,
if
you're
a
big
company,
it's
it's
too
much.
If
you
have
a
public
key
where's,
the
private
key
like
no,
it
believe
me,
it's
painful
and
like
the
literature,
is
riddled
with
like
public
key
management
or
just
key
management,
just
being
a
brutally
hard
problem.
A
A
A
So
if
you
were
using
a
sixstores
policy
controller,
this
is
a
little
bit.
What
the
crd
would
look
like
and
the
thing
that
I
really
want
to
draw
attention
to
is
you
know,
there's
a
pattern
for
what
the
images
look
like:
gcr.io
Foo,
something
there's
some
details
there
about
CT,
log
and
keyless,
but
the
the
thing
that's
very
important
is
what's
highlighted
in
color
and
again,
like
all
keyless
verification
should
have
this
property,
where
you
just
say:
I
demand
that
the
designer
was
this.
A
You
know
this
identity
provider
this
this
particular
subject
and
maybe
even
a
bit
of
a
pattern
matching
thing
where
you
say
like
I
trusted
this
subject.
You
know
most
of
the
time,
but
November
was
a
bad
month.
They
were
compromised
and
then
you
know
I
care
about
the
subjects.
Looking
like
this
pattern,
or
something
like
that,
but
so
it
can
be
flexible,
doesn't
have
to
be
one
exact
workflow.
So
this
is
what
it
might
look
like
for
for
someone
to
say,
trust
a
particular
GitHub
GitHub
workflow.
A
You
should
really
really
question
yourself
if,
when
people
are
verifying
the
signatures
on
your
assigning
system,
if
they
need
to
reference
a
key
ever,
it's
just
not
a
position.
You
want
to
put
your
developers
in
because
then
they
have
to
manage
them
and
understand
what
that
key
means,
and
what
is
this
like
referring
to
right
it
it's
going
to
get
bad
eventually,
and
so
how
can
we
get
the
same
kind
of
helis
design,
even
if
we
decide
that,
like
six
stores,
actual
open
source
systems
don't
fit
whatever
your
requirements
are?
A
Okay,
so
there's
there's
kind
of
some
analogies
here
about
why
you
might
want
to
build
your
own
right
if
you're,
building
like
webpki
right,
there's
a
big
one
that
is
open
source,
let's
encrypt
and
it's
a
design
in
a
particular
way
to
deal
with
a
large,
publicly
trusted
being
a
large
publicly
trusted
CA.
It
has
a
very
large
Target
on
its
back.
A
So
it's
designed
a
particular
way
right,
but
you
can
use
like
Boulders,
let's
encrypts
Boulder
CA,
if
you
wanted
to,
but
when
people
have
private
instances
of
a
web
pki
they
often
don't,
they
often
choose
different
technology,
that's
built
for
smaller
private
certificate
authorities.
If
you're
running
a
kubernetes
cluster,
you
have
a
CA,
you
know
it's
baked
into
the
API
server.
A
If
you're
running
a
service
mesh,
you
also
have
a
CA
right
that
becomes
that
root
of
trust.
For
for
all
the
communication
inside
of
your
service
mesh
and
people
also
will
kind
of
build
them.
Out
of
you
know,
small
step
or
vault
open
SSL.
Maybe
is
the
wrong
example
to
use
here,
but
you
could
use
that
too.
If
you
wanted
to
to
build
these
sort
of
smaller
systems,
with
a
different
set
of
constraints,
maybe
certificate
transparency,
which
you
know
let's
encrypt-
has
to
have
isn't
something
you
need
for
your
service
mesh.
A
So
I
guess.
The
question
is:
if
Sig
store
is
kind
of
the
the
big
public
code
signing
let's
encrypt,
if
you
will,
what
are
the
options?
If
we
are
trying
to
make
something
with
different
requirements,
that's
private!
Does
it
need
to
be
the
same
and
I
don't
mean
to
say
by
any
means
here
that
Sig
store
itself
shouldn't?
Be
your
first
option?
It
should
it's
fantastic
and
it's
built
to
be
extremely
secure.
A
So
it's
a
great
option,
but
if
you
discover
you
have
already
an
existing
x509
like
certificate
Authority
that
you
need
to
use
for
whatever
reason
from
other
some
other
team
has
put
this
constraint
on
you.
Let's
see
like.
Can
we
still
get
the
same,
behavior,
basically
Okay,
so
to
figure
out
how
you
can
do
this
yourself?
A
We're
going
to
look
at
the
keyless
signing
process
in
detail
when
you
use
sigstore
and
then
we're
going
to
keep
like
a
little
grocery
list
along
the
way
for
the
stuff
that
we
need
to
run
ourselves
if
we're
trying
to
get
the
same
properties?
Okay,
so
that's
the
way
it's
going
to
go
so,
when
you're
using
cosine,
like
that,
the
first
example
there
to
sign
a
container,
the
the
first
step
for
cosine
is
to
figure
out
who
is
using
cosine.
A
So
who
are
you
who's,
who's
calling
me
and
that
you
know
we
talked
a
little
bit
around
like
looking
around
in
the
environment.
If
it's,
if
it's
a
workload,
if
it's
a
person-
and
it
can't
find
anything,
it's
just
going
to
pop
open
a
browser
and
say
log
in
tell
me,
tell
me
who
you
are
and
the
response
from
that
is
going
to
be
specifically
for
Sig
store.
It's
going
to
be
an
oidc
ID
token
that
describes
who
the
user
is
along
with
according
to
who
like,
according
to
Google
according
to
Microsoft.
A
That
kind
of
thing-
and
that
brings
us
to
basically
grocery
list
item
number
one-
is
to
think
about
the
identity
provider.
You
will
use
for
your
signers.
If
these
are.
These
are
like
Ci
workloads,
they
need
to
have
a
strong
sense
of
identity
and
the
identity
is
going
to
be
tied
through
the
whole
system,
all
the
way
to
the
end,
so
that
the
verifiers
can
use
that
language,
the
same
language
as
the
identity
provider
to
describe
who
they
wanted
to
sign
their
systems.
But
in
your
system
it
doesn't
have
to
be
an
oidc
identity
provider.
A
Thankfully,
that's
actually
being
baked
into
a
lot
of
CI
providers.
These
days,
Circle
CI
has
one
GitHub
actions,
gitlab
it's
becoming
more
ubiquitous,
but
if
your
system
for
workload
identity
is
spiffy
and
they're,
you
know
x509s
fit
docs.
That
could
work
too
if
you're
building
things
in
AWS
and
your
identity
provider
in
that
case
is
AWS
aim,
that's
a
perfectly
fine
identity
provider
so
long
as
it
works
with
the
rest
of
the
system
and
we're
going
to
talk
about
that.
But
that's
one
thing
to
think
up
up
front
is
who's
signing.
Is
it
people?
A
A
So
it's
going
to
create
a
private
key
in
memory
and
then
it's
going
to
take
the
public
key
conjugate
to
that
and
that
ID
token
about
who
the
signer
is,
and
it's
going
to
pass,
that
up
to
falsio,
which
is
Sig
store's
certificate
Authority,
and
what
it's
asking
for
is
a
short-lived
code.
Signing
cert,
so
fulsio
is
going
to
take
a
look
at
that
identity
and
remember.
A
A
The
idea
is
to
get
a
certificate
for
every
signature
yeah,
so
the
shorter
the
time
window,
the
better
and
what's
really
great
about
this-
is
when
you're,
when
you
have
certificates
or
you're
issuing
for
a
minute
or
two
certificate.
Revocation
is
just
out
of
the
question
like
there's
no
reason
to
have
a
certificate
revocation
list
with
windows
that
short
they're
about
you
know,
they're
about
to
expire,
anyways.
A
Okay,
so
that's
item
number
two
is
that
certificate
Authority
is
going
to
be
happy.
It's
going
to
have
to
be
in
your
system
somewhere,
because,
if
you're,
just
using
public
keys
by
themselves,
there's
no
additional
metadata
about
the
validity
period
and
the
certificate
Authority
is
giving
us
two
things.
It's
pushing
the
identity
information
into
the
cert
to
pair
it
up
with
the
public
key,
and
it's
also
giving
us
that
window
of
it's
only
valid.
A
For
you
know
five
minutes
or
something
like
that
which,
which
is
the
magic
of
certificate
authorities
metadata
on
top
of
public
keys
right,
so
there's
lots
of
different
open
source.
You
know
certificate
authorities,
I
think
you
know
in
spirit.
You
could
probably
do
this
with
like
an
SSH
certificate
Authority,
because
you
can
do
signatures
with
those
two,
but
we'll
keep
our
discussions
to
x509.
A
So
the
same
kind
of
certificate
authorities
you
see
for
TLS,
just
with
different
data
inside
them
inside
the
metadata
and
the
key
bit
here
when
you're,
choosing
your
certificate
Authority
is
that
it
needs
to
understand
your
identity
provider.
So
when
you're
choosing
that-
and
you
know
that
your
identity
provider
was,
for
instance,
it
was
going
to
be
AWS
I
am
the
certificate.
Authority
needs
to
understand
that
and
be
able
to
exchange
those
credentials
for
certs.
A
Okay
next
bit,
we
have
a
private
key
and
we
sign
our
artifact
with
it,
and
that
gives
us
back
a
little
bit
of
data
the
signature
and
then
we
Chuck
the
private
key
in
the
garbage,
nothing
more
for
our
list.
Now
that
that's
just
something
we'll
be
able
to
do
so.
No,
no
more
things,
no
more
requirements.
I
think.
The
only
thing
to
remember
here
is
we're
kind
of
on
the
clock.
At
this
point.
The
certificate
is
going
to
expire
students.
So
we
better
sign
quickly.
That's
that's
kind
of
the
only
design
requirement.
A
Okay
next,
so
what
happens
next
in
cosine
is
that
it
tells
it
needs
to
go.
Tell
recore,
which
is
the
signature,
transparency
log
that
it
it
made
a
signature.
So
this
is
one
of
these
really
interesting
and
excellent.
Security
features
of
of
Sig
store
is
that
there's
signature
transparency,
so
each
signature
that
happens
ends
up
in
a
signature.
Transparency,
log
and
cosine
is
going
to
tell
cosine
is
going
to
tell
recore
this
signature
transparency.
A
Now
it's
not
signature,
transparency.
That's
that's!
What
gives
Sig
store
this
keyless
feature.
Signature.
Signature.
Transparency
is
great,
but
it's
not
the
keyless
bit
What's
Happening
Here,
to
make
keyless
possible
is
that
this
is
a
verifiable
timestamp
of
when
the
signature
happened
and
recore
doesn't
need
to
necessarily
be
the
thing
that
does
this,
but
you
must
have
something
to
it.
So
the
key
element
here,
the
last
thing
that
we're
going
to
put
on
our
grocery
list
is
a
Time,
stamping
Authority.
A
Now,
if
you
decide
that
you
want
signature
transparency,
because
it
has
a
lot
of
great
properties
in
its
own
right,
you
could
run
record
if
you
want,
as
the
signature
is
the
time
stamping
Authority,
but
you
can
also
run
time,
stamping
authorities
that
only
do
these
time
stamps
and
don't
actually
have
this
big
signature
append
Only
log.
If
that's
what
you
don't
want
to
have
they're
a
little
bit
simpler
to
operate
as
well.
A
Okay,
so
that's
it!
We
have
the
three
things
on
our
list:
we
have
an
identity
provider,
a
certificate
Authority
and
a
Time,
stamping,
Authority
and
then
the
final
question
a
little
bit
here
is
that
was
a
lot
of
stuff,
like
a
lot
of
bundle
came
out
of
this
like
how
did
that
turn
into
someone
just
saying
you
know,
cosine
verify
this
email
address
and
this
identity
provider
right
there's.
This
is
what's
in
the
hands
of
a
verifier,
okay
and
here's
how
verification
works
and
what
you
need
to
implement.
A
If
you
want
to
make
this
keyless
magic
kind
of
work
right,
you
have
the
the
signature
of
the
bundle
of
the
big
time
stamped
bundle,
and
you
have.
We
have
our
certificate,
we
have
our
signature.
We
have
the
artifact
in
hand.
You
have
to
ship
all
of
this
stuff
to
the
end
user,
what's
happening
in
cosine.
A
If
you
signed
a
container,
is
that
this
is
all
attached
onto
an
oci
image
right
beside
your
the
image
you
care
about,
so
it's
all
stuck
there
inside
your
oci
registry,
usually
so
here's
the
process
we
kind
of
have
to
peel
this
thing
like
an
onion
so
outside
layers
first
and
we're
going
to
make
our
way
inside
the
first
bit
is
to
just
verify
the
signature
of
the
bundle.
So
recore
in
this
case
has
a
public
key.
A
We
verify
that
this
signature
was
signed
with
recourse
public
key,
which
kind
of
removes
the
bundle,
which
means
that
we
trust
that
the
signature
happened
at
a
particular
time,
and
we
know
that
what
the
time
stamp
is.
Essentially,
the
next
part
is
to
check
that
the
certificate
is
valid.
Now
it's
really
important
right
here
that
we
don't
use
the
normal
certificate.
Validation
flow
that
you
would
see
like
in
TLS,
because
this
certificate
is
very
likely
already
expired.
A
In
that
sense,
what
we
need
to
do
is
do
most
of
that
aspect,
make
sure
that
it
chains
up
to
our
certificate
Authority.
But
then,
when
it
comes
to
the
time
of
validity,
we
just
need
to
check
that
the
time
stamp
is
inside
of
the
validity
window
for
the
certificate.
So
that's
a
modification
you
need
to
make
from
the
normal.
You
know
TLS
kind
of
verification,
so
that
kind
of
Pops
off
the
certificate
from
the
onion
and
then
second
last
thing:
yeah
go
ahead.
A
A
So
then
we
CH,
we
checked
that
we
trust
the
certificate
Authority
and
then
second
last,
is
we
Chuck.
The
signature
actually
is
valid,
so
we
take
the
artifact
the
public
key
and
check
the
signature,
and
after
that's
done
we're
remaining
with
the
thing
the
user
actually
asks,
and
they
put
that
input
in
and
say
do
I
trust
me
at
example.com.
It's
just
the
identity.
Metadata
left
here
do
I
trust
these
details
and
those
could
be
very
arbitrary
for
your
situation.
A
A
A
We
could
choose,
for
instance,
as
the
certificate
Authority.
If
you
all
have
ever
used
hashicorp
Vault,
you
know
Swiss
army
knife
of
many
security
things
you
can
use
AWS
as
an
auth
method.
You
know,
so
you
can
authenticate
using
AWS
identities,
and
then
you
can
exchange
that
for
a
certificate
secret.
A
They
will
call
them
so
you
can
issue
short-lived
certificates
that
would
totally
fit
this
need
and
then
the
last
bit
is
you
do
need
to
choose
timestamping
Authority,
so
six
store
has
an
open
source,
one
that
you
could
just
grab
off
the
shelf
and
use
for
this
purpose.
Basically
or
you
could
choose
recore
here
or
you
could
try
to
find
another
one
that
is
sort
of
I,
think
the
RFC
is
3161.
That's
time,
stamping
spec
that
you
could
use,
but
there's
there's
options.
A
Let's
think
about
maybe
signing
with
a
corporate
identity
provider.
Maybe
you
want
to
sign
git
commits
this
way
and
you
want
to
use
like
your
OCTA
or
something
okay.
So
if
you
have
octave,
you
can
create
most
of
these
corporate
identity
providers.
Have
you
know
the
capacity
to
make
an
oidc
compatible
app?
You
know,
that'll
speak
oidc,
After,
People
log
in
and
a
great
option
here
too
another
open
source
one
is
to
use
step
CA
so
step.
Ca.
A
Has
these
the
notion
of
a
provisioner
which
credentials
can
I
exchange
for
which
certificates
and
certificate
templating?
So
you
can
give
step
CA
an
oidc
token
from
your
OCTA
app
or
from
any
other
place
and
templating
the
values
from
the
from
the
token
into
extensions
inside
of
your
certificate.
So
that'll
give
you
that
mapping
into
your
certificate
details,
so
they're
called
provisioners
with
step
CA
and
then
the
templating
is
attached
to
a
provisioner
and
then
again
you
just
kind
of
choose
a
Time,
stamping
Authority.
A
A
Okay,
I'm
gonna
give
good
news
first,
which
means
you
know
that
the
bad
news
is
coming.
You
can
keep
signing
with
cosine.
It's
already
got
flags
for
a
situation.
Just
like
this.
If
you're
using
step
ca,
for
instance,
you
can
get
a
certificate
with
step,
CA
certificate,
here's
you
know
grabbing
one
for
me
at
example.com.
A
Cosine
needs
to
have
a
particular
format
for
the
private
keys.
So
you
use
this
import
private
key
command
to
structure
it
correctly
and
then
in
signing
you
just
do
cosine
sine.
You
know
you
point
to
the
private
key
which
you
can
throw
out
right
after
signing.
So
that's
the
keyless
aspect.
You
point
the
certificate
you
have
and
then
you
have
to
have
a
root
bundle
that
chains
up
to
your
to
your
root
and
then
point
to
your
image.
A
Yeah.
The
bad
news
is
that
we
can't
verify
very
easily
in
cosine
right
now.
Cosine's
verification
really
understands
specifically
falsio
at
this
moment.
So
you
can
imagine
if
you
stopped
all
kinds
of
arbitrary,
like
extensions
inside
of
those
certificates,
the
very
last
unpeeling
of
the
onion.
It
would
be
like
I'm
not
really
sure
what
to
do
here.
A
So
you'd
kind
of
you
need
to
write
your
own
verification
logic
and
that's
the
pain
point
right
now,
unless
you
make
your
certificates
very
similarly
structured
to
what
folsio
is
doing,
and
you
can
almost
pull
that
off.
But
if
you
have
arbitrary
metadata,
you
can't
really
get
there
right
and
that's
probably
why
you're
doing
this
in
the
first
place,
but
the
future
is
brighter.
There's
a
couple
rough
plans
to
make
this
just
extensible,
so
the
I
think
the
dream
would
be
for
everyone
to
have
the
first
parts
of
the
keyless
bit.
A
You
know
the
time,
stamping
bundle
being
verified,
the
certificate
being
verified
and
then
all
of
that
just
be
shared
inside
of
coastline's
verification
logic
and
then
I
think
what
some
of
the
the
hope
is
here
is
just
to
have
an
arbitrary
Rigo
policy
or
cue
or
whatever.
You
love
for
your
verification
language
at
the
end
to
verify
the
really
particular
details
of
your
certificate
structure
so
that
people
can
bring
their
own
pki
and
get
the
same.
A
B
B
A
B
A
B
A
B
A
I
hear
you
I
think
that's
part
of
the
reason
some
people
look
for.
Something
else
is
that
folsio
in
particular,
can
be
a
little
rigid.
You
know
it's
not
meant
to
be
this
extensible
system
that
can
take
an
arbitrary
identity
and
exchange
it
step.
C
was
one
that
I
found,
kind
of
would
take
whatever,
and
it
worked
worked
really
well
and
I
could
test
that
way.