►
From YouTube: IETF101-ACME-20180321-1520
Description
ACME meeting session at IETF101
2018/03/21 1520
https://datatracker.ietf.org/meeting/101/proceedings/
A
B
A
A
Okay,
so
most
of
you
have
heard
which
could
not
be
joining
us
this
side
here
so
I'm
alone
here
have
mercy.
This
is
the
note
well,
which
I'm
sure
you've
seen
several
times.
This
is
the
new
version
that
has
a
link
to
the
privacy
policy.
Otherwise
it's
not
much
changed
since
last
time.
As
always,
this
is
only
a
summary
and
if
you
want
to
know
the
actual
stuff
consult
lawyer
or
read
all
of
the
BCPs
there
at
the
bottom,
preferably
both
so
our
agenda
for
today
we're
doing
part
of
it.
A
A
A
Acme
CIA
is
expiring,
though
it
has
been
in
working
group
last
call,
so
I'm
not
really
sure
about
the
status.
Rich
seems
to
think
that
it's
ready
to
be
to
proceed
because
we
have
gone
through
working
group
last
call,
but
I
want
to
hear
it
from
the
author.
First,
so
I'll
talk
to
the
author
and
hopefully
push
this
to
the
ISG
to
email
drafts.
We
have
new
versions
from
this
month
for
the
TLS
document.
We
have
a
version
new
version
from
today
that
just
adds
pop3
Alexey,
since
you
didn't
send
slides.
D
D
A
A
So
also
we
have
the
Acme
service
provider
and
telephone
and
we're
going
to
do.
We
are
having
a
presentation
about
them
a
little
later
and
Acme
IP
and
acne
TLS,
a
LPN
were
also
having
presentations
so
Wilson.
So
what's
missing
well,
there's
the
base
document
and
we
thought
it
would
be
ready
by
last
time
and
it
wasn't
and
then
we
decided
that
we
made
enough
changes
that
they
it
required.
A
Another
working
look
last
call
and
then
a
lot
of
issues
came
up
and
that
those
were
addressed
and
fixed
and
we
have
a
new
version
version,
10
and
I
kind
of
practiced,
with
Richard
the
kind
of
back
and
forth
banter
or
asking.
If
it's
ready
and
say
yeah
everything's
ready,
you
just
push
it
out
and
then
there's
a
new
PR
from
yesterday
I
think
so,
which
I'm
still
not
in
the
room.
C
A
E
Yeah
I
think
we're
done
cool
and
you've
seen
the
new
PR,
yeah
I,
think
CPU,
just
virtual
okay,
yeah
I,
think
that
was
the
minor
clarifications
that
were
requested
on
the
list
during
last
last
call
so
that's
merged.
Now,
so
I
think
it's
ready
for
public
Wes
290th.
Let's
go
okay,
great
all
right!
Thanks.
F
G
Lu,
so
this
is
a
document
that
was
actually
adopted
sometime
last
year.
I
think
and
there's
basically
been
no
movement
on
it,
but
rich
thought
it
would
be
a
good
idea
to
have
a
quick
overview,
so
this
basically
adds
extensions
to
the
existing
document
to
provide
for
validation
of
IP
identify
as
currently
we
only
have
identifies
and
challenges
for
validating,
DNS
identifiers.
This
would
allow
us
to
use
acne
to
issue
certificates
for
issue
certificates
containing
IP
addresses.
G
So
the
existing
HTTP
and
TLS,
a
LPN
which
we'll
talk
about
next
methods,
will
work
with
IP
identifies
basically
without
any
modification.
The
only
thing
is,
you
know
we
don't
resolve
DNS
basically,
and
then
this
document
also
introduces
a
new
method
called
reverse
DNS,
which
basically
is
the
DNS
method
from
the
original
document,
except
for
there's
an
additional
step
where
we
look
up
their
reverse
zone
and
look
up
any
PTR
records,
and
if
there
is
a
PTR
record,
we
then
do
the
DNS
lookup
at
the
target.
G
H
No
hat
so
I
recognized
that
reverse
DNS
is
valid
according
to
three
to
five.
However,
it
doesn't
actually
have
anything
to
do.
We
control
the
IP
address
base,
and
so
it's
quite
different
from
the
DNS
situation,
where
actually,
if
you
controlled
so
look
at
it
this
way,
if
you
control
the
DS,
it
is
for
host
you,
you
actually
can
cause
traffic
to
another
location.
So
that's
constructive
control,
extracted
control
of
the
of
the
debate
name.
Do
you
control
reversed,
like
in
editor
aqua
for
the
host?
I
G
Okay,
I
think
control
of
the
reverse
I
think
control
of
the
reverse
zone
is
if
it's
enough,
they
kept
forum
I'm,
not
sure,
there's
and
I
mean
less
there's
a
slight
argument
that
you
know
an
attacker
may
be
able
to
get
in
control
for
averse
own
and
therefore
they
can
issue
certificates
for
that
IP
address.
Well,
if
they
control
the
rivers
own,
then
something
much
worse
has
happened.
No.
H
G
H
I
guess
we
have
this
meeting
time.
That
seems
like
usually
the
time
when
one
discusses
these
things
yep
so
I
guess
I'm,
not
sure,
quite
why
you
think
I
should
bring
up
in
the
list.
So
we
can
discuss
it
a
list.
One
right
here.
G
G
G
I
think
we
can,
you
know
if
we
can't
trust
that
I
Ana
or
whoever
a
and
Nick
are
not
properly
delegating
trust
to
the
reverse
zones.
Then
there's
a
much
more
severe
problem
here
and
I
think
you
know
that
this
has
that
this
has
been
going
on,
for
you
know,
however
long
would
be,
ours
have
allowed
it,
and
we
haven't
seen
any
issues.
So
far
is
a
reason
to
believe
that
there
isn't
an
issue.
Okay,.
H
So
I
don't
really
find
either
Zorgon
was
persuasive.
The
second
argument,
like
the
rule,
is
full
of
security
problems
which
we
discover
and
then,
like
you
know,
we
have
to
deal
with
them.
You
may
have
heard
of
specter,
so
I
don't
buy
that
versus
aramid.
The
for
argument
on
the
problem,
as
I
said,
is
it's
not
the
initial
delegation.
It's
a
subsequent
management
of
those
demands
which,
as
I
say,
you're,
not
operational
or
the
infrastructure
and
therefore
do
not
need
to
be
secured.
H
The
way
the
forward
part
of
the
mains
do
just
they're
operating,
but
if
they
go
wrong,
nothing
happens,
and
so
the
security
controls
those
needs
subject
and
the
the
reason
that
is
acceptable
to
have
quasi
acceptable
to
have
DV
is
there's
a
face.
Sharing
between
the
things
you
do.
The
checking
with
and
the
thing
is
operational
is
part
of
the
system
is
simply
not
true
here.
H
G
G
I
Yep,
so
I
do
disagree
with
Eric
here,
which
you
know
there's
a
matter
of
the
policy
in
that
sorry,
Ryan
sleevee
Google,
so
I
disagree
with
Acheron
security,
prime.
So
there
there's
the
separation
of
the
policy
and
the
technical
means
and
I
do
think
it's
appropriate
to
separate
out
between
the
expression
of
the
IP
address
and
the
certificate
and
whether
or
not
from
a
policy
perspective.
That
is
a
sufficient
level
of
validation
and
I.
I
Totally
appreciate
Eric's
concern
that
may
not
be
appropriate
from
my
policy
side,
and
you
know,
I
agree
that
if
it
is
not
acceptable
on
policy
than
policy
should
express
that
and
and
so
I'm
supportive
of
of
having
the
technical
means
to
address
that.
To
the
point
of
you
know
the
see
a
browser
forum,
we
are
going
through
an
overhaul,
the
validation
methods
to
re-examine
the
security
properties
both
of
domain
name
validation,
which
today
we
have
three
two
two
four
eight
which
allows
you.
I
Anyone
who
controls
any
IP
address
that
a
domain
resolves
to
can
get
a
certificate
for
that
domain
based
and
and
that
the
Assumption
there
is
well.
If
you
can
use
things
like
acne,
you
know
HTTP
or
TLS
AOL
in
then
it
makes
no
difference.
Why
not?
Just
let
you
do
the
IP
address
itself
that
they
are
commute
of
properties,
and
so
here,
when
we're
talking
about
IP
addresses
I,
agree
that
if
we
trust
IANA
in
the
same
way
that
we
trust
domain
I
can
to
handle
the
domain
name
delegation
and
properties,
then
it's
no
different.
I
The
the
question
is
policy
and
I.
Think
that
is
not
for
us
to
decide
here
and
we
should
instead
formalize
this
validation
method
and
then
let
the
policy
groups
that
handle
this
policy
address
it
as
appropriate.
The
only
thing
that
could
potentially
be
beneficial
here
is-
and
this
is
something
to
see
a
browser
forum
was
working
through,
which
is
the
security
property
of
expressing
an
IP
address.
Subject:
alt
name
and
the
validation
of
that
IP
address.
I
Subject:
alt
name
are
different
than
these
security
properties
of
expressing
a
DNS
name
subject
all
named
through
the
validation
of
the
IP
address,
and
so
we
treat
those
as
separable
problems.
So
this
I
think
is
appropriate
for
an
IP
based
validation
for
an
eye
piece
and
it
may
not
be
appropriate
for
a
DNS.
An
IP
based
validation
of
the
DNS
Sam
yep
agreed.
F
Cullen
Jennings
we've
tried
to
use
these
types
of
reverse
records
for
spam
mitigation
and
reputation
stuff
in
basically
spam
prevention
and
they're
wrong.
All
the
time
like
it's
crazy
to
think
that
these
are
accurate
on
a
widespread
basis,
they're
often
wrong
and
there's
nothing
to
fix
them.
So
I
was
not
actually
aware
that
cab
issued
certificates
that
way,
I'm
that
really
deeply
alarms
me
yeah.
F
G
G
F
J
One
of
two
reinforce
the
point
about
that
Eric
made
about
the
DNS,
not
the
reverse,
DNS
not
being
operationally
important,
and
therefore,
operators
pay
very
little
attention
to
its
accuracy
and
validity,
which
is
why
it's
such
a
mess.
From
the
point
of
view
of
how
the
reverse
DNS
delegation
relates
to
responsibility
for
routing
in
a
typical
enterprise,
the
DNS
will
be
respondent
will
be
the
responsibility
of
one
team,
and
the
routing
will
be
a
responsibility.
We
completely
separate
team
and
whether
they
actually
talk
to
each
other
in
an
effective
way
is
not
guaranteed.
K
Nitesh
projects
is
ethnic,
I
also
come
from
DNS
working
group.
Didn't
I,
wasn't
aware
of
this
Acme
thingy
up
until
now,
and
with
my
tle
operator
had
on
an
open,
recursive,
resolver
hat
on.
Please
don't
do
this
because
the
reverse
DNS
is
just
plain
broken
I
mean
there
are
big
parts
of
diversity
which
don't
even
resolve.
Don't
even
you
know,
servers
behind
them
because
nobody
cared
enough
to
put
a
DNS
server
in
there.
Also
big
chunks
of
DNS
diversity
are
not
signed
using
the
NSX,
so
I
mean
this
part
of
DNS
is
the
dark
corner.
L
This
is
a
question
because
I
don't
know
how
don't
all
the
details
could
this
be
perceived
as
actually
useful
in
a
local
environment
where
you
have
a
local
trust
anchor
for
for
for
your
reverse
tree,
because
then
you,
when
you
working
in
control
of
the
entire
environment,
so
to
speak,
the
security
parameters
are
totally
different
yeah,
but
from
the
for
the
larger
internet,
I
am
on
their
side.
Okay,.
M
E
N
Off
topic
point:
could
you
speak
your
name,
because
my
eyesight
is
going
and
I
cannot
see
you
where
the
mic,
when
I'm
typing
the
point
I
was
going
to
make
is
I
am
not
sure
where
the
cab
forum
rules
allow
it
I
I
will
have
to
check
to
see
whether
they
do
and
if
they
do
I'll
be
putting
in
a
ballot
proposal
to
shut
them
down,
because
I
don't
like
this.
Okay.
G
E
As
Richard
Barnes,
so
I
have
some
sympathy
with
sleepies
argument
that
it
is
ultimately
a
policy
decision
what
property
of
the
technical
infrastructure
PCAs
wants
to
rely
on
to
to
validate
these
things,
but
by
and
large,
I
think,
ekor
and
fluffier
are
on
the
right
track
here
in
terms
of
the
security
properties.
E
Of
this
thing,
so
I
mean
I
could
envision
a
universe
where
you
know
there
was
a
compelling
need
to
rely
on
this
sort
of
thing
for
some
large
set
of
critical
use
cases
that
couldn't
do
anything
else,
and
it
was
the
ietf
job
to
design
the
best
possible
mechanism
that
could
be
done
under
those
constraints.
I'm
not
convinced,
we've
quite
met
that
bar
yet,
and
so
in
the
interest
of
moving
this
forward.
I
I
Validation
is
the
assumption
that
the
RR
NIC
has
provided
correct
information,
so
in
the
set
of
methods
acceptable
to
validate
an
IP
address,
you
assume
that
the
RR
Nick
is
provided
and
you
can
contact
if
you
reach
out
to
the
Aaronic
like
Aaron
or
right,
and
you
can
get
an
email
address
for
saying
who
owns
this
net
block?
Anyone
who,
who
has
such
a
record
can
cause
issuance
for
any
of
the
IP
addresses.
I
G
So
this
is
a
replacement
for
TLS
S&I.
For
those
who
haven't
been
following
along
on
the
list.
There
was
a
rather
big
issue.
A
TLS
SNI
that
was
discovered
in
the
wilds
basically
boils
down
to
hosting
providers
allowing
users
to
claim
arbitrary,
sni
names.
So
you
would
go
to
hosting
big
hosting
provider
and
register
your
account
and
then
you'd
be
able
to
tell
them
hey
I
sort
of
traffic
for
invalid
Acme.
This
allowed
people
to
basically
serve
traffic
for
the
computed.
G
G
Basically,
this
method
is
very
similar
to
TLS
nya,
but
with
two
major
differences.
The
first
is
that
we
negotiate
ma
LPN
protocol,
which
basically
enforces
the
property
that
TN
TLS
a
LP
n
validation.
Is
opt-in
either?
Well,
unless
your
server
is
blindly
echoing
a
LP
n
values,
which
we
really
don't
want
people
to
do
and
is
bad
and
from
our
testing
no
one
seems
to
be
doing
so.
G
We're
not
worried
about
it
yet,
and
the
second
property
is
that
we
actually
use
the
name
being
validated
in
the
s
and
I
extension
this
time
instead
of
an
invalid
constructed
name,
and
this
means
that
we
actually
get
the
property
that
we
are.
We
know
we
are
talking
to
the
person
who
has
claimed
that
name
in
TLS
as
night.
That
still
would
been
a
problem,
because
if
you
hadn't
enabled
HTTP
on
your
site
on
a
hosting
provider,
someone
else
would
still
be
able
to
claim
that
name.
G
But
with
a
LP
n,
we
hope
that
any
hosting
provider
that
chooses
to
offer
this
understands
the
security
property
and
won't
actually
allow
arbitrary
people
to
claim
s
ni
names
which
they
aren't
actually
serving
traffic.
For.
So
the
method
is
quite
simple:
you
connect
to
the
host
who
initiate
a
TLS
handshake
and
the
client
hello
has
to
contain
the
alp,
an
extension
Acme
TLS
that
names
up
for
debate.
Some
people
have
suggested
other
things:
an
SN
I
extension
containing
the
name
being
validated.
He
then
verify
the
server.
G
Hello
is
echoed
back
the
alp,
an
extension
with
only
the
Acne
TLS
value
and
they
have
sent
a
self
signed
certificate
for
the
name
being
validated
that
contains
a
critical
extension
that
contains
the
validation
token.
You
then
compare
that
token
is
what
you
expect
and
if
it
is,
you
have
succeeded
any
questions.
H
Was
thinking
about
that
I
mean
this
use
just
sort
of
rely
on
an
accidental
property,
mainly
that
sites
don't
Justin
Moore,
not
ignore,
but
effectively
consent
to
whatever
a
opine
you
offer
them.
I
assume
the
rationale
for
using
a
OPN
is
that
you
think
that
we
enema
tell
us
is
too
hard
for
random
TLS
servers
to
process
at
different
extension
that
you've
made
up
yep.
So
I
guess
one
question
I
have
is:
do
random.
Http
servers
actually
allow
you
to
configure
the
EOP
on
settings.
H
I
guess
the
reason
I'm
getting
is
basically
all
modern,
TLS
stacks
are
having
to
add
next
external
extension
processing
in
order
support,
quick
and
so
given
that
you're
willing
to
given
that
you're
doing
something
which,
like
there's
no
natural
surface
area,
for,
why
not
define
a
new
TLS
of
tension
with
semantics
that
are
not
equitable,
for
instance,
I,
don't
know
like
you
know,
you
mess
the
responses,
a
message
I
just
the
input
that,
like
you,
absolutely
confident
that
no
random
server
will
do
I.
Think.
H
I
don't
mean
that
that's
exactly
my
point.
My
point
is:
is
that
the
the
way,
the
way
the
server
would?
In
your
case,
you
say,
the
servo
hello
contains
an
AOP,
an
extension
containing
activate
EMS
one
by
the
way
in
TLS.
1.3
I
should
be
EEE
but
anyway,
so
so
right
now
you're
relying
the
server
ulti
ulti
law
servers
ignore
Wario
p.m.
they
don't
recognize
ya.
H
H
Generate
a
ball
by
not
during
my
really
copying
the
impact
yeah,
it's
a
random
value
in
the
extension
and
then
the
response
is
I,
don't
on
like
I'm
H
Mac
of
like
something
in
the
spec
and
and
then
the
value
and
then
like
I,
mean
I
ruined
in
the
principle.
But
the
fact
that,
like
this
tell
us
just
having
to
stand
themselves
anyway,
suggests
that
maybe
it's
not
actually
hard
to
implement
and
it's
a
much
higher
like
doesn't
rely
on
like
axonal
properties
of
their
way
so
decide.
H
I
I
was
a
proponent
of
doing
the
LPN.
For
precisely
this
reason
was
the
spec
says
you
should
not
blindly
echo
NPN
have
that
property?
Where
you
could
do
this,
you
know
you
get
client
sends
one
thing,
and
the
server
can
send
a
different
value
that
the
client
didn't
echo
and
we
moved
away
from
that
in
TLS.
It's
a
must.
Yeah
yeah
yeah,
it's
it's
it's
it's
on
the
must,
and
that
was
that
was
part
of
the
same
concern
was.
I
N
Fell
on
Baker
I
are
on
the
side
of
more
cynicism,
all
right
as
far
as
the
legacy
service
is
concerned,
Acme
is
a
protocol
that
I've
always
believed
will
pretty
quickly
once
it's
been
standardized
merge
into
the
service,
and
so
I
think
that
we
will
get
a
new
generation
of
servers
turning
over
relatively
rapidly
so
I'm,
not
that
worried
about
the
legacy
base
and
further.
As
far
as
a
legacy
base
is
concerned,
I'm
only
concerned
that
there
is
one
way
that
they're
able
to
do
it,
not
that
they
have
access
to
absolutely
every
possible
method.
P
Yeah
so
Madden
Thompson
I
think
the
the
key.
The
key
point
here
is
that
you
basically
have
close
to
just
one
bit
of
information
coming
back
and
from
the
service
response
here.
But
if
you
make
a
new
extension,
which
is
echo
pointed
out,
is
actually
relatively
easy
in
in
modern
stacks.
You
can
do
the
whole
challenge
in
the
extension,
and
that
gives
you
128
bits.
So
what
about?
What
have
you
in
in
there
and
I'd,
be
far
more
confident
with
that?
I
think
this
is.
This
is
a
pretty
good
idea
and
I
like
that.
P
I
also,
like
the
fact
sorry
I,
also
like
the
fact
that
you
have
the
sni
is
for
the
the
intended
host
and
the
certificate
is
valid
for
the
intended
host
and
that's
that's
a
great
property
to
maintain,
which
means
the
sno
means
that
you
get
to
the
destination.
That
is
most
probably
the
right
one
and
the
fact
that
the
certificate
is
valid.
P
O
Or
it's
Google,
so
I
have
no
opinion
on
Yale
on
using
a
LPN
for
this
versus
using
an
extension.
But
I
just
want
to
reiterate
that
it
would
be
relatively
straightforward
to
render
this
strongly
immune
to
any
accidental
usage
in
the
a
LPN
mode.
And
if
you
don't
think
that
it's
good
enough
to
offer
acne
TLS,
0
and
acne
TLS
1
and
require
0
not
to
be
not
to
be
returned
with
higher,
require
1
to
be
returned
and
you
can
do
fancier.
Things
like
like
make.
O
Q
See
how
this
works
push
the
right
button.
Okay,
let's
see
here,
we
go
okay,
sir
an
ACME-
and
I
think
we've
talked
about
this
before,
but
people
that
don't
do
RT
stuff.
Well,
basically,
what
we're
trying
to
do
and
it's
something
we
tried
to
do
how
long
ago,
seventeen
years
ago
we
tried
ok,
sorry,
we
tried
to
solve
this
problem
about
17
years
ago
and
support
working
group
and
now
we're
finally
really
trying
to
solve
it,
because
it's
become
a
huge
problem.
Q
Q
Ok,
what
we're
doing
is
we're
based
on
we're
using
eighty
226,
which
talks
about
how
we're
going
to
use
certificates,
so
we
currently
have,
as
was
mentioned
before,
to
Acme
working
group
documents
to
support
stir
when
we
have
the
telephone
one
that
was
focused
on
how
you
do
challenge
responses
for
forty
ends,
and
then
we
had
one
that
came
in
because
of
the
work
we
were
doing
in
Addis
and
an
eye
taskforce
where
we
were
basically
rather
than
than
doing,
TNS
and
certificates
party
ends
we
have
certificates
per
some
service
providers,
identifies
that
we
call
service
provider
codes
and
these
are
existing
things
that
service
providers
use
within
the
network
to
uniquely
identify
them.
Q
So
we
we
had
that
document
both
of
these
were
agreed
as
working
group
documents.
So
where
are
we
now?
So?
When
I
was
discussing
the
service
provider
document
IETF?
Ninety
nine
in
Prague,
the
workgroup
suggested?
Well,
this
looked
like
something
that
could
be
evolved
into
a
generic
token
mechanism,
so
at
ITF,
100
and
John
and
I.
We
talked
a
little
bit,
but
we
kind
of
worked
a
little
independently.
Q
I
had
taken
the
service
writer
document
and
I,
took
it
pretty
literally
and
came
up
with
a
very
simple
token
challenge
response
mechanism,
and
so
that's
the
Barnes
Acme
token
challenge
and
then
there's
the
service
provider
document.
That
explains
how
we'd
use
the
generic
token
mechanism,
and
one
thing
I
want
to
highlight-
is
I,
updated
draft,
Barnes
Acme
token
challenge,
not
because
I'm
suggesting
we
progressed
it
right
now,
but
because
I
had
a
very
overt
error
and
I
can
be
really
OCD
and
pedantic
about
things
and
I
didn't
want
to
leave
that
out.
Q
There
then
John
also
had
a
proposal
that
was
kind
of
applicable
to
a
broader
range
of
applications.
You
know
he
thinks
bigger
picture
and
at
that
ITF
100,
the
workgroup
said
you
know
you
guys
really
should
come
up
with
a
comprar.
You
know
combined
proposal.
So
that's
where
we
are
today
and
John's.
Gonna
talk
about
the
generic
mechanism,
Authority
token
mechanism
and
then
Chris
is
going
to
go
into
the
details
on
how
we're
going
to
use
this
for
both
TNS
and
service
writer
cuts.
Okay,.
R
Hi
I'm
John,
so
Mary
already
gave
the
intro
so
I'm
not
going
to
go
too
much
into
what
ster
is
or
how
we
got
here.
The
basic
idea
again
is
that
we're
going
to
use
the
certificate
authority
we're
gonna,
have
a
proof.
It's
gonna
look
something
like
a
traditional
acne
challenge
and
that
will
result
in
an
acne
client
getting
a
cert
then
that
sir,
can
be
used
to
sign
communications.
R
So
what
we
decided
was
that
the
jock
took
in
that
JSON
web
token,
that
was
being
used
for
the
service
provider
code
proposal
could
probably
be
just
genericized
into
something
that
could
work
for
basically
any
identifier
type.
You
want
to
issue
a
challenge
for,
provided
that
you
believe
there
are
some
authority
out
there.
It
has
a
trust
relationship
with
the
CA
such
that
that
authority
could
generate
one
of
these
jobs.
You
could
then,
when
you
receive
a
challenge
as
an
ethnic
client,
go
off
to
this.
R
There's
this
thing
that's
called
NECA,
that
is,
that
actually
issues
these
Oceanos
that
end
up
being
used
in
the
PSTN
today,
and
so
this
began
to
notion.
Oh,
you
could
go
to
this
authority
token
in
this
instance,
something
that
is
neck
over
adjacent
to
NECA
has
access
to
its
same
database
and
from
that
get
a
token,
you
then
would
present
to
the
CIA
in
order
to
get
your
acne
certificates
for
that
particular
identifier.
R
So
we
just
abstracted
that
out
all
the
way
that
to
the
notion
that
pretty
much
any
identifier
or
identifier
type
you
could
put
into
a
challenge.
Well,
there
should
be
a
way.
You
can
then
identify
a
token
authority
who
is
a
Thorat
ativ
for
that,
and
they
can
give
you
whatever
token
you
need
to
prove
it
to
the
CI.
So
this
could
be
something
could
be
applicable
to
virtually
any
identifier
could
staying
even
domain
names.
You
could
imagine
you
were
actually
going
to
like
networks,
for
example,
and
saying:
okay,
I
have
an
account
with
you.
R
Here's
what
it
showed
me
now,
if
you
can
give
me
a
token
I,
can
then
bring
that
back
to
the
CI,
and
you
don't
even
have
to
do
that
kind
of
dns
proof
that
we
originally
discussed
here
in
Acme.
Obviously
I
think
the
DNS
root
beer
in
Acme
is
fine,
but
things
for
IP
addresses
things
for
any
kind
of
non
Internet
resource
you
imagine
might
want
to
issue
a
certificate
for
could
potentially
fall
under
the
rubric
of
this
authority
token,
and
the
way
that
we
did
this
is
we
just
defined
a
registry
of
these.
R
These
TK
off
types
we
defined
one,
that's
called
a
TC
for
the
authority.
Token
challenge
we
did
this
in
case
like
for
some
reason
somebody
didn't
want
to
do
this
with
Jah
right,
like
we
thought
we'd,
just
like
build
in
one
more
layer
of
indirection
in
case
somebody's,
like
just
utterly
against
everything
that
came
out
of
the
hose,
a
working
group
who
wants
to
use
some
alternative
form
of
token
for
this.
So
we
have
that
layer
of
modularity
in
this,
but
we're
really
only
pre-registering
in
this
document.
R
This
one
option
this
ATC
token,
which,
as
I
said,
is
a
job
the
token
Authority.
There
is
a
URL
that
is
optional.
That
can
tell
you
where
you
need
to
go
to
get
the
kind
of
kind
of
token
that
the
that
the
Boulder
instances
is
is
asking
for
in
this
case
and
that
isn't
mandatory
to
follow.
It
may
be
that
the
client
has
out-of-band
knowledge
of
this,
for
example,
precisely
in
this
Attis
and
in
AI
case
you
already
know
who
the
authority
it
is
that
you
need
to
go
talk
to
you.
R
Imagine
that
is
all
the
basics
T
for
encoding
of
the
JA
inside
of
that
and
based
on
saying
that
you
you
got
your
certificate
for,
for
that
instance,
we've
talked
a
bit
about
this
in
kind
of
a
small
internal
design
team
that
we
formed
based
on
being
told
last
time.
Please
come
back
with
like
one
proposal
instead
of
like
sixteen
ways,
you
might
do
this
so
Chris
and
I,
and
us
also
Mary
and
Dave.
Hancock
talked
a
bit
about
this,
since
Dave
is
doing
some
of
the
work
on
the
other
side.
R
One
thing
we
ran
into
pretty
quickly
the
way
that
I
hacked
this
together,
I
assume
that
we
need
a
way
to
bind
the
challenge
that
you
receive
from
yakhni
server
to
whatever
you
get
back
from
the
token
authority.
So
I
said,
oh
we'll,
just
take
the
nonce
like
from
reply
nonce
and
jam
that
into
the
information
that
we
give
to
the
token
authority,
and
so
that
would
then
end
up
being
put
into
the
the
job
itself
and
based
on
its
presence
there.
Then
you
know
the
the
Acme
server
would
know.
R
Okay,
this
actually
was
response
to
the
challenge
that
I
issued.
This
does
have
some
design
implications
and
there
are
alternatives
to
this.
This
is
kind
of
an
open
issue
for
us,
I.
Think
at
the
moment
you
could
instead
use
a
fingerprint
of
the
Acme
credential.
That
makes
it
clear
that,
yes,
this
is
the
right
Acme
account
for
this.
R
That
is
asking
for
it,
and
so
the
the
the
difference
here
really
being
that
use
of
the
token
is
one
that
say
if
you're
doing
short
short
term
certs
or
something
we
needed
to
go
back
and
get
so
it's
very
frequently
from
the
Acme
server.
Then
it
would
be
beneficial
to
have
a
token
that
was
tied
to
the
fingerprint
of
the
client
rather
than
to
each
individual
challenge.
You
received
right
because
this
dish's
reduces
the
number
of
times
you
need
to
go
and
get
go,
get
more
tokens
from
the
token
Authority.
R
So
this
is
something
that
we're
still
thinking
about.
I
know,
we
talked
a
bit
Richard
Barnes
about
this
I,
don't
know
if,
just
at
this
level
of
discussion
of
the
documentary
we
need
to
delve
into
the
open
issues,
I
mean
I.
Think
really
mostly.
What
we're
here
to
ask
today
is
you
asked
us
to
come
back
with.
Like
one
thing,
we
have
come
back
with
one
thing
and
like
this,
this
is
kind
of
the
consolidated
approach
that
that
we
want
to
take.
Do
people
think
this
is
reasonable
to
have
this?
R
First
of
all,
this
very
generic
token
capability
for
Acme.
If
you
are
there
other
use
cases,
people
are
interested
in
for
this
other
than
the
ones
that
are
related
to
telephone
numbers
that
people
want
to
bring
to
the
table.
The
people
don't
like
this
approach,
think
it
should
be
less
generic,
because
there
are
less
generic
ways
to
do
this.
If
people
are
so
inclined,
so
people
have
like
initial
fundamental
thoughts
about
that.
Yeah.
Q
Mary
bars
I
mean
it
would
be
good
to
hear
from
the
people
and
I.
Don't
remember
exactly
who
it
was
that
that
suggested
that
the
mechanism
I
had
presented
could
be
major.
Narak
right,
I
think
was
me,
oh
no,
there
was
somebody.
No
no.
There
was
somebody
else
in
this
room
right,
okay,
but
but
good
to
understand
your
use
case
for
this
right
or
is
it
just
a
philosophical
thing?
Okay,.
E
Isn't
philosophy
good
enough
yeah,
oh
yeah,
so
I
don't
have
personally
in
a
way.
I
would
put
this
to
use
immediately,
but
it's
something
I
think
could
be
good
for
the
ecosystem
in
a
few
different
ways.
You
know
I've
had
some
conversations
with
registries
about
providing
this
sort
of
things
you
were
talking
about
for
DNS
names
and
I.
E
Think
that
would
be
a
way
to
issue
DNS
certificates
with
a
higher
level
of
assurance
than
what
these
empirical
validations
without
needing
humans
in
the
loop,
so
I
think
having
a
mechanism
on
the
table
it
could
be
readily
adapted,
could
make
those
conversations
easier,
could
make
experiments
easier
and
those
sort
of
things
I
mean
even
Roland
in
the
IP
address
that
mean
you
can
imagine
using
like
rpki
certs
to
do
a
higher
assurance
thing,
which
still
has
some
accuracy
data
quality
issues,
but
we'll
ignore
this
for
a
moment,
so
yeah
I
think
this
in
general.
E
This
approach
is
pointed
in
the
right
direction.
I
think
probably
some
of
these
layers
of
interaction
could
be
collapsed
out
a
little
bit
with
some
assumptions
about
what
the
tokens
will
look
like.
You
know
I
think
I'd.
Probably
me
fine,
saying
JWT,
because
if,
for
some
reason
someone
could
not
possibly
live
in
the
JWT
envelope
like
we'll
just
mince
a
new
means,
a
new
challenge,
type
for
them
yeah,
so
yeah
plus
one
know
this
o
on
the
on
the
how
to
bind
thing.
Yeah.
K
E
Guess
I've
got
us
without
having
thought
about
this
real
deeply
I
think
it
seems
to
me
the
binding
to
the
account
key
is
probably
the
more
natural
thing
given
that
what
the
what
the
token
authority
is
probably
going
to
be
thinking
of
is
who
has
what
resources
not?
Who
has
is
doing
what
transactions
with
which
resources?
And
so
you
know,
without
having
a
concrete
examples
on
hand
about
how
these
tokens
would
be
issued.
E
It
seems
like
the
challenge
based
approach,
the
nonce
based
approach,
kind
of
presumes
that
the
token
issuance
process
can
operate
sufficiently
quickly
to
be
in
band
to
the
issuance
process,
also
true
yeah,
which
is
seems
kind
of
like
kind
of
an
unnecessary
apartment,
once
you're
really
getting
some
valuable
restriction
out
of
it,
as
opposed
to
just
being
in
enabling
the
account
holder
to
go
get
a
token
that
expresses
its
resources
in
general
or
you
know.
However,
he
wants
to
slice
them
up.
Yeah.
R
R
E
K
E
R
E
Q
R
R
Don't
clearly
have
a
broad
sweep
of
use
cases
right
now,
right,
I
mean
I,
I,
think
I
think
if
we
did
one
thing
to
start
and
I
am
sympathetic
to
Richard,
saying
who
probably
just
collapsed
down
the
layer
of
indirection
and
just
have
this
be
job,
and
if
someone
eats
does
something
else
will
do
something
else.
That's
fine.
You
know
doing.
This
was
like
one
thing
that
we
think
is
gonna
work
for
at
least
the
few
use
cases
we
have
in.
T
Chris,
why
not
I
was
just
gonna
agree
with
Richards
thoughts.
I
tend
to
think
that,
although
like,
like
you
I,
think
I'm
flexible,
shut
up,
you
know,
nonce
does
tie
you
to
every
transaction.
Fingerprint
is
a
little
more
flexible
in
terms
of
not
having
to
get
a
token
per.
You
know
if
you
have
tons
of
certificated
requests.
Maybe
that's
one
other
consideration.
You
know
that
you
so.
E
Richard
bronze,
if
we
think
there
is
some
real
uncertainty
about
what
the
right
answer
here
is
and
we're
not
comfortable
just
like
picking
one.
It
would
be
helpful
to
see
some
examples
of
what
the
token
issuance
processes
might
look
like
all
right.
If
whoever
is
issuing
the
TN
tokens
or
OC
n
tokens
or
took
ins,
is
insisting
on
manual
processes
that
involve
like
sending
paperwork
to
FCC,
then
yeah,
we
should
probably
bind
to
accounts
and
not
challenges.
Yeah.
Q
Well,
we
hope
Mary
Barnes
again.
We
hope
it
won't
be
manual
but
yeah,
but
I
just
want
to
mention
right
now.
What
we
have
in
the
shaken
certificate
management
specification
is
the
fingerprint
yep.
T
T
So
you
know
this
is
essentially
the
corresponding
Draft
I
guess
defined
sort
of
as
a
profile
of
the
one.
We
just
talked
about
specific
to
Acme
usage
for
creating
RFC,
82,
twenty-six
certificates,
mister
certificates,
draft
and
specifically
for
providing
an
authenticated
authorized
way
of
indirectly
incorporating
the
TN
awfulest
into
the
certificate,
as
defined
by
our
Piracy
82,
26
and
I.
Think
we
already
talked
about.
This
is
really
specifically
for
cases
of
telephone
service
providers.
So.
T
T
T
For
what
that
authorized
for
what
that
relationship
is,
it
happens
to
be
an
interface
just
to
get
the
token
with
also
with
authentication,
and
then
we
that
authorized
service
will
provide
a
valid
token
back
with
the
TN
auth
list
and
the
fingerprint
cetera
and
then
CSB
responds
the
Acme
challenge,
challenges
validated
and
then
creates
the
bar
C
82
26
complaint
certificate.
That's
the
high
level
process.
E
E
T
E
Q
T
Okay,
so
we
define
a
new
identifier
of
type
TN
off
list.
We
also
define
the
value,
which
is
we
define
it
as
a
JSON
array
of
T
and
all
its
components
and
as
I
just
mentioned,
that
there's
three
types,
SBC
TN
and
TN
range
I-
show
an
example
here
of
a
new
order.
That
includes
that
and
in
this
specific
one
there's
both
an
SPC
and
a
TN
as
part
of
that
down
in
the
identifiers.
Q
E
I
think
that
the
right
answer-
Robin,
someone
probably
from
JSON
mafia-
is
probably
gonna.
Come
nice
to
me
for
saying
this,
but
I
think
the
right
answer
is
probably
to
say
that
the
the
content
of
the
value
field,
it
should
be
specified
by
the
type
field
of
the
identifier,
meaning
when
you
get
an
identifier
object,
it'll
have
a
type
field.
You.
E
You
know
what
type
it
is
and
then
the
value
will
be
in
the
value
field,
but
it
might
be
a
string
or
it
might
be
an
array
or
might
be
whatever
the
type
specifies
it
is.
We
should
work
slightly
more
serious.
We
should
probably
add
some
feedback
from
JSON
folks
as
to
whether
that's
the
right
answer
sure.
Maybe
we
should
do
something
like
something
like
we've
done
with
challenges
where
you
use
names
other
than
value.
Okay,.
R
E
And
in
fact
it
was
occurring
as
I
was
sitting,
you
know,
probably
part
of
defining
and
identifier.
It
needs
to
be.
How
does
this
thing
appear
in
a
certificate
so
that,
because
there's
implicitly
a
mapping
between
these
JSON
objects
talking
about
identifiers
and
how
they
go
into
certs,
that's
kind
of
what
kind
of
Reliance
it's
kind
of
assumed
in
the
case
of
domain
names.
But
it
is
it's
different
here,
because
TN
off
list
is
I
think
it's
an
extension
yeah.
It's
not
not.
S
R
R
T
R
R
T
U
Q
Right
with
our
TN
office,
I
mean,
are
TR
valid,
see
a
list
well.
E
Is
it
seems,
like
there's
sort
of
two
plausible
operating
points
here?
On
the
one
hand,
if
you
want
to
go
the
morass
and
one
route
then
just
generate
the
extension
and
base64
encode
it
and
shove
it
in
as
a
string
no
need
to
change
the
base
spec.
On
the
other
hand,
if
you
want
to
have
something,
that's
more
readable
and
described
in
JSON
that
you
will
then
define
a
mapping
to
yes,
I'm
one,
then
we'll
need
to
change
the
base.
M
So
as
far
as
matthew
Miller,
so
as
far
as
the
mappings
go
there
is,
somebody
has
started
to
define
a
JSON
encoding
rules
for
SM
one
and
please
I,
and
after
looking
at
that,
I,
my
as
man
as
it
as
I
might
be,
with
just
doing
the
the
Tia
Nautilus
encoded.
That
I
mean
ultimately
what
matters
is
what
goes
into
the
certificate
and
what
I
mean
as
far
as
other
processing
of
it.
It's
it
doesn't
seem
to
be
very
relevant.
M
T
V
Russ
Housley
the
CA,
already
knows
how
to
deal
with
a
s
on
one,
obviously
yeah.
So
that's
not
a
big
deal.
I.
Think
John's
point
is
that
if
you
are
translating
back
between
multiple
representations,
you
could
lead
to
someone
making
a
surprising
assumption
somewhere
and
resulting
in
a
identifier.
You
didn't
intend
that's
all
easily
avoided.
If
you
provide
the
the
blob
to
decode
the
blob,
it
makes
sense
or
it
doesn't.
If
it
doesn't,
you
fail.
I
totally
speak
against
using
the
JSON
encoding
rules
and
hey
I
tried
to
read
them
once
I.
R
Concerned
about
this
being
about
the
sn1
being
unintelligible
to
any
of
the
actors
in
this,
then
let's
I
wouldn't
mind
as
a
hint
having
some
conversion.
That
shows
you
what
it
is,
but
the
canonical
representation
has
to
actually
also
be
in
it
right
and
whether
that's
basic,
supporting
or
whatever,
because
otherwise
I
do
think.
If
there's
misunderstandings
about
how
you're
supposed
to
convert
between
these
things,
it.
N
N
Something
is
when
something
has
gone
wrong
and
the
person
who
is
debugging
it
is
going
to
be
reading
a
cert,
that's
it
in
sn1,
and
so,
when
I
think
of
the
mental
leaps
I
think
the
shortest
distance
between
two
points
is
and
I
say
one
backwards:
I,
don't
like
sn1
any
more
than
anybody
else
does
I
I've
written
for
sn1,
compilers
and
I
would
like
to
have
no
new
sn1.
But
this
is
not
new
sn1.
It's
not
spreading
the
infection
any
further,
so
we
don't
need
to
worry.
Let's
just
do
it.
Okay,.
A
M
Well
well,
first,
relaying
well:
hem
I
can't
pronounce
the
last
name.
I'm
apologize,
he
asks
is:
will
the
JSON
encoding
destroy
the
CSR
compliance,
but
for
myself,
I
was
also
going
to
say:
I
regret
ever
mentioning
the
JSON
encoding
rules.
Please
just
put
in,
and
especially
so,
especially
in
I
mean
the
canonicalization
is
a
really
important
one,
and
getting
that
right
in
JSON,
as
I
saw
with
passport,
is
really
effing
hard.
So.
T
R
T
T
T
Have
a
couple
examples
in
here:
I,
don't
know
if
I
need
to
go
through
this,
for
this
crowd,
it's
just
variations
on
whether
there's
a
SPC
value
or
SBC
and
tiens,
or
things
like
that
they're
in
the
draft.
Unless
somebody
has
specific
comments
about
that
next
steps,
so
I
think
we
talked
about
that.
You
know
we
had
two
different
documents.
We
came
in
with
these
new
two
documents.
E
S
E
The
ATC
value
there
is
still
in
JSON
it's.
The
question
is
whether
now
that
we're
going
to
encode,
the
identifiers
in
acne
is
base64,
encoded,
yes
and
one.
Whether
the
token
should
also
use
that
encoding.
That
doesn't
seem
like
a
clear
answer,
because
you
might
have
differences
between
what's
in
here
and
what
you
might
put
in
a
certificate
right.
If
you
yeah.
T
R
R
R
On
so
yeah,
this
is
an
implication
that
perhaps
wasn't
obvious,
which
is
why
he's
bringing
you
out,
but
so
we're.
We
have
t
an
auth
list
there
right,
that's
the
identifier
pipe
that
we're
dealing
with,
and
so
that
then
will
key
that
what
is
going
to
appear-
and
the
second
thing
that's
now,
an
array
there
of
SBC
and
TN
is
instead
going
to
be
the
base
64
encoded
blob
got
it
Russ
says
that
I'm
correct,
so
I'm.
Obviously
right
no
does
that
make
sense,
because
at
the
point
is
so
we're
thinking
about
this.
S
R
K
E
R
R
That
would
be
the
work
will
do
as
we
then
develop
this
right.
I
mean
what
really
was.
What
we're
trying
to
accomplish
here
today
is
just
to
say
you
asked
us
to
come
back
with
one
thing
we
got
one
thing
this
is:
these
are
roughly
the
properties
it'll
provide.
We
don't
need
to
you
know
working
with
us
College
today,
but,
like
you,
see
the
direction
we're
taking
this
and
you
know,
do
people
think
it's
cool
okay,
so.
A
Having
said
that,
if
we
look
at
yeah
this
proposal,
let's
take
a
Hammond.
Does
anybody
just
one
not
two?
Does
anybody
look
at
since
they
know
this
is
not
a
good
idea.
We
should
stay
with
the
way
we
are
yeah.
So
if
you
think
this
yeah,
it
does
have
to
be
a
double
harmony
way.
If
you
think
this
is
a
good
way
forward
to
replace
both
the
both
drafts
with
single
one
hum
now,.
A
T
Yeah
price
to
be
there's,
there's
John's
and
then
mine,
right
tufa
to
Mary.
Q
R
S
S
So
here
is
that
we
think
we
are
done
with
the
edits.
We
remove
the
glass
to
item
from
the
to
the
list,
which
was
which
were
operational
consideration
and
security
consideration
in
particular,
regarding
the
operational
consideration,
we
now
define
what
short
term
means
in
terms
of
the
web
use
case.
We
created
equivalency
with
osseous
beam,
a
staple,
and
so
we
recommend
a
renewal.
S
The
tolerance
so
the
other
recommendation
that
we
always
predating
five
to
seven
days
pending
on
your
use
case,
and
then
we
added
a
third
note
about
us:
the
certificate
transparency
long
after
a
long
discussion
in
Singapore,
I
knocked
my
transcender
and
a
star
said
meeting.
Is
that
the
conclusion
was
it's
not
a
problem?
Probably,
but
if
it
is
a
problem,
then
this
document
doesn't
need
to
solve
so
done.
A
I
Ryan
sleepy
so
I
have
heard
the
draft
I
think
it's
good
for
working
group
last
call,
but
I
am
going
to
throw
out
a
potential
ranch
which,
having
having
looked
through
some
of
the
use
cases
and
scenarios
I,
think
it's
very
unlikely
that
this
would
be
useable
on
the
web.
Pki
yeah
I.
Think
for
you
know
an
enterprise
case.
It
is.
I
It
is
fit
for
task,
but
you
know
I
I
do
want
to
sort
of
potentially
throw
that
out
there
that
for
the
web
PGI
case
for
some
of
its
considerations,
the
comparison
between
OCSP
stapling,
the
the
motivating
cases
here
and
the
ecosystem
challenges
may
not
make
it
suitable.
So
if
it
is
something
that
we
do
want
to
see
on
the
web
PKI,
we
should
probably
talk
about
some
of
the
operational
considerations
and
deployment
considerations
to
figure
out
if,
if
that's
something
addressable
through
the
spec,
but
if
it's
for
enterprise
PKI,
let's
let's
ship
it.
I
Are
what
are
the
blockers?
So
one
of
the
blockers
is
that
CAS
themselves
I
have
strong
opposition
to
soar,
removing
OCSP
information
war
towards
expressing
short-lived
certificates
as
an
equivalent
for
OCS
P.
So
this
is
a
very
fundamental
objection,
all
right,
because
it
gets
to
the
whole
point
of
the
use
case
and
there
have
been
multiple
discussions
in
the
C,
a
browser
forum
for
the
course
of
three
years
now,
and
this
matter
continues
to
be
a
point
of
contention.
I
So
that
is
something
that
you
know
in
looking
through
whether
it
is
through
the
analysis
document
that
is,
you
know,
correlated
to
star
whether
or
not
that
needs
to
be
firmed
up
or
whether
it
is
actually
to
the
protocol
itself.
So
that
is,
is
you
know
one
of
the
core
considerations?
There
is
the
operational
deployment
of
you
know
if
a
server
is
capable
of
deploying
Hackney
star,
then
they're,
equally
capable
of
deploying
OCSP
stapling,
whether
or
not
OCSP
stapling
meets
that
case.
There's
also
from
looking
through
the
sort
of
security
risks
and
considerations.
I
I
A
X
I
mean
from
the
sea-air
browser
point
of
view,
I
think
the
correct
way
of
characterizing
the
the
position
of
the
majority
of
the
CAS
on
short-lived
certificates
is
the
majority
of
them.
Don't
care.
There
are
a
few
that
are
interested
in
issuing
them.
The
last
time
it
came
up,
the
biggest
debate
was
actually
I
forgot,
my
name
I'm
Kim
Halik.
X
The
biggest
debate
was
actually
between
Jeremy
Raleigh
and
me
with
me
actually
being
on
the
opposition
side,
and
the
opposition
was
actually
solely
based
on
not
wanting
to
remove
the
CRL
pointers
from
the
certificates,
even
if
they
were
short-lived.
So
the
actual
discussion
was
not
whether
certificates
should
be
short-lived
or
not,
but
whether
you
should
actually
have
a
crl
pointer
in
them
or
whether
it
was
okay
to
remove
that.
So
that's
where
that
went
I
think
you
know
there
are
a
lot
of
people,
including
us
who
would
like
to
see
widespread
adoption
of
short-lived
certificates.
X
N
Yeah
Phil
Han
Baker
I'm,
no
longer
a
CA
yeah
I'm
on
the
browser
side,
yeah
that
that's
my
feeling
from
Brett
see
a
browser
forum
in
that
there
been
a
lot
of
people
myself
included
who've
been
very
strongly
in
favor
of
short-lived
certs.
However,
before
it
is
practical
to
do
that,
you
have
to
have
a
standard
for
a
certificate
issue
and
automate
the
whole
lifecycle.
N
So
your
document
is
going
to
be
a
precondition
for
changing
things
in
cab
forum,
so
I
wouldn't
make
anything
kept
for
unblocking,
because
we
need
this
draft
and
we
need
to
spec
before
we
can
go
to
cab
forum
on
the
CRLs.
I
think
that
you're
still
going
to
want
crl
distribution
points
in
you're
not
going
to
want
to
you
could
get
rid
of
the
OCSP
piece.
S
R
John
Peterson
not
on
the
web,
PKI
about
on
another
use
case
for
us,
the
ster
thing
we
have
astir
short-lived
document
that
I've
kind
of
been
like
putting
on
the
back
burner
until
May.
The
changes
appreciate
very
much
but
as
part
of
this
of
working
class
call
I'd
be
I'd,
be
happy
to
go
and
try
and
plug
it
in
and
see
if
I
find
any
part
edges
that
are
things
that
might
be
suggestions
from
that.
But
that's
all
I
wanted
to
say
thank
you.
E
Non
normative
non
protocol
text
in
here
that
might
be
distracting
to
people
in
evaluating
its
compliance
against
the
web
Pai.
It
seems
like
the
main
technical
protocol
overlap
was
in
this
question.
Ryan
ranged
about
reissuance
with
the
same
key
pair
same
subject
key
pair,
and
that
that
seems
like
a
little
thing
to
discuss.
It
seems
like
a
good
way
to
flush
out
some.
Whether
there
are
comments
from
my
be
community
is
a
working
group
last
call
so
Phil
and
Tim
and
Ryan.
A
Will
anyway,
so
before
we
go
two
things?
First,
everyone
should
have
signed
the
blue
sheets.
If
you
haven't,
the
blue
sheets
are
right
here,
come
forward
and
have
them
signed,
and
one
other
thing
like
you
to
see
an
email
that
I
got
during
this
meeting.
So
the
bay
document
is
now
in
ITF
last
call
for
four
weeks
right.