►
From YouTube: IETF101-STIR-20180322-0930
Description
STIR meeting session at IETF101
2018/03/22 0930
https://datatracker.ietf.org/meeting/101/proceedings/
B
A
A
A
D
Okay,
okay,
so
this
is
a
status
update,
the
passport
extension
for
resource
priority
header.
You
know
authorization
provides
a
passport
extension
to
convey
a
cryptographically
signed
assertion
of
authorized
communications.
You
know
you
know
signing
the
resource
priority
header.
This
is
for
priority
services
such
as
government,
priority
services
and
sap,
national
security,
emergency
preparedness,
civil
emergency
911
safety
in
the
u.s.
firstnet
and
as
well
as
what's
being
deployed
here
in
the
UK
draft
zero
zero.
D
Now
going
back,
there
was
a
question
raised
on
the
list
with
respect
to
ordering
and
with
respect
to
ordering
an
our
pH
well.
First
of
all,
our
pH
only
has
one
claim.
The
compact
form
of
the
passport
is
not
specified
young
slash
supported,
and
there
is
an
example
of
you
know
the
syntax.
You
know
in
the
document.
You
know
where
the
claim
is.
D
D
E
Hi
John
Peterson,
so
I
have
a
slide
about
this.
Actually,
when
I'm
talking
about
divert
I
think
there
is
a
clerical
ambiguity.
That
is
entirely
my
fault.
That's
in
our
cat2
24
about
whether
or
not
the
the
values
of
the
PBT
equals
an
identity.
Header
should
be
quoted
or
not,
and
we
just
basically
have
it
as
like.
Oh
well,
the
value
of
in
they'd
be
enough
is
token,
but
then
in
other
parts
of
the
document
we
imply,
it
should
be
quoted.
So
I
think
we
need
to
clarify
that
you
haven't
unquoted
in
yours,
I.
E
Have
it
quoted
in,
like
all
of
the
other
extension
things
that
we're
doing?
We
should
have
one
way
of
doing
it.
So
I'm
a
is
a
last
call
comment,
depending
on
the
consensus
around
this
year.
You
know,
I
might
suggest
that
we
at
least
be
all
be
aligned
on
that.
This
is
like
a
really
tiny,
like
two
character
thing,
but
I
just
happen
to
know
this
near
to
I
thought
I'd
mention
it.
Thank
you.
A
F
E
Thank
you,
I'm,
going
to
talk
more
today
about
divert
then
so
just
to
the
chairs.
If
to
the
chairs,
if
we
run
over
ten
minutes
on
this
thing,
it's
okay,
because
I
have
like
very
little
to
say
about
OB
today
or
at
the
end
we
have
a
lot
to
say
about
two
Burke's
I'd
like
to
try
to
get
this
done,
because
everybody
seems
to.
A
E
E
A
lot
of
people
have
asked
about
this
about
how
we
handle
some
of
these
retargeting
cases
where
the
to
header
field
of
zip
is
signed
by
passport,
but
some
retargeting
entity
in
the
middle
of
the
network
actually
changes
to
as
you
go
through,
and
this
this
could
even
arise
actually
in
some
cases
where
they
don't
even
change
the
to,
but
you
just
have
received
through
the
network,
an
invite
that
was
originally
to
somebody
that
has
a
URI
that
you
just
don't
recognize.
It
doesn't
seem
to
be
you.
How
are
you
supposed
to
understand
secure
later?
E
This
wasn't
a
cut
and
paste
attack
that
somebody
like
plugged
in
from
an
invite
that
they
captured
there
was
at
that
going
to
somebody
else.
So
we
created
this.
This
divert
passport
extension
has
its
own
PPT
div
for
divert,
and
basically
it
does
a
function
similar
to
what
the
diversion
header
originally
the
inset,
did,
and
to
history
info
in
some
respects.
E
But
remember
because
of
the
way
we
do
canonical
is
stationed
in
stir
very
you
know,
kind
of
cosmetic
changes
to
the
URI,
even
changing
like
the
entire
host
portion
of
a
URI
that
has
a
telephone
number
and
the
user
part
doesn't
require
you
to
generate
a
new
passport.
So
in
fact
it
is
much
more
conservative
in
terms
of
where
how
many
times
you
would
need
to
include
a
a
diversion
and
passport
versus
what
you
had
to
do
in
history
info
or
the
original
version
header
next
slide.
E
Okay,
so
what's
new
people
are
kicking
the
tires
on
this,
and
necessarily
once
that
starts
happening
once
we're
doing
this
and
the
Addis
testbed
and
places
like
that.
We
start
hearing
issues.
This
one
was
a
favorite
of
mine.
Is
the
redirection
versus
retargeting,
so
we
designed
this
again
to
handle
these
retargeting
cases.
It's
important
to
remember
what
our
threat
model
is
here
in
ster
we're
trying
to
prevent
certain
classes
of
impersonation
attacks,
we're
not
really
out
to
try
to
track
service
logic.
E
The
way
that
history
and
foul
and
diversion
do
we're
here,
you're
hoping
that,
on
the
terminating
side,
the
entity
that
is
consuming
those
headers
may
make
some
decision
about
treatment
and
so
on,
it's
independent
of
determining
whether
or
not
the
originator
spoofed
the
call
right.
So
it
has.
It
just
has
a
different
threat
model
than
some
of
those.
Other
mechanisms
do
and
there's
a
sense
in
which
so
retargeting
actually
does
cause
a
practical
problem.
You've
thrown
an
invite
over
the
wall.
E
Somebody
changes
it
in
midstream,
there's
a
passport
attached
to
the
invite
and
then
the
changed.
Invite
and
the
passport
arrive
at
a
destination.
And
if
the
two
seem
to
be
out
of
parity
right,
then
the
verification
service
can
have
a
real
problem
figuring
out
whether
or
not
this
is.
They
should
trust
this
passport
for
3ot.
This
shouldn't
ordinarily
be
a
problem
because,
of
course,
when,
when
there's
a
redirection,
when
a
3xx
message
comes
back,
you
expect
usually
it
will
reach
the
UAC.
E
The
UAC
UAC
will
issue
a
new
invite
and
at
that
time
could
issue
a
new
passport.
Now,
if
you
go
deep
into
the
bowels
of
3261
in
the
UAC
behavior
section
right
now,
I
think
what
it
says
is
that
you
should,
when
you
receive
the
302,
keep
the
original.
But
it's
not
a
must.
In
some
cases
it
makes
more
sense
actually
for
the
UAC
to
change
the
to
reflect
the
contact
headers
that
were
sent
back
in
the
three
XX
in
the
backwards
direction
and
for
passport.
E
That's
actually
preferable
right
in
the
sense
of
you
want
the
to
header
field
to
correspond
to
the
destination
that
you
know,
you're
gonna
put
into
the
passport,
and
so,
if
you're
changing
with
spoon
and
password,
you
should
change
that
and
we
how
you
know
whether
it's
the
request,
URI
alone
or
both
the
request
URI
and
the
two
that
you
change
in
general.
Oh
there
should
be
no
problem
with
us.
E
Nonetheless,
we've
had
a
request
for
in
cases
where,
after
a
302,
a
diversion
header
would
be
added
to
have
some
way
to
have
a
passport
reflect
that
this
was
securely
diverted
and
again
I.
Don't
think
this
actually
is
like
salient
to
our
threat
model
like
it's,
not
there's
no
impersonation
attack
that
is
prevented
by
this.
E
It's
just
a
way
of
securing
that
service
logic
and
like
I'm,
I'm
kind
of
like
okay
I
can
see
how
we
can
adapt
this
to
this
case,
and
you
know
have
this:
have
this
passport
reflected
aversion
for
the
302
case,
even
if
it
doesn't
necessarily
solve
solve
the
problem?
So
what
I
did
and
this
this
revision
is
we
put
in
a
provision
now
that
in
a
3
xx
response,
it
is
possible
to
send
a
passport
back
to
the
UAC?
F
E
Yes,
for
personation
special,
we
only
care
about
what
is
in
the
new
invite,
that's
n.
But
if
you
want
to
capture
that
service
logic,
this
is
all
optional
and
like
ok,
if
you're
a
redirect
server,
you
may
send
back
a
passport
to
the
UAC
and
you
AC
may
use
it
if
it's
like
adding
a
diversion
header
and
it
wants
to
be
clear
about
or
a
history
and
file-
and
it
wants
to
be
super
clear
about
that.
It
was
securely
retargeted
from
that
that
destination
very.
G
Much
so
I
mean
yeah
I
think
we
want
a
broad
range
of
functionality,
support
various
use
cases
and
I
started
working
on
a
call
flow
document.
I
didn't
get
it
all
updated
in
time,
because
it's
incredibly
tedious
but
I
think
what
I'm
trying
to
do
is
do
some
Aereo's
and
show
how
we
can
leverage
stir
right
for
some
of
the
voicemail
hacking
scenarios.
I
think
it'll
be
very
helpful,
so
voicemail.
E
Vacuums
example:
I
mean
it's.
This
came
up
largely
actually
from
global
title
translation,
unsurprisingly
from
people
that
are
doing
800
dips
right
with
a
sip
that,
where
this
gets,
you
know,
3,
xx,
response
and
backwards
direction,
and
then
okay,
we're
gonna,
reflect
now
the
geographic
number
instead
of
the
free
phone
number,
and
but
we
want
to
preserve
the
original
free
phone
number
and
the
diversion
header
and
insert
way
we
can
securely.
You
know
show
that
that
was
the
original
call
number.
So
so
that's
what
we
have
now.
What
what
this
does?
E
This
has
changed
because
we've
said
in
the
past,
you
can't
have
like
an
identity
header
in
responses,
so
what
div
now
says
is
fine
and
a
3
X
ax,
you
can
have
a
passport
in
an
identity
header,
and
that
is
merely
there
as
an
optional
mechanism
that
the
UAC
could
snatch
that
from
and
stick
it
into
a
new
identity
and
push
it
back.
That's
what
we
have.
We
could
have
done
it
in
a
body
with
the
3
vo
2.
E
Instead,
if
people
want
to
talk
about
whether
implementation
choices
about
that
people,
care
about
this
would
be
a
good
time
to
dig
into
those.
The
simplest
thing
to
me
seem
to
be
just
allow
identity
in
the
backwards
direction
and
that
3
X
X
and
what
it
means
is
use.
This
and
future
invites
if
you
feel
like
it,
that
cool
with
everyone-
okay,
I'm,
not
seeing
anybody-
thinks
that
that
causes
any
huge
problems.
Krister
pointed
out
some
of
the
complexities
of
exactly
how
many
of
these
you
might
end
up
needing
and
that
can
get
complicated.
E
So,
based
on
that
I
decided
hedge
in
this
version
of
the
diverts
back.
What
I
say
now
is
the
current
guises.
You
should
do
nesting
for
in
band
you,
you
may
not,
and
it's
exactly
for
these
complex
cases
that
Krista
was
raising
where
you
know,
you've
got
multiple
authentication
services
that
are
adding
identity
headers
in
the
first
place,
then
your
end
up
with
like
multiple
you
know,
retargeting
from
that
that
you
want
you
want
this,
like
N
squared,
probably
rise
from
this,
and
so
it
seems
reasonable
still
to
have
multiple
identity
headers.
E
We
could
gain
a
sense
of
who
here
thinks
there
is
a
problem
with
like
the
identity,
header,
size
issue,
people
looking
at
me
nodding,
yes,
Martin
seems
to
think
so.
Cullen
seems
to
think
so.
Okay
I
mean
I,
believe
it
I
believe
you
that
they're
implementations
that
where
this
this
could
be
a
problem
realistically,
this
is
I
think
the
best
thing
for
us
to
do
for
now,
it's
easier
to
correlate
the
passports
if
we
nest
them
this
way,
but
you
know
I'm
not
going
to
mandate.
It
sounds
like
people
are
cool
with
that.
H
Adam
wrote
as
an
individual
I
apologize
for
the
hot
take,
but
my
initial
reaction
to
this
is
that,
having
more
than
one
way
to
do,
things
in
a
protocol
is
the
best
way
to
guarantee
non
entropolis
Asians.
So
if
we're
going
to
say
that
nesting
is
a
problem,
then
I'd
say
pull
it
out
altogether.
I,
don't
like
that
solution.
I
think
nesting
is
far
far
more
elegant
and
I
I
know
it'll,
be
really
hard
to
quantify.
E
E
There
are
blobs,
are
being
stored
and
like
unless
what
we're
gonna
do
is
what
we
have
to
do
is
give
keys
that,
would
let
you
be
able
to
decrypt
the
previous
ones
affected
right
or
something
similar
to
it
in
order
to
actually
you
know
you
get
some
kind
of
pointer
like
that
was
the
only
way
that
would
work
without
append,
so
we
started
from
there,
but
then
we're
like
well.
If
we
need
this
Radovan
and
we
think
we
can
use
it
for
in
band,
why
not
do
it
one
way?
E
E
H
E
Mean
the
one
thing
I'll
say
there
when
I
do
out
of
and
I'm
not
going
to
go
through
this
and
too
much
stuff
today,
but
there
are
these,
like
gateway
in
cases
where
you
might
want
at
a
gateway
to
pull
out
of
in
band
two
out
of
them,
and
things
like
that,
so
they
have
to
be
inter
workable
to,
or
at
least
that's
like
that's
a
key
use
case
for
it.
This.
This
is
how
we
ended
up
in
this
path
right
right.
So,
like
yeah,
there's
line
behind
you
on
a
wicked.
F
Yeah
Chris,
one
I,
think
it's
important
to
point
out
that
from
a
size
perspective
I
think
either
way
the
total
invite
size
will
be
very
similar.
It's
just
that
the
individual
header
is
long,
so
I
think
I'd
be
I'd
love
to
hear
from
people
that
are
concerned
more
about
the
individual
header
being
extremely
long
versus
the
total
size
of
the
invite.
D
Okay,
we
will
set
this
up:
Martin,
Donnelly,
okay,
so
for
us
the
total
size
of
the
M
by
E
is
less
a
problem,
because
we've
had
to
learn
how
to
fragment
and
take
care
of
that
a
long
long
time
ago.
This
isn't
going
over
the
air.
So
it's
not
an
issue.
Our
problem,
which
we
are
well,
our
correcting
was
the
size
of
a
single
header,
and
there
was
one
network
element
that
we
had
to
do
development
on
in
order
to
correct
that.
So
just
to
be
clear,
what
I
raised
my
hand
for
before
yeah.
E
J
Jackson
I'm,
pretty
sure,
I've
heard
it
written
code.
That
said
max
header
length,
10k,
but
I
mean
if
a
bug
was
reported
of
that,
it's
a
10
character
fix
and
a
recompile
like
I.
Just
when
I
really
thought
about
the
whole
issue
with
this
I'd
much
rather
see
us
do
the
same
thing
in
both
inbound
and
outbound
scan
he's
so
confusing.
If
we
don't
so,
let's
do
the
same
thing
and
do
one
thing
and
yeah
you
know
if
somebody
needs
to
fix
a
bug
logged
against
a
product
that
consists
of
basically
no
work.
I.
E
E
K
E
E
The
problem
with
OB
and
storing
passports
separately
is
that
OB
has
to
encrypt
the
passports
right,
and
so
the
problem
is
it's
encrypted,
each
one's
encrypted.
Basically,
to
that
that's
the
destination,
so
only
a
last
top
destination
can
decrypt
the
passport
for
at
and
so
what
this
does
is
it
creates.
So
there
are
there
ways
we
could
do
OB,
where
the
retargeting
entity
is
responsible
for
putting
in
you
know,
re-encrypted,
basically
the
original
passport
and
putting
it
in
key
to
the
new
destination.
But
this
is
how
we
ended
with
nesting
in
the
first
place.
E
So
like
then,
there's
be
two
blobs.
Both
you
know
that
you
would
end
up
downloading
and
decrypting,
for
you
know
for
the
same
endpoint.
Why
not
just
actually
bind
those?
So
you
know
which
is
supposed
to
go
with
which,
because
there
there
can
be
quite
an
assortment
right.
There,
they're
gonna
be
stored
as
resources
as
a
collection
effectively
for
a
particular
destination,
and
that's
how
we
ended
up
with
nesting.
Right
was
just
it
as
a
simple
way
of
correlating
this
thing,
so
Krister
Jun.
L
It's
Christian
I,
don't
have
a
problem
with
nesting
as
long
as
we
sort
out
these
things.
For
example,
if
you
have
multiple
incoming
separate
identity
headers,
because
I
assuming
a
nest,
all
of
them
into
this
diversion
header
or
I,
just
gonna
take
the
previous
one.
You
could
put
assumed
that
version
can
also
happen
multiple
times
during,
so
you
could
cut
one
incoming
which
all
city
contains
nesting.
So
so,
as
long
as
we
sorted
out,
I,
don't
think
we
should
assume
in
that.
Okay,
this
use
case.
L
E
Intuition
about
that,
as
I
think
we
already
discussed
in
the
list
was
that
for
each
such
independent,
a
s
that
has
provided
a
passport,
there
would
be
a
single
nested
diversion
for
each
time.
It
gets
diverted
right.
So,
in
other
words
like
that,
you
know
at
you
may
go
through
as
you
go
through
the
network,
you
may
accumulate
more
and
more
of
these
diversions
at
different
phases,
but,
like,
however,
many
identity
headers
there
are
will
reflect
how
many
different
authentication
services
you
know
decided
to
chip
into
this.
As
you
go.
A
L
L
E
L
E
With
and
you
nest
it
and
then
you
take
the
secondary,
then
you
had
her
and
you
nest
it,
and
there
are
two
headers
that
are
each
going
to
have
one
nesting
in
them
sure
I
mean
you,
reach
the
second
service
you're
going
to
read
nest
for
each
of
those
two,
and
if
a
third
identity
header
got
added
along
way,
you
must
have
one
live
nesting
in
that
one.
That's.
E
It's
just
think
about,
like
we
want
each
authentication
service
that
is
separately,
adding
a
passport
to
the
request
to
add
its
own
identity,
header,
basically
in
inbound,
and
yes,
we
can
clarify
this
if
this
is
a
if
this
is
which
one
clarified,
how
we're
doing
for
time.
Okay,
how
many?
How
many
more
minutes
we
have
of
my
20
flavor
game?
I'm,
sorry,.
J
E
Nick
well
next
slide
anyway,
and
we'll
keep
talking
when
I
figure
that
out
there's
been
Sibelius
list
traffic
in
general.
About
ordering
of
these
things,
I
I
have
been
I'll,
admit
a
bit
confused
about
some
of
this
I'm,
not
sure,
there's
really
a
problem
ordering
identity,
header
fields
at
all,
because
what
I
just
said
right
I
mean
to
me
like.
If
one
identity
header
is
being
added
by
each
authentication
service,
and
then
nesting
is
what
occurs,
it
doesn't
matter
what
order
those
are
in
and
I,
frankly,
I.
E
Don't
trust
intermediaries
to
preserve
the
order
anyway,
these
aren't
via
headers
right,
like
I
I
would
not
be
surprised
if
these
things
were
munge,
dand
spit
out
and
completely
different
orders
when
they
go
through
a
species.
So
if
we
rather
design
a
mechanism
that
does
not
rely
on
expecting
that
those
you
know,
header
fields
are
actually
ordered
in
the
request.
Is
there
something?
Is
there
something
I'm
missing
in
this?
Where
there's
like?
Actually
some
attackers
it
can
result
in
this
Chris.
L
No
I
think
it
was
more
from
a
sea
perspective
because,
as
far
as
I
well
I
know
the
RFC,
3261
and
also
other
extension
RFC
is
defining
new
headers,
where
you
can
have
multiple
instances
for
each
header.
This
is
always
a
description.
How
you
add
new
ones,
do
you
have
there?
Do
you
put
them
from
top
to
bottom
or
or
do
you
put
them
from
bottom
to
up?
So
it
was
more.
You
know,
protocol
things,
I
think
we
describe
that
for
each
other
header,
where
you
can
have
multiple
instances.
L
My
question
was:
why
don't
we
do
that
fried
end
it
to
a
you
know
and
and
and
I
agree
with
you
it.
Currently,
we
don't
have
any
use
cases
where
it
really
matters,
but
I'm
just
thinking
in
future
could
if
there
could
come
some,
because
this
is
a
difficult
thing
to
do.
We
just
need
to
specify
it
so
so
obviously
it
would
be
an
update
to
to
to
the
RFC
a
to
to
because
it's
not
really
a
passport
specific.
It.
E
Here
concerns
about
ordering
at
the
claims
of
passport
and
that
it
seems
unnecessary
because
ultimately,
there
is
a
canonicalization
in
serialization
algorithm
for
it
that
we're
going
to
execute.
You
know
before
we
actually
pass
this
through,
but
I
think
it
does
no
harm
to
have
to
specify
the
order
there.
So
hey!
You
know
it's
the
flip
side
of
the
same
argument.
It
sure
we
could
fix
that
to
make
it
so
that
it's
not
required
to
say
what
the
order
is
for
these
things.
E
L
E
E
L
This
all
came
out
from
there
from
you
have
in
art,
because
all
the
must
which
you
have
in
in
a
two
to
five,
which
is
that
it
you
must
describe-
and
this
becomes
a
problem
when
you
use
the
compact.
As
long
as
you
have
everything
in
the
JSON,
it
doesn't
cause
a
problem
because
but
when,
for
example,
if
you're
going
to
use
the
are
pH,
for
example
in
your
aura,
you
have
the
resource
priority,
sip
header
field,
so
you
may
choose
not
to
put
it
in
Internet
into
the
JSON.
E
L
E
That
you
deterministically
serialized
JSON,
and
we
yes
because
right
the
the
you
basically
you
take
that
and
alpha
dies
the
sat
in
the
way
that
they
define.
So
it's
never
to
be
ambiguous.
How
the
signature
comes
out
from
that
right.
I
mean
no
matter
how
you
build
the
claims
object
in
its
JSON
representation
and
correct
me.
If
I'm
wrong,
you
like
the
serialization,
will
result
in
those
being
sorted
properly
and
sure.
E
I
understand
what
you
say
that
the
language
is
useless,
because
you
I
agree
that
it
is
useless
the
language
that
is
in
there.
But,
however,
it's
uselessness
is
not
enough
reason
for
me
to
of,
like
you
know,
change
this
isn't
actually
broke
it
like
it's
not
like.
This
won't
work
because
of
that
it's
just
useless.
F
E
Okay,
another
suggestion
again
that
we
separate
out
opt
from
div
I'm
open
to
that,
like
you
know,
if
we
think
there
are
other
extensions
that
might
want
to
have
embedded
passports
within
them
other
than
div,
and
we
want
to
be
able
to
like
point
to
those
I
can
do
that.
But
does
anybody
else
care
like
it's
the
kind
of
thing
where
I'm
not
sure
what
that
extension
would
be?
That
would
necessitate
that.
E
Does
anybody
say
me
feel
strongly
about
this
either
way
about
whether
app
should
be
kind
of
under
div,
and
maybe
we
should.
We
would
define
it
differently
if
we
needed
another
way
to
bind
these
things
together
again.
This
is
one
of
these
things
where
that's
it's
such
a
minor
matter
of
the
syntax
that
I
don't
care.
A
E
I
mean
I,
guess
I
guess,
on
balance,
probably
I
would
separate
it
out.
I
think
it's
it's
easy
to
do
so,
in
other
words
like
op
would
not
be
under
dip,
it
would
be
a
separate
claim
and
that
you
know
would
just
appear
concurrently
with
div
and
then
so
just
in
case.
Some
future
extension
also
wants
to
use
off.
They
can
say
we're
using
opt
as
specified
in
RFC
buh-buh-buh-buh
I'll.
Do
that
so
every
every
okay
with
that.
Okay,
next.
E
E
You
know,
there's
not
much
use
in
quoting
it.
To
be
honest,
it's
not
like.
We
gain
a
lot
of
value.
That's
like
too
wasted
bytes
pretty
much,
so
we
could
also
just
back
that
out
hu
24
once
I'd,
rather
do
it
unquoted
again.
This
is
one
of
these
things.
The
two
choices
are
so
similar
I
hesitate
to
even
pose
it
as
a
question,
but
does
anybody
feel
strongly
about
how
we
should
try
to
repair
this
clerical
oversight
on
our
part.
E
Yeah,
so
my
intuition
is
that
so
I
I
had
it
all
quoted
in
it.
The
hu
24
does
say
it's
coded.
We
could
just
put
something
into
one
of
these
passport
documents.
It
says,
oh
by
the
way,
clarifying
what
we
did
mean
quoted
like
because,
because
it
does
say
quoted
in
there,
we
need
to
like
change
it
into
24.
Did
that
that
one
stray
piece
of
text
that
talks
about
it
being
quoted
this.
E
E
So
you
can
just
look
at
the
header
and
immediately
say:
oh
I
know
whether
or
not
I
understand
this
passport
type
without
having
to
crack
crack
that
the
JWT
open,
in
addition,
of
course,
for
Compaq
forum,
obviously
you
won't
have
a
deity
to
crack
open,
so
I
kind
of
like
it
as
mandatory
it's
been
raised.
Why
did
we
do
that?
E
E
E
Same
reason,
we
have
info
be
mandatory
friend,
so
I
I
do
appreciate
Krister
taking
a
closer
read
of
this.
We
need
some
more
closer
reads.
I
think
this
is
getting
close
to
done.
I'll
patch
in
the
stuff
that
we've
discussed
here
today,
but
I
think
we're
getting
pretty
close
on
this.
Okay.
A
A
M
E
This
is
the
picture
we
got
the
CPS,
we
got
the
a
s
and
the
BS
they're,
putting
passports
up
in
this
service,
probably
a
web
service
because
they
cannot
tunnel
signaling
in
band
and
a
s
ISM.
Yes,
here
could
be
end
user
devices
could
be
PBX
is
could
be,
gateways
could
be
whatever
this
is
the
generic
model
Forster
out-of-band
next
slide.
So
what's
new,
all
I
really
did
this
time.
So
we
added
some
text
about
the
smbs
behavior.
If
you
read
80
to
24,
actually
that's
the
place
where
we
do
a
s
and
BS
behavior.
E
It
is
like
really
release
if
specific
and
so
I've
written
a
version
of
that
that
rips
all
of
that
out.
So
it
is
now
very
generic
to
how
you
would
just
evaluate
a
passport
against.
You
know
a
CDR
right,
which
is
basically
what
we're
I
think
we
have
to
go
on
in
the
audubon
case,
and
you
know,
some
of
the
steps
are
specific
to
how
you
interface
with
the
CPS,
like
you
know,
acquiring
the
necessary
keys
and
those
kinds
of
things,
but
there's
now
some
behavior
for
that.
E
That
I
think
gives
us
a
much
better
sense
of
what
in
a
SPS
would
be
like
for
out
a
band
and
I
mocked
up
a
little
rest
interface
for
it.
If
echo
were
here,
I'm
sure
he'd
be
pummeling
me
for
all
the
problems
that
I
introduced
and
that.
But
the
point
was
just
to
give
a
sense
of
like
what
a
rest
interface
might
look
like
to
a
CPS.
E
It's
a
pretty
obvious
approach,
does
not
integrate
any
of
ecers
fancy
flood
control
mechanisms
using
that
unblinded
hash
stuff
at
the
moment
that
I
don't
understand
that
he
needs
to
do
himself,
but
we
will.
We
will
at
least
have
a
description
of
how
to
do
that,
probably
in
the
next
version
of
draft
next.
E
We
need
to
specify
at
least
one
CPS
discovery
mechanism,
I
think
what
I'm
leaning
towards
for
this
to
be
honest,
these
days
and
I
hope
Martin
if
you've
taken
your
your
blood
pressure
medication
today,
what
I've
been
leaning
towards
in
this
is
actually
you
know
using
the
credentials
themselves
to
point
to
the
CPS,
in
other
words,
having
the
certs
and
the
cert
discovery
process,
be
what
points
you
to
the
CPS
they'll
just
be
like
a
field
in
this
earth.
It's
like!
E
E
You
still
wait.
That's
Martin
Martin!
If
we
need
to
call
the
paramedics
okay
so
seriously,
we'll
do
something.
This
is
a
much
study
problem,
service,
discovery,
I!
Think
it's
really
the
last
outstanding
problem.
We
don't
understand
well
for
this
I
think
that
is
the
way
that
is
probably
closest
to
the
spirit
of
how
out-of-band
is
supposed
to
work.
However,
and
so
we
may
mock
that
up
and
just
know,
kick
the
tires
on
it
see
if
it
works,
might
actually
get
us
somewhere.
A
M
M
N
N
M
You
thanks
Brian
and
actually
I,
actually
just
go
back
to
that.
The
first
one
just
for
a
moment,
because
one
question
I
get
is,
is
I
Anna
up
for
this,
and
the
answer
is
yes.
I
Anna
is
up
for
this,
and
I
also
wanted
to
thank
Chris
derp,
because
he
did
ask
a
question
on
the
list.
Alright,
now
we
can
go
to
the
next
one,
and
this
will
be
the
only
time
I'll
do
the
problem
statement,
because
people
should
have
read
the
draft.
M
Basically,
as
we
know,
stur
certificate
authorities
are
not
the
same
as
web
certificate
authorities.
It's
an
absolute
statement.
I
know
in
a
lot
of
countries
are
going
to
be
different
companies.
Doing
that.
It's
also
a
structural
statement
as
the
roots
of
trust
problem
is
different.
I'm
not
going
to
read
the
rest
of
this
to
you,
but
if
you're
thinking,
why
do
we
need
different
stir
routes?
You
probably
haven't
been
participating
in
stir
for
the
past
five
years.
M
M
Won
part
of
how
they're
different
is,
who
can
be
the
CA
for
a
given
country's
telephone
number
appears
to
be
mandated
by
the
country.
If
you
just
hit
the
build
there
you'll
see,
Canada
is
insisting
it
be
a
Canadian
company.
The
United
States
is
expecting
it
to
be
a
US
company.
You
can
imagine
similar
things
going
on,
for,
like
say
the
European,
Union,
Russia,
China
and
so
on.
M
So
this
is
addressing
sort
of
a
practical
issue.
You
know
it's
pretty
easy.
If
you're
Rogers
in
Canada
CRTC
is
going
to
tell
you
who
the
ster
certificate
authority
is
in
the
US.
You
know
the
FCC
there's
a
process
going
on
now
and
we
can
tell
Martin
you
know
who
the
route
of
trust
is.
But
what
happens
when
we
get
a
call
in
the
UK?
M
That's
originated
in
Canada.
How
does
that
operator
of
BT
know
who's
supposed
to
be
the
official
certificate
authority
that
you're
the
root
of
trust
for
that?
So
if
we
take
the
next
one
and
answer-
and
this
is
just
you
know-
the
proposal
is
that
we
create
a
stir
root
certificate
registry
which
basically
Maps
countries
to
read
certificates
to
the
public
keys.
You
have
the
root
certificates
I.
It
would
be
managed
by
I
Anna
in
the
document.
M
M
For
example,
you
know
if
there
is,
it
turns
out
a
single
provider
for
plus
1.
That's
handles
very
nicely.
You
could
imagine
a
single
certificate
authority
for
all
of
plus
3
and
plus
four,
except
for
the
countries
that
want
their
own
below
that.
Also
it
handles
opting
out.
So,
for
example,
you
could
say
the
US
and
Canada
might
have
their
own
country
specific,
designated
root
certificate
authorities,
but
Montserrat's
not
doing
stir
at
all,
and
so
we've
got
away.
M
We
go
to
the
next
slide,
a
little
more
detail
on
the
registry
policy.
This
is
the
identical
process
is
used
for
the
time
zone
database.
Basically,
we
have
expert
review
that
happens
at
ITU
D
and
no
that's
not
a
typo.
It
is
ITU
D
that
publishes
a
directory
of
national
numbering
authorities
so,
like
it
basically
says
it's
the
FCC
for
the
u.s.
it's
Ofcom
for
the
UK
crtc
for
Canada
and
they
are
likely
to
just
publish
who
their
root
certificates
are.
M
The
expert
can
obviously
call
them
and
if
you
can't
figure
it
out
or
if
there's
a
dispute
to
take
it
to
the
list,
which
is
again
the
same
model,
we
have
for
the
time
zone
database
with
that
there
actually
are
and
I
found
two
open
issues.
One
is
in
the
draft
another
one
that
kind
of
came
into
my
mind
as
I
was
writing
up
the
slide
so
go
to
the
next
slide.
M
One
is
right
now
in
the
draft
I'm
expecting
that
they're
going
to
be
as
many
disputes
on
this
as
the
time
zone
database
which
to
date,
has
been
none
so
rather
than
set
up
a
new
list.
I
said:
hey
take
it
to
the
RAI
list,
but
you
know
an
open
issue
there.
If
we
did
want
to
do
this
model,
is
you
know,
do
we
want
a
dedicated
list
for
disputes
here?
M
The
other
is
whether
or
not
these
two
registries
actually
have
lives
of
their
own,
because
it
kind
of
dawned
on
me
having
a
EE
164
annex
D.
So
that's
the
national
number
codes,
+
1
+,
3,
3,
+,
3
2,
the
actual
countries
underneath
that
whether
that
would
be
generally
useful
beyond
stir,
although
of
course
this
just
establishes
the
registry,
so
we
could
keep
it
in
one
document,
so
those
will
be
open
issues
that
I've
seen
from
the
limited
discussion
on
the
list
and
people
coming
up
to
me.
Otherwise,
any
any
other
open
issues.
L
This
is
Christiana
and
I
gave
gave
a
comment
if
you
go
by
one
slide
back
regarding
the
expert
review.
I
think
then
drafts
need.
The
current
version
does
say
anything
about
what
what's
expected
from
our
expert
review.
Normally
in
the
CPR,
for
example,
the
expert
review
checks,
you
know,
does
this
it's
quite
easy
for
the
for
expert
reviewer
to
actually
go
and
check
RFC's
and
so
on.
L
But
what
is
I
mean
it's
you
mentioned,
for
example,
that
the
expert
reviewer
may
actually
call
this
country
so
and
so
on,
or
it
may
check
this
ITU
the
database
and
all
this
kind
of
thing
I
think
that's
needs
to
be
spelled
out,
because
you
know
this.
This
requires
a
little
more
from
the
experts
when
what
what
we
require,
for
example,
when
someone
registers
an
SDP
attribute
or
something
great.
F
M
M
What
do
you
think
and
then
obviously
others
are
not
going
to
do
anything
and
that's
why
it
is
a
little
loosey-goosey,
but
obviously
you
can
tighten
that
up
a
little
bit
just
say
you
know
here
where
the
well
I
say
where
the
resources
are,
but
to
actually
say
alright,
I
told
you
where
the
resources
are.
You
might
want
to
look
at
them.
O
Jonathan
Rosenberg,
like
others,
have
commented,
I
mean
I.
Think
expert
review
is
an
is
sort
of
an
understatement.
I
mean
in
a
lot
of
ways.
This
is
this
is
like
running
a
CA,
and
this
Ayana
expert
is
gonna,
be
responsible
for
like
issuing
the
equivalent
of
evey
certs,
but
not
nearly
as
low
touched
and
easy
as
that,
because
I'm
like
this
is
basically
like.
Is
this
really
the
owner
of
this
country?
You
know?
Is
this
a
person
who
can
issue
certificates
for
the
phone
number
for
phone
numbers?
O
An
entire
country
like
I
mean
this
isn't
going
to
be
like
the
time
zone
database
like
if
this
is
someone
who
just
press
the
okay
button.
This
is
gonna,
be
like
three
minutes
til,
it's
attacked
by
you
know.
Spammers
are
like
issuing
or
bad
guy
trying
to
convince
the
expert
reviewer
to
approve
them,
as
basically
as
a
CA
I
mean
this
like
the
root
CA
for
the
root,
CAS
I
mean
I,
can't
think
of
something
that's
more
dangerous
and
to
put
it
in
the
hands
of
like
well
it'll.
Just
be
expert
review.
O
M
E
John
Peterson
here
to
advocate
for
the
ITU
doing
this
No,
so
I
am
gonna
advocate
for
us
not
doing
it,
though,
for
any
number
of
reasons,
one
of
which
is
so
I
think
we're
conflating.
What
stir
is
in
some
respects
with
what
shakin
is
in
this
entire
discussion.
I
understand
what
the
GA
is
and
the
PA
is,
but
those
are
not
concepts
that
are
that
are
ITF
concepts.
E
Stir
is
a
technology
that
is
applicable
to
things
beyond
what
a
national
authority
wants
to
do
and
I
think
the
scope
of
this
well
I
mean
again
I
completely
understand
the
problem.
You're
articulating
I'm
sure
that
people
inside
groups,
you
understand
that
the
problem
you're
articulating
very
well
as
well
and
I'll,
be
very,
very
interested
in
this
proposal
and
in
creating
a
series
of
liaisons
that
look.
E
You
know
they're
just
as
complex
and
ultimately
just
is
self-defeating
as
the
ones
we
generated
for
public
ena,
which
led
us
down
a
long
rat
hole
of
like
IB
and
Geneva
meetings
that
ultimately
resulted
in
us
doing.
Private
enum
instead
right
I
mean
that
we
created
something
so
unwieldy.
It
was
impossible
for
us
to
find
a
middle
ground
between
us
where
anything
tractable
could
happen.
So
it's
not
that
I
don't
understand
the
problem
like
Jonathan
I'm,
just
kind
of
in
the
boat
of
III
I.
Don't
know
the
right
way
to
do
this.
I
do
know.
E
I
I
can't
imagine
the
liability
that
we
would
be
incurring
for
it
from
this.
If
we
we
put
this
on
I
Anna's
shoulders,
in
addition
to
everything
else,
we
do
here
and
I
decide
own
think
this.
Is
this?
Isn't
our
expertise
this
this?
We
aren't
responsible
for
the
concepts
that
are
built
in
behind
this
and
I.
Don't
want
to
import
all
that's
into
the
work
we
do
here.
The
ITF
generally
is
not
in
the
business
of
telling
people
who
to
trust
in
life
and
I
really
would
not
like
us
to
be
in
that
business.
M
E
E
Frankly,
it's
close
to
what
Jonathan
was
just
describing
is
talking
about
the
root
of
the
root
CAS
right,
there's,
a
sense
in
which
the
root
of
authority
for
naming
for
the
web
PKI
does
reside
with
I
can
because
the
control
of
the
gTLDs
and
the
ccTLDs,
and
so
on,
resides
there
well
to
a
certain
extent,
so
I
mean
yeah.
I.
Just
don't
see
this.
This
doesn't
feel
to
me
like
the
place
where
our
views
of
this
are
going
to
be
the
ones
that
are
gonna
carry
the
day.
I
just
figure
just.
E
Wow
I
mean
when
you
put
it
that
way,
that's
even
scarier,
so
I
mean
what
what
would
it
mean
for
the
ITF
not
to
be
involved
in
the
creation
of
registry
like
this
in
the
Ayana
right,
so
yeah
I.
If
you
think
that
I
can
should
be
able
to
create
their
own
INRI
tissues,
that
do
things
like
this.
That
would
be
its
own
whole
thing.
Like
I,
said
I,
you
were,
you
were
there
for
the
scene,
stuff
man,
you
remember
this
was
like
you
heard
the
IV
like
hassles.
E
We
went
through
with
this,
and
I
mean
it
was
a.
It
was
a
gong
show
and
it
ultimately
led
to
us
exploding
all
of
that
work
and
replacing
it
with.
Let's
just
let
people
trust
the
databases
that
they
have,
rather
than
trying
to
build
some
global
monolithic.
You
know
hierarchical
system
right
and
it's
because
we're
not
good
at
telling
people
who
they
should
trust,
and
why
sorry,
there's
a
long.
P
One
of
the
difficulties
that
we
had
with
the
email
special
in
the
ITU
Sayed
was
actually
getting
a
definitive
statement
out
of
administration
out
of
an
administration
about
who
speaks
for
the
numbering
plan
in
that
country,
and
you
cannot
rely
purely
on
the
public
information
that's
published
by
HUD
or
anybody
else
in
that
organization.
In
Geneva
and
back
in
the
days
of
the
email
we
actually
had
a
case
of
one
country
where
the
official
ITU
contact
did
not
want
of
anything
to
do
with
Iran
for
that
country.
P
But
the
people
who
went
to
study
group
two
meetings
did
want
to
get
the
national
delegation
and
the
problem
is.
If
you
then
talk
to
an
expert
review,
you
cannot
be
guaranteed.
You're
talking
about
something
that
can
really
speak
definitively
about
what's
being
done
and
I
think,
unfortunately,
this
is
Poland.
P
Q
The
premise
of
this
document
is
that
the
relying
parties
in
this
system
are
not
going
to
invest
the
effort
to
develop
their
own
trust
lists
of
their
own
lists
of
routes,
authorities
that
they're
going
to
trust
they're,
going
to
outsource
this
to
some
registry
and
just
blindly
trust
whatever
the
expert
for
this
registry
says
it
is,
is
the
right
thing?
That's
a
pretty
big
assumption
in
my
mind,
like
our
experience
in
every
other
PKI
we've
seen,
is
that
people
take
this
decision
of
relying
parties.
Q
Take
this
decision
about
who
to
trust
very
seriously,
gonna
want
to
do
their
own
validation
and
their
own
vetting,
and
so
there's
some
question
as
to
whether
this
is
valuable
at
all.
It
seems
like
to
the
degree
that
it
does
add
value.
It
will
be
as
a
starting
point
for
people
to
do
their
own
investigations
for
the
ATT
legal
department
to
go
figure
out
who's,
the
right
Authority
for
malaysia
and,
if
they're
gonna
accept
invalidate
things
from
there.
Q
And
so,
if
that's
and
since
that's
the
case,
it
seems
like
the
decision-making
part
of
this
is
almost
not
valuable
at
all.
You
might
as
well
have
a
first-come,
first-serve
registry,
where
you
can
drop
something
in
and
say
you
know:
I
am
a
provider
for
Malaysia
and
there
might
be
five
or
six
in
there,
but
it's
up
to
the
relying
parties
to
sort
that
out
because
they
need
to
do
that
vetting
anyway.
They
shouldn't
just
be
blindly
relying
on.
What's
in
the
list.
R
Pat
Sarpy
Ofcom
from
a
regulatory
perspective.
This
raises
some
interesting
challenges
and
I
think
that
we
would
have
some
reservations
about
handing
off
the
assertion
of
the
root
CA
to
a
third
party
is
worth
bearing
in
mind,
Erik,
that
in
the
United
Kingdom
the
regulator,
services,
failure
of
said
services
at
a
larger
scale
can
impose
fines
for
operators.
So
there's
there's
an
issue
there
about
whether
if
I
was
an
operator
I'd
be
satisfied
to,
in
effect,
give
it
to
a
third
party
where
there
is
some
liability.
R
We
know
that
you
know
there
is
a
necessity
to
have
some
form
of
root
CA
and
how
that
will
be
organized
I
would
suggest
you
know
the
the
door.
Ofcom
is
always
open
to
yourselves
here
at
the
IDF
willing,
and
he
could
speak
to
you
and
I
would
also
urge
you
to
speak
to
organizations
such
as
barrack
as
well,
and
obviously
the
ITU
Thanks.
K
Channeling
for
Willy
and
any
country,
any
country
regulator
will
likely
will
accept
multiple
CAS.
Any
signer
will
use
it.
Ca
validators
we'll
find
it
in
the
policy
administrator's
database
managed
by
the
national
authorities.
This
would
make
a
trusted
reference
plane
for
TN
CAS.
As
Eric
mentioned.
This
resource
ca's
then
could
be
openly
used.
Isn't
such
an
approach
open
enough.
O
Jonathan
Rosenberg,
to
fob
to
it
Richard
said
I,
do
think.
There's
a
problem
here
in
that.
How
do
you
know
which
she
A's
to
trust,
and
even,
if
you
don't
want
to
use
an
iron
in
a
registry,
it's
a
pretty
good
question
and
I
think
it
is
different
from
the
traditional
web
world,
where
you
can
look
at
a
standard
set
of
practices
and
policies
and
things
they
follow.
But
in
here
we're
adding
another
dimension,
which
is
you
know?
O
How
does
this
ca
effectively
have
its
authoritative
knowledge
about
who
in
fact
owns
these
phone
numbers
and
I?
Think
that's
a
pretty
hard
question,
especially
if
we
think
the
remit
of
this
problem
is
to
solve
this
in
an
international
global
worldwide
setting.
It's
not
obvious
to
me
at
all.
As
an
entity
buildings,
a
IP
PBX
is
or
something
whose
CA
should
I
put
into
trust
and
Bob
way.
Numbers
I
have
no
idea.
M
N
E
Grab
out
this
one
I'm
back
again,
hello
next
slide.
We're
gonna
try
to
do
this.
One
quick
since
I
know
I
wasted
too
much
more
time
earlier,
kicked
identity
back
in
the
day
when
we
did
good
old,
44
74,
it
only
worked
for
requests.
We
put
the
identity
header
in
requests
alone.
There
was
at
least
one
really
practical
reason
for
this,
which
is
you
can't
send
a
403
in
response
to
it.
200.
There
are
a
lot
of
people
who
said
at
the
start
of
the
identity
kind
of
discussions
there.
E
However,
you
know
that
was
really
based
on
the
fact
that
we're
trying
to
beat
a
specific
threat
model
in
here
we're
trying
to
prevent
robocalling
personation
that
enables
that
voicemail,
hacking,
swatting
phishing,
all
this
bad
stuff
and
those
all
result
from
requests
hidden,
largely
from
invite
requests,
and
we
don't
need
to
do
responses
in
order
to
beat
that,
but
what
this
new
document
that
Chris
and
I
hacked
together
this
time
talks
about
it's
a
problem,
we've
become
a
bit
preoccupied
by
lately
is
they're.
Actually
a
colleague,
impersonation
problem
and
I
think.
E
Unfortunately,
the
answer
is
that
there
is.
There
are
a
variety
of
spectacular
hijacking
attacks
that
have
been
demonstrated
in
the
wild
yep.
Those
are
you're
familiar
with
s-sir,
where
some
of
them
are
based
on
its
exploits
of
like
the
mobile
roaming
systems.
Some
of
them
again
just
are
based
on
the
fact
that
a
lot
of
IP
routing
frankly
uses
routing
tables
that
are
pretty
arbitrary,
like
we're
just
talking
about,
since
we
never
quite
got
public
enum
right.
There
are
a
lot
of
dis,
private
enum
resolution
databases
that
have
whatever
data
in
them.
E
They
want
to
figure
out
how
to
route
numbers,
and
so
I
think
there
is
unfortunately
kind
of
a
Kali
impersonation
problem
and
there's
a
need
that
has
been
identified
to
be
able
to
secure
more
trust
between
endpoints
that
are
reached
by
a
call,
and
especially
consumers.
They're
calling
a
certain
certain
categories
of
institutions
and
I
think
that
we
can
leverage
the
stur
work
and
the
stuff
that
John
Elway
did,
for
the
most
part,
largely
unchanged
to
try
to
address
this
problem
space
next
slide.
The
basic
idea
is
just
to
do
stir
backwards.
E
If
we
imagine
a
case
where
there's
a
client,
that's
calling
a
financial
institution,
they're
calling
fidelity
investments,
we'll
say
you
know
everything
normally
happens.
The
same
logical
authority
signs
the
requests
on
the
way
to
it
yet,
but
then
the
financial
institution
they've
reached
has
an
opportunity
using
the
49:16
mechanisms
to
send
requests
in
the
backwards
direction
in
the
dialogue
that
actually
validate,
who
it
was
you
connected
to
and
to
make
sure
that
the
client
can
actually
verify
I
reach
the
right
person
next
slide,
and
there
are
a
couple
of
big
questions
about
this.
E
The
draft
does
not
try
to
dig
into
mechanisms
or
solution.
It
really
is
kind
of
a
problem
statement,
but
there
are
some
different
moving
pieces
in
this.
For
example,
it's
possible
to
do
things
before
a
call
even
starts
that
could
help
kind
of
tee
up
what
your
relationship
is
potentially
especially
again.
Financial
institutions,
health
institutions
are
the
ones
that
people
are
largely
fixated
on
for
this.
E
You
could
do
some
key
discovery
mechanisms
you
could
do
discovery
of
what
security
services
are
available,
potentially
outside
the
context
of
a
calls
starting
I've
been
thinking
that
the
results
of
a
failure
in
this
would
be
similar
to
the
results
of
a
failure
of
say,
negotiating
SRTP.
In
other
words,
we
would
kind
of
not
send
media
unless
we
get
connect
identity
for
this
set
of
again,
you
imagine
that
would
be
some
kind
of
like
a
requires
again.
I.
E
Don't
want
a
solution
here
today,
but
something
that
will
let
the
the
user
tell
its
client
I
really
need
to
reach
this
person
and,
if
I'm
not
reaching
this
person,
you
need
to
shut
this
call
down,
and
that
may
only
matter
for
a
certain
category
right
off
of
potential
Khali's.
But
it
would
be
something
like
that
that
we
would
just
kind
of
cut
the
media
streamer
or
never
even
started.
If
we
don't
get
back
this,
this
strong
assertion-
and
there
are
user
experience,
questions
about
how
that
works.
E
I
mean
we're
not
like
looking
at
a
display.
Typically
after
we
hit
the
call
button.
So
what
happens
in
terms
of
how
a
user
knows
either
that
things
are
good
or
bad
is
something
we're
probably
not
going
to
dictate,
but
we
want
to
provide
it
in
Stokes
four
into
this
next
slide,
and
the
good
news
is
actually
at
Adam.
Did
this
exercise
and
sip
brandy
for
us
where
you
went
back
in
2016
and
went
through
49:16?
Do
you
remember
and
kind
of
tried
to
see?
Is
this
actually,
you
know
relatively
still
still
aligned
with
us.
A
E
One
tiny
normative
fix
that
that
Adam
identified
from
that
which
resulted
from
the
way
we've
hacked
the
resending
mechanism
for
full
form
versus
compact
forum
in
AD
224,
so
nothing
too
invasive,
in
other
words,
I,
think
the
actual
protocol
update
to
49:16
will
be
small,
but
the
procedure
is
that
we
will
articulate
in
order
to
solve
this
particular
Kali.
Impersonation
problem
is
really
what
what
will
be
interesting
in
this
and
yeah.
E
So
this
is
like
a
trial
balloon,
Chris
and
I.
Put
this
draft
out.
You
can
read
it
read
the
problem
statement
I.
If
people
are
interested
in
this,
do
people
think
there
is
a
problem.
I
have
heard
from
some
of
these
large
institutions
that
they
are
concerned
about
this
and
would
like
a
solution
for
something
in
this
space
and
anybody
here,
one
a
plus
one
or
minus
one.
This
I
see
some
thumbs
coming
up
from
various
people
in
the
room.
F
F
Value
add
features
we
could
add
to
this.
You
know
you
know
that
as
simple
as
I
dialed,
the
wrong
number
and
I
get
something
back.
That
shows
a
completely
different
person
than
I
thought.
I
was
dialing
yeah,
you
know
so
I
think
it
goes
all
the
way
up
the
chain
from
simple
use
cases
to
really
interesting
ones
that
we
can
imagine
in
the
future.
No.
E
I
mean
I,
think
I
think
vishen
use
cases
with
like
adjacent
numbers.
Are
we
confusing
things
there
in
texts
where
I
got
this
number
in
a
text
and
I
click
on
it
and
we
could
actually
get
in
front
and
tell
you
you're
not
connecting
the
person
you
think
you're
connecting
to
there
like
things
like
that
that
are
possible
with
enough
pre
Association
again,
you
assume
that
we
can
do
some
things
beforehand
for
the
financial
institutions
that
you're
related
to
to
identify
things
like
that,
it's
possible.
We
could
beat
some
some
interesting
attacks,
yeah.
O
Jonathan
Rosenberg
I
think
there
are
some
hard
problems
here
on
the
user
experience
and
because
you
know
redirection,
it's
not
always
an
attack.
To
give
an
example
in
an
enterprise
context,
you
know
it's
very
common
to
have
these
like
hunt
groups
and
the
call
bounces
around
like
five
different
people,
and
it
might
go
to
a
consultant.
You
can
configure
it
with.
You
know
outside
lines
whatever
so,
like
you
know,
is
that
bad,
probably
not
so
I
mean
you
know
and
again
to
your
point
like
if
you
do
is
this,
like
you
know
how
do
you?
E
So
we
do,
we
do
talk
a
little
bit
about
transfer
once
you've
made
an
initial
connection,
even
in
things
like
that,
going
through
hunt
groups
and
yeah
we're
I.
Think
our
primary
interest
here
again
is
that
we
hope
that
there
will
be
through
things
like
Chris's,
TN
pop,
for
example,
and
shaken
stop.
There
will
be
ways
that
we
can
get
certs
down
to
these
organizations
that
will
still
let
them
present
I'm
like
an
agent
of
fidelity.
E
You
know,
even
if
you've
gone
through
a
hunt
group
and
ended
up,
you
know
transferring
to
somebody
who's
like
you
know,
a
home,
you
know,
telecommuting
a
call
center
worker
and
things
like
that.
So
I
think
we
can
help
I
think
we
can
help
with
this
I'm,
not
going
to
say
that
it's
an
easy
problem
necessarily
but
I
think
we
we
can
provide
things
that
are
better
than
nothing.
Yes,
pretty.
S
Nice
I'm
not
quite
sure,
if
I
understood
it
correctly,
but
really
I'm
trying
to
assert
these
devices
as
opposed
to
persons,
not
sure
about
the
usefulness
of
financial
institution.
If
you
can
confirm
it's
your
device,
but
not
confirm
that
through
the
use,
all
they
want
to
talk
to
when
he's
using
this
device.
E
S
E
The
flipside
of
this,
though,
we're
talking
about
identifying
the
person
you
called
so
if
I'm
calling
a
you
know
us
back
yeah,
you
know
how
do
I
know
that
I
reached
us
Bank
and
that
this
wasn't
redirected
or
hijacked
or
sent
and
some
to
some
place
it
shouldn't
go
okay,
which
is
slightly
different
problem
again
that
that's
the
threat
model
we
hope
to
address
in
this
for
again
there's
a
particular
set
of
institutions
that
have
expressed
interest
in
having
this
capability.
It
seems
adjacent
to
what
we're
doing
and
again
it
it's
an
impersonation
problem.
E
It's
a
collie,
impersonation
mm
and
I
think
we
might
be
Li
had
some
traction
with
this
I'd
like
to
see.
If
we
can,
we
can
make
it
work,
alchemy
thanks,
but
in
general
everybody
thinks
this
is
pretty
cool.
We
should
keep
working
on
this.
Try
to
get
some
over
then
I
see
people.
Take
this
prequel,
okay,
that's
it
thanks!
Thank.
O
N
U
N
V
V
O
All
right,
hello,
everyone,
Jonathan,
Rosenberg
and
I'm
here
to
talk
about
sip
coin.
So
next
slide,
please!
Since
there's
a
lot
of
questions,
why
am
I
here?
I
thought
I'd
clarify
that
I'm
doing
in
initial
coin,
offering
for
my
blockchain
start
doing
virtual
reality,
quantum
computing
just
kidding.
So
you
know,
though,
there's
a
lot
of
hype
on
this
tech,
like
you
know,
I'm
interested
in
this
in
the
callback
draft.
O
For
the
same
reason,
a
lot
of
us
are
here
like
work
on
the
SIP
stuff,
with
you
all
for
a
long
time
and
I'm
freaking,
tired
of
all
these
Oracle
calls
and
I
said,
maybe
I
can
help
so
I
wrote
some
drafts
and
I
haven't
been
involved.
Much
in
the
star
stuff,
I
know
so
here's
some
ideas
to
try
make
it
better.
That's
it!
That's
it.
There's!
O
No,
like
ulterior
motives,
so
this
one's
a
of
the
two
drafts,
this
one's
sort
of
more
of
the
moonshot
crazy
idea-
and
we
have
a
lunch
session
after
this
to
talk
more
about
it
and
other
concepts.
I'm
not
going
to
go
through
the
technical
stuff
in
the
draft,
but
but
rather
I
want
to
focus
on
the
part.
You
may
have
skipped
because
it's
the
most
interesting
part
of
the
document,
which
is
sort
of
the
little
walkie
the
layer
of
argumentation
I'm
going
to
spend
most
of
my
time
on
the
third
here.
O
So
what
is
the
purpose
of
the
strap
like
it
makes
the
following?
If
sort
of
by
the
following
arguments
in
sequence,
one
this
is
fairly
orthogonal
verified
caller
ID,
like
even
in
a
world
where
we
have
verified
caller
ID
I
assert
that
will
help,
but
it
will
not
stop
the
bad
guys.
And
if
you
don't
agree
with
that,
then
you
sort
of
you
know.
Then
you
don't
need
this
document
at
all.
So
we
should
certainly
discuss
that
second
I.
O
The
third
argument,
which
is
the
thing
I'm
going
to
spend
time
on,
is
well.
Can
you
actually
solve
this
with
economics,
and
so
there
is
an
economic
analysis
in
the
document.
I
believe
interesting
with
the
answers.
Yes
that
at
least
based
on
real
data,
it's
back
to
the
end
admit,
but
real
data
says
that
there
is
in
fact
an
interesting.
All.
O
Pretty
wide
range
actually
have
cost
targets
that
disincentive,
tackers
well,
not
also
being
overly
burdensome
for
non
attackers
and
the
last
part
which
is
interestingly,
the
most
contentious
part
of
the
document,
is
also
perhaps
the
least
interesting
aspect
of
the
document,
which
is
that
we
can
incur
a
cost
target
via
computational
work,
and
it's
certainly
it's
hip
these
days
to
say
blockchain
and
bitcoins
suck,
because
they
you
know
they
burned
power.
I'm,
certainly
gonna
go.
O
Do
some
math
to
see
whether
or
not
this
is
actually
a
consequential
amount
of
power,
but
there's
other
ways
to
solve
that
problem.
The
more
interesting
thing
is:
do
you
think
that
an
economic
disincentive
is
interesting?
And
then
you
can
ask
the
question
whether
or
not
computation
is
the
right
way
to
pay
the
cause
next
slide,
and
so
again
people
hated
this
I'll
present
in
a
moment.
Some
other
ideas
even
beyond
this
draft.
Obviously
this
is
not
a
baked
proposal.
Next
slide,
so
I
assert
come
to
the
mic.
O
If
you
disagree,
verified
clarity
will
not
be
sufficient
and-
and
you
know
certainly
the
reason
is.
Is
you
know
it's
not
just
the
u.s.
its
outside
of
the
US
I
guarantee
you?
There
will
be
some
countries
somewhere
which
offer
numbers
at
a
relatively
low
cost
and
they
will
be
verified
now.
Maybe
you
think
that
I'll
just
block
all
international
calls-
and
you
know
I,
don't
know
some
people
like
getting
international
calls.
So
how
do?
How
do
you
know
so
I
think
there's
a
risk
I
think.
O
Even
if
you
focused
on
a
single
country
like
the
US,
you
know,
we've
got
a
lot
of
carriers,
no
offence,
Martin,
it's
not
just
18
t
Verizon.
You
know
there
are
a
few
others.
It's
a
long
tale.
Some
of
them
want
money
like
some
like,
given
my
phone
numbers
for
cheap
and
there's
a
lot
of
phone
numbers
in
that
are
not
all
valid
numbers.
Obviously,
but
you
know
in
the
North
American
number
of
quite
if
you
just
count
the
number
of
digits
available,
it's
a
pretty
big
number.
O
I
can
imagine
people
doing
faked
area
codes
or
whatever
it
seems
like
it
like
it'll
reduce
it,
but
it
is
not
going
to
completely
kill
it,
and
so,
even
if
you
think
you
can't
do
any
of
those
other
things
like
well,
I
might
rotate
numbers.
I
might
rotate
numbers
in
different
regions
like
I
will
buy
some
numbers
from
Verizon,
AT&T
and
I'll
use
them
till
they
get
blocked
and
then
I'll
buy
different
numbers.
O
I
mean
these
are
all
games
that
you
can
imagine
playing
and
as
long
as
there's
an
economic
incentive,
these
games
will
be
played
next
slide
I,
and
so
I
argue,
you
know
why
economic
disincentives
so
like.
Well,
it's
a
proven
technique.
I
mean
it's
certainly
used
in
lots
of
other
industries.
I
mean
it's.
O
The
entire
foundation
of
the
US
tax
system
and
and
probably
other
places
to
is
to
incense
or
distance
and
good
and
bad
behaviors
for
things
and
without
it
there's
always
an
economic
incentive
to
work
around
right
and
this
sort
of
addresses
that
so
next
slide.
So
the
interesting
thing
which
I'm
just
gonna
spend
a
couple
more
minutes
on,
so
I
want
to
talk
more
about
call
back.
Is
there
a
valid
cost
target?
There's
the
most
interesting
point
of
the
draft.
O
So
let
me
I
want
to
walk
you
through
this,
because
this
is
interesting
right,
so
I,
just
just
from
some
public
data
and
I'd
actually
welcome
feedback
for
people
have
better
data
than
this
okay.
You
know
there
were
200
2.5
billion
robo
calls
in
April
2017
from
an
article
I
found,
and
it
also
quoted
that
same
article
350
million
dollars
in
cost
to
Americans
in
years
prior,
admittedly,
that's
a
you
know,
there's
a
temporal
gap
there,
but
so
get
back
to
the
envelope.
O
So
but
like
I
mean,
is
it
10
times
more
revenue
and
then
six
years,
since
probably
not
okay,
so
close
enough?
So
that's
over
36
months!
That's
ninety
seven
point:
five
million
dollars
in
the
u.s.
profit
per
month
and
it
took
2.5
billion-
calls
to
get
there
and
we
get
0.38
cents
of
profit
per
call.
That's
the
metric
or
interested
in
profit
per
call.
Why
want
to
destroy
that
profit
per
call?
So
if
you
want
to
take
a
minimum
of
a
50%
profit
erosion
that
means
death.
O
I,
probably
that's
point
one:
nine
cents
per
call,
so
you
need
to
you
need
to
cause
the
Robo
callers
at
least
point
one:
nine
cents
per
call
a
payment
in
order
to
basically
make
this
not
profitable
anymore.
Next
slide.
Now
everyone
asked
well
what
about
the
good
guys?
Are
you
gonna
incur
costs
on
them,
so
this
is
I
can
do
the
math
on
that?
It's
in
the
document.
So
again
that
can
the
envelope
like
if
we
take
a
mobile
phone
bill,
it's
$100
on
average.
O
Let's
say
we
don't
want
to
use
it
as
let's
say
a
teen
teen
Verizon
pass
on
the
cost
of
the
consumer.
Three
percent
increase
at
most
three
dollars
extra
month
to
get
rid
of
Robo
callers.
I,
don't
know.
I
would
personally
spend
that
much
money
and,
as
you'll
see
in
a
moment,
you
can
probably
make
it
quite
a
bit
less
so
three
dollars
I
read
in
some
article,
the
average
American
makes
the
receive
six
calls
a
day.
That
seems
a
lot
to
me,
but
let's
run
with
symmetry.
That's
three
calls
a
day.
O
Ninety
calls
a
month
at
three
dollars
for
ninety
calls.
That's
three
point:
three
cents
per
call.
Those
caller
will
cost.
Now.
That's
not
a
wide
range
between
these
two
things.
It's
a
single
order
of
magnitude,
but
at
the
same
time
I
don't
think-
and
this
number
was
that
this
gap
wasn't
big
enough,
in
my
opinion,
to
make
it
by
itself,
viable
and
and
but
the
reality
is
I,
don't
watch
you
want
to
charge
everyone
for
calling
me.
O
If
you
combine
this
as
with
many
of
these
techniques
with
other
things,
it
works
much
better
in
a
particular.
If
you
introduce
a
challenge
response
mechanism-
and
you
only
request
payment
for
someone
I
don't
know,
then
you
only
end
up
incurring
this
cost.
For
the
introduction
calls
calls
from
someone
I
don't
know
that
I
either.
Don't
trust
by
reputation
they're,
not
on
my
contact
list
and
not
on
my
list.
I
haven't
called
them
whatever
other
things
have
applied
first,
if
all
of
those
fail,
then
is
last
resort.
O
You
challenge
them,
and
in
that
case
you
can
imagine
well
alright
next
slide
what
if
it's
only
say
one
in
ten
people
that
I
or
one
in
a
hundred
people
that
I
get
a
call
from
that
I've.
Never
I
have
no
other
record
of
who
this
is,
and
that
percentage
you
get
you
know
the
cost
of
a
single
call
to
a
consumer
could
be
a
hundred
times
higher
at
thirty
three
hundred
point
three
cents
per
call.
Is
it's
a
once
in
a
hundred
case?
O
So
a
next
slide
when
you
map
it
out
on
a
nice
graph,
you've
got
to
keep
the
cost
you
incur
to
a
caller.
For
one
of
these
introduction
calls
less
than
say
three
hundred
point
three
sends
probably
a
lot
less
and
you
want
to
click
the
cost
to
the
spam
or
more
than
point
one
nine
cents,
ideally
quite
a
bit
more
at
point.
Three:
eight
they're
out
of
business
completely,
that's
actually
a
huge
range
by
the
way.
O
Someone
sent
me
an
article
like,
oh
you
know,
we
looked
at
this
with
email
spam
and
it
didn't
work
sure
you
have
to
look
at
the
economics
for
each
industry
separately
and
so
I
may
have
some
of
this
wrong
and
I
would
love
your
feedback
to
make
the
analysis
better
and
if
it
turns
out
that
this
doesn't
work
and
it
doesn't
work,
but
my
pack,
an
envelope
says
this
actually
is
pretty
interesting
for
our
industry
to
think
about
so
next
slide,
then
there's
a
big
question:
how
to
create
the
cost,
and
so
you
know
proof
of
work.
O
Is
the
proposal
on
the
draft.
I
will
note
like,
although
it
says
you
know,
sip
coin
and
whatever
there's
not
a
proper
blockchain
in
this.
Actually
it
does
proof-of-work
uses
cas
to
do
agitation
at
that's.
A
station
of
proof
of
work
does
not
do
a
consensus
blockchain
because
it's
not
necessary
again.
So
this
makes
the
problem
much
simpler,
we're
not
trying
to
solve
a
problem
that
hard.
We
just
done
a
new
proof
of
computation
where
you
can
demonstrate
do
to
work
before
the
call
and
then
demonstrate
the
work
during
the
call.
O
That's
the
only
problem
we
have
to
solve,
and
that
is
the
technology
described
in
the
document.
So
fair
enough
it.
Yes,
it
will
burn
compute
I
assert.
If
you
go,
look
at
it
well,
you
know
the
good
guys
almost
never
need
to
do
it.
It's
only
for
introduction
calls
the
bad
guys
get
dissing
sense
it
they
won't.
Do
it
much
like
I
now
go.
Do
an
analysis
on
the
actual,
like
energy
burn
I
doubt
it's
actually
that
significant.
O
So
so
that
may
be
viable,
but
there's
other
techniques
to
proof
of
stake
has
been
mentioned,
there's
actually
direct
payments
or
trusted
CAS.
Maybe
literally
you,
you
know
you
have
to
send
30
cents
to
let's
encrypt
and
let's
encrypt
asserts
that
the
30
cents
has
been
received,
and
that
gives
you
permission
to
make
the
call
I'm
gonna
actually
have
a
global
security
charity
that
also
stops
Robo,
callers
I.
Think
that's
pretty
interesting
too.
So
these
are
some
ideas.
This
is
clearly
not
baked.
This
clearly
needs
more
thinking
and
better
analysis.
O
A
O
Don't
get
in
the
line,
I
thought
this
is
gonna,
be
quick
at
lunch
next
slides,
because
this
is
the
one
well
we'll
talk
about
it.
Let's
do
because
the
other
one
is
a
more
you
know.
I'd
say
slightly
more
serious
proposal,
a
little
less
crazy
I'll
just
try
and
keep
the
problem
statement,
and
we
can
talk
more
about
it
at
lunch
as
well.
V
O
M
N
O
All
right,
yeah,
that's
a
good
way
to
do.
It.
I've
seen
talks
like
that,
where
literally
the
slides
auto-advance
so
way
to
keep
it
fun.
Alright,
it's
fine!
That's
fine!
So
so
the
current
store
architecture
is
effectively
a
three-party
technology
which
means
for
it
to
work.
O
Do
you
trust
and
how
we're
gonna
issue
these
certs
and
how
you're
gonna
verify
the
numbers
in
them?
And
how
is
it's
gonna
work
in
each
country
and,
like
you
know,
or
we're
gonna
put
phone
numbers,
we're
gonna
put
carrier
codes
if
we
put
carrier
coats,
how
do
you
verify
those
carrier
codes
and
what's
a
database,
to
verify
that
it's
like
that's
all
the
hard
stuff
in
the
same
way
we
sort
of
went
through
this
with
enum
like
this
seemed
to
be
sort
of
repercussions
of
similar
problems
is
like
the
DNS
query,
ain't
the
problem.
O
The
problem
is
how
you
get
the
database
populated
and
verify
its
authenticity,
whatever
that
was
completely
insurmountable.
Now
I
think
this
looks
better
and
clearly
we're
making
progress
to
the
hard
work
of
some
of
the
folks
in
this
room.
But,
like
you
know,
we
want
global
worldwide
deployment
of
this
thing
and,
like
us,
a
serious
question
like
are
we
gonna
be
able
to
solve
this
easily
for
calls
from
you
know
small
European
countries
to
the
US
and
how
is
that
all
gonna
work
so
I
said
well,
simplification
is
about
eliminating
dependencies.
O
Can
we
come
up
with
a
solution
that
doesn't
necessarily
require
a
centralized,
CA
or
death
telco
database?
A
phone
number?
Do
you
know
how
cm
mappings
and
there's
lots
of
use
cases
for
that?
This
is
what
I
mean
about
the
long
time,
so
you
know
again,
even
if,
if
Martin-
and
you
know,
Chris
and
others
in
their
respective
carriers
deploy
this
thing,
there's
something
like
3000
I
think
is
what
you
said:
John
Lex
in
the
in
the
u.s.
like
how
do
each
of
them
get
involved
in
this
thing?
O
How
do
they
get
their
ca's
issued
all
that
kind
of
good
stuff
international
calls?
Third,
you
know:
longtail
providers
business-to-business
calls
where
it's
enterprises
connecting
to
each
other.
How
does
all
of
that
work,
and
so
what's
in
this
draft
next
slides,
is
a
very
simple
idea
of
an
old
technique
that
we've
been
using
many
times,
which
is
to
do
a
distributed.
O
Trust
model
where
each
terminating
domain
has
its
own
cache
of
certificates
and
phone
numbers
associated
with
those
certificates
that
it
trusts
and
it
populates
a
cache
with
a
reverse
call
back
and
just
in
order
to
not
annoy
the
user
next
slide.
The
reverse
call
back
has
a
sip
extension
that
blocks
the
call
at
the
doesn't
ring
the
phone
returns.
Some
response
codes
to
say
whether
or
not
this
return
call
went
to
the
same
place
that
issued
the
call.
So
the
technology
is
not
interesting.
It's
like
and
we
can
work
on.
O
It
is
not
complicated
but
again
that
the
core
thing
to
understand
is
this
conceptual
model
of
instead
of
relying
on
a
centralized
database
or
CAS
or
whatever
I
build
up
my
own
database
of
trust
by
doing
reverse,
call
backs
to
check
this
is
more
or
less
the
foundation
of
much
of
modern
identity,
anything
that
uses
an
SMS
or
whatever
is
doing
some
more
type
of
type
of
techniques.
Now
that
said,
last
slide
before
Martin
gets
all
upset
at
the
mic.
O
I
do
view
this
as
complementary
to
RFC
18
to
26
I
mean
that's
clearly
the
right
long-term
architecture.
So
a
question
for
me
is:
how
do
we
fill
in
the
holes
so
in
cases
where
it's
not
they're,
not
able
to
get
these
certificates
can
a
enterprise
that
receives
a
call
that
doesn't
have
one
of
these
beautiful
82,
26
certs?
It
can
go
and
it
can
do
the
reverse
call
back
to
verify
the
call
and,
as
we
get
more
and
more
eighty-two
26,
we
need
less
and
less
call
backs.
O
This
is,
if
you
know
so,
it's
four
entities
that
can't
get
the
certs
for
businesses
that
can't
do
these
things.
It
fills
in
the
gaps
so
I
view
it
as
largely
a
compliment
and
also
to
discuss
with
John
this
interesting
idea
of
even
issuing
certificates
based
on
these
callbacks
in
this
distributed
fashion,
similar
to
the
star
draft.
So
our
okay.
D
Martin
Dali
well,
there's
still
quite
a
few.
You
know
TDM
phones
out
there
yeah
and
even
where
there's
not.
You
know
unless
they're,
at
least
in
the
u.s.
less
there's
a
lot
of
regulation,
reform,
you're
still
going
to
have
this
bloody
IP,
TDM,
IP
and
right
so
you're,
going
to
hit
these
PSTN
gateways
is
the
bottom
line.
D
These
PSTN
gateways-
and
you
know
some
of
the
argument-
is
that
well
they
touch
sip.
So
therefore
you
can
touch
the
code.
The
answer
is
no,
and
so
therefore,
when
you
send
that
invite
in
the
backward
direction,
it's
going
to
look
like
another
call
set
up.
You
know
to
the
calling
party-
yes,
and
so
that's
so.
O
How
would
you
address
that?
Well,
that's
what
the
require
header
is
to
block
that
from
happening.
In
essence,
this
suffers
the
same
challenges
stir
in
banned.
It
won't
work
with
any
kind
of
PSTN
gateway
in
the
middle
I.
Don't
think
it's
any
worse
or
better
than
stirring
behind.
In
that
regard-
and
you
know
just
again
blood.
E
O
F
E
F
O
Yeah
I
should
be
clear.
Thank
you,
Chris
I'm,
not
referring
to
the
literal.
You
know,
usage
of
the
acne
protocol
in
the
issuance
certificates.
It's
the
policy
about
whether
or
not
I
can
legitimately
assert
that
I
own
a
telephone
number
and
which
CAS
are
legitimately
able
to
do
those,
and
how
do
you
to
make
sure
I
correctly
populate
those
lists
of
numbers
and
properly
account
for
number
portability
and
how
long
do
I
have
to
remove
it
from
the
certificate?
O
F
Well,
I
think
where
we
put
those
root
certificates,
you
know
we
can
figure
that
out,
but
it's
going
to
be
based
on
the
legal
structure
of
each
country
and
things
like
that
and
I
think
that's
that's
the
harder
part
than
knowing
where
to
look
to
get
those
certificates
so
I
think
it's
a
legal
problem,
not
a
technology
technology
problem.
Okay,.
E
E
Let's
make
sure
if
we're
gonna
do
something
that
is
a
bootstrapping
mechanism,
it
moves
the
ball
closer
to
the
80
to
26
world
that
we
all
want
and
that
there's
a
clear
kind
of
incremental
upgrade
path
to
it
from
this
I
think.
There's
a
way
to
do
this.
It
actually
does
have
that
property
and
we're
you
know:
I
mean
it
could
literally
end
up
generating
certs.
That
would
be
integratable
into
this
like
going
forward
so.