►
From YouTube: IETF96-ACME-20160718-1540
Description
ACME meeting session at IETF96
2016/07/18 1540
A
B
A
C
D
B
B
B
G
F
E
A
A
A
So
the
blue
blue
seats
are
circulated,
we
have
aged
a
prescribed
and
we
have
a
note
taker.
Thank
you
to
Robin
and
Joe.
You
are
in
Berlin
if
you
did
not
seek
to
be
in
Berlin
welcome
anyway,
but
we've
commented.
This
is
the
no
well
if
you
haven't
been
in
an
ITF
before
you
have
not
seen
this
if
you
have
been
a
night
yet
before
you've
seen
it
many
many
times.
The
note
well
is
a
brief
pointer
for
certain
values
of
brief
to
our
I
pr-related
rfcs.
Please
review
the
RFC's.
A
If
you
have
not
done
so,
they
describe
the
duties
you
have
taken
on.
Should
you
make
a
contribution
that
includes
either
messages
to
the
mailing
list.
Discussion
at
the
mic,
interpretive
dance
smoke
signals
really
quite
a
broad
thing.
Please
be
aware
of
what
duties
you
are
taking
on.
Should
you
endeavor
to
communicate
to
the
working
group
and
now
the
agenda?
This
is
the
point
at
the
agenda
where
you
are
allowed
to
agenda
bash.
It's
one
of
the
administrivia
pieces.
A
We
plan
to
discuss
the
acne
issue
list,
go
through
the
review
of
changes
to
the
document
and
upcoming
changes.
What
preparations
we
need
to
take
on
for
working
group
last
call
we've
allocated
some
time
for
that
and
then
40
minutes
for.
What's
next,
should
we
quietly
closed
down
or
soldier
on
into
new
and
uncharted
territories
which
would
need
to
be
chartered?
Is
there
any
bashing
of
the
agenda
as
presented.
E
A
H
Next
slide,
I
think
Ted
already
said.
All
these
we
had
a
rather
rushed
set
of
changes
going
up
to
the
internet
draft
deadline,
so
I
figured
we'd
spend
some
time
going
through
what
we
actually
let
the
changes
were.
That
went
into
the
document
in
case.
We
want
to
back
some
of
them
out
just
to
make
sure
that
we're
Oh
everyone's
okay
with
things
that
went
in
then
I've
got
a
list
of
open
questions,
mix
of
things
that
are
in
the
issue
tracker
on
github
and
a
couple
things
that
are
noted
in
the
document.
H
That
kind
of
came
up
came
to
mind
as
we
were,
making
some
of
the
changes
in
the
industry
aft
and
then
I
think.
The
goal
here
is
to
get
to
a
lot
of
the
list
of
kind
of
kind
of
punch
list
for
the
last
few
things
we
have
to
do
to
get
to
a
last
call,
because
the
chairs
keep
reminding
me
that
they
were
hoping
to
get
a
last
call
at
this
IETF,
and
maybe
it's
going
to
slip
a
couple
months,
but
I
think
it's
still.
The
end
is
in
sight.
H
So,
let's
the
goal
this
this
session,
I
think,
is
to
get
to
what
else
we
need
to
do
to
consider
start
considering
this
done
next
slide,
please
and
keep
going
so
this
is
the
usual
metric
slide
copied
and
pasted
from
github
27
poll
requests
from
last
time.
Yeah.
There
are
some
complaining
on
the
mailing
list
about
the
spike
of
activity
around
the
draft
deadline,
and
that
is
completely
legitimate
as
I'll
discuss
later.
H
H
Try
and
do
better
next
time
next
slide,
please!
So
what
I
call
it?
A
few
highlights
from
the
changes
that
were
made
in
this
last
Rev.
There
are
a
couple
of
security
changes.
We
made
what
I
hadn't
thought
about
it.
All
on
was
some
came
along
and
pointed
out
the
risk
of
server-side
request
forgery,
who
has
heard
of
server-side
request
forgery
in
this
room.
This
was
new
to
me
when
this
issue
was
posted.
I
think
I've
seen
these
attacks
before,
but
hadn't
heard
that
phrase
for
them.
H
And
if
the
CA
follows
redirects,
then
he'll
go
send
an
HTTP
GET
query
to
that
server,
and
so,
if
you
have
a
server,
that's
going
to
pass
back
some
information
from
that
he
got
from
that
get
request.
Then
it's
possible
for
an
attacker
to
get
some
information
from
an
arbitrary
server
on
the
internet
from
the
vantage
point
of
the
CA,
and
this
can
be
a
risk,
if
there's
say
internal
web
services
inside
the
CA
infrastructure
that
you
might
be
able
to
get
out
and
get
information
this
way.
So
this
came
to
mind.
H
The
reporter
knows
that
the
implementation
of
acne
that's
being
used.
Violence,
encrypt
actually
has
some
of
this
risk
in
that
the
error
reporting
that
the
server
provides
has
of
the
first
few
bites
of
the
response
from
the
validation
server
to
facilitate
debugging.
So
if
there
were
some
vulnerable
web
services
inside
of
let's
encrypts
infrastructure,
it
was
possible.
That
is
that
an
attacker
could
have
extracted
those
first
few
bites
of
the
response.
H
So
this
is
just
a
clarification
to
say:
you
really
should
make
sure
that
your
infrastructure
doesn't
have
any
web
services
that
are
going
to
do
anything
and,
and
that
that
you
wouldn't
want
people
via
accessing,
really
make
sure
the
things
doing
your
HTTP
validations
can
only
talk
to
the
Internet
can
only
talk
to
things
that
are
publicly
accessible,
because
that's
what
it's
there
for.
So
that's
mainly
clarification.
Some
operational
considerations
pull
request,
number
150
I
we
made
in
response
to
Karthik's,
Karthik's
analysis
and
some
operational
learnings
from
Lutz
and
Crips.
H
H
When
reality
you
needs
covered
both
the
old
key
annanuki
to
signify
that
both
the
old
key
and
the
new
key
consented
to
the
transition,
not
just
the
new
key.
So
there's
a
replay
risk
in
the
old
structure
change
the
signature
format
to
cover
it
cover
both
keys
now,
so
that's
that's
fixed,
there's
a
little
bit
more
fiddling
to
do
with
that.
A
little
bit
later
in
slides
that
senate
open
issue.
Also,
following
on
from
Karthik's
analysis,
karthik
noted
that,
with
the
limited
replay
problem
not
reflect
protection,
we
have
this
resource
field.
H
In
the
jws
Simon
said
the
type
of
acne
resource
you
were
sending
something
to
so
I'm,
sending
this
to
the
new
authorization
resource
or
to
a
challenge
resource
or
to
a
registration
resource.
Karthik
genetic
analysis
point
out
what
sort
of
already
knew,
which
is
that
if
you
have
an
intermediary
that
can
shuffle
as
responses,
then
they
can
shuffle
responses
around
within
those
resource
classes
and
there's
some
risks
that
arise
due
to
that
shuffling.
H
So,
as
we
discussed
the
last
ittf
meeting,
we
changed
from
using
this
resource
field
to
using
the
full
URL
to
which
the
thing
is
since
I
want
to
dive
into
that
a
little
bit
on
the
next
slide.
So
yeah.
We
took
this
resource
field
and
change
it
into
URL.
So
now,
when
the
server
gets
assigned
object
from
the
client,
it's
supposed
to
take
that
URL
field
and
compare
it
to
the
request,
your
I
of
the
requests
and
make
sure
that
they're
semantically
the
same
thing.
H
Now
we
had
this
big
discussion,
I
think
we
spent
20
or
30
minutes
on
the
last
ietf
meeting
about
how
comparing
your
eyes
is
non-trivial,
especially
when
you're
driving
one
of
them
from
the
parameters.
You
get
an
HTTP
request.
So
there's
kind
of
some
weasel
words
in
the
current
specs
saying
that
you
have
to
compare
the
URL
parameter
to
the
request-uri
and
if
they
do
not
match,
then
you
consider
the
request
unauthorized.
This,
like
I,
said
just
kind
of
weaselly
and
I
would
love
suggestions
for
how
to
improve
this
Ted
you're.
Looking
pensive.
A
As
a
string
match,
a
string,
exact
match,
result
right
and
so
I
I
think
that
what
we
want
to
say
here
is
basically
this
is
string
exact
match
and
the
fact
that
it
happens
to
be
a
URL
is
unrelated
to
the
processing
you
do
on
it.
To
do
that,
matching
so
do
not
do
any
of
the
more
complex
URL
matching
that
you
might
do
to
say
that
these
are
semantically
equivalent,
like
%
encoding
checks
or
any
of
that.
A
H
A
A
What
you
really
want
to
say
is
that
for
the
purposes
of
gauging
whether
or
not
they
match
we're
going
to
say
it's
string
exact
match,
otherwise
we're
going
to
fail
and
there
might
be
cases.
Can
you
go
back
to
that
so
there
there
might
be
cases
where
if
the
server
compares
it
and
they
don't
match,
they
would
have
been
semantically
equivalent.
H
H
A
H
I
I
I
A
J
Yeah
so
Martin
Thomson
I've
looked
at
this
particular
problem
very
very
recently,
and
it's
nasty,
so
r
SE
third
7230
as
a
section
on
urine
normalization
and
that
talks
about
it
makes
some
recommendations
about
what
you
can
do.
Regarding
percent
encoding
case,
whether
you
did
you
realize
that
you
can
put
a
hostname
than
a
colon
and
then
a
slash
and
leave
nothing
there.
J
In
this
context,
however,
you
will
find
that
in
most
cases
here
you
won't
have
a
problem,
because
the
URLs
are
generated
by
the
servers
that
right
and
I
think
what
you
probably
want
to
say
is
perform
some
simple
transformations
and
as
much
as
possible,
keep
the
the
octet
that
the
server
sent
you
and
then
it'll
probably
work
and
in
situations
where
it
doesn't
well.
You
know
back
to
debugging,
I,
guess
and
there'll
be
a
lot
of
well.
J
A
So
let
me
see
if
I
I
can
translate
that
and
make
sure
that
what
I
heard
and
what
you
said
agree
because
your
the
the
server
generates
the
euro
that's
going
to
be
used
by
the
client
to
generate
the
request.
Yes,
the
client
should
use
the
generated
URL
in
as
exact
form
as
it
is
possible
for
the
clients
do
in
emitting
the
request
back
to
the
server.
J
I,
maybe
the
Soviet
recover
its
is
processed
for
generating
the
URL
in
the
first
place
in
order
to
make
that
process,
because
what's
going
to
be
happening
here,
is
these
URLs
I
believe
appear
in
JSON
that
the
server
generates
and
sends
down?
So
they
there
will
be
a
utf-8
encoding
of
these
things
that
are
present
on
the
wire,
as
the
server
will
of
us
originally
conceived
of
them.
So
there
are.
A
E
H
J
I,
don't
know
if
you
want
to
belton
Bryce's
on
this
one
and
go
any
further
about
Mike
recommendations,
but
how
to
construct
that
string,
but
I
think
I.
Think
what
you
want
to
do
is
there's
there's
going
to
be
some
information
embedded
in
that
URL
that
the
server
will
have
to
recover,
and
you
could
possibly
recommend
that
the
so
but
recover
that
information,
using
whatever
method
it
can
and
then
reconstruct
the
string
as
it
would
have
done
when
it
sent
it
to
the
client
and
hopefully
that
would
produce
the
same
as.
J
H
All
right,
good,
it's
good
job,
ITF
solving
minutiae!
This
is
an
important
one.
Okay,
so
the
other
major
thing
that
I
regret
when
in
the
last
minute
here
and
should
have
gone
out
for
a
little
more
discussion,
but
I
wanted
to
put
it
out
in
a
relatively
concrete
form
for
folks
to
look
at
is
this
idea
of
applications?
So
this
application
is
the
current
word
I'm,
not
super
satisfied
with
it.
H
It
was
also
discussed
under
the
name,
preconditions
and
I
think
the
last
IETF
and
in
some
of
the
threads
on
the
lists,
but
the
idea
here
is
to
make
the
issuance
process
we
have
in
acne
a
little
more
flexible,
so
we
wanted
to
support
a
little
more
variety
in
CA
issuance
flows.
So
there's
some
CA
issuance
flows
right
now,
where
your
own,
the
client,
is
only
told
what
it
needs
to
do
to
get
the
certificate
after
it
has
already
sent
in
its
csr
to
describe
the
certificate
at
once,
which
is
not
true.
H
In
the
current
in
draft
02
acne
in
draft
Oh
to
acme
there's
an
assumption
that
the
client.
If
the
client
fills
out
the
right
authorizations,
then
he
can
just
issue
the
certificate
without
any
further
question
and
answer,
so
this
first
case
wouldn't
be
supported
in
the
original
acne
flow.
Some
cas
right
now
also
require
a
reauthorization
/
issuance.
So
if
you
prove
that
you
own
example
calm
when
you
issue
one
certificate,
you
want
a
second
certificate
with
example.com.
H
They
will
require
you
to
prove
again
that
you
own
an
example
calm,
and
so
there
is
a
desire
for
some
scoping
to
authorizations
here.
So
there
was
also
a
desire
that
we
discussed
some
last
time.
Phil
raised
the
need
for
a
cash
box
out
of
acne,
and
so
there
was
a
need
to
have
some
requirements
for
issuance
other
than
authorization
right
now
in
the
doc
you
we
have
a
requirements
framework
and
it
has
two
requirements:
authorization
and
out
of
and
star
do
do
whatever
else
here.
H
But
the
idea
is,
you
know
in
the
original
flavor
of
acne
draft
hour
to
flavor
the
only
thing
that
you
could
do
to
satisfy
the
server
that
it
should
give
you
a
certificate
was
proved
that
you
own
the
relevant
domains.
There
were
no
other
conditions
that
the
server
could
impose
and
so
yeah,
like
I,
said,
there's
a
lot
of
assumptions
that
draft
there
to
acne
made
that
were
not
or
restricted
from
addressing
these
use
cases,
and
I
should
say
this
is
the
source
for
a
lot
of
these
use.
H
Cases
is
kind
of
a
loser,
rated
starting
from
ssl
mate
and
looking
at
a
couple
of
other
CA
issuance
api's,
but
I
think
this
there's
a
pretty
okay
survey
that
covers
a
broad
swath
of
current
practice.
So
I'll
be
glad
if
there's
other
ca's
and
room
to
tell
me,
I'm
foolish
full
of
it,
and
these
are
not
actual
requirements,
and
we
should
just
revert
everything.
Make
it
a
lot
simpler,
but
I
get
the
sense
that
this
is
at
least
the
cash
box
one.
It
is
going
to
be
a
hard
requirement
here.
H
So
the
idea
here,
let's
see
next
slide,
I,
think
yeah.
So
as
we
discussed
them
on
the
list.
The
big
change
here
is
in
the
in
draft
02.
What
the
client
does
is.
It
shows
up
it
registers,
it
does
a
bunch
of
authorizations
proves
that
owns
a
bunch
of
domains
and
then
it
sends
in
a
CSR
and
gets
a
certificate,
and
what
we've
done
in
this
is
we
just
swap
those
latter
two
steps.
H
So
first
the
client
sends
in
the
CSR
and
says
here's
the
certificate
I
would
like
to
get,
and
then
the
server
responds
that
and
says
here's
what
you
have
to
do
to
get
that
certificate
and
that's
like
I
said:
there's
two
things
it
can
require
inspect
right
now,
I
can
say
you
have
to
fulfill
these
authorizations.
You
have
to
prove
you
own
these
domains
and
there's
an
out-of-band
requirement.
It
can
say
you
have
to
go
to
this
website
and
follow
whatever
the
instructions.
H
Aren't
there
so
and
then,
once
you've
done
this,
you
know
once
you've
satisfied
this.
The
ca
goes
ahead
and
issues
of
certificate
next
slide
I've
got
some
pretty
pictures
so
yeah
this
is
this
is
the
old
flow,
so
client
shows
up,
makes
a
registration.
Does
another
post
is
to
create
a
new
authorization
for
whatever
the
domain
he
wants
to?
Are
you
just
looking
at?
These
are
also
on
the
materials
page
if
you
want
to
have
them
close
up
on
your
laptop.
H
This
is
just
my
kind
of
cartoon
of
how
the
process
works,
so
the
client
says
I
would
like
authorization
for
example.com
server,
creates
a
challenge
to
say:
here's
how
you
can
prove
example.com.
The
client
sets
everything
up
and
says:
okay,
I'm
ready,
green
I'm,
representing
gray
on
the
left.
I
mean
representing
these
pending
States
says
the
server's
issued
it,
but
it
doesn't
know
if
it's
valid
or
not.
Once
the
client
responds
to
the
challenge.
H
The
cloud
the
server
goes
often
validates
it,
which
is
not
shown
here,
but
once
it's
validated
it
turns
the
the
challenge.
Green
says
the
challenge
is
good
notify
at
that
point,
once
the
the
the
challenge
has
been
completed,
the
authorization
is
good.
The
client
pulls
the
co
that
happens,
and
once
the
authorization
is
good,
the
client
can
send
a
new
certificate
request.
This
should
look
pretty
familiar.
If
you,
you
know
the
old
spec,
this
is
just
kind
of
a
graph,
so
we
can
compare
with
the
new
stuff
any
questions
about
this
clarifications.
H
Well,
yeah
the
it's
intended
to
illustrate
information
flow
as
opposed
to
request
response
flow.
Yeah
next
slide.
Please.
So
here
is
the
flow
we
have
in
the
current
draft
on.
So
you
can
see
there
is
another
layer
compared
to
the
last
one.
That's
just
less
slide
layout,
but
the
idea
here
is,
you
show
up
you
register
and
then
you,
instead
of
sending
a
new
authorization
request,
you
send
in
an
application
for
a
certificate
that
was
the
the
word
I
picked
out
of
the
ether,
not
totally
satisfied.
H
K
So
say
I
have
a
system
where
I
have
a
separation
between
the
origin
servers
which
are
on
Gator
certificates
and
the
authorization
system
which
is
proving
them
and
now
in
the
current
design
as
I
understand
it.
That
means
I
need
to
make
a
dummy
CSR,
which
I
actually
wish
not
to
be
fulfilled
in
or
determine
the
conditions
for
internal
conditions.
So
I
can't
stand
up
purely
my
authority.
My
authorization
system
without
standing
up
one
of
the
instances
of
the
things
which
actually
will
be
will
be
that
will
be
the
sort
of
identities
correct.
H
K
Think
I
just
I
said
so,
which
is
that
it
means
I,
cannot
build
a
separated
system
without
having
a
dummy
CSR
that
I
wish
not
to
be
authorized
so
I
know
I,
know,
I've
got
a
thousand
a
thousand
minions.
I
want.
I
had
a
thousand
domain
names
that
I
wish
to
be
able
to
issue
certificates
for,
and
then
I'm
going
to
spin
up
a
variety
web
servers
which
will
then
go
progressive
certificates
or
not,
and
I'm
going
to
authorize
them
now,
those
all
to
be
spun
up
before
I
can
do
anything.
J
H
J
K
Point
is
the
only
actual
working
at
BCA
does
not
have
the
policy
you're
suggesting,
and
so
it
is
extraordinarily
silly
to
design
the
system.
I
understand
understand
what
you're
saying
is:
let's
design
from
Egyptian
policy,
but
that
restrictive
policy
imposes
in
Mullane
conditions
on
the
on
the
on
the
customer.
So.
H
So
we
there
was
a
brief
exchange
on
the
list
about.
Should
we
keep
around
new
authorization
because
you
could
design
it?
You
can
sign
a
flow
we're
like
in
if
you
author,
if
you
offer
a
new
authorization
endpoint
in
the
directory,
that's
a
ca's
way
of
saying:
I
support
generic
authorizations.
You
can
come
here
and
pre-authorized
and
we
can
do
the
tradition
of
the
acme
dance.
You
know
and
love,
and
then
you
can
come
along
to
this
application
thing
and
all
the
things
will
just
pop
in
there
you'll
be
good
to
go.
K
K
It
seems
to
me:
is
it
like
on.
You
know
that
the
operating
conditions
that
I
thought
that
I
use
for
my
the
operating
conditions
that
I
use
for
the
keys
that
I
actually
do
terminate,
but
actually
actually
on
you
know,
wish
to
certify
for
may
be
totally
different
from
that
key
for
the
keys
that
I
wish
that
I
wish
to
be
authorizing.
K
Let
me
give
you
a
concrete
example
say
say
that
what
I
wish
to
do
is
I
wish
to
issue
on
Ed
2551
certificates
of
the
edu
5519
in
the
terminal
and
entity
or
in
more
aggressively,
say,
I
wish
to
issue
a
difficult
and
certificate
with
x2
5519
in
the
terminal
identity
right.
So
now
what
I'm
going
to
do
is
I'm
going
to
NASA
and
but
on
their
hand,
that's
like
in
my
web
server
somewhere
and
my
box.
My
pocket
is
a
registration.
Has
it
never
heard
of
actually
5509
and
it's
doing
PG
sex.
K
H
H
K
Point
is
that
right
we
might.
But
my
point
is
you
say:
oh
it
doesn't
matter,
why
not
you
get
a
dummy
certificate
and
not
worry
about
it,
and
what
I'm
saying
is
what
I'm
saying
is
that
there
may
be
conditions
where
the
stories
have
complete
different
character,
isn't
eventually
which
the
issue,
because
my
sis
are
not
compatible
so
yeah
I.
Do
that
you
think
is
that
I
do
think
that,
like
that,
this
is
like
not
an
opportune
time
to
like
take
out
something
which
is
like
a
basic
use
case.
A
A
A
H
H
H
Server
s
do
a
little
bit
more
state
tracking,
but
it's
a
pretty
minor
but
like
I
class
bullet
says
this
is
very
much
a
first
cut
very
open
to
suggestions,
comments,
yeah,
there's
and
I
highlighted
some
of
this
back
or
some
of
the
next
section,
all
right,
so
I
think
that's
it
for
current
spec,
any
other
notes.
People
have
thoughts
and
what's
what
went
in
and
03
again
apologize
for
the
late
rush
at
the
deadline.
I
hope
the
two
weeks
between
then
and
now
have
been
useful
effects
to
catch
up
on.
H
What's
inspect
all
right,
so
we
have
some
issues
in
the
issue
tracker
and
some
doc.
Once
you
call
these
out
and
see
if
folks
have
any
thoughts,
so
one
thing
someone
had
asked
for
is
some
explicit
indication
of
the
Acme
version
in
the
protocol.
So
right
now
we
don't
have
that
there's
no
place
in
the
protocol
where
the
server
says
this
is
the
acne
version.
I
supported
the
client
says
this
is
the
version
I
support
the
issue
other
guy
filed.
The
issue
said
that
you
could
put
this
in
directory
in
a
metal
container.
H
We
have
or
the
server
can
state
meta
data
about
its
acne
service.
In
thinking
about
this,
a
little
bit,
though,
occurs
to
me
there
might
be
some
subtleties
here,
given
the
kind
of
decoupled
way.
This
thing
is
designed,
so
you
might
have
a
registration,
an
account
you
created
with
a
v1
with
the
see
a
high
of
the
v1
protocol,
and
maybe
the
server
is
upgraded
to
v2
and
has
is
willing
to
persist
those
registrations,
and
so
there's
some
v1
stuff
that
persists
into
v2.
H
L
At
all,
Phil
I
totally
want
the
version
to
be
in
band
because
that's
anyway
can
be
authenticated
since
we're
going
to
be
doing
this
stuff-
yes,
you're
doing
it
over
HTTP
today,
but
you
know
we
might
want
to
do
it
over
different
protocols.
Http
is
probably
not
going
to
be
around
forever.
I.
Certainly
don't
want
to
have
the
fewer
connections
that
there
are
two,
the
acne
stuff
to
what
it's
riding
on
the
better.
So
yes
always
put
the
version
number
in
band.
It's
just
not
a
close
call.
J
J
Have
to
think
about
the
way
that
they
interact
with
each
other
in
nasty
ways
and
if
there's
an
explicit
version,
it
could
just
be
a
string
saying
this
is
Acme
right.
Then
we're
done
right.
You
just
check
that
it's
the
same.
It's
not
the
same
buff,
very
simple
thing
and
I
think
this
is
a
reasonable,
is
rid
of
it
and.
L
J
H
J
Suspect
that
is
probably
okay,
because
the
the
general
model
that
we're
operating
on
is
that
the
client
authenticates
its
its
information
by
using
the
Java
WS
and
signing
things
and
the
server
authenticates
its
its
responses
by
putting
them
in
HTTPS.
So
do
you
think
we
should
also
have
a
certain
server.
J
J
H
M
Can't
go
more
so
I
just
want
to
point
out
that
this
doesn't
mean
we
don't
have
to
think
about
it
at
all
right.
We
and
we
don't
get
upgrades
for
free
just
by
having
the
version
number
indicated
right.
If
we
have
the
version
number,
what
we're
doing
basically
is
saying
as
soon
as
we
change
the
version
number,
all
of
the
old
clients
are
going
to
fail
explicitly.
Yes,
so.
J
H
H
Remind
me
to
stop
using
TLS,
all
right,
I
think
think
we're
good
on
that.
So
right
now,
this
one
is
also
pretty
simple.
If
you
create
a
registration
with
one
account
key
and
you
try
and
create
you
send
another
new
registration
account,
the
same
account
key
there's
a
requirement:
the
server
return
of
409
conflict
response,
along
with
a
pointer
to
the
existing
one.
So
the
the
file
of
the
issue
pointed
out
that
this
is
way
too
harsh.
It's
not
doesn't
need
to
be
an
error.
H
H
J
H
J
H
H
All
right,
ok,
this
is
another
kind
of
simple
to
conceptualize
one
right
now
we
have
two
out
of
band
things,
and
the
question
is:
should
we
have
one?
We
have
an
out-of-band
requirement
in
the
application
flow
where
the
server
can
say
it
before
I
will
issue
a
certificate
at
all.
You
have
to
go.
Do
this
thing
like
the
payment
thing,
it's
just
a
URL.
You
go
to
a
website
and
do
whatever
it
says
there.
We
also
have
a
similar
thing
at
the
challenge
level,
which
was
added
I.
H
Think
in
the
last
IETF
cycle,
which
says
you
know,
instead
of
doing
one
of
the
predefined
challenges
like
HTTP
or
DNS
or
TLS
S&I,
you
have
to
do
this
other
thing
before
I
will
consider
you
authorized
for
this
identifier.
So
the
difference
here
is
just
in
what
the
out-of-band
thing
is:
gating,
whether
it's
getting
authorization
or
whether
it's
getting
issuance
of
the
certificate
overall
question
is:
should
we
kill
one
of
these
and
just
have
one
out
of
band
thing
I
the
argument
for
dropping
one
is
sort
of
why
I
have
two
out
of
band.
H
We
need
them
both
the
argument
for
keeping
them
would
be
that
you
know
you
could
imagine
a
CA
that
you
know
migrated
most
of
its
flow
over
to
acme
and
just
couldn't
migrate,
its
validation
system
I'm.
You
know
it
would
like
to
use
all
of
acne
state
tracking
and
issuance
flow
on
that,
but
it
can't
you
know
it
needs
some.
You
know
specially
crafted
email
base,
you
know
phase
of
the
moon
based
domain
validation
and
it
needs
to
use
the
out-of-bounds
stuff
for
that.
H
Anyone
has
strong
preferences
here,
not
seeing
a
lot
of
action
here.
So
I
think
my
suggestion
would
be.
I
kind
of
have
sympathy
with
the
only
do
one
out
of
band
thing
here.
So
unless
there's
objections,
I
think
I
don't
think
we
can
get
rid
of
the
requirement
one
because
that
stills
cash
box,
but
I
think
we
can
get
rid
of
the
challenge
one
because
that's
at
a
finer
level
of
granularity.
So
I
think,
unless
there's
objections,
I
think
I'll
go
ahead
with
taking
out
the
out-of-band
challenge.
H
J
H
The
other
thing
I
would
observe
here
is
that
if
it
turns
out
in
some
future
scenario,
we
need
the
out-of-band
challenge
thing.
The
challenge
space
is
designed
to
be
extensible,
so
it's
trivial
to
add
it
back.
We
don't
need
to
bump
the
version
number.
We
can
just
add
that
again,
alright,
so
resolved
pending
list
confirmation.
H
Alright,
this
was
is
slightly
more
technical
and
it
goes
back
to
that
question
we
were
discussing
earlier
about.
How
do
you
roll
from
one
account
key
to
another?
We,
this
is
like
iteration
number,
three
or
four
of
the
signing
structures,
so
we
did
one
that
Karthik
didn't
quite
like
we
swapped
the
order
of
signatures
and
that
and
then
Jacob
came
along
and
came
along,
came
up
with
this
parallel
signature
thing
we
we
fixed
with
having
both
the
new
key
and
the
old
key.
H
So
right
now
on
the
structure,
you
signs
it's
a
change
from
an
old
key
to
a
new
key.
Is
you
create
this
message
that
has
both
keys
in
it,
both
public
keys
and
then
you
sign
with
both
private
keys
on
so
that
both
keys
agree
to
the
changeover?
That
would
that
was
sort
of
the
critical
property
that
that
we
need
to
get
out
of
this.
H
This
message
is
the
son
of
both
keys
the
hand
over
the
issue
in
practice
with
this
parallel
signature
thing
is
that
it
requires
a
multi
signature
jws,
which
a
lot
of
libraries
jws
libraries
that
are
out
there
don't
support
and
if
you're
doing
a
I
was
doing
some
implementation
works
after
publishing
drafts.
If
you,
you
can
imagine,
building
a
nice
transport
layer
for
your
acne
server,
where
it
validates
one
signature
for
post
and
reports
up
what
key
it
did
that
validation
with
to
the
acne
layer.
H
This
breaks
that
pattern
of
every
post
being
signed
by
a
single
key
and
has
multiple
keys,
and
so
it's
a
little
bit
awkward
from
that
design.
Architecture,
aesthetic
point
of
view,
so
the
proposal
here
is
just
to
serialize
the
signatures
to
make
the
signatures
go
in
sequence,
instead
of
in
parallel.
K
K
H
H
Okay,
yeah
yeah,
sorry
about
that
yeah.
So
the
the
proposed
version
is
written
wrong
because
I
did
it
while
jet
lag
this
morning
on
the
the
inner
the
inner
signed
content
that
is
signed
by
the
new
key
is
M,
comma,
sig,
old,
em
right.
So
the
both
keys
end
up
signing
over
the
content
just
make
sure
yeah.
K
A
H
L
Phil
Han
Becca,
hey
yeah,
I'm
kind
of
confused.
There
is
only
gonna,
be
one
copy
of
the
blob
that
is
signed,
I
hope,
because
that
yes,
yes,
that's
correct,
ok,
just
ya,
cuz,
that's
not
what
you
said
yeah
there
is
only
the
thing
about
the
wrapping
I
mean,
like
I
I.
Think
the
problem
we
have
here
is
we
have
a
notation
that
isn't
Jason
yeah
and
to
discuss
this
particular
point.
We
need
to
see
the
Jason
to
understand
what
the
hell's
going
on
totally
agree.
I
apologize.
H
O
I
do
want
to
say
that
it
is
almost
trivial
to
support
the
multiple
signature
model
as
long
as
the
you
don't
make
use
of
like
the
unprotected
headers
to
hold
the
algorithm
or
anything
kind
of
funny
like
that,
the
way
you've
done
it
now,
I,
don't
think
the
limitation
on
library
support
for
is
particularly
a
big
concern,
because
you
can
take
libraries
like
mine
that
don't
support
the
and
it's
like
a
few
lines
to
just
kind
of
mix
and
match
and
put
it
in
there.
So
for.
H
H
Okay,
fair
point
yeah.
I
still
like
kind
of
the
architectural
point
a
little
bit
better,
but
it
sounds
like
there's
no
huge
concerns
raised
here
or
so
we'll
probably
end
up
being
discussion
between
jacob
and
myself,
because
we're
kind
of
on
opposite
sides
of
this,
so
we'll
hash
it
out
and
get
the
proposals
to
list
for
more
concrete
feedback
and
again
apologies
for
the
really
confusing
notation
here.
Next.
H
Is
anyone
care
about
nonces
anyone
feeling
overwhelmed
with
nonces
the
let's
encrypt,
guys
post?
It's
a
suggestion
that
we
try
and
be
a
little
more
economical
with
the
replay
notes
as
we
provide
so
right
now,
the
server
is
required
to
provide
a
fresh
replay
on
the
client
can
use
in
a
post
request
on
every
successful
response
be
that
they
get
responsive,
post
response
head
response.
H
So
they
suggested
that
to
restrict
the
requirement
to
only
requiring
the
server
to
provide
nonces
in
post
responses
and
then,
if,
if
you
provide
them
in
response
to
post
responses,
that
means
you
can
sort
of
do
a
chain
of
post
responses.
You
do
a
request.
You
get
a
nonce
in
the
in
the
response
you
can
use
for
the
next
request
and
so
on.
So
you
can
have
a
conversation
that
way,
but
then
you
need
some
sort
of
way
to
kick
the
whole
thing
off.
So
you
need
some
resource.
H
You
cannot
send
a
post
to
that,
will
give
you
a
you,
can
send
a
request
other
than
opposed
to
that
will
give
you
analysis,
kick
off
the
whole
process.
I
am
stating
the
arguments
for
completeness,
but
I
really
think
this
is
not
really
an
issue.
If
you
look
at
there
are
ways
to
maintain
lots
of
nonces
without
where
you
that
scale
proportionally
in
proportion
of
the
number
of
mountains
that
are
used
not
to
knotts
number
of
nonsense
issued
so
I'm
inclined
to
let
this
one
drop.
H
J
J
H
H
H
J
G
H
K
H
K
Mean
like
any
operational
server
is
like
probably
records
about
four
kilobytes
of
data
for
every
single
HTTP
requests
it
receives
so
like
the
have
you
have
any
having
do,
having
to
also
store
128
bits
or
so
of
nods.
For
some
short
period
of
time
does
not
strike
me
as
a
particularly
onerous
obligation.
Yeah,
okay,.
H
Sounding
like
there's
some
agreement
with
the
the
proposal
to
leave
the
requirement,
as
it
is
next
slide:
yeah.
Okay.
So
after
having
drafted
this,
the
applications
flow,
which
we
will
re
add
the
new
authorization
flow
to.
As
anchor
pointed
out
the
need
there
were
some
questions
that
arise
and
some
things
you
could
do
with
this
new
application
flow
that
are
not
inspect
right
now.
So,
if
you
look
at
the
ssl
made
api,
which
has
a
similar
sort
of
request,
a
certificate
you
apply
for
a
certificate,
get
requirements
flow.
H
H
So
I
dropped
an
open
issue
in
the
in
dark
as
to
whether
we
should
have
that
extra
step,
their
requirement,
basically
confirmation
from
the
client
that
you
should
go
ahead,
that
the
server
should
issue
the
certificate.
I
note
that
this
morning,
Andrew
air,
the
ssl
made
altar
said
no.
We
should
not
do
this
him.
Given
his
operational
experiences,
it's
not
worth
the
extra
step,
any
even
them
have
feedback
on
that
question
seems
simpler,
just
leave
it
as
it
is
guess:
I'll
leave
it
that
way
until
someone
complains.
H
The
other
thing
you
can
do
is
consider
making
these
requests
modifiable
or
supporting
multiple
CSRs.
So
maybe
a
CA
will
you
know,
allow
a
single
order
to
issue
both
are
sao
issue
certificates
for
both
our
essay
and
ecdsa
keys
for
the
same
subject,
and
so
you
could
send
in
two
CSRs
at
once
and
have
the
request
end
up
issuing
multiple
certificates,
Ted
you're
furrowing,
your
brow
here.
H
While
he's
blocking
I'll
say
the
other
use
case
for
this
is
renewal,
so
you
might
want
to
enable
a
client
to
say
change
the
dates
on
this
on
the
on
the
application
change
not
before
not
after
and
caused
that
to
reissue
a
certificate
with
new
dates,
assuming
all
the
requirements
was
still
satisfied.
Ted.
A
Ted
Hardy
from
the
floor
microphone
for
those
in
the
ether
I
was
just
trying
to
imagine
how
much
savings
there
was
really
going
to
be
in
not
having
each
of
the
multiple
CSRs
be
in
in
a
separate
application,
because
that
that
seems
to
be
the
obvious
option
here
and
I
was
wondering
if
you
had
any
mean
what
are
we
actually
saving
by
not
having
them
be
in
their
independent
applications?
Yes,.
H
So
from
chatting
with
Andrew
I
I
understand
that
there
are
some
CA
cases
right
now
where,
where
you're
paying
for
the
order,
and
if
you
get
them
both
together,
you
they're
considered
as
one
order
in
one
transaction
and
you
pay
once
for
both
of
those
certificates.
I,
don't
know.
If
that's
something
we
need
to
reflect
at
this
layer
of
the
protocol.
I.
A
Don't
think
so
I
so
personally
speaking,
I
would
say
that
putting
that
into
this
state
mechanics
doesn't
seem
sensible
if
they
want
to
do
that
they
can
have
an
order
ID,
where,
if
you're
all
associated
with
the
same
order,
ID
the
order.
Id
means
that
you
pay
your
transaction
fee
just
once.
If
you
use
this
this
handy
code,
maybe
they
could
reuse
the
nonce,
for
that
no
I
didn't
mean
that,
but
yeah
I'm
not
a
huge
fan.
How
about
renewal
while
you're
up
then
he
thought
someone.
A
P
H
Nice
clear
answer:
okay,
so
we
all
I'll
delete
that
open
issue
from
the
stack
consider
it
closed
and
it
sounded
like
I'm,
not
hearing
I.
Think
the
issue
of
modifiable
Xand
multiply
multiples.
I
noticed
Andrew
posted
some
feedbacks.
The
list
this
morning
and
I
haven't
had
any
time
to
look
at
that.
So
there
may
be
I.
Think
he's
had
some
thoughts
on.
He
did
have
some
thoughts
on
renewal
said
so
I
will
consider
that
remaining
open
for
now
recovery
to
move
on
down
here.
H
So
we
at
the
original
draft
of
acne
all
the
way
back.
The
individual
submission
stage
had
not
one
but
two
mechanisms
by
which
an
account
holder
who
has
lost
his
account
key,
could
recover
his
account
and
gain
control
of
it
again.
Contact
face
recovery.
You
know,
send
me
an
email
sort
of
recovery
in
a
Mac
based
recovery
scheme,
where
you
use
a
short
code
that
you've
been
provided
by
the
CA.
Both
of
those
have
since
been
removed
from
the
spec
I.
H
Think
I've
still
got
some
notes
in
my
to-do
lists.
To
think
about
doing
this.
There
was
some
discussion
on
Karthik's
analysis
pointed
to
some
recovery
mechanisms.
That
would
be.
That
would
be
workable.
That
would
be
good
to
have,
and
so
there
are
some
thought
about.
You
know
outlining
a
recovery
mechanism
in
here
that
you
can
instantiate
in
a
few
ways,
but
not
actually
providing
a
concrete
instantiation
benefit
would
be
that
you
know
we
would
capture
the
for
posterity.
H
This
framework
that
we'd
agreed
was
cryptographically
sound
if
only
you
had
a
way
to
provision
the
right
bits
and
so
save
the
risk
of
getting
it
wrong
in
principle,
reduce
the
risk
of
getting
it
wrong
later,
but
I
wouldn't
really
provide
much
utility
in
the
short
term.
So
I
guess
the
proposal
here
has
to
kind
of
declare
recovery
well
and
truly
dead.
Does
anyone
think
that
losing
your
account
key
is
something
we
really
need
to
worry
about?
I
guess
is
this
yeah
yeah?
If
recovery
mechanism
in
Acme
I.
H
K
Maybe
neither
scope
mechanism
is
sufficient
for
setting
that
for
resetting
that
you
don't
need
to
recover
the
key,
but
I
do
not
think
it
is
the
case
that
you
do
not
need
to
be
a
hen
situation
which
we
lose
their
keys
and
discriminative
in
that
situation,
which
I'm
trying
to
take
over
your
accounts.
Okay,
so
do
I
mean,
but
I
think.
K
Be
fine,
I
think
the
one
way
to
handle
out
would
be
to
say
that
the
recovery
mechanisms
were
inherently
basically
manual
and
that
the
way
of
CA
handles
this
is
by
is
is
by
basically
having
a
manual
process
which
are
sets
you
back
to
the
state
as
if
the
is,
if
these
demain
center
from
register
and
then
allows
you
do
it
again,
and
that
and
the
advantage
that
would
be
that
that
does
not
introduced
new
new.
You
know
come
sec
logic
errors
in
the
the
system.
Otherwise
we
have
a
worst-case
scenario.
K
K
K
K
I
guess
I
would
say
I
was
just
as
the
guidance
of
you
ever
read
about
it
in
the
guy.
Didn't
the
guidance
guidance
will
be
fine
to
say
that,
in
wit,
CA
should
probably
have
some
manual
process,
some
kind
for
dealing
the
calc
you
recover
E,
and
we
recommend
that
they,
basically
just
the
account,
rather
than
try
to
recover
the
key.
J
So
Martin
times
and
I
mean
part
of
the.
The
additional
extra
steps
that
you
might
do
is
have
different
challenges
in
response
two
or
more
challenges.
In
response
to
that,
the
request
to
create
authorizations,
for
which
an
existing
account
already
has
an
existing
registration
already
has
authorization
I
mean
that
could
be
a
policy
choice
that
the
CIA
could
make?
Let's.
Q
Q
Key
or
the
key
to
recover
it
from
whatever
file,
he
is
right,
so
I
think
a
section
on
operational
considerations
that
says
you
need
a
way
to
create
a
replacement
account
key
as
opposed
to
doing
any
kind
of
recovery,
because
that
encourages
one
to
store
it
in
some
other
place
like
it
in
the
cloud
or
whatever.
Well,.
H
H
A
H
Q
H
Yeah
so
I
think
Becker
is
probably
about
right
by
providing
our
and
Russ
about
providing
operational
considerations
and
kind
of
reset
anything.
So
rust
was
the
answer
to
Ted's
question
you'll
craft
some
text
for
us,
okay,
great,
fantastic,
all
right
yeah.
The
only
last
question
here
was:
we
have
the
way
we
do
scoping
in
graph.
23
is
the
authorization.
Struct
has
a
scope
field
in
it,
which
is
either
not
present,
or
it
is
the
URL
for
an
application
to
which
this
authorization
belongs.
H
Pretty
rudimentary
scoping,
but
I
think
it
covers
at
least
some
use.
Cases
and
question
is,
if
there's
a
need
for
more.
This
is
probably
not
a
really
useful
to
discuss
right
now,
but
just
to
throw
a
flag
in
case
people
have
these
cases
that
need
more
different
scoping
or
something
else
all
right,
I
think
that's
all
I've
got
for
open
issues,
yeah,
so
last
call
it's
a
thing
next
slide
for
those
who
might
not
be
might
not
have
the
ITF
process.
H
Swapped
in
this
is
my
cartoon
of
the
process
we're
on
the
scale,
not
no.
No,
not
this
good,
roughly
scaled
right.
So
this
idea
is
well.
It
really
it
should
be
kind
of
kind
of
spiky.
You
know
we're
working.
Her
work
occurs
at
IETF
deadlines
during
the
actual
work
phase,
so
yeah.
The
idea
is,
you
know,
we've
got
a
bunch
of
work
on
this
refining
it
and
then
there's
a
bunch
of
last
calls
for
comments
and
ballots
that
go
out
before
it
gets
to
be
entire
NRC.
H
But
the
idea
is
once
we
send
it
off
on
that
path.
We
should
feel
pretty
comfortable
that
all
the
major
issues
have
been
addressed,
so
the
question
is:
do
we
at
least
have
a
list
of
the
major
issues
that
we
need
to
address
as
we
prepare
to
send
this
off
in
the
sometime
in
the
fall?
So
the
next
slide,
so
we
had
a
few
things
left
over
from
previous
sections
and
action
items
for
for
the
authors
to
resolve.
This
is
kind
of
a
a
when
I
was
can
group
trees.
H
The
call
for
issues
anything
that
you
think
is
ambiguous
or
not
covered
by
the
current
spec,
so
I
think
it
would
be
good
to
have
a
list
of
issues
pretty
soon
now
on
people
could
flush
those
issues
out
to
the
lists
kind
of
as
soon
as
possible,
and
then
we
can
work
on
getting
those
addressed
in
the
next
few
weeks
and
it
would
also
be
good.
At
least
a
couple
of
implementations
will
latest
like
I've,
talked
to
the
let's
encrypt
guys,
they're
going
to
start
working
on
upgrading
their
server
pretty
soon
now.
H
Hopefully,
some
other
folks
who
out
there
who
have
clients
or
servers,
will
start
implementing
as
well,
and
we
can
get
some
experience
with
whatever
the
light
of
this
implementation
draft
is
like
so
would
be,
probably
04,
so
I
think
the
hope
would
be
produced
that
sometime
mid
next
month.
I
have
more
confidence
in
that
than
I
did
the
last
time.
H
A
A
H
It's
a
really
important
paragraph
yeah,
all
right
so
yeah
well
get
together
with
the
other
authors
on
fs-d
ittf
meeting
and
see
if
we
get
this
hammered
out
and
get
some
implementation
going.
Ok,
so
I
think
that
is
the
end
of
my
silence.
Oh
right,
I
have
one
more
thing.
Speaking
of
implementation,
after
getting
dressed,
Oh
3
out
I
thought
gee.
Wouldn't
it
be
great
to
actually
have
an
implementation
of
the
current
spec
going
so
I
started
one
up
next
slide.
H
H
Suites
still
very
much
a
work
in
progress
right
now,
I've
got
a
transport
layer
together,
which
is
how
I
got
thinking
about
all
of
this
parallel
signature,
stuff,
server-side
logic
is
mostly
complete
and
haven't
done
anything
with
the
client
side,
so
anyone
is
interested
in
collaborating
or
providing
feedback
here
very
interested
in
getting
this
hack
together.
That
is
actually
the
end
of
my
slides
artists.
F
Okay,
so,
given
the
the
timetable,
that's
been
proposed
and
we
seem
to
have
agreement
on
the
question-
is
what
do
we
do
next
or
do
we
do
anything?
If
anything
next
I'll
point
out
that
the
next
meeting
is
november
in
seoul,
which
might
has
might
have
lesser
attendant,
but
are
there
any
things
that
we
want
to
consider
taking
on
his
new
work?
Do
you
want
to
just
not
meet
and
declare
victory
and
wait
and
see
what
happens
anyone
prepared
to
make
a
proposal
at
this
point?
F
For
what
stuff
to
add,
I
know,
you're
supposed
to
argue
read
I
supposed
to
argue,
read:
okay,
we're
done
right!
I'm
thinking
would
be
great
if,
if
the
minutes
from
this
meeting
had
two
sentences,
which
are
about
to
go
into
last,
call
recommend
the
recharter
I,
don't
think
our
ad
would
have
any
problem
with
that.
A
E
A
A
A
A
We
want
to
kick
off
discussion
on
the
mailing
list,
with
the
presumption
that
we're
going
to
close
down
before
soul
or
we're
going
to
send
things
off
before
so
not
meet
in
Seoul,
because
we
have
no
work
on
our
on
our
plate
and
we
would
recharter
a
new
working
group
if
work
came
up
or
do
you
want
to
say,
let's
be
realistic
ones
once
somebody's
built,
a
building
block
people
want
to
build
new
things
with.
It
will
presume
that
those
new
things
come
in
after
this,
and
that
starts
in.
So
that's
the
argument
so.
H
Just
to
provide
people
some
concrete
use
cases
other
things
we
might
do.
The
things
I've
got
I've
had
in
my
head
and
haven't
don't
even
have
an
edit
buffer
right
now,
where
I
think
there
would
actually
be
some
potential
uptake
and
some
real
usage
r1
doing
acne
for
EV
certificates.
You
know
assuming
when
we
get
the
whole
payment
thing
working
and
there's
some
combination
to
be
done.
I've
talked
to
some
folks
who
do
EV
issuance
and
do
automation
around
EV,
issuance
and
they'd
be
interested.
H
I've
got
some
folks
who
would
be
interested
in
contributing,
but,
like
I,
said
nothing
even
in
a
buffer
right
now.
The
other
thing
that
I
think
I've
heard
the
a
few
folks
mention
is
the
idea
of
extending
the
CAA,
the
ca
authorization
domain,
dns
record,
which
currently
right
now
can
say
these
are
the
CAS
that
are
authorized
to
issue.
For
me,
I've
heard
some
folks
ask
to
also
have
an
extension
of
that,
where
you
can
specify
Acme
validation
mechanisms
to
whitelist.
Only
HTTP
validation
should
be
done.
H
J
Yeah
Mountain
Thompson
the
reason
I
up
to
us.
That
question
is
oh
I'm,
not
actually
seeing
anything,
but
thanks
to
Richard
I'm,
seeing
a
couple
of
those
things.
It
is
perhaps
the
right
plan
here
to
use
this
time
to
solicit
at
least
very
rough
drafts
on
those
ones.
So
we
can
sort
of
get
an
idea
of
what's
out
there
and
when
we're
obviously
not
closing
the
working
group
tomorrow.
So
we
do
have
a
little
bit
of
time
to
collect
that
that
information.
So
once
we
have
well.
J
L
Phil,
home
baker,
yeah,
I,
I,
think
they're
a
bunch
of
application
areas
as
well.
We've
got
to
think
of
because
acne
was
really
targeted
at
TLS
and
there's
a
bunch
of
other
stuff
I'd
like
to
do
with
it.
I'd
like
to
be
able
to
use
acne
with
DNS
SEC
I
would
like
to
be
able
to
use
acne
with
s
mine,
and
there
are
different
authentication.
A
So
this
is
Ted
Hardy,
with
a
chair
hat
on,
even
though
I'm
standing
in
the
pink
box,
Mike
I
have
a
question
to
our
area,
director
of
whether,
in
the
cases
like
that,
where
it's
a
significantly
different
application,
whether
we
would
like
to
do
it
in
a
working
group
focused
on
the
ca
management
or
focused
on
the
application.
That
is,
would
it
go
to
something
like
lamps
to
do
to
do
this
work?
Or
would
it
stay
here.
D
So
Kathleen
Moriarty
I
think
it
depends
if
in
a
working
group,
exists
right
and
if
that's
the
right
choice
or
not,
and
what
this
group
wants
to
do
right,
because
you'll
have
a
clean
slate
when
this
work
is
done.
So
lamps
would
be
a
clear
case
for
s,
lime
and
peach
p
stuff,
but
I
think
Phillip
also
said
ipsec
right.
So
no.
D
D
Right
so
it
might
go
over
right,
so
I
think,
let's
just
take
it
case
by
case
and
see
what
comes
in
if
there's
an
existing
working
group
or
not.
Sometimes
it's
not
the
right
place
to
do
that
right.
So
I
have
another
working
group
right
now
that
one
draft
isn't
getting
enough
review
and
I
think
it
should
have
gone
over
to
a
different
group,
and
that
might
happen.
P
D
I
think
what
I've
heard
so
far
is
that
there's
some
ideas
and
we
need
to
see
some
drafts
and
then
decisions
can
be
made.
So
I,
don't
think
word
to
the
point.
That
Eric
is
that
because
no
there
there
aren't
drafts
yet
there's
ideas
and
we
need
to
see
if
those
drafts
come
to
fruition
and
we
need
to
see
if
we
like
them
and
think
they
should
be
adopted.