►
From YouTube: IETF114 ACME 20220728 2000
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
C
C
C
So
we'll
not
dwell
on
that
too
much
specifically
for
itf
114
in-person
participants
make
sure
to
sign
the
session
using
the
meet
echo.
You
take
a
light,
that's
easy
to
do
by
scanning
the
qr
code
at
the
door
and
use
mitecho
to
join
the
my
microphone
queue
and
keep
audio
and
video
off
if
you're,
not
using
on-site
version
and
wear
masks
unless
you're
actively
splitting
at
the
microphone-
and
this
is
something
regardless
of
how
we
feel
about
it.
This
is
something
we
all
agreed
when
we
signed
up
for
this
meeting.
C
C
C
We
already
got
to
note
taker
and
we'll
do
the
document
status
then
we'll
talk
about
current
work
items
which
are
detailing
node
id
and
ari,
which
is
not
really
a
current
torque
item
because
we
haven't
adopted
it
yet,
but
we'll
talk
about
that
as
well
and
then
there's
potential
new
work
from
brandon
weeks
and
the
agenda
bashing
before
we
continue.
C
Good
so
document
status,
we
don't
have
any
new
rfcs
since
vienna
acme
authority
token
has
a
discuss
from
ben
k
deck
since
november
of
2021
new
version
zero
eight
from
this
month.
And
what
do
we
do?
Then?
Kadak
is
no
longer
an
ad.
C
D
It
going
yeah,
so
we
did
try
at
least
to
deal
with
the
discuss
on
the
first
of
these
documents
on
the
the
original
authority.
Token
doc.
I
know
we
have
not
gotten
to
the
token
t
not
list,
I'm
not
actually
the
editor
of
that
one
but
like
hopefully
with
this
new
zero,
eight
version.
It's
like
better.
I
tried
to
fix
what
seemed
to
be
the
major
discusses
that
were
out
there
and
even
to
address
the
majority
of
ben's
comments.
D
D
A
Right
so
we
know
who
to
chase
now
for
that
one
yeah,
because
it's
not
you.
D
Was
I
mean
it's
really
honestly,
it's
probably
more
responding
to
ben's
mail
in
particular.
That
is
the
long
pole
in
that
tent,
because
there's
just
a
ton,
there's
a
ton
of
comments.
Honestly,
when
I
looked
at
it,
some
of
it
does
spill
over
between
the
documents,
even
a
bit
so
like
yeah,
there's,
there's
actual
work.
That
needs
to
be
done.
It's
hard
to
get
people
to
do
actual
work.
D
D
D
F
Yeah,
so
a
couple
of
observations.
First,
I
think
that
I
would
be
reticent
to
bring
to
do
a
different
progression
on
the
documents
separately.
They're.
Clearly
you
know
intertwined
and
if
something
comes
up
and
we
advance
one
too
far
forward
we're
going
to
be
in
a
pickle.
So
I
want
to
move
them
in
in
lockstep.
So,
even
if
we
clear
on
the
other
one
and
we
haven't
cleared
on
this,
one
like
I'd
want
to
hold
it.
So
I
think
part
of
it
is.
F
I
would
need
to
revisit
where
we
are,
but
it
looked
like
substantial
changes
were
needed
on
the
tf
office
based
on
based
on
the
feedback.
So
typically
what
we
do
when
we
have
substantial
changes,
we
want
to
reconfirm
consensus
on
the
solution.
So
what
we
don't
want
to
do
is
reiterate
in
the
isg,
because
we
still
need
to
check
with
the
working
group
that
they're
good
with
the
big
changes
and
then
there's
a
judgment.
F
Call
there
whether
we
got
to
go
back
to
the
community,
so
my
recommendation
would
be
given
that
we're
anticipating
big
changes
on
that
the
easiest
way
to
do
the
consensus
check
and
have
a
formal
process
to
know
where
we
are
where
we
are.
Instead
of
you
know
doing
this
kind
of
side,
consultation
would
be
to
bring
it
back
to
the
working.
D
D
Is
something
that's
probably
worth
doing
at
this
point?
I
I
definitely
agree.
We
should
move
these
together,
that
it
doesn't
make
sense
to
advance
the
authority
token
document
without
tnothlist
or
vice
versa,
and
so
I
guess
you
know
the
question
is:
do
we
want
to
start
that
process
of
just
sending
the
list
and
saying,
like
hey,
is
everybody's
still
cool
with?
D
What's
an
authority
token
now,
as
of
zero,
eight
like
or
do
we
want
to
wait
until
tenochlis
is
also
iterated
and
then
ask
the
working
group
are
both
of
those
documents
jointly
cool,
but
we,
I
think
that
kind
of
can
occur
in
parallel
with
the
ihg's
ongoing
review.
That's
right!
I,
what
I
don't
want
is
for
these
things
to
literally
be
like
you
know,
go
through
a
new
pub
wrath
and
a
new,
like
you
know,
gen
art
and
everything
when
they've
already
been
to
the
isg.
F
Well,
we
actually
do
that
all
the
time
and
I
stare
at
it.
I
guess
I
I
just
don't
know
where
the
energy
is
so
we're
15
months
from
the
last
version
of
that
document.
So
that
gives
me
great
applause.
I
guess
and
given
that
I
didn't
hear
kind
of
firm
dates,
we're
gonna
we're
committed
to
to
hammering
it
kind
of
here.
You
know
at
a
particular
time
we
are
we
sure
about
the
editors,
we're
not
like,
maybe
we'll
track
them
down.
I'm
concerned
that
we
can
close
it.
F
It's
been
15
months
and
that's
the
consensus
check
on
primarily
after
I
mean
when
it's
been
15
months,
since
we
did
it,
we
have
big
kind
of
problems.
I
I
mean
I'm
kind
of
what
I
was
hoping
here
is
a
lot
of
energy
to
kind
of
move
forward,
because
my
gut
is
I'm
not
sure
and
that's
why
I
want
to
bring
it
back.
A
So
why
don't
I
take
an
action
to
go
back
to
the
tnoth
list
authors
and
find
out
who
the
editor
is.
Who
has
the
pen
who
has
the
pen
and
and
give
them
and
make
them?
Tell
me
how
long
it's
going
to
take
them
for
them
to
update
the
document
once
they
update
the
document
and
reissue
right,
then
we
drop
them
back
down
to
the
working
group
for
a
short
period
of
time
just
to
review
them
both
in
parallel
and
at
that
point
we
pop
them.
D
A
F
Just
to
make
sure
we
have
the
names
right,
the
others
are
comments.
These
are
the
blocking
discusses
and
paul
did
take
up.
Ben's
position,
so
paul
can
help
us
right.
G
Mister,
well,
you
know
yeah
right,
former
chair,
sorry
deb
president,
the
tn
stuff
was
def
came
to.
You
know,
hope,
john
correct
me.
If
I
got
a
character,
if
my
memory
is
faulty,
but
it
came
from
the
stir
stuff,
and
it
wasn't
really-
I
mean
the
domain.
Expertise
is
for
the
most
part
over
there
right.
G
So
if
it
landed
for
more
than
a
year,
it
was
probably
not
purely
the
working
acme
working
groups,
issue
or
concern
and
they
might
have
fallen
through
the
cracks,
because
some
of
the
people
got
busy
and
other
stuff.
In
stir,
I
mean.
A
D
It's
like
really
huge
and
we're
all
super
busy
with
it,
and
so
this
this
was
is
not
front
burner
because
we
we
need
the
token
format
and
that's
already
written
into
some
like
addis
documents
under
standards
bodies-
things
like
it,
but
we
haven't
seen
a
lot
of
uptake
on
actually
using
acne.
For
this
bluntly,
no,
I
I'm
not
thrilled
about
that
in
the
sense
of
we
have
like
a
short
lived
certificate
story
that
we're
building
for
stir.
D
D
D
A
E
H
I
J
A
You're
the
best,
so
I
think
the
plan
is
to
to
contact
the
authors
of
tnoth
and
find
out
or
whatever
we're,
calling
that
thing
figure
out
when
we
can
get
an
update
to
that,
we'll
bring
them
all
both
of
them
back
to
the
working
group
for
a
two-week
last
call
and
we'll
review
it
with
the
number
of
reviewers
that
we
normally
get
in
this
working
group,
which
is
three
possibly
more
than
the
number
of
authors
of
the
document,
but
I
wouldn't
count
on
that.
A
C
That
sounds
good
enough.
I
mean
one
outcome
is
that
the
group
has
lost
interest
interest
and
we
buried
the
documents.
I
mean
that's
also
a
possible
outcome.
If
really
there's
no
energy
to
write
them,
I
mean
if
this
was
really
important
for
people,
then
the
original
office
not
having
energy
would
mean
that
somebody
else
takes
the
pen.
I
don't
see
anybody
else,
rushing
to
take
the
pen
either
so
well,
I
guess
it
all
depends
on
the
current
authors.
Getting
getting
the
energy
to
revise.
A
When
we
make
that
when
we
make
that
working,
glute
last
call
we'll
cc,
stir
too
while
we're
at
it,
because
that
might
get
us
a
few
more
reviews
right.
Okay,
does
that
sound
like
a
plan,
yeah,
okay,
good,
because
we'd
like
to
get
this
done
right?
It
needs
to
be
yeah
right
it
doesn't
you
don't
need
hanging
over
your
head
for
the
rest
of
your
life
right
just
saying,
okay,.
C
So
two
more
things
integrations
went
through
working
group.
Last
call
not
a
lot
of
discussion.
Question
is:
are
we
ready
to
go
ahead
and
sub
domains?
Just
finished
working
with
last
call.
A
A
A
handful
of
reviews:
it's
got
some
tie-ups
with
lamps
in
that
there's
a
is
my
purchase
in
here.
No,
oh,
look
at
that
he's
got
a
draft
in
lamps
that
needs
to
get
adopted,
but
I
mean
I
guess,
that's
not
our
problem
right.
C
C
And
okay
and
then
there
was
ari,
which
we
had
a
adoption
call
and
well
when
it
was
presented
in
vienna
and
the
previous
meeting.
There
was
a
lot
of
enthusiasm
in
the
room,
a
virtual
room
at
least,
and
then
we
called
for
adoption
and
heard
pretty
much
nothing
from
on
the
mailing
list
so
yeah.
How
do
we
deal
with
that?
Well
anyway,
we
do
have
a
presentation,
so
we
might
want
to
delay
the
that
discussion
until
today's
presentation,
okay
and
with
that
it's
time
for
acme
detail
nowadays,.
C
H
Very
short,
yes:
so
go
ahead
to
the.
H
Yeah,
so
the
good
news
is
that
there
has
not
been
any
further
changes
since
the
last
ietf.
These
are
really
the
same
notes
as
before
summarizing
the
last
changes
in
the
document.
H
The
bad
news
is
that
there
hasn't
been
any
feedback
or
real
progress.
So
far
on
this,
the
the
cose
document
is
still
in
in
off
48,
which
isn't
a
huge
hold
up
and
the
I
don't
have
it
on
this
slide,
but
the
the
corresponding
dtn
document
to
add
a
missing
iana
registry.
That's
needed
here,
is
still
being
requested
for
working
group
adoption,
but
it's
also
not
a
controversial
thing,
any
other
working
group.
H
Oh,
I'm
sorry!
Well,
the
the
last
ietf
ended
up
with
this
requesting
a
last
call,
since
there
were
changes
in
function,
changes
in
on
the
wire
encoding
on
on
this
behavior
for
the
the
algorithm
agility.
A
F
Yeah,
I'm
just
pulling
up
the
way
I
yeah,
so
we
went
to
itf
last
call
a
bunch
of
things
were
kind
of
requested.
We
made
breaking
changes
in
the
protocol
and
I
think
the
call
on
the
list
was.
Can
we
confirm
that
people
put
eyes
on
those
changes
and
we're
good
to
go?
It's
I
think
it's
like
a
consensus,
recheck
question,
because
adam
last
call
we
did
to
make
breaking
changes
like
separating
separating
the
bundle.
H
C
B
E
C
A
Okay,
so
we'll
reiterate
the
request
for
review
and
look
and
see
how
many
reviews
you
already
had.
I
think
you
had
a
couple
right
and
we'll
see
if
we
can't
push
this
along.
B
B
Most
of
the
changes
here
are
pretty
small,
a
few
people
spotted
some
minor
typos
and
we
got
those
cleaned
up.
There's
some
good
discussion
on
the
mailing
list
about
why
other
solutions
aren't
viable
solutions
to
the
set
of
problems
that
this
draft
solves,
and
so
I
updated
some
of
the
text
in
the
introduction
to
better
address
those
questions
and
clarified
the
suggested
renewal.
Algorithm
next
slide.
B
So
this
is
just
the
one
thing
that
is
like
actually
slightly
substantive,
the
there's
text
in
the
draft
that
describes
what
a
client
should
do
with
the
information
about
its
requested
renewal
window,
and
previously
it
was
phrased
that
the
client
must
perform
a
specific
set
of
calculations
and
then
simply
should
renew
at
the
time
resulting
from
that
set
of
calculations
and
some
people.
B
Obviously,
I
would
like
people
to
take
a
look
at
this.
Slightly
changed
text
provide
feedback
about
it.
Let
me
know
if
it
makes
sense
if
it
seems
like
a
reasonable
way
to
standardize
this
etc,
but
I
think
all
of
that
will
be
part
of
just
the
the
current
round
of
document
review
next
slide.
B
Yeah
so
next
steps-
I
just
slightly
updated
the
draft,
so
I
need
to
go
back
and
update
the
current
implementation
to
match
the
the
very
latest
version,
but
that's
not
hard.
At
this
point
and
after
the
last
ietf
deb
sent
out
an
email
asking
for
a
call
for
adoption,
review
and
feedback
and
support
for
call
for
adoption.
B
There
was
a
small
amount
of
discussion
on
the
list
and
I
have
addressed
all
of
the
feedback
received
from
that
discussion
so
far,
but
I
think
the
next
big
step
is
whatever
the
chairs
want
to
do
with
the
discussion.
That's
happened
so
far.
That's
all
I've
got.
A
So
I
think
we
need
more
review
on
this
right
when
it
does
need.
When
we
ask
for
the
call
for
adoption,
we
need
people
to
pop
up
and
say
whether
they
think
it
should
be
adoption
adopted
or
not.
So
I
think
we're
going
to
redo
the
call
for
adoption
again
and
hopefully
we'll
get
more
people
popping
up
and
saying
yeah.
We
want
this.
E
C
C
One
of
the
polls
here
I'm
sure
we
would
get
like
10
people
or
20
people
saying
yeah.
We
should
adopt
this,
but
then,
when
you
ask
them
the
list,
nothing
right.
B
There
is
currently
support
for
adoption
from
two
people-
melinda
shore
and
peter
thomason,
and
that's
that's
it
on
the
list
so
far,
yeah.
A
C
Saying
what
we're
saying
is
that
don't
assume
that,
just
because
you
said
yeah,
let's
adapt
it
to
the
meeting
that
it
applies
to
the
formal
call
for
adoption.
Yes,
rich.
G
A
C
Okay,
because
these
polls
don't
appear
in
the
youtube
recording
we're
running
a
poll
now
that
says,
should
we
adopt
ari
and
so
far,
we've
had
well
I'll
wait
for
the
final
results
which
declare,
I
guess.
C
D
C
A
K
Well,
everyone
I'm
brandon
weeks,
I'm
from
google
just
to
clarify
I'm
on
our
security
team
and
specifically
our
corporate
security
team.
So
I
do
not
represent
any
products
whatsoever.
I
have
no
influence
over
product
direction.
K
Tldr,
why
am
I
here?
This
is
a
specification
and
it's
relatively
simple
that
combines
the
web
authentication
statement,
format,
which
is
effectively
a
key
value
pair,
where
the
key
is
a
attestation
format
that
it
exists
in
a
registry
and
the
value
is
a
format
specific
series
of
bytes
with
acme.
The
reason
I
care
about
this
is
this
seems
like
an
ideal
way
to
issue
client
certificates
for
primarily
things
like
laptops,
workstations
and
servers,
but
I
don't
think
there's
any
reason
that
the
specifications
necessarily
be
restricted
to
that
I
can.
K
K
So
why
acme
there's
numerous
certificate
enrollment
pro
protocols?
Most
of
them
are
ietf
specs.
However,
skep
remains
the
standard
for
operating
system.
Vendors
device
management,
vendors,
cmp
est,
cmc.
All
of
those
specifications
haven't
really
seen
any
adoption
from
operating
system
vendors
while
they
might
be
adopted
in
networking
gear.
K
K
K
So
what
makes
this
a
good
time
to
do
this?
This
is
probably
the
first
time
we
can
say
that
most
of
the
devices
that
are
purchased
and
deployed,
at
least
in
enterprise
environments,
actually
have
a
way
to
do
a
device
identity
at
the
station
and
the
device
can
identify
itself
and
speak
for
itself
without
users.
So
on
android,
we've
had
android
kia
station
since
7.0,
which
is,
I
think,
over
five
years
old
apple,
introduced,
managed
device
out
to
station
this
wwdc,
so
on
ios.
K
K
The
rats
eat
specification
is
attempting
to
build
a
standardized
way
of
doing
attestation,
statements
that
doesn't
involve
having
four
different
five
different
specifications,
and
I
would
one
day
like
to
include
that.
But
today
we
have
the
formats
that
we
have
and
tpms
is
probably
the
most
well
known,
and
this
is
what's
mostly
used
on
linux
windows
and
other
operating
systems
that
don't
have
proprietary
attestation
schemes
next
slide.
Please.
K
So
web
authent
is
already
got
mindshare,
as
seemingly
the
de
facto
format
for
encapsulating
and
abstracting
different
attestation
formats
across
vendors
apple
already
adopted
it
in
their
apotest,
which
is
their
anonymous
attestation
that
is
provided
to
app
developers
and
they've
since
adopted
for
their
managed
device
at
a
station
feature
that
is
their
non-anonymous
feature
for
managed
enterprise
devices.
K
I've
discovered
this
week
that
there's
two
other
ietf
drafts
that
were
presented
at
114
that
also
made
independent
decisions
to
use
the
same
format
there's
one
for
including
attestation
formats
in
tls,
and
there
was
another
four
essentially
back,
porting
this
to
cmp
and
est
and
existing
like
older
certificate
protocols
and
like
acme
web
authent,
enjoys
fairly
ubiquitous
library,
support
across
languages
and
across
platforms
almost
like
every
vendor
already
had
to
build
this
for
their
browser.
K
So
it
should
be
pretty
easy
to
integrate
into
other
parts
of
their
platform
next
slide.
Please.
F
Hi
everyone
before
we
jump
off
that
for
anyone
that
was
in
lamps,
maybe
shauna
rich,
didn't.
We
learn
that,
after
some
discussion
with
the
the
designated
experts
for
the
web
authent
registry,
that
the
approach
wasn't
what
we
thought
it
was
going
to
be
for
that
lamps
document.
F
K
Yeah,
I
believe
the
outcome
was
there
are
the
attestation
formats
that
are
already
defined
in
web,
offend
there's
an
extensible
registry
for
that
exists
already
for
formats.
That
would
make
sense
for
the
primary
use
case
of
web
authent
and
we'll
likely
need
to
create
an
additional
registry
for
formats
that
don't
fit
into
like
the
actual
web
off
and
fido
scheme.
L
K
K
Yeah
go
ahead.
I
I
K
I'm
not
sure
what,
if
this,
if
the
correct
answer
is
a
separate
draft
or
being
included,
I
will
say
that
the
draft
I'm
proposing
is
fairly
narrow.
It
only
works
it's
for
devices,
it's
not.
It
doesn't
touch
certificates
issued
to
users
or
authenticating
users,
it
doesn't
touch
code
signing
and
it
doesn't
touch
devices
that
lack
the
ability
to
attest
their
own
identity.
K
So
this
is
a
fairly
narrow
focus
and
the
the
web
offend
usage
in
the
client
certificate
draft
is
around
actually
using
the
full
web
offense
spec.
This
is
narrowly
tailored
to
only
using
datastation
statement
format
as
an
encapsulation
for
attestations.
The
rest
of
web
authent
has
is,
has
nothing
to
do
with
this
proposal.
L
A
L
This
working-
yes,
wonderful,
okay,
yet
another
device
hi.
So
I've
been
asked
to
come
here,
so
I'm
swinging
by
the
lamps
id
says
that
they
use
cryptographic
attestation
in
order
to
establish
the
provenance
of
a
key,
that's
fine,
but
that
is
not
what
a
tpm
does
in
general.
L
That's
just
one
of
the
tiny
things
that
tpm
does
the
gpm
creates
evidence
about
the
system
characteristics
that
can
prove
its
trustworthiness,
which
has
nothing
to
do
with
the
web
off
and
also
it
does
not
do
that
but
they're
also
not
it's
true.
That's
not
entirely
true,
and
two
can
do
that
optionally,
which
makes
me
happy
to
hear
when
you
say
that
it's
just
about
framing
I'm
putting
the
evidence
inside
and
I
think
that's
the
term.
L
I
want
to
hear
here
if
you're
talking
about
the
authenticity
of
a
device,
that's
phosphory,
meaning
it
is
doing
exactly
what
is
intended
to
do
and
nothing
else.
Then
I
think
you
are
absolutely
go
okay
with
saying
attestation
evidence,
but
please
differentiate
between
the
the
web
off
and
capabilities,
the
fact
that
they
say
over
500
times
at
the
station
and
only
mean
it
like
four
times.
L
I
think
between
the
tpm
capability
and
and
the
other
ones,
so
just
define
are
you
creating
assertions
that
are
actually
believable
about
the
trustworthiness
or
are
you
really
talking
about
key
provenance
which
are
which
is
part
of
the
first?
But
it's
absolutely
not
the
first,
but
it
said
just
highlighting
that.
K
Thank
you.
That's
helpful.
Tpms
have
many
many
things
it
can
do
in
lots
of
options,
but
what
the
rest
of
the
attestation
schemes
actually
do
in
reality
is
relatively
simple:
they
provide
evidence
that
the
key
was
generated
in
hardware
and
they
provide
an
identity
of
the
device.
K
That's
associated
with
that
so
for
tpms
to
kind
of
exist
side
by
side
of
these
other
attestation
schemes
we're
really
just
using
key
certification
along
with
either
the
endorsement
key
or
the
platform
or
the
endorsement
certificate
or
the
platform
certificate
to
establish
the
identity
of
the
device.
L
Sorry
for
interrupting
just
state
that
up
so
don't
use
the
term
like
at
the
station
just
state
what
you're
doing
like
you
just
did
and
then
mint
the
term
in
the
context
of
your
work.
That's
fine,
you
can
call
it
grab
it
doesn't
matter.
The
important
thing
is
people
understand
what
you're
actually
talking
about
and
and
think
that's
a
big
problem
with
throwing
the
term
attestation
around,
because
it
means
nothing
anymore.
L
If
it
you
don't
can't
even
say
it's
a
if
it's
a
procedure
or
a
message,
so
if
you're
at
that
level,
I
think
really
talking
about
the
exact
thing
and
defining
it
and
then
naming
it
is
a
better
way
around
and
then
everybody
would
be
happy
and
then
you
can
tie
android
key
to
station
and
gpms
and
apple
here
to
take
whatever
I
do
there
and
then
that
will.
L
K
How
many
thanks
thank
you
for
the
feedback,
so
what
is
the
actually
contained
in
the
extension?
It
specifies
a
new
challenge
type
when
this
challenge
type
is
presented
to
a
client.
The
client
returns
a
web
authentication
statement
format
in
the
response,
payload
the
challenge
response,
payload,
which
is
not
done
by
any
other
challenge
types
anymore
of
today,
but
the
high
level
acme
specification
does
have
language
around
future
specifications
may
do
this.
K
K
It
also
uses
the
acme
specified
key
authorization
as
the
nonce
that's
passed
into
the
key
generation
methods
of
the
various
formats
and
definitely
open
to
feedback.
If
this
is
the
like,
the
intended
use
of
key
authorization
ident,
I
specify
two
identifiers
one
uses
the
rfc
4043
permanent
identifier
to
identify
the
platform.
K
I
also
included
a
hardware
module
identifier
that
was
specified
in
rfc
4108.
However,
I've
gotten
feedback
this
week
that
this
may
not
be
the
best
idea.
The
reason
I
put
that
there
in
the
first
place
was,
if
you
imagine,
a
tpm
device,
tpm
included
in
a
device
that
doesn't
have
an
issued
platform
certificate,
the
that
device
is
actually
unable
to
prove
the
identity
of
the
device.
K
I
also
added
informative
text
around
using
external
account
binding
for
pre-authenticating
requests
to
the
ca.
In
my
experience,
most
enterprise
environments
don't
want
to
have
except
unauthenticated
requests
on
the
open
internet,
so
they're
likely
would
want
to
include
this
in
some
form
of
configuration
management.
That's
pushed
down
to
the
device
before
it
is
able
to
prove
its
identity.
Next
slide.
Please.
K
E
Was
just
going
to
comment
that
I
did
something
similar
in
a
proprietary
implementation
of
a
new
challenge,
type
with
a
challenge
response
that
contained
a
a
jwt
authentication
token
using
the
the
d-pop
work
and
that
seemed
to
work
quite
well.
So
that
seems
like
quite
a
sensible
thing
to
me.
So
thank
you.
Good.
K
So
existing
implementation,
I
created
a
fork
of
small
step,
which
is
a
not
a
fork
per
se
patch
series
of
patches,
a
small
step.
It's
a
open
source,
golang
ca
that,
along
with
a
client
that
implements
this
for
tpm
at
a
station,
and
he
also
includes
a
tpm
simulator
in
case.
You
want
to
run
this
on
a
regular
laptop.
K
The
other
major
implementation
of
this
is
apple's
ios
16
betas
that
uses
this
uses
encoding,
including
an
acme
web
authentication
statement
in
acme
as
the
basis
of
requesting
a
certificate
alongside
skep
and
sending
the
private
key
plus
certificate
in
a
p12
payload
or
the
other
two
methods
they
spot
on
older
versions
and
not
included
on
this
version
of
the
slides.
K
Please,
and
now
I
have
some
questions
for
everyone.
There's
been
some
discussions.
I've
had
this
week
around
the
the
types
of
information
that
can
be
reflected
into
the
client
certificate
that
the
ca
has
validated.
K
What
are
the
relative
trust
levels
of
a
trust,
trust
zone
versus
discrete
hardware
versus
hardware,
on
diverse
hardware,
on
a
bus,
and
is
this
draft?
The
place
should
be,
or
is
that
somewhere
else,
because
that's
a
pretty
hard
problem,
it
sounds
like
and
the
verification
procedures.
This
came
up
on
the
mailing
list.
Someone
asked
okay,
why
would
my
enterprise
ca
trust
any
of
this?
K
Each
of
the
different
attestation
formats
has
various
levels
of
quality
of
documentation,
the
documentation
where
it
does
exist,
there's
often
asterisks
and
foot
guns
that,
if
implemented
improperly
caused
the
system
not
to
be
secure,
and
I
don't
believe,
there's
any
place.
This
is
really
specified.
I
think
web
authent
has
done
the
best
cross
attestation
scheme
attempt
at
documenting,
but
I
know
there's
issues
with
like
it's
not
complete
with
all
of
the
the
foot
guns
and
asterisks.
K
K
J
Sean
turner,
so
in
full
disclosure.
I
am
writing
a
draft
and
lamps
about
this
kid
station
stuff
over
there.
So
I'm
basically
supportive
of
this
approach
for
the
first
one.
It
seems
like
that
is
a
hole
that
you
could
be
buried
in
for
a
long
long
time
did
we
just
set
up
a
registry
and
leave
it
alone,
make
it
first
come
first
serve
and
knock
yourself
out.
J
So
the
mechanism
is
there
to
be
able
to
specify
what
those
things
are
and
just
punt
completely,
because
that
would
be
an
option
to
do
that,
because,
if
you're
going
to
try
to
document
all
of
them,
good
luck,
you'll
come
back
and
you'll
have
a
long
gray
beard
like.
I
do
yeah
the
verification
procedures.
You
have
to
put
something
in
there
right,
but
if
it's,
if
it's
really
that
complicated
but
again,
there's
a
bunch
of
different
options,
I
don't
know
how
you
write
that
right.
So
then
you
end
up
in
this
hole
of
like.
J
K
D
A
A
Then
we're
going
the
wrong
way
if
the
ca
can't
tell
whether
the
device
I
mean
the
device
can't
just
say:
hi,
I'm
a
tpm
without
proof
that
he
is
actually
a
tpm
right.
So
you
have
to
be
able
to
validate
that
now.
It
appears
I've
spent
like
15
minutes
reading
this
stuff.
It
appears
that
android
and
a
bunch
of
places
have
basically
root
cas
that
assert
that
these
are
devices
that
they
have
built.
A
So
that's
fine
within
the
realm
of
how
trustworthy
that
is
seeing
that's
another
rabbit
hole.
So
that
was
my
my
main
when
I
first
saw
this.
My
main
concern
was
who's
this
who,
who
gets
to
decide
whether
this
is
what
it
really
is,
and
I
can't
self-assert
like
self-assertion
should
not
be
possible.
Oh
my
opinion.
So
that's
that's
part
of
it.
There
was
had
another
point.
What
was
it.
A
I
think
you
can't,
when
you
talk
about
key
generation
and
the
quality
of
key
generation,
there's
no
way
for
a
ca
or
of
a
lying
party
to
know
how
well
you've
done
key
generation
and
you're
back
to
basically
self-assertion
at
that
point.
There's
no
way
for
an
acme
ca
to
know
that
this
tpm
over
there
did
it.
This
way
for
real.
K
K
When
you
generate
a
key,
the
the
policy
is
encoded
in
a
string
that
is
signed
and
verifiable.
So
if
the
key
is
not
generated
in
the
expected
manner,
so,
for
example,
tpms
allow
key
importation
and
they
also
allow
key
generation,
and
you
can
actually
tell
the
difference
whether
a
key
was
imported
or
generated
it.
K
Can
it
provides
evidence
whether
it
was
rsi
or
ecdsa,
and
if
you,
if
you're
in
an
environment
that
has
a
attestation
ca
or
a
private
cca,
that
is
willing
to
de-anonymize
clients,
as
is
in
an
enterprise
environment,
the
privacy
ca,
can
pass
along
the
identifiers
included
either
in
the
endorsement
key
certificate
which
identifies
the
gpm
chip
itself
or
the
platform
certificate
which
identifies
the
the
combination
of
a
tpm
and
a
platform.
K
K
A
Yeah,
okay,
so
there's
pitfalls
here
I
think,
is
probably
the
best
way
to
say
that
I
am
generally
untrustworthy
of
these
things,
so
maybe
I'm
a
little-
and
this
is
no
hats
by
the
way.
This
is
just
me.
K
Since
monty
is
staying
right
behind,
I
will
pick
on
the
trusted
computing
group.
A
little
bit.
Android,
chrome,
os
and
apple
have
implemented
their
attestation
schemes
in
a
way.
So,
for
example,
apple's
managed
device
attestation
if
it
generates
a
key
at
all
and
it
produces
an
agitation
certificate
that
was
generated
in
their
secure
enclave.
Processor,
there's
no
other
way
to
get
so.
M
The
trust
in
the
the
tpm
monty
wiseman,
by
the
way,
the
trust
of
the
tpm,
is
anchored
in
whoever
signs
the
ek
certificate,
which
says
who
made
the
tpm
that's
really
not
any
different
than
trusting
apple
to
say
the
key
and
the
t2s.
The
same
is
good.
Just
in
android,
that's
really
not
any
different
than
trusting
infineon
to
make
the
tpm
the
only
real
difference
is
it's
portable
across
platforms.
M
So
anyway,
I'm
gonna
go
on
the
other,
the
other
topic.
The
reason
I
came
up
here
is,
I
think,
a
document
like
this
is
a
really
good
place
to
put
values.
You
know
maybe
hardware,
I
don't
I'll
make
the
same
comment
I
made
in
lamps.
I
think
it's
going
to
be
hard
with
a
binary
assertion
of
hardware
versus
not
hardware,
but
the
distinction.
M
Any
distinctions
we
made
about
we
make
about
quality
should
not
go
in
here
needs
to
go
somewhere
else;
otherwise
it
becomes
exactly
the
same
comment
labs.
So
we're
gonna
have
to
find
a
way
to
enumerate
these
somehow
right
to
make
any
value
assertion
between
a
software.
Tpm.
That's
running
in
my
process
that
I
have
happen
to
have
an
ek
signed
by
something
on
my
platform
and
an
affinian
tpm
or
something
else.
We
have
to
find
some
way
to
make
a
distinction
between
those
something
like
this
doesn't
need
to
worry
about
that.
M
C
B
Aaron
yeah
having
having
read
the
stock
when
it
first
went
out
on
the
mailing
list.
I
I
think
it's
completely
appropriate
for
this
document
to
not
specify
exactly
what
the
ca
is
supposed
to
do
in
order
to
determine
whether
it
trusts
the
attestation
that
it
receives,
because
that's
a
matter
for
like
five
different
documents,
because
it
is
very
difficult.
The
thing
that
surprised
me
was
that
this
document
didn't
talk
about
that
at
all.
B
I
was
expecting
a
paragraph
that
was
like
and
when
you
receive
the
key
attestation,
you
should
make
sure
that
you
trust
it
via
informative
reference
to
some
other
set
of
things
that
might
be
useful.
Instead,
it
was
just
like
the
ca,
gets
the
attestation
back
and
is
good
to
go,
and
I
was
like
I
am
very
confused
now,
so
so
some
sort
of
reference
to
the
fact
that
this
is
a
hard
problem
and
ca's
need
to
do
it
correctly
would
be
very
appropriate.
But
I
don't
think
it
should
be
fully
specified.
K
C
Hi
yeah.
I
agree
that
there's
a
lot
missing
in
the
document
like
there's.
No
no
example
of
the
posters
get
with
the
new
identifiers,
but
that's
fine
and
it's
really
a
zero
zero
version.
C
E
C
The
second
question
here:
well,
I
thought
so
maybe
you
don't
hear
me
no.
A
C
Okay,
thank
you.
So
so
you
have
some
open
questions
for
us.
We
have
an
obvious
question
for
you.
Are
you
seeking
adoption.
K
Yes,
I
am
in
consideration
of
vendors
already
beginning
to
support
this.
I
would
love
to
get
as
much
feedback
about
bachelor
encoding
of
the
requests
as
soon
as
possible.
I
think
there's
been
broad
interest
on
the
mailing
list
for
someone
to
write
something
whether
it
be
an
existing
draft
or
a
new
draft.
It
does
seem
like
people
are
attempting
to
use
kieva
station
and
acme
and
cmp
and
est
and
tls,
and
seems
to
be
a
very
prominent
topic
this
year.