►
From YouTube: IETF104-ACME-20190327-1120
Description
ACME meeting session at IETF104
2019/03/27 1120
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
A
C
But
so
this
is
a
note,
well,
I'm
sure
you've
seen
that
a
couple
of
times
this
week
loved
it
well
on
the
agenda.
Well,
we
have
the
blue
sheets
circulating
we've
got
scribes.
Thank
you,
we'll
do
a
brief
status,
then
we'll
see
presentation
on
star
and
devices
the
station,
client
certificates
and
finally
TN
off
and
don't
believe
we're
actually
going
to
have
time
for
open
mic,
but
so
any
agenda
bashing
going
once
going
twice.
A
A
D
A
C
So
finally,
RFC
eight
five
five
five
is
out:
I
promise
ticker
tape,
but
ticket.
It
doesn't
look
good,
so
I
added
a
confetti
thing,
some
stats,
so
we've
had
19
draft
versions
of
the
working
group.
Draft,
plus
five
of
the
individual
draft
took
50
months
from
the
first
individual,
zero
zero,
two
final
RFC,
and
we
in
doing
that
time,
we
went
from
36
pages
to
95,
that's
pretty
much
common
for
the
IDF.
So
great
we
reached
our
first
and
most
important
milestone
other
stuff.
We
got
the
first
version
of
draft
acne
star
delegation.
C
We
have
new
revisions,
zero
to
off
DNR's
and
zero.
Three
appeared
this
week.
Please
read
in
comment:
CIA
has
version
sexy
made
the
evaluation
acne
IPS
your
fibers.
Also.
We
made
the
evaluation,
no
new
revisions
of
s
moment:
email,
TLS,
but
Alexi
promises
that
we
will
have
new
revisions
next
time
and
no
new
revisions
of
acne
TLS
al
p.m.
which
is
in
state
aid
evaluation,
revised
the
immediate
sense
December
24th.
So
we
might
want
to
get
a
new
revision
there.
Hi.
E
Ad
here
for
the
next
six
or
seven
hours,
I
just
took
a
look
at
act.
The
IPO
five,
apparently
Mike,
ominous
security
considerations
resolved
by
Rudy
ruin
the
Securities
eration
section.
That's
not
in
compliance
notified
me
to
do
so.
They're
gonna
have
to
put
one
back
in
and
actually
have
security
considerations
and
I'm
assuming
Roman
movavi.
C
F
F
Specifically,
there
were
questions
about
timing
when
exactly
certificate
issuance
happens,
how
that
relates
to
two
potential
times
q
on
the
client
side,
exactly
when
this
certificate
is
available
on
the
server
and
how
that
relates
to
their
not
before
not
after
on
the
certificate.
So
all
of
that
we
made
into
its
own
section
clarifying
the
whole
thing
giving
diagrams
and
more
formal
description
of
the
of
these
various
time
periods.
F
We
also
found
out,
we
need
to
actually
add
the
parameter,
so
a
parameter
coming
in
from
the
client
saying,
I'm
running
on
a
client,
that's
potential
that
may
experience
a
long
time.
Skill
so
I
expect
to
have
I,
don't
know
a
five-day
times
Q.
If
bedlam
is
configured,
please
take
the
into
account.
Please
take
that
into
account.
The
server
can,
of
course,
decide
to
ignore
the
whole
thing
and
just
assume
no
time
skew,
or
it
can
actually
use
it
when
it
computes
the
timing
for
certificate
assurance.
G
C
H
E
F
E
So
if
there
are
certificates,
if
you
using
this
using
spec
ISM,
then
like
that
that's
the
thing
I'm
rejecting
tip
so
very
case,
like
I,
said
Tiggy
I'm
thinking
my
ad
held
off
now
book
is
like
this
will
not
be
a
problem
but
like
like
that's
the
thing
I'm
saying
it's,
like
only
has
things
refurbished
generals
who
are
in
a
dorm
if
you
were
doing
great
but
like
I've
seen
a
lot
of
person
there's
nobody
does
it's
not
just
like.
This
is
all
work.
Silly.
K
L
To
implement
it
now
great
Michael
Richardson,
so
anima
is
not
a
thing,
that's
going
to
implement
it,
but
we
have
more
or
less
in
our
ACP
said,
go
look
here.
This
is
a
really
good
idea
to,
and
you
probably
want
to
do
this
so
I,
don't
know.
If
that's
it's
not
exactly
implementing
so
much
as
saying
yeah,
we
really
need
it.
So.
C
M
M
Next
time,
I
guess:
oh
there
you
go
okay.
So
what
I'm
trying
to
achieve
with
this
with
this
draft
is
try
to
automate
the
issuance
of
say
of
certificates
a
to
devices,
especially
during
the
initial
deployment
of
those
devices,
is
specifically
what
I'm
trying
to
achieve
is
in
the
ability
to
deploy
a
specific
certificates
for
a
specific
device
to
allow
that
device
access
to
a
specific
service,
not
just
a
generic
a
device
certificate.
M
So
in
this
light
is
just
a
slide
showing
them
a
different
partition
name
in
their
same
in
the
setup
and
the
initial
trust.
So
you
have
the
a
DA
as
the
device
authority,
which
is
the
manufacturer
of
that
device,
and
then
you
have
the
device
itself
in
now.
There
is
a
initial
trust
between
between
the
device
and
the
DA,
so
they
be,
they
will
be
able
to
a
modular
indicate
each
other,
and
there
is
that
trust
between
the
DA
and
acne
CA.
M
Now
the
initial
setup
is
that
the
client
will
be
able
to.
We
need
to
create
an
account
with
a
with
a
with
a
a
da
and
then
claim
that
device
him,
as
without
with
the
MA
any
other
acne
operations.
They
will
have
to
create
an
account
with
acne
and
prove
control
over
a
specific
service
URL.
So
that's
what
the
setup,
so
this
slide
is
trying
to
show
that
that
big
picture
of
the
flow
and
and
later
we'll
dig
into
a
kind
of
down
the
Acme
flow
itself.
M
So
the
device
starts
with
a
with
a
communicating
with
the
da
authenticating
itself
and
obtaining
a
job
in
the
device.
Then
a
will
a
create
a
CSR
locally
on
the
device
and
push
those
best
years
or
and
to
that
client
the
client
then
we'll
start
the
operation,
the
acne
operation
with
acne
ACA
obtains
that
certificate
and
pushed
that
certificates
back
to
the
device.
So
that's
at
the
high
level
now
I
will
talk
about
that
kind
of
the
interaction
between
the
client
and
the
acne
CA.
M
So
the
client
start
the
process
with
a
regular
acne
order,
M
with
a
with
a
key
ideas
that
the
customer
that
call
in
this
case
the
difference
is
that
the
URL
will
be
pointing
back
to
them
ad
a
in
this
case
so
and
they
finalize
a
finalized
and
authorizations
URL
would
be
created.
A
the
client,
then
we'll
post
a
request
to
the
with
the
job,
to
authorize
that
operation
get
a
200,
ok
status
and
then
send
the
csaw
request
to
the
M.
M
Today,
a
acne
CA
it
to
obtain
URL
for
the
certificate
itself,
so
that
the
difference
here
is
that
what
you
see
in
red
here
so
typically,
you
would
see
customers
calm,
also,
all
the
ways
in
name
in
they
were
elected
to.
In
this
case,
were
talking
about
that,
the
authorization
gonna
be
happening
from
based
on
that
ad,
a
so
that's
reason
it.
The
URL
is
a
vendor
to
come
in
this
case.
M
A
and
the
difference
also
is
that
in
the
they
in
step,
two,
you
would
get
the
URL
to
be
able
to
push
an
authorization
for
that
operation.
Typically
with
the
atmosphere.
You'll
get
there's
another
round
trip
or
for
a
request
and
response
to
get
that.
So
in
this
case,
we're
doing
directly
in
so
that
M
that
the
the.
I
Daath
also
differ
a
identifies
right.
There.
Sorry
I'm
a
bit
confused
here,
so
it
looks
like
in
in
line
one
there.
The
request
is
going
to
the
CA,
which
is
which
is
on
acne
calm,
but
the
URL
is
in
this
URL
parameter
of
the
jws
is
pointing
to
vendor
calm.
This
is
like
a
pretty
radical,
so
that's
the
case.
Yes,.
M
I
I
On
the
CIA's
Acme
server
right,
like
the
the
URL
parameter
in
the
Jade
EBS,
provides
the
binding
between
the
Nivea.
It
expresses
the
intended
destination
of
that
request
by
the
client,
which
is
a
URL
on
the
cia's
acne
server.
So
it
seems
like
a
pretty
significant
change
to
to
change
if
you're
gonna
change
that
URL
field,
like
that,
does
a
pretty
such
a
significant
change.
The
security
model
of
acne
so.
M
M
M
So
in
that
the
death
toll,
so
they
defines
that
Device
Identifier
for
the
Mac,
so
we
have
a
type
and
and
a
value
with
the
Mac
as
the
identifier.
It
is
an
example
of
a
job
in
this
case
we're
talking
about
the
issuer.
It
would
be
the
the
vendor
Descamps
and
the
subject
will
be
the
MAC
address
of
that
device
and
I'm
trying
to
limit
the
jaw
to
a
specific
client
communicating
with
the
Acme.
M
So
in
this
case,
I'm
showing
audiences
has
both
of
those
there's
no
kind
of
a
well-defined
claim
today
in
to
to
kind
of
put
the
customer
calm
in
a
in
a
in
a
jot
and
we're
working
on
kind
of
trying
to
define
a
specific
claim
for
that
and
at
the
end,
what
you
get
is
a
certificate
with
a
MAC
address
and
a
specific
service
URL.
So
the
device
will
be
able
to
authenticate
itself
to
that
surface,
a
making
sure
that
it
is
a
specific
device
accessing
a
specific
service.
N
O
O
N
L
I
Michael
Richardson
I
was
very
interesting,
your
jock-or-not
and
I,
and
the
the
in
general.
What
I
see
is
that
in
Acme
is
that
the
various
challenges
that
we
do
are
essentially
attesting
to
the
existence
of
you,
know
the
device
and
so
you're,
basically
delegating
that
to
something
else:
right:
okay,
and
so
that
I
think
that's
where
the
terminology
kind
of.
Does
that
translate
the
terminology
better?
We
don't
call
it
attestation
in
an
ACME.
We
call
it
a
challenge
and
I
think
that's
the
connection,
bridging
different
technologies.
That
makes
more
sense
to
me.
P
M
P
M
I'm
trying
to
automate
this
whole
process
so
the
whole
idea
you
get
the
device
from
you
buy
a
device
from
vendor.
We
want
to
be
able
just
to
immediately,
deploy
it
without
doing
anything,
but
that
that
deployment
will
be
automatic,
you'll
get
a
certificate
and
you
will
be
able
to
automatically
start
accessing
that
device
by
authenticating
that
device.
You
have
a
mutual
authentication.
P
C
C
So
what
I
would
suggest
is
that
you
add
this
some
terminology
because
words
like
at
the
station
cryptographic,
binding
and
stuff
mean
a
different
thing
in
pretty
much
any
document.
That's
mentioned
them
so
that
you
add
this
and
then
we'll
ask
people
to
read
it,
and
then
we
can
well
either
harm
or
ask
them
the
list
whether
people
want
to
adopt
this
okay.
So
no
thank
you.
Thank
you.
Q
Hi,
so
thank
you,
I
wanted
to
see
and
get
a
feel
of
the
working
group
to
see
who
is
interested
in
different
types
of
client
certificates.
This
is
a
pretty
bare-bones
draft,
because
I
wanted
to
get
a
pulse
of
what
was
interesting.
Some
things,
I'm,
not
quite
sure,
are
interesting,
but
I
wanted
to
cover
the
spectrum
and
then
figure
out
from
their
challenge
types
that
might
need
to
be
added
in
things
of
that
nature,
but
I
wanted
the
pulse.
First,.
Q
Q
There
is
a
case
for
device
client
certificates
to
the
IP
address,
based
and
so
I'm
wondering
if
that
could
be
it
instead.
Added
to
the
IP
address
draft
I,
think
that
makes
more
sense
right.
Now
it's
written
as
it's
for
server.
You
may
only
have
the
distinction
there
in
the
CSR,
but
that's
just
not
clear
from
how
it's
written
so
I'd
like
to
figure
that
out
and
if
we
could
put
that
in
the
IP
address
draft
and
you
might
have
on
an
internal
network,
a
CA
that
supports
Acme.
Q
So
if
you
have
like
a
cluster
of
systems
and
one
is
acting
as
the
CA,
that
would
be
the
use
case
for
it.
So
you
might
have
non-routable
addresses
or
whatnot,
but
this
would
be
specific
to
your
environment
so
that
you
could
get
your
systems
up
with
trusted
connections
and
looking
at
eight
five,
five
five,
it
calls
out
explicitly
web
server
certificates
and,
looking
this
you
know,
I,
you
could
use
DNS
and
you
could
use
the
same
challenge
type.
Q
But
when
people
look
at
that
draft
they
see
web
server
certificates.
So
do
we
need
anything
different
is
my
question
to
the
working
group
to
do
this
for
a
client
device
certificates,
and
so
does
that
mean
there's
a
is
there
another
challenge,
type
that
makes
sense.
I.
Think
the
DNS
kind
of
makes
sense
is
the
only
differentiation
point
in
the
CSR
or
does
the
interface
need
some
other
differentiation
point
like
if
people
are
interested
to
do
this,
which
I
am.
Q
F
F
For
cloud
deployments,
there's
the
well-known
distinction
of
cattle
versus
pets,
so
named
staff
versus
really
unnamed
stuff
that
that
compliant
with
some
sort
of
policy,
so
it's
part
of
a
group
of
devices
or
endpoints
or
whatever
you
call
them,
but
it's
not
really
named.
It
doesn't
have
its
own
identity,
but
still
needs
needs
a
certificate.
Yes,
so
I
would
like
to
see
this
evolve
towards
covering
these
these
cases
as
well.
Okay,.
Q
R
R
S
Palo
Alto
shredded.
We
also
experimenting
with
some
IPSec
usage
of
Acme
certificates,
so
so
sometimes
they
had
some
different
ikki
use
and
other
properties
or
no
certificates,
usually
they're
made
backwards
compatible
to
be
like
TLS
server,
tillis
client,
but
it
would
be
nice
if
it
could
also
work
with
like
either
the
sort
of
I
think
it's
RFC,
45:43,
ipsec
profile
certificates,
okay,.
Q
I
Richard
Barnes
so
mm-hmm,
so
the
degree
that
these
clients
are
using
are
identifying
themselves
with
DNS
names
or
IP
addresses
I,
don't
think,
there's
any
new
work
necessary
here,
it's
already
possible
to
express
the
the
client
auth
EKU
in
your
CSR
and
then
it's
just
up
to
the
CEA's
policy.
Let's
not
you
yeah.
Q
Q
I
So
I
mean
yeah,
it's
a
to
the
some
of
the
other
points
there
he's
like.
If
people
want
to
identify
their
clients
in
other
ways,
like
absolutely
should
define
like
new
identifier
types,
new
challenge
types,
you
know
I
wear
some
of
these
are
already
on
the
agenda
today
for
for
other
reasons,
but
the
idea
that
that
I
don't
think
there's
a
core
difference
between
clients
and
servers
hurts
here
other
than
just
the
EKU.
I
Q
I
I
Q
For
Dell
EMC
I'm
not
talking
about
us
in
DP,
either
right
so
I,
don't
know
what
kind
of
checks
I
think
some
of
the
checks
go
beyond
in
the
certificate
content
types,
so
I
get
and
I
wrote
in
the
draft
that
CSR
changes
or
enough
to
make
this
request.
I
just
wanted
to
make
sure
my
read
of
that
didn't
underestimate
somebody
else's
use
cases.
E
Q
M
K
Q
Q
Yeah,
sorry
about
that
so
I'd
like
to
hear
more
on
the
list.
It
sounds
like
some
people
are
I,
guess
I'm
going
the
wrong
direction,
but
that
makes
no
sense.
So
can
you
advance
it
so
I'd
like
to
hear
more?
It
sounds
like
there
are
some
people
with
interest,
but
we
have
to
see
what
it
what
it
flushes
out
to
for
other
use
cases
and
if
there's
enough
there,
so
the
next
one
is
user
and
user
certificates.
So
my
personal
opinion
is
no.
Q
T
E
T
T
Q
I
Q
Q
Q
You
we
probably
could
do
something
right
now
for
just
standard
certificates
with
the
existing
challenge
types,
but
for
easy
certificates,
I
poked
at
it
a
little
bit
to
figure
out
what's
the
issuance
process,
so
usually
there's
an
account
created,
and
so
there's
you
know,
proofing
of
the
organization
there's
at
least
two
administrators
contact
information
is
associated
with
the
account
and
then
they
do
something
via
a
portal.
Could
it
be
further
automated
through
the
use
of
acne
and
so
email,
SMS
or
some
other
type
of
challenge
that
could
be
possible
to
further
automate
this.
U
Much
better
cable
ads.
We
actually
have
a
lot
of
experience
with
that,
because
in
our
infrastructure
we
actually
use
code
signing
certificates
to
sign
all
the
humours
for
cable,
modems
and
our
equipment.
The
procedures
are
really
really
strict.
Yeah
I
would
not
feel
comfortable
to
meeting
many
of
those
because
we
require
verification
of
the
business
etc,
and
we
always
have
to
have
only
I
well
invite
people
that
can
request
a
certificate.
T
U
Q
P
Q
P
Q
V
Gonna
we're
gonna
cut
the
line
after
the
current
speakers.
Sure
John
nah
keep
this
because
I'm
gonna
talk
about
this
exact
thing
in
a
minute,
I
think
you
know
we
actually
created
this
this
framework
for
the
stuff
we're
doing
here
in
act
me.
That's
called
this
authority
token
concept,
and
this
isn't.
This
is
a
step
of
automation
where
you
know
that
there
are
some
external
authorization
process
being
conducted
by
a
third-party
entity,
and
that
could
be
an
extremely
complex
like
enrollment
process.
V
That
involves
like
business
process
and
like
everything
else
and
like
the
way
that
I
think
this
might
be
relevant.
What
you're
talking
about
is
it
is
an
automation,
step
right
there.
There
is
a
way
to
automate
the
process
of
getting
like
a
job
from
this
Authority
and
you
know,
provided
the
CAS
have
the
proper,
a
trust
relationship
with
the
authorities.
There's
like
a
workflow
we
drive
for
that
could
be
helpful
for
something
like
this.
This
is
a
touchdown
great.
Q
G
Come
just
a
comment
on
the
authorization
tags
for
Celtic
in
her
given
India
a
comment
on
the
authorization
types.
We
did
some
analysis
on
Acme
and
published
this
last
year
and
we
made
a
strong
distinction
between
a
write
authorization
like
YouTube,
with
the
DNS
and
an
HTTP,
and
even
in
the
old
TLS,
a
nice
stuff
and
read
authorization
channels
like
email
and
SMS,
and
we
showed
that
it
without
transitions
and
like
email
and
SMS
a
distinctly
weaker
in
fact,
distinctly.
G
Q
Q
Yeah
point
taken
and
we
don't
have
to
beat
a
dead
horse
and
I
didn't
spec
it
out
thinking.
It
was
the
best
thing
since
sliced
bread
I
there.
So
you
know
that
I'm
not
committed
to
anything
more
of
let's
figure
out
if
there
are
ways
to
go
forward
or
you
know
it
sounds
like
there's
some
interest.
So
if
people
want
to
work
with
me
on
this,
it
clearly
needs
more
development.
I
I
Q
C
V
Hello,
I'm,
John,
I'm
gonna
talk
about
authority
tokens
for
acne
extremely
exciting
relevant
to
much
what
we've
been
discussing
next
slide.
Please
we'll
go
quick.
The
basic
idea
behind
this
and
again
this
was
motivated
by
this
stirrer
work,
we're
trying
to
beat
this
robocalling
snuff
just
as
a
refresher
on
what
this
is
actually
all
about.
V
We
abstracted
this
into
a
generic
need
for
authorities
to
be
able
to
provide
a
token
that
could
be
used
in
acne
challenges
for
sponding,
the
CA
to
say,
hey
some
third-party
entity
that
was
responsible
for
something
that
isn't
a
domain
name.
Some
other
name
space
mother
identifier
class
has
vetted
whoever
this
acne
client
is
and
thinks
it's
cool
for
them
to
be
issued
a
certificate
for
this
resource.
That's
the
basic
idea.
The
draft
is
draft
acne,
token
Authority,
and
it's
really
a
pretty
generic
framework.
S
V
There
and
we,
but
we
created
registries,
so
if
you
want
to
use
things
other
than
jots
as
ways
to
kind
of
attest
from
a
third-party
authority,
hey
I
this
this
person
is
legit.
You
should
ask
them
certificate
for
the
following
identifier:
it
is
flexible
enough
to
incorporate
that
and
that
could
be
useful
for
a
lot
of
these
other
identifiers
right
than
the
DNS
that
we
seem
to
be
getting
increasingly
interested
in
here
next
slide.
V
So
this
is
the
description
of
the
atc
token
TK,
auth
type,
which
again,
as
I
said,
uses
jot.
This
is
what
would
actually
look
like
in
an
acne
response.
The
atc
itself
is
buried
down
there
and
that
payload
element
and
will
break
out
that,
so
you
can
look
at
it,
because
this
is
the
main
thing.
We've
changed
in
this
version
in
a
sec,
but
next
slide.
So
what's
new
in
oh
three
and
OH?
V
Yes,
we
very
abruptly
issued-
and
oh
three
at
the
beginning
of
this
week
as
Chris
went
and
I
have
still
been
kind
of
ironing
out
the
interaction
of
this.
With
this
new
stur
delegation
mechanism
that
we
were
defining
over
in
stir,
the
big
things
we've
done
is
actually
fleshed
out
a
rest
interface,
an
interface.
So
you
can
go
to
one
of
these
token
authorities
and
request
one
of
these
tokens.
We
cribbed
this
actually
from
work
that
is
being
done
on
addis
in
addis
for
specifying
how
people
are
going
to
get
their
certificates.
V
We
need
in
order
to
be
able
to
attest
ownership
of
telephone
numbers,
to
be
convinced
spoofing,
so
we
can
in
turn
prevent
Robo
calling,
which
would
be
absolutely
amazing,
and
what
we
did
is
we
beefed
up
the
atc
structure
in
this
revision.
It
wasn't
terribly
good
JSON
previously,
and
we
tried
to
give
it
the
semantics.
We
think
it
actually
needs
to
do
what
the
use
case
requires
larger.
That
included
actually
getting
good
way
to
do.
Authorities
scope-
and
this
is
just
a
notion
of
when
you're,
going
to
a
token
authority
to
this.
V
This
kind
of
third-party
Oracle
and
asking
hey,
give
me
a
token.
I
can
then
pass
the
CA.
How
do
you
specify
kind
of
what
the
scope
of
the
authority
is
that
you're
requesting
and
the
way
that
we
decided
to
do
that?
This
is
the
main
thing
we
change
between
0,
2
and
0.
3
is
effectively
just
to
give
the
ATC.
You
would
like
the
authority
that
token
authority
to
issue
to
it,
get
it
to
sign
it,
give
it
back
Tia
and
then
you
can
put
it
in
the
act,
be
challenged
with
your
CSR.
V
Get
your
cert
a
couple
of
interesting
things
we're
doing
here.
This
is
not
something
I'm
sure
any
be
else
is
doing
because
of
the
way
we
want
to
do
delegation
in
stir-
and
this
is
actually
kind
of
similar
to
our
PKI
delegation.
We
use
something
like
the
encompassing
semantics
or
certificates.
In
other
words,
where
you
think
about
telephone
number
allocation
right,
there's
big
blocks
of
telephone
numbers.
We
want
to
be
able
to
delegate
down
okay.
This
carrier
has
this
huge
block.
V
Because
of
that,
we
want
to
actually
be
able
to
use
Acme
to
ask
for
CI
Sert's
Sert's
with
a
CA
bullion
equal
to
true,
so
that
when
that
enterprise
gets
their
initial
cert
allocation
from
acme,
they
will
be
able
to
delegate
down
themselves
an
individual
certificate
to
a
particular
single
telephone
number
user.
I
could
have
asked
I
asked
Richard
Barnes
about
this
was
like
does
Acme
like
work
with
this
and
he's,
like
probably
I,
mean
again
just
put
it
in
the
CSRs
table
and
it's
true,
and
it
should
should
work
so.
V
But
if
anybody
wants
to
barf
on
that,
this
would
be
a
good
time.
We,
we
think
it's
cool
for
our
use
case,
but
I
don't
see
anybody.
Barfing
I
see
some
thumbs
up
in
the
crowd.
Okay,
I
think
those.
The
only
thing
was
like
really
like
interesting
or
controversial
potentially
in
this,
and
that
needs
to
be
reflected
in
the
ATC
element,
so
that
has
its
own
internal
boolean,
because
you
do
want
the
token
Authority
who
is
telling
the
CH
to
issue
the
certificate
to
know.
V
V
Stirrup
owned
of
name
constraints,
so
the
way
that
we're
doing
this
in
this
is
very
similar
to
rpki.
We
really
did
kind
of
quit
from
this
I
mean
the
thing
is
the
Tia
Nautilus
or
so
there
in
the
search.
There's
this
this
new
element,
we
define
that's
called
Tia
NOC
list
and
that's
where
you
would
stick
those
telephone
numbers
in
fact
that
we
were
saying
is.
That
is
the
name
constraints.
When
we
first
looked
at
this,
we
were
like.
V
Should
we
have
like
a
separate
like
TN
constraints,
element
that
is
adjacent
to
that,
but
ultimately
I
think
the
same
way
rpki
encompassing
works.
It
seems
like
the
you
know,
if
you
get
this,
you
know
thousand
block
from
your
carrier
and
your
stop
going
down
a
hundred
block.
Well,
it
is
the
thing
that
said
you
have.
A
thousand
block
is
the
constraint
that
says:
you're
allowed
to
issue
the
hundred
block
and
then
in
turn
it
is
the
constraint
if
that's
a
shooing
down
a
single
number
to
some
other
entity.
C
V
Well,
so
we
have
verification
services
required
to
enforce
it.
That's
so
we're
going
to
do
it
in
stir.
Is
that
it
we
are
pushing
it
to
the
relying
parties
and
that's
a
you
know:
I
mean
there.
There
are
edges
that
are
hard
edges
on
this,
actually
in
the
way
that
telephone
number
allocation
works
because
there
are
weirdnesses
about
numbering
plans
and
things
like
that,
so
it
requires
the
verification
service
to
have
a
certain
amount
of
domain
expertise
in
how
number
allocation
works.
V
We
think
that
in
this
use
case
we
can
we
can
assume
that,
but
you
know
I
I.
You
hear
the
tenuousness
in
my
voice
about
that.
I
think
I
think
it's
it's
okay,
because
because
in
the
web
it
wasn't
enforced,
understood
and
yeah
I've
read
about
how
names
and
trains
have
have
their
own
issues
on
this.
Yes,
yes
max
back.
U
Here,
well,
that's
regarding
the
CA
communication.
They
CSR
I
would
advise
against
it
because
in
the
past
some
CAS
might
have
the
practice
of
just
copying
some
extension
from
the
CSR
to
the
certificate,
and
this
extension
should
be
particularly
guarded,
because
it's
very
particular
I
would
suggest
instead,
if
possible,
to
do
to
use
an
attribute
where
you
indicate
maybe
the
type
of
profile
of
certificates
that
you
want
to
to
get.
U
V
V
That
the
token
Authority
has
said
it's
okay
to
accept
the
boolean.
We
just
assumed
we'd
have
to
put
it
in
the
CSR
as
well
right.
The
point
is
it's:
if
there's
kind
of
a
belt
and
suspenders
it's
both
in
the
CSR
and
it's
in
this
authority
token
in
the
ca's
job,
when
it
if
it
supports
this
extension,
is
compliant
with
it
is
to
look
at
that
ATC.
But
what
ties
the
token
through
the
CSR
there's
a
fingerprint
and
binding.
There's
like
all
this
stuff
that
the
way
that
the
DHEC
works?
V
V
I
M
U
I
I,
don't
think
that
it's
like
there's
like
real
hard
language
in
there,
I
I,
don't
think,
there's
there's
hard
requirements,
but
I
think
the
if
I
recall
correctly.
What's
what's
in
the
RFC
is
something
like
it's
the
CAA.
It
cannot
issue
the
the
certificate
as
requested
in
the
CSR,
so
where,
where
the
CSR
specifies
something
you
should
follow,
you
should
be
sure
you
know
issue
that
specifically.
So,
if
there's
like
an
extension
request,
the
specific
extension
contest,
you
should
have
that
specific
extension
contents
in
certificate.
I
That
doesn't
mean
the
CIA
can't
like
added
extensions
that
corresponding
CAS
policy.
But
you
should
you
know
where,
where
the
CSR
specify
something
you
should
stick
with,
that
specification,
I
mean
I,
don't
think
it's
a
hard
requirement,
but
it
you
know,
following
this
approach,
is
consistent
with
that
that
general
approach,
but
in
they
have
so.
A
I
V
They're
not
changing
their
gonna,
because
the
way
that
we
have
defined
the
extension
right,
the
Authority
open
itself-
you're
not
supposed
to
do
it
unless
the
authority
toke.
Yet
the
token
Authority
is
actually
quoted
in
the
ATC
CA
winkles.
True,
like
I,
think
there
is
a
policy
backstop
I,
don't
think
there
goes
like
some
risk
that,
like
accidentally,
the
CA
people
in
is
gonna,
get
set
true
because
somebody's
being
like
sneaky
and
puts
that
in
the
CSR
and
not
in
the
ATC
I
mean
we've
been
put
in
an
even
harder
language
about
that.
V
X
V
I
V
What
this
looks
like
there's,
this
optional
limit,
you
can
add
for
C
equals
true,
but
for
the
most
part
you're
just
doing
the
fingerprints
and
that
the
TK
value
there
is
the
thing
that
you
know
you're
signing
off
on.
That's
all
the
a
64
encoding
of
what
the
telephone
number
is.
Another
junk
looks
like
next
slide,
so
we
still
need
to
have
like
security
considerations
and
privacy
considerations
and
stuff
to
this,
but
otherwise
I
think
is
relatively
baked
at
this
point
and
we're
starting
to
see
this
going
to
production.