►
From YouTube: Digital Identity Attestation WG (December 9, 2020)
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).
B
B
C
So
thanks
for
having
me.
C
Not
a
problem,
if
it's
a
little
rough,
though
that's
the
explanation,
that's
my
excuse.
Can
everyone
see
yeah
all
right
cool,
so
I'm
mike
malone
I've
been
hanging
out
in
these
working
groups,
since
I
think
the
first
one,
if
not
the
first
one,
pretty
early,
been
super
interesting.
So
far,
I
have
some
background
in
open
source
and
open
standards.
I've
worked
with
django
and
cassandra
when
they
were
pretty
young
projects.
I
hung
around
and
helped
out
a
little
bit
on
the
oauth
and
open
id
spec
processes.
C
The
early
on
before,
like
pre
ietf
days
of
oauth,
like
oauth
1.0,
and
these
days
I
run
a
company
called
small
step
and,
like
broadly
for
the
purposes
of
this
group,
probably
the
best
way
to
explain
it
is
like
we
do
certificate
based
public
key
infrastructure
stuff.
So
like
internal
ca
and
certificate
lifecycle
management
stuff.
We
have
this
open,
we're
an
open
core
company,
so
we
have
an
open
source
tool
chain
like
our
core
technologies,
all
open
source.
C
C
So
I
guess
I
have
some
background
in
certificate
based
public
key
infrastructure
and
identity,
which
is
really
what
I
what
I
wanted
to
talk
about
today,
because
sort
of
as
I
watched
the
presentations,
we
talked
a
lot
about
signing
stuff
and
how
that's
sort
of
an
important
thing
to
figure
out
if
we're
trying
to
secure
the
software
supply
chain
and
talked
less
about
how
these
signing
keys
are
issued
and
distributed
and
renewed
and
revoked
and
just
overall
managed
and
certificates
are
a
way
to
do
that
in
the
surrounding
infrastructure.
C
So
I
thought
it
might
be
interesting
to
sort
of
go
through
the
status
quo
and
sort
of
some
of
the
protocols
and
standards
that
exist
today
and
certificate-based
public
key
infrastructure,
and
I
think
that
might
be
relevant
to
the
group.
So
that's
the
plan,
so
here's
a
sort
of
brief
agenda,
I'm
going
to
start
really
almost
from
nothing.
So
hopefully
this
isn't
too
sort
of
like
rudimentary
or
too
like
boring,
but
hopefully
we'll
get
through
that
pretty
quickly.
C
And
then
I
wanted
to
demo
a
few
little
bits
that
I
think
are
cool
in
our
tool
chain
that
I
I
thought
might
be
sort
of
relevant
to
the
group,
specifically
like
some
workflow
stuff
around
connecting.
C
We
were
talking
a
minute
ago
about
openid
connect
and
single
sign-on
connecting
single
sign-on
to
certificate
issuance,
which
you
know
perhaps
could
be
relevant
here
and
then
I
have
a
few
slides
on
some
standards
and
technology
that
are
like,
maybe
a
little
bit
less
familiar,
but
are
what
I
think
are
interesting
and
solve
problems
in
the
certificate-based
pki
space
that
again
are
relevant
to
the
working
group
and
then
I'm
going
to
end
up
with.
C
I
think,
like
one
slide
on,
why
I
think
the
the
existing
ecosystem
isn't
going
to
work
for
our
purposes,
but
I'll
save
that
for
the
end
you
guys
might
might
get
to
it
before
I
get
there,
though
so
starting
at
the
very
very
beginning.
I
like
to
sort
of
start
to
explain
sort
of
justification
for
what
a
certificate
is.
I
like
to
start
like
with
hmac
right.
So
if
you
know
what
a
hash
function
is
right,
it's
a
one-way
function.
C
Stuff
goes
in,
you
get
some
random
stuff
out.
You
can't
reverse
the
process
right.
So
if
you
take
a
hash
function
and
you
take
a
shared
secret
like
I,
I
know
the
shared
secret
and
kim
knows
the
shared
secret.
For
example,
I
could
take
the
shared
secret
in
a
message,
run
it
through
the
hash
function
and
then
shoot
the
message
and
the
result
of
that
that
hash
over
to
kim
and
then
kim
also
knows
the
shared
secret.
C
So
she
can
run
the
message
I
just
sent
through
in
the
secret
through
the
hash
function
again
compare
the
hashes
and
if
they
compare
if
they're,
if
they
match,
then
she
knows
I
sent
it
because
the
only
way
to
produce
that
hash
output,
it's
a
big
random
number-
is
to
have
known
that
shared
secret
and
the
message.
So
she
knows,
there's
some
integrity.
C
There
right,
like
nobody's,
changed
the
message
in
transit
or
anything
so
that
sort
of
makes
sense
except
there's
a
problem
because
she
doesn't
she
sort
of
knows
that
I
sent
it
that
I
produce
it
hash,
but
she
also
could
have
produced
that
hash
right.
It's
only
two
people,
that's
not
a
problem,
because
she
knows
she
didn't
produce
it,
but
if
we
all
knew
the
shared
secret,
then
she
can't
really
tell
who
who
sent
it
right
so
enter
signatures.
C
There's
like
for
people
who
are
experts
which
I'm
sure
there
are
experts
here.
This
is
probably
annoyingly
incorrect,
but
it's,
I
think,
good
enough
for
our
purposes.
So
signatures
are
a
lot
like
message:
authentication
codes
except
they're,
using
asymmetric
cryptography,
and
I
I
I
think
of
like
asymmetric
cryptography
as
like
a
magical
gift
from
mathematics
to
computer
science
because
it
lets
you
do
this
thing
that,
like
really
can't
do
any
other
way,
so
you
have
instead
of
having
one
shared
key.
You
have
this.
C
You
have
two
keys,
you
have
a
public
key
and
a
private
key,
and
you
can
sign
something
which
is
sort
of
like
producing
an
hmac
with
the
private
key,
but
you
can
verify
that
signature
with
a
public
key
right,
so
signatures.
C
Let
you
prove
someone
has
has
possession
of
a
private
key
without
knowing
the
private
key
yourself.
So
kim
can
verify
my
signature
without
having
the
private
key,
which
means
she
can't
generate
a
signature.
So
everybody
in
the
room
can
have
the
public
key
and
I
can
sign
something-
and
you
can
all
know
for
sure,
it's
coming
from
me
and
not
somebody
else
in
the
room
right.
C
So
so
that's
a
that's
a
pretty
powerful,
primitive
and
in
authentication.
You
know
the
way
this
typically
works
and
again
this
is
a
huge
oversimplification,
but
in
a
protocol
like
tls,
if
I
wanted
to
know,
I
was
talking
to
kim,
say
I
could
produce
a
big
random
number
myself
and
send
it
over
to
kim
and
just
be
like
hey
kim,
sign
this
big
random
number
and
send
it
back
to
me
right
and
if
she's
able
to
do
that,
then
I
verify
it
with
her
public
key.
D
C
C
Asymmetric
crypto
is
great,
but
you
need
to
know
the
public
key
of
everybody
that
you're
talking
to
right
and
the
way
that
you
learn
public
keys
has
to
be
secure,
like
we
can
trust
the
crypto
right.
But
if
I'm
able
to
lie
and
tell
kim
that
my
public
key
or
like
dan's
public
key
is
my
public
key
right,
then
I
could
pretend
to
be
dan
right.
C
So
the
key
distribution,
it's
really
important,
that
the
key
distribution
is
also
secure
and
that
can
be
really
hard
it's
hard
to
scale
and
and
keep
secure
right
so
enter
certificates.
C
If
you
like,
this
is
the
reason
I
sort
of
go
through
the
story
arc
is,
I
feel,
like
the
complexity
of
certificates
is
somewhat
overblown.
There's
a
lot
more
to
it
than
what's
on
the
slide
when
you
get
into
practice.
But
really
all
a
certificate
is,
is
a
data
structure
that
binds
a
name
to
a
public
key
right,
so
you
think
of
it.
C
As
like
a
you
know,
it's
not
a
json
object,
but
like
a
json
object
with
two
properties,
a
name
and
a
public
key
and
and
then
the
certificate
itself
that
data
is
signed
by
a
certificate
authority.
C
So
you
can
think
of
it
as
a
statement
like
some
issuer,
some
authority
says
that
mike's
public
key
is
x,
signed
authority
right,
and
that
means
instead
of
having
this
like
end,
to
end
problem
where
everybody
has
to
know
everybody
else's
public
key.
It's
sufficient
for
everybody
to
just
know
the
certificate
authority's
public
key
right
and
you
can
learn
other
people's
public
keys
using
certificates
and
it
doesn't
matter
how
you
get
the
certificate
because
the
certificate
is
signed.
C
So
you
have
this
thing
called
data
origin
authenticity
like
you
know
that
it
came
from
the
certificate
authority
somehow
because
it's
signed
by
the
certificate
authority.
So
you
can,
you
can
receive
this
certificate
through
an
insecure
channel
and
still
trust
it
and
how
the
certificate
is
usually
received
is
directly
from
the
person
signing
something
so
like
in
a
tls
handshake.
C
When
I
send
kim
a
big
random
number,
she
sends
back
a
signature
over
that
number
and
her
certificate.
So
I
didn't
know
kim's
public
key
before
the
handshake,
but
I'm
learning
it
in
the
handshake
and
then
I
verify
the
signature
on
the
certificate
and
now
I
know
her
public
key
and
now
I
can
verify
her
signature
over
the
big
random
number
and
now
I
know.
C
To
kim
right,
so
this
is
a
big
thing
that
certificates
do.
Is
they
help
solve
this
key
distribution
problem?
You
don't
need
things
like
key
servers
to
tell
you
who
who
who
owns,
which
public.
C
Key
so
I
like
to
throw
this
in
here
too.
This
is
a
real
x509
certificate
and,
as
you
can
see,
it
has
a
lot
of
stuff,
in
addition
to
just
a
name
and
a
public
key,
a
lot
of
it's
sort
of
scaffolding,
stuff
and
obscure
stuff
that
you
don't
necessarily
need
to
know
about
certificates
also
tend
to
include
stuff
like
what
the
key
is
supposed
to
be
used
for
right.
It's
like
key
uses.
Some
keys
are
meant
for
signing.
C
Some
keys
are
meant
for
encryption,
so
you
can
throw
that
in
a
certificate
that
way
things
that
are
using
the
certificate
know
not
to
misuse
it.
An
important
thing
here
is
a
lifetime
right
once
a
certificate
is
signed.
Unless
you
have
some
additional
infrastructure
mechanisms
in
place,
it's
going
to
be
trusted
forever.
C
Right,
so
lifetimes
are
usually
thrown
in
there
right
so
begin
date
and
end
date.
So
only
trust
the
certificate
between
these
two
dates:
there's
a
bunch
of
policy
stuff
and
extensions
and
metadata,
but
at
its
core
it's
binding
a
name
to
a
public
key.
So
that's
what
a
certificate
does
so
a
few
more
definitions,
real
quick!
I
just
want
to
run
through
these,
because
sometimes
I
just
like
use
some
of
these
terms
in
passing,
and
I
want
to
make
sure
everyone.
I
don't
even
know
these.
These
are
like
my
definitions.
C
C
A
root
certificate
is
a
certificate
that
contains
the
ca's
public
key.
So
it's
used
to
verify
certificate
signatures
again.
A
certificate
is
just
a
thing.
A
data
structure
that
binds
a
global
key
in
a
name
and
signed
by
ca,
a
subscriber
is
a
named
subject
of
a
certificate.
That's
issued
by
a
ca.
So
it's
just
a
thing
that
has
its
own
certificate.
C
A
relying
party
is
a
thing
that
uses
a
certificate
to
authenticate
somebody
else
right
so
like.
If
kim,
had
a
certificate-
and
she
was
authenticating
to
me-
then
kim's
a
subscriber
and
I'm
the
relying
party
tls.
You
guys
know
what
that
is
x.
509
is
a
standard
certificate
format
used
by
tls
and
then
a
leaf
certificate
is
just
a
certificate
that
belongs
to
a
subscriber,
as
opposed
to
a
ca
certificate.
C
So,
and
then
I
put
this
slide
in
here
because
I
like
to
differentiate
between
when
people
think
of
certificate-based
public
key
infrastructure,
I
think
the
first
thing
that
pops
into
their
head
is
web
pki,
which
is
not
even
a
term
that
people
hear
often
because
generally,
we
just
call
it
like
pki
like
the
pki,
because
it's
what
people
think
of
that
when
they
think
of
certificate-based
public
key
infrastructure
is
the
web.
C
So
webdki
is
the
public
infrastructure
that
your
browser
uses
to
securely
connect
to
websites
right
when
you
see
https
and
the
uri.
These
are
like
the
let's
encrypt
certificates.
It's
mostly
standardized.
C
The
big
standards
are
rfc
5280.
I
think
there's
an
update
to
that
one,
but
that's
the
one
that
I
know
off
the
top
of
my
head
and
ca
browser
forum,
which
is
more
of
sort
of
a
policy
statement,
an
agreement
between
the
browsers
and
the
certificate
authorities
on
like
how
certificates
are
issued
and
some
details.
C
So
an
interesting
aspect
of
what
pki
is:
we've
talked
about
like
these
root
certificates,
everyone
has
to
know
the
root
certificate.
Public
keys.
These
are
distributed
in
a
quote:
trust
store
with
your
browser
or
operating
system.
So
there
are
root
programs.
C
There
were
three
root
programs,
apple,
microsoft
and
mozilla
ran
root
programs,
but
I
think
google
actually
just
started
what
google
was
using
mozilla's
until
I
think
just
a
couple
weeks
ago.
They
they
kicked
off,
I
think-
and
now
so
they're
gonna
have
their
own
root
program,
so
these
trust
stores
are
shipped,
so
your
computer
browser
comes
with
a
bunch
of
certificate
authorities
that
are
already
trusted
right.
C
There
are
over
a
hundred
of
them,
they're
a
bunch,
so
the
web
pki
is
really
important,
because
web
ppi
certificates
are
trusted
by
default
by
browsers
and
pretty
much
everything
else
that
uses
tls
right.
So
there's
no
configuration,
no
trust,
bootstrapping
required.
It's
already
done
for
you
and
then
what
I
do
most
days
is
talk
to
people
about
internal
public
key
infrastructure,
so
that
is
pki
that
you
run
yourself
for
your
own
stuff,
but
you
can
think
of
this
as,
like
any
other
pki
right,
the
advantage
of
not
using
web
pki.
C
C
They
can
only
issue
certificates
for
fully
qualified
domain
names
that
are
in
public
dns,
and
so
there
are
a
lot
of
rules
and
restrictions
around
lifetime
of
certificates
and
stuff
like
that,
whereas
you
know,
if
you
design
your
own
public
key
infrastructure,
you
control
all
of
that.
You
control
enrollment,
renewals
to
your
lifestyle
life's
lifetimes
authorizations,
identity
proofing,
all
your
policy
and
everything
you
also
control
your
system
security.
So,
instead
of
relying
on
the
security
of
100
plus
web
pki
certificate
authorities,
you
you
know
exactly
who
can
issue
right?
C
The
downside
is
you
have
to
do
it
yourself,
right?
Okay,
so
that's
my
background
on
public
certificate-based,
public
key
infrastructure.
I
this
blog
post,
if
anyone's
interested
where
I
it's
like.
It's
a
long
read
it's
like
45
minutes,
but
it
goes
in
like
depth
on
everything
I
know,
which
I'm
sure
isn't
everything
but
everything
I
know
or
new.
At
the
time
when
I
wrote
this
about
public
infrastructure,
it
was.
B
C
So
that's
that
so
now
we
know
what
certificates
are
we
have
sort
of
a
grounding
in,
like
you
know
the
terminology
and
whatnot.
So
I
wanted
to
talk
real,
quick
about
certificate
life
cycle,
so
these
are
like
key
moments
in
certificate
management.
So
there's
bootstrapping
right.
If
you
don't
already
trust
the
root
certificate
authority,
you
need
to
bootstrap
and
figure
out
how
to
how
to
sort
of
establish
trust
and
root
certificate
authority.
C
So
these
are
all
very
important
aspects
and
I'm
going
to
jump
into
a
demo
here
in
a
second,
and
the
thing
I
want
to
demo
is
connecting
oauth
oidc
single
sign-on
to
certificate
issuance,
which
I
think
is
a
really
neat
workflow
and
something
that
could
be
useful
or
interesting
to
the
working
group
here.
So
if
you're
not
familiar
with
oauth
oidc
openid
connect,
it's
sort
of
the
merger
between
the
oauth
authorization
framework
and
the
open
id
authentication
framework.
It's
a
single
sign-on
protocol,
like
people
jokingly,
call
it
saml
with
curly
braces.
C
So
let
me
show
you
a
quick
demo
of
some
stuff
over
here,
so
I'm
running
our
open
source
certificate
authority
in
this
tab
and
here's
the
flow
I
wanted
to
demonstrate
so
getting
a
certificate.
The
point
of
this,
I
guess,
is
that
getting
a
certificate
doesn't
have
to
be
hard,
so
I'm
going
to
run
step
ca
certificate
mike
at
smallstep.com,
so
mike
at
smallstep.com
is
the
name
that
I
want
my
certificate.
So
it's
the
subject
name
and
then
actually
before
we
do
this,
I'm
pretty
sure
I'm
pretty
happy.
C
So
then,
I'm
going
to
say,
I
want
to
write
my
cert
out
to
mike.cert
and
my
key
out
to
my.key
and
when
I
hit
enter
here,
the
step
command
line
tool
is
going
to
say,
like
okay
cool.
How
do
you
want
to
prove
that
you're
mic
at
smallstep.com?
C
How
do
you
want
to
do
enrollment,
and
I
have
a
few
different
provisioners
configured
here
for
enrollment
and
I'm
going
to
choose
this?
Google
open
id
connect
provisioner
and
when
I
do
that,
it's
going
to
launch
the
single
sign-on
flow
in
my
browser
and
I'm
going
to
log
in
as
mike
smallstep.com
and
it's
going
to
get
redirected
back
and
what
happened
here
is
on
the
redirect
back.
My
client
here
got
an
oibc
identity
token,
which
is
assigned
a
assertion
issued
by
google
saying
hey.
This
is
mygetsmallstuff.com
generated.
C
A
new
key
pair
generated
a
certificate.
Signing
request
submitted
this
certificate
signing
request,
along
with
the
oidc
identity
token,
to
my
certificate
authority
over
here,
which
verified
that
token,
which
proved
that
I'm
mike
smallstep.com
and
authorized
me
to
get
a
certificate
from
my
getsmallstep.com.
C
So
if
I
run
set
certificate,
inspect
short
white
dot
cert
you
can
see.
I
got
a
certificate
here
with
mike
smallstep.com.
As
a
subject,
we
also
put
in
like
your
user
id,
that's
just
how
our
oidc
provisioner
works
by
default,
so
so
yeah.
This
allows
you
to
sort
of
connect
your
existing
identity
infrastructure
to
a
certificate-based
public
key
infrastructure.
So
you
can
imagine,
like
you
know,
a
certificate
authority
running
and
using
social
sign-in
to
issue
certificates.
In
this
way,
once
you
have
a
certificate,
you
can
do
cool
stuff
with
those
certificates.
C
So
we've
been
talking
a
lot
about
like
tls.
I
wanted
to
show
another
standard,
real
quick,
so
I'm
going
to
use
jws
json
web
signing
to
sign
something
so
jws.
If
I
think
I
have
a
slide
on
it
in
a
second,
but
if
you've
heard
of
jots
json
web
tokens
or
jwts,
it's
part
of
this
jose
group
of
standards,
that's
all
like
json
encryption,
stuff
and
signing
stuff,
so
jws
is
json
web
signing
and
it's
just
a
signing
standard.
So
we
happen
to
have
jws
support
built
into
this
step
command
line
tool.
C
So
I
can
do
step
crypto
jws,
sign
some
file,
dot
text
and
then
jw.
The
jws
standard
has
this
cool
sort
of
integration
with
x,
509
certs?
C
So
I
can
pass
in
x5c,
cert
and
x5c
key
and
pass
in
my
x509
certificate
in
key
and
I'm
going
to
get
this
big
base64
encoded
thing
back,
but
the
format
of
a
jws.
You
can
see
they're
probably
hard
to
see,
but
I'm
going
to
highlight
to
the
first
dot
here
the
format
of
a
json
web
signature
is
base64,
encoded,
json,
header,
dot,
base64,
encoded,
payload,
dot,
base64
encoded
signature.
C
So
the
header
is
the
interesting
bit
in
this
case.
So
I'm
going
to
base64
decode
it
for
us
real,
quick
hd
hype
to
jq.
C
E
C
It
yeah
it
does.
I
was
trying
to
pipe
it
through
jq.
It
looks
like
it's
not
terminated.
Anyways,
you
can
see,
there's
an
algorithm
here,
a
key
id.
I
was
hoping
to
format
it
nicely
for
you
guys,
but
this
is
the
interesting
bit
so
you
can
see
in
here.
Is
this
x5c
property
and
then
there's
a
list
and
if
you're,
a
like
x509
nerd
you'll,
probably
recognize
this
mii
beginning.
These
are
x509
certs,
base64,
encoded,
x,
509
certs
in
the
header
of
this,
this
data
structure
so
sort
of
like
tls.
C
The
neat
thing
about
this
is:
if
I
send
this
to
you
and
you
trust
the
root
certificate,
you
can
verify
that
it
was
sent
by
me
without
already
knowing
my
public
key,
because,
again
in
this
structure,
my
certificate
is
included
right.
That
was
the
point
I
was
trying
to
make.
Unfortunately,
I
didn't
get
to
to
make
it
as
eloquently
as
I'd
hoped.
C
So
yeah
anyways
we
inspected
her.
Oh,
I
wanted
to
show
a
couple
quick,
additional
workflow
thing.
So,
as
I
mentioned.
C
Search
expire,
we
issue
short,
live
certs
by
default,
which
is
good
practice.
You
want
things
to
be
trusted
for
a
shorter
duration,
it's
good,
but
you
need,
if
you're,
going
to
keep
using
the
the
sort
after
experience,
you
need
to
be
able
to
renew
it.
So
again,
renewal
doesn't
have
to
be
hard.
C
We
can
renew
like
that,
and
now
I
have
an
extended
lifetime,
and
that
is
literally
just
using
a
mutual
tls
request
as
a
certificate
authority,
and
you
can
renew
that
way.
We
also
have
a
revocation
second
revoked,
so
I
just
revoked
that
cert
and
now,
if
I
try
to
renew
it
again,
I'm
going
to
get
an
error
because
it's
been
revoked
right.
C
So
the
last
thing
I
wanted
to
show
is
sort
of
like
a
live.
Demo
is
just
what
this
might
look
like
in
a
workflow
and
I'm
going
to
demonstrate
how
we've
integrated
this
certificate
lifecycle
management
stuff
into
ssh.
So
ssh
again,
I
have
a
slide
on
this
in
a
second
with
more
details
on
it.
Open
ssh
actually
supports
certificate
authentication
and
it
has
a
bunch
of
neat
benefits.
C
C
So
this
is
like
the
normal,
open,
ssh
client,
we've
configured
it
to
use
certificate
authentication
and
if
I
don't
already
have
a
certificate
use,
the
single
sign-on
flow
that
I
just
demonstrated
automatically
to
obtain
a
certificate
in-band
in
the
connection.
So
if
I
ssh
to
this
server
you're
going
to
see
that
same
flow
that
we
just
looked
at
before
it's
going
to
be
like
oh
you're,
not
logged
in
you're
not
going
to
be
able
to
connect
to
the
server
so
go
and
get
a
certificate
first
using
this
oidc
flow.
C
So
I'm
going
to
sign
in
my
browser
in
this
case
I'm
using
octa,
not
g
suite.
I
get
redirected
back
and
in
band
with
this
request
that
same
flow
that
we
were
just
talking
about
happened.
So
I
got
an
odc
identity
token.
It
generated
a
new
key
pair.
I
changed
it
with
the
ca
and
got
an
ssh
certificate.
The
key
material.
In
this
case,
we
just
jam
into
ssh
agent,
which
is
like
an
in-memory.
C
It's
a
it's
a
little
process
that
runs
that
on
a
unix
domain,
socket
that
the
ssh
client
can
talk
to
so
all
the
key
materials
held
in
memory.
So
it's
ephemeral,
short-lived
keys,
held
in
memory,
never
touching
disk,
so
better
security
and
improves
operations,
because
you
don't
have
to
do
the
key
distribution
stuff
and
pretty
good
user
experience
too,
because
this
works
on
ssh
by
the
way
it
works
with
ssh,
I
should
say,
and
git
can
use
ssh
for
as
a
transport.
C
All
right
so
relevant
standard,
so
the
first
one
again
open
ssh
certificates,
they've
been
in
open
ssh
for
10
years.
It's
not
open.
Ssh
uses
its
own
certificate
format,
so
it's
not
x509
whatever.
It's
still
got
a
lot
of
benefits
and
the
interesting
thing
for
our
purposes
is.
You
know
I
noticed
when
damian
was
talking
about
open,
ssh
signing
that
he
mentioned
it
works
with
ssh
certificates.
C
The
other
standard
I
thought
was
sort
of
just
worth
discussing
real
quick
is
the
jose
suite
of
standards.
I
talked
a
bit
about
them
already,
everybody
hates
them,
but
everybody
also
uses
them
they're
used
by
oauth,
though
abc
the
identity.
Tokens
that
I
keep
talking
about
are
jots.
C
In
fact,
the
jose
suite
was
largely
developed
to
support
oadc.
The
probably
most
relevant
two
standards,
for
our
purposes
are
the
one
I
was
just
demoing
the
json
web
signing
standard
which
can
sign
arbitrary
stuff
and
there's
also
json
web
key,
which
out
of
the
suite
of
standards,
I
think,
is
my
favorite.
It
is
a
standard
way
to
represent
a
cryptographic
key
in
json
and
out
of
all
of
the
ways
I've
seen
to
represent
a
key.
I
think
it's
the
best.
C
C
The
first
thing
is
certificate
transparency.
So
I'm
going
to
sort
of
set
this
up
as
a
problem
solution
to
sort
of
help
grocket.
So
we
talked
earlier
about
web
pki
and
how
they're,
like
you,
know,
100
plus
certificate
authorities
that
every
browser
and
operating
system
trusts
by
default.
So
any
one
of
those
certificate
authorities
can
issue
a
certificate
for
google.com
right
and
everybody
will
trust
it
and
google
didn't
like
that.
C
Some
of
these
certificate
authorities
are
in
china
yeah,
for
example,
so
certificate
transparency
is
a
solution
to
that
problem.
So
the
way
certificate
transparency
works
is
when
cert
is
issued.
The
certificate
authority
submits
it
to
a
certificate
transparency
log,
which
returns
this
sort
of
receipt
that
it's
been
submitted.
I
think
it's
called
a
signed
certificate
timestamp,
it
doesn't
matter
sct,
it's
a
proof
that
you
submit
agents
to
the
log
and
anyone
can
monitor
these
ct
logs,
so
they're
public.
So
anything
that's
been
submitted.
C
Is
it
gets
in
this
append
only
log
structure
and
anyone
can
see
what's
been
submitted
to
it
and
relying
parties
like
browsers,
only
trust
certificates
if
they
have
one
of
these
scts.
So
basically,
if
a
certificate
hasn't
been
tr
submitted
to
publicly
public
certificate,
transparency
lists
browsers,
won't
trust
them.
C
So
there's
sort
of
this,
this
detection
mechanism
now
built
into
the
web
tki
that
allows
people
to
choose,
detect
this
malicious
behavior
if
it
occurs,
so
that
that's
certificate
transparency
and
certainly
if
some
sort
of
certificate-based
pki
were
used
for
us.
I
think
that
you'd
want
some
sort
of
similar
mechanism
beyond
just
certificates,
though
there's
a
lot
of
work
going
on
generalizing
the
these
transparent,
this
notion
of
transparency
over
arbitrary
stuff
right,
so
there's
key
transparency.
C
There's
you
can
imagine
sort
of
like
a
commit
log
transparency
or
release
transparency
list.
The
concept
of
a
sort
of
immutable
append
only
map
of
stuff
or
log
of
stuff
that
happens
with
inclusion
proofs
is
is
useful.
It's
a
useful
security,
primitive
google
has
a
project
called
trillion.
If
you
haven't
checked
it
out
that
that
does
this,
that's
sort
of,
I
think
the
the
best
solution.
I
don't
know,
even
if
there
are
other
ones,
but
trillion
is,
I
think,
the
way
to
go.
C
Blocking
I'm
not
a
blockchain
expert
by
any
means,
but
I
think,
like
at
a
high
level,
blockchain
can
probably
be
made
to
do
a
lot
of
the
same
stuff
as
certificate
transparency.
It's
probably
overkill.
It's
probably
more
decentralized
like
if
you'll
notice
like
like
ct,
is
still
somewhat
centralized
right.
You
have
these
ct
lists,
it's
a
server
running
somewhere.
That's
issuing
these
signed
statements
and
the
log
right.
So
it's
not
like
fully
decentralized.
The
way
blockchain
is
blockchain
would
probably
be
less
efficient,
more
complicated
than
ct.
C
There's
this
there's
another
idea
around
blockchain,
though
that
I
think
is,
is
relevant,
which
is
so
there's.
This
conjecture
called
zuko's
triangle,
so
this
is.
This
is
an
identity
concept
right.
So
there's
this
conjecture
called
zuko's
triangle
that
says
names
in
in
a
name
space
and
like
an
identity
system.
There
are
three
desirable
properties:
they
should
be
human
readable.
In
other
words,
they
should
be
like
meaningful
and
memorable
to
people.
C
They
should
be
secure,
so
you
shouldn't
be
able
to
sort
of
steal
somebody's
name
and
and
the
naming
system
should
be
decentralized,
so
resolutions
and
bindings
shouldn't
require
a
central
authority
and
zuko's
conjecture
was
that
you
have
to
choose
two.
You
can't
have
all
three
so
dns,
for
example,
is
human
readable
and
it's
decentralized,
but
it's
insecure.
Dns
sac
is
human,
readable
and
secure,
but
it's
centralized.
C
You
could
use
raw
public
keys
to
identify
people
right
instead
of
they're
like
human
names,
in
which
case
would
be
secure
and
decentralized.
Anybody
can
generate
a
key
pair,
but
those
public
keys
are
big
random
numbers,
so
they're
not
meaningful
to
humans.
So
this
was
a
thought
that
was
sort
of
out
there
in
the
world.
For
a
while
and
then
blockchain
came
along
and
aaron
schwartz
wrote
this
blog
post
and
was
like
yeah
nope
zuko
is
wrong.
C
Blockchain,
you
can
do
all
three
and
this
sort
of
quick
summary
he's
always
a
great
blog
post.
It's
pretty
accessible
called
squaring
the
triangle.
C
I
have
the
link
up
here,
but
I
think
that
the
main
sort
of
idea-
the
way
I
understand
it,
is
that
like,
if
you
understand
the
double
spending
problem
in
the
blockchain
space,
where,
like
you,
only
want
to
be
able
to
spend
a
piece
of
currency
once
and
that's
like
the
one
of
the
reasons
for
the
immutable
log
of
like
transactions,
it's
pretty
similar
to
double
name
assignment,
which
I
think
is
a
big
problem
between
that's
the
conflict
between
human,
readable
and
decentralized,
is
if
it's
human
readable.
C
C
C
C
Is
this
this
notion
of
time
and
the
reason
I
wanted
to
include
this
is
because
I
don't
think
it's
solved
by
many
systems,
including
pgp
pgp
seems
to
just
assume
that
keys
are
never
compromised
and
never
rotated
or
changed,
which
is
an
interesting
thing
to
assume
so
here's
the
scenario
I
steal
your
key
today
you
notice
and
revoke
it.
Then
I
go
and
I
use
your
key
that
I
stole
to
sign
a
commit
with
yesterday's
date
in
it
right.
C
So
there's
sort
of
two
options
here
when
you
revoke
the
key
like,
are
you
revoking
going
forward
or
are
you
revoking
forever
if
you
revoke
forever
now
you
have
all
of
these
old
signatures
using
your
your
key
that
are
no
longer
trusted.
So
that's
not
gonna
work,
but
if
you
revoke
only
going
forward
and
if
the
person
making
the
connect
gets
to
pick
the
date
of
the
commit,
then
they
can
lie
and
just
say
it
was
signed
before
the
key
was
revoked
so
broadly.
C
The
solution
here
is
to
include
a
third-party
source
of
authoritative
time.
That's
like
bound
in
with
the
commit
and
there's
this
protocol
called
rough
time
that
I
think,
would
probably
be
a
good
solution
for
this
in
our
world.
I
think
there's
some
other.
I
there's
a
thread
on
my
twitter
because
I
was
asking
the
internet
about
this
yesterday,
but
like
basically
the
way
rough
time
works.
Is
there
these
public
rough
time
servers?
C
I
think
like
cloudflare
runs
one
and
you
can
shoot
a
notch
over
to
them
and
they'll
return
with
like
a
tuple
of
the
time
and
like
I
think,
your
nonce
and
like
their
signature
over
the
time
and
the
nonce,
so
it
basically,
it
proves
that
this
nonce
existed
at
this
time
according
to
cloudflare.
C
So
if
I
sent
over
my
signature
over
my
commit
to
a
rough
time
server
and
got
a
signed
proof
back
from
rough
time,
that
said,
like
hey,
this
signature
existed
as
of
this
date,
then
you
guys
could
all
be
pretty
confident
that
I
signed
it
before
that
date.
Right
because
cloudflare
is,
is
that
the
signature
existed
in
the
world
before
that
date.
Right,
it's
not
just
me,
and
then
you
know
you
could
include
that
in
the
signature
package
and
a
header
or
something
like
that,
I
don't
know
of
any.
C
I
know
this
is
used
in
document
signing,
but
I
don't
know
of
anything
in
sort
of
like
release,
management
or
code
signing
that
uses
this.
I
could
be
wrong
well
unless
of
course,
cloudflare
steals
your
key
and
right
yeah.
So,
interestingly,
rough
time
has
sort
of,
I
think
you'd
have
to
rough
time
is
very,
is
a
very
low
level
primitive.
I
think
you
so
you
can
build
on
it.
Rough
time
has
an
answer
to
that
too,
which
is
that
you
can
chain
rough
times.
C
So
what
you
would
do
is
you
get
cloud
players
answer
right
and
then
you
take
their
signature
over
like
their
payload
and
you
submit
it
to
another
rough
time
server
and
then
they
return
and
like
now,
you've
sort
of
chained
it
right
and
and
that
also
lets
you
detect
malice
too,
because
if
the
other
rough
time
server
says
it's
a
different
time
than
cloudflare
said
right,
because
these
are
supposed
to
be
like
monotonically
increasing
clocks,
then
you
could.
F
Yeah
I
I
I
like
that.
I
certainly
agree
with
the
problem.
I
do
worry
that
if
it's
optional,
you
just
don't
include
it.
C
Yeah
yeah:
well,
you
can
make
it
not
optional
right.
I
I
I
guess
like
I'm.
C
I
put
I
I
don't
know
the
right
answer
here.
This
is,
I
think,
the
problem
and
and
a
a
tool
that
may
help
solve
it,
but
I,
I
actually
don't
know
the
landscape
here
very
well.
I
do
know
about
rough
time
and
I
think
rxce
3161,
a
bunch
of
people
were
pointing
me
to
which
I
think
is
a
time
authority.
It
seems
pretty
similar
in
concept,
though,
broadly
though
I
think
you
have
to
appeal
to
some
third-party
time
authority,
I
can't
think
of
another
one.
Actually
I
take
that
back.
C
I
I
had
there
is
another
way,
which
is,
I
think
you
can
use
some
form
of
transparency
as
well.
So
if
something
was
submitted
to
this
log
structure,
data
structure
right
append
only
log
and
it
was
in
the
log
yet
from
yesterday,
then
you
know
it
was
signed
yesterday
right.
So
you
could.
You
could
reuse
that
that
piece,
that
bit
of
architecture,
that
bit
of
infrastructure
for
this
purpose.
F
B
Yeah
there's
a
couple
of
problems
here
too,
that
you
know
people
usually
don't
know
a
key
stolen
unless
somebody
because
nobody
actually
advertises
you
know
hey.
I
got
cheeky,
you
know
right
so
unless
somebody
actually
leaves
their
laptop
and
the
laptop
is
physically
stolen,
you
know,
then
they
say
have
to
start
to
worry
about.
Like
hey,
I
think
my
key
is.
B
Ahead
and
revoke
it,
but
that's
a
very
unlikely
scenario
more,
like
the
scenario
is
going
to
be
that
you
know
some
somebody
stole
it
from
the
disc
and
the
developer
does
not
know
it.
So
there
is
even
if
you
include
rough
time
or
any
scenarios
like
this.
You
don't
actually
get
anything
out
of
this,
because
the
anybody
can
use
rough
time.
You
know
anybody
who
is
is
has
the
key,
but
the
the
owner
of
the
key
doesn't
know
the
key
stolen.
You
know
there.
You
can't
go
back
and
say
actually
didn't
sign
it.
B
You
know
we
colonel.
We
recently
released
the
transparency
log
specifically
for
this
purpose
saying
you
know
these
commits
were
pushed
at
this
time
and
this
is
appended
to
our
append
only
git
log.
Well,
it's
not
git's
not
append
only
right,
but
but
we
replicated
fast
forward
only
to
a
bunch
of
places,
including
infra.
We
don't
own.
So
if
that's
modified
or
somebody
tries
to
rewrite
history,
it
will
be
extremely
obvious
to
everybody
that
has
been
done
so
it's
time
for
evidence.
It's
not
time
to
proof.
C
Yeah,
so
that's
bad
yeah,
that's
probably
a
good
argument
for
using
transparency
over
just
simple
time
authority
for
something
like
this.
I
I
think-
and
this
is
just
me
off
the
cuff-
so
I
could
be
totally
wrong
but
like
yes,
a
transparency
list
would
also
let
you
detect
possibly
at
least
give
you
the
tool
set.
You
still
have
to
do
some
work
to
detect
that
somebody
is
using
your
key.
D
So
we've
been
working
on
a
project
that
does
just
this.
It's
it's
a
personality
on
top
of
trillium
and
the
the
requirement
for
a
log
entry
is
that
there's
a
signature,
public
key
and
some
sort
of
artifact.
That's
signed.
Okay,
and
this
is
then
entered
into
the
transparency
log,
and
then
you
can
pop
entries
off
and
look
for
things
such
as
your
public
key
being
used
as
as
an
example.
So
it's
it's
it's
something!
D
That's
it's
a
it's
a
fairly
early
piece
of
work
that
we're
getting
towards
a
usable
state
now
so.
C
Yeah,
that's
cool
yeah
and
it
it's
taken
years
for
this
ecosystem
to
develop
around
web
pki.
I
mean
certificate.
Transparency
has
existed
for
a
while
now
and
what's
now
starting
to
happen
is
like
vendors,
like,
I
think,
cloudflare
has
a
free
service.
Now,
where
you
can
enter
your
domain
name
and
they'll,
send
you
an
email
whenever
a
certificate
is
issued
for
your
domain,
so
you
can
like
imagine,
layers
being
developed
on
top
of
stuff
like
that.
D
Yeah,
so
the
idea
of
what
we're
doing
is
we're
not
really
driving
a
specific
use
case
with
the
transparency
log.
It's
more
that
we're
making
it
easy
for
people
to
implement
those
use
cases,
so
they
can
work
with
a
simple
set
of
apis
and
not
have
to
worry
about.
You
know
how
they
code
an
inclusion
proof
and
get
a
signed
tree
head
and
all
those
sorts
of
complexities.
D
So
this
way
somebody
can
come
up
with
their
own
manifest
okay,
and
as
long
as
there
is
some
sort
of
signing
in
there
so
that
we
have
non-repudiation,
so
people
can't
just
throw
anything
in
there.
Then
you
know
we
can
then
have
a
use
case
where
one
example
that
we
use
is
have
I
been
pwned.
D
You
know
the
old
website,
where
you
put
your
email
in
and
they
they
trawl
through
all
the
paste
bins
to
look
if
your
account's
being
compromised
when
a
website
has
been
hacked
you're
familiar
with
the
yeah
okay.
So
a
good
example
there
is.
Somebody
could
build
a
website
on
top
that
monitors
the
log
okay
and
then
you
then
submit
your
public
key
and
an
email
address
to
this
site.
D
Okay,
which
runs
independent
of
the
transparency
log,
and
then
they
monitor
entries
coming
into
the
log,
and
if
they
see
your
public
key
being
used,
they
could
send
you
an
email
now,
most
of
the
time
you
might
think.
Well,
meh,
you
know
yeah.
Of
course
I
just
signed.
Take
me
projects
release,
so
you
just
delete
the
email,
but
another
time
it
could
occur
where
you
are
kind
of
like
hold
on
I've
not
been.
You
know,
I've
not
signed
anything.
What
is
this?
D
Do
you
see
what
I
mean
and
then
immediately
there
is
that
there
is
obviously
some
investigation
that
needs
to
happen
as
to
you
know
what
artifact
was
signed.
You
know
what
what
other
sort
of
data
sets
were
associated
with
that
that
was
in
the
manifest
that
was
used
now,
of
course,
somebody
could
sign
something
and
not
put
it
in
the
transparency
log,
okay,
but
then
the
question,
that's
begged,
then
is:
should
you
trust
something?
That's
wrong
the
transparency
law,
because
it's
not
what
everybody
else
is
seeing,
then
so
it's.
D
Yeah
sure
yeah,
if
I'll
get
it
for
you,
so
our
readme
needs
a
bit
of
attention.
We're
kind
of
we're
iterating
over
the
design
and
coding
at
the
same
time,
but
yeah
there's
a
there's
a
website
going
up
shortly
as
well.
So
we've
done
a
few
things
like
we've
pulled
in
node.js
releases
and
all
their
signing
stuff
and
entered
that
in
and
just
looking
for
other
projects
as
well
to
include
the
but.
E
D
It's
relatively
easy
for
somebody
to
stand
up
their
own
instance
as
well.
We've
got
some
code,
that's
just
in
review
at
the
moment
to
add
what
we
call
implicable
types,
so
somebody
can
sort
of
delegate
their
own
key
values
within
a
manifest
of
of
what
they
want
to
capture,
so
it
could
be,
for
example,
compiler
version
or
build
system
version
or
developers,
email
or
you
know,
whatever
sort
of
specific
data
sets
you
wanted
to
get
in.
E
The
w3c
did
working
group
seems
to
be
active
in
this
kind
of
this
kind
of
topic
as
well.
It's
then
that's
the
decentralized
identity.
C
So
decentralized
identity
is
hard,
which
is
actually
a
nice
segue
into
this
last
slide
that
I
I
just
wanted
to
throw
up,
and
then
we
can
go
back
to
this
sort
of
discussion.
I
guess
like
summarizing
everything
I
went
through
like
a
lot
of
problems
are
solved
with
the
the
tooling
and
infrastructure
that
we
just
went
over
right
and
transparency
is
probably
one
of
the
most
interesting
things.
C
So
I'm
it's
interesting
that
it's
got
the
conversation's
going
in
that
direction,
but
I
think
existing
certificate-based
pki
the
way
it
works,
sort
of
with
web
pki
is
probably
too
centralized
still
too
centralized
for
this
working
group's
purposes
and
using
like
depending
maybe
you
could
depend
on
email
addresses
as
a
name.
Maybe
you
depend
on
oiu,
but
I
don't
know
that
you
could
really
ask
every
open
source
developer
to
have
an
email
address
with
an
oidc
identity
provider
and
have
a
small
number
of
trusted
certificate
authorities
the
way
that
webdki
works.
C
So
I
think
there's
a
lot
that
is
solved
here,
but
I
don't
know
that
it's
it's
exactly
what
this
working
group
is
looking
for.
However,
the
remaining
problems
may
be
easier
to
solve
than
fixing
pgp
style
key
distribution.
C
B
C
The
not
necessarily
you
know
I
can
verify
a
certificate
and
a
ct
log
inclusion
signature
without
any
online
request.
C
If
you
require
a
revocation
check,
yeah
replication
in
the
web,
gta
I
didn't
get
into,
but
it's
kind
of
a
tire
fire.
If
you're
using
super
short
live
certs,
then
replication
is
less
important.
There's
also
stuff
like
ocsp
stapling,
which
is
this
like.
You
can
have
a
longer
lift
certificate,
and
then
you
get
sort
of
a
shorter
duration
statement
from
a
ca
that
says
like
for
the
next
five
minutes.
Trust
me
this
certificate
hasn't
been
revoked,
which
requires
less
availability.
But
yes
for
revocation,
you
generally
need
some
sort
of
online.
E
Service
there's
no
server
bullet
here,
you're
right
right,
yeah,
if
you
have,
if
you
have
revocation
checks
that
happens
every
five
minutes
and
you
say
well,
let's
go
to
short
term
lifetimes
of
your
certificate
of
let's
say
every
five
minutes.
Then
that
means
either
way.
I
need
to
be
able
to
connect.
C
C
Yeah,
well
I
mean
again
fundamentally
I'd
say:
certificates
are
a
way
to
distribute
keys
and
arguably
right
like
I
I
I
I
I
I
I
suppose
I
am
presenting
the
case
that
they're
perhaps
a
better
way,
but
that's
certainly
arguable
debatable.
B
No,
no,
I'm
not
arguing
for
symmetric
keys.
I'm
just
saying
the
key
server
isn't
pgp
server,
so
there
is
still
asymmetric.
So
it's
the
certification
is
done
by
some
other
means.
For
example,
when
you're
retrieving
a
certificate,
you
could
use
a
https
connection,
so
you're
kind
of
delegating
your
trust
over
to
ssl
certificate
or
the
certification
authority.
That
way,
or
you
can
trust
that
all
of
the
keys
that
this
certificate
that
this
key
server
presents
are
trusted
because
they
are
signed
by
the
by
the
key
server
itself.
For
example,
that's
that's.
E
C
Yeah,
so
part
of
the
argument
constantine,
I
think,
is
that
there's
there's
also
a
lot
of
infrastructure
around
certificate-based
pki.
That
could
be
reused,
possibly
and-
and
maybe
maybe
I
know
that
I
know
that
the
sort
of
pgp
style
case
less
well.
So
perhaps
the
same
infrastructure
exists
there,
but
I'd
say
that's
part
of
the
argument
for
certificate-based
pki
as
well.
You
know
the
fact
that
that
there
are
standards
and
protocols
around
a
lot
of
this
stuff
that
already
exists.
A
Awesome
well
we're
a
couple
minutes
over
thanks
a
lot
mike
conversation
there
david
just
asked
for
the
slides
link.
I
think
you
have
that
you
can
drop
that
into
the
agenda.