►
From YouTube: IETF98-ACME-20170330-1300
Description
ACME meeting session at IETF98
2017/03/30 1300
A
Welcome
to
Chicago
for
those
of
you
who
are
unfamiliar
with
Chicago.
This
is
Wrigley
Field
home
of
the
Chicago
Cubs.
We
were
going
to
include
the
other
baseball
teams
park
as
well
in
the
interest
of
fair
play,
but
it
turns
out
one.
They
were
not
involved
in
the
ferris
bueller's
day
off
movie
and
two.
They
foolishly
renamed
themselves
a
guaranteed
rate
field,
no
I'm
not
kidding,
and
we
just
didn't
want
to
put
that
on
a
slide.
We
can't
really
explain
why,
but
it
made
us
uncomfortable.
A
A
Okay,
so
here's
our
agenda
for
today
the
10
minutes
of
an
administrator
is
mostly
me
blathering
up
here
then
we'll
have
a
discussion
of
the
changes
in
the
acne
internet-draft
and
going
to
the
rest
of
things.
As
you
see
here,
we
do
have
a
thanks
to
give
out
already
to
dkg,
for
acting
as
our
jabber
relay
and
to
Thomas
is
acting
as
our
scribe,
so
you
won't
have
to
sit
here
in
stunned
silence,
while
I
stare
out
looking
for
them.
Please
thank
them
for
their
work.
B
A
B
Acne
acne,
so
we've
been
at
this
for
two
years
in
two
years
since
bones
County,
something
like
that
so
since
the
last
time
so
I'm
hoping
next
slide,
I
think
a
theme
here
is:
is
that
there's
nothing
too
big
because
we've
been
through
last
call
now:
we've
got
a
bunch
of
good
issues
and
hopefully
we're
getting
about
done
and
I
can
send
this
to
the
iesg.
So
the
reason
we
didn't
want
to
have
nothing
big
is
that
big
things
require
realized,
calls,
and
so
we'd
like
to
avoid
that
and
keep
the
document
movie
next
slide.
B
Please
so
quick
review,
what
we've
done
since
the
last
IETF
meeting
next
slide
the
usual
graph
of
commits
as
usual.
The
ID
deadline
is
very
clearly
indicated
by
the
commit
graph
over
time,
as
usually
we've
kept
up
our
pace
of
having
a
bunch
of
different
contributors
and
thanks
to
all
those
people
who
sent
for
requests
or
reviewed,
pull,
requests
help
keep
this
pace
pretty
lively
through
the
winter
next
slide.
Please
so
just
a
quick
review
here,
there's
a
bunch
of
editorial
PRS
that
improve
grammar
and
commas
and
terminology,
and
things
like
that
slide.
B
Yes,
one
of
those
major
technical
changes
was
to
name
to
change
the
names
that
we
apply
to
things
changing
registrations
to
accounts
and
was
a
new
certificates,
a
new
to
new
order.
There
were
a
few
PRS
related
to
just
kind
of
cleaning
up
terminology
from
that
and
making
sure
that
we
were
consistent
in
saying
everything
the
same
way
throughout
the
document.
Yes,
finally,
the
a
bunch
of
what
we
got
in
last
call
was
comments
about
the
kind
of
general
data
model
of
the
protocol
has
and
had
kind
of
accreted.
B
Over
the
couple
of
years
we've
been
working
on
this,
and
some
of
the
reviewers
noted
that
there
a
bunt
there
were
several
things
in
there
that
we
weren't
using
anymore
and
could
safely
take
out
so,
for
example,
on
the
account
object,
had
a
reflected
the
public
key
associated
to
the
account,
so
that
you
know,
if
you
requested
your
account
object
from
the
server.
It
would
say.
Here's
the
contact,
information,
I
have
and
here's
the
public
key
I
have
the
observation.
B
Jacob
made
that
convinced
me,
this
was
not
useful,
reflecting
the
key
wasn't
useful
is
that
the
client
needs
to
have
the
key
in
the
first
place,
to
make
the
request,
because
it
requests
for
count,
objects
or
access
controlled,
and
so
there
really
is
zero
utility
and
reflecting
that
back,
because
the
fact
that
the
server
is
sending
this
account
objects.
The
client
is
already
proof
that
the
client
has
the
key.
That
goes
with
the
account.
So
we
took
that
out
and
similar
arguments
for
these
other
things.
B
So
just
lots
of
cleanup
going
on
that's
why
we
do
working
a
lot
of
grief.
Last
call's
is
to
discover
what
we've
done
wrong
so
far.
Next,
similarly,
a
bunch
of
small
things
like
changing
content,
location
to
location,
revising
how
Pina
native
we
were
about
HP,
KP
and
redirects,
and
tweaking
Xin
HTTP
response
codes,
so
things
that
if
people
were
being
super
precise
about
things
like
response
codes
might
require
some
code
changes.
B
But
you
know
just
changing
from
like
2012
204,
so
not
major
stuff,
but
still
you
know
if
you've
got
an
implementation
going,
you
might
have
to
tweak
to
address
these
things
next,
all
right!
That's
that's
the
entire
history,
the
summary
of
the
history
to
hear
any
questions
comments
on
what
we've
done
in
the
last
few
months.
B
Yes,
I,
don't
think,
there's
anything
major.
There
are
no
major.
We
are
connecting
they
mainly
just
streamlining
and
tweaking
things
to
be
a
little
more
consistent,
nicer
all
right.
So,
let's,
let's
go
skim
through
the
open
issues.
So
for
each
of
these
open
pr's,
open
issues
in
github
and
mailing
list
issues,
I've
got
kind
of
started
those
three
bins
kind
of
triage,
those
into
things
that
look
like
things
that
Jacob
and
I
could
just
triage,
intimate,
decide
for
ourselves
and
things
I,
thought
merits
and
discussion
here.
For
these
you
know
those
are
the
PRS.
B
B
We've
done
here
well
and
pointed
out
that
this
is
kind
of
silly
on
causes
breakage
for
the
non-trivial
number
of
clients
that
are
out
there
already,
and
it's
kind
of
handy
actually
to
have
these
version
numbers
around
on
challenges,
because
we
might
discover
some
future
date
that
were
unhappy
with
precisely
how
the
HTTP
challenge
works.
We
might
want
to
upgrade
it
to
have
another
version
of
the
HTTP
challenge.
Does
anyone
have
a
preferred
color
for
this
bike
shed.
B
B
Okay,
that's
correct
yeah.
It
says
the
proposal
is
to
keep
what
we
have
now
we
might.
We
might
have
to
change
the
semantics,
because
right
now
it
says
that
the
version
number
is
the
draft
version
in
which
the
change
was
introduced.
So
we
might
just
have
to
register
things
with
with
the
version
attached,
but
yeah.
D
E
B
All
right
the
shed
and
shelby
blue,
then
whatever
color
the
version
numbers
are
okay,
yeah,
welcome
to
know
the
true.
Yes,
the
show
shelby
versions
shall
we
say
I'm
to
let
the
minutes
reflects
so
resolved
next
slide,
please
so
that
was
PRS.
There's
some
issues
in
github
as
well,
most
of
some
of
which
have
been
already
been
addressed
by
PRS
that
have
already
landed
so
I
just
struck
those
through
for
now
and
a
couple
of
which
are
just
minor
text
tricks.
B
Well,
so
we
built
in
this
nice
deactivation
of
authorization
so
that
you
could
kind
of
deal
with
this
situation
if
you
had
the
URL
for
the
authorization
to
say
deactivate
this
authorization,
but
these
clients,
because
they
were
still
trying
to
get
things
working,
weren't,
keeping
those
authorization,
your
l's
grounds,
they
couldn't
use
the
deactivation
thing.
So
josh
from
watson
cook
called
me
and
said:
hey
we
have
this
issue.
Question
is:
should
we
address
this
bottom
bolts
are
kind
of
my
opinion
here.
B
I
think
it's
probably
not
worth
addressing
this
super
specifically,
but
it
seemed
like
a
one
way.
You
could
address
this
while
having
a
fairly
high
degree
of
generality
is
reading
this
authorizations
field
to
the
account
objects,
so
that
you
know
an
account
holder
could
enumerate
all
the
authorizations
that
have
been
attached
to
this
account
over
time.
That
seems
like
kind
of
an
okay
idea
to
me
just
in
terms
of
exposing
server
state,
and
it
would
have
the
Hindi
effect
of
addressing
this
I'm
dickham.
Thank
you.
Oh.
G
F
By
Oliver
I'm
living
with
fergie
cycle
and
then
authorizations,
in
other
words-
and
this
is
actually
a
comp-
it
part
of
the
latest
version
of
the
stack.
So
if
you
ask
for
a
new
order
and
there's
already
exists,
a
pending
authorization
or
one
of
those
names,
the
server
is
free
to
and
its
continued
to
you.
We
use
that
same
authorization.
So
I
think
this
will
just
become
a
non
issue
with
the
latest
stack
and
they
don't
think
any
filters.
Part.
B
A
A
B
A
D
B
B
This
is
kind
of
this
is
kind
of
the
entirety
of
the
recommendations
we
have
for
client
behavior
in
terms
of
how
you
go
through
the
sequence
of
requests,
getting
a
certificate,
and
the
recommendation
here
is
that
you
know
once
you've
gone
through
the
whole
submission
in
order,
and
you
tried
to
respond
to
the
challenges
you
need
to
see
when
it
is
that
the
server
thinks
it
has
validated
your
challenges
or
it's
made
of
its
mind.
This
recommendation
is
that
you
pull
the
authorization
URL
of
which
there
might
be
several
for
a
given
certificate.
B
The
suggestion
here
is
just
a
change:
that's
pulling
the
order,
URL,
which
is
actually
more
efficient,
because
that
gives
you
the
certificate.
Url
just
wanted
to
put
this
out
there
on
the
floor
because
it
was
a
is
kind
of
a
technical
change
that
seemed
sensible
to
folks
not
seeing
any
dramatic
reactions.
Oh
Jacob
back
to
you.
F
Alright,
so
I
don't
actually
remember
recommending
this,
it
might
be
somebody
else,
I
recommended
this.
One
possible
issue
is
so
if
one
of
the
authorizations
they'll
also
connected
to
the
point
Google
raised
about
retrying
individual
challenges,
if
we
allow
that
the
order
won't
transition
when
challenges
fail,
so
you
would
pull
the
in
the
case
where
the
challenges
fail.
You
point
upon
the
order
forever,
so
I
think
there's
some
interaction
there
and
then
favor
continued
recommend
get
off
see
for
now,
but
I
could
totally
be
convincing.
F
B
So
maybe,
let's
table
this
until
we
get
to
that
which
is
a
little
bit
later,
this
the
end,
not
a
huge
change.
It's
not
really
normative
anyway,
so
you
can
always
tweak
all
right
next
issue
here
resource
relations.
So
someone
pointed
out
I
forget
who
exactly
it
was
that
we
have
this
link
relation
between
an
authorization
and
the
order
that
created
it,
but
authorizations
can
be
used
across
multiple
orders.
B
So
you
know
I
assume
it
in
order,
for
example,
calm
and
I
get
authorization,
for
example,
calm
than
I
issue,
200
more
certificates,
using
that
authorization
which
link
what
do
I
set.
This
up
link
relationship
to
when
I
get
that
authorization
resource
on
seems
like
there's
kind
of
three
obvious
answers.
B
1
you
set
it's
the
order
that
created
the
authorization
you
provision,
200,
link
relations
to
each
order
that
use
this
authorization
or
you
could
just
delete
this
entirely
and
rely
on
clients
tracking,
which
orders
go,
which,
with
author
authorizations
I
think
my
preference
would
probably
be
to
just
drop
it
because
I
don't
get
the
sense
that
there's
a
lot
of
usage
of
these
linked
relations
going
on.
But
if
people
thought
this
was
valuable
in
terms
of
tying
all
these
resources
together,
I
think
there
could
be
some
argument
for
keeping
them
does.
I
I
B
B
There
may
be
some
where
I
think
the
chairs
have
a
couple
on
the
agenda
that
are
bigger
issues,
so
yeah,
let's
go
through
these
real
quick,
looks
like
these
defining
revocation
were
clearly
so
Erika
port.
No
I
suggested
that
this
was
this.
Our
description
of
revocation
is
kind
of
ambiguous
because
it's
got
a
leash
should
scattered
throughout
it
about
what
the
client
has
to
do
to
prove
that
he's
authorized
to
revoke
a
certificate
now
our
default.
B
You
know
we
are
fairly
conservative
in
the
specification
about
what
we
require
a
server
to
do,
because
servers
are
bound
by
things
like
the
baseline
requirements
and
route
programs
as
to
what
exactly
they
can
do
can't
do.
However,
in
this
case,
you
know,
you
are
within
the
scope
of
the
revocation
mechanism
that
Acme
defines,
and
so
it
seemed
to
me,
like
you,
could
perhaps
safely
within
that
box,
say
that
change
these
shoulds
to
musts
and
say
the
revocation
method
that
Acme
defines
within
that
scope.
B
The
server
has
to
consider
one
of
these
any
of
these
three
keys
to
be
valid.
Erika
suggestion
was
that
we
require
at
least
one
of
these
three,
which
is
a
little
bit
more
limited
in
terms
of
burden
of
places
on
the
server,
but
it
seems
all
so
confusing
from
the
client
point
of
view,
because
you
don't
know
which
of
those
three
a
given
server
is
going
to
support
so
I'm
kind
of
looking
at
the
ca
guys
in
the
room.
You
have
to
be
next
to
the
mic.
B
If
we
were
to
change
these
two
musts,
and
so
that
would
require
that
if
someone
shows
up
who
had
it
was
the
issue
of
the
certificate
that
seems
kind
of
obvious,
but
someone
who
has
proven
control
the
same
set
of
domains
in
the
certificate
or
the
private
key
with
this,
it
goes
with
the
certificate.
Like
would
you
be
willing
to
accept
revocation
from
any
of
those
three
entities?
I,
don't
see
any
issue
with
these.
B
So,
okay,
so
the
upshot
here
is,
you
know,
will
change
these
two
musts
and
then
it's
kind
of
a
take-it-or-leave-it
forciers
so
like
either.
You
do
all
these
things
and
you
get
to
use
acne,
revocation
or
you
have
to
invent
your
own
revocation
thing
all
right.
So
people
are
okay
with
that,
we'll
just
change.
Those
two
work,
two
sheds
to
musts
get
resolution
thanks.
So
there's
prison
in
here
that
service
should
validate
should
make
sure
that
they
kind
of
like
the
you
are
eyes
that
are
providing
these
contact
fields
and
counselor
registered.
B
There
was
some
concern
about
interoperability
impact
because
there's
not
any
way
for
the
server
to
advertise.
What
urls
might
be
acceptable
to
it?
I
think
general
practice
among
the
sea
is
that
have
deployed
acting
so
far.
Is
it
male
2
and
tell
our
kind
of
the
obvious
ones
to
accept,
but
you
might
have
some
other
scheme
that
some
cas
might
accept.
Some
might
not,
and
if
a
client
wants
to
use
that
it
doesn't
know
whether
given
CA
is
going
to
accept
that
and
accept
it
or
not.
B
D
Daniel
McCartney
again
so
from
my
perspective,
I
think.
The
the
main
criticism
here
was
that
it
was
difficult
to
determine
whether
the
contact
was
invalid
or
unsupported
and
I.
Think
we
added
an
arrow
type
and
supported.
That
seems
better
than
me.
The
metadata
aspect
of
it
I
mean
right
now
the
spec
says
that
the
metadata
element
in
the
directory
is
May
and
so
I.
Think.
If
we're
really
looking
to
clear
out
all
the
confusion,
we
would
have
to
change
that
normative
must
and
I
think.
D
This
is
probably
not
the
only
place
where
an
acne
client,
it's
meant
to
be
generalized
across
multiple
acne
ca's,
we'll
run
into
you.
One
feature
another
that
isn't
supported
and
so
I
kind
of
land
on
the
side
of
having
a
simpler
server
and
a
smarter
client.
That's
able
to
handle
those
errors.
I
think
the
other
aspect
here
for
this
particular
one
is
that
this
is
likely
to
only
come
out
during
account
registration
and
contact,
update
and
so
I
think
the
UX
downside.
A
Ted
Hardy,
so
there's
a
general
point
here
that
you're
going
to
have
multiple
different
permitted,
your
I
schemes,
you
run
the
risk
of
negotiation.
Failure
we're
the
ones
that
are
supported
by
the
client
of
one
supported
by
the
server
do
not
have
an
intersection
point.
Typically,
we
solved
that
by
declaring
a
mandatory
to
implement
that
everybody
knows
would
be
supported.
Yes
and
I.
Think
a
single
one
of
male
2
is
probably
sufficient.
If
people
want
to
have
to
mandatory
and
implement
I
would
have
agreed.
It.
A
H
A
B
Then
the
other
thing
you
could
also
do
is
have
a
little
bit
of
a
negotiation
mechanism
where,
if
you
guess
wrong
and
provide
something
that
the
server
doesn't
like
and
it
provides
you
back
an
unsupported
scheme
mechanism,
you
should
that
you
could
set
the
server
could
say.
Here's
a
list
of
scheme
that
you
like
in
that.
B
So
I'm
inclined
just
to
scope
down
and
declare
the
MTI
all
right,
I'm,
seeing
some
God
so
we'll
go
with
that
all
right
next
yeah
this
is
this-
is
the
the
challenging
one
so
Hugo
Landau
observed
on
the
list
that
you
know
you
can
end
up
in
these
situations
where
I
submit
an
order
for
certificate,
has
ten
names
in
it?
I
try
to
go
fulfill
the
challenges
for
those
names
and
nine
of
them
work,
but
in
one
case
the
DNS
didn't
propagate
quite
fast
enough,
and
so
that
challenge
failed
that
authorization
I
got
invalidated.
B
B
Although
that's
not
guaranteed
it's
up
some
ca's
policy,
and
so
the
question
here
is:
should
we
do
something
that
makes
that
addresses
this
case
a
little
more
elegantly
on
Hugo
posited
three
potential
mechanisms,
one
allowing
a
mechanism
for
retrying
a
challenge
so
that,
if
a
challenge,
if
CA
tries
to
validate
a
challenge-
and
it
fails-
the
client
could
maybe
kick
the
server
and
say
please
retry
this
challenge.
We
try
to
validate
again.
Another
option
he
proposed
was
to
allow
challenges
to
be
regenerated,
so
an
authorization
comes
with
a
list
of
challenges.
B
If
one
of
those
gets
invalidated,
maybe
we
want
to
give
the
client
way
to
say.
Please
give
me
a
new
list
of
challenges
just
prove
that
I
on
this
the
same
domain,
you
could
also
do
similar
dance
at
the
authorization
level,
letting
getting
a
new
authorization
for
within
a
given
order.
One
thing
occurs
to
me:
we
could
also
do
here
is
kind
of
address
this.
Just
from
the
ca
side,
it
seems
like
if
ca's
weren't,
quite
so
aggressive
about
invalidating
challenges.
B
If
they
don't
work
the
first
time,
then
you
might
not
need
somewhat
such
mechanism
here.
So
you
know
if
the
worry
were
things
like
DNS
propagation,
it
you
might
avoid
a
bunch
of
these
errors.
If
the
ca
were
just
willing
to
try
again
in
a
couple
minutes-
or
maybe
you
have
some
expanding
window
of
retries
of
validation
over
time
and
that
wouldn't
require
any
protocol
change,
we
would.
We
could
just
add
some.
You
know
non-normative
recommendation
where
we
recommend
ca's
retry
some
of
these
things
in
order
to
allow
for
clients
getting
everything
arranged
properly.
B
F
I
so
I
agree
that
your
fourth
entry,
that
maybe
is
we
try
validation,
queries.
That
was
an
outburst
and
I
think
that
this
seems
like
the
best
way
to
fix
this.
The
problem
is,
you:
do
want
to
kind
of
have
exponential
back-off
like
try
again
in
a
minute,
try
again
in
five
minutes
an
hour
a
day
or
maybe
even
up
to
a
week.
We
do
actually
have
some
clients
who
you
know
create
authorizations
and
then
on
order
and
days
to
play
something.
F
B
Try
imagine
mechanism
was
that
what
that
would
look
like
I
mean
if
it
were
something
like
you
know,
I
take
the
same
payload
that
I
are
the
same
yeah
the
same
payload
that
I
posted
before
I
Reese,
I,
knit
and
I
posted
to
the
challenge
again
see
a
verifies
that
it's
the
same
payload
and,
if
so,
reach
drives
the
validation.
Is
that
something
like
what
you'd
be
imagining
here
for
the
mechanism?
Yeah.
F
And
so
also
the
question
is
during
those
automatic
retries
by
the
ca:
what's
the
status
of
the
authorization,
you
know
it's
not
invalid.
Yet
but
most
clients,
probably
you
know
the
straightforward
case.
Most
clients
want
to
return
to
the
user
and
say
this
was
the
error.
We
got.
That's
how
you
fix
it.
B
It
seems
like
you
could
I
think
my
opening
offer,
for
that
would
be
to
keep
it
in
a
pending
state,
but
then
have
like
a
list
of
error
results
that
the
CIA
had
gotten.
So
if
you
observe
that
the
challenge
is
still
pending,
but
it
now,
it's
got
an
error
attached
to
it.
Then
you
can
infer
that
the
ca
is
not
succeeded
at
validating
it
and
provide
that
error
back
to
the
user
yeah
one.
F
B
B
A
Okay,
so
if
there's
anybody
who
objects
to
this
approach
now
would
be
a
good
time
to
think
it
will
cause
us
to
recycle
the
working
group
last
call
it's
a
big
enough
change
for
that.
So
understand
that
that's
a
consequence
to
make
this
change
I,
don't
see
an
objection,
so
it
sounds
like
the
next
step
would
be
for
the
editors
to
make
this
change.
And
then,
when
we
issue
a
new
working
group,
glass
hallway,
we.
B
B
A
K
A
That
what
we're
what
we're
proposing
here
is
functionally
equivalent
to
doing
a
text
plain
encoding
and
that
creating
a
new
listing
for
text
plain
is
not
sensible
and
he's
suggesting
that
we
go
to
ad
er
rather
than
a
pen.
Concatenated
de
are
I
believe
so
rich.
Do
you
want
to
comment
from
the
floor
on
this
sure.
M
L
Names
of
the
format
right,
that's
just
an
editorial
issue.
The
other
thing
he
was
suggesting
and
we'll
have
to
do.
A
consensus.
I
think
is
rather
than
have
yeah
base64
some
support
character,
encoding
on
just
out
put
it
in,
say
any
kind
of
arbitrary
gurr
order,
for
example
the
one
the
one
he
recommended
that
the
end
was
used.
The
TLS
certificate
lists
order.
It.
A
B
I
think,
as
I
recall,
that
we
originally
had
just
dürer
as
the
way
you
return
or
certificate
reason
we
changed,
that
was
for
developer
friendliness
to
match
what
was
accepted
as
input
by
most
of
the
industry.
It
turns
out
there
is
kind
of
a
de
facto
standard
there
and
so
I
agree
with
rich
that
I'm
hesitant
to
move
away
from
that.
Unless
there's
some
agreement,
there's
some
other
state
are
coming
up
so
yeah.
What's
the
lightest
so.
M
M
C
I
B
B
A
So
the
proposed
resolution
to
the
Thornton
group
at
see
if
anybody
objects
to
this
is
to
adjust
the
terminology,
as
was
originally
suggested
in
Sean's.
First
message:
that's
not
quite
as
simple
as
changing
the
mime
type,
there's
also
some
character
set
stuff
that
has
to
happen
Jacob
book.
You
want
to
propose
a
different
resolution
or
a
comment
on
this
proposal.
Well,.
F
Yeah
comment
so
very
recently
on
the
left
in
the
last
like
hour
or
two
John
Ray's,
but
I
actually
thought
it
was
a
really
good
point,
which
is
that
if
the
client
naively
copies
the
pen
certificate
chain
into
a
file
to
be
loaded
by
say
Internet's
or
patchy,
which
is
what
we
expect
them
to
do.
It's
obvious
thing.
The
ca
can
slip
a
private
key
in
there
and
those
web
servers
will
interpret
that
to
say.
Oh
I
should
use
this
private
key
rather
than
the
one
that
I
was
configured
with.
L
B
A
So
back
to
the
proposed
resolution,
the
proposed
resolution
here
is
a
textual
adjustment
to
correctly
identify
the
mime
type
here
which
includes
character
set
and
the
other
issues
that
go
along
with
that
and
secondarily
to
investigate
and
potentially
add
text
to
the
security
considerations
on
the
insertion
of
a
private
key
attack
which
on
raised
since
we
are
already
going
to
have
to
go
back
through
working
group.
Last
call
that
was
the
previous
issue.
There's
still
some
time
for
on
list.
A
C
Yeah,
so
we
should
probably
deal
with
this
issue,
but
can
really
not
this
probabilistically
much
as
I
despise
ever
discussing
whether
or
not
promising
dairy
advice
or
random?
Okay,
Matt
judo
that,
like
pick
this
text,
I
looked
at
this
PR
right,
it
didn't
require
like
a
minimum
length,
so
I
mean
if
we
want
to
tell
people
I
mean
so.
Is
there
an
issue
for
this?
I
could
bring
up
and.
C
C
I
do
not
think
that
telling
that
the
pretending
that
they
are
not
unique
is
a
useful
like
waiting
age
of
the
universe,
if
160,
if
you
prefer
to
like,
have
you
know
a
if
you're
really
feeling
nasty,
so
I
don't
care
how
we
specify
what
people
do,
but
I
think
that
like,
if
we're
going
to,
but
if
we're
organism
so
we're
going
to
say
they
should
be
unique
and
leave
it
entirely.
The
server
discretion
that's
reasonable.
B
So
a
construction
like
saying
that
they
may
either
be
random
of
a
certain
length
or
more
or
constructed
to
be
unique
seems
book
could
be
bought
yeah.
But
that
seems
fun
to
me
I
could
and
if
you're
right
this
is
daniel.
I
think
you
may
have
been
writing
the
texture
on
this.
Maybe
not,
let's
seem
to
recall
seeing
a
PR
danny.
B
B
B
C
L
L
B
Is
not
the
domain
it
with
that?
It
is
not
a
level
at
which
the
specification
addressed
cas
do
any
number
of
things
that
we
have
makes
you
have
a
list
at
the
back
of
the
spec
of
additional
things
beyond
acne
that
is,
EA's
should
probably
do
to
meet
their
obligations
to
the
world
before
the
issue,
a
certificate
checking
against
hi,
my
name's
looking
for
you
know,
PayPal
calm
like
domains,
things
like
that
and
yeah.
B
A
Said
Ted
Hardy
just
pointing
out
that
on
the
list,
in
fact,
Hugo
who
raised
this
issue
or
as
one
of
the
folks
who
raised
this
issue,
has
pointed
out
that
the
cab
forum
has
now
made
it
mandatory
in
an
in
it
in
a
document
that
was
issued
in
march
of
this
year.
As
a
result,
the
marginal
utility
of
us
requiring
it
as
well
seems
at
modest,
is
a
good
description.
Is
there
anybody
who
wishes
to
argue
at
this
point
that
that
modest
utility
is
worth
it.
M
B
L
L
P
So
it's
my
contention
since
I
think
I'm
the
one
who
raised
this
issue
that,
while
requiring
people
to
sign
their
own
domains,
is
perceived
quite
onerous
and
many
people
haven't
that
running.
A
validating.
Resolver
is
rather
routine
these
days,
and
I
think
that
for
folks
who
have
signed
their
domains
and
are
then
going
to
be
using
dns
challenges
to
obtain
certificates.
P
It
is
a
very
reasonable
expectation
that
the
ca
would
do
you,
the
courtesy
of
validating
your
dns
responses
and
not
accepting
forgeries
from
any
man
in
the
middle
attacks
and
that
the
burden
on
the
ca
of
just
spinning
up
you
know
their
favorite
resolver
and
configuring.
The
trust
anchor
is
very
minimal,
so
I
would
expect
I
think
reasonably
that
the
ca
can
join
the
millions
of
people
who
use
a
today
today
today,
tour,
very
science
version
and
so
on
and
are
already
using
DNS
SEC
with
no
noticeable.
A
P
P
A
P
I,
don't
know
who
the
casr,
who
aren't
already
in
camp
forums,
I'm
not
sufficiently
aware
of
what
what
the
difference
is
in
practice
would
be.
It
just
seems
to
me
that
if
you're
implementing
the
specification,
you
ought
to
be
aware
that
the
DNS
challenge
or
can
be
verified
this
DNS
and
if
it
said
multiple
times,
I,
don't
see
the
harm
of
saying
it
multiple
times,
just
like
I.
Don't
really
in
the
previous
topic,
see
the
harm
of
saying
that
CAA
is
mandatory,
even
if
cab
form
already
said
so,
there's
no
reason
not
to
say
so.
H
K
In
ITF
bill
I,
don't
think
that
this
could
be
a
must
because
it
isn't
actually
a
necessity
for
interoperation,
but
I
could
be
persuaded.
Otherwise.
The
issue
I
would
see
from
the
cab
forum.
Point
of
view
is
that
we
have
been
very,
very
careful
to
avoid
endorsing
the
I
can
root
as
the
root
of
everything
and
for
us
that
is
a
showstopper,
because
we
do
not
know
who
will
be
running
I
can
in
10
years
time.
K
We
do
not
run
oh,
who
will
control
it,
and
there
is
absolutely
no
way
that
we
can
establish
an
administrative
guarantee
that
he'd
be
running
an
acceptable
fashion.
So
I
think
that'll
be
very
difficult
to
get
a
statement
in
cab
forum.
That
bcas
must
be
subservient
to
I
can
see
a
as
the
root
of
all
things.
Oh
that's.
A
C
A
K
A
Of
progress
instead
of
describing
this
is
a
requirement.
Why
don't
we
write
up
what
the
threat
is
and
include
the
threat
in
the
security
considerations
such
that
somebody
in
the
security
considerations,
sees
the
potential
threat
and
knows
that
if
a
DNS
SEC
signed
delegation
is
available,
the
threat
threat
is
mitigated
that
doesn't
put
a
requirement
on
it,
but
is
information
to
the
developer
community
of
what
the
threat
is
and
what
one
meeting
each.
P
Other
yeah,
I
think
this
completely
fails
to
address
the
issue.
You
know
if
I
am
the
if
I
own
a
DNS
SEC
signed
domain
I'm
expect
certain
security
properties
for
my
domain
and
I'd,
like
anybody
petitioning
for
a
certificate
for
my
domain
to
be
prevented
by
my
signature
from
easily
forging
the
DNS
accor
various
other
challenges,
so
the
DNS
or
various
other
challenges.
This
needs
to
be
a
mustache
should
is
largely
pointless,
just
as
should
for
CAA
was
pointless
until
the
cab
forum
finally
made
it.
A
must
then
s2
fills
point
you
know.
P
P
B
Ted's
point
about
documenting
the
threat
here
on
mitigations
of
believe
we
do.
You
have
texting
security
considerations
about
such
threats
and
there
are
some
text
in
error
and
I
think
has
been
there
for
a
long
time
about
how
you
can
reduce
the
threat,
while
not
the
dress
gate
as
part
is.
The
NSF
does,
by
doing
validation
from
multiple
vantage
points,
to
reduce
the
risk
of
getting
that
responses
to
Victor's
point
I
think
it's
dramatic
overstatement
to
open
sort
of
this
setback.
B
K
B
We
can
we
can
check
and
make
sure
it's
as
good
as
it
can
possibly
be
I
think
to
Victor's
point
about
expectations
of
what
I
could
expect
when
I
sign
my
domain
to
say
that
I
expect
my
DNS
SEC
signature
be
validated
before
some
requests.
Certificate
is,
unfortunately,
hugely
optimistic
in
the
world
we
live
in
today,
I'm,
given
that
there
are
a
number
of
CAS
out
there,
only
a
small
number
of
which
even
are
doing
at
any
flavor
of
acne.
Today,
there's
not
really
it's
not
really
sensible.
I
have
an
expectation.
B
The
NSF
makes
any
particular
difference
like
now.
Now
that
we
have
a
CAA
requirement,
you
might
add
a
CA,
a
policy
that
says
your
ca.
Please
check
verify
the
DNS
SEC
signature
for
you
doing
that.
That
I
think
would
be
a
fine
thing
to
do,
and
we
should
it
might
be
worthwhile
to
write
up
an
extension
of
CA
to
do
that.
But
I
think
you
know
given.
H
F
Next
or
all
right
so
yeah
we
definitely
we
have
a
normative
recommendation
for
DNS
SEC
Victor
said:
that's
not
enough.
I
stand
that
fun
view
one
thing
that
might
help
them
form
the
conversation.
Let's
encrypt
does
validate
dmsx
today.
So,
like
all
the
publicly
available
acne
servers
implement
this,
and
so
then
the
question
is,
but
is
this
the
right
lever
to
get
more
cas
to
implement
DNS,
SEC
I?
F
Think
if
another
CA
were
to
prolong
and
say
we
really
want
to
implement
acne,
but
we
don't
want
to
bother
validating
DNS,
SEC
or
more,
like
you
know,
if
there's
some
reason
why
they
don't
want
it
validate
the
MS
sec
I
think
they
won't
say
wow.
We
want
to
implement
acne
so
badly
that
we're
going
to
start
melody,
didn't
DNS
SEC.
Now
they
would
just
go
ahead
and
implement
acne
and
ignore
this,
because
it's
not
actually
an
interoperability
concern
I,
think
more
likely.
G
I
H
Want
to
keep
pretty
much,
but
the
thing
that
John
is
just
said:
I
1.8,
that
what
you're
doing
validation
in
DNS
sake,
it's
not
necessary
to
use
the
ones
you
trust
anchor
from
the
I
can
administer
fruit
so
about
the
to
resolving
server.
Could
if
it
chose
to
set
up
a
suntrust
bank
here
in
quality
of
that
as
realized
or
instead
of
yeah
I
can
just
don't
get.
P
It
sure
just
quick
I
certainly
have
no
expectation
that
every
dns
query
from
my
domain
will
be
validated.
What
I'm
trying
to
get
to
is
that
the
Acme
cas
who
might
want
to
issue
certificates
from
my
domain
would
validate
the
DNS
responses
that
contain
the
the
challenge.
Verification
bits,
that's
it!
Oh
sorry,
one
more
thing:
I
I
haven't
heard
yet
a
reason
why
I
CA
would
not
run
a
validating
resolver.
It's
not
like.
It
takes
more
than
two
minutes
to
set
one
up.
K
That's
verisign
sells
for
six
bucks
a
year,
so
this
is
not
an
organization
that
I
think
it's
completely
beside
the
point.
Phil.
Could
you
stick
to
the
technical
point?
No
from
this
point.
From
my
point
of
view,
it
is
to
the
point
because
you
are
creating
a
technical
time
that
creates
a
technical
risk
for
my
business
and
so,
whereas
you
can
check
in
to
the
top
level
domain,
DNS
SEC
is
a
particularly
objectionable.
K
A
A
Does
this
CA
support
my
linkage
or
not,
would
be
a
valuable
extension
making
it
a
permanent
part
of
the
protocol,
I
agree
with
you
is,
is
not
a
necessary
thing
for
this
group
to
do,
but
making
it
part
of
an
extension
that
would
allow
you
to
discover
whether
or
not
ACA
honored
this
linkage
in
this
way
or
not
I
think
it's
quite
reasonable.
I
also,
don't
think
that
it
is
necessarily
a
wonder:
go
in
right
now,
sort
of
thing
which
leads
us
and
I'm
going
to
change
from
this
microphone
to
the
chair,
microphone
to
our.
I
P
Oh
No
agree
actually
think
that
was
Richard
with
the
last
call.
This
is
victor.
The
CIA
suggestion
actually
might
cover
it.
If
CAA
could
specify
don't
issue
with
that
DNS
SEC
that
might
be
another
vehicle
for
this
I,
don't
see
anything
in
CA.
That
can
do
that,
but
you
know
me
being
able
to
check
the
weather
my
chosen
CA.
P
You
know
honors
DNS
SEC,
it's
not
sufficient,
because
my
concern
is
that
some
attacker,
who
is
not
me,
might
choose
some
other
CA
and
that
they
being
a
neck
me
CA,
no
longer
obligated
by
the
spec
to
check
the
NS
a--
quill.
Not
so
it's
not
a
question
of
whether
I
will
wisely
choose
the
a's,
the
validate
it's
an
issue
that
the
attacker
will
choose.
The
least
restrictive
see
the
main
problem.
I.
A
Yes,
we're
staying
as
it
is,
as
you
noted
from
the
previous
thing,
we
are
going
to
go
through
another
working
group
last
call
because
of
the
changes
to
this.
So
the
first
question
to
the
isg.
Yet
that
that's
not
what's
going
to
happen
now,
we
have
to
have
at
least
one
more
Reb
of
the
other
document
and
one
more
working
group
last
call
before
we
take
the
isg.
A
So
the
working
group
last
call
comments
that
have
come
in
and
the
resolutions
we've
seen
today
do
seem
to
us
to
require
that
so
re
working
group
last
call
p.
The
second
item
here
seems
like
our
most
sensible
path
board
here,
but
there
is
then
the
question
we
will
we
after
that,
continue
to
hold
for
implementations
of
these
changes,
and
I
think
that
the
the
question
really
is.
Although
these
changes
are
significant,
do
we
need
to
call
them
so
significant
that
we
need
for
interrupt
to
be
demonstrated
on
what
level
button.
A
J
A
So
I
guess
the
question
then
is
given
that
timeline.
Do
we
want?
We
will
run
the
working
group
last
call
before
Prague,
obviously,
as
soon
as
the
editors
give
us
that
do
that
and
on
the
list
work
through
any
new
issues
which
come
up
or
any
which
are
revisited
by
new
information
and
then
it
sounds
like
people
wants
to
lie
quiet
for
a
little
while
and
just
before,
Prague
perhaps
decide
whether
we're
ready
to
send
a
very
blessed
fall.
Does
that
make
sense
as
a
time
frame
for
people
Prague
is
in
July?
A
So
in
parallel
to
the
working
group
last
call,
then
we
will
probably
then
entertain
on
the
list.
Any
suggestions
for
what
work
items
might
go
on
to
a
recharter
and
then
we'll
make
discussing
such
a
recharter
the
primary
work
of
Prague,
assuming
that
the
base
draft
has
gone
to
the
isg
in
the
meantime.