►
From YouTube: IETF100-ACME-20171116-1550
Description
ACME meeting session at IETF100
2017/11/16 1550
https://datatracker.ietf.org/meeting/100/proceedings/
A
A
A
The
note
well
has
been
shown,
and
after
this
we
will
do
a
very
very
brief
after
this
we'll
do
a
very,
very
brief
status
update
and
the
email
talk
is
going
to
move
to
the
start,
because
Alexi
has
to
go
to
someplace
else.
That's
problem
with
being
an
ad
I
always
have
to
be
places,
and
afterwards
we'll
try
to
get
the
main
document
finished.
Then
then,
telephony,
star,
Acme,
IP
and
if
x,
remains
open
mike
any
agenda.
Bashing.
B
A
C
D
So,
based
regarding
that
TLS
certificates
for
email
services
based
on
discussion
in
Prague,
are
there
were
three
options
presented
for
to
implement
challenges.
One
was
DNS
one.
One
was
extra
capability
in
SMTP
or
IMAP,
and
one
was
TLS
hack,
so
I
think,
based
on
discussion,
the
cheerless
one
was
removed,
I.
D
D
I'm,
after
adding
comments
to
the
document
and
sort
of
talking
to
myself
in
the
document,
adding
comments
and
removing
them,
I
decided
that
port
is
probably
required
in
the
challenge,
so
both
service
name
and
the
port
are
required.
So
in
theory
that
allows
to
get
to
make
you
know
to
get
the
certificate
for
like
a
70,
P
or
IMAP
server
running
on
non-standard
port
as
well,
and
then
you
know
general
I
fixing,
typos
setting
references
etc.
So.
D
D
D
D
Then
the
other
question
is
for
services
like
IMAP
they're,
typically
running
on
a
couple
of
ports.
One
is
native
TLS
port
and
another
one
is
where
you
start
and
then
usually
start
your
last
command
and
upgrade
to
tell
us
if
available
so
in
theory,
the
same
certificate
can
be
use
for
both,
but
they
actually
different
port
numbers
and
different
service
names.
So
probably
you
cannot
get
the
same
certificate
for
both
in
one
go.
F
D
G
Same
point,
this
does
not
really
seem
like
an
acne
issue.
You
know
as
long
as
these
certificates
you're
issuing
are
agnostic
as
to
the
port
number
that
it
seems
like
in
principle.
It
should
be
fine,
it's
only
if
you
were
using
something
like
an
SRV
name,
where
you're
specifying
the
port
number
in
the
in
the
certificate
brain.
H
D
G
I
D
D
A
sim
similar
vein
L
MTP
service,
which
is
sort
of
a
variant
of
SMTP
for
final
delivery.
Again
some
of
them
are
public
facing,
so
they
they
might
need.
I
might
I
might
as
well
support
them
as
well,
but
for
this
LM
TP
doesn't
have
a
standard
registered
port
number
and
it
doesn't
even
have
the
name
registered.
So
I
probably
should
do
that
anyway.
J
D
D
J
Want
someone
spinning
up
a
you
know:
the
ability
to
run
a
TCP
server
on
my
machine
on
port
5000
is
not
necessarily
a
good
indication
that
the
person
controls
the
machine.
So
you
definitely
want
to
have
some
text
around
around
this
and
and
maybe
even
strongly
recommend
that
there
be
some
policy
at
the
CA.
That
says
if
the
port
number
is
something
other
than
the
ones
we've
identified
here,
then
it's
probably
not
a
good
idea
to
accept
this
okay,
because
we
did
the
same
thing
for
HTTP
right.
G
D
D
Think
we
really
need
to
flesh
out
the
exact
mechanism,
how
the
message
is
going
to
look
like
and
what
to
do
here,
but
major
changes,
because
in
curdled
and
in
lamps
and
curdled
we
are
updating,
crypto
and
adding
internationalized
email
addresses
to
certificates
and
stuff
like
that.
I
might
as
well
allow
for
them
here
so
that
we
have
just
a
single
email
identity
that
can
be
both
internationalized
or
not.
A.
D
G
I
John
Levine,
yes,
just
being
able
to
mean
if
being
able
to
receive
mail
is
adequate.
I
can
get
an
act
piece.
I
can
get
an
s.
Why
I'm
certificate
for
any
IETF
mailing
this,
which
is
probably
a
bad
idea
since
it
as
a
public
IMAP
server.
On
the
other
hand,
there
is
no
way
to
verify.
There's
someone
can
send
mail
from
an
address.
I
mean
I.
I
Could
I
can
put,
the
I
can
put,
the
I
can
put
I
can
put
a
name
on
the
from
line
and
you
can
sort
of
wave
your
hands
about
about
SPF
and
DKIM
and
domain
names.
But
but
you
know
yeah
beyond
beyond
a
certain
point.
You
just
have
to
say:
well,
maybe
close,
maybe
close
enough
so
I.
This
is
not
a
problem
we
can
solve
technically,
but
it's
definitely
a
security
consideration
that
there's
a
certain
amount
of
a
certain
amount
of
spoofing
of
identities
for
mechanically
verified
certificates
is
unavoidable.
Right.
K
Here
at
the
nakajima
from
there
Cory
I
think
it's
the
same
point
that
so
that
we
can.
We
can
make
sure
that,
if
the
risk
that,
if
we
sent
that
verification
email
to
this
receiver-
and
we
can
verify
that
that
he
or
she
has
that
email
address,
but
for
sending,
we
need
to
make
sure
that
there
we
need
to
make
sure
that
he
or
she
has
certain
images.
So
we
need
to
use
other
technology
like
not
to
spoof
the
email
address
so
like
email
course
also,
technology
should
be
called
mentioned
in
the
draft.
I.
G
G
The
the
other
one
last
observation,
I
would
add,
is
that
I'm
looking
at
John
Peterson
here,
because
it
seems
like
this
is
there's
probably
some
overlap
between
this
and
the
empirical
telephone
number
verification
case.
I,
don't
know
like
on
the
send
receive
both
spectrum
if
they
align
that
you
know,
if
they're
sufficiently
similar
to
merit
similar
mechanisms,
but.
L
Yeah
I
mean
so
John
Peterson
returned
drought,
ability,
tests,
various
kinds
been
used
right
to
issue
credentials
for
some
time,
I
mean,
if
anything,
we're
stealing
that
from
practices
has
been
around
an
email
forever
right.
Exactly
I
mean
we
have
the
benefit
in
the
telephone
case
that
especially
for
smart
endpoints,
there
can
be
some
other
indications
right
that
you
can
corroborate
it
with
to
strengthen
it
like
if
you've
got
cryptography
in
the
sim
right
card
of
your
phone.
Maybe
some
of
that
can
contribute
identifiers
that
are
specific
to
the
network.
L
You
can
kind
of
interrogate
the
network
and
get
access
to
it.
Ask
about
where
I
am
the
eyes
are,
and
things
like
that,
but
I
mean
if
what
you're
afraid
to
richer's,
potentially
like
kind
of
genera
sizing
this
a
bit
and
defining
a
profile
that
you
think
encompasses
both
those
return
route
ability
tests
for
this
and
then
and
then
for
that
I'd
certainly
be
willing
to
work
with
that
with
you
on
that
Alexei.
If
you
are
interested
sure.
A
M
A
G
All
right
so,
since
the
last
one
I
didn't
do
the
usual,
what
we
did
slide
because
I
figured
you
can
all
look
at
github
yourselves
last
few
remaining
to
do
is
that
we
managed
to
get
the
ad
review
comments
from
Kathleen
address
before
this
Thank
You
Kathleen.
For
those
observations
we
have
a
much
much
longer
gen
art
review
from
DL
Whirley
to
address
I
have
you've
seen
some
traffic
analyst
hasn't
gotten
to
that.
That's
just
back
in
the
queue
I
figured.
G
G
So
the
issue
we've
had
here
so
we've
had
this
new
order
flow
for
a
while,
where
you
send,
in
a
new
order,
request
to
request
issuance
you
that
provides
you
some
authorizations
from
the
CA
that
the
CA
wants
you
to
fulfill
before
I
delicious
certificates.
So
the
client
goes
off
and
fulfills
those
authorizations
and
it
comes
back
to
that
order,
objects
and
asks
for
the
certificate
and
just
downloads
it
with
the
get
request.
G
So
there's
a
question
in
this
flow
as
to
where
we're
in
this
flow,
it
is
appropriate
to
send
the
CSR
and
I
put
an
asterisk
there
to
say,
logically
it's
a
CSR,
it
might
be
a
list
of
JSON
object.
That
represents
the
stuff
that
is
logically
in
the
CSR
might
be
some
additional
fields
that
we've
got
to
go
alongside
the
CSR,
but
you've,
probably
the
stuff.
That
is
innocent
requests
for
a
certificate.
G
So
there
are
some
cases
where
you
want
CSR
information
at
the
beginning
of
this
process,
as
we
have
it
today.
So,
as
things
are
in
the
document
today,
you
send
in
the
CSR
and
any
associated
data
at
the
beginning
of
the
process,
so
that
the
CA
can
look
at
this
and
provide
as
to
what
you
need
to
do.
What
proof
you
need
to
provide
before
the
certificate
will
be
issued
and
that
that's
something
we
don't
want
to
lose
in
this
editing.
G
There's
there's
kind
of
a
second
order
issue
here
that
the
let's
encrypt
guys
observed
it
there's
also
this
question
of
the
the
last
step
where
the
client
comes
and
gets
the
certificate.
The
document
right
now
says
the
CA
should
proactively
issue
so
like
once,
the
last
authorization
gets
proved
go
ahead
and
issue
at
that
moment,
and
they
observe
that
you
know
they
have
some
cases
where
people
do
all
the
authorizations
and
then
never
ask
for
their
certificate,
and
they
don't
want
to
spend
the
signing
energy.
G
You
know
the
jewels
to
issue
a
certificate
if
no
one's
ever
going
to
ask
for
it
and
there's
been
some
debate
on
the
list
as
to
whether
that
can
be
addressed
with
by
kind
of
being
a
little
more
relaxed
in
how
proactive
the
SIA
has
to
be
Jacob.
I
think
that's
all
I've
got
on
the
summary.
So
Jacob
you
have
a
comment.
N
Yeah
I
just
wanted
to
clarify
the
reasoning
on
asking
for
that:
finalize
change,
it's
less
about
abandon
cert
flows
and
more
about
because
this
n
by
M
problem
involving
every
order,
can
have
a
bunch
of
authorizations
on
it,
and
every
authorization
can
be
a
member
of
a
bunch
of
orders.
And
so
you
wind
up
having
to
check
a
really
large
number
of
objects,
but
are
the
authorization
that
gets
done
potentially.
So
this
kind
of
smoothes
out
the
amount
of
work
you
can't
really
done
fairly
finished
authorization,
they're.
G
So
right
so
highlight
kind
of
all
the
solutions
here,
we're
talking
about
have
kind
of
the
same
general
flow
you
send
in
the
CSR
kind
of
all
did
on
the
on
last.
Let
you
send
in
the
CSR
you
get
it.
The
server
sends
back
information
to
the
client
about
what
the
client
needs
to
do,
to
prove
authority
to
get
this
certificate.
G
Client
cuz
we're
out
and
do
some
work
to
prove
it
has
that
authority,
and
then
the
the
question
we've
got
here
before
us
today
is
whether
you
send
this,
whether
you
always
do
the
second
step,
where
you
send
the
CSR
back
in
and
of
course,
at
the
end,
you
you
get
the
certificate
from
the
certificate
URL.
So
the
two
basic
approaches
we've
got
here
are
one
with
the
with
a
pull
request
that
Daniel
submitted
and
one
that
I
wrote
up
a
couple
days
ago
on
the
left
hand
side
of
the
screen.
G
The
proposal
is,
you
always
do
the
same
flow,
so
in
the
language
of
the
last
slide,
you
always
do
step
four
there's
always
a
second
CSR
submission,
even
if
a
CA
has
already
cashed
that
the
CSR
from
the
first
request-
and
it
is
ready
to
use
that
again
so
this
this
has
the
benefit
that
you
know.
You
always
do
the
same
thing.
There's
no
branch
in
your
code,
depending
on
whether
the
CA
is
going
to
cash,
this
thing
or
not
cash,
the
thing,
so
it's
simpler
from
that.
G
C
O
It
depends
on
exactly
how
you
handle
the
second
request
right.
So
one
version
of
this
is
you
handle
the
second
request
as
if
it
were
done
over
a
request
and
just
look
up
to
see
if
it
has
a
rent
versus
issue,
and
then
you
don't
need
to
compare
them
because
you
don't
care.
What's
the
first
one
was
just
hinting
and
the
only
the
second
one
matters
right,
so
so
I
mean
that's
like
that's
what
you
do
for.
Let
me
know
like
listen.
O
Let's
talk
about,
let's
talk
about
the
second
issuance
right,
we're
on
you
know,
you'd
so
say
for
the
sake
of
argument
that
I
go
and
I've
issue
a
CSR
for
a
B
and
C
right
and
then
and
and
I,
do
all
the
nonsense.
You
want
me
to
do
to
issue
and
Alice,
and
now
you
have
those
positions
on
that
account
and
now
I
come
back
with
another
CSR
for
a
B
and
C.
You
know
you
can
fulfil
that
right
away.
You
don't
need
an
you,
don't
need
a
new,
a
new
check.
O
O
G
So
I
mean
another
way,
so
I
didn't
get
around
to
describing
the
right
hand
side,
but
basically
you
know
the
the
right
hand.
Side
is:
don't
we
define
a
separate?
You
know
some
sort
of
switch.
The
client
uses
to
decide
whether
to
do
the
second
transmission
and
the
another
way
you
can
view
this
dichotomy.
Here
is
whether
or
not
we
view
the
first
and
second
requests
as
part
of
the
same
flow
or
whether
we
view
them
as
decoupled
things.
G
So
the
the
deep
more
decoupled
case
that
Acker
was
mentioning
just
now.
This
has
the
benefit
that
you
know.
Things
are,
as
only
you
only
spend
as
much
caching
and
it
own
as
much
bandwidth
as
you
need
to
for
a
given
CA
in
a
given
transaction.
You
know
cash
of
CSR
if
you
don't
need
to
cache
the
CSR,
and
as
echo
has
mentioned,
you
get
kind
of
this
decoupling
where
you
can
explicit.
G
There's
there's
no
coupling
between
there
doesn't
need
to
be
any
coupling
between
the
first
and
second
requests,
and
so
you
can
have
a
slightly
simpler
logic
on
the
server
by
just
considering
each
request
on
its
own
without
having
to
bind
sequence
of
requests
together.
The
cost
is
that
the
thing
the
logic
on
the
client
is
a
little
bit
more
complicated
because
that's
it
has
to
switch,
but
the
two
cases
yeah
Jonathan.
M
If
you're
I
guess
at
least
the
necker's
model,
where
you
only
paid
it
to
the
second
one,
even
is
the
first
one.
Just
I
want
to
make
a
I
want
to
request.
It
looks
kind
of
like
this,
but
you
know
if
it's
entirely.
If
it's
different
later,
don't
worry
about
it,
I
mean
you
can
sort
of
have
just
like
a
dummy
that
doesn't
have
any
actual
crypto
editor
so
well,.
G
So
one
of
one
of
the
use
cases
for
getting
the
CSR
up
front
is
that
there
are
some
legacy
api's
that
you
might
have
behind
I'll
in
acne
interface
that
require
the
CSR
at
the
beginning
of
the
process,
and
in
that
case
they
would
really
require
that
the
second
CSR
be
the
same,
because
the
backend
has
done
everything.
It's
done
premise
on
the
CSR.
You
sent
the
first
time
yeah.
So
this
is
really
the
only
question
I
had
for
the
working
group
is
which
of
these
approaches.
G
N
So
I
strongly
before
the
former
or
I
should
say
I
strongly
district
or
the
latter.
The
main
reason
being
you
know,
I
want
to
avoid
things
that
this
protocol,
where,
like
one
CA,
does
something
this
way
and
another
CA
does
something
that
way,
because
we're
very
likely
to
wind
up
with
a
proliferation
of
clients
that
only
implement
the
one
thing,
and
then
we
don't
have
an
interoperable
system
so,
rather
than
adding
options
for
you
do
it.
However,
you
want
I'd
like
to
pay
with
a
relatively
simple,
straightforward.
O
Mean
that
isn't
a
crazy
concern,
but
that's
what
interrupts
testing
is
for
and
I
think
actually
having
a
perfectly
sensible
protocol.
Hygiene
is
more
important
and
I
and
and
as
I
said
in
my
email,
I
don't
understand
in
the
I,
don't
understand
in
the
first
one
like
what
my
requirements
are
for
the
CSR
and
what
had
it
had
a
reason
about
I,
don't
reason
about
the
multiple
CSRs
and
there's
a
courier
requirements
on
them.
You.
G
O
N
Think
they
necessarily
do
I
think
we
could
also
to
say
you
know
these
are
guaranteed.
You
know
like
he
said
this
is
the
hip.
You
know
this
is
how
we
choose
to
generate
the
set
of
identifiers
and
the
first
of
all
be
thrown
away
and
final
one
will
be
ignored.
It
seems
like
the
second
one.
Here
is
a
response
to
ambiguity
there,
but
I'm,
not
I,
guess
I,
don't
see
the
issue
with
either
case
either
requiring
that
they
be
the
same
or
specifically
saying
that
the
first
one
is
ignored.
There's
both
seem
to
work,
I.
N
O
The
protocol
is
to
take
a
position
on
that.
That's
what
security
protocol
on
so
like
I
mean
I.
Guess
the
fact
that
you're
telling
me
the
you
don't
seem
to
know
the
internet
question
actually
is
quite
concerning
to
me
because
either
like
either
it's
okay,
if
they're
different,
in
which
case
the
hashes
unnecessary
or
it's
not.
Ok,
if
they're
different,
in
which
case
the
hash,
is
obviously
necessary,
and
we
gotta
be
able
to
answer
that
question
right.
N
So
I
can
I
can
tell
you
for
our
setup
and
policy.
It's
okay,
if
they're
different
and
the
hash
of
necessary
I
propose
the
hash.
Mainly
because
my
assumption
would
you
comment
on
the
list.
Was
you
wanted
them
to
be
I
gonna
call
it
thought
was
way
to
solve
it,
but
if
you
don't
feel
like
they
need
to
identical
I,
don't
either
yeah.
G
L
G
B
O
Okay
I
mean
but
again
they've
been
the
protocol
house
will
say
if
that
to
be
the
same
or
not
because
otherwise,
you'll
have
on
our
mobile
clients,
though
I
mean,
like
I,
mean
Michael.
My
complaint
is
this
great
opportunity
for
screwing
things
up
in
a
bunch
of
different
ways:
okay,.
N
G
Think
the
way
you
would
the
way
I
would
be
inclined
to
state.
This
is
to
say
whatever
checks
a
CA
does
on
an
issuance
request
have
to
be
done.
With
regard
to
the
final,
the
CSR
sent
the
second
in
the
second
request,
but
I
guess
I
realize
you
could
do
that
up
front
by
requiring
that
second
request
be
the
same
as
wellness.
O
But
no
I,
don't
that
works
because
exactly
the
point
chicken
was
raising
earlier
been
around
for
Cody,
like
my
understanding
is
you
were
saying,
my
understand
is
the
reason
we
were
in
this
soup
is
there
are
some
CAS
with
either
thing
up
front,
which
means
they
must
intend
to
issue
off
that
thing
and
so
and
so
therefore,
that's
true,
they
just
check
out
that
thing
and
therefore,
if
that's
true,
they
must
be
the
same
and
and
so
like
my,
this
is
something
okay,
so
they
have
to
be
the
same.
O
The
client
has
to
retire
them
at
Jimmy's.
The
server
has
to
check
because
ER
doesn't
check,
then
we
maybe
I
mean,
and
we
don't
wait
there.
What's
our
reason,
I
mean
our
reasoning
is
that
you
know
it
may
not
be
that
if
they're
required
to
be
the
same,
that
the
server
has
to
rely
on
the
mean
the
same,
which
means
that
serves
that
chat
that
to
be
the
same
or
have
problems,
and
so
now
we
have
an
opportunity
of
like
a
covert
error
or
the
circle
right
diminished.
O
G
J
Come
on
Thomson
I,
this
suggestion
that
we
need
CSR
at
the
beginning
of
the
order
flow
as
well
as
at
the
end,
is
what
I'd
like
to
push
on
a
little
bit.
What
situations
require
the
CSR
up
front
and
at
the
end,
because
if
it
were,
if
it
were
only
a
problem
at
the
point
of
issuance
that
you
need
the
CSR,
then
you
could
create
the
order
with
a
list
of
identifies
the.
G
J
G
G
O
Think
well,
I
think
it's
happened.
Based
on
this
conversation
is
that
you
decided
to
try
to
take
two
entirely
different
flows
and
unify
them,
and
because
you
don't
want
the
client
doesn't
have
to
know
which
flow
is
in
play
and
like
it
seems
like
either.
You
need
to
see
us
are
out
front
or
II
need
to
see
us
or
later
we
don't
need
them
both
and
like,
and
the
problem
is
the
client
just
doesn't
know
which
one
it
is
right.
I
mean
so
like.
N
I
mean,
like
I,
said
earlier:
I
I
think
only
one
of
those
social
getting
the
blended
I
mean
the
the
issue
with
the
ecosystem.
Today
is
you
know,
there's
about
actually
I
would
guess
50
to
100
a
can
climb
because
awesome,
but
they're
all
essentially
much
encrypt
clients
right
and
they're.
A
lot
of
them
are
likely
to
implement
a
sneaky
to
as
what
simple
fills
it
out
and
we
want
those
clients
to
interact
with
the
other
CA
is
the
ca's
I
haven't
I?
Guess
he
flows
and
meet
the
CSI
of
course.
N
O
Yeah,
like
futures
picker
in
the
past,
I
think
I
I,
guess,
like
the
the
idea,
seems
to
be.
We
should
like
make
all
those
clients
now
check.
You
know
change
in
adopt
some
clunky
flow,
because
we
can't
the
ca's
who
have
the
old
clunky
flow,
can't
change
your
new,
less
clunky
flow,
and
that
doesn't
seem
like
this
is
like
the
wrong
like
this
mission.
Just
we
shouldn't
know
like
war
yep.
N
So
my
ideal
answer
is
actually
what's
in
PR
342,
which
is,
and
we
don't
send
the
PR.
We
don't
simple
CSR.
First
of
all,
we
just
send
the
identifiers
CSR
lasts
from
talking
to
other
CAS.
It
sounds
like
that's
kind
of
a
more
modern
way.
They
tend
to
think
of.
The
CSR
is
just
a
vehicle
for
the
public
treatment.
Once
all
the
other
stuff
is
gone,
I
think
the.
What
we
really
need
to
hear
from
here
is
directly
from
CAS
who
have
an
API.
O
So
it
sounds
to
me
like
you
and
I
prefer
the
same
thing,
which
is
340
so
I
guess
I'd,
like
that.
I'd
like
to
like
really
be
convinced.
O
As
we
remember,
I,
was
early,
be
convinced
that
we
really
need
to
support
the
CSR
front
flow,
as
some
people
will
like
to
that
and
that
we
not
only
mean
to
support
it,
but
that
we
need
to
force
every
client
Universal
just
annoying,
because
because
we
don't
want
to
because
you
don't
want
people
to
like
you
who
are
so
terrified
that
those
clients
will
not
be
willing
to
implement.
The
other
flow
like
that.
That
apparently
CA
is
neat.
P
Rick
Saul's
not
could
we
make
the
error
code
be
generic
so
that
you
know
whenever
you
get
this
error
code
resubmit
with
the
CSR
and
then
say
the
CSR
whenever
submitted
must
be
the
same.
One.
P
L
G
N
N
The
identifiers
you
asked
for
in
the
new
order
342
and
have
a
wild-card
function,
so
in
other
words,
they
are
equivalent
with
DNS
names
if
I'm
in
the
certificate.
So
if
you
want
a
wildcard,
be
sick,
a
wild-card
identifier
in
your
new
order
request
the
current
policy
and,
let's
encrypt,
is
that
that
will
wait
a
single
day
with
a
DNS
challenge.
J
Among
Tom's,
just
to
an
editorial
comment,
I
think
I,
like
342
as
well.
I,
just
noticed
in
there
that,
yes,
you
do
allow
them
to
be
wild
cards,
but
you
don't
actually
define
what
all
matters
and
I
think
a
little
bit
more
precise
and
simply
say
that
each
specific
type
of
identifier
needs
to
identify.
These
would
precisely
define
what
it
means
to
have
an
ID,
a
wild
card
and
the
format
of
it
and
I
think
the
dns
is
really
straightforward.
The
leftmost
label
as
a
start,
but
you
need
to
actually
write
that
down.
Well,.
Q
G
Okay,
so
it
sounded
like
there's
a
fair
bit
of
mass
behind
342
here.
What
I
might
suggest?
Well
ping,
the
folks
I
think
in
your
air
from
missus
tell
me,
has
Ike
the
backends
that
require
the
CSR
up
front,
so
I'll
think
in
serving
you
and
provide
some
feedback.
It
seems
like
kind
of
picking
up
on
that
goes.
Future
is
bigger
than
the
past
point
like
we
might
be
able
to
have
some
small
extension
that
had
some
affordance
but
something
there.
You
have
some
signal
in
the
dictionary
in
the
directory
object.
G
P
As
chair,
but
with
a
bit
of
snark,
instead,
we
called
it
a
change,
type,
respect
message:
I
mean
it
is
an
alligator,
it's
the
exact
same
thing
right
yeah
longer,
but
you
and
then
you
write
the
doctor
and
the
server
has
the
option
to
act
on
whichever
one
it
wants.
So
the
client,
therefore
the
burden
of
making
sure
it's
doing.
The
same
thing
goes
back
to
the
client
I.
R
Just
yeah
probably
has
been
discussing:
is
there
any
difference
in
terms
of
robustness
for
denial
of
service
attacks,
resource
exhaustion,
attack
somebody
launches
a
bunch
of
requests
with
no
intent
of
validating
I.
Think
of
is
sometime.
I
mean
there's
obviously,
time
involved
why
the
validation
is
going
on
is.
G
G
That's
that's
so
that
was
the
concern
that
prompted
this
I
think
in
terms
of
the
the
really
expensive
operation
for
the
server
I.
Think
is
the
validation
operation,
where
you've
got
to
go
out
to
the
internet
and
make
some
HTTP
queries
in
order
to
trigger
that,
the
client
has
to
do
several
HTTP
requests
and
some
crypto
computation.
So
there's
there's
some
cost
to
that.
To
that
imposing
that
cost
on
the
server
has
some
cost
to
the
client.
G
A
A
G
Alts
end
up
paying
off
to
the
legacy
folks
now
and
getting
a
PRT
enough,
I
should
be
able
to
do
like
in
the
next
week
or
two
I
haven't
honestly
looked
all
the
way
through
Dale's
review,
so
I
don't
have
a
little
bit
more,
but
my
sense
is
that
it's
a
little
more
toriel,
so
that
should
hopefully
be
straightforward.
So
I
want
to
say
bye
like
early
December
get
around
the
church.
Is
that
I
believe
the
chairs
are
looking
at
Kathleen.
S
S
Hasn't
even
been
telling
added
yet
right:
well,
the
order
of
events
would
be
a
finished
working
group.
Last
call,
then
it's
typically
the
ad
review
and
that's
been
done,
and
then
it
would
go
to
a
etf
last
call
and
then
a
tell
a
chat.
So
hopefully
we
can
do
this
soon,
because
it'd
be
nice
to
get
this
wrapped
up
with
me
as
opposed
to
having
another
a
'they
have
to
go
through
a
review
and
and
stuff.
So
as
it's
early
as
we
can
get
this,
the
better
yeah.
C
L
Hello
John
Peterson
honestly,
you
know,
probably
both
Mary
and
I
are
presenting
like
the
same
material
right
basically
and
trying
to
pose
the
same
question.
So
I
will
try
to
make
this
cover
both
of
us
as
much
as
we
can,
though
Mary
please
do
get
get
in
interject,
contribute
and
we'll
get
your
slides
next
slide.
L
Just
for
those
of
you
that
have
not
been
tuning
to
this.
We
have
this
crazy
idea
right
that
we're
gonna
try
to
figure
out
a
way
to
like
certify
and
sign
telephone
calls
in
order
to
prevent
the
impersonation
that
is
just
endemic
in
enabling
robocalling.
Wouldn't
that
be
an
amazing
thing
to
be
able
to
do
one
of
the
main
problems
behind
this,
of
course,
is
figuring
out
how
to
get
security
credentials
essential
to
this
down
to
the
devices
that
need
them.
L
Our
good
friends
here
at
the
ITF
suggested,
maybe
acne,
would
be
able
to
help
with
that
and
so
over
in
the
store
working
group
we've
been
working
on
this.
We
already
have
a
certificate
profile
for
that
which
we've
articulated
pretty
well.
We
have
some
extensions
to
the
typical
x5o
known
profile
for
this.
L
That
are
specific
to
the
use
cases
we're
considering
there
there's
kind
of
two
branches
of
it,
one
that
concerns
what
we're
calling
service
provider
codes,
and
these
are
codes
that
are
kind
of
like
internal
code
points,
the
telephone
network,
what
you
use
to
identify
like
that
you're,
a
carrier
that
you're
legit
in
the
the
PSTN
as
we
call
it
and
then
a
second
profile.
That's
focused
on
telephone
numbers
in
particular
in
being
able
to
issue
credentials
that
are,
you
know,
would
let
even
an
end
user
potentially
have
like
a
certificate
for
their
telephone
number.
L
That
would
be
very
difficult
to
administer
and
manage
whoever
without
something
like
an
ACME
infrastructure,
which
is
why
we
are
here
next
slide
this,
if
you
don't
know
anything
about
stirrers
kind
of
what
it
looks
like,
we
assume
there's
a
logical
authority.
We
assume
that
there
are
these
kind
of
endpoints,
like
you
know,
clients
and
the
telephone
network.
In
some
cases,
those
these
are
endpoints
might
be
IP
enabled
that
might
be
speaking
speaking,
sip,
natively
and
other
cases.
They
might
be
connecting
up
some
kind
of
intermediary
that
that
is
doing
this
over
IP
I.
L
Keep
hearing
actually
like
a
lot
of
the
telephone
network
is
now
really
IP.
It's
something
you
know.
You
probably
know
better
than
me
heading.
It's
like
some
people
say
like
50
percent
or
something
even
if
like
landline
call
are
getting
to
there,
but
all
of
the
cellular
network
and
things
like
that.
Moving
towards
ulti
lots
of
IP
around
that,
so
we'll
see
more
end-to-end
IP
through
it,
but
some
of
it
is
still
largely
intermediated.
L
T
L
If
you
like,
you're
pretty
loud
in
the
room,
okay,
so
a
little
squeaky,
okay,
that's
better
good!
So
yeah
we
started
looking
at
acne
through
a
stir
lens.
Imagine
hey!
We
could
add
these
certificate
authorities.
There
could
be
some
kinds
of
challenges
and
proofs
that
we
would
perform
for
acne
clients,
and
these
clients
would
then
be
able
to
provision
down.
These
credentials
sounds
fantastic
next
slide,
so,
but
then
we
get
down
to
what
are
the
conditions.
L
We're
gonna
use
for
these
challenges
in
these
proofs,
and
this
is
where
we
have
some
interesting
things
to
discuss
here
today.
We
need
some
input
from
the
group
on
kind
of
what
the
way
for
it
is
for
this,
as
Alexi
was
alluding
to.
Obviously
there
are
return,
rideability
mechanisms
that
seem
interesting
for
this,
especially
for
the
telephone
number
case.
I
can
imagine
again
something
simple
like
an
SMS
challenge
right,
provided
that
it
was
reinforced
with
something
a
bit
meteor
because
of
course,
SMS
has
all
these
these
potential
vulnerabilities
as
well.
L
So
you
want
to
make
sure
that
you
have,
among
other
things,
repeated
tests
to
make
sure
you
retain
control
of
the
number,
but
also
some
kind
of
a
secondary
factor,
whether
it's
the
network
telling
you
that
this
is
a
proper
registration
or
something
similar
that
ideally,
you
got
that
to
work.
That
basic
idea
is
in
the
documents
called
draft
ITF
Acme
telephone
and
we're
still
kind
of
fleshing
it
out.
L
This
is
all
relatively
preliminary
at
this
point
in
part,
because
we
want
to
talk
about
some
of
these
approaches
and
get
a
sense
from
the
room
here
of
what
what
people
think
we
should
do.
The
alternative
is
some
kind
of
a
top-down
attestation.
Obviously
there
are
authorities
to
issue
telephone
numbers.
Today
you
get
your
telephone
number
from
a
carrier.
I
know
there
are
use
cases.
L
Carriers
are
interested
in
where
they
could
delegate
some
of
that
authority
for
a
telephone
number
down
to
say
an
enterprise
that
is
a
customer
of
theirs
and
they
want
them
to
be
able
to
have
a
credential
they
could
use
to
sign
for
these
cause.
A
lot
of
enterprises
are
using
IP
telephony
today,
but
how
will
you
really
do
that
and
in
Mary's
service
provider
draft
draft
ITF
Acme
a
service
provider?
L
She
proposed
some
token,
basically
that
you
would
go
out
and
acquire
from
an
authority
for
the
specific
case
of
these,
these
s,
pcs,
these
service
provider
codes
that
we
have
in
the
store
certs
document-
and
you
know
these
service
writer
codes
in
North
America.
There
are
things
we
call
them.
Oc
ends
they're
issued
by
a
particular
Authority.
You
kind
of
go
to
this
entity
there
or
the
person
who
decides
who
gets
to
have
which
of
these
kind
of
four
digit
codes,
and
so
the
thinking
and
the
Acne
service
rider
draft
was
great.
L
There
should
be
a
way
that
you
can
kind
of
get
a
token
from
someone
who
is
at
least
connected
to
that
chain
of
authority,
and
it's
it's
a
bit
complex
how
this
is
working
out
like
implementation.
Why
is
in
North
America
there
is
this
notion
there
will
be
a
policy
administrator
that
will
be
connected
then
to
this
entity
that
is
actually
responsible
for
issuing
these.
These
SPC's,
but
I
mean
that
that
complexity
aside,
it's
not
so
salient
to
how
we
implement
this
here.
L
L
So
this
this
got
me
thinking
because
again,
I
was
looking
at
this
okay
there's
this
one
use
case
right
where
you're
a
carrier
and
you're
getting
these
these
service
provider
codes
and
you're
going
to
this
Authority.
For
that,
then
there's
this
use
case
or
like
you're,
an
enterprise
and
you're,
going
to
your
carrier
to
get
a
token
from
them
potentially
and
then
bring
that
to
the
CI.
L
Surely
like
there
just
must
be
a
need
in
Acme
for
some
generic
mechanism
that
basically,
where
an
Acme
server
has
some
pretty
existing
trust
relationship
with
an
authority
of
this
kind.
The
Acme
server
can
challenge
you
and
say:
look
you
need
to
go
get
a
token
from
this
entity.
That
I
know
controls
this
namespace
and
if
they
think
that
you're
legit
and
they
give
you
back
something
cryptographically
sign
I'll,
give
you
your
cert
and,
like
you
know,
when
I
started
thinking
about
them
like
there
could
probably
be
all
kinds
of
use
cases
for
that.
L
L
This
is
a
straw
man
and
like
I'm,
good
don't-don't-don't
critique
my
where
my
brackets
are
or
anything,
and
this
is
just
to
convey
the
general
idea
that
we'd
have
a
type
that's
for
this.
This
token.
For
this
generic
token,
it
would
have
some
subtyping
in
it.
You
would
have
a
token
type
that
token
type
would
be
governed
by
some
kind
of
registry,
because
different
authorities
might
require
you
to
get
different
tokens.
Some
might
want
to
do
OAuth.
L
Some
might
want
to
you
JA
somebody
wants
to
Kerberos
I,
don't
know
write
whatever
it
is
that
you
need
to
do
to
go.
Get
a
token.
This
thing
tells
you
the
kind
of
token
you
need
to
go,
get
and
even
proposes
you
know
if
you
need
it
as
a
hint.
Here's
a
URL
of
a
place.
You
know
who
the
authority
is,
and
if
you
go
to
that
website,
this
is
probably
where
you
can
navigate
this
and
get
and
get
what
you
need.
L
Then
that's
probably
would
be
optional,
but
the
token
type
would
be
required.
So,
for
example,
we
would
have
a
TN
auth
list
thing
to
get
for
spc
a
separate
one
to
get
for
telephone
numbers,
a
separate
one
for
EZ
Pass
and
those
would
be
the
types
that
would
fill
up
that
I
in
a
registry
next
slide
so
I
know
Mary.
L
Let's
talk
about
this
as
well,
and
I
mean
I,
don't
make
any
decisions
about
anything
until
you
hear
what
she
has
to
say,
she
has
a
draft
that
approaches
this
slightly
differently
and
I
kind
of
I
think
the
discussion
we
want
to
have
is
kind
of
what
approaches
for
this
seem
like
tractable
and
useful
ones
for
the
group.
But
if
people
think
this
is
a
good
idea,
I
think
we
should
do
something.
L
Generic
like
this
very
similar
to
what
the
conversation
is
with
with
Alexi
right,
where,
if
there
seems
to
be
a
general
need
for
like
a
return
route
ability
as
a
kind
of
challenge
that
we're
interested
in
let's
build
systems
that,
let
you
you
know
extended
and
subtype
it
for
the
kinds
of
use
cases,
people
might
be
interested
in
res.
Did
you
want
something
before
Mary
talk,
sir
yeah.
U
L
Know
I
just
suggested
that
there's
some
pre
Association
okay,
so
again,
it's
probably
you'll
get
a
challenge
right
and
then
that'll
that'll
tell
you
which
I
thought
you
need
to
go
talk
to.
If
you
didn't
already
know,
and
in
some
for
some
use
cases,
you'll
probably
already
know
who
you
need
to
talk
to:
okay,
Mary,
you're,.
F
T
T
T
That's
fine
because
I
don't
see
slides,
but
I've
got
my
PowerPoint
up,
so
I'm
gonna
run
through
it,
okay,
so
the
feedback
at
last
idea
that
we
should
have
a
more
generic
token
now,
that's
mechanism
that
we
could
use
it
for
served
by
service
provider,
codes
and
John
talked
about
that
a
little
bit
and
again,
John
talked
about
his
proposal
at
this
point.
I'm
not
I,
didn't
make
any
changes
to
the
onesearch
document,
because,
obviously
we
need
to
agree
the
approach.
Okay
next
slide
right,
and
so
what
I
did
you.
A
L
T
T
Okay,
I'm,
assuming
y'all,
can
still
hear
me
okay,
so
what
I
did
yesterday
was
dark
and
it
was
add
feedback
that
we
got
specifically
on
that
just
a
couple
things
so
hopefully
y'all
can
hear
me
I'm
here
back.
There
annoys
me,
I'll
just
keep
talking
and
then
John
can
walk
over
me
later.
Okay,
so
I
added
text
about
the
lifetime
of
the
service
writer
covered
in
just
change.
We
had
this
subfield
to
be
a
array
of
strings
rather
than
a
string.
T
T
K
L
So
yeah
I
mean
I
I,
so
I
think
the
original
acnes
service
provider
draft
right
was
very
specific
to
the
SPC
use
case
no
species
likes
are
these
like
4G
chip
codes,
basically,
and
so
yeah
last
time
actually
attacked
me
I
said
we
need
to
figure
out
a
way
to
make
this
more
generic,
so
I
think
the
proposal
that
Mary
was
looking
at
was
to
then
create
to
migrate
away
from
SPC
and
into
a
generic
entity
code.
The
NDA
code.
There
pretty
much
has
the
same
syntax
as
the
SPC
does.
The
notion.
L
And
again,
if
you
forgive
me,
if
I'm
not
getting
it
quite
right,
this
is
this
is
my
understanding
of
it.
The
the
entity
code
is,
it
uses
the
same
syntax
effectively
that
the
original
SPC
did
under
the
notion
that
pretty
much
any
generic
authority
that
you'd
be
talking
to
would
have
some
identifiers
for
you
right
and
that
would
kind
of
tell
them
the
CA
what
kind
of
credential
they
needed
to
give
you
Chris.
Do
you
think
that's
fair
for
you?
You
can
speed
this
to
your
you're
working
on
this
and
so
I.
L
Think
that's
the
distinction
or
the
one
that
we're
interested
in
discussing
is
how
generic
we
want
this
to
be
and
exactly
where
we
kind
of
put
in
the
extensibility.
That
tells
you
what
kind
of
credential
is
ultimately
going
to
be
issued,
and
so
I'm
kind
of
arguing,
I
guess
for
a
model
where
we
use
subtyping,
where
we
use
an
a
registry
that
is
going
to
specify
how
these
tokens
work
in
particular
and
I.
U
Provider
is
really
corresponds
to
the
shaken
stuff
that
we've
done
in
the
ster
domain
in
terms
of
the
service
provider.
Could
the
question
is
you
know
with
that
document
now
refer
to
this
other
doctor
and
what
is
the
generic
mechanism
that
we
come
up
with
and
I?
Think
if
I
were
to
do
you
want
to
go
to
the
next
slide.
U
H
T
So
I
mean
I
didn't
get
to
talk
about
it,
but
so
the
separation
I
had
two
other
documents.
Right,
one
is
intended
to
be
generic
right
and,
and
there
might
be
a
typo
in
there
where
I
forgot
to
change
service
provider
codes
so
effectively.
What
I
took
the
other
document
and
broke
it
out
right.
So
the
one
mechanism
is
generic
and
then
the
other
is
just
example.
User
is
the
writer
code,
because
in
that
model
you
don't
you
don't
need
all
this
registration.
T
It's
a
little
bit
lighter
weight
in
my
opinion,
so
it
doesn't
put
as
much
knowledge
of
how
we're
doing
this
I
think
in
the
in
the
Acme
circle
right,
and
so
it's
totally
up
to
the
authority
and
its
relationship
with
the
entity
to
figure
out.
You
know
the
value
of
the
token
and
the
unique
identifier.
V
L
Okay,
thanks,
that's
gonna,
say
yeah,
so
it's
definitely
a
lighter
weight
but
I
guess,
since
we
have
to
assume
a
pretty
association
between
the
authority
and
the
CA
anyway
right,
because
there
is
a
trust
relationship,
there
is
a
pre
association.
You
know,
III,
don't
think
you
can
really
kind
of
get
around
the
notion
that
yeah
they
need
to
share
knowledge.
Domain
expert
knowledge
right
of
what
kind
of
namespace
this
is
and
what
kinds
of
credentials
get
issued
for
it
and
like
given
the
degree
of
potential
variability
than
that.
L
If
we
truly
want
to
make
this
generic
it,
you
know,
I
think
the
the
lighter
weight
of
this
just
kind
of
limits.
What
kinds
of
things
you
can
end
up
talking
about,
and
it
it
won't
make
the
problem
go
away
of
having
to
have
the
server
have
behavior
that
is
specific
to
the
domain,
because
it
needs
to
be
able
to
issue
a
certificate
that
is
specific
to
the
adjusting
authority
for
the
domain.
T
Okay,
yeah,
yes,
I
see
your
point
because
I
was
doing
it
in
the
circuit.
You
know
the
original
server
write
code
document
was
from
the
perspective
that
the
PA
and
the
CA
already
have
that
trust
relationship
right
and
in
the
shakin
model.
We
absolutely
have
that
right
because
we
don't
have
we're
not
the
the
entity
source
writer
isn't
using
a
CA
that
hasn't
been.
You
know
authorizing
shinned
by
the
PA.
If
you
will
like
so
we
do
have
a
more
restricted
model,
so
I
can
see
how
I
guess
I
get
a
little
more
generic
yeah.
L
L
T
Because
I
mean
my
opinion
is
that
it
doesn't
cost
anything
to
not
be
generic
Frank
I
mean
my
concern
again
walking
up
to
the
group.
My
concern
is
that
if
we
try
and
open
up
and
make
it
too
generic
we're
gonna
get
use
cases.
You
know
dozens
that
we
need
to
evaluate
and
make
sure
it
works
for
those
situations
right,
and
so
you
know,
people
have
already
implemented
the
shake
and
stuff
and
it
works
everything.
So
Oh
be
quiet.
Now
let
other
speakers.
G
Richard
Barnes
I
think
that
this
is
worth
doing
generically
I've
had
this
a
similar
use
case
in
mind
for
DNS
names
for
a
while,
like
it
wouldn't
it
be
nice
even
for
the
DV
case,
if
the
CA
could
get
information
directly
from
a
registry
as
to
who
holds
which
domain
name
so
I
think
like
it's
worth
at
least
including
that
case
I,
think.
The
thing
we
need
just
need
to
struggle
here
with
struggle
with
here
is
like
what
the
right
axes
are
for
generalization.
G
U
Chris
went
I,
agree
that
it'd
be
good
to
have
a
generic
I
do
see,
though,
all
the
other
use
cases
I
think
maybe
one
thing
we
could
do
is
have
maybe
a
more
sort
of
a
default
mode.
Where
the
you
know,
there's
like
a
UUID
or
something
like
that
as
the
code-
and
you
know
it's
probably
a
scenario
where
I
don't
know
80
90
percent
of
the
folks
using
this
may
have
just
pretty
much
the
same
mechanism
so
that
could
be
one
I,
don't
know.
P
Want
to
point
out
that
the
let
we
already
adopted
both
my
base,
basically
John's
document
and
Mary's
document
and
if
they're
converging,
then
you
know
maybe
John
and
Mary,
should
get
together
within
Chris
and
Richard.
You
know
and
get
together
and
come
up
with
a
converge
document.
If
that,
if
that's
where
you
think
you're.
L
Going
and
where
the
room
supports
right,
so
this
is
John
yeah.
So
there
are
two
individual
submissions
that
we
did
for
this
ITF
one
from
Marian,
one
from
me
just
for
the
generic
token
challenge
of
this.
So
really
we're
trying
to
forget.
Yes,
can
we
merge
those
right
and
if
we
do
then
I
totally
agree,
both
the
service
provider
document
and
the
TM
document
would
then
rely
on
that
merged
generic
one
and
yes,
I'm
happy
to
put
in
Chris's
UID
case
I.
Think
that
makes
a
lot
of
sense.
I
love
the
case.
T
No
I
mean
you
know:
John,
Chris
and
I
will
work
together
and
see
Tom
again.
So
the
one
point
was
that
you
know
the
linkage
in
the
the
role
of
the
authority
is
slightly
different
right:
the
balance
between
that
and
the
CA,
and
so
that's
a
slight
difference
that
just
why
I'm
a
little
bit
reluctant
just
to
throw
it
out
generic.
L
John
again,
I
would
say
Mary
again,
I,
don't
see
if
we
lunch
in
this
one
right,
I
mean
I,
think
you
can
assume
it,
but
like
it's,
that's
assuming
that
there's
still
a
ton
of
domain
knowledge,
that's
in
the
CA
that
it
understands
how
to
issue
things
that
look
like
stir,
certs
and
beyond
that.
Those
are
the
things
that
that
tie
this
down
to
that
particular
use
case.
When
you
say
we
can
just
do
this
as
something
as
narrow
as
entity
code,
so
I
think
I.
L
Think
once
you,
if
you
accept
it,
you
want
anything
more
than
that
level
of
pre
Association.
Then
yeah,
you
end
up
effectively
with
with
the
tokens
and
subtypes
everything
else
we're
talking
about,
but
I
would
appreciate.
There's
anybody
else
in
the
room,
that's
interested
to
this
speaking
to
it.
So
please.
C
W
Use
a
generic
mechanism
that
allows
you
to
do
this
sort
of
token-based
the
I
generally
approve
of
the
direction
this
is
going
on,
but
I
do
want
to
just
have
a
a
slight
thing
on
the
amount
of
domain
knowledge
that
you
need
and
I
think
that
you,
you
still
require
a
certain
amount
of
domain
knowledge
in
the
CA
to
know
something
about.
Let's
call
it
the
number
space
that
you're
eventually
going
to
issue
the
CA.
C
W
G
Just
to
briefly
clarify
the
context
here,
though,
the
the
context
we're
talking
about
here
is
within
an
authorization
transaction
at
which
point
you've
already
specified.
This
is
the
specific
identifier,
you're
validating
so
I
think
we
don't
run
into
the
questions
of
wild
cards,
etc.
I,
don't
think,
there's
a
wild
card
issue
here.
W
Tett
Rd
I
I
agree
I'm,
just
trying
to
say
that
the
amount
of
state
can
only
get
so
low
right
because
you
you,
you
have
to
be
able
to
match
it
to
what
kind
of
identifier
is
going
to
be
issued,
and
there
are
some
of
these
identifiers
which
are
functionally
issued
with
only
one
reference
Authority
and
that
kind
of
identifiers.
The
amount
of
state
you're
willing
to
take
is
whatever
the
reference
Authority
requires.
U
K
A
P
Do
we
do
we
do
we
need
to
hum
on
that?
Or
is
everyone
fine
does
anyone?
Fine
I
have
objections
with
coming
in
bringing
this
on,
you
know,
is
a
there's.
A
new
work
item
well
make
sure
the
Charter
has
to
it
has
to
be
adjusted
we'll
deal
with
that,
but
all
by
London
the
goal
would
be
to
have
this
on.
A
new
submission
is
a
working
graph
working
group
doc.
P
P
X
We
did
a
lot
of
changes
that
were
triggered
by
a
review
that
Martin
did
a
couple
of
months
ago.
Unfortunately,
we
missed
the
cutoff
date
and
we're
sorry
about
that,
and
we
submitted
the
a1
version
of
the
draft.
Only
on
Sunday
night
I,
don't
know
how
many
of
you
have
had
a
chance
to
glance
through
through
the
draft
the
one
well,
the
phonebook
is
I'm
gonna
go
through
okay
couple
of
people.
X
As
a
result
of
this,
we
also
change
the
document
title
which
now
doesn't
talk
about
any
delegation
and
reads
as
support
for
star
certificates
in
acting.
So
delegation
is
one
of
the
main
motivation
for
this
for
us
as
well,
but
it's
not
the
the
only
use
case
and
not
the
main
topic
of
the
of
the
traffic.
Since
that
should
just
describe
that.
The
mechanics
of
the
protocol
and
Ana
mechanics
of
how.
X
X
X
That
depends
on
the
point
when
the
actual
the
first
certificate
is
issued
by
the
biota
CA,
whereas
we've
changed
to
use
absolute
dates.
So
the
ACMA
client
requests
a
defined
well
defined
period
in
terms
of
absolute
dates
and
then,
of
course,
the
Acme
server
can
can
can
reply
and
correct
this
and
and
as
needed.
The
other
thing
we
did
was
change
the
granularity
for
the
forty
for
each
of
the
short-lived
certificates,
which
now
is
expressed
in
seconds
instead
of
days.
We
could
have
done
hours
or
minutes,
but
you
know
ii
seem
to
be.
X
X
And
then
we
we
did
some
work
with
the
respond
being
more
specific
on
what
would
return
in
case.
For
example,
the
their
certificate
has
been
cancelled
or
explicitly
cancelled
or
the
whole
lifetime
of
the
of
the
thing
is
expired,
and
so
we
were
using
RFC,
78
or
7
format.
And
of
course,
we
have
had.
We
had
to
add
a
couple
of
entries
in
the
in
the
corresponding
Jana
registry,
and
then
we
added
a
SPC
p2o5.
X
We
added
an
implementation
status
section
which
described
the
open
source
implementation
that
telefónica
did
on
top
of
Poulter
and
circled
with
pointers
to
to
the
actual
code.
And
of
course
this
exists.
This
is
a
femoral
section
which
exists
only
for
a
period
of
time
that
the
traffic
exists
when,
when,
when
the
drug
goes
into
the
fabrication
cute,
and
then
it
will
be
removed
to
scho,
of
course,
because
it
doesn't
matter
anymore.
U
C
X
R
X
L
Hi
John
Peterson,
with
my
use
case,
that
is
not
quite
domain
names.
I,
do
appreciate
that
deal,
urkesh
that
you
did
thus
far
that
whole
term,
though
D&O
like
the
notion
that
there
is
this
domain
name
owner
and
that's
what
like
actually
cancels,
an
automatic
renewal
still
doesn't
quite
fit
the
language
of
my
use
case,
but
I
love
like
being
able
to
do
exactly
what
you're
doing
and
so
just
a
little
bit
less
specificity
of
the
domain
name.
L
E
C
E
O
80
hat
off
yeah
I
mean
my
sense
of
that
meeting
frankly,
was
that
people
didn't
really
think
it's
much
a
problem
to
just
issue
shirtless
certificates
directly
into
the
CTE
given
the
lifetime
in
sort
of
because
you
actually
implausibly
issue
for
short
left,
so
I
mean
like
in
terms
of
clock
accuracy,
you
legally
can't
go
below
a
week.
Probably
can't
probably
can't
go
blow
too,
and
so
we
already
know
that
the
system
is
accepting.
You
know
the
CDs
has
been
accepting.
You
know.
L
G
X
Yeah
and
then
there's
the
site
meeting
dis
Bourget
that
your
visa
is
is
leading
documenting
star
in
general
right,
not
not
as
a
general,
the
independent
of
the
of
the
actual
infrastructure
that
is
used
for
issuance
and
and
and
in
cancellation,
notarized
cancellation.
So,
for
example,
animal
or
you
know,
Acme
or
a
proprietary
solution.
Whatever.
C
X
A
Okay,
I
was
going
to
plug
that,
but
the
idea
there
is
not
to
talk
about
acne
or
any
particular
issuance
method,
but
about
the
considerations
for
using
shortened
certificates
in
terms
of
accuracy,
security
and
stuff.
Like
that,
so
yeah
like
it
says
there
6:00
p.m.
at
the
elephant,
which
leaves
us
with
just
one
more
presentation:
Oh
anything
about
the
star
go
so
just.
G
One
quick
question
out
of
curiosity,
for
the
author's
have
you
had
any
chats
with
CA
is
about
whether
anyone's
interested
in
deploying
this
okay
I
think
he
said,
digits
hurt.
A
Y
I
am
on
a
team
that
works
on
a
on
an
open-source
project
that
involves
users
being
able
to
launch
their
own
secure
cloud
services.
Currently,
we
don't
have
a
way
for
those
users
to
access
their
that
there's
service,
which
is
launched
in
a
VM
of
their
own
creation
in
a
web
browser
we've
had
to
write
our
own
clients
and
do
everything
outside
of
browsers,
because
the
the
endpoints
don't
have
a
name,
don't
have
a
domain
name,
so
there's
no
way
for
them
to
acquire
certificate.
Y
So
there's
no
way
to
establish
a
secure
connection,
and
we
don't
want
to
put
them
all
under
some
DNS
name
of
our
control,
both
because
that
gives
us
too
much
control
over
them
and
because
it
makes
it
identifiable
that
a
user
is
specifically
accessing
one
of
our
services.
So
that
means
that
every
TL,
every
TLS
connection
is
marked
with
an
S
ni.
That
says
this
is
the
the
kind
of
software
that
I'm
accessing.
Y
It
means
that
it's
preceded
by
a
DNS
query
that
identifies
the
kind
of
software
that
I'm
accessing
and
invite
somebody
to
block
access
to
that
software.
So
having
connections
that
are
essentially
not
specific
to
the
specific
kind
of
software
that
is
running
on
the
VM,
that
we're
launching
would
be
great
and
it
seems
like
I-
feel
you
guys.
Certificates
would
be
the
way
to
do
that.
But
that's
not
matter
for
the
working
group.