►
From YouTube: IETF-STIR-20220422-1400
Description
STIR meeting session at IETF
2022/04/22 1400
https://datatracker.ietf.org/meeting//proceedings/
A
A
Okay,
welcome
it's
at
the
top
of
the
hour,
so
in
respect
for
everyone's
time,
let's
go
ahead
and
get
started.
Ben's
running
the
slides,
I'm
gonna
be
the
emcee
today
and
wow.
I
was
expecting
a
few
more
people,
but
let's
get
started
with
this
part
and
people
can
join
in
as
they
show
up.
We've
got
a
pretty
full
agenda
next
slide.
Please.
A
So
this
is
the
note:
well,
it's
not
changed
since
we've
met
last
at
ietf
112..
This
is
the
responsibilities
that
anyone
who
contributes
has
so
please
make
sure
you
have
reviewed
it
before
you
contribute
next
slide.
A
So
please
live
the
itf
code
of
conduct,
let's
just
be
respectful
of
each
other
and
courteous,
and
this
group
has
not
had
problems
with
that
in
the
past.
Let's
keep
it
that
way.
Next
slide.
A
So
this
is
the
agenda
for
today
I
was
sent
to
the
list
a
while
ago.
A
Okay
and
thank
you,
jack
right
before
the
meeting
started
on
email
you
volunteered
to
take
notes.
We
greatly
appreciate
it,
so
I
think
chris
is
going
to
do
the
presentation
of
the
first
one.
Is
that
right,
john?
So
russ
did
we
have
an
agenda
bash.
A
B
A
A
short
lifetime
and
ocsp
which
we
approved
and
we'll
just
handle
those
during
any
other
business.
You
know
assuming
there's
time,
sounds
good.
D
D
D
Jack's
suggested
text
for
the
procedures
on
json
pointer
digest
and
I
didn't
move
that
section
it
was.
It
wasn't
an
odd
place.
I
don't
know
how
that
happened.
It
was
probably
a
copy
and
paste
thing
or
something
like
that,
but
I
moved
it
up
to
the
top
of
section.
I
think
it's
6.1
and
I
fix
some
of
the
digest.
Example:
values.
D
So
going
back,
we
haven't
had
a
meeting
since
these
changes,
so
we
added
the
there
was
some
list
discussion
about
it,
but
in
general
the
comments
that
I've
heard
about
adding
the
new
icon
key
value
are
all
pretty
positive
and
sort
of
corresponds
to
the
call
info
purpose
icon,
just
in
general,
used
as
a
alternative
way
of
doing
things.
If
you
know,
I
think
where
it
was
sort
of
ending
up,
was
that
people
were
just
using
j
card
to
provide
an
image.
D
D
E
D
A
D
D
Okay,
I'll
move
on
unless
anyone
else
has
any
comments,
we
can
always
come
back
to
talk
to
ben's
comment.
D
D
Are
you
back
online
ben?
Can
you
speak
or.
B
Figure.
Okay,
I
was
going
to
say
I
like
this
change
a
lot
and
the
reason
I
like
to
change
is
we
were.
I
was
looking
at
situations
where
we
would
want
to
pre-compute
rcdi
values.
You
know
like.
Maybe
you
want
to
put
it
in
a
crank
constraint
or
something
and
computing
rcdi
values
when
you
want
to
do
something
simple
like
just
have
an
image
but
then
dealing
with
all
the
overhead
and
variability
of
the
j
card.
You
know
having
the
order
right
and
things
like
that.
It
is
somewhere
between
tedious
and
tricky
know.
B
D
Yep
yeah,
I
agreed
it's
actually
been
mentioned
for
a
little
while
and
finally
stuck
it
in
at
the
end.
So
I
I
think
yeah
most
of
the
comments.
I've
gotten
are
very
positive
about
this.
One.
A
D
It
should
it
it's
essentially
defined
as
a
key
value
where
the
value
is
the
your
url
to
the
image
itself.
So
it
follows
similar
to
how
the
definition
of
icon
is
in
call
info,
and
we
don't
say
too
much
more
about
it.
There
is
discussions
about
you,
know
the
formats
and
other
things
and
I
think
we're.
We
tried
to
we're
trying
to
resolve
that
in
the
zip
core
draft
as
more
general
rules
that
apply
to
both
rcd
and
call
info.
C
D
D
The
last
one,
obviously
probably
more
discussion
to
be
had
there.
I
I
don't
know
if
folks
saw
my
message
to
the
list
last
night,
I'm
sort
of
admitting
that
I
opened
a
can
of
worms
that
I
probably
shouldn't
have.
D
Although
a
lot
of
the
discussions
going
on
in
the
industry,
right
now
are
sort
of
relevant
to
this
topic,
but
I
think
at
the
end
of
the
day
you
know
the
maybe
the
simplest
fix
is
just
to
revert
that
paragraph
that
I
inserted
and
we
can
have
those
discussions
as
part
of
other
profiles
and
policy
initiatives
that
happen
in
other
forums,
curious.
What
people
think
about
that
ben
your
hand
is
up.
B
I
think
I
agree,
and
I
was
going
to
ask
you
when
you
talk
about
reverting
this.
I
noticed
this
text
in
the
I
can't
remember
the
section
number,
but
the
section
on
putting
rcd
claims
in
non-rcd
passports
that
that
has
some
fairly
prescriptive
language
there
that
I
think,
might
be
part
of
what
needs
to
be
adjusted.
D
Yeah
yeah,
I
agree
with
that
yeah
I
I
recognized.
I
probably
crossed
that
line
a
little
too
far,
so
I
think
the
the
the
replacement
that
I
had
was
a
note
that
did,
I
think,
did
stay
within
those
bounds,
but
you
know
certainly
willing
to
hear
comments.
I
I
probably
maybe
I
should
have
included
that
text
here,
but
people
can
reference
it.
If
you
have
to
look
at
the
14
spec
in
order
to
see
what
was
there
before.
D
I
mean,
I
think,
we're
probably
not
going
to
get
consensus
on
this
call,
although
I
would
sort
of
like
to
say,
like
people
are
in
general
agreement,
and
maybe
we
can
work
through
that
on
the
list,
if
possible,
to
to
push
things
forward.
If
there
is
if
people
are
have
any
issues
with
the
note
as
it
was
in
14,.
F
D
B
I'm
not
sure,
but
I
think
the
text
I
mentioned
in
the
section
on
non-rcd
passwords
was
already
in
14..
It
wasn't
to
change
from
14
to
15..
I
may
be
mistaken
on
that
point,
but.
D
Yeah,
so
I
have
text
note,
there
is
one
very
important
caveat
to
this
capability
because
it
generally
because
generally,
if
there's
a
uri
reference
content
in
rcd
passport,
there's
often
requirement
to
use
rcdi
and
claim
constraints.
So
it
was
important
for
the
user.
The
specification
to
recognize
that
certificates
used
must
include
the
necessary
jwt
claims
constraints
for
proper
integrity
or
security
of
values
in
the
rcd
claim
incorporated
in
passports
that
are
not
rcd.
G
G
You
know,
I
think
we
we
certainly
want
to
explain
what
the
use
case
is
for
using
jwt
constraint,
claim
constraints
inserts,
but
I
don't
think
we
want
to
cast
it,
especially
at
this
stage
of
adoption
in
the
marketplace
in
such
a
way
that
it
comes
across.
G
Like
you
have
to
have
gdp
claim
constraints,
you
can't
do
rcd
and
like
that,
you
know
the
text
isn't
normative,
so
I
mean,
but
it's
it
still
pretty
strongly
seems
to
encourage
that
to
me-
and
you
know
I
I
just
think
we're
gonna
face,
especially
as
adoption
of
rcd
begins
to
ramp
up.
You
know
there
are
gonna,
be
use
cases
where
it's
absolutely
essential
to
use
jwt
claim
constraints,
and
these
are
use
cases
that
involve
enterprises
and
delegation
and
all
that
kind
of
stuff.
G
But
you
know
then
they're
going
to
be,
I
think,
a
class
of
service
providers
and
potentially
veterans.
We
can
use
the
the
v
word
here
in
the
itf,
who
you
know
probably
are
not
going
to
be
signing
rcd
with
certificates
that
have
jvt
claim
constraints
in
them.
D
Yeah
I
mean
I
think
I
generally
agree
with
that.
I
think
I
agree
with
as
long
as
we're
on
the
same
page
that
my
biggest
concern
is
that
we
shouldn't
not
say
anything
that
encourages
the
use
of
integrity
but
yeah
to
to
have
any
normative
language
around
it.
I
agree
is
not
appropriate
for
at
least
the
back
go
ahead.
Ben.
G
D
There
was
some
news
text
that
I'm
just
recalling
now
that
maybe
I
didn't
catch
when
I
did
the
diff
around.
D
D
I
think
we
had
general
agreement
on
the
list,
but
I
think
you
know
that
would
be
one
more
thing
to
mention
that
I
want
to
make
sure
folks
are
generally
agreeing
with
as
well
again
I'm
not
saying
that
that
has
to
be
the
case.
It's
just
we're
pointing
that
out
as
a
potential
security
concern
like
that,
you
have
in
your
jwt
claim
constraints.
You
have.
You
know
essentially
not
plain
text,
but
in
the
asm1
there's
plain
text:
rcd
claims
that
could
be
exposed
because
certificates
are
public.
D
Okay,
so
what
should
we?
What
should
be
the
plan?
I
think,
can
we
work
on
the
list
on
this?
Is
this
something
we
want
to
try
to
work
out
on
the
list
and
and
push
this
forward,
or
is
it
going
to
take
another
meeting
cycle
for
this,
or,
I
guess
that's
my
question
all
right.
A
B
I
was
gonna
hope
we
don't
need
another
meeting
cycle.
That's
that
hope
always
goes
right.
We
should
never
need
another
meeting
cycle
for
anything,
but
in
this
case
I
really
hope
we
don't
need
another
meeting
cycle,
but
the
question
I
have
is:
has
there
been
enough
change
since
the
last
working
group
last
call
to
need
another
working
group
last
call
and
I
tend
to
think
we
have,
even
though
we've
done
a
bunch
of
them,
and
I
was
going
to
ask
my
co-chairs
opinion.
A
So
so
my
view
is
that
once
we
get
this
discussion
closed
and
another
draft
posted
17,
we
just
do
a
a
call
that
says:
are
there
any
new
issues
opened
by
these
changes
or
was
the
fix
to
your
previous
issue
not
adequately
resolved?
That
way?
It's
kind
of
a
a
closing
of
the
existing
last
call
yep.
D
D
Okay-
okay,
that's
all
I
had
to
discuss
for
this.
Is
there
any
other
comments?
Last
minute
comments.
G
You're
welcome
to
if
they're
available,
I'm
sure
it
would
take
me
tons
of
fumbling
around
to
figure
out
how
to
make
them
appear,
but
is
my
video
look
super
distressed
everyone
else?
I
look
like
I'm
in
an
8-bit
video
game.
G
Are
you
sure
it
is
a
little
wobbly
for
some
reason
I
I
am
in
an
8-bit
video
game,
it's
true,
amaze,
I'm
locked
in
1984
or
so
so
yeah.
Let's
talk
a
bit
about
connected
identities.
This
is
not.
This
will
be
a
recurring
theme
in
my
presentations
today.
This
is
not
a
very
substantial
update.
This
is
a
maintenance
update,
primarily
next
slide.
G
For
those
of
you
that
have
long
since
forgotten
about
what
we're
trying
to
achieve
here,
the
idea
of
the
connected
in
d
draft
is
basically
that
the
way
we
define
stir
because
of
stirs
problem
statement,
it's
really
focused
on
invites
right,
like
that's
the
only
thing
that's
getting
signed
practically
in
deployments
out
there
today
and
the
issue
with
that
is,
if
there
are
use
cases
where
it
makes
sense
to
be
able
to
sign
other
messages,
we
probably
need
some
guidance
about
how
to
do
that,
and
in
particular,
some
of
the
other
messages.
G
That
was
based
on
the
original
rc4474,
which
first
defined
the
identity
header
and
explain
how
we
can
get
basically
that
mechanism
updated
to
the
degree
that
it
needs
to
be
to
work
with
post,
rfc,
8224
stir,
and
there
are
a
couple
of
threat
models
that
actually
motivate
this.
Aside
from
this
question
of
how
do
I
know
the
person
I
connected
to
is
actually
who
they're
supposed
to
be?
You
know
it's
great
when
you
do
connect
to
a
bank,
for
example,
to
be
able
to
get
something
back
from
them.
G
You
know
a
star
level
assurance
that
the
number
you're
trying
to
reach
is
the
number
you
haven't
back
connected
to,
but
there
are
also
a
set
of
other
things
that
are
just
outside
of
the
original
stir:
a
threat
model
like
route
hijacking,
where
somebody
manages
to
connect
you
not
to
your
bank
or
even
kind
of
more
arcane
things,
and
this
comes
from
you
know,
work
and
threat
models
that
I'm
more
of
in
the
mobile
arena,
especially
around
things
like
short,
stopping
or
various
attacks,
where
an
intermediary
tries
to
tell
one
side
of
the
call
that
the
call
is
torn
down
and
tell
the
other
side
that
the
call
is
still
going
and
as
well.
G
G
So
what
have
we
done?
Well,
we
made
it
to
working
group
item
and
I
was
pleased
to
see
that
the
supporting
charter
text
is
now
in
place.
That
kind
of
removes
some
of
the
shackles
that
we
originally
put
on
the
start
working
group
to
keep
it
focused
strictly
on
that
impersonation
problem,
but
otherwise
it's
a
fairly
minor
revision
based
on
our
previous
discussion.
It
now
punts
on
conferencing.
We
talked
about
what
we
wanted
to
do
for
multi-party
cases
of
this.
G
Those
are
just
like
out
of
scope
of
this
for
the
moment
and
I'll
come
back
to
this
a
bit
when
we
talk
about
messaging
later,
but
you
know
there's
a
bit
more
text
in
there,
not
much
about
pre-association
and
the
potential
use
of
directories
to
determine
whether
or
not
someone
you're
trying
to
reach
supports
connected
identity
or
if
they
should.
You
know,
especially
as
this
is
a
new
idea,
not
something
with
any
implementation
in
the
field
today.
G
Obviously,
you
can't
have
any
expectation
when
you're
calling
a
particular
bank
that
they're
gonna
support
all
the
things
you
need
to
support
to
do
this,
and
you
know
there
are
a
couple
of
ways
potentially
to
mitigate
that.
One,
of
course,
would
be
if
there's
some
way
to
advertise
support
for
it.
You
could
also
do
something.
That's
more
like
trust
on
first
use-ish
right
where
I
know
in
the
past,
when
I
connected
to
this
particular
bank,
they
did
support
connected
identity,
I'm
just
going
to
kind
of
log
that
and
remember
it.
G
G
What
one
thing
this
does
desperately
need
is
examples
is
to
update
the
examples
from
rfc
4916..
I
was
kind
of
surprised,
actually,
I'm
just
going
back
through
4916.
It
doesn't
really
seem
to
have
an
example
of
connected
identity
during
call
setup.
It's
really
kind
of
focused
on
getting
the
initial
call
done
and
then
kind
of
renegotiating
who
it
is
that
you
ended
up
connecting
to
so
I
started
mocking
up
based
on
the
text,
I'd
written
previously.
G
What
I
think
some
of
those
examples
would
look
like,
but
obviously
we'll
need
detailed
message,
breakdowns
of
both
a
sunny
day
case
and
a
rainy
day
case.
You
know
the
sunny
day,
one
just
being
I
connected
to
my
bank
great.
They
send
me
an
update
message
in
the
backwards
direction,
a
passport
that
shows
me
that,
in
fact,
I
reached
the
number
that
I
was
trying
to
reach.
That's
fantastic
and
then
a
rainy
day
case
where
I
was
trying
to
reach
bob
and
instead
carol
is
replying,
and
at
least
I
have
a
passport
that
ensures
me.
G
That
carol
is
who
I
think
carol
is
and
what
I
then
do
with
that
information.
How
that
factors
in
is
something
that
obviously
has
left
a
local
policy
into
the
unfortunately
pretty
pretty
strict
constraints.
G
So
yeah,
I
still
do
have
an
open
action
item
to
put
in
some
more
text
about
privacy
and
anonymity,
and
this
is
kind
of
an
issue
and
that
you
know
if,
if
I
can,
especially
using
a
medialis
dialogue,
which
is
one
of
the
things
that's
discussed
for
how
you
might
kind
of
forge
a
pre-session
to
ascertain
who
it
is,
I'm
gonna
be
connecting
to
and
then
choose
to
elevate,
that,
with
updates
into
like
a
real
tip
session
with
media
and
so
on.
G
You
know
that
could
be
used
to
like
probe
in
ways
that
might
reveal
information
that
we
don't
want
to
reveal,
and
so
there
probably
needs
to
be
some
guidance
in
there
at
least
about
what
we
think
the
potential
privacy
risk
is
in
that
it
may
be
that
people,
don't
particularly
want
you
to
know
who
you're
going
to
be
reaching
when
you
call
this
number.
G
Obviously,
since
this
is
an
optional
feature,
they
could
always
choose
not
to
share
a
connected
identity
in
the
backwards
direction
if
they
thought
that
they
didn't
want
to
reveal
who
they
were.
But
nonetheless,
you
know
just
automated
systems
that
are
doing.
This
could
end
up
shedding
data
that
we
don't
want
shed.
So
we
need
some
privacy
security
text
to
wrap
around
that
now.
G
I've
kind
of
gone
back
and
forth
over
the
years
of
whether
I
think
this
is
really
abyss
of
4916
and
I
think
it's
not
in
the
sense
of
the
stuff
that
4916
actually
defines.
I
don't
think
we're
modifying
so
much
as
explaining
how
it
applies
or
could
be
reapplied
to
what
is
in
824,
as
opposed
to
rc,
44
74.,
and
you
know.
Definitely
the
examples
need
to
reflect
all
this
like
that.
G
But
you
know
I,
unless
people
here
feel
strongly
about
this-
and
I
think
I
probably
have
raised
this
before
in
previous
meetings
like
I
think,
I'm
comfortable
with
this
kind
of
just
being
like
an
update,
as
I
said,
rather
than
a
formal
abyss
that
is
intended
to
obsolete
4916.
G
But
you
know
people
feel
strongly
about
that.
They're
welcome
to
weigh
in,
but
that's
about
it
on
this
one,
like
I
said,
not,
there's.
There's
stuff
still
to
do.
I
still
think
we
need
this.
It's
not
in
my
super
pressing
category
of
things
that
we
need.
So
you
know
I'm
not
it's
not
on
a
front
burner
of
mine
at
the
moment,
but
definitely,
I
think,
more
review
energy
interest.
All
that
stuff
would
be
welcome
and
needed
next
slide.
G
A
D
I'm
already
co-author
of
this
document,
but
I
will
say
that
you
know,
especially
if
we
can
get
an
rcd
done.
I
will
definitely
spend
more
time
on
this
document.
D
There's
really
not
too
many
changes.
I
think
we
were
sort
of
pretty
much
in
agreement
on
most
of
the
content
before
you
can
go
to
the
next
slide.
D
I
did
include
the
specific
reference
to
robert's
draft
and
a
few
I
think,
they're
only
editorial
updates.
Robert.
Do
you
want
to
say
something.
C
So
now
that
you've
made
that
reference-
and
I
think
this
is
the
only
reference
to
the
document-
that
document
still
needs
to
go
through
subcore,
I
suppose,
does
it
need
to
wait
for
anything
or
do
we
tell
push
or
go
ahead
and
publish
it.
D
Thank
you
for
doing
that.
I
did
add
some
basic
security
considerations
just
to
to
put
that
in
there,
but
somewhat
repeats
some
of
the,
in
particular
the
privacy
consideration
of
making
sure
that
you
strip
the
passport.
D
If
you
use
that
as
an
id
to
reference
the
the
passport
that
has
an
error
going
back
so
just
reinforcing
that
I
guess
other
than
that
go
jack.
You
have
a
comment.
F
Hey
so
I
vaguely
recall
having
a
discussion
about
the
fact
that
that
security
consideration
to
strip
what
wasn't
actually
enough
and
that
we
probably
need
an
extra
security
consideration,
saying
that
if
you
value
your
privacy,
you
need
to
use
the
compact
form
rather
than
the
full
form,
because
intermediate
the
intermediate
diverting
entities
might
not
understand.
This
might
not
have
implemented
this
and
so
won't
strip
their
information
and
therefore
they
will
just
happily
pass
it
back
and.
D
D
A
So
that's
what
what
we'll
plan
for
sounds
good.
B
Apologies,
I
don't
seem
to
have
that
one
preloaded.
Let
me
give
me
just
a
second
and
I'll
get
the
slide
decked
out,
but
it
might
take
a
couple
of
seconds
here.
G
G
This
is
something
that
you
know
for
me
is
motivated
by
a
couple
of
use
cases,
I'm
more
of
mostly
in
the
international
space
where
some
nations
or
systems
are
looking,
are
not
optimistic
about
making
an
ip
transition
entirely
anytime
soon,
but
are
nonetheless
trying
to
realize
some
of
the
value
of
stir
shaken
with
something
like
the
certificate
architecture
that
you
know
allocates
certificates
to
service
providers
in
a
roughly
shaken
like
way,
but
that
they
would
have
the
ability
to
access
what
we
call
a
call
placement
service
in
8816
to
store
and
retrieve
passports
such
that
potentially,
you
can
circumvent
the
amount
of
pstn
or
potentially
even
ip,
that
just
simply
is
not
going
to
send
passports
end
to
end.
G
That
might
be
between
a
couple
of
service
providers
and
the
bit
of
sleight
of
hand.
We
did
that
that
alters
the
original
rfc
8816
threat
model
was
that
you
know,
since
really
rc
16
was
focused
on
preventing
data
collection
at
the
cps
when
it's
operated
as
a
third-party
service.
G
What
we
kind
of
assume
for
the
purposes
of
the
service
provider
ob
draft
is
that
the
cps
is
not
a
monolithic,
centralized
nad,
but
is
rather
something
that
is
operated
on
behalf
of
service
providers,
specifically,
who
are
going
to
see
the
pstn
signaling
anyway,
and
so
like
any
information
that
we're
sending
in
like
a
bear
passport,
is
really
redundant
with
signaling
information,
they're,
probably
going
to
receive
now.
You
know
we
say
that
it's
either
operated
by
one
of
these
csps
or
is
operated
on
their
behalf
either
way
kind
of
contractually.
G
The
assumption
is
that
we're
no
longer
as
concerned
about
the
data
collection
model,
and
so
you
know,
like
I
said
this
is
this-
is
descriptive
of
kind
of
emerging
efforts
that
I
see
in
a
couple
of
places
to
do
this.
Obviously
there
is
a
spec
and
addis,
which
alec,
I
believe,
is
on
the
line
wrote
that
looks
at
kind
of
the
more
gatewaying
specific
case
and
especially
kind
of
looks
at
like
okay.
We
have
an
ipad-
and
I
here
in
the
united
states
and
there's
going
to
be
some
bits
of
pstn.
G
That
sort
of
hang
off
of
it
is
there
a
way
that
we
can
like
make
this
work
for
that
as
like
a
gateway
function.
This
is
looking
much
more
broadly
at
if
you
have
an
ecosystem
of
players
who
don't
have
an
ip9
between
them.
Necessarily
like
you
know,
what
are
their
prospects
to
be
able
to
use
a
cps
so
next
slide.
G
Once
again,
this
is
a
brief
maintenance
update,
so
really,
for
example,
the
things
that
are
significant
open
issues
in
this
are
about
what
the
interfaces
are,
that
server
service
provider
providers
would
utilize
to
access
the
cps
right
now,
I'm
basically
pointing
to
rfc
8816
and
saying
there
is
a
rest
interface
defined
in
that
that's
the
rest
interface
that
we
propose
using
the
security
for
that
is,
of
course,
based
on
the
possession
of
certificates
that
are,
you
know,
used
when
storing
or
retrieving
passports,
to
restrict
it
just
to
that
community
of
service
providers
that
are
interacting
with
the
cps
now
the
issue
is
8816
is,
of
course,
informational.
G
This
document
has
aimed
for
ps
from
its
inception.
You
know
if
you
look
back
politically
historically,
like
rc-8816
was
made
informational,
because
people
weren't
very
comfortable
without
a
band
overall.
At
the
time,
I
think
the
there
has
been
a
bit
of
a
tectonic
shift
around
that
in
the
way
that
people
are
looking
at
out
of
band
and
as
a
a
consequence,
you
know
I
would
just
eat
the
down
ref.
G
To
be
blunt,
I
mean
we
could
just
copy
that
passage
out
of
8816
and
put
some
more
normativity
into
it
and
like
have
that
be
in
this
document,
but
I
mean
this
is
something
I
guess
question
for
the
chairs
and
for
anybody
it's
process-wise
wants
to
comment
like.
I
would
just
eat
the
down
ref
if
nobody
says
otherwise.
G
Yeah
yeah,
I
mean,
I
think
it's
it's
a
pretty
easy
sell,
because
I
mean
there
is
enough
of
an
api
specified
in
8816.
That
I
mean
I
think
it
could
have
been
ps
right
like
if
we
just
you
know,
choose,
chose
to
push
it
that
way
for
us
any
comments.
Well,.
G
G
G
You
know
in
the
the
push
model,
there's
an
assumption
that,
because
the
cps
is
effectively
acting
on
behalf
of
a
particular
service
provider,
any
passports
that
are
pushed
to
it
can
just
be
pushed
down
to
the
terminating
search
providers
obvs
and
the
obvs
doesn't
need
to
like
wait
for
a
call
to
come
in
and
be
like.
Oh,
I
need
to
go.
Ask
the
cps
for
any
passports
that
might
exist
for
this
call
and
like
get
them
back.
G
That
just
seems
like
a
recipe
for
the
introduction
of
additional
latency
and
needless
rtts,
and
you
know
I
kind
of
went
back
and
forth
as
we've
been
working
on
this
of
how
much
I
want
to
specify
that
push
interface
in
part,
because
it's
easy
for
me
to
imagine
models
where
the
cps
and
the
ob
vs
are
effectively.
G
You
know
the
same
entity
right
and
like
because
the
the
cps
exists
for
the
purpose
of
receiving.
You
know
we
imagine
it
is
scoped
to
the
terminating
service
writers.
You
know
interests
then,
like
you
know,
it
exists
for
no
other
purpose
than
to
receive
passports
that
are
supposed
to
go
to
that
obvs.
G
G
Okay,
I'm
going
to
push
this
passport
to
servicewriter
a,
whereas
this
password
goes
to
service
provider
b
and
like
we
could
specify
a
whole
subscription
notification
interface
right
between
ob,
vss
and
cps's,
where
you
say
exactly
what
resource
it
is
you
want
to
subscribe
to,
but
as
the
fine
print
and
the
bullet
down
there.
The
third
bullet
from
the
bottom
suggests.
G
G
Some
kind
of
external
database
needs
to
tell
you
that,
and
you
know,
I
suspect,
that
that
logic
will
end
up
living
more
in
places
like
that
than
in
okay.
I'm
gonna
figure
out
a
way
to
describe
you
know
to
do
a
subscription
that
is
gonna
specify
like
every
number
in
this
list.
I'm
gonna
push
this
to
the
cps
and
how
the
point
is.
G
This
document
can
advance
faster
like
because
you
know
the
more
I
looked
at
it,
the
less.
I
actually
want
to
go
to
the
hassle
of
defining
that
subscription
interface,
when
I
think
it's
actually
pretty
much
inert
in
terms
of
what
the
cps
would
practically
do
to
figure
out
how
it's
going
to
distribute
passports,
anybody
want
to
push
back
on
that
or
have
a
better
idea
because,
like
that
seems
to
be
the
reality
on
the
ground
for
me.
If
how
this
would
work,
alec.
H
Yeah,
so
we
we
built
one
of
these
actually
and
I
really
liked
it,
but
for
other
reasons
it
we
we
changed
it,
but
the
basically,
I
think
so.
H
They
could
subscribe
to
their
entire
unique
id
or
even
specific
numbers,
prefixes
of
numbers
within
their
unique
id,
but
they're
they're
scoped
to
their
id.
So
it's
kind
of
like
a
coupling,
but
then
it's
it's
multi-tenanted.
So
it's
separate
I
it
worked
really
well.
It
was
really
cool
because
you
could
and
it
was
push
it's
fast
much
faster
than
retrieving.
I
mean
retrieving
is
fast,
but
it
was
you
know
it.
We
beat
the
call
every
time.
Every
time
way
before
the
call
I
mean
it
wasn't
even
close
tdm
is
so
slow.
G
Yep,
no,
I
believe
that
yeah,
I
mean
that's
another
great
example
like
anything
that
just
prefixes
the
url
or
uses
url
decoration
in
some
form
to
differentiate
which
terminating
service
provider
you
are
targeting
with
the
cps
push
like,
I
think,
makes
this
pretty
trivial.
I
mean
my
question
is
just
how
much
value
do
you
get
out
of
the
tsp
being
able
to
subscribe
to
some
subset
of
the
passports
that
are
supposed
to
go
to
it?
Because
if
there's
like
real
value
in
that,
then
there
might
be
value
in
specifying
a
subscription
interface.
H
We
we
created
it
so
that
it
was
multi-tenanted,
so
the
terminating
service
fighter
could
give
credentials
to
their
enterprise
and
then
let
the
enterprise
and
the
terminating
service
provider
was
all
using
pki.
So
actually
it
was,
we
didn't
even
maintain
credentials.
It
was
really
nice,
but
they,
the
the
enterprise,
could
be
giving
credentials
signed
by
the
terminating
service
provider
that
scoped
them
to
a
specific
set
of
of
numbers,
and
then
they
could
subscribe
and
receive
those
directly.
G
H
They
wouldn't
know,
and
so
then
this
is
where
the
problem
we
had
with
the
with
that
model
in
the
first
place
was
right.
The
person
publishing
has
to
know
your
server's
unique
id
and
then
you
kind
of
defeat
we
just
you're
shifting
the
problem
of
the
cps
having
to
know
who
it
belongs
to
to
the
osp
having
to
know
who
or
whoever
is
publishing
it
to
having
to
know
they
have
to
put
the
right
url
in
there
and
how
do
they
know
what
the
url
is?
H
G
F
G
Right
and
like
my
favorite
is,
of
course,
to
just
bake
the
cps's
url
into
the
serve,
and
so
any
case
we're
using
like
delegation.
Enterprises
like
the
enterprise
of
cert
would
actually
have
this,
but
that,
basically
I
mean
I
understand
that
that
just
transposes
this
into
a
certificate
discovery
problem.
But
I
actually
like
that
problem
more
because
we
already
have
a
network
of
sticrs
right,
like
it's
their
job,
to
get
these
certs
out
so,
like.
G
I
think,
there's
a
couple
ways
to
skim
that,
but
I
I
think
I
do
want
to
think
some
more
about
that
question
of.
If
there
are,
you
know,
multiple
entities
behind
the
tsp
effectively
that
that's
being
shared
out
to
what
the
implications
of
that
would
be
for
this
yeah.
H
One
comment:
we
we
use
something
called
nats
as
the
the
client,
the
it's
a
open
source
system.
But
the
point
is,
I
guess
I
I
don't
know
that
you
would
necessarily
want
to
define
a
formal
push
mechanism
like
the
the
symantec.
You
know,
people
may
want
to
leverage
exist.
There's
a
lot
of
pub
sub
systems
out
there.
Maybe
people
want
to
use,
you
know
pub
sub
systems.
We
we
didn't
build
our
own
pub
system,
we
we
we
used
the
existing
one
that
has
its
own
internal
protocol,
that
it
uses
and
supports
pki
based
authentication.
H
G
G
G
D
100
agreement
that
we
should
not
define
a
new
push
interface
and
we
should
either
make
it
abstract
or
or
or
some
something
that
allows
people
to
use,
existing
solutions
that
are
battle,
tested,
etc.
Yeah.
G
G
You
know
I
mean,
if
everybody's
cool
with
that
this
might
really
be
nearing
its
final
form.
You
know
if
we're
aiming
this
for
ps,
I
think
I
probably
want
to
go
through
and
sprinkle
in
some
musts
and
shoulds
and
places
that
are,
but
they
probably
belong
that
they
there
aren't
now
but
like
otherwise.
I
think
this
is
good
for
some
serious
review
and
like
if
anybody
has
any
interventions
or
thoughts
or
other
places
we
should
take
it,
I'm
glad
to
talk
about
them,
but
this
might
be
getting
close.
E
F
So
something
I
kind
of
missed,
as
you
were
going
through,
the
slides
is
the
api
for
pulling
the
passports
from.
F
At
881.6816
would
that
be
normative
as
an
api,
or
is
it
just
a
suggested?
This
is
what
it
could
look
like.
G
That's
a
really
good
question.
I
mean
it's
kind
of
your
job
when
you're
doing
this
as
ps
to
be
normative.
If
you
can
be,
but
I
don't
think
we'd
want
that
to
be
exclusive.
No,
I
think
we
want.
We
want
to
have
a
representation
of
the
architecture
that
is
clear
what
the
security
properties
are
and
then
be
able
to
point
8816
and
say,
like
you
know,
this
is
a
standard
way
to
do
that
right
and
like.
I
don't
think
we
want
to
say
that
there
is
no
other
possible
api
for
this,
but
that
one.
G
So
I
I
think
I
might
you
know,
there's
a
traditional
dodge
used
in
the
itf,
which
is
we
say
something
is
mandatory
to
implement,
but
not
mandatory
to
use.
I
might
say
that
implementations
that
are
compliant
with
this
specification.
G
It
would
be
mandatory
to
implement
that,
but
that
and
because
it's
just
rest
right,
I
mean
it's
like
bare
rest
like
it's,
not
something
that
you
know
is
a
pretty
heavy
lift
for
anyone,
but
not
mandatory
to
use
so
that
alternatives
could
be
used.
Would
that
assuage
any
concerns.
G
Anything
like
this
now
is
going
to
require
given
who's
interested
in
doing
this
at
this
point,
so
like
yeah,
please
do
jack.
It
just
is
a
personal
favor
to
me.
Please
go
back
and
look
at
it.
I
mean
it's
just
it's
just
like
press
stuff.
It's
not
like,
I
don't
think,
there's
any
any
hidden
magic
in
there.
B
So
I'm
going
to
pull
the
usual,
I
haven't
had
a
chance
to
read
the
most
recent
update,
but
I
haven't
commented
about
it
anyway.
B
Oh,
but
the
one
thing
I
would
like
people
to
do
is
think
really
hard
about
the
security
considerations
and
because
this
came
up
in
some
of
the
addis
discussions
and
mainly
those
are
referring
out
to
security
considerations
in
the
informational,
the
big
out-of-band
rfc
around
the
potential
for
replay
attacks
and
just
think
about.
Is
there
anything
else
we
need
to
say
here
that
we
haven't
said.
I
don't
know
that
there
is
I'm
not
suggesting
there
is,
but
I
think
we
need
to
make
sure
that
people
think
about
that
when
they
look
at
this.
G
Yeah,
I
I
think
I
did
even
introduce
some
new
text
about
the
substitution
attack,
which
is
the
only
one
that
anyone
seems
to
care
about
in
this
again.
I
you
know
the
my
party
lied
in
the
substitution
attack
for
a
long
time
has
been
pretty
clear.
I
think
that
I
don't
think
it's
a
problem
for
impersonation
use.
Cases
like
we
consider
for
robocalling
right
where
the
problem
is
bulk,
unsolicited
commercial
communications.
G
I
I
don't
think
it
makes
sense
for
any
number
of
reasons,
but,
like
you
know,
in
the
end
of
the
day
and
ecker-
and
I
went
around
this-
you
know
maple
endlessly,
when
this
ob
first
started
up
like
it's,
it's
a
pretty
dangerous
like
there's
a
lot
of
exposure
in
launching
that
substitution
attack
like
it's
pretty
obvious
that
you
tried
to
do
it
and
like
the
kind
of
powers
you
need
to
have
to
launch
it
successfully
are,
are
pretty
extreme.
G
Now
there
are
cases
again
where
there's
a
lot
of
money
at
stake,
or
whether
you're
a
state
actor
or
something
or
that
stuff
worries
me
but
yeah.
It
doesn't
worry
me
for
the
vast
majority
of
what
stewart
has
traditionally
be
concerned
with,
as
we
get
more
into
kind
of
fraud
cases.
I
maybe
get
a
little
more
worried
about
the
substitution
attack.
G
D
I
was
just
going
to
make
a
comment
relative
to
the
api
stuff.
I
think
the
problem
for
me
using
rest
as
a
interoperable
protocol
is
when
you
get
to
things
like
authentication
and
other
parts,
it
sort
of
breaks
and
there's
probably
a
few
other
dimensions
that
I'm
not
even
thinking
of
off
the
top
of
my
head.
So
even
though
it
looks
simple
from
the
beginning,
you
know
to
fit
it
in
a
framework
that
people
are
authenticated
and
and
other
things
like,
that
it
sort
of
breaks
down.
D
So
I'm
not
a
big
fan
of
standardizing
apis
from
that
perspective,
but
that's
my
personal
feeling.
G
Yeah
and
just
be
clear,
I
mean
the
intention
in
search
right
or
ob
draft.
Is
that
your
your
authentication
is
based
on
your
store
credentials
right
and
like
that?
That's
that's
the
price
of
admission
of
dealing
with
a
cps,
and
so
hopefully
that
updates
some
of
it.
But
is
there
something
more
specific
that
you're
concerned
about
with
authentication.
D
If
it,
if
it's
that
straightforward,
if
like
the
request,
is
signed
somehow
or
I'm
not
that
I
would
have
to
look
back
at
the
draft,
how
it
works.
But,
as
you
know,
as
long
as
it's
a
common
way
of
doing
it
and
and
people
don't
have
to
build
other
things
around
it,
which
won't
be
interoperable.
D
That,
then,
then
that's
that's.
A
better
situation
like.
G
In
the
draft
now
is
alex
personal
favorite,
which
is
using
mutual
tls
right
so
that
actually
your
https
connection
is
just
like
secured
by
by
tls
from
you
know,
based
on
your
search,
I
know
allocates
it,
which
is
his
favorite,
but,
and
I
mean
I,
I
think
that
you
know
there
are
alternatives
to
that.
Like
you
know,
the
addis
approach
uses
signing
a
token
instead
designing
a
passport.
G
Basically
right,
and
so
I
mean
there
are
alternative
ways
to
bootstrap
the
you
know,
the
certificates
into
the
security
association
with
the
http
server
but,
like
I
think,
the
the
most
itf-ish
way
would
be
to
say,
use
mutual
tls
just
have
the
tls
be
where
that's
that's
rooted.
D
Yeah,
maybe
that
can
work
but
yeah
just
my
opinion
and
just
a
comment.
G
H
No,
I
completely
agree,
I'm
not
a
fan
of
mutual
tls.
H
Just
in
practice,
I
find
it
can
be
difficult
on
public
services,
but
one
comment:
I
had
kind
of
going
back
to
the
previous
comment
about
the
replay
attacks
that
I
don't
know
if
you're
familiar
with
the
addis
1095
kind
of
uui,
putting
passports
in
a
ui
coded
in
a
special
way
to
make
them
fit,
but
that
that
idea
a
little
bit
thinking
about
what
if
we
could
put
something
in
maybe
the
uui
or
maybe
somewhere
else
in
the
tdm
kind
of
like
some
unique
identifier
that
maybe
could
help
to
then,
when
we
get
to
the
other
side
right,
you
can
have
that
identifier
and
say:
okay
yeah.
H
This
is
really
the
right
call.
Now
it's
got
to
make
it
to
the
other
end,
which
is
can
be
a
challenge,
but
the
uui
could
be
a
good
option
that
looks
like
maybe
that's
got
a
high
probability
of
making
it
to
the
other
end.
G
Yeah,
so
I'm
aware
of
these
and
for
those
that
aren't
following
the
other
stuff,
this
is
this:
is
we're
talking
ice
up
here,
ice
up,
uui?
Yes,
you
know,
I,
I
guess
my
the
prospects
I
have
for
biceps
931
like
actually
being
changed
enough
to
permit
this
to
go
through.
I
personally
don't
think
the
prospects
that
are
very
good.
I
mean
it'd
be
interesting
to
hear
from
people
that
think
you
know
we
can
upgrade
the
ssv
network
I've.
G
I
think
it's
been
kind
of
a
you
know
a
talking
point,
maybe
a
canard
for
the
last
like
10
years,
that
just
it's
not
feasible
to
upgrade
that
network
in
any
in
any
way.
That
would
result
in
like
and
then
stuff
working
between
discrete
service
provider
environments
so
like
I
I'm
I'm
certainly
not
opposed
to
it
in
principle-
and
I
agree:
we've
talked
about
as
well
about
like
in-band
media
indications
like
there
are
all
kinds
of
ways
you
can
try
to
get
some
additional
signal
through
the
pstn
channel
that
would
mitigate
those
substitution
attacks.
G
I'm
just
not
that
worried
about
the
substitution
attacks.
I
guess
I'm
really.
I
think
it's
it's!
It's
prohibitively
difficult
to
launch
and
it's
like
super
detectable.
It's
super
hard
to
win
and
like
you
need
like
really
good
powers
to
be
able
to
figure
out
how
to
do
it
like
powers
that
involve
like
compromising
call
processing
systems
that
you
can
like
tell
calls
or
in
progress
that
you're
in
a
race
against.
G
Like
you
know,
apart
from
some
of
those
baiting
attacks-
and
I
you
know,
I
don't
really
think
the
beating
attacks
are
feasible
for
most
scenarios.
You
know
I'll
put
it
this
way.
I
think
it
it's
more
feasible
to
defeat
this
through
just
like
implementing
reasonable
security
back
best
practices
around
things
like
that
than
like
changing
ice
up.
B
If
you're
going
to
exactly
respond
to,
if
you're
going
to
respond
directly
to
what
he
just
said,
go
ahead.
H
So
I
I
agree,
I
guess
so.
I
was
actually
kind
of
thinking
of
this
from
a
couple
ways.
So
one
yeah,
the
replay
some
identifier
that
could
be
beneficial.
I
agree,
I
think,
that's
very
challenging
to
to
do
in
practice,
certainly
for
the
robocall
use
case.
I
really
agree
with
kind
of
everything
there,
but
I
think
maybe
there's
a
second
way
to
look
at
it.
That
could
be
helpful.
H
The
the
cps
discovery
is
a
major
problem
right,
not
to
say
it
doesn't
have
solutions,
but
it,
but
it
can
be
a
problem
it
can
be,
can
be
challenging.
One
thing
I
was
looking
at
was
what,
if
we
just
put
a
url
in
the
uui
of
iso
signaling,
and
that
url
is
the
call
placement
services
url,
there's
no
longer
a,
I
need
to
know
which
url
it's
no
longer
this,
it's
no
longer
the
tsps
or
I
say
tsp,
it's
no
longer
the
provider
converting
it
back
to
sep
or
the
tsp.
H
Whichever
the
case
is,
it's
actually
the
osp
or
the
provider
converting
it
to
tdm,
it's
their
call,
placement
service
and
so
they're
going
to
put
it
in
their
call
placement
service.
Basically,
when
they,
when
you
convert
a
call
to
tdm
you
make
it
the
passport
available
in
the
cps,
and
then
you
put
in
this
iso
signaling
here's
how
you
go
get
it.
H
It's
really
kind
of
really
very
similar
to
95,
where
you're
you're,
using
iso
signaling,
but
95
tries
to
put
everything
in
iso
signaling
and
that
works
or
cases
where
you
have
so
little
information
that
it
fits.
But
as
soon
as
you
have
too
much
information,
it
doesn't
fit
anymore
and
you
start
losing
things
and
if,
instead,
you
just
put
a
url,
you
could
have
20
passports,
it
doesn't
matter
it's
just
a
url
and
that
url
is
going
to
have
some
random
string.
H
So
you've
not
only
dealt
with
the
replay.
You
also
now
don't
have
to
distribute
passports
between
different
call
placement
services.
You've
dealt
with
discovery,
you've
kind
of
dealt
with
everything,
so
that's
something
I'm
kind
of
looking
at
and
I
might
be
submitting
a
contribution
in
nipka
for
just
so
everybody's
aware.
G
H
G
Interesting,
if
we
should
talk
more
about
it
offline,
I
mean
you
know
there.
I
think
there
are
hard
edges
around
that
and
again,
a
lot
of
it
comes
down
to
exactly
who
we
expect
what
what
the
relationship
is
between
the
gateway
that
is,
both
you
know,
do
doing:
ipd,
pstn
and
psd
and
ip
and
the
osp
and
the
tsp
and,
like
the
yeah.
G
A
lot
of
this
comes
down
to
how
you
stage
the
cps
to
meet
the
security
principles
that
we're
trying
to
achieve
with
this
draft
right,
which
are
not
allowing
third
parties
to
be
the
operators
of
cps's
and,
like
you
know,
unless
they're
specifically
again
contracted
to
the
either
the
osp
of
the
tsp
and
like
how
you
know,
because
if
what's
happening
is
there's
like
a
yard
of
pstm
that
calls
go
through
somewhere
in
the
middle
in
transit
networks
that
has
no
relationship
to
the
osp
or
tsp.
G
That
gets
much
harder
for
me
from
a
security
perspective.
But,
like
you
know
that
doesn't
mean
it's
not
solvable
like
you.
If
you
imagine,
for
example,
that
your
url,
the
url,
the
cps
was
like
already
in
something
that
is
being
carried
like
with
the
passport
as
it's
traveling
and
like
that,
just
gets
to
go
into
the
ui
and,
like
you
know,
is
perceptible
to
the
tsp
when
it
arrives
like
there
are.
There
are
ways
that
that
could
help
yeah,
definitely.
H
And
just
I'm
thinking
this
is
operated
by
the
provider,
converting
the
call
to
tdm.
So
any
privacy
concerns
really
don't
exist
because
the
provider
they
have
the
signaling.
They
have
the
identity,
header
they're,
making
it
accessible
to
the
person
downstream,
but
they
already
have
it.
And
yes,
maybe
they
outsource
their
their
call
placement
service
to
a
third
party.
But
maybe
the
answer
is
their
authentication
to
a
third
party
verification,
and
all
that
I
mean
it
says.
H
There's
no
third
party
that
wasn't
contractually
asked
to
do
something
that
has
access
to
anything
and
anyone
who
has
access
to
it
already
had
access
to
the
passports
and
the
sip
signaling
or
tdm
signaling
and
everything
so
kind
of
again
avoiding
the
privacy.
I
agree
with
what
you're
saying
about
that.
G
I
mean
I,
I
guess
at
a
high
level.
I'd
say:
probably
this
isn't
something
you
know
figuring
out
how
to
stuff
something
into
uui
is
probably
not
what
we're
going
to
do
in
the
itf
so
like.
Maybe
that
that
you
know,
as
an
ipka
thing,
that's
cool,
but
I
doubt
that
would
end
up
being
in
the
scope
of
this
document.
This
work
here,
even
if
it
does
end
up
helping
it
in
the
long
term
yeah.
I
I
kind
of
figured
okay
ben
you've,
been
you've
been
waiting
for
a
while.
B
So
that
conversation
was
very
specific
to
tdm,
interconnects,
and
so
is
the
nepka
use
case
is
very
specific
to
tdm
interconnects
and
but
it
made
me
think
about.
Are
there
ways
you
know?
I
think,
at
a
high
level,
what
we're
talking
about
is
adding
some
extra
information
to
the
signaling
to
bind
to
bind
the
passport
to
avoid
the
substitution
attack.
B
You
know
so
you're
binding
on
more
than
just
the
from
and
two
numbers,
and
I
know
this
is
futile
to
talk
about
putting
something
except
for
this.
You
know,
because
anything
you
put
into
it,
gets
stripped
by
the
very
sort
of
people.
You
want
to
not
strip
your
passports,
but
I've
heard
you
know.
People
speculate
on
other
use
cases
about
a
ban,
for
example
like
just
mentioning.
B
Maybe
you've
got
this
sep
interconnect,
that's
still
using
udp
and
can't
handle
fragmentation,
so
you
pretty
much
can't
send
passwords
or
identity
headers
and
if
you
had
some
extra
separator
that
they
would
somehow
be
trusted
not
to
mess
with,
they
could
be
used
to
help
bind
that
passport
to
the
other
end,
and
I
know
that
that's
futile
and
then
also
I've
heard
some
speculation
and
I
think
it's
even
mentioned
in
your
messaging
draft
about
potentially
using
out-of-band
in
messaging
cases.
B
G
Yeah
and
for
messaging
that
that's
the
goal
right
is
to
make
it.
So
all
you
can
reply
is
identical
messages
and,
since
the
passports
have
a
time
stamp
like
they'll,
just
they'll
show
up
in
your
ui's
timeline
is
a
dupe
right
like
provided.
You
know
your
inbox
experience
is
like
halfway
decent,
but
yeah.
It
is
important.
To
note
I
mean
I
I
don't
talk
about
ob
either
here
or
in
8816
is
something
specific
to
the
tdm
problem.
I
think
the
tm
problem
is
like
super
interesting,
but
like
there
are
a
lot
of
reasons.
G
Passports
don't
get
end
to
end
it's
not
it
policy
is
probably
the
number
one
right
and
so,
like
you
know,
even
if
we
get
past
all
the
sbcs
that
just
strip
everything
and
so
on,
it's
really
policy.
That
is
the
I
think
the
you
know
it
is.
Something
is
something
at
least
that
I
want
this
to
address
if
it
can
and
like
so
yeah.
G
I
I
share
your
pessimism
about
being
able
to
do
anything,
practical
and
sip
that
would
be
conveyed
and
end
in
environments
where
that
stripping
is
occurring
either
due
to
malice
or
incompetence.
Right
like
if
the
passport
isn't
going
to
survive,
I
can't
imagine
anything
else.
That's
going
to
survive
that
we
would
be
able
to
tunnel
as
like
a
the
secret
indicator.
It
reminds
me
you
know
that
this,
the
solid
people
remember
that
solid
thing
it's
one
of
sir
timothy's
projects.
G
You
know
they
had
their
proposal
for
how
to
do
stir
together
with
solid
and
part
of
the
way
that
it
worked.
Is
you
would
put
in
like
a
phony
calling
party
number
and
that's
actually
what
you're
tunneling,
because
there's
this
like
resolution
service,
that
the
terminating
side
would
use
to
transform
that
phony
number
into
the
url
of
the
place
where
your
passport
lives
and
like
I
could
you
could
you
can
certainly
get
like
steganographic
like
that
about
this?
G
If
you
want
to
go,
you
know
totally
over
the
top,
but
there
were
a
number
of
reasons
why
I
think
that
was
a
bad
idea
in
stir
solid,
and
I'm
not
sure
I
want
to
you-
know,
really
scrape
the
bottom
of
the
barrel
for
ways
that
we
can
like
tunnel
information
through
any
of
these
signaling
protocols.
It
may
turn
out
there's
something
useful.
We
can
do
with
uui
or
something
like
that.
G
F
So
so
what
so
we?
This
doesn't
work
for
kind
of
obvious
reasons,
but
we
already
have
a
mechanism
to
do
this.
We
have
media
key,
which
obviously
doesn't
work
because
pst
and
tdm
all
of
that
stuff,
just
like
you,
can't
do
tls
over
that,
but
the
the
idea
of
that
is
to
tie
the
signaling
to
the
passports
and,
in
fact,
if
you
don't
do
that
and
you're
using
and
you're
in,
like
a
pure
sip,
everything
makes
it
all
the
way
through.
There
are
still
ways
to
impersonate
people
using
div,
and
things
like
that.
F
I
guess
I'm
saying
it
like
this
isn't
a
particularly
new
problem
in
a
way
the
the
the
the
fact
that
signaling
needs
to
be
tied
to
the
passport
has
been
a
problem
for
a
while
now
and
wouldn't
be
added
by
isn't
exactly
new
with
ob
yeah
and
but
I'm
not
convinced
that
that's
a
good
situation
to
be
in.
G
I
mean
again
for
the
purposes
of
defeating
these
robocalling
attacks,
which
is
where
we
started
from,
and
that's
right
like.
I
think
it
helps
in
the
sense
that
you
know
if
it's
just
a
hassle
to
impersonate
people,
then
we
make
that
cost
more
than
the
money
you
make
from
your
unsolicited
bulk
commercial
communications.
Then
we
may
drive
you
out
of
business
like
that.
That's
been
the
play
from
the
start
here
right
now,
we're
in
the
extra
credit
realm.
Well,
I
guess
ob
is
still
in
the
original
realm
like
connected
identity
and
messaging.
G
That's
the
extra
credit
problem
ob
is
about
like
how
can
we
score
more
wins,
like
you
know,
with
something
that
we
think
will
take
unsophisticated
adversaries,
people
that
just
cannot
launch
that
substitution
attack
off
the
table
or
make
it
more
expensive
for
them
to
do
it
right
and,
like
I
mean
that's,
been
my
pitch
on
this
from
the
start,
is
that
you
know
something
like
ob
it
ain't
perfect.
The
substitution
attack
is
an
issue
but
like
what
you
actually
have
to
do
to
like
win
those
races.
G
What
you
have
to
know
to
win
those
races
and
the
degree
of
exposure
you
create
for
yourself
as
an
actor
in
you
know
the
deployment
by
trying
to
win
that
race.
Those
are
not
risks
that
the
kind
of
people
doing
bulk,
unsolicited
commercial
communications
are
willing
to
take
and
at
their
expense
of
risks
and
like
so
for
me,
this
is
just
this
is
all
gravy
right?
This
just
you
know,
takes
deficiencies
as
you
point
out
or
endemic
to
sip.
G
G
G
B
One
comment
I'll
make
there
is
I
I
was
joking
earlier
about
not
having
read
the
draft,
but
it
hasn't
been
out
there
very
long.
So
I'm
sure
I'm
not
the
only
one
that
hasn't
so
before
we
say
it's
ready
for
working
group
last
call
we
might
might
give
people
a
chance
to
read
it.
Yeah
yeah,
probably
for
most
of
today's
drafts.
So
but
that's
as
much
the
chairs
as
anyone
else.
G
G
Next
slide:
okay,
so
for
those
of
you
that
have
forgotten
about
this
one,
this
is
looking
at
trying
to
leverage
all
the
great
credential
infrastructure
and
smarts
that
we
have
generated
through
stir,
to
apply
to
messaging
specifically
to
messaging
where
telephone
numbers
are
used
as
identifiers
for
right
now
we
are
kind
of
keeping
the
scope
to
that.
Although
pretty
artificially
to
be
honest-
and
yes,
we
all
know
message
span
is
a
problem.
I
understand
from
the
chat
that
ben
you
got
some
mms
spam
while
we're
in
session,
which
is
which
is
awesome.
G
I
get
a
ton
these
days.
I
think
I
get
more
text
spam
than
I
get
call
spam
at
this
point,
which
was
not
true
when
I
started
working
on
this
stuff.
Well,
I
started
working
this
stuff
a
long
time
ago,
but
it
was
not
true
even
like
five
years
ago,
and
you
know,
the
basic
premise
here
is
look
if
somebody
needs
to
provide
a
system
that
is
going
to
securely
attest
that
the
sender
of
a
message
has
the
following
telephone
number
like
they
should
be
using
store
credentials
to
do
that.
G
G
There
are
two
paths
identified
in
the
document:
there's
really
an
sdp
negotiated
path
which
looks
like
rcs
would
be
most
familiar
in
the
messaging
space
around.
This
could
be
applicable
to
rcs,
but
basically
anything
that's
negotiating
a
session
with
an
invite.
We
should
just
get
it
for
free
right.
It
should
just
like
work
with
start
for
the
most
part
or,
if
it
didn't,
we
did
something
phenomenally
wrong
with
what
we
did
with
star
in
the
first
place.
G
The
second
path
is,
of
course,
the
use
of
individual
messages
like
for
the
message
method.
I
don't
believe
brian
rosen
is
with
us
today.
We
still
don't
see
him
in
the
log,
but
he's
been
a
big
advocate
for
this
for
emergency
services
in
particular.
Apparently
they
really
need
this
for
some
of
these
applications,
and
he
more
or
less
persuaded
me
that
we
should
try
to
specify
this
here.
G
We've
been
looking
at
it,
as
of
maybe
one
or
two
revs
ago,
at
the
mime
level,
really
avoiding
worrying
about
creating
specific
profiles
for
specific
mime
types.
Now,
as
ben
pointed
out
in
the
list
and
I'll
talk
about
the
next
slide,
of
course,
signing
entire
mind
bodies
has
its
own
legacy
of
issues
that
those
of
us
familiar
with
have
long
combated
in
s
mime
and
elsewhere.
G
You
know,
I
I
think.
Basically,
though
this
can
stand
as
an
initial,
you
know
proposed
model
for
how
we're
going
to
approach
this
with
a
couple
of
caveats
that
I
added
in
so
next
slide.
G
So
what
is
actually
new
here?
I
added
some
text
on
freshness.
This
came
from
ben's
comments
on
the
list.
You
know
ben
rightfully
pointed
out
that
stir
passport
expiry
timers,
as
we
recommend
from
82
24
onwards.
You
know
at
around
60
seconds
at
the
most
probably
are
not
adequate
for
a
lot
of
these
store
and
forward
sorts
of
potential
messaging
delivery,
ecosystems
that
exist
out
there.
G
If
I
just
got
off
a
plane-
and
you
know
this
message
has
been
waiting
for
me
for
the
last
six
hours
and
suddenly
I
turn
my
phone
on
like
what
happens,
then
you
know,
I
think
what
the
text
I
added
effectively
says
is:
look,
you
know,
passports
have
time,
stamps
and
message
systems
can
like
peg.
You
know
your
message
to
the
time
that
it
was
sent
and
like
there
isn't.
G
I
don't
think,
there's
like
a
replay
attack
or
something
like
that
or
even
much
opportunity
for
confusion
as
long
as
the
user
has
an
inbox
experience
on
their
device
that
takes
into
account
the
fact
that,
yes,
this
message
was
sent
at
this
particular
time.
There
was
a
you
know,
a
date
header
in
the
sip
message
method
that
carried
it,
and
there
is
an
it
in
the
passport
those
are
correlated,
and
this
should
like
work
theoretically
ben.
Do
you
want
to
comment
on
this?
One.
B
That
is
suggesting
that
this
verification
is
done
as
close
to
the
recipient
as
possible,
because
another
potential
approach
to
this
would
say
you
know
your
message
store
verifies
when
things
come
in
and
that
way
you
don't
have
this
delay,
but
then
you
have
added
a
you
know,
additional
step
and
a
lack
of
end-to-endness,
which
is
not
ideal.
If
you
do
it
that
way,
then
the
other
kind
of
related
comment,
I
was
going
to
say
it's
not
necessarily
just
a
six
hour
because
you
were
on
a
plane.
B
You
know
if
you
go
look
at
your
any
messaging
app.
You
can
see
messages
from
years
ago,
message
histories
and
such-
and
I
don't
know
if
we
want
to
say
anything
about
that,
but
it
kind
of
seems
to
me
that
there's
a
difference
between
you
haven't
seen
the
message
yet
and
you
want
to
see
it
verified
versus
I'm
going
to
look
at
my
message
history
next
year
and
see
a
still
see
the
verification.
B
And
again
I
don't
know
if
there's
anything,
we
need
to
say
about
that.
I
don't
know
if
these
applications
are
gonna
wanna
keep
a
passport
store,
so
they
can
go
back
and
look
at
them
versus
just
mark
everything.
That's
verified
in
your
storage,
but
a
place
that
might
make
a
difference
is
when
you
have
multiple
devices
and
things
using
the
same
history,
storage.
G
I
mean,
I
think,
there's
even
some
text
in
the
draft
that
basically
says
if
your
inbox
experience
does
not
support
this,
like
you
need
to
treat
expiry
timers
much
more
seriously
like,
but
your
your
other
point
about
you
know.
Do
we
want
this
to
be
like
a
forensic
non-repudiation
tool
is
an
interesting
one.
Obviously,
my
philosophy
on
this
from
the
start
has
been
all
these
messages
passport
should
go.
You
know
to
end
devices
as
much
as
possible.
That
is
the
best
security
story
all
around
for
everything
that
we're
trying
to
achieve
on
this.
G
But
you
know
we
live
in
a
world
where
things
are
just
much
more
mediated,
and
it
probably
is
worth
documenting
that
that
specific
case
that
you
were
discussing
where
it
really
is,
like
some
kind
of
you-
know,
inbox
service
that
is
going
to
consume
these
passports
and
that
is
responsible
for
rendering
what
the
user's
inbox
experience
looks
like.
So
the
user
will
not
have
that
forensic
capability
themselves
right
like
potentially,
though,
a
service
could
log
what
the
passwords
were
that
were
associated
with
these
messages.
G
G
You
know
explanatory
material
about
all
this
that
fleshes
that
out
a
bit
more,
it
would
be
helpful.
Probably
what
we
can't
do
is
offer
much
you
you
got
to
do
it
this
way
around.
Any
of
that.
B
I
No,
no,
it
was
just
a
comment
on
the
the
backlog
like
when
you
look
at
your
texts
that
have
been
received
in
the
past.
I
think,
if
you
front
end
it
and
hit
that
verified
it,
the
services
should
be
able
to
just
drop
off
everything
else
and
just
state.
This
is
verified
in
the
past.
I
don't
I
don't.
I
can't
imagine
you
would
need
a
backlog
of.
G
I
Yeah
I
mean
I
and
that
and
that's
my
point
is
that
that
both
both
sides
generally
keep
their
own
version
of
the
text
backlog.
So
I
was
trying
to
figure
out
how,
because
they
you
know,
once
you
receive
it's
no
longer
linked,
you
know
it
you've.
G
The
point
here
is
that
the
message
and
the
passport
they
coexisted
in
the
end
user's
inbox
right
because
the
passport
has
this
hash
over
the
message
content.
It
is
actually
non-repudiable
proof
that
the
message
content
existed
at
that
time
and
said
what
it
did,
and
so,
if
you
had
it,
you
would
be
able
to
tell
your
friend
I
gave
you
said
you
got
the
500
bucks
where's
my
baseball
card.
G
I
Right,
yeah
yeah-
that
was
my
other
thought,
is
that
you
know
I.
How
often
is
it
send
receive
and
their
store
send
as
opposed
to
end
in
system.
You
know
the
system
that's
closest,
having
stored
and
then
displayed
like
you
know
when
you're
getting
off
a
plane
yeah,
I
don't
know:
okay,
no
worries
yeah.
I.
D
Was
going
to
say,
I
think
we
need
both.
I
I
think,
on
the
store
and
forward
I
mean,
I
think,
all
messaging
protocols
end
up
being
store
and
forward
right
or
well,
I
shouldn't
say
all,
but
all
the
mainstream
ones
at
least,
and
we
have
the
complication
that
you
know
with
msrp
it's
session
based
with
message.
It's
message
base
with
rtt,
it's
actually
character
based,
but
ultimately
there
has
to
be
some
story
forward
mechanism.
D
I
think
you
know
there
could
be
some
mix
of
verification
at
the
store
and
forward.
You
know,
but
I
think,
a
bigger
topic
also,
which
I
think
we're
touching
on,
but
is
probably
relevant
not
only
to
messaging
but
voices
more.
The
operational
aspect
of
like
how
are
people
keeping
passports
and
certificates
in
cdrs
and
that's
something
we've
been
there's
been
sort
of
some
background
conversations.
I
think,
but
we
really
don't
have
a
formal
recommendation,
whether
it's
itf
or
other
forums
for
those
things.
D
But
I
do
think
those
are
important
for
multiple
reasons,
including
forensic
non-repudiation
or
or
other
things
like
that.
But
that's
a
bigger
comment
than
you
know
this
draft
but
relevant
to
it
as
well.
So
I
I
think
we
should
take
both
of
those
things
into
consideration.
G
It
would
be
interesting
actually
to
look
separately
at
what
we
think
the
forensic
obligation
is
that
people
take
on
as
as
vs,
especially
there
could
be
a
best
practice
or
something
in
that
we
could
look
at
yeah.
H
I
was
just
going
to
say
the
I
mean
the
only
comment
so
like
in
your
example.
The
baseball
card-
I
you
know
shaken
passports-
may
not
be
that
useful
for
that
right.
That
means
that
that
number
sent
it
to
you,
but
not
that
person
it's
almost
like
if
you're,
if
you're
using
this
for
for
non-repudiation
you
you
want
this,
you
know
what.
If
what?
If
you
know
you
have
a
phone
number
and
you
send
a
message
and
then
the
number
gets
assigned
to
somebody
else.
H
You
you,
I
think
you
without
some
distinction
of
like
you
know,
this
number
has
changed.
It's
not
the
same
person.
I
don't
know
how
useful
it
is
to
the
end
user.
I
don't
know
that
they
care.
I
got
a
text
message
from
this
number.
I
think
they
care.
I
got
a
text
message
from
this
person.
If
you're
talking
non-repudiation.
G
G
E
G
But
you
know
the
you
know,
I
I
do
think
the
way
that
inboxes
are
organized.
You
know.
If
it
really
push
came
to
shove
and
you
needed
to
go
to
court
to
someone
right.
I
think
their
service
provider
saying
that
their
number
at
the
time
claimed
they
got
the
500
bucks
as
something
you
know.
Your
lawyer
would
be
very
interested
in
seeing
so
I
don't
think
I
I
think
it's
still
useful,
but
so
I
think
we
have
ben
then
chris.
B
I
was
just
going
to
mention
that
connects
kind
of
to
a
previous
discussion.
We've
had
about
messaging
from
things
that
don't
look
like
phone
numbers
from
from
the
the
from
better.
I
think
that's
still
currently
out
of
scope
because
we're
stirring
we
do
phone
numbers,
but
it's
something
to
think
about.
In
the
long
run.
G
Yeah,
it's
certainly
not
in
a
scope
of
8224
right
like
it's
just
issue
26
and
all
the
things
derived
from
it.
I
I
think
what
we
want
to
avoid
is
conflating
this
discussion
with
a
much
broader
discussion
about
whatsapp
and
well.
Maybe
whatsapp
is
a
bad
example,
but
any
over
the
top
messaging.
That
is,
you
know
that
does
not
rely
on
telephone
numbers.
I
guess
whatsapp's
a
bad
example
of
that,
but
chris.
D
Quick
note
on
non-repudiation,
I
think
we've
sort
of
had
that
philosophical
discussion.
You
know
if
I
have
a
phone
if
I
have
a
desk
phone
sitting
and
somebody
else
comes
and
picks
it
up
and
makes
a
illegal
call
on
it.
D
G
G
I
was
thinking
that
as
well
in
that
forensics
case.
You
know
if
somebody
wants
to
try
to
deny
well
look.
My
number
changed
like
if
I've
got
like
100
text
messages
for
me
this
month.
You
know,
I
think
your
argument
gets
a
little
bit
weaker.
If
you
want
to
try
to
say
you
know,
oh
my
god
like
that.
Wasn't
me.
G
Okay,
anyway,
we
we've
talked
about
expiry
thresholds
enough
for
for
one
session,
so
I
did
also
add
a
little
bit
of
tech
span
based
on
your
comment
about
cpm
metadata
that
basically
just
points
to
your
rc
rfc
8946,
and
to
what
you
say
in
that
about
the
potential
modifications
to
cpa
metadata,
as
calls
are
in
transit
and
did
a
little
bit
more
general
word
smithing,
yes,
ben
super
metadata.
B
E
G
Exactly
all
right
so
next
slide,
I
think
we're
done.
G
So
I
did
chat
a
bit
with
richard
barnes
about
mls
and
what
the
potential
mls
interaction
with
this
would
look
like
and
after
we
went
round
and
round
and
round
in
this,
I
think
the
conclusion
we
came
to
is
actually
we
need
to
find
what
mls
means
for
like
sep
and
once
we
did
that
we
could
figure
out
like
how
to
sign
it
for
stir.
G
We
think
that
would
probably
need
its
own
working
group.
That
might
be
a
working
group
worth
doing
actually
for
a
number
of
reasons.
But
like
my
pitches
here,
let's
not
wait
for
that
ben.
B
D
Yes,
well
for
practical
purposes,
I
think
you
know
the
state
of
group
messaging
for
mms
is
pretty
messy.
Maybe
rcs
has
some
better
things
there.
I
don't.
I
don't
know,
I'm
not
as
intimately
familiar
with
that,
but
I
think
if
you
want
to
have
trust
across
groups,
I
think
we
do
need
to
consider
something
new.
So
I
think
that
this
is
the
right
stance.
D
G
G
Like
I,
I
don't
think
we
want
to
say
a
lot
more.
I
think
we
want
to
get
this
out
into
the
marketplace
and
you
know
be
able
to
tell
people
no.
There
is
a
story
for
doing
messaging
with
stir,
and
this
is
the
story
and
see
if
anybody
bites.
G
B
I
have
read
this
one
and
I
think
this
is
probably
pretty
close,
pretty
close
to
ready
to
working
group.
Last
call
we've
been
through
several
versions
and
you've
incorporated
comments,
and
I
think
the
last
round
mine
were
the
only
comments.
G
G
Yeah,
I
was
going
to
say
that
your
only
other
comment
was
about
the
ob
stuff,
but
I
thought
the
the
existing
text
around
ob
like
was
okay
and
like
that,
didn't
require
any
specific
correction.
So
if
there's
anything
more
narrow
with
that
text
that
you
want
to
add,
because
I
I
don't
think
we
want
to
be
real
prescriptive
about
it,
but
like
if
there's
something
specific
that
you
want
to
like
wordsmith
about
that
just
so
you
know
what
it
is.
B
G
A
B
I
was
going
to
make
a
quick
call
back
to
the
previous
comment
about
mls.
There
was
something
in
dispatch
on
on
applying
mls,
so
anyone
who's
interested
go
back
and
look
at
that.
I
don't
remember
the
details.
G
G
Okay,
there
are
some
documents
believe
it
or
not
that
have
existed
for
a
very
long
time.
Next
slide
that
I'm
going
to
talk
about
today,.
G
So
you
know
this:
this
presentation
is
a
bit
of
a
rerun
from
itf
98.
I
think
the
last
revision
to
the
ocsp
draft
was
in
2017
and
that
just
not
to
terrify
any
of
you.
That
was
five
years
ago
now,
and
this
was
really
based
on.
As
russ
pointed
out
going
back
into
the
the
archaeological
record.
You
know
we
had
some
text
about
ocsp
originally
in
rfc826,
and
we
split
it
out
into
a
separate
draft
because
we
felt
like
this
could
be
work.
G
If
we
felt
like
doing
later,
we
could
figure
out
why
we
wanted
to
do
it
and
do
it
then-
and
I
guess
what
I'm
here
to
suggest
today
is
there
may
be
a
reason
to
actually
do
this
now,
and
you
know
I
revive
both
this
and
my
old
short-lived
search
draft
for
a
very
specific
reason
that
has
to
do
with
using
tnoff
lists
with
telephone
numbers
in
them
and
not
service
provider
codes.
Obviously,
the
majority
of
deployment,
thus
far
firster
shaken,
has
been
focused
on
spcs.
G
The
issue
is,
with
the
advent
of
certificate
delegation.
People
are
seriously
starting
to
look
at
the
question
of
okay.
How
do
you
issue
a
certificate
with
the
t
analysis,
full
of
telephone
numbers?
And
you
know
our
traditional
party
line
for
this-
has
been
and
was
even
in
82
26,
that
complex
certificates
with
telephone
numbers
probably
want
to
have
those
telephone
numbers
included
by
reference
rather
than
by
value?
What
do
I
mean
by
that?
Instead
of
having
this
big
oid
tnoth
list?
G
That
lists
like
every
single
telephone
number
that
say
an
enterprise
is
responsible
for
even
broken
up
into
ranges.
It
could
still
be
quite
complex
and
dynamic.
You
know
dynamic
to
the
point
where
you
have
to
reissue
the
cert
like
every
two
hours.
If
things
about
the
number
inventory
change
and
those
thresholds
which
is
just
a
hassle
for
everyone-
and
this
is
worth
doing-
we
defined
in
8226
a
way
to
use
the
authority
information
access
to
include
a
uri
in
the
certificate
that
points
to
where
that
tn
authorist
lives
somewhere
on
the
web.
G
G
G
You
do
not
have
your
hand
up
now:
okay,
rather
than
having
people
download
the
entire
tnoth
list,
as
relying
parties
like
whenever
they
need
to
rely
on
their
certificate
effectively,
they
need
to
look
at
the
freshest
available
copy
of
it.
Why
don't
we
define
an
ocsp
extension
that
effectively
just
means
you
know.
G
G
And
you
know
when
we-
I
guess
I'll,
one
more
bit
of
history
about
this
just
by
explanation,
when
we
you
know
when
we
started
looking
at
ocsp
and
certificate
freshness,
we
really
were
thinking.
You
know
how
to
do
this
broadly,
an
environment
like
star
shaken:
should
there
be
crls,
or
should
there
be
ocsp
or
should
be
using
like
scbp
or
whatever,
and
it
was
kind
of
like
a
beauty
contest
between
these
options?
G
That
certainly,
is
not
what
we're
talking
about
now,
we're
not
talking
about
changing
anything
about
the
way
that
people
use
crls
for
the
vast
majority
of
the
spc
certificates
that
are
out
there.
This
is
all
about.
Should
we
have
an
ocsp
option
specific
to
the
by
reference
case
and
thus
more
or
less
specific,
to
certificate
delegation
wherein,
as
they
say,
an
ad
as
an
sca,
any
certificate
authority?
That
is,
you
know,
delegating
certificates
down
to
enterprises
or
whatever
would
run
an
ocsp
interface?
G
That
people
could
query
to
ask.
The
simple
question:
is
the
calling
party
number
of
the
passport
I
got
in
the
scope
of
the
certificate
that
signed
it
right
now
now
there
are
two
ways
to
skin
this
cat,
at
least
there's,
probably,
unfortunately
like
17.
There
are
two
that
are
in
drafts
at
the
moment.
One
is
what
I
just
described
doing
this
with
ocsp.
G
The
other
is
to
use
short-lived
certs,
in
other
words,
to
basically
generate
a
certificate,
possibly
on
a
per
tn
basis,
maybe
for
a
range,
maybe
for
individual
tns.
That
is
going
to
expire
very
rapidly,
that
like
enterprises
can
use
acme
or
some
of
their
dynamic
protocol
to
be
able
to
ingest
these
search
and
then
use
them
to
sign
calls
so
that
again
it's
it's
unambiguous
to
relying
parties.
G
Whether
or
not
the
telephone
number
that
you
know
it
appears
in
the
calling
party
number
is
within
the
scope
of
authority
of
the
cert
or
not
do
people
understand
the
problem.
Am
I
explaining
this
well
enough?
Do
people
get
kind
of
why
I'm
now
focused
on
this,
because
really,
as
we're
kicking
the
tires
on
certificate
delegation
and
doing
tnothless,
potentially
by
raph,
these
kinds
of
questions
come
up?
Pretty
quick
like
how
do
you
actually
practically
do
this?
If
you
have
a
large
and
complex
tnop
list,.
G
The
the
things
people
think
are
wrong
with
buy
reference
or
twofold
one.
The
the
thing
you're
downloading
could
be
big,
could
be
really
big
and
that
you
need
to
download
it
basically
every
time
you're
going
to
rely
on
the
cert
every
time
I
call
basically,
you
know
with
an
x5
view
of
that.
Cert
is
in
front
of
your
bs
two,
and
this
is
maybe
the
more
sensitive
one.
G
Some
people
seem
cagey
about
dispersing
lists
of
every
number
that
they
own
through
an
interface
like
this.
Remember
like
your
search.
Gonna
live
out
in
nest,
icr,
where,
like
anybody
can
grab
it,
and
then
anybody
can
look
at
the
aia
and
look
at
that
url
and
like
download
your
entire
tnop
list,
like
I
gather
some
people
are
kg
about
the
idea
that
they're,
just
gonna
reveal
like
what
their
entire
telephone
number
inventory
is.
F
Yeah,
so
I
guess
the
reason
that
the
the
like,
I
can't
really
comment
on
the
kg
about
what
tns
you
own,
but
the
the
the
fact
that
they're
big,
I
kind
of
see
as
a
good
thing,
because
in
general
from
like,
when
we've
deployed
this,
we
just
don't
have
time
to
make
any
requests
out
to
the
internet.
We
can't
even
usually
download
the
certificate
in
the
time
span
that
we're
meant
to
like
be
able
to
verify
these
passports.
F
G
And
you
know,
and
when
we
get
into
this
ocsp,
has
this
thing
called
stapling
we're
going
to
talk
about
that
in
a
minute.
So
there
are
corners,
you
cut
if
you
actually
are
going
to
go
down
the
oc,
ocsb
path
that
we'll
get
into
that
can
mitigate
some
of
that.
But
did
I
who,
who
was
first
russell
alec?
I
I
don't
remember.
A
I
think
it
was
me
so
in
a
shaken
environment
you
could
have
a
certificate
that
only
has
an
spc,
and
so
is
the
question
being
asked.
Has
the
tn
moved
out
from
under
this
spc
to
somewhere
else,
or
are
you
asking
something
else?
I
guess
I'm
trying
to
ask
the
bigger
picture.
G
Yeah,
so
we're
we're
talking
about
certificates
that
were
delegated
down
from
in
intermediates
or
held
by
one
of
those
shaken
providers
effectively
right.
Let's
just
assume
we're
talking
about
north
america
exclusively,
which
we're
not
but
it'll,
be
happier.
If
we,
you
know
easier,
if
we
do
it
that
way.
For
now,
just
assume
a
shaken
provider
with
an
spc
has
has
an
intermediate
cert
right
and
has
an
sca
and
they're
issuing
delegates
or
certs
down
to
an
enterprise.
G
Now,
as
you
may
know
like,
potentially,
there
could
be
like
multiple
donors
of,
like
you
know,
svcs
that
are
donating
different
numbers
to
the
blocks
of
that,
like
individual
enterprises,
cert
we'll
close
over
that
for
the
moon
as
well.
Let's
assume
that,
like
you
know,
the
enterprise
wants
to
have
the
number
ranges
for
which
it
is
responsible
to
what
is
expressed
by
its
delegate,
sir
we're
talking
about
using
ocsp
exclusively
for
the
validation
of
those
delegate.
Certs.
A
And
just
a
time
warning
we're
down
to
nine
minutes.
H
So
I
guess
yes,
I
think
you
mean
you
kind
of
said
this
to
jack's
comment,
but
I
I
think
the
big
one
of
the
big
problems
with
by
reference
is
yeah.
What's
the
expiration,
I
mean
you
you're
you're,
cashing
it
and
then
how
long
do
you
cash
it
for,
and
that
can
be
a
problem.
I
think
one
thing
just
a
comment
I
mean,
I
think
the
ocsp
use
case.
H
I
think
that's
useful
outside
of
just
tn
by
reference,
just
whether
it's
team,
by
reference
by
value
either
way,
I
mean
the
and
the
reason,
the
only
reason
I
say
that
is
ocsp
statewide.
I
think
if
we
I
think
require
personally,
I
think
we
should
require
ocsp
statement,
there's
no
csp
without
ocsp
stapling
in
this
environment
and
maybe
a
a
header
in
the
passport
that
has
your
staple.
I
mean
that
that
alleviates
that
round
trip
and
when
you.
F
H
When
we're
talking
the
the
delegate
model,
at
least
what
what's
been
done
in
the
ietf,
you
can
put
a
crl
and
the
terminating
provider
doesn't
know
it
until
they
go
to
get
it
until
they
get
the
passport.
So
you've
now
forced
them
to
do
two
round
trips
versus
the
current
model,
which
is
one
round
trip
and
they're
sequential
round
trips,
because
you
don't
know
the
url
until
you
go,
get
the
certificate
to
do
this.
H
G
Yeah,
I
mean,
I
think,
a
lot
of
this
comes
down
I'll,
like
just
to
anticipate
my
own
argument
here
too.
Where
do
you?
Where
do
we
fall
between
ocsp,
stapling
and
short-lived
or
like
really,
what
is
the
practical
difference
between
them
like
and
that
that's
where
this
gets?
I
think
pretty
interesting,
because
one
one
thing
we
don't
have
is
a
way
to
convey
ocsp
stapling
now
and
I'm
not
sure
if
it
would
actually
be
in
the
passport.
I
think
we
probably
need
to
be
in
a
sip
header,
but
why
don't
we
fast
forward
two
slides.
G
Okay
yeah,
so
I
mean
we
should
recommend
stapling,
but
I
think
we
would.
We
would
need
to
recommend
where,
in
the
request
where
you
want
that
staple
to
live,
and
like
you
know
when
we,
you
know
part
of
the
the
thing
I'm
trying
to
pose
here
and
I'm
struggling
to
figure
out
how
to
do
this
in
less
than
seven
minutes.
I
guess
what
I'm
trying
to
up
level
to
here
is,
I
think,
especially
because
of
the
use
case
of
biref.
G
There
are
now
people
asking
questions
that
are
only
going
to
have
answers
in
this
solution:
space
right,
something
like
ocsp
with
stapling
or
short-lived
certs,
and
you
know
my
my
pitch
here.
Basically
is
we
need
to
work
on
one
or
both
of
these
to
satisfy
what
I
see
as
an
emerging
request
from
the
market
that
we
anticipated
a
long
time
ago
like
it's,
not
that
we
didn't
know
this
was
coming
down
the
pike,
it's
just.
G
It
hasn't
been
urgent
until
suddenly,
like
tm
by
ref,
because
of
delegation
is
becoming
a
thing
and
it
may
have
applicability
beyond
it.
But
that
is
from
what
I
see
the
motivating
use
case
to
like
really
return
to
this,
and
we're
not
going
to
solve
in
this
call
like
whether
stapling
or
short
lived
is
like
a
better
approach
to
this.
When
we
go
next
slide.
G
Like
a
half
hour
presentation,
just
in
fact,
keep
going
still.
Obviously
the
pitch
for
short
lived
is
that
you
use
acme
and
especially
like
acme
star,
and
things
like
that.
Now,
if
acme
had
more
practical
deployment
as
a
protocol,
people
are
using
to
acquire
certificates
for
stir
shaken.
I
would
feel
more
optimistic
about
that.
G
The
fact
that
you
know
people
are
using
tokens
30
tokens
right
really
in
the
absence
of
all
of
the
protocol
machinery
of
acme,
for
the
most
part,
does
not
make
me
as
optimistic
for
this,
as
I
was
five
years
ago
that
this
was
like
a
practical
path,
but
I
think
it
doesn't
change
the
fact
because,
especially
I'm
not
sure,
acme
is
going
to
be
used
much
anyway
between
sca's
and
enterprises.
G
F
G
Where
we're
gonna
get
to
so
like
my
pitch,
is:
let's
explore
both
of
these
a
bit?
You
know
we
could
probably
have
a
whole
interim,
or
at
least
just
an
informal
call
with
the
chickens
here
who
care
right
like
to
figure
out
like
how
much
we
think
needs
to
be
fleshed
out
of
one
or
both
of
these.
I
don't
think,
there's
much
harm
in
kicking
the
tires
on
both
and
kind
of
figuring
out
what
the
path
is.
G
I've
also
heard
you
know
some
people
pitching
clujas
right
that
are
gonna,
try
to
accomplish
some
of
this
with
like
http
semantics
and
x5u,
and
things
like
that,
like
there's
a
there's,
a
bunch
of
different
ways
to
potentially
skin
this,
I
think
we
need
what
we
may
ultimately
need
actually
is
like
a
requirements
phase
of
this
that
you
know
we're
then
going
to
be
able
to
compare
these
solutions
to
it
could
be
as
well.
You
know,
and
certainly
cognizant
short-lived
certs
can
co-exist
with.
G
You
know
any
approach
that
we
choose
here
for
this
right
and
like
it's
certainly
not
going
to
be
very
intrusive
to
the
overall
operations
of
stir
shaken
to
do
it,
except
for
upfront
costs
you're
paying
not
at
call
setup
time
in
order
to
like
you
know,
get
live
fresh
short-lived
certs,
so
I
mean
it
may
not
be
that
you
know
we
even
need
to
resolve
a
beauty
contest,
but
I
think
we
need
to
look
at
this
because
the
need
for
it
is
real,
and
you
know
this
is
just
a
a
chicken
that
has
come
home
to
roost
in
terms
of
something
that
we
we
gotta.
G
D
I
just
put
a
note
in
the
chat,
but
I'm
I'm
supportive
of
looking
at
both
and
potentially
utilizing
both.
H
G
G
All
right:
well,
let's
find
some
time
when
we
can
like
get
together
and
like
talk
through
what
we
think
the
essential
features
are
what
the
mature
version
of
these
looks
like
because,
again
most
of
the
stuff,
that's
in
this
draft.
I
kicked
it
a
bit
to
explain
the
bireff
problem,
in
particular
on
both
the
drafts,
but,
like
a
lot
of
this
taxes,
you
know
got
whiskers
on
and
it
sold.
G
With
that,
I
suggest
that
we
declare
victory
for
today.
My
voice
is
getting
worse
here.
A
Okay,
so
clearly
more
discussion
is
needed
on
these
topics.
Hopefully
we'll
see
some
of
that
on
the
mail
list.
The
the
two
drafts
are
already
out
there.
So
take
a
look
see
what
john's
thinking
about
any
last
moments.
We
have
about
a
minute
left.
A
Okay,
so
expect
to
see
one
working
group
last
call
for
messaging
produce
in
the
next
couple
days
and
then,
when
the
versions
get
posted
for
identity,
header
errors
and
service
provider
oob
after
the
next
version
of
each
of
those
appears
we'll
do
a
working
group
last
call
for
those.