►
From YouTube: IETF115-ACME-20221110-1530
Description
ACME meeting session at IETF115
2022/11/10 1530
https://datatracker.ietf.org/meeting/115/proceedings/
B
B
B
Good
we
allocated
like
five
minutes
for
this
and
we're
one
minute
in
and
we're
already
through
that
so
we're
ahead
of
time.
Good
then
we're
going
to
do
document
status,
talk
about
current
work
items,
that's
just
DK
node
ID,
because
there
has
been
much
progress
in
the
other
stuff
and
we're
not
going
to
talk
about
potential
new
work.
B
All
right
so
document
status
well,
third,
meeting
in
a
row
that
we
have
don't
have
any
new
rfcs.
The
last
one
was
published
in
September
of
last
year,
but
we're
going
to
break
this
bad
streak
because
Authority
token
is
approved
and
it's
going
to
be
in
the
RFC
and
tsq.
So
with
some
chance
of
having
it
published
before
116..
Okay,
Acme
client
has
just
been
allowed
to
expire
with
no
continued
interest.
Ari
is
now
a
working
group
draft
Authority
token
TN
auth
list.
B
A
C
Hi,
this
is
Remington
Elio,
responsible,
Ag
and
yeah.
Talking
about
the
dtn
one
I,
don't
know
which
slide
kind
of
we
want.
I
I
want
to
get
a
sense
for
what
the
plan
is
here
because
I'm
starting
to
feel
like
we
took
this
document
too
early.
So
as
I
rewind
the
history
we
started
the
document
then
dtn
changed
on
us.
We
had
to
rev
the
document
and
then
we
revved
it,
and
then
we
were
ready
to
go
ahead
and
then
we
decided.
Oh
wait,
wait!
C
A
A
E
D
D
D
C
A
A
F
A
B
A
E
B
E
That
is
we're
allocating
a
code
point.
We
need
the
place
to
put
the
code
point.
There
was
an
eye
and
a
registry,
but
it
was
not
properly
updated
in
the
dtn
working
group,
as
actually
in
between
the
time
these
slides
were
prepared,
and
today
the
dkm
working
group
has
adopted
the
document
that
corrects
the
Ayana
registry,
and
at
this
point
it
seems
like
if
Acme
working
group
is
happy
with
this
document
as
is,
and
it
can
live
in
a
state
that
is
waiting
in
a
kind
of
an
approval
cluster.
E
C
Responsible
ID,
so
we
are
currently
sitting
in
this
document
in
a
halfway
state.
It
is
out
of
the
word
group,
it's
in
my
hand,
so
we
we
have
not
yet
sent
it
to
the
isg.
Given.
Where
we've
been
with
this
document,
it's
I'm
going
to
keep
it
there
until
I
see
the
dtn
document
progress
a
lot.
You
know
a
little
further
because
practically
there's
no
difference
between
keeping
it
in
Miss
ref
versus
here,
and
this
document
would
get
discussed
on
anyway
for
not
having
the
kind
of
the
Ayanna
thing
sorted
out.
So
it's
one.
E
A
Right
so
I
think
we're
squared
away
from
an
Acme
point
of
view,
I
think
from
a
dtn
point
of
view.
Stephen
and
I
are
going
to
go
talk
to
somebody
sometime
about
other
other
parts
of
dtn,
maybe
algorithm
choices.
Perhaps
things
like
that,
but
we'll
handle
that
offline.
It's
obviously
not
an
acne
business.
So
all
right
so
Roman's
happy
and
it's
a
working
group
draft
I
think
we're
good
we'll
let
it
we'll
let
it
sit
for
the
minute.
It's.
D
G
A
C
No,
no,
the
it
depends
on
what
you
say
all
what
all
the
other
drafts
are.
This
one
is
the
only
one
notionally
parked,
which
is
we
we're
waiting
literally
for
someone
else
to
do
something.
That's
outside
the
working
group,
all
the
other
documents
we
actually
very
concretely
know
what
needs
to
get
done
and
the
power
to
change
it
is
inside
the
working
group.
So
that's
why
I'm
distinguishing
it
from
the
perspective
of
the
working
group?
C
A
D
A
H
H
For
that-
and
the
second
is
there-
was
discussion
114
about
if
we
should
reuse
the
identifiers
from
web
authen
exactly
as
they're
specified
in
WC3
or
if
we
should
create
a
new
Iron
Iana
registry
and
the
consensus
was
create
a
new
registry,
so
I
added
the
text
that
Carl
added
to
his
draft,
which
is
encapsulating
the
exact
same
types
of
attestation
into
my
draft.
So
thank
you
Carl
next
slide.
Please.
H
H
H
So
there's
three
concurrent
drafts
at
the
ITF
that
all
attempt
to
essentially
do
the
same
thing,
which
is
take
a
vendor
specific
attestation
evidence
this
can
be
either
an
x509
certificate
with
an
extension
or
this
can
be
in
the
TPM
case,
a
bunch
of
byte
arrays
and
include
them
either
in
a
shift.
Your
request,
in
the
case
of
the
first
two
drafts
or
in
a
TLS
handshake
in
the
last
draft
or
middle
draft,
is
the
TL
Centric.
H
It
seems
to
everyone
I've
spoken
with
that.
The
best
course
of
action
is
to
have
all
of
these
drafts
use
the
same
encapsulation
format
since
114
the
Carl
Wallace's
draft
has
been
adopted,
so
that's
actually
wrong.
It's
draft
lamps
yellow
station
now
and
the
TLs
draft
has
had
a
revision
that
actually
now
moves
away
from
the
same
encapsulation
format
that
the
other
two
drafts
use.
So
this
is
the
thing
I
think
that
needs
the
most
feedback
from
the
working
group.
H
I
H
Yeah,
multiple
attestation
schemes
use
x59
certificates
as
containers
for
attestation
evidence
and
then
those
are
during
coded
and
stuck
into
the
encapsulation.
So
in
my
draft,
that's
borrowed
from
the
Web
author
and
attestation
statement.
So
it's
just
a
seabor
key
value
pair.
The
key
exists
in
the
Iana
registry
for
the
attestation
formats
and
the
value
is
whatever
vendor
specific
thing.
H
H
So
since
one
run,
four
there's
actually
been
two
implementations
of
the
draft
that
are
not
by
me.
The
first
exists
in
buried
deep
inside
Apple's,
managed
device
attestation
feature
that
exists
in
iOS,
16
and
TV
OS,
something
and
it
also
exists
in
the
step.
Ca
certificate
Authority.
It's
a
open
source,
Acme,
CA,
developed
by
small
step
and
I
believe
these
two
interoperate
as
of
today
response.
H
A
A
B
A
H
B
F
There's
nothing
wrong
with
being
in
the
lead
you're
of
I'm
just
going
to
do
a
little
Cherry
from
the
floor
and
suggest
that,
like
this
seems
like
something
where
the
broad
outlines
are
clear,
you
know
the
use
cases
clear.
The
approach
is
clear:
there
is
a
nuances
to
be
worked
at
in
terms
of
some
of
the
coordination
stuff
it's
been
mentioned,
but
I
think
this
is
more
than
ready
for
an
adoption
call.
So
I'd
encourage
to
just
go
ahead
and
call
for
that.
B
J
I
just
wanted
to
address
Deb's
Point
about
there
are
lots
of
different
types.
That's
that's
intended
this.
This
draft
is
basically
an
abstraction
layer
for
stuff
that
exists
in
the
wild
because
we're
not
going
to
have
a
draft
per
thing
that
exists,
so
the
web
authent
gives
us
a
means
to
say
that
we're
supporting
an
apple
attestation
or
Google
at
a
station
or
a
ubico
at
a
station,
or
what
have
you
through
that
format
where
we
diverge
and
I
haven't?
J
B
A
A
D
A
F
K
Hello,
hello,
thank
you
great
things
from
Switzerland
I'd
like
to
present
a
new
proposal
here
at
DNS
account
one.
So
next
slide,
please
we
already
know
dns01,
it
is
an
existing
Challenge
and
it
is
specified
in
RFC
8555
next
slide.
Please,
basically,
it
works
with
storing
a
random
value
in
a
txt
record
under
underscore
ahmeda's
challenge.
Next
slide,
please,
however,
some
people
just
have
a
DNS
server
that
cannot
easily
be
automated.
K
Maybe
it
reads:
A
Zone
file
from
disk
doesn't
play
well
with
Acme
clients,
so
a
frequent
setup
is
to
have
a
SIM
name
record
to
a
DNS
server
that
supports
an
API
or
a
database
on
the
back
end,
or
something
like
that.
So
so
this
setup
exists
and
it
has
a
few
problems
next
slide.
Please,
one
of
the
use
cases
we've
heard
about
is
a
multi-region
deployments
where
a
service
exists
in
a
deployment
where
there
are
multiple
regions
that
are
independent
from
each
other,
so
the
operators
do
not
want
any
dependencies.
K
Basically,
all,
but
one
regions
can
go
down
in
the
service
would
still
be
able
to
function
next
slide.
Please
another
scenario:
we've
seen
is
zero.
Downtime
migrations.
Maybe
someone
is
moving
from
a
cloud
provider,
for
example,
to
an
on-premises
setup,
and
this
migration
can
take
months
like
multiple
multiples
of
the
lifetime
of
short-lit
certificates,
so
they
need
to
be
able
to
issue
certificate
from
both
the
old
setup
and
the
new
one
in
order
to
ensure
that
the
service
continues
to
work
next
slide.
K
Please,
and
in
all
of
these
scenarios,
like
people,
don't
want
to
have
to
run
every
60
days,
they
don't
want
to
have
to
go
and
run
search,
Bots
there
and
SCP
the
private
Keys
around
and
do
any
of
these
things,
and
they
also
don't
want
to
have
any
downtime
like
when
they
do
the
migration.
They
want
the
search
to
be
already
there.
K
They
don't
want
to
change
the
records
and
then
just
hope
that,
like
for
a
few
minutes
until
the
TLs
sets
can
be
issued,
traffic
will
be
dropped
and
in
general,
some
of
them
either
for
compliance
reasons
or
operational
reasons.
They
try
reliability.
They
try
to
have
no
dependencies
between
those
regions.
K
So
next
slide.
Please.
The
problem
here
is
that
if
you
have
a
cnname
record,
it
has
to
point
to
somewhere.
It
has
to
point
to
a
DNS
server
next
slide,
but
you
cannot
have
two
c
Name
Records
due
to
how
DNS
works
you
you
just
can't
have
two
senior
records
of
points
to
the
old
and
the
new
setup,
all
to
five
synonyms
one
per
region
next
slide,
please!
So
that's
why
we're
proposing
to
address
these
regions
and
a
few
others
were
proposing
DNS
account
or
one.
K
We
don't
intend
to
replace
the
ns01
with
this.
This
is
just
an
additional
challenge
that
we
want
to
introduce
next
slide.
This
is
what
the
label
looks
like.
Instead
of
just
underscore
Acme
does
challenge.
It
also
has
an
ID
and
next
slide
here
you
can
see
the
first
point,
which
is
this.
This
unresolved,
let's
say
comment,
and
it
is
the
use
of
the
underscore
there.
Why
is
it
not
a
dash?
K
The
standard
works
there.
There
are
no
problems,
even
if
it
becomes
a
dust.
The
reason
we
did
that
was
basically
so
the
fields
can
be
separated
because
Acme
and
challenge
are
technically
the
same
field.
So
we
wanted
to
separate
it
visually
better,
but
there
is
no
technical
concern
there
like
we're
happy
to
change
it.
If
you
want
next
slide,
please
so
about
this
ID
here.
K
What
is
it?
How
is
it
generated
in
the
next
slide?
You
can
say
that
we've
basically
take
the
Acme
account
resource
URL.
This
is
defined
in
the
RFC
8555
and
we
calculate
the
hash
of
it.
We
take
the
first
10
bytes
and
then
we
base
32
this.
This
entire
thing
and
the
reason
we
chose
the
account
URL
is
because
every
region
or
every
service
you
use,
has
a
different
Acme
account.
So
it
works
fairly
well
to
separate
between
them.
K
If
we
did
it
pair
CA,
it
may
not
have
been
flexible
and
it
also
survives
account
Acme
account
key
rollovers,
so
you
can
replace
the
keys
and
you
still
have
the
same
ID
there
and
the
reason
we
pick
10
bytes
is
so
it's
we
needed
something
that
does
not
have
a
lot
of
collisions.
It's
not
long
enough
to
to
create
problems
with
DNS,
and
it's
also
exactly
at
the
Block
size
for
base
32.
So
it
doesn't
have
any
padding
in
the
end,
like
the
equal
signs.
Next
slide.
K
Please
here
you
can
see
another
comment
we
received
like
how
do
we
denote
the
first
10
bytes,
because
in
some
programming
languages
like
the
last
digit
is
excluded?
We
just
opted
for
the
mathematical
notation
and
we
also
Define
it
in
the
text
that
this
means
the
first
time.
Bytes
next
slide,
please
so
here
every
region
or
every
use
case
it
can.
K
It
has
a
basically
a
different
Acme,
a
different
DNS
label,
so
you
can
create
as
many
of
them
as
you
want,
and
you
can
see
name
each
one
individually
and
have
them
point
to
your
automatable
DNS
server
next
slide.
Please
also
akumi
is
not
about
only
a
webpki
and
publicly
trusted
cas,
so
we
wanted
to
check
make
sure
that
it
works
well
for
this
use
case
and
we
looked
at
the
next
slide.
K
We
looked
at
the
cab,
Forum
Baseline
requirements,
section
32247
it
allows
issuance,
so
any
publicly
trusted
CA
can
use
it
today.
If
they
want
to,
we
don't
have
to
go
through
any
ballots.
We
don't
have
to
get
any
approvals.
It
can
start
working
today
and
basically
that's
the
presentation
in
the
next
slide.
You
can
see
some
resources
like
the
the
draft
and
the
URL
of
the
data
tracker
and
the
rest
of
the
time
about
two-thirds
of
it.
I
think
we
have
for
questions
or
comments,
foreign.
A
F
F
Of
having
the
text
to
clarify,
so
that's
not
a
big
deal,
I
seem
to
recall.
We
had
a
bunch
of
discussion
on
the
list
about
various
options
here,
and
this
is
the
one
that
seems
to
meet
all
of
the
requirements.
So
this
this
seems
like
reasonably
put
together.
I
would
be
ready
for
an
adoption
call
on
this.
A
K
If
can
I
add
a
few
notes
as
well,
since
we
have
some
time,
we've
posted
something
on
on
mdsp
for
Mozilla
to
try
to
get
to
see
if
there
are
any
problems
with
that
and
they
were
happy
with
the
solution
and
we
have
a
working
implementation
in
a
testing
environment
for
over
two
years
now
and
in
production
limited
so
not
available
to
to
many
people
for
a
few
months
now.
So
there
is
also
implementation
of
this.
F
K
Now
it
will
not
in
the
previous
slide,
you
can
see
the
section
basically
any
value
that
any
DNS
label
that
starts
with
an
underscore,
and
it
is
immediately
after
the
domain
that
you
want
to
validate
works
and
dns01
is
the
only
challenge
that
works
for
wildcard
certificates
as
well,
which
is
one
of
the
main
issues
people
had
with
with
the
other
challenges.
So
so
it
shouldn't
require
anything
from
the
cab
forum
and
it
can
be
used
today.
G
Yeah
Tim
hellaby
for
digital
apologies
for
not
using
the
automated
thing.
I
think
you
might
actually
have
a
few
cab
form
problems
that
you
haven't
anticipated
and
in
particular,
because
it
looks
like
I
just
reviewed
this
really
quickly.
But
it
looks
like
the
the
validation
method.
That's
for
Acme
basically
says
use
855
and
8555
says
at
the
Acme
Challenge
and
doesn't
have
support
for
this
additional
stuff.
That
you're
adding
so
I
think
that
you
would
have
to
update
the
validation
methods
to
allow
this.