►
From YouTube: IETF110-ACME-20210309-1430
Description
ACME meeting session at IETF110
2021/03/09 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
B
B
C
A
A
A
A
A
A
E
E
E
And
the
point
of
why
this
draft
is
being
proposed.
We
talked
about
this
on
the
last
ietf,
but
the
idea
here
is
that
acme
has
all
of
the
infrastructure
and
bookkeeping
and
all
the
necessary
things
to
do
p,
kicks
validation
and
there's
a
need
in
the
dtn
to
be
able
to
do
this
kind
of
thing
when
a
new
node
comes
onto
the
network
and
needs
to
be
validated
the
same
way
that
a
new
email
user
might
for
an
sbm
certificate
and
next
slide.
Please.
E
So
so
the
the
flow
that
is
in
the
email,
s9
draft
is
basically
duplicated
here
with
this
other
encoding.
This
other
transport
we're
going
to
define
an
administrative
record
for
for
the
bundle
protocol
and
then
the
acme
server
generates
a
part,
one,
a
part,
two
transport,
those
two
different
paths
and
then
the
dtn
client,
that's
doing
the
validating
of
their
identifier,
combines
them
and
sends
back
the
response
next
slide.
Please.
E
So
the
because
the
blackout
period
for
the
the
internet
draft
updates-
I
wasn't
able
to
update
draft
until
just
early
this
week,
but
I
did
submit
a
zero
one
version
of
the
draft
that
had
some
clarification
and
updates.
This
is
experimental
draft.
The
idea
is
that
this
would
not
be
widely
implemented
in.
F
E
E
But
this
the
structure
is
really
the
same,
and
a
lot
of
some
supporting
text
was
taken
in
from
the
changes
to
the
s
mime
draft.
So
this
is
more
in
alignment
with
the
what
was
approved
for
s
mime
and
at
this
point
I
have
spent
a
little
bit
of
time
on
a
demonstration
implementation,
just
as
a
proof
of
concept
and
that's
where
things
stand
right
now,.
A
E
Because
of
the
simplicity
and
because
the
alignment
with
the
s
mime,
I
don't
believe
that
there
are
any
further
changes
necessary.
Yes,
so
oh
and
the
other
thing
to
mention
is
that
the
the
bundled
protocol
drafts
on
which
this
were
relying
on
for
encoding
and
for
for
transport.
Those
have
been
moved
to
the
the
editor
queue.
So
those
are
now
stabilized,
whereas
in
the
past
they
really
were
still
in
slight
flux.
A
A
B
Ahead,
all
right,
I
was
just
gonna
jump
in
you
know,
as
brian
has
kind
of
indicated.
This
is
a
bit
of
a
very
narrowly
focused
kind
of
use
case.
We
did
decide
to
adopt
it,
so
an
approach
we
could
try
is
to
go
to
work
group
last
call
and
if
we
get
enough
folks
to
have
put
eyes
on
it,
we
and
we
work
the
results.
We
can
proceed.
If
we
don't
get
enough
review,
then
we
can
have
another
conversation
about
how
we
can
get
more
review
here.
G
A
F
An
slide
draft
that
describes
how
acme
can
be
integrated
with
multiple
existing
clients
and
device.
Certain
enrollment
mechanisms,
without
requiring
any
changes.
So
what's
documented
in
this
version
of
the
draft,
is
est
risking
risky
cloud
and
tip
integrations,
and
it
doesn't
change
any
of
the
specifications
for
a
usd
risky
or
type
it
just
stitches
them
together.
Next.
F
Slide
so
there's
been
one
change
since
the
previous
draft
in
igf-109,
and
there
was
one
open
item,
which
is:
how
do
we
handle
the
risky
requirements
that
the
briskey
and
then
to
research?
The
brisket
registrar
itself
has
an
identity
search
with
an
idkp
cmc
ra
eku
set,
and
the
conclusion
that
we've
reached
is
that
even
if
the
briske
ra
is,
is
in
the
middle,
acting
as
essentially
a
proxy
that
lets
a
pledge
get
a
certificate
from
acme.
F
The
briskey
area
itself
cannot
get
a
certificate
from
an
acme
server
that
is
not
willing
to
give
it
an
idk,
pcmc
array.
So,
for
example,
let's
encrypt
is
not
going
to
wish
you
an
identity
search
with
idkb,
cmc
or
asset,
and
so,
if
the
ra,
even
though
the
ra
may
be
getting
acme
certificates
on
behalf
of
pledges,
the
ra
itself
may
not
be
able
to
get
an
acme
certificate
for
itself.
F
F
C
C
F
But
but
the
the
one
that
the
one
that
was
contentious
is
the
is
this
one
because
yeah
the
drafts
all
but
acting
integrations?
We
know
that,
let's
encrypt,
which
is
most
isn't
going
to
hand
it
out
so
they're.
Just
that
caveat
that
the
brisky
ray
itself
needs
to
search
from
a
different
city
than
the
pledges.
D
F
But
it's
it's!
It's
for
the
brisket
integration
use
case
russell
when,
when
you're
using
so
the
brisk
array,
the
pledge
talks
to
briskera-
and
actually
I
don't
have
a
picture
of.
I
don't-
have
a
picture
of
the
architecture
in
this
presentation,
but
the
breeze.
The
slides
will
talk
to
the
brisk
array
and
the
risk
array
will
have.
F
Okay,
okay
and
we're
just
like
we're
just
we're
explicitly
calling
out
in
the
in
the
document
that
the
ra
itself
can't
get
its
own
identity
cert
itself
from
acme,
because
then
the
r
isn't
going
to
be
able
to
present
that
and
then
to
research
to
the
mass
in
order
to
get
a
voucher.
On
behalf
of
pledge.
G
So
this
is
henrik.
Don't
please
correct
me
if
I'm
wrong.
I
understand
this
extended
usage
as
the
indication
that
this
is
an
array,
and
this
is
required
by
est
in
the
the
7030
drop
it
is
was
initially
introduced
by
cmc
and
we
also
tend
to
reuse
it
also
for
cmp
so
to
have
one,
let's
say:
unique,
extended
key
usage,
identification
for
an
array
and
therefore
you're,
probably
right.
G
A
H
F
A
H
D
H
H
F
H
H
A
A
F
F
F
F
F
So
if
this
flag
is
true,
then
the
server
may
issue.
If
the
client
includes
this
flag
and
the
flag
is
through,
then
the
server
knows
it
can
issue
a
challenge
against
any
of
the
parent
edn's
and
the
client
will
be
capable
of
fulfilling
a
challenge
against
them.
If
the
client
sets
this
flag
as
false,
then
the
client
is
telling
the
server.
I
can't
fulfill
the
challenge
against
any
parent
domain.
The
only
thing
I'm
authorized
to
fill
the
challenge
against
is
the
explicit
the
explicit
mfqdn
that
I'm
requesting.
F
So
that's
the
only
thing
I
want
to
challenge
for
well.
This
slide
looks
a
little
smaller
apologies,
but
I
just
cut
and
pasted
some
text
from
the
draft,
which
shows
what
the
parent-to-main
authorization
looks
like
it's
just
an
extra
brilliant
flag
that
is
optionally
associated
with
the
identifier,
and
I
think
well,
we
can
debate.
F
We
should
actually
debate
what
the
logic
should
be
if
that
isn't
included,
and
I
think
if
the
flag
isn't
included,
it
should
default
to
true,
probably,
and
because
that's
the
behavior
that
and
baseline
acme
has
baseline
acme
doesn't
make
any
assumptions
about
this
at
all.
So
it's
left
entirely
of
the
server
policy,
but
so
I've
one
follow-on
question
for
this
proposal.
If
you
go
onto
the
next
slide.
F
F
That's
better!
So
you
scroll
over
to
this
yeah.
You
can
see
that
the
client
has
issued
a
an
order
for
the
food
that
part
of
example.org
identifier
and
I've
just
included
illustratively.
The
client
could
also
optionally
include
a
list
of
edn's
saying
well.
I
can
confirm
the
challenge
against
food
that
bar
that
example
org.
F
F
F
Yeah
there
you
go
there
that
you
want
to
open
items.
The
draft
has
just
been
published
with
those
two
open
items
and
closed
and
documented,
so
I'd
like
to
get
some
feedback
on
those
two
proposals
for
the
open
items
and
it
is
based
on
what
was
discussed
in
demanders
a
couple
of
months
back
and
then
we'd
look
for
a
final
review
of
draft
zero.
Four
without
any
feedback-
and
I
know
ross-
you
you
reviewed
version
two.
I
believe
we've
incorporated
all
that
feedback
already.
D
D
D
C
A
B
A
A
B
Awesome
yeah,
I
was
going
to
say
thanks
rich,
I
don't
know
how
to
flip
my
camera
everyone's
looking
at
my
monitor
for
those
that
might
be
interested
in
being
a
co-chair.
Please
do
drop
me
a
note
and
to
me
and
ben,
and
we
can
sort
that
out.
Additionally,
what
would
be
helpful
for
the
working
group
is
if
we
chartered
a
little
more
specificity
into
what
the
future
work
is.
For
example,
we
have
a
we
have
some
drafts
we're
talking
about.
We
have
some
drafts
adopted,
we
don't
have
necessarily
milestones.
B
I
see
that
there's
some
drafts
that
that
are
related
and
we
don't
even
have
on
the
agenda
to
talk
about.
So
if
we
just
had
some
dates
for
when
we
think
we're
going
to
be
done,
and
we
have
some
notion
of
when
we
will
be
done
and
what
classes
of
extensions
we
want
to,
we
want
to
cover.
So
it's
basically
a
matter
of.