►
From YouTube: IETF-ACME-20210929-1800
Description
ACME meeting session at IETF
2021/09/29 1800
https://datatracker.ietf.org/meeting//proceedings/
A
B
A
E
A
So
I
have
I've
used
the
managed,
slide
thing
and
uploaded
them
manually
because
it
wasn't
didn't
seem
to
be
doing
it
straight
from
the
data
tracker.
So
when
I
look
at
managed
slides,
I
see
three
decks
ready
to
be
shared,
but
I
don't
see
any
way
to
actually
get
them
to
show
up
like
shouldn't.
I
be
able
to
click
the
little
meeting
material.
F
C
C
A
C
H
A
C
Well,
the
agenda
says
that
we
first
talked
to
with
reminding
people
about
the
note
well,
which
we
totally
should
so
yes
welcome
everyone
to
the
acme
meeting,
and
this
is
an
official
itf
meeting
so
note
12
does
apply.
We
didn't
prepare
a
slide
with
the
note
well,
but
you've
all
seen
it
before.
So
you
know
what
it
says,
and
you
know
what
you're
supposed
to
do
and
what
you
are
not
supposed
to
do
right.
C
C
B
B
B
The
end
result
is
that
this
draft,
and
on
the
next
slide
I'll
talk
about
some
small
upcoming
change,
but
there's
still
no
change
in
in
any
of
the
bundle
protocol
on
the
wire
encoding
or
any
of
the
logic
related
to
the
the
transport
and
there's
also
no
changes
to
the
acme
side
of
the
logic
outside
of
the
identifier
name
changed
and
the
certificate
claim
is
changed,
but
the
logic
of
what's
being
done
and
how
it's
being
done
besides,
that
have
been
unchanged.
So,
if
you
skip
to
the
next
slide,
please.
B
So,
taking
that
in
mind,
the
the
easiest
thing
to
do
here
is
to
just
extract
that
portion
of
this
draft
document
into
a
dtn
working
group,
a
very
small
update
document
and
use
that
as
a
normative
reference
here
that
the
clarification
the
update
is,
is
a
bookkeeping
minor
in
a
registration
thing
on
the
bundle
protocol
side.
But
it
is
necessary
because
this
is
the
registry
that
the
node
id
validation
mechanism
here
is
using
to
to
declare
these
new
administrative
bundle
types.
B
C
B
H
H
D
Hi
brian,
I
first
off
I
had
the
same
question
you've
had,
but
you
you
answered
now
that
you
said
you
know
all
the
coordination
in
the
dtn
working
group.
So
I
guess
all
I
wanted
to
say
is
kind
of
thank
you
for
making
all
these
changes
and
banjoras
spanning
between
acme
and
dtm,
to
try
to
harmonize
all
that.
I
know
it
took
a
lot
of
effort.
So
much
appreciated.
G
B
That
is
where
the
actual
certificate
profile
is
located
and,
unfortunately,
because
of
the
the
timing
of
these
updates.
The
reference
from
this
acme
document
is
revision
26,
but
the
actual
latest
one,
the
actual
one
that
has
made
the
change,
is
revision
27.,
okay,
thanks
and
you
can
see
the
diff
on
that
document
that,
where
it
used
to
say
stan
uri
now
says
the
other
name,
and
it
gives
a
full
explanation
of
the
other
name
encoding
and
all
that.
D
D
B
D
D
C
C
I
What
subject
alters
them
to
include.
There
was
a
lot
of
discussion
on
the
matters
about
this
over
the
last
couple
of
months
and
we've
reached
consensus
on
an
agreed
approach,
and
there
is
a
very
traffic
draft
in
github
at
the
moment
on
how
to
update
csr
attribute
handling
in
70
30..
It
will
be
published
before
ietf112,
but
it's
not
there
yet.
So
we
will
update
the
acme
integrations
draft
to
reference.
I
I
The
authorization
object
to
differentiate
between
the
wildcard
authorization
and
domain
domain,
namespace
authorization
and
the
third
one
which
I'm
completely
on
the
fence,
with
an
open
to
removing,
is
the
changes
to
the
new
order
request
so
that
a
client
can
specify
not
only
the
identifier
at
once
the
identifier
it
wants
to
get
a
certificate
fire,
but
also
the
top
level
domain
name
space
that
it
has
control
over.
I
for
the
use
case
I
have
in
mind.
I
I
think
the
new
authorization
flow
makes
a
lot
more
sense
for
registration
authority
and
the
new
order
flow
makes
less
sense.
So
I'm
perfectly
okay
with
removing
the
change
to
the
new
order
request,
but
it
was
added
as
a
result
of
pretty
extensive,
mirror
discussions,
maybe
six
nine
months
ago,
and
that's-
and
this
is
the
only
update
I
have-
and
I
just
like
to
discuss
these
two
points.
H
The
person
on
the
other
end
of
those
mailing
list
discussions,
I
think
my
conclusion
is
that
I'm
perfectly
happy
having
it
in
the
new
order
flow
as
well
like.
I
think
the
majority
of
my
point
was
from
a
position
of
not
having
observed
and
had
all
the
context
for
those
previous
discussions
nine
plus
months
ago-
and
so
I
was
like-
is
any.
I
I
I
But
there's
no
substantive
changes
required
to
draft
it'll,
be
changed
in
language
or
cleaning
up
terminology,
but
I
think
the
overall
flaws
that
are
defined
in
the
draft
don't
need
to
be
changed
and
the
changes
to
one
of
the
objects
are
as
is
so
next
steps,
and
there
was
a
call
for
working
group
adoption.
Are
we
ready
to
bring
this
back
to
the
mailer
and
ask
the
question
again.
C
Well,
we
can
raise
the
question
again,
but
we
will
want
to
have
well
more
than
two
people
who
have
read
the
draft
so
we'll
try
to
see
if
there's
a
good
number
of
people
who
have
read
the
draft,
want
the
draft
or
interested
in
having
it
go
through
the
working
group
and
become
an
rfc
but
yeah.
So
it's
it's
probably
more
advanced
and
more
complete
than
we
usually
want
documents
to
be
when
we're
adopting
them.
But
the
big
question
is:
if
there's
enough
interest
and
we'll
ask
that
on
the
mailing
list,.
I
G
C
H
This
is
introducing
a
new
draft
that
is
currently
still
a
personal
draft.
I've
got
some
slides
here.
Basically,
I
want
to
go
over
the
motivation
behind
this
draft
a
little
bit
of
what
the
acme
client
flow
ends
up.
Looking
like
the
current
proposed
changes
to
acme
resources
and
then
take
questions
and
talk
about
next
steps
and
stuff
like
that.
So
next
slide
in
terms
of
motivation.
H
Here,
I've
just
got
a
bunch
of
diagrams
you've
got
like
suppose
that
you
are
a
ca
and
you
have
some
sort
of
normal
issuance
volume
over
time
it
varies
a
little
bit.
Sometimes
you
issue
a
little
more.
Sometimes
you
issue
a
little
less
and
assume
you
have
some
sort
of
standard
renewal
interval
for
existing
acme
cas.
H
That's
often
something
like
60
days
where
the
cert
lifetime
is
90
days,
but
clients
renew
early,
so
something
like
60,
but
it
could
be
anything
these
axes,
don't
have
actual
labels
on
them
on
purpose
next
slide,
but
for
any
number
of
reasons
you
might
have
a
issue
in
spike.
Maybe
your
rate
limits
fell
over
and
a
bunch
of
people
got
through
and
did
a
bunch
of
issuance.
H
Maybe
you
had
a
mass
reflection
event
and
needed
to
revoke
a
bunch
of
certs
and
issue
replacements
for
all
of
them,
with
some
tweaks
to
the
certificate
profile
or
a
different
issue,
or
something
like
sometimes
issue
and
spikes
happen,
they're
the
fact
of
life.
So
what
happens
after?
That
is
the
question
next
slide.
H
Naively,
what
happens
after
that?
Is
your
issuance
drops
to
nearly
zero,
because
suddenly
everyone
who
is
an
existing
subscriber,
has
a
valid
cert
and
doesn't
need
to
renew
and
some
you
still
have
some
issue
with
traffic.
Obviously
new
subscribers
people
whose
clients
behave
differently,
but
you
drop
to
nearly
zero
for
the
entirety
of
the
renewal
interval,
and
then
you
have
another
spike
you
you
see
it
coming.
H
However,
many
days
out,
every
single
one
of
these
certs
that
you
just
issued
in
a
short
period
is
about
to
get
renewed
and
that's
going
to
be
a
problem.
This
is
something
that
you
want
to
avoid
like
that.
Initial
mass
spike
is
maybe
unavoidable.
Maybe
it's
a
compliance
incident.
You
have
to
be
able
to
issue
that
many
certs
in
that
smaller
period
of
time,
but
these
future
spikes-
you
don't
want
to
have
to
deal
with,
having
that
much
issuance
capacity
all
at
once.
You
don't
want
to
deal
with
that
sort
of
spiky
load.
H
H
H
This
is
a
great
idea.
This
is
wonderful,
it
doesn't
work,
you
cannot
do
it
because
everything
is
dependent
on
the
client
initiating
the
certificate
issuance
right.
Nothing
is
actually
driven
by
the
acme
server.
Everything
is
driven
by
the
acme
client
it
can
check
in
whenever
it
wants.
It
can
decide
to
renew
whenever
it
wants.
H
You
have
no
control
over
this,
so
if
we
could
do
it,
that
would
be
really
cool
next
slide,
because
if
we
could
do
it,
we
could
smooth
this
out.
We
would
still
have
that
first
big
issue,
in
spite
for
whatever
reason,
but
then
we
could
do
proactive
work
ahead,
smooth
it
out
and
go
back
to
normal
issuance
levels
immediately.
H
Most
acne
clients,
certainly
not
all
of
them,
but
many
acme
clients
wake
up
on
a
regular
schedule,
for
example,
once
every
24
hours
or
once
a
week
or
something
like
that
inspect
the
certificate
that
is
on
disk,
that
they
are
responsible
for
issuing
and
renewing
and
see
when
it
is
supposed
to
when
it's
not
after
date
is
when
it's
going
to
expire,
then
they
do
some
math.
Maybe
they
renew
a
specific
number
of
days
before
the
not
after,
maybe
they
renew
a
specific
percentage
of
the
way
through
the
lifetime
of
the
certificate.
H
There's
a
variety
of
things
here,
but
basically
it's
wake
up,
check
the
certificate
on
disk
to
realize
it
doesn't
need
to
be
renewed.
Yet
go
back
to
sleep
repeat
again.
The
next
some
period
later
wake
up
check
the
cert
on
disk
realize
it
doesn't
need
to
be
renewed,
go
to
sleep
at
some
point.
They
wake
up
check
the
cert
on
disk
realize
that
it
is
time
to
renew
and
then
go
talk
to
the
acme
server
say
new
order,
complete
the
challenge.
H
H
The
re
proposal
changes
that
flow
to
be
contacting
the
server
instead
of
inspecting
the
desk.
Yes,
this
drastically
increases
the
amount
of
traffic
that
the
acme
server
is
handling,
but
we
can
talk
about
those
details
in
a
slightly
different
time,
but
basically,
all
this
is
doing
is
keeping
the
same
basic
flow
for
the
acme
client,
but
instead
of
waking
up,
checking
the
disk
and
doing
some
math
based
on
the
not
before
and
not
after
dates
of
the
certificate
it
wakes
up,
makes
an
api
call
to
the
acme
server
and
says:
hey.
H
Should
I
renew
yet
and
the
acme
server
says
here's
when
you
should
renew
and
the
client
says:
that's
not
right
now
and
goes
back
to
sleep
exactly
like
it
would,
when
it
inspects
the
local
certificate.
Wake
up,
ask
the
server
go
to
sleep.
Wake
up,
ask
the
server
finally
says
yeah,
you
should
renew
nowish
goes
through
the
renewal
renewal
flow
stores,
the
certificate
on
desk,
so
overall,
the
client
flow
is
not
that
different
from
what
most
clients
do
today.
H
I
H
Time
that
obviously
has
complications
for
stateless
acme
clients
that
don't
persist
any
files
to
disk,
except
for
the
final
certificate
that
they
receive,
but
it
also
has
the
advantage
of
allowing
servers
to
construct
these
renewal
info
urls.
However,
they
please
very
similar
to
how
rfc
8555
allows
the
servers
to
construct
the
certificate
url.
H
This
would
mean
that
stateless
acme
clients
don't
need
to
persist
any
information
other
than
the
certificate,
but
it
also
means
that
constructing
the
full
url
means
contacting
the
acme
server
for
the
directory
extracting
a
base
renewal
info
url
from
the
contents
of
the
directory
resource
concatenating,
that
with
some
value
computed
from
the
local
certificate
and
then
querying
that
so
it's
two
api
calls
every
time
it
wakes
up
one
to
the
directory
and
then
one's
the
renewal
info,
and
both
of
these
proposals
have
merits.
I
look
forward
to
additional
discussion
on
that
either
here.
H
C
I
H
Not
an
approach
that
I
had
considered
so
far.
It
does
inflate
the
size
of
the
certificate
for
all
tls
handshakes,
which
is
something
that
I
I
think
both
the
like
cab
forum
is
as
a
whole
and
let's
encrypt
in
particular,
strives
to
avoid.
But
it's
not
necessarily
a
bad
idea.
I
will
have
to
do
more
thinking
about
that.
A
I
feel
weird,
I'm
a
new
chair
too,
so
I'm
as
new,
almost
as
new
as
you
are
so
you'd
have
to
to
do
that.
You'd
have
putting
it
in
the
cert
is
one
way
to
do
it
so
that
the
client
always
has
it.
You
need
an
extension
to
put
it
in,
and
the
question
is:
does
that
extension
exist,
or
would
you
have
to
define
a
new
extension.
K
K
So
that
would
be
another
argument
in
favor
of
making
it
constructible
making
it
constructible
from
the
certificate-
and
I
see
a
question
chat.
What's
the
use
case
for
a
foretold
revocation?
Well,
that,
basically
would
be
a
compliance
problem.
The
baseline
requirements
say
that
if
certain
things
happen,
for
example,
a
certificate
is,
is
issued
with
with
a
with
a
mistake
in
it.
It
needs
to
be
revoked
within
a
certain
time
frame
and
the
larger
time
frame
is
five
days.
H
Compelling
one
similarly
yeah
like
thank
you
very
much
for
the
suggestion
about
it
being
more
prescriptive
on
clients.
This
is
one
of
the
places
where
my
relative
newness
is
certainly
something
that
I
need
feedback
and
help
with
where,
like
deciding
what
things
should
be
shoulds
versus
musts
is
not
my
strong
suit
yet
so
thank
you
for
that.
I
had
one
other
comment
as
a
reply,
but
I've
just
blanked
on
it.
I'm
sorry.
D
H
A
I
I
think
this
is
it's
a
it's
an
interesting
problem,
and
it's
certainly
something
that
we've
we
have
had
in
running
a
large
enterprise,
pki
systems
we've
had
issues
with
in
the
past.
It
would
be
interesting
to
look
at
what
the
options
are
to
how
you
would
solve
a
problem
like
this.
I
have
frankly,
never
never
really
considered
the
preemptive,
oh
by
the
way
your
shirt's
going
to
be
revoked.
Therefore,
you
need
to
renew
it
problem.
C
K
So
there
is
a
lot
of
pressure
on
cas
from
web
browsers,
like
mozilla,
for
instance,
for
them
to
come
up
with
a
solution
to
this.
So
I
think
it
would
be
great
if
that
solution
could
be
a
standardized
solution,
because
I
think
it's
going
to
be
something
that
cas
are
going
to
have
to
come
up
with
a
solution
to
regardless.
H
Yov
has
a
question
here
in
chat,
I'm
wondering
if
to
prevent
six
million
clients
from
all
renewing
the
same
day
rather
than
100
000
every
day
we
instead
make
them
all
check
status
every
day
and
by
status.
I
assume
you
mean
ocsp
status.
The
issue
with
that
is
that
it
solves
it.
It
almost
solves
the
renew
before
I
mean
sorry,
mind
blank.
It
almost
solves
the
renew
before
revocation
problem,
for
example,
if
everyone
is
doing
ocsp
stapling
well,
the
search
is
considered
still
valid
until
the
server
queries.
H
C
Yeah
thanks,
but
my
question
was
rather
different.
It's
great
six
million
clients
and
the
problem
you're
trying
to
solve
is
that
all
six
million
want
to
renew
on
the
same
day.
So
what
you're
doing
here
instead
is
having
them
all
of
those.
Six
million
check
check
every
day,
whether
they
still
whether
the
certificate
is
still
good,
whether
they
need
to
renew
it
all
that
so
now,
you've
made
the
at
least
as
far
as
traffic
is
concerned,
a
spike
just
as
big
every
day,
rather
than
once.
Every
two
months.
H
Yeah,
so
the
the
big
idea
there
is
that
the
huge
spike
of
traffic
from
all
of
the
clients
checking
in
is
going
to
this
renewal
info
end
point
which,
of
course
it
depends
on
the
implementation.
But
I
I
think
it's
pretty
easy
to
agree
that
serving
a
single
json
blob
containing
two
time
stamps
is
going
to
be
less
computationally
intensive
than
doing
up
to
a
hundred.
H
I
think
individual
validations
and
then
like
domain
control,
validations
and
then
signing
and
issuing
a
pre-certificate
and
submitting
it
to
ct
and
signing
and
issuing
a
final
certificate
like
just
the
the
big
idea
here
is
that
the
load
of
the
renewal
info
endpoint
is
light
enough.
That
the
trade-off
is
worth
it.
C
H
Yeah,
as
always,
I
look
forward
to
more
comments
on
the
draft
andrew.
I
think
I
I
I
think
your
comment
about
monitoring
has
probably
convinced
me
that
the
url
should
be
constructable,
so
I'll
put
together
a
version
0
1
that
switches
the
constructability
of
the
renewal
info
url,
and
we
can
continue
discussion
from
there.
J
L
I
L
Important
to
do
okay,
great
and
the
main
premise
of
it
is
that
it
just
adds
additional
challenge
types
right.
So
it's
had
some
review.
A
number
of
people
have
reviewed
it.
It
adds
several
new
challenge
types
and
the
challenge
types
are
independent
of
certificates,
but
it
does
have
a
few
use
cases
that
it
could
be
tied
to
okay.