►
From YouTube: IETF103-ACME-20181108-1610
Description
ACME meeting session at IETF103
2018/11/08 1610
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
B
Trying
to
tell
them
it's
a
growing
market,
it
was
cool
being
in
that
design,
meeting
meetings,
Rick
where's,
Richard
anyhow,
that's
right!
Yeah
I
was
sort
of
interesting
started.
You
know
took
all
of
the
CA
Thrones
looked
at
the
color
schemes
tried
to
find
something
that
was
different,
obviously
wanted
different
identity
from
you
know:
let's
encrypt
the
original
source,
so
yeah
help
yourself
to
you
know
couple
stickers
from
each.
B
C
C
B
C
C
No
okay,
so
let's
get
on
it.
So
since
the
last
meeting
we've
had
last
call
start
and
July
25th
last
Co
ended
August
8th
made
some
changes
based
on
based
on
last
call
comments.
I
was
tenth.
Then
we
had
a
bunch
of
comments
and
discusses
from
the
iesg.
Yeah
always
ruin
everything.
So
then
at
version
15,
but
Adam
rotaries,
disgusts,
was
still
in
resolving.
There
was
a
lot
of
discussion.
The
list
about
allowing
or
disallowing
gets
as
opposed
to
authenticated
posts.
C
Finally,
October
12,
we
had
version
16
with
no
more
gets
and
among
other
changes
and
finally
and
November
the
second.
The
document
is
approved,
but
there
needs
to
be
a
revision
for
some
minor
comments.
So
this
is
where
I'd
put
the
slide
with
ticker
tape
and
champagne
bottle
graphic,
but
we've
already
done
that
about
a
year
and
a
half
ago,
so
not
jinxing
it
again.
D
Quick
point
on
that
last
slide:
Richard
Barnes
I'm
still
waiting
for
my
co-author
to
take
a
look
at
the
PR
that
we
have
open
with
these
minor
revisions.
So,
while
you're
sitting
in
the
room
here,
you
might
pull
up
the
github
repo
and
take
a
quick
glance
at
that
and
see.
If
there's
anything
you
want
scream
about,
while
we're
still
here,
I'll
probably
merge
it
late
tonight
or
tomorrow,
cool.
C
B
C
E
E
Yeah
so,
as
we
all
know,
the
base
at
my
document
move
move
to
use
posters
get
for
everything.
However,
this
is
this,
doesn't
work
in
delegation
use
case
and
therefore
we
added
treatment
of
HTTP
GET
in
this
document.
This
is
the
main
change
that
happened
in
zero
form.
We
made
some
terminology
changes.
This
is
one
example.
Some
smaller
changes
as
well.
E
We
clarified
the
certificate
validity.
So
in
the
case,
when
you
have
a
certificate,
that's
good
for
say
three
days:
you
want
to
have
it
on
available
on
the
server
fifty
percent
so
a
day
and
a
half
before
it's
before
the
previous
one
expires,
and
you
want
the
new
certificate
to
actually
be
valid
as
soon
as
it's
available.
E
E
So
to
drill
down
into
the
way
we're
proposing
to
use
get
the
server
adds
an
attribute.
So
we
added
an
attribute.
The
server
needs
to
include
in
the
metadata
object
in
that
directory
object
and
then
it's
on
a
perl
older
basis,
so
client
asks
for
this
specific
order,
so
for
the
series
of
certificates
for
in
order
to
be
available,
we
are
get
and
assuming
the
server's,
ok
with
it
the
there.
E
E
Okay,
so
the
status
of
the
document
is,
it
was
actually
past
working
group
last
call
and
so
on,
the
verge
of
being
publication
requested,
but
we
made
quite
a
few
changes,
starting
with
the
get
thing,
but
also
including
other
changes.
So
it's
basically
for
the
working
group
to
decide
what
we
want
to
do
now.
We
could
rerun
it
through
working
group
last
call
or
weaker.
We
could
move
it
forward.
Just.
D
C
B
B
B
Is
anybody
interested
in
being
a
document
Shepard?
This
is
sort
of
writing
up
the
history
of
the
document
within
the
working
group
and
it's
presented
with
the
publication
request.
It's
an
easy
way
to
disability
points.
You
get
brownie
points,
comma
points.
If
not,
it
falls
to
working
group
chairs,
but
it's
if
you're
thinking
about
getting
more
involved
and
at
some
point
it's
a
good
way
to
get
experience
as
to
what's
involved.
B
E
All
right,
so
speaking
of
document
history
atmost,
our
delegation
went
through
sec
dispatch,
sec
dispatch
said
yeah.
This
has
to
do
with
ACMA,
send
it
to
acme
folks
at
acme,
weren't,
so
happy
with
it,
because
it
was
sort
of
a
very
small
rest
api
and
not
an
ACME
protocol
per
se.
So
now
it
is,
we
actually
rewrote
the
document
as
an
acme
protocol
profile,
with
some
differences,
of
course,
which
will
list
later,
and
this
is
now
published
as
draft
chef
and
so
on.
Next.
E
E
E
Requests
to
the
I
do
identifies
itself
or
authenticates
itself
as
an
account
owner
on
the
I
do
and
now
the
I
do
acts
both
as
an
ACME
server
and
an
ACME
client
sort
of
a
proxy,
but
not
exactly,
and
the
document
goes
into
the
specifics
of
what
is
proxy
than
what
is
not
unlike
regular
Acme.
The
CSR
gets
sent
immediately
and
there
are
no
authorizations
for
the
client
and
then
the
doc
is
there.
Protocol
between
the
I
do
and
the
CI
server
is
just
normal
like
me
or
like
my
stop.
E
E
E
There
are
no
authorizations,
it's
a
simpler
state
machine
and
one
more
thing
in
order,
and
you
can
move
to
the
next
slide
in
order
to
simplify
the
management
of
DNS
delegations
that
normally
come
in
this
situation.
We
include
cname
information
into
the
identifier
object,
as
you
can
see
at
the
bottom
of
this
slide.
We
add
an
attribute
delegated
in
a
cname
listing
the
actual
name
that
should
go
into
a
cname
resource
record
that
will
be
created,
assuming
the
I
do
has
an
auto
waited
way
to
provision
this
record
into
its
DNS
zone.
D
E
D
F
H
E
D
D
Comes
from
John
Peterson,
he
said
so.
This
is
like
lurk,
so
I
think
bumping
up
a
level.
I
obviously
need
to
read
the
drafts
and
really
understand
this,
but
I'm
worried
that
we're
conflating
two
functions
here.
One
is
setting
up
a
delegation
and
the
other
is
issuing
certificates
that
you've
leveraged
that
delegation
to
do
validation,
so
maybe
maybe
he's
okay
I'm,
not
totally
convinced
that
those
are
worth
kind
of
slamming
together.
In
this
way,
I'll
take
a
look
at
the
drafts
and
since.
E
The
the
document
is
sort
of
on
the
face,
also
on
the
fenced
area,
guarding
whether
this
is
restricted
to
short-term
certificates
or
applicable
to
your
normal
long-term
certificates,
and
this
is
something
that
I
would
like
to
open
with
a
group.
Here,
we
could
focus
on
short-term
certificates
unless
people
feel
that
delegation
is
actually
useful
for
the
normal
certificate
case.
D
I
mean
this
seems
almost
obviously
useful
for
the
the
short-term
otter
or
need
case,
but
I
don't
see
a
necessary
reason
to
conjoin
them
like
that.
That
makes
sense.
It's
like
I,
don't
see
a
reason
to
say
you
shouldn't
do
this
for
long
term
stuff.
It's
just
that!
There's
not
a
much
reason
to
okay
at.
I
C
You
have
no,
it's
no
Hudson.
What
if
we
don't
find
such
a
use
case
before
the
thing
is
published,
you
doing,
publish
hoping
that
when
such
use
case
can
was
it
it's
really
appropriate,
because
this
this
has
endangered
looked
when
we
that
at
some
point
we
would
want
to
do
delegation
as
an
overt
for
long
term
certificates.
This
one
is
not
appropriate
because,
right
now
we
don't
have
any
use
cases
like
that.
J
E
K
Tim
Holoubek,
my
personal
opinion,
is
that
just
makes
things
much
more
complicated,
I.
Think
if
you,
if
the
if
delegation,
depends
on
something
like
the
certificate
lifetime
which
is
completely
independent
of
what
you're
actually
doing,
then
you
know
everybody
has
to
keep
in
their
mental
models
and
all
their
analysis.
That
oh
delegation
is
for
short-term
certificates
and
that's
a
special
case
that
doesn't
exist
for
long
term
certificates,
I,
I,
I'm
sensitive
to
the
idea
of.
K
Are
we
building
something
that
people
will
use
or
not,
but
I
think
there
are
lots
of
cases
where
you
want
to
do.
Delegation
and
I,
don't
think
it
has
anything
to
do
with
the
lifetime
at
the
certificate.
It's
more
useful
in
short,
live
certificates,
but
I
think
it's
generally
useful
and
I
don't
see
any
good
reason
to
restrict
it.
C
C
E
C
K
D
It
the
NDC,
then
the
NDC
can
just
run
an
ACME
on
its
own.
It
effectively
owns
that
identifier.
Now
it
doesn't
need
to
go
through
the
identifier
owner
at
all
right
because
the
dns
just
points
to
it.
It
can
well
I
can't
do
the
DNS
challenge,
but
it
can
do
the
the
HTTP
challenge.
Maybe
it
can
do
the
DNS
challenge,
but
I
can
do
at
least
some
of
of
the
domain
name
challenges
just
by
having
a
cname
pointing
to
it.
In
fact,
this
is
there's
a
lot
of
deploy
to
art.
It.
E
D
That
be
a
problem
or
no
there's,
no
there's
no
inherent
binding
between
the
count,
keys
and
domain
names,
except
what
you
prove
by
doing
validation.
So
if,
if
no
one's
ever
claimed,
ABC
Don
NBC
do
you
know
dot
example
and
some
random
account
key?
That
happens
to
be
that
an
NBC
shows
up
and
validates
that
it
can
control
that
domain.
Then
the
CA
will
accept
that
he
has
control
that
domain.
D
D
D
H
Peterson
again
so
I
think
the
difference
would
be
if
you
only
have
an
account
with
the
intermediate
write
that
is
acting
as
a
back-to-back,
Acme
client
server
for
you
here
and
you
don't
have
an
account
with
the
end
server,
which
is
the
use
case
you
had
up
originally
right
like
then,
then
you
can
kind
of
see
the
sense
of
it
right.
So
if
your
your
account
is
only
with
dno,
is
that
right,
the
domain
name
owner
there's
an
idea
in
this
case
idea
idea?
H
Okay,
if
your
account
is
only
with
the
idea,
that's
running
that
then
yeah
like
then
you
wouldn't
be
able
to
prove
it
the
main
server,
unless
you
establish
some
independent
account
with
that.
So
at
least
that's
different,
it's
not
very
different,
but
it's
at
least
you
know.
If
the
argument
is
that
this
doesn't
actually
accomplish
anything
at
least
accomplishes
that
right
it
just
a
boost.
Does
that,
like
back
to
back,
then.
D
Yeah,
you
would
have
to
have
a
son
of
yeah
I,
find
that
not
so
convincing
because
Acme
accounts
are
cheap,
like
you
just
spin
them
up
on
demand.
You
know,
except
where
a
CA
is
imposing
conditions
on
things.
So,
for
example,
one
thing
that's
been
discussed
off
and
on
the
lots
and
discussed
for
a
while
was,
like,
you
might
say,
lock
a
domain
to
a
particular
account.
So
if
you,
if
an
account,
if
a
domain
has
been
validated
by
a
given
account,
you
might
refuse
to
validate
it
to
other
accounts
in
the
future.
D
G
I
want
to
make
sure
that
topic
was
done
before
I
I
just
have
a
quick
question
actually
cuz
on
the
star
side
of
things.
We
have
cases
for
delegated
certificates
in
a
very
similar
model.
Is
there
open?
Are
you
locking
this
DNS
type,
or
are
you
open
to
having
other
identifier
types
in
the
delegated
model,
so.
E
L
C
Yeah
still
not
that
I'm
going
to
have
adoption,
but
how
about
we
have
Monday
question
whether
the
working
group
would
like
to
do
work
in
this
in
this
area
in
this
domain.
On
this
subject
and
after
that,
we
do
the
regular
call
for
adoption
where
people
would
be
expected
to
read
before
really
give
their
opinion.
So
how
many
things
that
this
document
is
this
subject
is
something
that
the
working
group
should
do
work
on
humm
now.
C
How
many
think
that
this
is
something
that
the
group
should
not
do?
Work
on?
Okay,
that's
pretty
clear!
So
we'll
send
well
we'll
wait
a
week
because
people
don't
really
do
any
ITF
work
in
the
week
following
ITF,
because
yeah
we're
late
for
stuff.
So
in
about
a
week
or
two
we'll
issue
a
call
for
a
doctrine
and
see
where
that
takes
us.
M
G
M
So
the
main
changes
in
the
late
latest
version
is
basically
the
shuffling
of
moving
some
attributes
from
jose
header.
I
believe
to
the
payload
I
think
I
talked
to
Richard
Barnes.
Here
she
said
it's
the
more
natural
thing
for
it
to
be
yeah
corrected.
Some
typos
and
I
would
also
edit
SMTP
extension
registration,
which
is
a
requirement
for
sent
EP
extensions.
N
N
N
M
M
D
M
D
D
Sorry
so,
in
that
case
yeah
this
might
need
a
little
bit
of
refactoring
I
think
it
might
make
sense
to
treat
SRV
ID
as
a
different
identifier
type.
That
would
then
get
its
own
challenges.
Basically,
the
same
challenges
you've
got
here,
but
then
you'd,
not
the
identifier
type
to
you
would
you'd
say:
I
want
to
be
able
to
be
able
to
say
host
name
and
port
in
the
identifier
in
the
cert,
and
then
you
validate
possession
of
that
host
name,
important.
J
If
the
it's
the
thing
that
you're
trying
to
issue
embeds
this
stuff,
then
obviously
you
need
it
right,
but
but
but
I
also
don't
know
who's
actually
validating,
as
Harvey
named
inserts
at
all
like,
so
that
there's
like
several
steps
of
the
chain
that
seem
to
be
missing,
to
justify
the
inclusion
of
this
of
this
additional
complexity.
If
the
name
would
have
worked
anyway,
right,
right
or
or
or
is
what
this
is
supposed
to
be
doing,
giving
the
giving
the
issuing
CA
in
different
instructions.
M
J
M
J
N
So
Paul
often
again,
this
isn't
clear
in
the
current
draft,
because
I
thought
that
this
was
all
about
putting
in
like
attributes
in
the
cert.
So
the
fact
that
you're,
you
know
so
I'm,
just
saying
whatever
you
do
here,
making
a
ray
or
whether
you
should
also
be
adding
a
paragraph
or
two,
maybe
with
examples.
D
I
guess
we've
got
a
couple
layers
of
indirection
here.
We've
got
the
name
that
appears
in
the
search.
The
thing
you
validate
the
identifier
you
validate
an
ACME
and
the
challenge
you
used
to
validate
it.
I
think
what
I'm
least
clear
on
is
the
mapping
between
the
thing
that's
in
the
cert
and
the
thing
that
you
want
to
validate.
D
D
So
if
you,
if
you
want
to
see
a
to
validate
the
specific
ports
and
I,
think
you
do
want,
like
I,
see
an
SRV
name
identifier
instead
of
using
the
DNS
identifier,
because
that
that
way
you
can
have
challenges
that
maps
that
specific
port-
yes,
I,
have
no
idea.
What
M
do
you
guys
do?
Email,
certs
at
all,
you
can
comment
on
the
state-of-the-art
here.
K
K
The
the
other
interesting
comment
that
I
wanted
to
make
while
I
happen
to
be
up
here,
is
the
assumption
that
all
services
on
a
particular
domain
are
controlled
by
the
same
people
and
even
operate
by
the
same
server
is
no
longer
true,
and
so
that's
something
we
probably
want
to
be
a
little
bit
careful
about
and
I
would
like
to
live
in
the
world
that
you
live
in,
where,
if
you
have
a
certificate
for
you
want
to
live
in
as
well.
Let
me
put
it
that
way.
M
M
M
B
M
M
M
M
Half
of
we're
talkin
arrives
over
HTTP.
That
half
arrives
over
email
and
a
special
message,
and
then
the
client
sends
calculate
you
know
signature
and
sends
the
response
in
another
message.
So
most
of
the
most
of
the
work
here
was
in
recent
versions
was
done
on
specific
messages,
and
there
are
some
examples
of
this
might
look
like.
M
So
the
idea
is
that
the
message
is
simple
enough:
that
it
can
be
handled
automatically
by
mail
client,
because
there
are
special
ways
of
recognizing
that
this
is
special
challenge.
It's
also
would
be
possible
for
the
user
to
cut
and
paste
token
into
an
external
app
generate
the
value
placed
into
response.
Send
it
back
wonderful.
J
M
B
C
Have
a
question:
I
won't
cook
the
mic,
because
I'll
trip
over
the
wires
here
is
there
any
provision
in
the
draft
about
people
reading
their
email
on
different
clients,
multiple
clients?
If
you
get
the
certificate
into
one
client
and
it's
not
present
on
the
other
you're
going
to
get
encrypted
mail
and
not
be
able
to
read
it
I.
M
C
M
B
H
H
This
is
really
short-range
left
hand,
okay,
yeah,
so
we're
talking
about
authority,
tokens
and
T
n
awfulest.
We
don't
have
much
to
say,
though,
so
you
guys
can
pretty
much
check
out
in
case
you
forgotten
what
the
authority
token
is
for
this
came
out
of
the
work
that
we're
doing
in
ster,
where
we
decided
there's
a
be
way
to
do
challenges
with
some
kind
of
a
generic
authority
that
has
some
out-of-band
means
of
determining
which
kind
of
clients
would
have
the
authority
to
claim
certificates
or
certain
kinds
of
identifiers,
telephone
numbers
or
original
use
case.
H
We
created
a
typing
mechanism
for
that
and
this
really
short
range.
This
is
what
a
challenge
this
might
look
like
for
this
this
this
particular
type
of
a
touken.
Here
we
have
the
token
type
defined
as
ATC,
which
is
the
version
we
use
for
jobs
and
that's
all
that's
in
the
first
one
of
these
drafts
and
that
Draft
has
not
changed
a
terrific
amount
in
this
particular
revision.
But
we
have
a
registry
for
those
types
that
so
people
undefined
other
types
for
it.
They
could
to
use
things
other
than
jaw.
H
That's
all
in
there
is
amazingly
short
range,
so
then
we
did
go
ahead
and
define
a
way
to
do
this.
That
is
specific
to
the
telephone
number
option,
for
this,
and
Chris
can
talk,
probably
a
bit
about
that
and
what
we've
done
with
it,
but
at
the
end
of
the
day,
really
where
we
are
with
this.
As
for
this
revision,
we
just
did
some
editorial
fixes.
We
updated
the
examples
so
that
they
actually
conform
with
the
latest
version
of
Acme
and
the
changes
that
were
made
in
that
we
put
in
some.
G
H
G
H
G
H
We
would
do
things
for
approving
things,
for
DNS
names
and
so
on.
So
it's
important
that
we
keep
that
on
board
in
terms
of
what
we
still
have
to
do.
I,
don't
think
this
is
ready
for
last
call
or
review.
Probably
at
this
stage
we
we
do
want
to
patch
in
and
we're
just
gonna
shamelessly
steal
this
from
what
the
people
are
doing
in
at
us.
The
restful
interfaces
are
actually
using
for
token
acquisitions.
We
don't
have
anything
for
that.
Now,
in
the
main
authority,
token
draft
are
in
in
our
inclination.
H
To
do
it,
but
instead
to
have
that
be
an
example
and
if
people
want
to
use
something
other
than
this
restful
interface
that'll
be
fine,
but
we
will
at
least
define
one
way
of
doing
this
in
the
base
specification
or
at
the
betoken.
We
have
a
ton
of
housekeeping
still
to
do
in
both
drafts,
though
like
adding
seconds
to
the
the
TN
off
less
draft,
so
I.
Think
probably
we
do
one
more
wrap
of
this.
It
should
be
ready
for
review
and
hopefully
for
last
call,
there's
really
not
much
to
it.
I
guess
so.
H
H
Yeah,
so
that's
kind
of
when
we
talk
about
review
over
it
@s,
that's
why
they
do
shaken
and
it's
you
know
this
is
a
pretty
crucial
use
case
or
for
that
in
the
sense
of
there's
actually
like
major
agencies
and
governments
and
carriers
and
stuff
that
are
spinning
up
the
process.
That'll
actually
create
the
seasons
for
this,
and
so
it's
not
an
insubstantial
use
case.