►
From YouTube: IETF97-ACME-20161116-1330
Description
ACME meeting session at IETF97
2016/11/16 1330
B
C
B
So
I
I
could
do
that
if
I
got
a
replacement,
javis
carb.
Ok,
you
want
to
take
over
okay,
we've
got
a
replacement,
jabber
scrub
and
your
to
capture
the
meeting
in
a
series
of
means,
and
we
will
put
this
into
the
official
minutes
if
the
memes
are
an
accurate
portrayal
of
the
meeting
as
as
it
goes
forward,
gives.
B
E
B
B
B
Note
same
hyperlinks,
it
doesn't
matter
what
language
you
say
it
in.
It's
the
same
pcps
on
Rica
five
minutes
in
administrivia,
50,
minutes
of
open
issues
on
the
Acme
internet-draft
15
minutes
on
short-term
certificates,
10
minutes
on
CA,
a
document
and
10
minutes
on
working
group.
Next
steps
is
there
anybody
who
would
like
to
bash
this
agenda
before
we
go
on.
B
F
F
In
that
graph
of
commits
per
week,
we
were
less
productive
than
we
thought
during
the
first
phase
of
the
cycle,
but
during
the
end
of
it,
when,
with
the
deadline
approaching
Jacob
and
I,
got
on
slack
and
had
some
real
time
discussion
and
got
some
issues
hammered
out
where
we
had
pretty
much
agreement
on
the
list,
but
he
and
I
disagreed
on
some
things.
We
got
our
agreement
and
got
some
things
landed,
so
highlights
are
in
next
few
slides
lots
of
typos
and
clarifications
varying
in
seriousness
from
spelling
too
technical
clarifications.
F
Next
slide,
please
a
couple
of
things
were
proposed:
I
think
mainly
from
the
let's
encrypt
side
to
kind
of
make.
The
protocol
more
developer-friendly,
like
historically
we
had
presented
the
certificates
that
were
issued
as
in
der
binary,
is
in
one
format,
Joe
and
just
the
end
entity
certificate.
When,
in
reality,
what
you
need
to
consider
web
server
most,
the
time
is
a
pem
formatted
thing
that
has
the
whole
chain
of
certificates
back
to
a
trust
anchor,
and
so
because
that
was
what
the
developers
were
going
to
need.
F
Anyway,
we
figured
why
not
just
provide
that
in
the
protocol.
It's
a
little
in
some
ways,
it's
suboptimal
because,
of
course,
the
pki
being
the
complex,
beautiful
beast
it
is.
There
is
not
one
true
trust
chain
back
to
back
to
one
trust
anchor
for
any
given
an
intensity
cert,
and
so
we
still
have
the
links
in
there
that
rely
that
clients
can
use
to
build
alternative
chains
if
they
want
to
you.
F
Other
cas
and
use
other
routes,
but
the
idea
was
by
defaults
to
have
the
ca,
recommend
one
and
do
some
of
that
logic
about.
Will
this
chain
be
accepted?
Broadly
in
on
behalf
of
clients,
we
added
some
stuff
around
except
language
and
some
clarity
around
how
the
server
should
handle
contacts.
It
doesn't
life
next
slide.
Please
terms
of
service.
There
was
a
bunch
of
back
and
forth
on
the
list
about
this.
Basically,
we
wanted
to
optimize
for
the
case.
F
The
question
that
arises
is
the
client
agrees
to
some
terms
of
service
when
it
signs
up
with
acne
when
it
registers
its
account,
but
over
the
course
of
time
as
the
that
account
exists
for
weeks
or
months
or
years,
the
CA
may
have
to
change
its
terms
of
service.
I
may
have
to
update
it,
and
the
question
is
what
happens
when
the
CA
does
that
in
practice?
F
Ch
do
this
fairly
frequently
and
they
generally
structure
their
terms
of
service,
so
that
the
client
doesn't
have
to
really
does
have
to
re
express
its
agreement
when
the
terms
change,
but
we
wanted
to
accommodate
the
case.
You
know
it
is
possible
in
principle
that
one
of
these
changes
might
require
clients
to
re-express
their
agreement.
If
there's
some
really
huge
material
change
that
wasn't
predicted
in
advance,
and
so
what
we've
done
is
we've
made
a
change
that
really
optimizes
pretty
heavily
for
that
former
case,
so
the
only
in
band
provision.
F
You
know
the
provision
in
the
protocol
itself
is
for
that
initial
agreement.
Two
terms,
so
the
only
time
you
can
agree
to
terms
is
when
you
establish
your
account,
if
there's
a
need
for
re
agreement
down
the
line,
there's
not
a
way
to
do
that
in
the
protocol,
but
we
have
an
error
code
that
the
server
can
use
to
say
you
know
put
the
brakes
on.
F
You
know
you
can't
perceive
unless
you
agree
to
these
terms
and
in
the
error
document
the
server
presents,
it
can
provide
a
link,
they
send
a
user
out
to
visit
this
link
because
we
need
to
explicitly
break
automation
at
this
point.
The
concern
overall
is
breaking
automation
for
the
Sri
agreement
wanted
to
do
that
as
little
as
possible.
So
we
have
the
emergency
pop
out
of
with
this
error
code.
F
H
Cashing
this
error
code
and
cheating,
what
do
you
mean?
I
mean
it
like
the
whole
notion
that
the
user
agreed
to
determine
the
servers
in
the
first
place
is
completely
specious.
Right
and
I.
Appreciate
it.
The
legal
fiction,
but
I'm,
just
saying
like
so
like
is
this
chart?
Is
this
construction
interests
away
that
I
can't
simply
reregister
the
light
that
there's
no
way
for
the
client
to
pretend
that
he
presented
to
give
these
are
the
terms
of
service
but
actually
contain
go?
H
Are
you
looking
for
some
like
captcha
here,
to
verify
that
a
human
touch,
the
no
I'm
asking
I'm
asking
is
the
protocol
is
charged
in
such
a
way
that
the
steps
to
the
steps
to
which
the
crime
would
have
to
do
have
to
have
to
go
through
to
pretend
that
these
are
looked
at?
It
are
obvious,
so
is
it,
for
instance,
to
go
to
some
link
and
the
directions
for
you
to
do
or
in
that
link
and
then
the
and
then
that,
like,
basically,
you
can't
you
can't
complete.
J
I
F
Ultimately,
up
to
the
server's
policy
when
it
wants
to
prevent
the
present
this
error
in
the
first
place,
and
so
it's
a
service
policy,
you
know
how
how
much
of
a
pain
it
wants
to
be
about
forcing
some
of
their
do.
This
agreement
and
I
might
be
the
server
would
let
you
do
some
fiddly
things,
but
not
issue
certificates
might
let
you
do
authorizations,
but
now
certificates
and
then,
when
you
go
to
issue
a
certificate
I'll
throw
this
error
up.
F
I,
don't
know
that
there's
much
for
the
straps
to
say
about
that,
because
it's
ultimately
up
to
the
CA,
how
much
15
ian
wants
to
be
okay,
this
Christmas
fairly
silly,
but
not
everybody,
gonna
batter
breath
I
mean.
Let's
be
honest.
All
of
this
agreement.
Stuff
is
kind
of
silly,
but
it's
you
know
something
that
CAS
are
feeling
they
have
to
have
in
order
to
comply
with
the
VRS
and
so.
H
But
I
mean
you
don't
need
an
error
occurred.
You
don't
need
a
specific
error
code
for
this.
You
could
just
what
you
need
is
an
error
code
that
says
something
is
going
wrong,
go
to
this
URL
and
deal
with
it
as
a
generic
fashion.
That
does
no
reason
to
be
a
special
Eric,
oppas
particular
case,
for
something
is
growing.
You
need
to
go
to
a
URL
sure
I
mean
I
guess.
My
point
is
like
that.
F
C
F
H
H
F
All
right,
I
think
I'll.
Do
that
then,
because
I
think
that's
probably
a
little
bit
more
useful,
okay,
I
hope,
meme
taker.
You
got
that
I
that
that
seems
seems
like
user
action
required
has
a
good
name
coming
with
it
all
right.
Third
service
key
roll
over
there
was
a
bunch.
We
had
some
discussion
on
this
last
IETF
meeting
and
very
vague
terms,
and
they
got
more
concrete
on
the
list
and
kicked
around
a
bunch
of
options.
Next
slide
net
of
those
PRS.
We
have
more
or
less
of
structure.
F
We
discussed
last
time
where
we
have
nested
signatures
where
the
old
key
when
you
bring
your
transit.
So
this
the
use
case
here
is
we're
transitioning
from
an
old
account
key
to
a
new
account
key
for
existence.
You
know
we're
worried
about.
You
know
just
keeping
fresh
keyz,
so
the
old
key
signs,
the
the
overall
payload,
which
kind
is
not
kind
of
nice,
because
it
preserves
the
invariant
that
the
outer
signature
on
a
payload
sense.
The
server
is
always
an
sing
account.
You
don't
have
a
new
thing
new
key
to
ending
this
so
yeah.
F
F
So
I
think
that
was
basically
what
Karthik's
analysis
over
the
summer
pointed
us
toward
and
well
basically,
what
we
discussed
on
this
may
be
slightly
out
of
this
may
need
a
little
bit
of
an
update,
because
since
we
change
to
represent
keys
by
reference,
but
it's
this
is
the
idea
next
slide,
please
yeah.
So
a
couple
of
bigger
things
after
echo,
suggesting
the
last
IETF
meeting
in
noting
that
the
new
new
application,
how
new
order
flow
lost,
this
pre-authorization
thing
lost
some
important
use
cases.
We
agree
added
that,
as
Jacob
pointed
out
on
the
list.
F
There
are
some
compatibility
implications
to
this
when
you
consider
the
existing
acne
client
base,
that
is
connecting
a
let's
encrypt,
so
existing
acne
clients
supporting
earlier
versions
of
the
protocol
are
only
using
the
new
authorization
flow
they're,
not
using
a
new
order
flow
and
so
leaving
these
both
around
might
mean
that
their
clients
around
that
don't
support
all
of
the
spec
I
think.
That's
probably
the
I
think
it's
ultimately
not
a
blocker,
but
something
we
should
keep
an
eye
on
as
we're
developing
the
client
base
for
it
and
starting
to
do
some
implementation
interop.
F
There
was
some
concern.
We
have
these,
not
these
anti
replay
announces
around
in
the
protocol
and
in
the
first
four
iteration
of
this.
The
way
you
got
them
was
in
headers
on
every
random.
You
could
go
to
any
resource,
send
the
request
to
it,
and
even
if
you,
your
request
was
invalid,
because
you
didn't
have
a
nonce,
you
could
get
an
onsen
response
observation
from
some
deployment
experiences.
Let's
encrypt
guys
with
this
made
caching
a
real
problem,
because
then
you're
invalid
responses
can
be
casual.
Daniel
do.
F
The
client's
account
key
itself
in
the
jws
or
by
putting
the
URL
for
the
clients
account
in
there,
and
the
trade-off
here
is
as
follows.
So
if
you
put
the
key
in
there
you're
relying
on
the
server
to
compare
that
key
to
the
key,
it's
got
stored
for
an
account
in
the
in
its
account
database.
And
if
you
put
the
URL
there,
you're
trusting
the
server
to
look
up
the
key
and
so
not
screw
up
its
URL
comparison.
So.
F
Risk
why's
your
kind
of
balancing
those
to
risk
the
risk
you
squeaky
comparison
versus
a
risky
script,
a
URL
mangling
thing
on
that
balance:
I,
don't
think
we
had
any
consensus
around,
which
was
more
likely.
They
both
seemed
like
both
pretty
remote,
because
people
do
these
things
regularly.
All
the
time
Jacob
I
think
preferred
the
especially
preferred
the
key
lookup
thing,
because
that
means
that
the
server
has
to
have
identified
an
account
that
this
key
it
belongs
to
before
it
does
any
further
processing.
F
Whereas
you
know
you
can
do
some
processing
if
you've
got
the
key
in
hand
without
it,
knowing
that
it
belongs
to
an
account.
So
it's
a
little
bit
more
conservative
in
that
way.
So
any
comments
on
those
state
of
the
art,
all
right,
I
think
that's
the
last
of
the
things
we
did
alright.
So
now
you
can
tune
in
and
put
your
discussion
hats
on
a
couple
things
that
are
still
open.
F
I
wanted
to
get
feedback
on
see
if
we
can
bring
some
conclusion
to
and
close
now
next
slide,
please
so
a
couple
of
issues
opened.
We
have
an
issue
and
a
PR
and
some
discussion
on
your
list
about
this
topic.
The
issue
is:
if
you're
talking
about
taking
a
CA,
it's
been
in
business
for
a
while
or
CA
that
has
you
know
non
acne
thing
going
on
it's
going
to
have
a
customer
database
that
is
not
in
acne.
F
It's
not
just
the
you
know,
keep
air
and
contact
information
that
acne
negotiates,
so
you
might
have
some
additional
authorizations
tied
to
that
authorizations.
The
issue
EV
say,
or
you
might
have
some
richer
customer
information
and
policy
information
associated
with
that,
and
so
you
might
want
to
tie
your
customer
account
database
that
existed
before
acne
or
beside
acne
an
associate
an
account
there
with
an
account
in
acne.
You
know
an
account
key
pair
in
the
acne
except
context,
and
so
there's
a
desire
for
some
way
to
associate.
F
You
know
to
take
one
of
these
and
associate
it
with
the
other,
so
we
have
a
PR
right
now
that
takes
an
idea
that
some
start
come
guys
proposed
and
writes
it
in
the
idea
is
when
you,
you
make
your
new
registration,
your
new
account
in
the
new
parlance
in
in
your
payload
there
you
include
and
its
external
secret.
The
idea
is,
this
is
something
like
an
API
key
or
a
binder
that
the
CA
is
handed.
F
The
one
thing
I'm
wondering
here
this
seems
at
one
level
very
straight
for
the
one
thing
I'm
only
thing
I'm
wondering
here
is
whether
we
should
write,
maybe
some
security
considerations
to
kind
of
recommends
that
we
get
authorization
in
both
directions.
So
taking
the
API
key
from
the
existing
system
and
putting
it
into
acne
gives
you
your
kind
of
enables
acne
to
claim
an
existing
thing.
F
We've
had
unknown,
keisha
risks
again,
I'm,
not
totally
sure
how
that
that
shows
up
that
might
show
up
here,
but
might
be
something
conservative
trick.
Then
people
consider
cas
in
the
rooms
this
scene
sufficient
for
what
you
might
be
imagining
in
terms
of
account
management's
where's,
my
digits
ER
guy
yeah.
What
do
you
think.
L
L
And
that's
kind
of
what
we've
been
moving
towards
as
having
within
their
account
somewhere
that
they
can
specify
their
acne
key.
You
know
specific
to
their
cap,
so
they
can.
They
can
make
that
proactively
or
within
the
acne
bridge
new
reg
a
call
they
can.
They
can
specify
an
external
secret
to
link
it
there
think
as
well.
So.
C
Yeah,
so
mum
Thompson,
if
you're,
asking
someone
to
bind
an
acne
account
key
into
existing
systems,
you're
going
to
want
to
prove
to
those
existing
systems
that
you
hold
the
private
key
for
that
yeah
good
point,
and
that
means
then
you
probably
need
some
advice
on
what
to
sign,
because
we
don't
want
people
creating
themselves,
cross-domain
confusion
in
the
tax
lansing.
Yes,
so
just
a
little
bit
of
advice,
here's
a
suggestion
make
it
a
jws
like
the
rest
of
acne
is
and
just
put
something
different
in
the
field.
F
C
J
Yeah
rich
rich
Saul's
in
the
back,
my
individual,
it's
an
API,
key
and
I
think
just
the
security
considerations
of
you
know.
Applications
you
have
a
certain
it
enterprises
using
this
retreat
as
securely
as
any
other
use
of
the
API
key,
and
that's
really
all
you
have
to
say.
Then
it's
mostly
importantly,
unsupportable.
F
All
right
good,
so
it
sounds
like
protocol
wise,
at
least
in
terms
of
the
new
reg
thing
we
can
argue
with
Jacob
about
what
exactly
we
should
call
the
field
that
will
put
a
field
in
its
that's
an
opaque
thing
where
you
can
put
whatever
the
CIA
gave
you
and
we
won't
say
anything
further
about
what
the
structure
is
and
then
I'll
talk
with
martin
about
what
we
should
put
in
security
considerations.
All
right
great
thanks.
F
Next
slide,
please,
the
other
requests
we
got
from
CA
from
interests
was
that
we
have
some
way
to
provide
more
information
on
if
you
think
about
a
lot
of
existing
CA
plus,
which
which
I
am
NOT
deeply
familiar,
but
I
believe
when
you
sign
up
as
a
customer
with
these
organizations,
you
provide
a
whole
bunch
of
information.
You
can
provide
context
of
information.
F
Some
organizational
information,
things
like
that
and
so
cas
might
want
to
be
able
to
request
that
clients
when
they
show
up,
provide
some
additional
information,
and
so
the
question
is
like
do
we
need
to
reflect
this
stuff
in
acne?
You
know
you
could
imagine,
having
sort
of
and
out
of
damn
thing,
a
user
action
required.
Please
go
to
this
web
page
and
fill
in
the
additional
stuff
before
I'll
accept
your
registration.
F
Now
that
we
have
that
mechanism
thanks
Eckhart,
you
can
imagine,
have
some
sort
of
external
pop
out
there.
You
can
imagine
doing
something
like
was
proposed
in
the
email
thread
of
having
a
designated
CA
extension
zone,
where
you
can
put
these
additional
fields
or
you
can
imagine
just
shoving
them
in
at
the
top
level.
So
that's
all
about
kind
of
how
the
ca
would
how
the
client
would
provide
that
stuff
up
to
the
CA
in
its
new
registration
request.
F
There's
also
the
question
of
doing
it
whether
we
need
a
way
for
the
ca
to
prompt
the
clients
to
say
yes,
you
sent
me
this,
but
no
I
really
need
more
information.
I
need
you
to
provide
these
for
the
following
non-standard
fields.
There's
I,
guess
some
question
about
how
you
deal
with
the
non-standard
feel
that
your
clients,
but
not
sure
they're
any
thoughts
about
what
to
do
here.
I
could
Oh
Martin.
Are
you
gonna
get
up
and
always.
C
C
C
To
put
it
in
this
bucket
accepted
wisdom
here
is
that
we
define
the
fields
in
the
freeform
text,
fields
that
we
already
have
there's
plenty
of
space,
and
if
they
turn
out
to
be
useful,
then
you
talk
about
standardization
at
that
point,
yeah
and
I,
don't
think,
there's
any
particular
need
for
a
special
bucket.
Now
the
question
of
what
to
do
with
fields
that
may
be
a
needed
by
particular
cas
and
and
would
be
required
of
proprietary
extensions
that
become
sort
of
critical
to
the
processing
of
a
request.
C
That's
a
special
problem
that
cas
create
for
themselves
that
I'm
not
sure
that
we
necessarily
need
to
concern
ourselves
with
in
the
protocol
right
right
here.
We
do
have
protection
against
someone
who
wants
to
actually
change
the
semantics
of
the
protocol.
Pneus,
that's
in
the
versioning
fields,
and
I
think
that's
perfectly
sufficient.
So.
F
If
I
could
summarized
at
least
the
protocol
the
aspects,
but
I
think
the
X
dash
the
X
dash
thing
is
really
good
analogy
for
those
who
have
not
been
following
it
used
to
be
that
in
HTTP.
If
your,
if
you
had
an
experimental
header,
you
prefixed
it
with
X
dash
and
the
problem
was
that
thing's
escape
from
being
experiments
and
became
standard
usage,
and
so
you
have
these
things
that
were
now
practically
standard.
F
You
may
have
seen
like
x-forwarded-for
by
name
and
experimental
header,
but
now
everyone
just
uses
it,
and
so,
rather
than
having
to
rename
things
that
became
standard
good,
the
current
guidance
is
don't
bother
with
X
dash
to
start
with,
and
so
the
correspondence
here
is
don't,
if
you're,
if
you
might
add,
say
organizational
unit
field
to
the
new
reg
in
this.
In
this
extension
bucket
shouldn't
bother
tagging
it
as
an
extension.
F
L
Clin
Wilson
I
actually
agree
with
with
Martin
here
a
great
deal
I
feel
like
it's
just
having
some
kind
of
general
top-level
list
is
the
most
flexible
solution,
and
we
don't
need
to
have
something
specific.
We
we
feel
like
we
can
get
by
without
this
at
all,
but
it
would
absolutely
be
very
useful
and
I'm
having
it
just
in
the
top
level
tickets
use
standardized
it
is
along
with
our
thinking,
is
so.
C
C
And
hold
your
breath
and
maybe
maybe
you'll
be
okay,
the
other
one
is
to
define
a
de
final
registry
and
lower
the
bar
make
it
really
easy
to
register
things
in
there,
and
I
would
suggest
something
like
specification
required
and
just
put
all
the
existing
ones
that
you
have
in
there
now.
Do
you
have
multiple
registries?
That's
probably
something
that
you
need
to
think
about
our
a
few
minutes,
but
it's
not
gonna,
be
particularly
difficult.
I
would
probably
just
want
to
say
no,
I
don't
know
I
think
about
it
myself,
but
it
seems
pretty
straightforward.
M
And
this
is
dkg.
I've
been
30
in
these
comments,
in
particular.
Just
want
to
highlight
that
the
reason
the
one
risk
that
you
have
of
putting
everything
at
the
top
level
is
a
coordination
risk
right
where
to
two
organizations,
start
using
the
same
name
for
two
different
purposes,
and
so
the
more
that
you
can
facilitate
coordination.
The
better
and
a
registry
is
a
reasonable
way
to
do
that.
C
F
Provide
some
back
pressure
for
duplication,
yeah,
gratuitous
duplication,
yeah
all
right
great
next
slide,
please.
So
this
one
went
a
few
rounds
on
the
mailing
list
about
requirements
and
authorizations
and
kind
of
the
object
model.
We
have
here,
Thank
You
Daniel
for
sitting
me
down
last
night.
We
kind
of
like
draw
droughts
and
diagrams
and
figured
out
what
the
what
the
proposals
should
go
forward
so
send
us
out
in
text
on
the
list
last
night,
but
we'll
go
through
it
here.
F
Kind
of
coming
at
this
with
two
goals:
I
think
Jacobs
initial
proposal,
which
is
in
the
poor
request,
is
to
try
and
deduplicate
status
fields
between
the
order,
object
and
the
authorization
object
and
remove
unnecessary
levels
of
abstraction.
So
right
now,
we've
got
basically
kind
of
three
levels
of
abstraction.
We've
got
an
order
which
has
requirements,
and
one
of
those
requirements
is
an
authorization
and
we
really
need
this
requirements
level
of
abstraction.
Or
can
we
just
have
orders
directly
having
authorizations
so
proposal
I'll
talk
about
in
detail
on
the
subsequent
slides?
F
It's
basically
erase
this
requirements
of
abstraction,
and
in
particular,
one
thing
that
would
do
is
remove
the
out-of-band
requirement,
which
is
the
only
non
authorization
requirement
we
had
then
once
you've
removed
that
you
take
instead
of
having
a
requirements
array
in
the
order.
You
just
say
here
are
the
authorizations
you
have
to
go,
get
and
don't
say
anything
further
about
whatever
the
cert
of
whatever
the
CA
would
require
to
get
a
cert
next
slide.
F
So
here's
kind
of
the
old
semantic
model
or
old
on
I,
say
currents,
that's
in
the
draft
right
now,
so
we
have
kind
of
two
clusters
here.
You
know
an
order
is
a
request
to
get
a
certificate
and
the
requirements
tell
you
what
you
have
to
do
to
get
that
certificate.
So
that's
kind
of
one
cluster.
An
authorization
is
a
request
to
get
an
identifier
and
the
challenges
tell
you
what
you
have
to
do
to
be
able
to
represent
that
identifier.
So
we
kind
of
duplicated
that
structure
in
these
two
places.
F
For
these
two
targets,
certificates
and
identifiers-
and
then
we
kind
of
link
them
together
by
saying
one
type
of
requirement
you
might
make
to
get
a
certificate.
Is
you
have
to
get
authorization
for
the
identifiers
in
the
certificate
and
we
made
that
distinction
so
that
we
could
also
have
this
out-of-band
requirement?
So
in
order
to
get
the
certificate,
you
have
to
prove
that
you
own
all
the
identifiers
in
it.
You
have
to
get
authorization,
then
you
also
have
to
have
a
user
load.
F
This
URL
and
you
know,
pass
a
CAPTCHA
or
submit
a
credit
card
or
you
know,
enter
their
favorite
color
or
whatever,
with
the
idea
that
you
know,
CAS
have
all
sorts
of
processes
leading
up
to
issuance
and
we
should
have
some
affordance
for
patching
those
processes
in
beyond
just
the
authorization
process
for
proving
identifiers
so
next
slide.
The
proposal
here
is
to
scratch.
Those
through
just
have
orders
directly
refer
to
authorizations.
F
You
know
no
change
in
the
bottom
right
hand
corner,
but
remove
this
level
of
abstraction,
remove
the
out-of-band
capability
and
just
have
just
have
the
protocol
talk
about
what
authorizations
the
client
has
to
do
before
the
CA
is
willing
to
issue
next
slide.
Here's
how
it
shows
up
in
the
order
objects.
Now
before
you
had
requirements,
one
of
those
authorizations
one
of
them's
out
of
band
on
this
also
shows.
F
One
thing
we
could
do
if
we
really
want
to
deduplicate
status
fields
is
just
in
line
the
authorization
ins,
the
order
object,
as
opposed
to
refer
to
it
by
reference
I'm
left,
I'm
totally
in
Finland
and
Jacob
said
we
shouldn't
and
I'm
fine
with
that.
So
yeah.
That's
that's
what
the
proposal
looks
like.
So
it
kind
of
compacts
down
the
semantic
model.
A
little
bit
you
know,
saves
I,
guess
some
server
logic
and
you
know
streamlines
the
capability
model
a
little
bit
so
I
guess.
F
The
question
here
is:
does
is
there
anyone
here
that
feels
the
out-of-band
stuff
is
really
necessary
or
that
we
really
need
this
generic
requirements
thing?
So
obviously,
what
we
can
do
I
mean
if
we
decide
we
need
some.
If
we
need
to
see
a
to
be
able
to
specify
some
other
requirements
in
the
future.
You
can
add
stuff
to
this
order,
object
and
say
in
addition
to
doing
these
authorizations.
You
also
have
to
go
out
and
do
this
other
thing.
F
C
Some
on
Thompson
I
think
the
general
structure
that
you
have
here
is
sign.
I
just
wanted
to
clarify
that
the
example
that
you
show
is
the
exploded
version
and
you
are
going
to
have
a
non
exploded
version.
That
is
simply
what
a
list
of
URLs
or
a
list
of
the
things
that
we
see
on
the
left,
because
we
don't
need
a
type
field
anymore
right,
yeah,.
F
H
H
G
F
That
case,
the
thing
you
get
back
is
an
authorization
directly
producer
change
there
yep
alright.
So
this
proposals
on
the
list
like
I
guess,
if
anyone
has
comments,
they
can
chime
in
there.
Anyone
else
in
the
room
have
questions
about
this.
Anyone
really
sad
about
the
out-of-band
stuff,
going
away.
I'm
looking
at
clin
he's
not
shaking
said.
F
Okay,
so
danger
of
showing
up
here
as
a
CIA
is
that
you
get
called
on
all
the
time
you
two
dating
ok,
so
I'm
I,
think
Jacob
and
I
are
more
or
less
in
agreement
on
this
now
as
editors
and
we
can
go
off
and
implement.
This
I
think
that
was
last
issue,
except
for
the
bike
shed
next
slide,
please
so
yeah.
This
is
the
proposed
change
in
terminology.
Just
came
up
on
the
list.
A
couple
days
ago,
Jacob
proposed
changing
applications
to
orders.
F
F
I've
done
I
know,
there's
some
cas
that
have
different
parts
of
it
in
there
I
think
mostly
their
interoperate
with
Cirque
pot,
which
is
a
legacy
implementation.
So
I
think
what
I
wanted
to
propose
here
is
that
we
do
more
or
less
what
TLS
is
doing
right
now,
so
they've
they've
had
their
having
a
working
group
last
call
to
kind
of
last
call
the
document
and
have
people
do
some
reviews
and
say
yeah.
The
document
looks
good,
it's
comprehensible.
F
It
seems
internally
because
it
seems
implementable,
but
then
let's
go
then
that's
absolute
last
call
and
kind
of
at
the
end
of
that
fix
any
comments
and
basically
declare
the
spec
stable
and
frozen
for
a
little
while
something
people
can
go
off
in
implements
allow
a
little
bit
of
time.
I,
don't
know,
probably
six
weeks
to
months
for
people
to
go
off
and
do
some
implementation
and
then
come
back,
probably
sometime
in
q1
and
learn
from
that.
Compare
notes
on
that
implementation.
B
So
the
proposal
here
is
basically
will
will
issue
a
working
group
last
call
and
any
changes
resulted
from
today's
meeting
where
the
working
group
last
call
will
create
an
implementation
version
and
we'll
ask
everybody
to
go,
who
is
building
an
implementation
and
implement
to
that
so
that
we
can
do
interrupt
testing
with
a
bunch
of
different
implementations
which
all
believe
they're
working
on
the
same
version?
If
we
get
everybody
interoperating
right
away,
boohoo
we're
done.
B
My
experience
with
this
in
other
working
groups
is
that
letting
this
drag
on
for
very
long
periods
of
time
is
a
failure
mode,
because
people
then
say
oh
well,
I'll
wait
and
let
some
other
person
finish
their
implementation
first
and
then
I'll
I'll.
Do
whatever
so
I
think
if
we
do
do
this
will
do
the
working
group
last
call
pretty
aggressively?
B
We
want
to
have
that
done
and
any
revs
from
it
done
before
the
end
of
the
year,
and
we
want
to
have
the
implementation
period
basically
between
the
new
year
and
Chicago,
so
that,
if
we
march
25th-
and
so
ideally,
we
would
come
to
the
conclusion
before
march
25th
that
we're
complete
with
this
document
and
we
can
not
even
raise
it
again
in
chicago.
If
not,
it
gives
us
a
nice
place
to
resolve
all
the
questions
that
may
have
come
up.
A
A
That's
like
this,
so
the
the
point
of
the
whole
thing
is
to
delegate
ownership
to
delegate
authorization
over
a
website,
and
normally
I'm
a
Content
owner.
I
want
to
see
the
end
to
delete
I
want
to
see
the
end
to
deliver
my
content.
For
me,
what
and
I
wanted
to
be
over
fearless,
of
course,
so
normally
what
people
do
today
is
this
simply
hand
out
the
private
key
and
certificate
to
the
CDN,
which
is
no
fun
so
we're
looking
for
an
alternative.
A
Will
at
the
look
thought
we
looked
quite
a
bit
at
a
different
way
of
doing
it,
where
each
TLS
handshake
is
basically
terminated
by
a
remote
box
that
has
the
private
key
and
the
signs
RSA
signs
the
relevant
parts
of
the
handshake,
but
obviously,
in
a
CDN
scenario,
high
performance,
all
I,
throughput
scenario
having
a
remote
box
touch
each
and
every
handshake
is
far
from
ideal.
So
we
are
looking
at
other
ways
of
doing
it,
and
this
is
shortened.
Certificates,
I
published
a
proposal
for
shorter
and
certificates
for
the
logged
off.
A
J
A
A
They
also
agree
on
a
policy.
So
what
domain
name
the
certificate
should
cover?
How
often
they
should
change
and
so
on,
and
that
policy
is
encoded
as
a
csr
template
as
a
binary
csr
template
that
the
CDN
will
be
able
to
use
when
it
requests
in
the
short-term
certificate
and
then
the
domain
name
owner
registers
with
the
arc,
my
server
next
and
the
course.
A
The
protocol
is
this
bootstrapper
a
phase,
and
this
is
where
the
CDN
is
asking
the
dno
for
to
get
the
short-term
certificate
series
for
it,
and
the
DNR
accesses
forward
state's
request
into
the
acne
server
so
step
by
step.
The
CDN
generates
a
CSR
with
the
template
that
it
received
the
offline.
Previously,
the
Dino
validates
that
the
CSI
is
actually
in
line
with
the
template
/
policy.
A
Then
it
sends
the
CSR
into
the
acne
server
requesting
a
short-term
certificate
or
what
we
call
short-term
automatically
renewed
certificate
with
a
cute
acronym
star
acne
does
all
the
normal
checks
authorizations
were
it's
the
DA
knows
responsibility
to
fulfill
the
authorizations.
So
if
you
need
to
test
the
NS
or
to
test
HTTP
01,
it's
the
Dino's
business
to
get
it
to
work
and
then
once
it
gets
once
the
ca
is
happy
with
the
authorizations
it
gives
back
a
URL
were
the
CDN
will
be
able
to
fetch
the
certificate.
A
This,
the
DN
owner
returns
this
URL
to
the
CDN,
and
the
CDN
can
now
go
out
and
retrieve
the
certificate
directly
from
the
ACMA
server.
Next,
every
once
in
a
while
say
every
three
days
or
so
the
acme
the
CDN,
wants
to
get
and
use
a
new
certificate
so
that
it
always
has
a
valid
certificate
for
this
piece
of
content.
It
goes
directly
to
the
at
my
server
and
fetches
the
certificate
from
they're
this
URL.
A
A
For
this
particular
series
of
short
on
certificates,
serious
come
comes
with
a
particular
identifier
of
star
ID
lakme
server.
Now
stocks
issuing
the
certificates
certificates
are,
of
course,
still
valid
for
the
duration
that
the
issued
for
and
that's
the
whole
point
of
short-term
certificates.
It's
short
enough
to
make
to
make
revocation
effective,
and
then
we
don't
do
any
classical
x509,
revocation,
no
CR
else,
no
ocsp.
A
D
Daniel
McCarney,
let's
encrypt
so
before,
I
was
involved.
Let's
encrypt
I
worked
for
a
CDN
whose
name
did
not
start
with
the
letter.
A
and
I
think
this
is
an
interesting
technology,
but
I'm
a
little
bit
curious
about
the
motivations
are
particularly
in
terms
of
whether
you
think
there's
been
a
lot
of
demand
on
CD
ends
for
this
sort
of
technology
to
be
applied
and
whether
there's
been
any
participation
from
existing
cdns
kind
of
demonstrating
an
interest
to
implement
something
like
this
yeah.
A
B
It's
at
hardy
from
the
floor,
so
I
really
appreciate
the
way
your
diagrams
make
it
very
clear
that
what's
happening
here
is
sort
of
the
domain
name
owner
using
split
client
model.
They
do
all
of
the
work
of
make
making
the
the
requests
to
the
acne
server.
They
they
get
the
authorization
URL
and
then
they
they
turn
around
and
they
share
with
a
different
machine
and
the
fact
that
the
different
machine
is
actually
an
outsourced
service
as
opposed
to
a
a
part
of
their
own
domain.
B
It's
kind
of
not
our
business
right
that
that's
their
choice,
but
it
strikes
me
that
you
could
carry
that
forward.
That
model
a
little
bit
further
and
simplify
this
radically
and
simply
say
it
continues
to
be
the
case
that
that
domain
name
owner
goes
through
the
registrations
on
a
cyclical
basis
and
refreshes
that
URL,
so
that
you
know
they
do
that.
B
To
simply
say
the
domain
name
owner,
passes
the
checks
and
then
at
at
the
the
period
when
the
the
certificate
would
be
close
to
invalidation
for
time
purposes,
just
refreshes
it
and
since
you're
already
creating
this
mutually
authenticated
channel.
I.
Don't
really
understand
why
you
don't
just
use
it
and
continue
to
use
certs
that
that
we
don't
have
to
give
a
special
nice
acronym
to,
but
simply
have
shorter
than
usual
periods
of
validity.
Yeah.
A
So,
basically,
when
you
pay
for
a
CDN,
you
would
like
as
much
of
the
high
availability,
always
on
twenty-four/seven
stuff,
to
be
on
the
city
inside
and
not
have
the
dno
actually
be
available
once
every
three
days
to
make
sure
that
this
all
dance
happens
so
I
think
that's
our
main
motivation
for
passing
the
responsibility
of
throwing
the
responsibility
away
from
the
dno
and
into
the
ca
into
the
CA.
Actually,
in
this
case,
do.
B
You
want
to
ask
a
clarifying
question,
and
so
the
clarifying
question
is
whether,
then,
you
believe
that
the
the
dno
and
the
CDN
are
not
actually
communicating
on
other
topics
within
this
time
scale
right.
So,
if
they're,
if
they're,
not
getting
fresh
content
or
otherwise
of
contacting
the
Dino
during
this,
this
timescale,
I
sort
of
see
your
point,
but
if
there's
other
contacts
going
on
I
really
don't
understand
why
this
would
be
onerous
for
the
Dino
to
be
online
to
make
these
these
checks
I.
A
J
N
O
Nick
Sullivan
CDN,
okay,
just
see
the
end
for
which
cloudflare
so
for
which
the
business
model
is
that
DNS
is
operated
by
the
CDN
you
mentioned.
That
is
one
of
the
security
considerations.
Is
that
really
realistic
to
expect
your
CDN
and
your
DNS
provider
to
be
different?
It's
a
pretty
common
use
case
for
them
to
be
the
same.
So.
A
E
K
Around
necessary
google,
so
the
solution,
one
solution
we
have
in
mind
for
that
is
have
like
separate
city
logs
for
like
shortly
with
certs,
which
will
be
able
to
roll
much
faster
or
maybe
find
ways
to
somehow
trim
the
democracies
are
kept
in
city
logs
for
for
short,
it's
live
certificates
and
have
other
logs
for
long
the
circuits.
Thank
you
thank.
C
G
M
Is
like
you're
going
to
push
over
here
it
kind
of
pops
out
over
there,
so
well.
That
means
that
CT
log
isn't
going
to
be
as
big.
It
means
that
our
window
of
like
compromise
notification
that
you're
supposed
to
get
from
CTE
will
become
smaller,
so
it
doesn't
sound
like
an
actual
solution
to
me,
it
just
sounds
like
saying
sure
we
can
sort
of
shuffle
the
operational
trade-offs.
J
B
B
J
B
Yeah,
obviously,
we
can't
have
a
discussion
when
only
a
couple
of
people
have
have
read
it.
We
do
encourage
you
to
read
it
in
particular,
if
it's
going
to
be
a
requirement
to
adopt
the
short-term
certificate,
as
currently
presented,
then
clearly
understanding
its
trade
offs
as
part
of
understanding
of
the
larger
set
of
trade
up
surround
short-term
certificates.
A
B
P
J
J
Q
Well,
actually,
after
your
last
remarks,
we're
gonna
move
stir
to
see
MPs
right
people
clearly
or
not
welcome
here,
no
I'm,
sorry
I'm,
just
joking
yeah.
So
in
the
store
working
group
we
are
interested
actually
in
using
Acme
to
gap
certificates
related
to
telephone
numbers.
We
have
some
interesting
extensions
to
certificates
for
telephone
numbers
that
we've
been
developing
over
in
the
store
working
group,
but
we
desperately
need
are
some
ways
that
people
can
actually
like
get
them
cuz,
they're
hard
to
get
now
and
so
which
barnes
nigh,
put
forward
kind
of
straw.
Q
Man
draft
we
did
just
send
a
note
to
the
list.
I
did
not
ask
for
it
in
the
time
here
today
to
discuss
this,
because
we
needed
to
talk
about
it
a
bit
instr
first,
but
expect
that
to
come
around
and
yeah
if
there's
interest-
and
that
will
be
progressing
that
here,
because
it
does
define
you,
identifier,
snot
new
challengers
things
like
that
for
acne,
and
then
you'll
have
to
learn
our
wall
yeah
or.
J
B
P
Q
J
Q
I
think
the
discussion
from
this
morning
is
very
positive.
There
was
a
lot
of
energy
there
around
doing
this.
We
need
to
probably
end
up,
doing
really
is
doing
kind
of
like
some
of
the
work
that's
released
or
a
specific
instr
about
kind
of
like
how
we'd
apply
this
to
some
particular
attack,
actually
doing
the
validation.
Q
So
we
want
to
do
within
sip
itself
with
us,
but
yeah
I
think
the
discussion
there
is
positive
about
going
forward,
and
so
necessarily
we
would
need
to
come
to
here
where
the
expertise
is
to
work
on
the
parts
of
this.
That
would
be
specific
to
the
finding
like
new
identify
or
acne,
and
so
on.
Yeah
positive
session.
J
J
B
G
Kathleen
Moriarty,
so
I
gets
closed
down
to
working
group
the
next
couple
of
days,
so
I'm
not
going
to
push
other
ones.
If
there's
real
work
to
be
done,
it
should
get
done
right.
So
if,
if
there's
good
work
that
the
working
group,
things
should
be
adopted,
I'm
totally
fine
with
that,
because
that's
how
are
driven
we're
driven
by
working
groups
and
what
people
want
to
get
done
so
we'll
take
it
by
that
and
by
the
advisement
of
the
tears
from
assessing
what
the
group
wants
to
do.
B
So
I'm
not
sure
rich
was
close
enough
to
the
esky
okay.
Well,
probably,
during
that
period,
when
we're
going
through
the
implementation
phase
will
be
concurrently
running
a
charter
discussion
on
the
mailing
list
to
figure
out
whether
there
are
other
items
that
we
believe
can
be
tackled
in
a
useful
way
in
a
relatively
short
term.
B
We're
not
looking
for
you
know
solving
world
hunger,
so
closing
down
a
working
group,
finishing
its
work
and
then
chartering
a
new
one.
It's
not
a
bad
thing!
So
if
we
actually
just
finish
this
work
and
any
you
know,
any
pieces
obviously
needed
to
associate
with
it.
But
that's
okay!
We
don't
have
to
solve
world
hunger
if
we
do,
that
would
be
astonishing,
also
cool
any
other
discussion
for
today.