►
From YouTube: IETF109-ACME-20201119-0730
Description
ACME meeting session at IETF109
2020/11/19 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
B
Well,
if
your
browser
allows
you
to
share
just
the
window,
then
that
usually
works
better.
A
A
A
A
D
A
Okay,
welcome
everyone
to
acme.
We
have
a
few
presentations
about
an
hour.
So,
let's
I
know
we
all
wanted
to
be
in
bangkok,
but
instead
we're
all
on
video.
A
You
have
all
hopefully
seen
the
note
well
by
far
before
it
describes
how
the
iatf
operates.
What
your
rights
and
privileges
and
responsibilities
are
by
viewing
this
via
meet
echo
you
have
signed
on
and
entered
into.
You
know,
sign
the
blue
sheet
and
therefore
a
legally
binding
document
should
we
all
get
sued
so
don't
worry
about
it.
A
Administrative
tasks,
so
we
need
one
or
two
note
takers,
jove's
gonna.
Do
the
jabber
scribe
because
he'll
cut
in
and
talk
can
we
have
someone
to
do
the
kodi,
md
or
ether
pad,
whichever
you'd
like
to
call.
A
A
A
All
right
next
slide
the
agenda,
so
we
already
did
the
first
bullet
the
administrivia
I'll
go
through.
The
next
section
is
the
drafts
that
are
out
of
the
working
group
and
on
to
you
know
various
parts
of
their
publication
life
cycle,
the
authority,
token
authority
authority
talking
list,
those
have
been
ied,
iesg
reviewed
and
we're
waiting
for
revision.
A
We
know
the
author,
I
know
the
authors
plan
to
do
stuff,
they've
just
sort
of
been
busy
with
stir,
which
is
their
their
main
interest.
So
those
will
happen.
A
A
Last
meeting
we
moved
to
be
pushed
star
delegation
through
working
group.
Last
call
I
have
to
write
the
shepherd.
Do
the
shepherds
write
up
and
hit
the
forward
to
the
isg,
but
I
will
do
that
shortly.
A
Drafts
in
progress.
Okay,.
D
A
D
Yeah,
hey
richard,
if
I
could
just
jump
in
on
the
first
two
documents
around
authority:
token
they're,
actually
not
with
the
isg
they're
still
actually
with
me.
So
I'm
waiting.
A
Got
it
yep?
Thank
you,
roman.
Yes,
so
they
are
waiting
for
they've
had
a
d
review
and
he's
requested
some
revisions
reasonably
so
oh
outlook
notice,
yeah.
Thank
you
start
allegations
waiting,
shepard's
right
up.
I
will
get
to
that.
A
Probably
during
the
next
coffee
break
thereafter
and
hit
the
button
to
forward
that
drafts
in
progress,
acme,
client
and
the
acme
integrations.
We
have
presentations
from
owen
friel
about
the
updates
on
those
dtn
node
id
was
published
as
a
working
group
draft
has
had
no
other
changes
and
I
don't
believe
brian
is
here,
so
I
don't
think
we'll
have
any
talking
on
that.
A
Some
new
documents
were
submitted
for
working
group
consideration,
one
on
subdomains
within
night
within
acme,
we'll
be
talking
about
that
onion
routing
was
submitted
by
roland
schumacher,
who
has
you
know,
left
let's
encrypt
and
moved
on
to
another
job,
and
I
haven't
been
able
to
track
him
down.
So
I
don't
think
we'll
be
having
anything
on
that.
A
I
encourage
anyone
who
is
interested
in
onion
stuff
and
I'm
trying
to
solicit
some
volunteers
to
consider
picking
it
up.
Otherwise,
we'll
just
have
to
consider
it
a
banded
service
discovery
will
have
a
presentation
and
related
to
that
is,
I
guess,
the
server
capabilities
and
that
will
be
coming
from
fraser
teasdale.
B
Well,
kathleen
is
not
here,
but
she
has
to
to
get
feedback
on
her
draft.
I
guess
it
means
integrations.
A
All
right,
oh
and
you're,.
A
E
F
B
B
E
So
quick
summary:
this
is
an
informational
draft.
It
describes
how
acme
can
be
integrated
with
multiple
existing
clients
and
device.
Certain
normal
mechanisms
without
requiring
any
changes
to
acme
and
the
the
three
main
things
we're
looking
at
is
integration
with
est
integration
with
brisket
and
bristly
cloud,
which
is
really
just
briskly
with
a
default
cloud.
Registrar
and
integration
with
teep
there's
been
a
few
changes
since
draft
0.2.
We
just
published
draft
0.t
very
very
recently
and
we've
added
the
security
considerations,
and
this
is
a
quick
summary,
probably
documented.
E
The
first
thing
to
consider
is
that
acme
disintegrations
draft
makes
no
changes
to
the
existing
standards,
we're
just
primarily
referring
to
the
security
considerations
that
exist
in
the
existing
reference
standards,
but
a
couple
of
things
we
did
explicitly
call
out.
The
acme
integration
service
could
be
configured
with
keys
for
dns
updates
in
order
to
handle
acme
and
challenges,
so
so
the
operator
of
that
acme
integration
server
should
consider
restricting
the
blast
radius
and
the
dns
zone
that
those
keys
can
update.
E
And
similarly,
the
actual
integration
service
could
be
authorized
to
write
to
http
servers
for
handling
http
challenges
and
again,
the
operator
should
consider
restricting
the
blast
radius
of
the
server
accesses
and
also
the
acme
integration
service,
because
it's
handling
requests
coming
in
from
multiple
clients
and
proxying
those
requests
through
to
the
acme
server.
We
need
to
consider
acme
integration
dos
tax
and
we
should
consider
on
the
acme
integration
service
having
a
certificate
caches
to
avoid
having
to
ping
and
the
acme
server
continuously,
when
it's
not
when
it's
not
necessary.
E
So
those
three
three
consider
security
considerations
are
described
in
more
detail
in
the
draft
and,
additionally,
the
only
other
changes
that
are
made.
There's
a
minor
tutorial
changes,
we've
fixed
up
some
broken
references
and
we've
made
we've
picked
up
some
nits
with
the
calls
and
some
knits
and
titles
throughout
the
doc,
but
they're
only
minor
editorial
and
there's
one
discussion
item.
Do
you
want
to
talk
talk
about?
It
was
brought
up
on
some
of
the
mailers
a
while
back,
but
it
didn't
really
go
anywhere
and
it's
about
cmc
ras
that
that
eku.
E
So
when
you
look
when,
particularly
when
you
look
at
brisky-
and
it
also
mentions
this
in
est-
that
when
est
or
brewski
goes
to
enroll
for
a
certificate
when
the
easter
brewski
client
goes
from
role
for
certificate
against
the
east,
to
your
brewski
servers
and
the
client
or
the
pledge
should
check
for
the
cmc
ra
eku
and
I've,
what
I've
quoted
there
is
the
explicit
text
from
est
the
explicit
text
from
brewski
that
outlines
how
the
cmc
ra
should
be
checked.
E
So
when
we're
looking
at
him
est
or
brewski
integration
with
acme,
we
just
need
to
think
about
if
the
registrar
itself
is
going
to
be
enrolling
automatically
with
acme
to
get
its
own
identity
certificate.
E
Should
that
register
be
requesting
a
cmc
ra
from
acme?
Currently,
that's
encrypt
won't
give
out
a
cmc
or
a
eku,
and
what
does
that
really
mean
when
you're,
when
you're
getting
a
certificate
from
a
public
acme
certificate
authority
such
as
let's
encrypt,
and
should
the
pledge
really
be
checking
for
this
anymore?
So
that's
just
a
general
discussion
point
that
we
probably
need
to
bring
to
the
brewski
anima
mailers
and
the
iot
onboarding
mailers,
but
I
just
wanted
to
call
it
out
here,
because
we
don't
have
a
good
answer
for
this.
E
And
next
steps
is
reviewers,
please
and
feedback
please,
and
there
is
an
old
email
thread
on
brisket
on
this
cmc
ra,
that
we
must
bring
to
the
top
emitters
again,
because
we
do
want
some
input
on
this.
We
do
need
to
close
this
before
we
close
on
the
acme,
brewski
and
acme
est
integrations
sections
and
that's
it.
E
G
Oh
owen
asked
me
a
couple
days
ago
about
this
point
and
I
went
oh
yeah.
This
is
a
real
issue,
and
so
I
have
an
email
half
written
to
that
about
this
issue
and
ironically,
allows
the
registrar
to
have
a
self-signed
certificate,
and
that
is
actually
part
of
the
the
leverage
point.
G
So
you
can
have
this
bizarre
situation
where
you
could
have
a
registrar,
that's
giving
out
certificates
to
clients
that
it
got
via
acme
while
itself
not
using
one
which
really
feels
bizarre,
and
so
I
think
that
you
know
that's
a
discussion
that
I
think
we
should
have
and
in
the
not
yet
adopted
acme
subdomains
thing:
it's
it's
possible
that
that
maybe
that
the
authorization
process
that
would
allow
you
to
through
one
authorization,
doing
quite
a
number
of
sub-domains,
not
a
wild
card,
but
many
certificates.
G
Maybe
that
actually
should
set
that
bit.
But
then
there's
some
other
issues
about
what
that
bit
really
means
that
maybe
our
it
means
actually
really
we
shouldn't
set
that
bit
and
we
maybe
we
need
another
bit.
I
don't
know,
but
I
think
that's
a
conversation.
I'd
like
I
like
I'm,
going
to
start
on
the.
D
B
Okay,
yeah.
Thank
you
moment
anything
else.
Okay,
so
I
guess
the
next
one
is
what
subdomains
yeah
supplements.
E
E
Okay,
so
subdomains
three,
we
published
a
new
version
of
this
a
couple
of
months
ago,
so
the
summary
act
made
house
an
acting
server
to
issue
certs
for
a
given
identifier,
each
a
subdomain
without
requiring
a
challenge
to
be
explicitly
fulfilled
against
that
identifier.
E
E
E
So
what
that
means
is
that
the
order
output
could
be
for
sub-domain
and
the
authorization
required
could
be
foreign
some
changes
since
since
changes
in
three
since
ik108
we've
incorporated
the
meter
feedback
on
zero.
Two,
I
know
ross
gave
quite
a
bit
of
feedback,
we've
updated
the
terminology
section
and
we've
added
security
sections
and
there's
there's
some
open
items
that
I
do
want
to
talk
about
that
were
discussed
on
the
mirror,
but
we
didn't
really
reach
any
concrete
conclusion.
E
I
just
for
terminology
clarification.
What
I
added
was
some
ca
browser
forum
based
on
requirements,
definitions,
I
reference
these
for
base
domain
domain,
name
and
domain
name
space
and
just
for
clarity.
What
I'm
finding
a
sub
domain,
as
is
a
domain
that
is
in
a
domain
name
specific,
given
parent
domain
for
domain
name,
space,
domain
name
and
parent
domain
are
the
ca
browser
forum,
definitions.
E
Security
considerations-
we've
added
quite
a
bit
here,
but
in
summary,
acme
for
some
domains
has
exactly
the
same
two
security
goals
as
acme
and
I've
quoted
these
two
security
goals
from
acme
verbatim,
so
only
an
entity
that
controls
an
identifier
can
get
an
authorization
of
that
identifier
and
once
authorized
and
account
keys
authorizations
cannot
be
improper
use
by
another
account.
E
So
exactly
the
same
security
goals,
we
don't
propose
making
any
changes
to
our
counter
key
management,
channel
establishment
and
validation,
channel
establishment
or
the
security
mechanisms
or
threat
models
there
and
for
acme
server
policy
decisions.
We
just
clarified
because
there
was
some
confusion
on
the
mailer
about
this
as
well.
The
document
may
be
applicable
to
public
cas
privacy
is
for
issuance
of
iot
search,
etc.
E
E
Should
we
enhance
the
acme
protocols
that
the
client
is
able
to
specify
anywhere
from
one
to
four
identifiers
that
they're
willing
to
fulfill
challenges
against?
And
the
second
question
is
that
was
raised
on
the
mirrors?
Is:
does
the
server
need
a
mechanism
to
provide
a
choice
of
identifiers
to
the
client
and
let
the
client
choose
which
challenge
to
fulfill?
So
for
the
same
example
again,
should
the
server
be
able
to
specify
anywhere
from
one
to
four
identifiers
that
the
client
can
pick
from
to
fulfill?
E
So
both
one
and
two
require
json
object.
Definition,
changes
to
the
baseline,
acme,
spec
and
they're
not
currently
covered
in
the
sub
domains
document.
Currently,
the
document
only
defines
how
a
client
can
submit
a
new
order
or
new
authorization
for
a
sub
domain
and
the
server
can
choose
any
of
the
parent
identifiers.
That
requires
a
challenge
for
the
madam,
but
can
use
just
one
and
so
we're
not
giving
the
client
we're
not
giving
the
client
a
mechanism
to
offer
a
choice
of
identifiers
that
you're
willing
to
fulfill.
E
Similarly
we're
not
giving
the
server
the
option
to
choose
or
to
provide
a
choice
of
identifiers
that
they're
willing
for
the
client
to
pick
and
choose
from,
and
if
we
want
to
do
that,
it
requires
some
changes
to
the
json
and
next
steps
is
just
discussion
on
the
open
items
and
based
on
the
discussion,
the
open
items,
what
we
actually
want
to
do
with
this
document,
because
it's
still
not
adopted.
B
E
Yeah,
but
I
can
see
the
comments
in
the
chat
room
seem
to
be
about
the
previous
one,
where
we're
asking
about
ra
eku's
right.
So
so
that's
the
open
question
from
the
from
the
the
integrations
one
that
slider
popular
integrated
to
cmcra
and
and
currently
acme
says
nothing
at
all
about
about
ekus.
It's
entirely
up
to
the
server
policy,
and
we
actually
don't
know
whether
I
I
don't
know
whether
we
need
to
try
and
explicitly
extend
the
acme
spec
to
see
anything
that
he
can
use.
E
You're
requesting
or
explicitly
extend
the
specs
server
can
advertise
what
he's
willing
to
offer,
but
we're
not
proposing
that,
because
we
haven't
really
discussed
the
eku's
and
specifically
for
the
cmcra
on
the
matters
at
all.
Yet
so
at
the
moment,
we're
not
proposing
or
suggesting
any
changes
to
acme
to
do
at
equus,
and
currently
that
policy
is
just
acme
internal
server
policy
and
we're
not
entirely
sure
how
to
handle
the
cmc
rx
yet,
which
is
why
we
need
that
discussion
and
but
in
the
sub
domains
in
sub
domains.
E
E
C
C
Just
to
comment
about
the
eku's
and
whether
we
want
a
mechanism
for
service
to
express
things
like
what
eku's
it
will
put
on
the
cert.
I
have
a
draft
which
I'll
speak
to
very
briefly
later
about.
C
E
A
To
move
forward,
oh
and
maybe
just
start
two
email
threads
one
on
each
open
item
and
let's
see
what
the
group
says.
If
anything.
I
I
Okay,
so
the
good
news
is
that
the
the
primary
dtn
drafts
are
making
their
way
through
the
iesg
review.
Now
the
security
review
on
the
primary
users
of
these
certificates
that
are
being
discussed
for
acme
issuance
are
being
worked
out.
I
There's
a
lot
of
detail,
that's
that's
being
hammered
down,
which
is
good,
but
what
that
means
is
that
the
the
acme
use
of
those
certificates
is
is
really
going
to
rely
on
those
details
being
finalized,
and
I
also
saw
that
the
s
mime
draft
having
gone
through
for
acme
progressed
further,
is
going
to
help
out
because
the
the
dtn
use
case
is
very
similar
in
flow,
though
a
completely
different
encoding
than
the
s
mime
use
case.
I
So
all
the
secondary
activity
is
is
progressing,
which
is
good
for
the
final
use
that
dtn
will
have
of
acme.
A
Yo,
if
you
want
a
solicit
discussion
on
the
client,
the
client
document
kathleen
stock.
B
Yeah
sure,
just
let
me
share
my
screen
this
time
this
one
right.
Yes,
I
did.
B
Okay,
can
you
assist
because
I
can't
can
you
see
the
screen?
It's
still
being
started,
okay,.
B
Okay,
so
this
is
the
the
draft
and
what
kathleen
wanted
to
know
is
I'm
going
to
do
solicit
comments
and
the
other
thing
to
answer
the
question:
whether
we
think
it's
ready
for
working
group
last
call.
B
B
B
B
C
C
So,
just
presenting
my
draft
for
a
service
discovery
mechanism
for
acme.
So
why
do
we
need
service
discovery?
The
acme
ecosystem
is
growing
and
there
are
now
multiple
publicly
trusted
cas
with
acme,
endpoints
and
also
private
enterprise.
Pkis
are
beginning
to
implement
acme,
so
we
have
environments
that
may
have
access
to
multiple
acme
servers.
C
Are
likely
to
use
that
to
push
configuration
to
clients
and
the
disposition
that
says?
Well,
I
don't
want
any
auto
discovery.
I
want
to
make
sure
that
my
client
is
explicitly
configured
is
valid,
but
in
other
cases
that
doesn't
work
so
well
or
it
doesn't
scale,
so
you
can
think
of
devices,
maybe
printers.
C
You
know,
iot
things
even
a
light
bulb
entering
a
network,
and
this
thing
could
be
quite
difficult
to
explicitly
tell
you
need
to
use
this
acme
server
over
here,
but
you
may
still
wish
to
be
able
to
have
it.
Talk
acme
and
opportunistically
acquire
a
certificate
to
secure
communications
with
that
device.
C
Another
situation
is
an
organization
with
a
bring
your
own
device
kind
of
network
where
people
are
coming
in
with
who
knows
what
software
that
can't
necessarily
be
managed
by
their
configuration
management
system,
and
yet
you
know
their
email
clients
they
might
want
their
users
to
talk
smite.
Okay,
if
you're
a
big
enterprise
network
using
outlook
everywhere,
you
might
be
able
to
push
that
configuration
out
through
active
directory.
C
Well
what
if
some
of
your
users
have
brought
their
own
computers
and
they're
running
thunderbird
or
mutt?
So
these
are
the
kinds
of
use
cases
that
service
discovery
can
be
useful
for.
The
goal
is
that
where
you
want
service
discovery,
it
enables
automatic
selection
of
the
best
server
in
the
environment
best
being
defined
by
the
network
administrators
and
how
they
express
the
services
that
are
available.
C
So
there
are
a
bunch
of
different
service
discovery
protocols.
Some
are
peer-to-peer
or
distributed,
such
as
dns
service
discovery
over
multicast
dns,
some
use
a
central
registry.
Some
are
specifically
tied
to
particular
communications
technology,
such
as
bluetooth
and
some
are
general
using
existing
naming
systems
such
as
the
dns.
C
C
Rfc
6763
defines
dns
service
discovery
and
it
uses
pointer
records
for
listing
of
available
service
instances
in
a
given
domain
and
srv
records
and
txt
records
with
supplementary
data
to
give
information
about
where
those
service
instances
are
located
and
any
other
data
that
might
be
of
interest
to
clients.
For
that
particular
service
type,
so
acme
service
discovery
is
built
upon
dns
service
discovery
or
dns
sd.
C
C
So
the
first
step
for
the
client
is
to
determine
its
parent
domains.
These
could
be
given
by
explicit
configuration
or,
as
I've
alluded,
something
that
comes
via
the
network
configuration
or
the
kerberos
realm.
Basically,
some
way
for
the
client
to
decide
here
is
a
domain
name
or
here
is
a
series
of
domain
names
that
I
will
search
for
acme
services.
In
it,
then
searches
for
pointer
records
with
the
owner
underscore
acme,
server,
dot,
underscore
tcp
dot
the
parent
domain
and
I'll
just
give
an
example.
C
C
Scoping
it
across
multiple
owners
allows
the
administrator
who
is
setting
up
these
advertisements
to
define
priority
among
different
service
instances
and
the
the
draft
goes
into
a
bit
of
detail
about
that,
and
also
some
security
consequences
of
this
rescuing
of
the
priority
field.
C
So
from
here
the
client
will
choose
the
best
server
that
is
the
highest
priority
server,
that
is,
advertising
capabilities
that
meet
its
needs
and
constructs
the
directory.
Url
attempts
to
get
the
directory
object
and
pass
it
to
see
if
it
is
a
valid
acme
directory
object
and
if
so,
all
good.
That
is
the
server
that
the
client
will
try
to
use.
C
Otherwise
it
will
try
the
next
server
and
if
it
exhausts
all
of
the
service
instances
advertised
in
the
current
parent
domain-
and
it
has
other
parent
domains
to
try,
then
it
can
go
across
to
the
next
parent
domain
and
repeat
the
dns
service
discovery
for
that
parent
domain,
and
once
it
runs
out
of
parent
domains,
then
it
can
either
give
up
or
fall
back
to
a
default
such
as
let's
encrypt.
If
it's.
If
this
is
for
a
dns
client.
C
C
C
C
So
I'm
I'm
very
interested
to
hear
what
other
people
think
about
this
re-scoping
of
the
semantics
of
the
srb
priority
field.
C
This
specification
restricts
it
to
unicast
unless
there
is
explicit
configuration
telling
the
client
that
it
can
do
it
on
multicast,
but
I
think
we
need
to
restrict
service
discovery
to
domains
not
ending
in
dot
local
and
we
need
to
restrict
or
filter
out
service
instance.
Names
that
end
in
local
as
well,
so
that
acme
clients
performing
service
discovery.
Don't
inadvertently
accept
service
instance
names
that
have
been
advertised
over
multicast
dns,
just
in
a
first
come
first
serve
basis
by
peers
on
the
local
link.
C
C
Https
I
see
in
the
chat
rust
does
dot
home,
have
similar
concerns,
yes,
possibly
stroke,
probably
and
yeah
the
whole
question
of
parent
domain
selection.
This
draft
does
not
seek
to
specify
or
constrain
how
clients
would
do
this,
but
I
would
like
to
give
good
examples
of
how
a
client
could
do
this
that
aren't
completely
insecure
and
a
terrible
idea,
because
people
will
sometimes
mindlessly
follow
the
examples
so
yeah
we
just
don't
want
to
give
people
loaded,
foot
guns.
C
So
the
next
steps
is
for
people
to
give
feedback
and
for
the
working
group
to
consider
whether
you
would
like
to
adopt
this
draft.
I
have
the
source
for
this
draft
in
a
github
repository.
The
link
is
there
and
you
can
create
issues
there.
Some
people
requests
if
you
wish
I'd,
be
very
happy
to
collaborate
with
people
to
improve
and
advance
this
draft.
C
C
C
Obviously,
this
would
need
to
go
hand
in
hand
with
proper
support
in
popular
tls
libraries
for
srv
name
verification
as
well.
But
you
know
we
have
people
at
red
hat
whose
whole
job
it
is
just
to
work
in
maintaining
open,
ssl
and
nss.
C
So
you
know
if,
if
we
agree
it's
a
good
idea,
then
where
there's
a
will
there's
a
way.
C
A
Gee,
I'm
not
sure,
well,
I
don't
yeah
we'll
use,
I
guess
the
show
of
hands
tool.
Do
a
quick
poll
how
many
people
have
read
the
draft
give
me.
A
All
right,
not,
I
don't
think
enough.
People
have
really
read
it
yet
to
discuss
to
consider
adoption
frazier.
Could
you
post
an
individual
draft
via
the
data
tracker
and
then
we
can
and
then
mail
to
the
list
asking
people
to
read
it
and
let's
see
if
we
get
feedback
there
or
if
you
want
to,
if
you
prefer
just
post
a
note
to
the
list
saying
you've
got
the
draft,
but
you
know
we
have
some
discussion.
Let's
see
what
the
github
interactions
are.
B
F
Yeah
that
was
going
to
be
my
kind,
and
since
we
have
a
queue
here,
I'm
popping
in
so
this
is
richard
barnes
from
cisco.
I
think
this
is
a
really
good
idea.
I
think
this
is
a
problem
that
is
worth
solving.
That
is
certainly
emerging
in
some
enterprise
use
cases.
I
I've
seen
some
of
the
same
challenges
I
expect
of
fraser
has
seen.
F
I
haven't
looked
in
detail
at
the
exact
best
mechanism
for
discovery
here,
so
I
agree,
there's
a
need
for
some
sort
of
discovery.
Here
I
haven't
looked
exactly
at
the
details.
The
dns
based
thing
here.
The
main
thing
I
think
worries
me
about
this
is
the
choice
of
the
the
the
starting
point-
the
name,
the
name
you
use
for
lookup,
and
for
that
I
wonder
if,
for
at
least
some
identifier
types,
we
could
leverage
the
identifier
you're
looking
to
authenticate
as
a
starting
point.
F
So,
for
example,
with
a
domain
name
identifier,
you
could
use
the
domain
name
itself
or
or
some
parent
domain
or
for
email
address
identifiers.
You
could
potentially
use
the
domain
of
the
email
address
as
the
starting
point
you
know
with
with
appropriate.
You
know
underscore
prefixes
just
just
suggestion
there,
the
the
identifier
type
stuff,
I
wonder
if
that
might
be
better
in
meta,
as
opposed
to
in
the
discovery
system,
since
it's
just
one
more
http
query.
I
A
All
right,
we
have
hit
the
end
of
the
agenda
and.
A
Yeah
normally
we'd
be
like
okay,
let's
rush
to
get
the
cookies.
Oh
mark
said
he
agrees
with
richard.
So
okay,
but
since
any
cookies
are
either
in
the
wrong
time
zone
or
have
to
make
them
yourself.
Is
there
any
other
business.
H
I
realize
I
am
way
behind
on
keeping
up
with
what's
going
on
in
the
acme,
and
I
recognize
that
the
s9
draft
is
very
far
advanced.
But
recent
discussion
on
the
lamps
mailing
list
suggests
that
the
preferred
configuration
for
email
users
is
to
have
two
certificates.
J
F
Yeah,
I
wonder
if
that's
just
an
informative
note
to
say
that
you
know
once
you've
validated
an
email
identifier,
you
can
issue
different
certs
under
it
for
different
key
types.
J
H
I
will
raise
this
on
the
acme
mailing
list.
I
suppose
I'm
not.
I
I
apologize
for
being.
You
know
for
being
this
late
in
the
in
the
process,
but
I'm
just
not
sure
how
how
to
get
that.
H
D
Per
dkg's
feedback,
if
we
want
to
talk
about
a
little
bit
on
the
mailing
list
and
come
to
some
agreement,
we
can
just
bring
the
document
back.
I'm
happy
to
do.
A
It
alexis
said
I
have
him
in
the
notes.
Is
it's
a
good
question
so
daniel
bring
it
up
and
we'll
give
a
lexi
first
whack
at
it?
I.