►
From YouTube: IETF94-ACME-20151106-0900.webm
Description
ACME meeting session at IETF94
2015/11/06 0900
A
A
A
A
B
Good
morning,
everybody
we
are
today
Friday
the
last
session
of
ITF
94
I,
don't
know
if
anybody
actually
got
to
see
it.
The
morning
was
actually
visible,
but
that's
Fujisan
and
you
are
an
acme
where
you
do
not
have
to
scale
Fujisan,
despite
it
being
the
local
acne,
will
probably
start
the
actual
presentation
in
a
few
minutes,
given
that
it
is
friday
morning
we
expect
people
to
kind
of
trickle
in
a
little
bit,
but.
B
B
B
C
A
C
Hello,
all
right,
so
we
are
currently
at
version
01
of
acne
on
the
chairs
finally
reminded
me
that
I
should
submit
00
a
little
while
back,
which
I
did
I
had
held
off
submitting
00
because
Andrew
air
had
pointed
out
the
signature
use
vulnerability
in
the
individual
draft
version,
but
went
ahead
and
submitted
it
with
this.
Do
not
implement
copy
out
at
the
front,
so
the
major
fix
in
the
0020
one
transition
was
to
fix
that
signature,
reuse,
vulnerability,
which
I
think
has
been
pretty
thoroughly
discussed
on
the
list.
C
So
I
will
recap
it
here.
Peter
Eckersley
also
pointed
out
some
issues
around
default:
virtual
hosts,
which
we'll
discuss
a
little
bit
more
a
little
later
on
in
this
deck
we
I
put
in
some
provisional
fixes
there
I
think
the
fix
for
the
http-based
challenges
are
probably
good
to
go.
We
might
revisit
the
TLS
sni
based
fix
a
little
later.
C
Let's
see
oh
yeah
at
the
end
once,
even
though
this
version
fixes
the
signature,
we
use
vulnerabilities
and,
I
think,
is
as
good
as
we
know
how
to
make
the
protocol
right
now.
I
forgot
to
remove
the
do
not
implement
caveat
this
version.
01
is
what
let's
encrypt
is
currently
using
for
the
records,
so
there
is
some
deployment
out
there
next
slide.
Please,
okay,.
C
Yes,
just
to
read,
I
guess
I
will
recap
the
signature
use
issue,
so
the
fix
the
signature
use
issue
was
well.
What
Andrew
pointed
out
was
that
the
way
we
were
using
signatures
in
the
challenges
we
had
defined
relied
on
using
the
fact
that
someone
could
generate
a
specific
signature
value
as
proof
that
they
had
a
certain
public
key,
and
what
Andrew
pointed
out
was
that
you
could
cry
given
the
signature
value
that
had
been
provisioned
by
the
real
domain
owner.
C
In
some
cases,
you
could
craft
a
key
pair
that
would
produce
that
signature
value.
So
to
avoid
relying
on
that
property
of
signature
systems,
which
is
not
a
common
property,
we
refactor
things
not
to
use
signatures
at
all,
but
instead
just
to
provide
directly
the
token
from
the
challenge
and
a
digest
of
the
account
key,
that's
being
authorized.
Remembering
the
challenges
are
the
way
the
owner
of
a
domain
expresses
his
authorization
for
an
account
key
to
act
for
that
domain
and
acne.
C
So
one
of
the
nice
things
about
that
was
that
we
now
have
a
lot
of
consistency
in
how
the
challenges
are
expressed
so
that
token
dot
dot.
Thumbprint
thing
is
now
a
standard
construct
that
is
used
in
http-based
validation
as
an
eye
based
validation
and
dns
based
validation.
The
latter
two
cases
have
some
compactness
requirements
so,
instead
of
using
that
thing
directly,
we
use
the
digest
of
it,
but
it's
either
the
thing
itself
or
digest
of
the
thing.
The
same
in
all
three
cases,
nice
little
bit
of
consistency
there
Mick
slide.
Please.
C
Default
V
hosting
the
issue.
There
was
that
in
some
server
deployment
environments,
if
you've
got
a
bunch
of
virtual
hosts
behind
it,
CLS
server
and
someone
sends
you
a
client
hello
that
has
this
NSN
I
field
that
you
don't
recognize.
Oh
these
are
these
hosting
environments
will
send
that
client
hello
to
some
default
of
be
host.
They
have
configured.
C
The
upshot
of
that
is
that,
if
that
is
it,
a
domain
is
hosted
in
one
of
those
environments,
then
that
default
V
host
can
use
the
S&I
based
validation
or
the
http-based
validation
using
TLS
to
get
a
certificate
for
any
other
hosts
on
that
V
house.
So
that
seemed
like
kind
of
a
bad
thing,
well,
yeah,
so
to
try
and
work
around
that.
C
So
you
tend
not
to
have
as
much
of
a
need
for
that.
So
HTTP
validation
is
now
really
only
HTTP
validation,
not
HTTP
or
HTTPS
validation
figured
that
was
pretty
safe
to
remove
that.
If
we
wanted
to
do
an
HTTPS
base
one
in
the
future,
we
could
just
add
an
HTTPS
challenge
in
a
TLS
sni
validation
case.
The
solution
that
Eckersley
proposed
was
to
instead
of
doing
a
single
round
of
challenging
the
client
to
produce.
You
know,
provision
a
random
looking
s,
an
eye
on
the
server
and
provide
an
assert
that
corresponds
to
that.
C
Let's
generate
a
sequence
of
several
random
looking
values
and
require
the
server
to
respond
for
some
random
subset
of
that
chosen
by
the
server
yeah
I
see
the
face.
Aaron
is
making
yet
it's
complicated
and
big
dance
and
it's
been
for,
but
there's
a
PR
right
now
proposing.
We
revert
this
change,
so
keep
that
in
mind
as
we
go
forward
next
slide,
please
alright,
so
that
that
was
all
the
major
changes
in
the
transition
01.
C
Since
then
this
week,
I
went
through
and
merged
a
bunch
of
trivial
editorial
pr's
and
including
fixing
the
do
not
implement
caveat.
So
now
it's
officially
implement,
as
Ted
said,
I
kept
a
little
bit
of
a
cavanna
tops
like
copies
crimson
text
from
TLS
13,
which
has
a
nice
little
disclaimer
at
the
top
says,
this
is
still
a
work
in
product
process.
There
may
be
more
security
analysis,
so
if
you
deploy
be
careful
and
added
a
pointer
to
the
github
repo,
its
top
of
the
document
as
well.
C
Next,
please,
that's
just
a
list
of
the
thing
was
emerged:
they're
all
little
little
things
getting
rid
of
the
simple
and
simple
HTTP,
because
we
don't
like
simplicity,
alright,
so
today,
I
think
the
plan
was
just
to
go
through
the
issues
in
pleura,
quests
I
went
through
all
the
issues
in
pr's
in
the
github
repo,
and
we
have
slides
on
that
turn
them
into
slides
and
I've
got
some
suggested
resolutions
for
them.
In
some
points,
I'd
like
to
get
some
feedback
on
next
slide,
so
yeah.
C
Well,
so
hopefully
we
can
end
up
with
some
extra
security
at
the
end
of
the
day,
alright,
so
I'm
trying
trying
to
make
this
roughly
in
order
of
difficulty.
So
we
can
take
more
and
more
time
on
these
issues
as
we
go
through
them.
This
one
I
thought
was
pretty
straightforward.
Someone
propose,
we
add
a
domain
to
the
when
we
do
a
TLS,
S&I
validation.
C
Currently,
we
just
have
challenged
won
that
challenge
to
acme,
not
invalid,
as
the
the
server
name,
its
presented
to
the
TLS
server.
What
that
means
is
when
that
name
comes
in.
If
you
haven't
configured
the
server
a
priori
to
know
where
to
send
this,
the
server
has
no
idea
where
to
send
it,
because
it's
just
a
bunch
of
random
junk
back
me
down
invalid.
C
B
Yeah,
basically
I
was
going
to
say,
I'm,
certainly
aware
of
host
strings.
That
would
be
very
interested
in
using
hackney
that
are
close
to
the
bite
limit,
because
they're
relatively
deep
hierarchies
people
are
interested
in
using
this
in
enterprise
contexts
where
you
know
it
would
be
host
name,
location,
corp,
enterprise
named
top-level
domain,
and
if
you
start
having
two
challenges
in
front
of
that
it
and
and
acne
and
invalid,
it's
it's
going
to
blow
up.
So
I
think
the
255
bite
limit
really
write.
Writes
this
out.
Yep.
C
All
right
does
anyone
think
this
is
an
important
failsafe,
because,
if
not
I'm,
just
going
to
close
the
issue
won't
fix
all
right.
So
be
it
all
right,
good,
easy
one
kill
the
second
one.
This
one
is
a
little
bit
subtle,
so
this
started
out
as
a
row
as
a
proposal
to
a
DS,
a
PR
that
adds
a
specific
error
to
the
table
of
errors
which
will
ultimately
be
in
a
ana
registry.
C
So
it
raises
the
question
of
what
should
we
do
about
error?
Extensibility
chances
are
as
we
develop
this
and
get
some
implementation.
Experience
will
want
to
flush
out
the
error
registry
to
provide
more
detailed
semantics,
and
the
question
is:
how
should
we
manage
this
right
now?
There's
a
requirement.
Well
right
now.
C
Let's
say
we
have
a
specification
that
we've
defined
the
urn
Acme
namespace
and
there's
a
proposal
in
the
PR
that
we
require
servers
not
to
emit
errors
in
that
namespace
unless
they're
defined,
so
the
requirement
would
be
your
server
is
non-compliant
if
it's
emitting
errors
that
are
earning
acme
and
they're,
not
registered
errors.
So
you
know,
a
client
can
then
use
that
urn
acne
namespace
as
an
indication
that
it's
getting
something
that's
likely
to
understand
late.
D
So
I
think
it
depends
on
what
kind
of
registry
control
you
want
right.
If
you,
if
you're
going
to
do
like
an
expert
review
or
specification
required,
you
might
as
well
keep
it
in
in
the
URL
naqvi
in
space.
It
doesn't
matter
and
if
it
going
to
be
a
first
come-first
curb
or
a
very
sort
of
just
spam
control,
then
you
just
let
people
use
whatever
you
are
I
stable,
yeah.
C
C
To
be
honest,
the
urn
thing
is
kind
of
an
artifact
of
the
are
reuse
of
the
problem
document
format.
So
maybe
we
can
just
let
a
thousand
errors,
bloom
speak
and
and
just
let
people
shove
whatever
they
want
show
whatever
took,
and
they
won't
after
earn
a
key,
but
Ted
seems
like
you
might
have
an
opinion
about
that.
B
Said
Hardy
again,
I
I,
don't
think
it's
a
problem
to
have
a
non
urine.
Acne
namespace
error
messages,
but
I
do
I
did
want
to
suggest
that
we
actually
pull
out
the
registration
of
the
you
are
n
into
a
different
document
so
that
we
can
progress
that
quickly
and
get
it
set,
because
the
process
for
getting
a
you,
AR
n
need
is
a
bit
of
Arcana
I've
dealt
with
a
couple
of
different
times
and
it
is.
It
is
not
quick
our
canna
at
the
moment
because,
there's
a
you,
are
envious.
Working
group
guard
I.
B
Apologize
I
was
so
excited
about
your
ends.
I
turned
off
the
mic
for
those
of
you
playing
the
home
game.
What
I
said
was
the
you
are
ends,
are
a
bit
of
Arcana
I've
dealt
with
in
the
past
and
it
can
be
a
bit
slow,
so
I
propose
that
we
actually
pull
out
this
registration
and
do
it
separately
from
progressing
the
document,
so
we
can
do
it
in
advance.
Anybody
have
a
problem
with
that
proposal.
B
D
So
let
your
honey
I
think
extensibility
for
errors
is
kind
of
dangerous,
it's
actually
very
hot.
For
for
a
lock,
you
know
a
wide
range
of
chance
to
agree
on
common
semantics
players,
so
when
I
would
suggest
is
that
have
a
mi
registry,
for
you
are
an
acne,
have
specification
required
for
those
and
then
but
allow
other
URI.
So
if
you
want
to
have
your
own
local
thing
right,
don't
don't
expect
anybody
else
down
stat
it
so.
D
Thing
out
it
just
let
people
stick
whatever
your
eyes.
They
want
right.
Okay,
don't
have
the
protocol
m
force.
You
are
ms,
just
let
people
use
whatever
you
are
eyes.
They
want
right,
but
the
things
that
you
expect
all
kind.
The
semantics
I
expect
all
clients
understand
at
the
URL
acne
and
have
specification
required
for
it.
D
A
Yeah
I'm
just
a
quick
comment
that
actually
you
know
I
I'm,
not
that
optimistic
about
your
end
is
getting
the
best
document
out,
but
there
is
an
interest
in
expediting
getting
getting
namespaces
registered
so
right.
So
so
that
might
be
fine
I,
don't
think
that
eat
the
you
are
n
ends
themselves
need
to
be
overly
complex
here.
I
think
it
could
be
pretty
straightforward,
so
I,
don't
I,
don't
see
the
logistical
side
of
this
is
a
problem
and
actually
I
don't
see
the
semantic
side
of
it
is
a
problem
either.
So
yeah.
F
So
none
Thompson
I
was
wondering
why
you
chose
your
n
acne,
rather
than
just
look
at
being
a
subject
to
one
of
the
existing
urine,
ITF
or
whatever,
whatever
is
used
as
well.
I
did
sorry,
so
we
have
urine
something
idea
of
something
something
something
in
another
number
of
other
places
and
registering
things
in
that
spaces
has
proven
to
be
relatively
straightforward.
There's
there's
a
bcp
on
it
and
it's
I've
done
it
before.
It
was
just
a
matter
of
writing.
Writing
an
RFC
and
then
I
own
I
acted
upon
that.
B
So
I'm,
going
to
put
myself
virtually
on
the
floor
for
a
second
I,
still
think
it
would
be
a
good
idea
to
pull
it
out
into
a
separate
document
of
whether
we
are
going
to
put
it
in
an
existing
namespace
or
construct
a
new
one.
Depending
on
whether
or
not
we
want
people
to
be
able
to
register
things
into
this
namespace
with
specifications
outside
of
the
ITF,
which
is
a
question
we
would
deal
with
in
that
document,
we
might
make
either
choice
but
I
I'm
fine,
with
it
being
in
an
existing
names.
F
So
the
other
thing
that
I
was
going
to
suggest
here
is
that
we
seem
to
be
discussing
things
that
relate
to
the
the
problem
draft
that
is
in
apps
area
working
group,
apparently
so,
rather
than
try
to
prescribe
what
goes
in
that
particular
field
here,
maybe
we
should
just
leave
that
to
the
apps
area
working
group
to
define
how
you
feel
that
particular
field
and
they
have
rules
I,
think
you
will
find
and
we
can
just
follow
those
rules.
I
don't
see
that
there's
any
need
for
us
to
prescribe
further
than
that.
I
mean.
F
C
F
C
You
have
suggestions
on
other
places.
We
might
other
you
know,
or
you
are
in
constructs
we
might
use
nail
to.
The
list
would
be
helpful.
Another
point
that
occurs
to
me
as
we're
talking
about
your
ends
if
we
might
want
to
not
put
the
errors
directly
under
whatever
namespace
be
defined,
but
instead
define
some
error
space
within
it
in
case
we
want
to
name
other
things.
C
Thank
you.
Okay,
minutes
capture
that
Thanks
all
right,
so
good,
I'll
get
Jacobs
update
that
PR.
We
should
be
able
to
line
that
pretty
quickly
next,
please
I
so
yeah.
Here
the
the
proposal
was
to
use
an
extension
for
simple.
If
ever
the
paths
we
have
in
simple
HTTP,
so
recall
that
a
simple
HTTP
now
called
HTTP
01
in
this
challenge
the
server
the
client
proves
his
ownership
of
a
domain
by
provisioning,
a
file
in
an
HTTP
server
right
now.
The
process
that
the
server
follows
to
verify.
C
That
challenge
requires
the
content
type
of
that
returns
in
the
HTTP
response
to
be
either
text
plain
or
nothing.
Now,
when
you're
building
a
sex
who
fulfill
these
challenges.
This
raises
the
question
of
how
do
I
get
my
HTTP
server
to
omit
the
correct
thing?
Those
of
us
who
know
how
to
configure
HTTP
servers
and
there
a
variety
of
ways
to
do
this,
but
one
of
the
simpler
ways
is
just
put
txt
at
the
end,
however,
the
structure
of
the
URL
is
defined
by
acme
and
it
says,
don't
put
txt
at
the
end.
C
I'm
not
sure
I
think
I
may
have
put
the
wrong
proposal
here.
Different
proposal
proposed
just
ignore
the
content
type
thumbs
up
from
Thompson.
Anyone
think
that
it's
important
for
the
servitor
check
the
content
type
when
checking
the
response
from
the
server
that
purports
to
prove
ownership
of
the
domain
said.
B
C
B
Had
a
different
default
encoding
that
might
run
into
this
issue
and
as
long
as
they
were
doing
anything
in
utf-8
space,
all
of
the
ASCII
fields
are
the
same.
So
it
seems
like
a
corner
case,
but
maybe
we
want
to
point
out
that
corner
case.
If
we
adopt
the
do,
no
do
no
content
type,
that
if
your
content
system
and
does
not
use
a
ski,
you
need
to
make
sure
that
this
particular
content
turns
into
a
ski.
When
you're
meeting
the
acne
test,
yeah.
C
B
But
if
you
include
something
else
like,
if
you
give
us
a
car
set,
that's
you
know
JP
dash
to
32
or
something
it
will
fail
right
now.
The
question
you
run
into
there
is
because
a
ski
is
a
strict
subset
of
utf-8.
If
somebody
gives
you
a
car
set
and
says
it's
you
GF
aid,
what
do
you
expect
to
happen
right.
C
F
F
C
Was
leaning
in
that
way
as
well
to
just
fix
the
serialization
in
bytes
and
say
the
payload
you
return
me
must
be
the
utf-8
encoding,
because
I
think
that
in
practice,
the
way
people
are
going
to
implement
the
validation
algorithm
you're,
probably
going
to
run
into
issues.
If
you
try
to
use
a
different
character
set
anyway,.
B
Tetra
Deegan
I
would
agree
with
you
that
if
you
try
and
use
a
different
set
of
characters,
especially
with
text
plain,
the
chances
are
you
getting
it
right
and
validating
are
pretty
slim.
So
if
you
do
it
as
a
sara
lee
as
a
serialization
of
bytes
and
utf-8
I
think
my
implication
here
is
that
I
disagree
with
Martin
and
that
we
should
not
allow
white
space,
because
that
simplifies
your
life
enormously
and
simply
do
it
as
a
serialization
of
bytes,
no
whitespace,
no
end
of
line
yep.
Okay,.
C
G
G
B
Teddy
actually
I
was
about
to
say
something
a
little
less
cryptic,
but
exactly
the
same
effect.
But
if
you
do
a
prefix
match
here
or
essentially
permit
whitespace
only
at
the
end
of
the
matching
octet,
then
I
think
you
get
both
properties
and
I.
Think
if
somebody
is
a
a
server
administrator
and
they
see
XY
carriage
returns
e2
and
it
doesn't
match
XYZ
to
they'll,
they'll,
recognize
it
or,
if
there's
XY
blank
space
z2
and
it
doesn't
match
X
Y
Z
to
they'll
recognize
it.
C
B
So
there's
the
yeah
you
could
you
could
basically
yeah
okay,
so
white
space
permitted
only
at
the
end
is
actually
probably
the
characteristic
you
want,
because
you
could
have
a
prefix
match
where
there
were
garbage
characters
that
were
not
white
space
and
would
still
match
the
prefix
and
that's
probably
downs
as
I
recollect
with
you.
So
white
space
is
permitted
only
at
the
end
boo
that
this
is
always
fun
to
write
the
a
B
and
F
for
I.
F
F
I
think
that's
I,
think
that's
a
perfectly
acceptable
outcome.
I
mean
you
could
put
arbitrary
amounts
of
junk
at
the
end
as
well,
and
have
some
level
of
confidence
that
the
that
the
person
had
put
that
information
there,
but
I
see
no
reason
to
allow
for
the
valid
token
plus
someone's
essay
or
something
like
that.
That
suggests
that
there
might
be
some
some
way
that
someone
could
squeeze
that
in
and
at
the
start
of
the
document
that
I
don't
know.
F
G
C
All
right,
so
we
will
allow
spaces
at
the
end
of
our
bike,
shed
alright
great.
So
that
sounds
like
a
got
a
resolution
here.
Okay,
I'm
one
request.
I
got
that
there's
an
issue
for
us
to
support
a
key
role
over
for
account
keys.
So
right
now
we
have
this
notion
of
registration
when
a
client
first
shows
up,
he
registers
his
contact
information
and
this
signs
that,
with
an
account,
keep
air
and
then
forevermore
that
account
keep
air,
represents
the
registration,
and
so
when
a
client
shows
up
and
says,
give
me
an
authorization.
C
The
key
that's
used
to
sign
that
request
for
authorization
is
the
thing
that
identifies
which
client
that
came
from
identifies,
which
registration,
which
account
that
came
from
as
it
stands
right
now,
there's
the
only
time
you
can
set
the
account
key
is
when
you
create
the
registration.
So
de
facto,
you
have
one
account
key
forever
when
you,
once
you
created
a
registration-
and
you
can
imagine,
you
know,
clients
having
a
long-term
relationship
of
the
ca
having
the
same
account
for
a
long
time,
and
it
might
be
concerned
about
the
stability
of
that
key.
C
That
possible
compromise
of
an
account
key,
and
so
they
might
want
to
rotate
their
account
keys
every
so
often
so
the
proposal
here
well
first
proposals.
I
think
this
seemed
like
a
reasonable
thing
to
implement
anyone.
I
think
this.
This
is
not
a
good
idea.
This
is
too
much
overhead,
okay,
so
I've
Ted.
B
Temporary
kind
of
a
clarifying
question:
I,
don't
have
like
serious
agita
about
it,
but
I
I
thought.
The
theory
here
was
that,
in
a
situation
like
this
I,
a
client
created
a
new
account
and
got
credentials
for
the
same
servers
on
the
new
account
using
challenges,
and
and
could
there
thereby
eliminate
the
old
account
once
the
new
account
had
had
appropriate
credentials.
Now
the
the
difference
between
that-
and
this
is
really
now-
you
need
a
mechanism
to
destroy
an
accounts
as
opposed
to
a
mechanism
to
roll
over
an
account.
B
It
becomes
functionally
how
you
do
the
key
roll
over
well.
The
other
difference
is
that
the
reason
you
might
prefer
it
that
way
as
far
as
I
can
tell
is.
It
also
means
that
you're
using
the
same
mechanism
for
loss
of
credential
that
you're
using
for
key
role
over
right,
because,
whatever
proof
I
gave
you
to
say,
hey
I've
lost
my
private
key
and
and
therefore
I
need
to
create
a
new
accounts
to
to
manage
the
same
domains.
B
G
Jones,
let's
encrypt
the
reason
we
in
particular
would
want
to
keep
to
roll
over
an
account
key
is
because
in
practice
we
have
special
relationships
with
certain
subscribers
and
it's
a
configuration
problem
to
have
to
move
all
of
that
information
from
one
opaque
public
key
to
another.
It
would
be
nice
to
be
able
to
do
this
in
a
API
fashion.
B
G
C
And
it
also
seems
like
that
we
do
have
recovery
mechanisms
in
the
draft
right
now
and
they're,
pretty
darn
heavy
weight,
because
you
don't
have
the
original
account
key.
So
you
have
to
go
through
some
giant
complicated
dance.
It's
a
prove
you're
the
original
got.
It
seems
like
it
seems
plausible,
since,
given
them,
we
have
two
mechanisms
already
to
have
a
third,
that's
sort
of
the
orderly
way
to
joy.
B
C
C
So
I
think
I've
got
a
sketch
of
this
in
the
next
slide
yeah.
So
the
the
proposed
is
the.
This
is
just
sort
of
a
notional
construct
to
use
something
like
to
do
a
post
to
the
registration.
In
point.
The
same
way,
you
would
do
to
update
your
email
address.
It's
the
contact
information,
that's
associated
with
your
account
and
in
that
to
put
a
turkey
or
new
key
field
that
has
a
jwk
that
signs
with
the
new
key
over
some
information
that
characterizes
the
existing
account.
C
So
you
would
want
to
use
that
resource
thing
as
we
do
in
the
other
messages
to
ensure
uniqueness
and
have
the
registration
field
to
indicate
that
the
new
key
agrees
to
be
bound
on
to
this
this
account.
So
that
goes
into
the
overall
message,
which
gets
signed
with
the
old
key,
so
that
you
get
this.
You
get
clearer
authorization
from
the
old
key
to
the
new
key
and
you
get
the
new
key
assenting
to
be
bound
into
this.
This
look
roughly
accessible
to
folks.
If
we're
gonna
have
this
mechanism.
C
C
Yeah
so
raise
your
hand
if
you've
heard
of
certificate,
transparency
yeah
so
certificate
transparency,
the
the
operative
part
of
it
right
now
is.
Are
these
things
called
signed
certificate
time
stamps,
which
is
how
a
web
server
proves
to
a
browser
or
a
certificate?
Subject:
groups
for
relying
party
to
take
my
browser
head
off
that
they
that
the
certificate
he's
presenting
was
logged
in
CT
and
CT
defines
a
couple
of
ways
to
provide
this.
You
can
put
an
extension
in
the
cert.
You
can
use
any
ocsp
extension
or
you
can.
C
The
ca
just
provides
them
at
insert
or
a
no
CSP
in
that
third
case,
with
the
TLS
extension,
the
client
the
web
server
might
want
to
download
is
going
to
need
to
download
the
SCT
somehow
so
that
it
can
then
stick
it
in
its
TLS
server
config
to
send
out
in
that
TLS
extension,
so
I
think
Eric
or
squirrel
have
found
an
issue
here
to
propose
adding
a
some
way
in
Acme
to
tell
the
the
cert
subject
where
he
can
download
an
SCT.
So
it
goes
with
this
cert
proposal.
C
D
C
D
Then
again,
if
you're
already
getting
certificate,
you
are
already
in
that
position
that
you
are
diverging
what
you're
interested
in,
and
maybe
this
is
not
an
interesting
case
because
you
are
the
domain,
but
just
as
it's
not
extremely
complicated
to
get
that,
and
if
we
get
get
a
need
for
it
tomorrow,
the
SCT
is
only
half
of
the
of
the
thing.
So,
basically,
if
you
could,
it
might
be
interesting.
I'm
not
do.
C
D
C
I
would
actually
probably
still
be
inclined
to
publish
s
cts
like
this,
just
because
that's
what
people
are
using
today,
that's
what
chrome
is
checking
for
four
EV
certificates,
I
guess
they're
checking
for
DV,
but
not
requiring
I.
Think
I'd
be
inclined
to
to
publish
s
cts
in
this
way,
but
might
also
be
a
good
idea
to
publish
log
proofs.
E
G
C
Yeah,
that's
what
the
the
rel
equals
indicates.
What
the
thing
is,
it's
that
that
link
so
right
now
we
have
rel
equals
up
to
point
to
the
issuing
CA
certificate,
so
you
can
auto
configure
a
chain
in
your
server,
so
yeah
we're
we're
just
sort
of
accumulating
links
at
the
top
of
the
certificate
resource,
so
we
would
have
an
uplink
for
the
parent.
We'd
have
an
SCT
link
for
the
for
the
SCT.
We
might
have
a
login
herb
you
might
have
for
SCT
links.
C
F
This
is
something
that
can
be
added
later
relatively
easily
and
only
use
things
that
you
know
a
pretty
stable
in
this
regard.
I
think
that
we
want
to
get
this
done
as
quickly
as
possible
without
having
to
wait
for
someone
to
to
do
some
arbitrary
amount
of
work
somewhere
else
to
get
the
log
inclusion
purchase
right,
yeah.
C
C
Yeah
just
clarifying
basics
before
it
basics
before
URL
she's.
All
of
these
are
kind
of
editorial.
One
issue
we've
run
into
an
implementation
is
actually
one
that's
foreseen
by
the
jwk
specs.
So
we
have
this
key
authorization
construct
where
we
compute
the
thumb
prints
of
a
jwk
and
obviously
in
order
for
that
to
be
a
faithful
representation,
you
need
to
have
the
same
octet
string
representing
the
elements
of
the
key
and
in
a
lot
of
libraries.
C
There's
a
note
that
says:
if
there
is
a
zero
octet
there,
you
must
get
rid
of
it,
and
so,
if
we've
run
it,
we
actually
ran
into
this
bug
in
some
interoperability
testing
or
unless
encrypt,
where
someone
building
a
client
was
throwing
in
that
zero,
octet
and
so
I
think.
The
only
action
here
is
just
again
clarify
you
know,
point
hey,
JW
k
says:
get
rid
of
the
zero
octet.
C
It's
make
that
clarification
here
and
it's
sort
of
in
a
similar
vein,
because
this
computation
of
the
JW
k,
thumbprint
and
the
key
authorization
is
a
little
tricky.
We'll
add
an
example
of
how
that
computation
goes,
how
you
get
from
the
numerical
values
of
the
key
of
an
RSA
key
to
the
JW
k,
to
the
thumb
prints
of
the
key
authorization
object.
I
think
that's!
This
one
is
looking
more
editorial
than
I
imagined
it.
C
When
I
wrote
it
down
any
objections
to
adding
those
clarifications,
I
think
this
is
just
text
yeah
all
right
next,
that
was
easy
yeah.
That
was
just
summary.
Keep
going
this
one's
actually
kind
of
interesting,
so
you're.
The
issue
now
to
enable
clients
to
request
a
certificate
lifetime
I
believe
some
assurance
systems
today.
Have
this
property,
where
a
client
can
send
a
request
and
say,
give
me
a
three
month,
sir.
Give
me
a
one-year
sir
give
me
a
two-year
sir,
give
me
20
years
or
so
that
you
know
the
to
meet
various
demands.
C
You
might
have
a
cloud
hosting
thing
that
you
know
is
going
to
go
away
in
a
week,
so
you
only
want
a
week
low
insert
for,
it
seems
seems
like
a
nice
weight,
but
a
clients
opted
into
shorter
lifetimes
as
well,
if
that's
something
with
CA
desires,
so
the
question
arises
of
how
we
should
express
this
seems
pretty
clear,
should
go
in
the
new
certificate
message,
because
you're
requesting
a
new
certificate,
you
should
specify
its
lifetime
and
right
now.
All
we
have
in
the
new
certificate
message
is
a
certificate
signing
request.
C
The
CSR
there'd
been
some
discussion
of
whether
we
should
use
CSRs
everybody.
We
should
use
JSON
to
describe
the
contents.
The
certificate
and
I
think
where
we
ended
up
on
the
list
was
that
we
would
use
CSRs
for
things
you
can
put
in
a
csr
as
yes,
our
syntax
limits
you
to
certain
things
and
things
that
need
to
be
signed
by
the
key
pair.
So
to
avoid
things
like
triple
handshake,
unknown,
Keisha
attacks,
you
need
the
circ.
C
You
need
the
key
and
certificate
to
sign
over
the
names
that
are
going
to
be
in
the
certificate,
and
so
the
names
clearly
need
to
be
in
there.
They
need
to
be
signed
by
by
the
key
pair
that
you're
certifying.
So
the
question
is
and
then
JSON
we
can
use
for
other
stuff
that
don't
meet
those
those
first
two
criteria.
So
question
is:
how
should
we
expressed
this
out
in
next
slide?
Please?
Oh,
this
blinks
in
the
18
HTML
version.
We
don't
think
the
blink
here.
We
just
get
the
red
yay.
C
Yeah
so
I
pulled
up
the
definition
of
CSR.
It's
just
a
double
check
that
there
was
no
validity
period
here
and
in
fact,
RFC
2986
explicitly
says
it
does
not
include
a
validity
period
because
they're
optimizing
for
short
requests
to
accommodate
certificate
authorities
that
are
accepting
requests
on
paper
I'm,
so
glad
we
accommodate
that
use
case,
so
yeah
so
double
check.
We
cannot
put
the
validity
period
in
CSR,
so
next
slide
proposed
to
just
add
some
fields.
That's
the
standard
solution
here
you
know.
C
Obviously
you
could
imagine
doing
this
in
a
couple
in
the
standard
two
ways
of
representing
a
date
range
either
you
could
have
the
the
clients
say
how
many
what
duration
it
wants
out
of
the
certificate
or
it
could
specify
not
before
not
after
dates.
The
duration
seems
appealing
in
some
ways
because
the
ca
is
going
to
assign
the
nut
before
not
after
dates.
C
Anyway,
that's
probably
not
just
going
to
accept
what
the
client
hands
it,
but,
on
the
other
hand,
I
don't
think,
there's
a
standard
way
of
expressing
durations
in
a
string
or
in
JSON,
whereas
for
dates
we
have
the
standard,
39,
88
I.
Think
that's
the
whatever
the
ISO
number
dates
in
taxes.
Thank
you.
Iso
8601
not
artsy,
86,
that
when
we're
not
there
yet
any
thoughts
on
dates
versus
duration,
rich.
A
C
I
think
you
know
there's
always
this
idea,
that
a
new
certificate
request
is
a
request
for
the
by
the
client
for
some
certain
contents
in
a
certificate,
and
the
csr
can
already
include
requests
for
extensions,
and
things
like
that.
You
know
you
could
require
the
poison.
Accenture
can
see
tears.
Only
if
you
want
to
invalid
certificate
and
see
I
can
always
choose
not
to
fulfill
that
inputs.
You
know
most.
Obviously,
if
this
client
sends
the
CSR
that's
got,
some
names
is
not
authorized
for
agent
needs
to
say
no
I
will
not
serve
that
request.
C
The
ca,
also
in
principle,
has
the
option
of
changing
the
values
and
issuing
a
cert
that
is
more
to
its
liking,
so
yeah
I
think
the
expectation
would
be
that
if
the
ca
got
some
dates
it
didn't
like
it
would
either
clamp
the
dates
to
some
range
it
liked
or
reject
the
request.
I
think
that
would
be
up
to
the
CIA.
So.
A
That
that's
fine
I,
just
the
spec,
should
say
explicitly,
because
you
would
expect
if
you're
asking
for
sands
at
which
you're
not
entitled,
you
would
expect
that
to
be
rejected
and
also
those
temp,
those
other
things
tend
to
be
in
the
csr,
whereas
this
is
outside
of
the
CSR
and
it's
got
you
know
pick
the
behavior
just
make
sure
it's
documented.
That's
it
could.
C
E
Robin
Wilson
I
duration
seems
to
me
to
open
the
daughter
for
more
ambiguity.
I
mean
if
you
talking
about
months.
You
know
culturally
some
calendars
work
by
lunar
months
and
don't
and
some
months
or
different
lengths.
So
if
I
say
six
months,
do
I
mean
do
I
mean
starting
at
day
one
or
starting
now,
whereas
the
date
thing,
while
it
still
has
some
cultural
ambiguity,
has
less.
F
Yeah,
so
so
Martin
Thompson,
yeah
8601
defines
a
period
format.
Don't
use
that
it's
it
addresses
all
of
the
issues
that
Robin
raised,
but
it
is,
it
is
massively
complex.
The
only
reason
that
you
would
want
to
put
a
duration
in
here
is
if
a
human
would
generating
this
and
I
think
that,
to
all
intents
and
purposes,
that's
impossible
for
this
sort
of
protocol.
So
I
would.
E
C
A
Ya
know
I
mean
I
I'm.
Just
saying
this
is
what
I'm?
Sorry,
no
I
I
think
days
are
pretty
clear
as
durations
I,
don't
like
durations
I'm,
just
trying
to
be
complete,
but
yeah
I
think
they
are
ambiguous,
I,
don't
like
them
either
confusing
for
the
reader.
You
know
I
mean
we've
all
seen
on
facebook
and
twitter.
You
know
posted
3
hours
ago,
like
what
does
that
mean
right,
say
so,
and
you
run
the
risk
of
the
same
thing
here,
but
it
is
technically
feasible.
E
C
C
G
Jones
be
I
also
agree
that
having
an
explicit
date
is
probably
better,
though,
if
you
are
going
to
do,
duration
hours
might
be
more
precise
for
for
short
certificates.
One
other
point
on
the
on
the
explicit
dates
in
practice:
we're
seeing
a
non-trivial
number
of
clients
with
extreme
dates
Q,
so
we
should
probably
be
clear
about
what
happens
when
the
ca
rejects.
In
that
case,
perhaps
a
different
error
message.
B
Ted
Hardy
I
certainly
agree.
A
different
error
message
would
be
a
good
thing.
I
I
think
that
what
Martin
said
earlier
about
don't
use
this
because
they
handle
all
of
these
issues,
and
it's
too
complicated
is
perfect.
Illustration
of
why
we
don't
want
duration
right
anything
we
do
that
handles.
This
correctly
is
going
to
be
just
as
complicated,
and
you
know,
given
that
I
can
construct
durations
in
which
days
are
ambiguous,
I
can
construct
hours
that
are
they're
ambiguous
during
during
time
changes
yeah
just
don't
want
to
go.
There.
H
Cement-Like
Dinkins
on
the
site,
so
this
is
kind
of
a
caveat.
I
guess
that's
an
so
how
long
the
subscriber
wants
is
certificate
to
last
is
not
actually
what
these
are
about.
This
is
an
assertion
by
the
ca
that
you
that
the
reporting
party
should
not
trust
the
certificate
before
and
after
these
dates.
Now,
if
you
want
to
change
what
they
mean
that
you
know
you
could
do
that,
but
you
I
would
suggest,
putting
a
lot
text
around
it.
H
Right
but
if
a
CA
says
I
issue,
DB,
certs
and
then
cab
firm
has,
which
defines
TV
certs
has
a
certificate
policy,
as
sdb
shirts
are
good,
for
whatever
I
mean
so
shortening
it
would
be.
Certainly
yet
Kevin
only
has
an
excellent,
so
all
right
song,
so
you
already
addressed
it.
You
said
the
ca
you
know
would
check
and
make
sure
it
was.
Okay,
you
know
by
the
CIA
may
not
an
arbitrary
CA
may
not
be
thinking
I
need
to
check
the
state.
You
know
and
may
not
know
what
to
do
with
them.
F
A
F
I
I
would
prefer
that
if,
if
the
the
CIA
intended
to
extend
the
duration
or
had
a
minimum
duration
on
the
on
the
certificates,
it
was
providing
and
the
client
asks
for
30
seconds,
which
might
be
an
unreasonable
thing
to
ask
for
that.
We
have
an
error
code
for
it
and
I.
Think
rich
is
right
to
ask
that
yeah
yeah.
F
E
C
A
C
Okay,
great
all
right,
so
let
it
be
to
let
it
be
known
we
will
use
not
before
and
not
after,
and
not
this
wacky
duration
construct
or
any
other
great
next
issue,
simplify
TNL,
SS
and
I
challenge
so
yeah,
as
I
said
before,
to
address
the
default
be
hosting
wii
version.
01
added
this
complicated
dance
where
you
generate
a
whole
hat
sequence
of
hashes
from
the
initial
value
and
you're
supposed
to
be
able
to
respond
for
any
of
them
and
server
tries
some
random
subset
of
its
choice.
A
C
This
request
is
signed
with
the
clients,
account
key
okay,
yeah
yeah
yeah,
that
that's
the
overall
authorization
every
request
the
client
sends
to
the
server
assigned,
with
its
account
key.
That's
how
you,
how
we
maintain
continuity
of
identification
of
client,
yeah,
so
yeah.
The
proposal
here
is
that
Jacob
Hoffman
Andrews
from
the
FF
propose
that
we
just
do
this.
We
revert
out
the
fix
the
tss
and
I
his
assertion.
Is
that
there's
a
lot
of
work
to
do
this?
C
It
makes
the
challenge
really
complicated
to
do
both
for
the
client
and
the
server
and
the
in
order
to
exploit
this
vulnerability
requires
kind
of
a
corner
case.
Looking
situation,
you
have
to
have
this
default,
a
hosting
provider
that
has
this
default
V
host
issue,
and
you
have
to
have
the
property
that
the
attacker
can
provide
a
certificate
for
that
and
can
specify
the
certificate
that
is
going
to
be
provided
for
that
default
be
host.
B
B
Generate
one
of
these
things
in
order
to
create
certs
for
any
of
the
hosts
that
they're
hosting
right,
without
necessarily
creating
anything
that
would
be
logged
on
the
host
their
hosting
itself.
So
you
could
say:
hey
it's
the
hosting
provider
they.
They
could
always
attack
you
right
and
they
could
attack
you
by
by
creating
the
other
challenges
in
emitting
this
right,
but
those
at
least
are
somewhat
noticeable
to
the
hosted
parties
because
they
they
create
laga
Bowl
files.
C
Looks
like
you,
I
rephrase
that
a
little
differently,
I
think
you
know
the
hosting
provider-
can
always
get
a
certificate.
If
you
posted
example,
calm
right,
they
can
pretty
much
always
get
a
certificate
for
that
without
any
trace.
I'm
imagining
like
the
Heroku
hosting
platform,
has
this
complicated
routing
system
before
it
ever
gets
to
the
the
customer
right,
so
they
could
just
hook
that
routing
system
and
you
the
customer,
would
never
see
anything.
C
So
unless
I
find
the
the
point
about
observability,
less
compelling
I
think
the
difference
here
between
the
standard,
your
hosting
provider
can
screw
your
argument-
and
this
is
that
here
your
hosting
provider
is
screwing
you
by
letting
some
other
guy
get
certificates,
not
the
hosting
provider.
So
it's
an
invert
inadvertent
action
by
the
hosting
provider,
not
a
malicious
one.
So.
C
We
could
it's
not
totally
clear
to
me
that
you
can
do
a
lot
better
than
this,
because
in
order
to
separate
is
default
via
the
case.
So
you
need
to
separate
somehow
the
case
where
I
actually
control
the
host
virtual
hosts
on
this
provider
and
the
default
be
host
case.
The
current
solution
relies
on
requiring
the
some
random.
C
Yeah
they're
in
the
current
making
it
with
the
current
mechanism.
In
order
for
the
attack
to
work,
the
attacker
has
to
provide
a
sequence
of
certificates
in
pretty
rapid
succession
and
guess
the
right
order
that
the
sea
is
going
to
ask
for
I'm.
Assuming
that
you
know,
there's
only
one
default
be
hit.
B
And
the
concern
with
continuing
to
use
that
is
that
the
number
of
iterations
is
sort
of
problematic
for
the
challenge
and
that
you,
you,
as
the
appropriate
responder,
also
have
to
join
right,
those
in
appropriate
succession
and
it's
somewhat
complicated
to
both
get
that
right
and
check.
If
I
understand
the
right
shoe
correctly,
and
it
does
seem
to
me
that
it
it
does
actually
provide
some
significant
protection
in
this
case
and
dropping
it
with
no
replacement.
B
C
B
C
Yeah
now
that
I
think
about
it
this,
if
you
would
want
the
ca
to
do
the
check
to
see
if
you
know,
send
just
a
completely
random
V
host
value
and
as
a
probe
to
the
hosting
provider
to
see
if
something
responds
to
see
if
this
particular
hosting
provider
has
this
issue
before
accepting
a
TLS
challenge.
Alright,.
B
B
C
I
think
I'm
now
that
you
mentioned
I,
think
I'm
more
enthusiastic
about
specifying
away
an
action
to
have
the
ca
take
to
check
whether
this
threat
scenario
is
the
case,
because
that
you
can't
have
the
client
check,
because
the
risk
attaches
ones
right
before
yeah.
So
I
think
what
I
would
like
to
try
here
is
to
try
to
specify
what
the
ca
should
do
to
check
whether
this
is
the
case
to
check
whether
the
default
be
host
and
then
take
the
mechanism
out
via
not
have
the
the
multiple
mechanism.
C
A
C
I'm,
just
pondering
where
I
put
the
text,
probably
in
challenge
section
but
yeah,
we
can
figure
that
out.
It's
just
text,
alright,
yeah
anyone
have
strong
objections
to
that
course
of
action.
Having
see
a
check
for
whether
there's
a
default
view
host
in
place
before
I
will
do
a
TLS
base
validation,
seeing
a
couple
nods,
okay,
I'll
draw
some
text
for
that.
All
right,
good
I
think
we're
getting
close
to
the
end
here.
Moving
on
time,
Mike,
it's
underly,
yeah,
okay,
I
save
this.
For
last,
this
is
the
last
one.
C
If
we
were
letting
the
caldav
administrator
use
cal
down
to
the
show
that
he
owns
the
domain,
then
the
guy
with
the
CalDAV
server
can
prove
that
he
owns
the
domain,
that
you
might
not
want
to
authorize
that
in
any
case,
and
that's
saying
nothing
of
the
the
risk
of
high
numbered
ports
and
arbitrary
users
on
a
machine
spinning
up
HTTP
or
TLS
services.
Anyone
here
who
really
wants
this
or
has
actually
they've,
got
a
couple
of
proposals
and
they
actually
on
the
next
slide.
I've
got
some
guy
yeah.
C
What's
so
yeah
that
that's
interesting,
I
hadn't
thought
about
that
use
case,
so
I
think
that
actually
has
some
broader
implications
if
you
want
to
use
those
names.
So
right
now,
Acme
talks
about
identifiers
and
it
defines
one
type
of
identifier
which
is
a
domain
name
and
so
I
think.
If
we
were
going
to
support
a
validation
for
those
SRV
names,
you
would
want
to
have
a
different
identifiers
type
and
different
challenges
to
go
along
with
it.
G
Know
that
my
thought
is
that
this
would
this
would
be
useful
for
ports
other
than
443
for
non
dns
name.
Subject:
all
name
/
certificate,
the
head
in
non
dns
name,
subject
all
day
and
yet
and
yes,
I
I,
agree
that
that
would
not
produce
a
certificate
that
would
be
for
someone
who
wanted
to
do
a
DNS
name,
validation
on
the
certificate
yeah,
but
I
think
would
be
useful
and
other
services.
G
You
know
we
have
a
definition
for
underscore
map
s
dot,
T
underscore
TCP
services
should
be
able
to
validate
that
clients
should
be
able
to
validate
that.
So
this
is
one
thing
one
one
answer
you
could
give
to
people
who
come
to
you
with
this.
If
we
have
an
SRV
ID
specification
to
say
sure
make
sure
that
your
stuff
works
with
SRB
names,
yeah.
C
I
think
what
I
was
trying
to
say
is
like
if
you're
gonna
make
an
SRV
ID
specification,
which
I
think
the
way
this
the
extensibility
points
are
cut
out.
It
would
be
natural
just
to
do
that
in
a
separate
doc.
I
think
what
we
would
do
if
we
did,
that
is
say,
here's
what
an
SRV
ID
looks
like,
and
here
are
the
challenges
you
do,
and
it
may
be
that
you
define
the
challenges
by
reference.
You
say:
do
HTTP
on
the
port
specified
in
the
SRV
or
do
TLS
on
report
specified
it.
C
G
Is
DK
GI
I
actually
think
that
that
is
super
sketchy,
I,
think
it's
sketchy
that
we've
been
using
domain
names
this
whole
time
because
service,
a
on
host
X
is
not
the
same
as
service
beyond
those
decks.
The
fact
that
we
are
even
issuing
certs
that
don't
scope
to
the
to
the
service
that
scope
to
the
host,
I
think,
is
sketchy.
So
I
don't.
I
would
want
to
extend
that
sketchiness
fair
enough.
C
F
C
F
C
B
B
Allocations
of
certificates
using
the
TLS
challenge,
so
we
would
basically
say
hey
if
you
have
a
service
like
I'm,
a
pass
or
DNS
over
TLS,
which
is
capable
of
using
the
TLS
challenge,
but
you
may
use
acne
in
the
following
way
right.
We
would
not
support
creating
a
DNS
challenge,
based
mechanism
for
other
ports,
for
the
sketchiness
reasons
that
he
laid
out
and
that
the
answer
to
the
to
those
people
would
be
draft
text
that
says
hey.
B
F
F
B
F
B
E
Hi
sorry
I'm
behind
on
this
discussion,
but
I
don't
have
a
different
thought
on
the
way
forward,
but
we
should
carefully
in
this
process,
think
about
the
implications
for
RC
6125
and,
if
you're,
by
happenstance,
adding
any
new
requirements
that
ought
to
go
into
that
spec
or
that
aren't
already
covered
by
that
spec
got
to
figure
out.
How
wanted
would
address
that
is
that
buried
in
acne
documents
or
is
there?
Is
this
patek
added
to
6125,
updated.
C
Yeah,
I
think,
for
the
most
part
we're
just
talking
about
how
you
validate
stuff
that
would
meet
the
requirements
of
6125
when
once
it
was
in
a
certificate.
But
if
there
were
a
revision
process
open,
it
might
not
be
a
terrible
idea
to
to
add
some
comments
and
there
about
how
one
goes
about
validating
the
name.
Oh
yeah,
yeah
I
know
yeah.
The
do
you
know
if
it
happens
to
you
haven't
know
if
it
talks
about
how
names
are
validated
and
what
the
considerations
are
around
that
yeah.
It.
C
C
The
concern
here
is
precedent
to
that,
in
the
sense
that
we're
talking
about
how
a
CA
before
issues
a
certificate
checks
that
it
should
issue
a
certificate
with
a
given
name:
okay
anyway,
which
you
can
see
how
they
not
they
sort
of
notch
together,
yeah
yeah,
and
so,
if
there's
not
discussion
of
that
prior
step
in
6125,
it
might
be
useful
to
add
some
notes
on
that.
If
there's
like.
D
E
Max
pretty
Francisco,
this
seems
like
a
very
small
example
of
a
broader
set
of
cases
that
I'm
turn
to
the
sketches
own
of
connecting
back
into
devices
that
are
not
in
the
port,
80
or
443
space,
and
there
is
a
whole
bunch
of
other
examples
of
that
use
case,
and
so
we
might
want
to
look
at
it
more
broadly.
Yeah.
C
So
this
is
not
a
new
you're,
not
taking
any
action
for
generic
ports
with
HTTP
or
TLS
is
not
to
say
that
we
can
never
do
other
ports
than
80
or
443.
It's
not
taking
action
here
and
basically
imply
that
if
we
want
to
extend
validation,
two
things
that
don't
do
those
ports,
we
would
have
define
a
new
challenge
to
do
whatever
the
new
thing
is
right,
so
we've
got
an
extensible
challenge
space,
so
we
can
do
that.
C
C
C
Alright,
so
I
think
that's
the
last
issue.
I
had
some.
If
people
wanted
it
is
I
had
some
options
for
how
we
could
but
we're
not.
So
this
is
not
needed
and
I
think
that's
the
last
issue.
We
had
yeah
actually
I
thought
of
one
more
as
we
were
discussing
the
account
recovery
earlier
and
what
you
do
if
you've
lost
your
account.
Key
we've
got
two
mechanisms
in
there
right
now,
one
that
uses
contact
information,
so
the
CIA
would
send
you
an
email
to
your
registered
contact
address
and
you
know
do
that.
C
You
do
that.
The
rest
of
it
is
undecided.
The
idea
is,
you
would
do
this
standard
sort
of
click
and
you
can
click
the
link
to
verify
that
you've
gotten
this
email
and
prove
that
this
is
your
account.
So
that's
the
first
minute
we've
got
contact
based
recovery
and
then
we've
got
another
I
forget
what
we
called
it,
but
it
uses
a
bunch
of
fancy
crypto
to
establish
a
secret
key
that
you
could.
C
Do
people
think
that
that's
important
to
keep
in
the
document
I
I'm
sort
of
inclined
to
get
rid
of
it,
because
it
adds
a
fair
bit
of
complexity
and
it
requires
some
non-trivial
crypto
on
the
client
server
to
do
diffie-hellman
moderated
over
HTTP
I,
don't
know.
Is
there
any
objection
in
the
rooms
that
ripping
out
the
the
token
based
recovery,
crypto
based
recovery,
I'm,
not
aware
of
any
implementation
of
it?
Even
in
let's
encrypt.
C
B
Okay,
then,
it's
time
for
issues
for
the
working
group
I'd,
like
you
all,
to
open
your
calendar
application,
or
at
least
your
mental
model,
of
how
far
it
away
our
Buenos
audits
meeting.
Is
it's
a
long
time
from
now
five
months,
so
the
interaction
on
the
mailing
list
has
actually
been
pretty
sparse
and
we'd
really
like
to
make
sure
that
people
understand
that
we
do
not
wish
to
turn
up
in
Buenos
Aires
with
another
issues
list
and
a
02
and
be
silent
between
then,
and
now
we
really
can't
afford
that
amount
of
time.
B
So
as
soon
as
these
issues
get
merged
into
a
new
draft,
we
would
like
to
have
some
real
review
of
the
draft,
either
in
standard
ITF
fashion,
on
fully
on
the
mailing
list
or
in
our
split
brain
mechanism
of
issues
in
github
brought
to
the
mailing
list.
But
we
really
really
really
cannot
wait
between
now
and
Buenos
Aires
to
have
this
progress.
We
want
to
be
moving
much
much
faster
than
that.
B
The
second
point
is
you:
you
heard
us
say
it
before
that
do
not
implement
is
out
of
the
draft
implement
and
we
really
would
like
people
who
are
trying
to
implement
this
spec
as
part
of
the
review
community
at
this
point.
So
if
you
are
implementing
a
client
if
you're
implementing
any
other
part
of
the
system,
please
share
your
experiences
early
and
often
anything
you
found
ambiguous
anything
you
found
difficult
to
follow.
C
Richard
barnes
one
thing
I
would
add
to
the
in
addition
to
people
implementing
things
folks
who
have
experience
with
existing
issuance
api's,
some
things
that
CZ
cas
are
using
nowadays,
I
would
love
to
know
how
acme
maps
to
your
issuance
api
of
preference
and
if
it's
not
clean,
what
we
need
to
do
to
align
it
because
I
my
it
is.
My
earnest
hope
that
we
can
get
acne
to
a
point
where
we
can
get
most
of
the
pki
moved
over
to
it.