►
From YouTube: IETF99-ACME-20170721-0930
Description
ACME meeting session at IETF99
2017/07/21 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
Kotick,
including
wait
if
you're
looking
for
seller
you're,
not
in
the
right
place,
the
seller
is
always
the
lowest
part
of
the
true
party.
No
just
one
remote
was
there.
Anybody
who
is
looking
for
lossless
encoding?
No,
really
it's
quite
pleasant.
You
should
try
it
weird
Acme!
Welcome
you
to
go
around
thanks
to
our
Mimar
here,
Richard
and
Matt
Miller
from
under
chaperone
any
agenda
bashing.
Let's
bring
it
up
so
that
they
can
see
it
while
they
agenda
bash.
A
Yes,
that's
right,
because
somebody
had
a
plane
to
catch.
So
all
right.
B
C
So
the
main
draft
whoo
and
the
CAA
draft
are
working
plus
call.
They
both
had
revisions
since
the
start
of
last
call,
and
we
hopefully
think
they're
both
done
and
we're
going
to
verify
it
here.
Then
we've
got
a
bunch
of
new
documents
that
we've
just
adopted
and
we're
going
to
hear
about
them.
Well,
not
for
the
first
time,
because
we've
heard
about
them
in
the
virtual
interim,
but
we're
going
to
see
them
in
the
context
of
a
face-to-face
meeting
for
the
first
time
today.
So
does
anybody
want
to
bash
the
agenda?
C
A
D
Good
morning,
I'm
Iran
chef
I'll
be
talking
about
issuance
of
short-term
certificates
star.
This
was
adopted
in
the
last
session,
so
now
it's
a
working
group
document
and
therefore
I
will
start
with
a
high
level
but
dive
into
the
details
and
specifics
next,
so
starting
at
the
high
level.
Some
of
the
motivation
behind
this
draft
is
to
be
able
to
authorize
a
third
party
to
publish
a
website.
D
D
D
The
working
group
draft
covers
the
two
pieces
that
are
in
red
so
being
able
to
request
the
star
certificate,
the
short-term
certificate
from
the
Acme
server,
as
well
as
the
periodic
retrieval
of
the
certificate
directly
into
the
NDC.
The
third
piece
is
the
initial
interaction
between
the
NDC
and
the
bno,
and
that's
a
different
draft
that
we
pulled
out
of
the
original
individual
draft
and
that
I
will
discuss
shortly
later
in
the
presentation.
This
is
not
a
working
group
document
today.
D
D
This
is
backward
compatible
in
the
sense
that,
if
you
don't
implement
these
properties,
the
client
will
get
back
in
order.
Resource
I
mean
get
back
from
the
post
and
all
the
resource
that
does
not
contain
these
properties.
The
client
should
notice
that,
and
were
probably
just
punt
there
was
the
world
comments
on
the
that
day's
are
too
long.
So
I
would
like
to
hear
other
people
on
this
point
right
now.
This
is
specified
both
states.
Both
durations,
are
specified,
as
dates
as
days.
D
D
The
star
certificates
are
all
fetched
from
the
one
certificate
endpoint,
that's
the
same,
endpoint
that
we're
using
in
today's
regular
Acme.
The
current
draft
says
that
the
client
can
understand
what
is
their
remaining
lifetime
of
the
short-term
certificate.
By
looking
at
the
expires
header,
it
was
noted
on
the
list
that
is,
this
is
at
best
abuse
of
the
expires,
header
and
probably
just
incorrect.
D
One
thing
we
could
do
is
just
send
the
client
to
pass
the
certificate
itself
and
so
understand
what
is
the
expiration
of
the
short-term
certificate
personally
I
would
like
it
to
be
expressed
explicitly
so
that
people
can
can
deal
with
it
as
simply
as
possible,
and
yes,
this
does
create
duplication
of
information.
Yes,
Saturday.
A
E
A
There's
a
potential
silly
state,
then,
if
you
actually
included
somewhere
other
than
the
certificate
where
somebody
else
has
had
to
parse
it
and
and
put
something
in
wrong.
So
it
seems
to
me,
although
it's
a
kind
of
a
pain
to
parse
the
search
to
extract
it.
It's
it's
by
far
the
most
deterministic
answer.
I
agree.
A
I
would
suggest
we
just
stick
to
that.
Richard
does
not
like
determinism
and
would
like
to
rise.
B
C
So
why
do
we
need
this
special
treatment?
I
mean
regular
certificates
are
issued,
they
expire,
you
proactively,
renew
them.
Why
do
we
need
the
special
thing
just
because
the
lifetime
is
shorter?
We
might
as
well
use
the
regular
a
key
protocol
and
get
just
a
few
hours
or
a
few
days
of
validity,
presumably.
D
Because
so
because
it's
so
much
easier
to
be
in
DC
here,
all
you
need
to
do
is
to
periodically
fetch
a
certificate
and
install
it
locally.
You're,
not
the
world's
the
Acme
protocol.
You
don't
have
any
certificate
issuance
passed,
saying,
understanding,
logic,
you're,
just
a
dumb
endpoint,
so
we're
skipping
the
challenges
that
are.
F
Some
reason
that's
kind
of
why
I
got
up
to
contradict
Ed's
need
for
determinism,
I,
think
it's
worth
having
the
expires
here
in
kind
of
the
interests
of
layer
separation.
If
you
got
you,
this
kind
of
certificate,
maintenance
thing
and
it's
only
job-
is
to
fetch,
updated,
certs
and
drop
them
in
the
right
spot
on
the
web
server.
It's
kinda,
it's
just
kind
of
a
pain
to
have
that
thing,
parsed
the
search
to
find
out
what
it
needs
to
go,
get
the
next
one
and
in
fact
the
you
know
this.
F
A
In
that
already
pretending
to
be
at
the
front
mic,
so
in
the
case
where
the
expires
header
and
the
certificate
disagree,
you
could
end
up
in
a
situation
where
it's
dropped
in
something
that
has
a
period
of
invalidity
and
you're.
Just
gonna
say:
that's
an
error.
You
shouldn't
do
that
if
it
hurts
when,
when,
when
you
climb
into
the
boiling
water,
wait
for
it
to
become
tepid,
and
so
in
other
words,
you
just
see
that
as
a
bug
and
okay.
A
F
Something
like,
instead
of
specifying
how
long
I
want
this
from
you
or
less
say,
I,
want
the
last
renewal
not
to
exceed
this
date
right.
You
could
do
something
like
that.
What.
F
G
D
D
H
Expiry
so
I'm
saying,
if
you
happen
to
ask
during
that
second
half
of
the
period
you
get
a
new
you
you
get
it,
you
may
get
an
a
different
thing
than
you
did
before
you
will
get
a
different,
but
but
you
said
it
should
be
ready.
It
might
not
be
ready
and
there
may
be
caching.
That
means
that
you
don't
get
the
new
one
during
samisen
yeah.
D
A
Okay,
Terry
with
a
clarifying
question
to
Michael.
If
you
were
gonna
design
this
and
had
a
bike
shed
available,
what
color
would
you
paint
this
name
because
it
doesn't
seem
like
expires,
is
exactly
capturing.
What
you're
asserting
is
the
intended
semantics
and,
and
that
you've
just
said
actually
makes
it
even
clearer
that
this
isn't
truly
an
expires
header.
This
is
actually
you
know.
New
e
tag
will
be
valid
on,
or
some
extremely
clunky
way
of,
saying
that
this
is
actually
something
for
the
next
renewal
available
at.
H
A
So
I
think
the
clarification
that
this
is
actually
not
expires,
but
something
else
with
a
different
semantics
is
very
useful.
Thank
you.
J
F
This
I
would
be
disinclined
to
invent
a
new
header
for
this,
because
what
all
we're
talking
about
here
is
maintaining
cash
sake
like
I
want
to
presume
that
the
CA
can
update
the
search.
It
will
faithfully
update
the
certificate
before
it
expires,
and
so
there
will
always
be
a
valid
certificate
there,
and
in
that
case,
all
you
care
is
that
the
server
is
replicate
you,
a
cash
update
rate
that
server
the
the
rate
of
the
update
of
the
resource,
gets
reflected
on
the
server.
K
So
just
one
more,
this
is
Debbie
Cooley
from
NSA,
so
I
think
you
need
three
values
you
need
is
available
on
and
expire
on,
so
you
need
that
certs
gonna
be
available
on
this
date.
You
need
the
certs
going
to
expire
on
this
date,
because
that
needs
to
go
in
the
certificate
and
then
you
need
the
drop-dead
date
when
you're
not
going
to
renew
anymore,
because
you're
not
changing
the
private
key
here
right.
This
is
reuse
of
the
public
key
to
sign
a
new
cert
right.
K
K
D
D
D
F
F
D
D
There
was
mention
of
OCSP,
stapling
and,
and
so
a
better
discussion
of
why
this
is
needed.
Slash
useful,
but
I
think
overall
does
little.
That
needs
to
go
it's
a
simple
protocol,
so
we
are
hoping
for
zero-one
to
be
published
within
the
next
IDF
cycle
and
to
be
ready
for
working
group
last
call
next
piece
so
going
back
to
the
other
one
to
the
blue
arrow
on
my
previous
diagram.
This
is
the
part.
Were
they.
D
Were
the
BNC
sorry
NDC
request
the
initial
the
initial
thing
from
the
Dino
requests,
the
DNA
Tinh
to
initiate
the
our
Acme
request
to
the
to
the
CA,
the
some
complexities
involved
with
that
and
some
serious
security
considerations
and
to
me
this
is
the
main
reason
why
I
would
like
to
see
it
also,
as
a
working
group
document
I
think
it's
it's
early
for
that
I'm
not
calling
for
adoption
now
to
clarify,
but
I'd,
like
the
working
group
think
about
it.
So.
A
Just
as
a
point
of
order,
if
you've
actually
read
the
document
since
it
was
split
out,
could
you
please
raise
your
hand?
Okay,
they're,
a
couple
of
people,
five
or
so,
but
I'd
really
like
to
see
a
folks
have
a
chance
to
review
this
on
before
we
take
up
the
question
of
whether
it's
gonna
be
a
working
group
item
or
not.
So
if
you
could,
if
your
hand
was
not
already
raised,
please
arrange
to
read,
raise
it
soon
by
reviewing
the
draft
and
commenting
on
the
list.
Thanks.
A
A
K
F
Assuming
that's
applause
for
the
slide
art
here,
so
we've
had
our
second
working
group
last
call
after
we
published
a
draft
for
this
meeting,
got
and
I
think
based
on
that
we're
pretty
much
done
next
slide
has
a
couple
of
issues:
we've
we've
had
a
couple
of
things
come
up
on
the
mailing
list,
thanks
to
folks
sending
this
in
this
week.
F
All
of
these
I
believe
are
pretty
editorial
issues
and
on
the
next
slide,
we've
got
some
things
that
are
in
github
as
of
this
morning.
I
think
all
this
is
pretty
editorial
stuff
I
mean
it
may
involve
like
diffs
that
are
a
few
sentences,
long
or
maybe
a
paragraph
long.
So
it's
not
completely
trivial
stuff,
but
I
think
all
the
stuff
is
I,
don't
think
any
of
it
is
making
protocol
changes
and
it's
all
just
kind
of
clarifications.
F
Maybe
some
like
should
to
must
weeks
that
we
can
run
by
the
working
group
as
we're
doing
them,
but
I
think
we
can
get
this
all
just
sort
of
landed
and
I.
Don't
think
it'll
be
anything
obviously
up
to
the
chairs
discretion,
but
I,
don't
think
it'll,
be
anything
don't
require.
Yet
another
working
group
last
call
so
I
think
we
should
be
able
to
on
the
next
slide
to
just
send
this
on
to
the
iesg.
F
Any
anyone
think
that
any
objections
to
that
plan
I
think
I
would
I
would
target,
is
in
the
next
say
by
the
end
of
the
month,
trying
to
get
some
proposals.
That's
the
list
for
the
fixes
here,
get
some
pr's
up,
give
people
a
couple
days
to
glance
at
them
and
then
land
up
and
send
it
on
by
early
mid-august,
thumbs
up
from
chairs
from
the
floor
from
the
ad
all
right.
F
N
F
And
it's
actually
kind
of
an
open
issue
on
acne,
so
the
question
a
swap
aggressively
swapping
in
as
I
speak
here.
The
question
raised
in
the
list
was
that
the
CAA
draft
has
a
slot
in
it
to
describe
what
validation
mechanisms
are
approved
for
use
with
the
subject,
the
domain
that
is
listed
in
the
CAA
record.
Right
now,
that's
focused
on
acne
mechanisms
drawing
on
the
registry
that
we
have
of
acne
validation
mechanisms.
F
The
proposition
I
made
on
the
mailing
list
was
that
it
might
also
be
useful
to
use
this
for
non
acne
validation
mechanisms.
For
instance,
the
the
see
a
browser
based
there
see
a
browser
forum
based
on
requirements
list.
Several
validation
mechanisms,
they're
approved
for
use
in
web
PKI
with
are
not
acne
mechanisms
and
it
could
be
useful.
F
You
know
to
make
see
the
see
a
record
I
useful,
more
broadly
than
just
for
act,
to
have
the
ability
for
people
to
express
those
validation
mechanisms
in
the
Carra
CAA
records,
as
well
as
well
as
Acme
validation
mechanisms.
So
the
the
the
impact
of
this
would
be
mainly
to
change
the
token
in
the
ca
record,
from
acne
methods
to
validation
methods.
F
But
the
registry
and
impact
would
be
that
we'd
want
to
kind
of
track
the
the
tokens
you're
using
for
these
non-acting
mechanisms,
as
well
as
for
the
acne
mechanism,
so
that
you
could
be
unambiguous,
and
so
the
the
acne
impact
was
that
we
might
take
the
registry
of
validation
mechanisms,
that's
defined
in
the
acne
spec
right
now,
and
generalize
that
to
a
validation
that
that's
registry
with
a
column.
That
indicates
whether
this
is
an
acne
mechanism.
So.
A
F
I
think
we
have
sufficient
joint
participation
that
could
probably
be
orchestrated,
yeah
I,
don't
expect
yeah
I
think
that,
like
I
said
that
could
probably
be
made
to
happen.
The
see
a
browser
firm
has
been
working
on
tightening
up
their
list
of
validation
mechanisms
and
have
being
more
restrictive
on
cas
and
so
the
it's
it's
something
that
is
under
under
work
in
that
space
and
so
they're
there
I
would
expect
there
would
be
appetite
for
aligning
with
the
sort
of
stuff
that
they
are
also.
F
A
A
That's
the
conversion
to
a
single
registry
theory,
and
as
long
as
everybody
is
okay
with
that
with
a
column
that
just
indicates
whether
it's
suitable
for
use
in
acne
or
not
I
think
that
that's
a
fun
idea,
but
we,
we
probably
do
need
some
confirmation
from
see
a
browser
forum
that
that
they're
not
going
to
get
upset
at
us
registering
their
validation
mechanisms.
In
such
a
thing.
I.
F
Also,
don't
think
the
registry
part
of
this
is
totally
necessary
if
you
look
at
the
way,
CAA
is
expressed
its
these
precise
values
used
in
the
CAA
fields
are
left
up
to
the
role
of
the
certificate
applicant
and
the
CA
I
think
the
expectation
is
basically
the
CA
will
express
to
the
applicant
what
values
it
should
put
in
there,
and
so
you
could
conceivably
get
by
with
just
defining
the
field
in
this
document,
not
the
values
that
go
in
that
field
and
if
there's
a
need
for
Interop
at
that
level
later,
we
could
come
along
and
specify
perhaps
a
new
registry
that
has
some
additional
values
beyond
acne
methods
that
you
go
in
that
field.
F
N
Hoffman,
so
one
of
the
reasons
why
I
was
asking
about
this
is
that
I've
just
started
following
see
a
browser
forum
stuff,
more
and
I.
One
thing
I
see
especially
on
CAA,
is
they're
still
wandering
around.
They
know
where
they
want
to
go,
but,
for
example,
someone
will
put
up
a
ballot
about
something
and
people
will
start
saying
yes
and
someone
say:
oh,
this
is
badly
worded
and
things
like
that.
So,
if
we're
going
to
rely
on
them,
I
think
we
need
to
rely
on
a
specific
date.
You
know
say
that
we
have.
N
You
know
the
the
base
requirements
of
a
certain
date
or
a
certain
version,
or
something
like
that.
Having
said
that,
I
think
that
this
is
actually
a
really
good
place.
Where
see
a
browser
forum
is
doing
some
reasonable
work.
That
CAA
is
one
of
the
most
visible
things
that
would
work,
especially
with
acne,
so
it
might
lay
things
a
bit
might
take,
make
them
take
longer,
but
I
think
it
would
actually
be
a
very
good
thing
for
us
to
consider.
O
Come
Wilson
did
you,
sir?
So
one
thing
that
I
think
the
cap
form
is
is
working
on,
is
you
know,
obviously
defining
these
ten
validation
methods
and
and
very
well
defined
validation
methods
that
are
that
are
allowed,
but
they're
also
trying
to
make
sure
that
those
sub
items
within
the
baseline
requirements
don't
change.
So
these
are
all
under
three
to
2.4
and
then
one
through
one
through
ten.
O
So
in
theory
we
could,
we
should
be
able
to
just
basically
register
those
identifiers
or
not
even
necessarily
registered
the
actual
identifier
z'
but
register
the
the
extension
and
have
those
identifiers
is
map
to
all
the
methods.
In
addition
for
public
CAS,
it's
going
to
be
required
to
track
the
version
of
the
baseline
requirements
and
the
method
which
of
those
sub
identifiers
in
the
baseline
requirements,
was
used
to
validate
a
domain.
So
it
might
make
sense
to
to
some
extent
coordinate
that
with
with
the
CAA
records
as
well,
since
they
have
to
track
those
anyway.
F
So
just
trying
to
bring
this
to
closure
I
think
the
question
here
is
whether
people
think
that
the
field
we're
defining
NCAA
here
should
be
specific
to
acting
methods
or
whether
we
think
that
it
would
be
useful
that
to
have
the
ability
to
express
non
acne
validations
in
this
field.
If
the
latter,
then
we
can
find
a
way
to
express
it.
Okay,.
A
A
A
Okay,
if
you
believe
what
we
should
be
registering
here-
are
validation
methods
which
are
valid
for
both
acne
and
for
non
acne
validation
methods.
Please
now
Kathleen
check
my
work
here.
I
believe
that
that
was
a
pretty
strong
in
favor.
Okay,
so
I
would
call
that
unanimity
of
the
interested
parties
for
finding
a
method
to
include
both
acne
and
non
acne.
A
P
Had
you
apologize
in
advance,
but
we're
gonna
talk,
nonetheless,
gonna
power
through
this
to
talk
about
stir
and
it's
exciting
applicability
to
acne.
So
what
is
start
the
first
place?
Stir?
Is
this
thing
we
cooked
up
over
in
that
art
area
over
there
as
an
attempt
to
rectify
the
long-standing
deficiency
in
the
SIP
protocol,
largely
created
by
myself
that
you
can't
really
authenticate
like
the
source
of
calls?
P
It
kind
of
like
kind
of
a
big
deal,
turned
out
to
be
a
big
enabler
for
things
like
robocalling,
a
lot
of
room
calling
actually
happened,
starting
in
the
SIP
world
and
ending
up
in
the
PSTN
world.
That's
kind
of
on
us,
so
we
gotta
do
something
about
it.
The
best
thing
we
come
up
with
to
do,
of
course,
is
to
have
a
cryptographic
way
to
a
test
authority
over
the
telephone
numbers
that
cause
seem
to
be
originating
from
for
that
we
need
certs
for
certs.
P
Reed
therefore
created
a
a
draft
ID
ester
of
certificates,
which
is
in
the
RFC,
editor
queue,
I,
think
or
48
or
XE
of
your
queue
now
I
forget
wedge,
but
this
creates
kind
of
two
axes
of
extension
to
traditional
x5
n
inserts
one
that
lets
you
attach
the
list
of
telephone
numbers,
and
some
cases
number
ranges
that
a
start
is
responsible
for.
In
other
cases,
these
things
called
SPC's,
which
are
service
writer
codes.
P
Mary
Barnes
is
going
to
talk
about
those
in
a
sec
I'm
going
to
drop
those
for
now,
but
anyway,
that's
what
stir
is
about.
We
got
to
figure
out
a
way
to
issue
and
provision
these
certs.
Our
best
thought
about
this
is
to
do
it
with
Acme
next
slide.
This
is
kind
of
what
stirrer
looks
like
just
to
give
you
a
broad
sense
of
it
right.
We'll
use
some
protocol,
like
sip
from
these
user.
Endpoints
probably
will
have
these
intermediaries
write
these
like
proxy
servers.
P
P
So
hey
that
seems
kind
of
like
a
no-brainer
like
we
could
just
use
Acme
right
figure
out
what
we
think
the
right
proofs
would
be
that
you
own
a
telephone
number
or
these
other
resources
that
we're
considering
and
get
those
down
to
these
authentication
services
where
they
need
to
go
then
have
search
stores.
We
can
acquire
those
search
to
validate
them
on
the
verification
service
top
right.
Okay,
next
slide.
P
So
when
it
comes
to
TNS
particular
what
are
interesting,
crews
well
I
mean
we've
looked
at
a
couple
ways
that
you
can
do
effective
control
sorts
of
proofs
that
you
know
we
thought
about.
Well,
how
do
we
do
this
for
the
DNS
right
in
a
communion?
There
are
things
like
SMS
return
route
ability
which
are
widely
used
today
is
kind
of
a
two-factor
off
meta,
so
mob
viously,
because
of
their
wide
use
by
banking
applications.
They've
been
of
a
special
interest
to
adversaries.
P
These
days,
who
have
engineered
a
few
ways
to
try
to
cheat
this
and
again
SMS
is
routed
in
interesting
ways
out
in
the
network.
The
ss7
network
is
not
not
not
cryptographically
secure
in
a
meaningful
way
where
all
the
stuff
takes
place.
So
we
got
to
be
cautious
about
that.
I
think
there's
some
belt-and-suspenders
things
we
can
do,
though,
that
will
rely,
at
least
in
part,
on
automated
tests
like
that,
you
can
also
like
interrogate
the
operating
system
of
smartphones
to
learn
things
about
it.
There
are
things
about
the
ss7
network.
You
can
query.
P
If
you
have
access
to
carrier
databases,
you
can
ask
the
things
that
kind
of
track
where
your
phone
is
connected
to
important
things
like
that,
then
they
might
help
anyway
to
get
this
all
together,
so
we're
kind
of
spitballing
that
a
bit
now
the
other
way
to
do.
This,
of
course,
is
through
some
kind
of
top-down
delegation,
because
in
most
jurisdictions
there
are
carriers
and
those
carriers
are
allocated
large
blocks
of
telephone
numbers
and
they
in
turn
assign
them
to
consumers
and
enterprises.
P
Everything
everybody
else
like
that,
so
we
want
to
have
a
way
that
you
can
let
a
carrier,
a
task
hey
for
this
number,
that
I
control
that
assigns
to
this
this
user.
This
enterprise,
they
should
be
able
to
come
to
ask
me
some
kind
of
token
get
that
and
an
redeem
it
for
a
cert
for
that
TM.
Wouldn't
it
be
great
I
mean
think
about
some
other
ways,
I
think
to
hear
about
next
life,
so
things
we
want
to
do
with
Acme.
We
love
to
start
stars,
pretty
cool.
P
We
want
these
things
be
to
be
dynamic,
because
telephone
number
assignment
unfortunateiy
is
kind
of
dynamic
like
if
you
have
an
end
user
number.
There
things
like
number
of
portability
that
may
move
around
what
carries
responsible
for
it.
So
we
need
some
agility
and
the
assignment
I
think
these
things
we'd
love
for
them
to
expire
and
be
renewed,
probably
at
less
than
a
day
interval,
at
least
for
it
to
be
possible
for
it
to
be
less
than
a
day
interval.
We
want
to
be
able
to
tweak
that
and
figure
it
out
today.
P
Obviously,
I
think
from
my
reading
of
start
is.
It
is
still
very
specific
to
the
lurk
use
case.
I
mean
it
has
any
bees
named
it
like
the
dno
that
don't
a
meme
owner
and
really
feel
like
to
apply
to
something
like
TNS.
We
need
to
have
it
slightly
more
generic
and
in
this
now,
but
in
other
respects,
I
think
it's
pretty
much
dead
on.
You
know,
I
I,
also
I,
guess
kind
of
wonder.
P
If
there
are
ways
other
than
delegation
which
affects
lakes,
it
assumes
again
that
lurk
--is--
model
that
there's
a
domain
name
owner
and
then
a
CDN
or
River.
That's
going
to
use
that
if
there
is
something
more
like
proofs,
you
know
that
are
there
automated,
like
effective
control
of
sorts
of
proves
that
could
be
built
into
the
automation
process
such
that
the
Acme
server?
P
Actually,
when
it's
going
to
reach
you,
the
sir,
doesn't
just
check
and
see
if
the
entity
delegated
from
cancel
your
subscription
is
for
this
or
but
but
instead
it
does
the
test
again
right
like
for
the
DNS
case.
If
it
looked
in
the
DNS
every
time
it
was
going
to
Auto
renew
said:
hey,
is
this
actually
still
valid
right?
So
I
think
there
might
be
things
like
that?
P
This
one
I'm,
largely
gonna,
defer
I
think
to
Mary's
presentation
as
well,
because
she's
kind
of
doing
a
lot
of
this
token
stuff
for
her
model
of
how
you
get
these
SPC's.
These
a
service
provider
codes,
but
definitely
I,
think
I'm
kind
of
surprised.
There
is
not
already
a
generic
mechanism
in
acne
that
lets.
P
You
say
like
hey
some
authority
over
this
namespace
can
issue
tokens
and
you
can
get
with
those
tokens
and
give
it
to
you
know
Boulder
and
get
back
a
sir
for
the
thing
that
that
authority
adjusted
to
provided
again
that
the
instance
of
Acme
trust
that
authority.
It
seems
to
be
like
there's
just
probably
a
lot
of
use
cases
that
could
rely
on
a
generic
mechanism
for
that
so
kind
of
about
I,
I'm
gonna,
advocate
after
Mary,
gives
gives
her
spiel
on
this,
that
we
make
that
more
generic
as
well
here.
P
So
it
just
seems
like
a
no-brainer
that
be
useful
next
time.
I
don't
know
if
a
lot
of
people
here
are
like
super
jazzed
about
this
use
case
I.
Think
it's
a
really
interesting
one.
There's
a
lot
of
interest
from
this
from
regulators
and
even
some
operators
in
North
America.
So
you
know
this.
This
draft
is
still
a
pretty
exploratory,
we're
still
trying
to
figure
out
what
we
think.
Some
of
the
proof
would
be
but
definitely
happy
to
work
with
folks
here
on
it.
P
If
energy
has
any
comments
or
questions
now
happy
to
hear
yeah
thanks
for
the
hollows
I
know,
I
feel
cheerful.
Yes,.
L
I'd,
better
spot
chicks
is
ethnic.
I
have
slight
warning
from
the
DNS
planet
because
we
tried
something
similar
with
enum,
where,
basically,
you
know,
the
hierarchy
is
that
the
carrier
has
control
over
the
prefix
and
then
in
theory
he
could
delegate
or
supply
the
records
for
the
customers.
But
whenever
you
try
to
you
know
gets
some
piece
of
the
cake
which
is
now
couriers.
L
They
were
refused
to
do
it,
so
in
failed
horribly,
because
you
know
the
carrier
didn't
delegate
anything
for
their
customers,
because
it
would
mean
that
their
customers
could
use
sip
and
basically,
you
know
avoid
the
carrier.
So
the
problem
is
with
the
the
identify
race
ties
to
the
carrier
more
or
less,
and
the
carrier
may
not
be
willing
to
do
anything
with
the
identifier.
If
it's
you
know
and
then
just
his
you
know,
income
so.
P
That
was
pretty
gnarly
after
great
I
guess
what
the
only
ray
of
hope
I
can
really
offer
for
this
beyond.
That
is
that
this
robocalling
stuff
has
gotten
a
lot
of
people.
Super
pissed,
like
you
know,
in
America,
like
senators
and
stuff,
come
to
the
FCC
when
we're
there
to
talk
about
it
and
like
yell
about
it,
because
people
call
them
all
day
and
are
like.
Why
am
I
getting
ruble
calls
and
can't
you
fix
this,
and
that
this
has
created
tremendous
regulatory
pressure
on
carriers
to
get
something.
P
That's
actually
good
work
here
and
as
a
consequence
of
that
that
there
was
never
anything
like
that
for
eat
up
my
promise,
like
wait,
I'm
one
of
the
largest,
you
know
mop
or
you're
still
in
the
world,
probably
a
new
service,
so
I
mean
it's!
It's
not
like.
You
know
this.
This
yeah
there
are
still
people
who
use
it
right,
and
these
these
little
initial
cases.
This
has
overwhelmingly
greater
applicability
and
interest
in
the
community.
P
Okay,
you
know
some
some
carriers,
though
I'm
sure
some
carriers
are
not
going
to
be
eager
to
do
that.
Sin
it'll
be
different
in
different
jurisdictions
and
I
think
there's
a
carrot
and
a
stick
to
offer
in
this.
Now
we
have
aster
approach
as
well
that
it's
almost
entirely
predicated
on
out
of
ban
mechanisms
that
don't
need
the
carriers
to
buy
in
for
him
to
work,
because
if
the
carriers
don't
want
to
do
it,
we
still
need
to
fix
this
and
we'll
fix
it.
Okay,.
Q
Well,
I'm,
not
a
carrier,
Mary
Barnes,
but
the
carriers
are
interested
in
solving
this
problem
now
and
they're
working
over
in
Addis
and
in
the
sit
forum.
There's
a
joint
task
group
called
the
NNI
task
group
and
I
can
send
the
documents
to
the
list
for
people
that
want
to
look
at
them
and
I'm
going
to
talk
about
something.
That's
output
from
that
group
in
a
few
minutes.
R
P
R
Ii
limits,
so
we
may
not
have
to
call
it
Y
number,
but
we've
got
on
the
DNS
path,
we're
at
least
aware
of
what
the
potential
problems
would
be.
Unsellable
resistance
from
the
carrier's
for
public
healings
to
do
with
revenue
protection
also
follows
stuff
like
that:
the
sale
in
save
the
tip
the
telephone
networks.
This
probably
could
be
made
to
work,
but
we
might
be
careful
how
we
use
the
terminology
of
the
language,
but
to
my
mentor
nobody
know:
you've
got
a
hierarchical
numbering
scheme
based
on
e.164.
That
reflects
very
nicely
into
the
DNS.
P
F
I've,
just
wonder:
mrs.
Richard
burns
this
one
to
clarify
the
proposal,
at
least
with
regard
to
identifying
how
expressing
telephone
numbers
in
this
document
is
still
to
happen.
An
independent
identifier
type
for
telephone
numbers
as
opposed
to
mapping
them
into
the
DNS
and
treating
them
as
DNS
identifiers.
Somehow,.
M
Q
Q
Okay,
so
changes
since
the
last
version,
and
we
won't
yet
ask
hands
of
who
read
it,
but
so
I
we
didn't
have
before
we
just
said
the
new
identifiers
there
and
we
had
our
new
challenge
type
and
we
didn't
have
a
lot
of
detail
and
how
it
worked.
So
I've
added
those
details
and
how
it
works
within
shaken
and
shaken
is
signature
based
handling
of
asserted
information
using
tokens.
Okay,
we
should
have
done
been
going
here.
So
that's
what
it
stands
for,
okay,
so
what
I
did
we
were
kind
of
overloading?
Q
You
know
the
key
authorization
field,
that's
used
for
other
challenge
times
like
TOS
sa9,
HTTP,
we're
kind
of
overloading
it,
because
what
we
have
is
this
token
and
within
the
token
we
actually
have
the
fingerprint,
which
was
what
was
being
carried
in
the
key
authorization
and
then
I
added
I
didn't
this
was
part
of
Martin
Thompson's,
not
here
right,
but
he
had
reviewed
the
document.
He
had
some
comments
about.
Q
So,
in
this
the
stic
a
and
the
stic
are
our
PK
I,
CAS
and
CRS
on
the
STI
PA,
and
this
is
what
John
was
highlighting.
We've
got
this
policy
administrator
and
he's
the
guy
that
authorizes
service
providers
to
actually
be
able
to
get
the
certificates
okay
and
so
they.
So
this
is
what
we've
got
the
service
provider
code
token
just
highlight.
This
is
a
logical
architecture
right
so,
but
you've
got.
We've
got
a
key
management
server,
which
is
the
Acme
client.
Q
We
have,
you
know,
secure
key
store
for
your
private
key
and
then
the
usual
and
then
the
STI
AES
and
VSR.
The
authentication
service
and
verification
service
defined
instert,
okay,
so
here's
the
model
for
the
I
can't
set
up
getting
the
token
and
then
doing
the
acne
account
registration.
So
this
is
where
the
STI
PA
is
the
authority.
If
you
will
and
so
he's
gonna
process
the
service
provider
code,
the
service
provider
is
going
to
set
up
an
account
with
him.
Q
Q
Okay,
the
next
one,
okay,
so
here
is
the
format
we
have
for
the
for
the
token,
so
it's
got
the
algorithm
type.
It's
has
j
TT
and
the
URL
to
the
STI
PA,
that's
actually
the
the
validator
and
in
the
payload
we've
got.
The
only
thing
unique
here
would
be
the
service
provider
code
value.
Now.
This
is
something
that
we
could
generis
eyes.
Possibly
here.
I
do
want
to
highlight.
So
within
our
token,
we
actually
have
the
fingerprint
of
the
AMIA
account
and
that's
kind
of
it
gives
us
a
little
bit
of
indirectness
right.
Q
You
know,
you've
got
your
valid
acme
account.
You
match
that
with
whoever
sending
acne
messages
and
then
you've
got
this
token
that
the
service
provider
signed.
One
thing
is
right:
now
we
have
the
fingerprint
being
generated
by
the
acne
client
and
then
being
sent
over
to
the
PA
when
he
wants
to
get
a
token,
we're
not
quite
sure,
if
that's
the
right
thing
to
do
or
we
have
the
PA,
the
policy
administrator
actually
create
that
so
Christian
bring
in
it.
Yeah.
S
Yes,
since
we
have
an
indirect
thing,
while
we
were
trying
to
model
the
HTTP
approach,
we
sort
of
thought
it
made
sense
that,
during
the
account
setup
or
sort
of
out-of-band
of
the
actual
transaction
of
getting
the
token,
you
send
the
fingerprint
to
the
policy
administrator
and
then
the
policy
ministers
that
and
then
embeds
it.
In
the
token
when
it's
returned,
when
the
token
is
actually
requested,
so
that's
sort
of
the
current
thought
looking
for
some
feedback
on
that
mechanism
and
whether
that
is
actually
the
correct
way
to
do
it,
but
I
think.
A
That
are
good,
quick
question
about
coke
and
reuse,
so
in
in
in
lemonade
in
previous
places,
we
have
this
concept
of
the
Pontic
style
token,
with
URL,
auth
and
I'm
wondering
in
this
particular
case,
whether
you
you
have
some
assumption
that
these
servers
to
write
our
code.
Tokens
are
single
time
consumable
or
are
they
something
that
somebody
could
use
multiple
times?
We're.
A
Q
S
So
we
would
assume
that
whatever
the
policy
is
for
the
time
to
live,
for
that
token
should
be
based
on
best
practices
and
everything
else
they
could
set
up,
because
the
authentication
service
could
be
it.
You
know
right
now,
it's
going
to
be
very,
you
know
it
could
be
hours
between
times
where
it's
going
to
get,
but
in
the
future,
if
we
have
more
telephone
certificates,
I
mean
it
could
be
constantly
getting
new
certificates.
So
the
question
is:
does
have
to
get
a
new
token
for
every
single
transaction.
S
A
A
L
L
A
Q
Q
S
S
Q
F
P
P
Q
Right
and
I
think
we're
open
now,
if
you
can
go
back
to
the
forum
and
I
think
we've
got
fields
in
there,
we've
got
dates
and
all
that
sorts
thing
dates
and
times,
and
all
of
that,
so
we
can
manage
it
that
way,
I
think,
okay,
so
let's
just
close
okay.
So
we
talked
about
the
identifiers
specific
to
that.
So
we
talked
about
everything
here,
so
I
don't
know.
Q
So
if
we
go
away
from
the
Tia
Nautilus,
then
the
first
point
is
a
mute
point,
because
John
would
not
be
using
this
mechanism
for
chance
right
or
you
could
you
could
do
it
for
the
delegated
right?
Okay,
okay,
okay,
okay,
so
that's
fine!
So
we've
done
actual.
Let's
go
look
at
the
identifier,
maybe
change
identifier,
and
then
we
can
make
it
something
you
can
reuse
as
well.
For
that
yeah.
P
We
can
have
two
yen
and
SPC
is
separate
identifiers
or
we
can
have
T
not
list,
it
doesn't
matter.
But
the
point.
Q
Q
That's
fine,
so
so,
okay
and
again
Chris
already
brought
up
the
point
of
we
don't
want
to.
We
need
to
get
this
done
pretty
quick,
because
people
are
implementing
stuff
right
now,
so
we
just
need
to
get
done
so
and
I'll
send
the
links
to
the
document,
because
there's
a
document
that
you
know
we're
using
and
we've
defined
how
we
use
it,
and
we
will
have
to
make
some
slight
changes
in
that
as
we
of
all
this
some
okay,
any
other
comments.
R
R
T
E
Yeah,
there
is
no
dynamic
and
content
there,
so
I'm
a
bit
anyway,
so
the
goal
is
to
get
jealous
certificates
for
email
services
like
SMTP,
submission,
IMAP
or
potentially,
and
all
other
related
stuff,
so
RFC
7817,
which
specifies
how
to
verify
email,
server,
TLS
identity
specifies
two
ways:
one
is
DNS.
Name
is
just
you
know,
host
name
where
the
service
is
running
or
sorry
name
is
a
host
name
plus
the
service
type,
which
allows
for
being
slightly
more
restrictive
in
certificates.
E
B
E
E
Both
SMTP
and
IMAP
have
capability
negotiation,
so
we
can
just
add
extra
capability
which
has
a
string
that
some
encoded
challenge.
So
it
would
be
easy
to
publish
some
information
there
well
pros
and
cons
again.
It's
you
know,
you
don't
need
to
use
dns,
but
you
potentially
need
to
modify
your
email
servers
implementations
again
for
somebody
who
is
writing
email
service,
you
might
prefer
just
to
modify
it
or
not
or
next
slide,
and
the
last
option
is
based
on
service
name
indicator
again.
This
is
just
a
tweak
on
existing
variant
advantage
here.
E
You
know
this
can
be
just
done
in
TLS
stack
once
and
used
in
different
services.
But
again
you
probably
because
if
you
don't
want
to
restart
your
email
service
to
start
advertising
this
to
augment
server,
you
need
some
way
to
be
able
to
dynamically
reload
this
information
and
publish
them
and
TLS.
So
it's
potential
slight
architecture,
change
next
slide.
E
So
there
are
three
options:
there
might
be
more
I'm,
not
particularly
vacating
that
we
pick
one
or
maybe
people
have
preferences
I'm,
not
suggesting
that
we
actually
try
to
narrow
those
down
here.
But
comments
are
welcome,
yeah
and
the
other
comment
is
in
order
to
accommodate
service
name
and
port
attributes,
I
added
them
to
the
JW,
yes
token,
just
so
that
they
can
be
conveyed
in
the
chat
in
the
requester
of
my
server.
It's.
A
Already
kind
of
a
deployment
state
of
the
state
of-the-art
question
when
somebody's
running
an
IMAP
service
on
multiple
hosts.
At
this
point
you
you've
gotten
a
group
of
these
up
to
they
typically
at
this
point,
present
the
same
certificate
or
do
they
present
independent
certificates,
which
cover
the
same
name
now.
A
In
in
in
what
you
want
to
design
for
this,
it
seems
like
some
of
what
you're
putting
forward
would
would
facilitate
the
first
and
some
the
second
in
particular.
If
you
wanted
a
different
certificate
for
each
one
of
the
ones
doing
it,
then
each
one
that
provided
the
proof
using
the
the
IMAP
okay
I'm,
getting
okay,
so
the
the
problem
so.
E
E
E
A
E
L
Sex
is
ethnic
I'm,
the
Danish
person,
so
I
would
go
for
the
DNS
option,
because
it's
just
easy
for
me,
but
I
have
a
protocol
question.
It
seems
that
the
Dane
and
the
self-signed
certificates,
which
are
starting
or
with
fingerprint
start
Indians,
finally
took
off
for
the
SMTP.
So
the
provocative
question
is
whether
it's
worth
the
hassle,
for
example.
Comcast
is
just
recently
announced
that
they
are
going
to
use
this
so
and
they
are
example
the
big
provider
right.
E
E
E
N
Paul
Hoffman
I
think
we
should
deal
with
this
because
there
is
getting
to
be
much
more
interest,
especially
for
authenticating
IMAP
servers
not
as
much
as
some
TP.
Simply
because
they
don't
mind
lies.
You
know
that
they
they
don't
mind
being
opportunistic
but
I'm
app
servers.
We
are
seeing
more
I
can't
get
to
my
IMAP
server,
because
the
certificates
wrong
so
I
would
like
to
see
us
do
one
and
I
think
one
is
option.
U
Andrea
shelter
I
would
prefer
the
second
option
to
extend
the
existing
protocols.
As
you
mentioned,
they
have
the
ability
to
negotiate
that
that
would
have
the
benefit
that
the
broad
soft
other
the
software
which
is
in
place
could
be
updated.
Take
some
yes,
but
in
in
that
case
also
there
smaller
instance,
a
smaller
installation
would
benefit
about
that.
The
the
large
installations
don't
care
about
it.
U
U
V
W
It's
consistent
out
of
those
three
options:
I
still
think
the
running
separate
HTTP
is
most
useful
for
that.
So
maybe
I
was
thinking
what,
if
we
could
just
deck
up
on
those
two
problems
and
be
able
to
request
via
HTTP
server
a
certificate
with
a
special
usage
for
for
a
map
or
other
services.
So,
and-
and
maybe
even
vice-versa,
if
you
maybe
would
be
usable
to
prove
HTTP
certificate
by
using
SMTP
or
him
up
server
like
they
can
put
those
two,
those
two
things
right.
E
E
F
Richard
Barnes
yeah
I
agree
that
we
don't
need
to
choose
just
one
here
and
I
really
let
some
other
folks
have
said
that
one
and
two
are
much
more
appealing
than
three
I
kind
of
understand.
The
appeal
of
two
of
using
defining
some
validation
mechanisms
based
on
the
email
protocols.
That
seems
perfectly
sensible
here
what's
unclear
to
me,
is
why
we
need
a
change
to
the
DNS
datian
mechanisms
to
support
this
use
case.
F
E
F
F
A
F
F
F
E
F
E
N
Paul
Hoffman
I
didn't
actually
expect
anybody
to
stand
up
in
support
still
using
the
you
know,
the
fake
HTTP
server,
so
I
would
like
to
speak
against
that
for
a
couple
of
reasons.
One
is
it's
lying
and
you
know
part
of
what
we're
trying
to
do
is
to
validate
like
real
things,
and
it's
long,
it's
saying:
I'm
the
server
who's
gonna
be
writing
the
certificate.
No
I'm,
not
I'm
handing
it
somebody
else,
but
the
other
is
acne,
is
about
trying
to
make
things
simpler.
N
So
saying,
oh,
you
need
to
set
up
this
this
lying
server
in
order
to
get
an
acne
certificate.
We're
now
pushing
towards.
You
know
a
level
of
difficulty
that
I,
don't
think
is
necessary
if
we
have
any
other
options,
but
really,
let's
not
promote
the
idea
of
lying
and
handing
the
certificate
off
to
somebody
else.
Okay,.
E
E
E
So
obviously
this
need
new
identifier.
Type
email
address
because
of
existing
acne
identifiers
type
is
not
sufficient,
and
then
you
just
see
my
rumbling
and
mumbling
on
the.
What
kind
of
proof
we
want
for
the
email
challenge-
and
my
current
thinking
is
that
while
we
can
do
something
similar
to
verification
done
when
you
subscribe
to
our
mailing
list,
you
know
there
is
some
kind
of
challenge
and
response,
but
hopefully
we
can
make
it
simpler
so
that
it
can
be.
E
E
H
Michael
Richardson
I
think
these
are
totally
reasonable
assumptions.
I
just
I
I,
wonder
if
we
actually
should
be
providing
the
challenge
in
a
clearly
articulate
clearly
defined
way
such
that
actually,
an
email
client
could
just
have
a
button
that
says
get
certificate
and
the
rest
of
it
is
handled
by
the
mullah
without
the
user.
Having
to
click
on
links
is
that
your
goal.
E
H
A
A
A
N
C
N
D
N
Than
one
hug
is
needed
on
that,
one
on
a
weekly
basis
and
I
work,
I
work
for
an
organization
that
has
a
good
IT
department.
There
are
people
in
here
who
need
way
more
hugs
than
I
do
because
they
have
to
run
outlook.
You
get
something
like
Outlook.
Someone
goes.
We
need
to
have
secure
Outlook,
let's
make
them
do
s
mine.
Yes,
this
would
be
used
and
remember.
Part
of
the
reason
of
acne
was
not
to
make
large
organizations
to
be
able
to
get
their
one
certificate
a
year
if
we're
free
or
small.
N
Ones
for
like
do
I
do
this
and
believe
me,
all
of
us
has
mine
users,
even
the
ones
like
Rome
right,
chaired
the
s/mime
working
group
for
a
long
time
it
still
sucks.
We
are
the
people
for
whom
this
would
absolutely
be
great.
So,
yes,
it
would
get
used
by
the
same
sort
of
target
audience
that
started
up
acne.
Can
we
do
it
securely?
N
G
So
make
of
that
what
you
will
and
and
there's
also
maybe
you've
noticed-
there's
been
little
green,
lock,
icons
showing
up
in
Gmail
and
different
places,
trying
to
say
something
about
the
path
security
of
smtp
between
you
and
the
destination.
That
seems
like
it
could
be
relevant
to
proof
of
control.
F
So
note
a
couple
of
things,
hopefully
with
optimism:
one
is
that
we
already
have
some
protections
against
intermediation
in
acne
in
terms
of
acne
being
intermediated,
because
we
had
this
idea
that
acne
Sia's
might
be
fronted
by
CD
ends.
So
the
existing
challenge
types
have
some
protections
against
that.
It's
why
we
have
the
key
authorization.
So
there
may
be
some
some
things
we
can
leverage
out
of
that's
to
deal
with
the
intermediary
here.
F
I
was
also
going
to
point
out
looking
well
anyway,
so
it
seems
like
they,
this
validation,
stuff
and
the
s1ba
or
SMS
sort
of
stuff.
The
jungle,
something
that
earlier
have
a
lot
of
common
properties
will
rather
common
risks.
So
it
probably
merits
thinking
about
those
together
and
following
some
common
design
patterns
and
people.
F
I
think
one
thing
we
might
be
able
to
leverage
in
terms
of
making
this
a
little
more
secure
as
I
was
hinting
at,
is
the
fact
that
you
have
some
existing.
You
know
through
acne,
you
have
you've
already
established,
you
know
binding
between
some
entity
and
it's
private
key,
and
so
you
can
at
least
validate
that.
The
thing
you
are
dealing
with
every
email
is
the
same
thing
you
were
dealing
with
in
Act,
so
I
have
slightly
more
Hope
than
the
maybe
Ted
was
expressing.
E
M
M
B
T
A
F
One
thing
I
would
be
interested
to
know
in
this
recharter
process
is
whether
there
are
any
CAS
that
are
actually
interested
in
issuing
certificates
of
these
flavors.
Obviously
we
can
define
a
lot
of
mechanism
here,
but
it
would
be
nice
if
you
could
focus
our
efforts
on
things
that
will
get
deployed.
F
I'm,
not
sure
if
we
have
any
that
are
in
the
room,
ready
to
say
anything
today,
but
I
think
it
would
be
useful
to
have
some
notion
of
that
for
the
working
group
as
we
it
would
be
useful
to
know
if
we
have
any
CAS
who
are
actually
considering
issuing
certificates.
That
would
rely
on
any
of
these
mechanisms.
I
think
that
has
been
maybe
validated
some
for
the
stirrer
mechanisms.
N
Paul
Hoffman
I
will
specifically
say
that
over
the
last
15
years,
I've
talked
to
CAS
about
a
s,
mine
certs
and
they
all
say
we'd
like
to
do
them,
because
they're,
regular
and
stuff,
we
just
don't
make
that
much
money
because
advertising
them.
You
know
like
all
of
our
advertising
budget
on
them,
is
wasted,
so
they
become
smaller
and
smaller
links
on
the
main
page,
I
believe.
N
If
we
do
something
with
s
mime
and
entity
certificates,
there
will
be
people
who
want
to
do
because
that
will
then
make
their
ability
as
long
as
you
know,
there's
pay
or
whatever
involved
that
makes
their
ability
to
renew
them
infinitely
easier.
So
we
may
not
have
many,
but
we
don't
need
many
fresh
mine.
We
need
a
couple
that
are
well
well
respected.
O
O
O
It's
yeah
I'll,
ask
me
you
can
have
as
many
as
you
want,
so
we're
still
getting
our
heads
around
acne
in
general
and
implementing
it
in
general.
So
I'm
not
sure
exactly
how
much
interested
we'd
have
in
these,
but
I
can
say
in
in
general.
You
know
we'd
want
to
make
it
as
easy
as
possible,
especially
once
we
have
acne
fully
implanted
to
get
to
support
all
of
our
products,
and
so
that's
that's,
where
we'll
likely
have
some
some
future
work
on
things
like
code
signing
and
document
signing
as
well.