►
From YouTube: IETF114 STIR 20220726 1900
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
D
B
E
Okay,
welcome
to
stir
at
ietf
114
next
slide,
please.
This
is
the
note
well
by
this
point.
You
probably
have
already
read
it,
but
please
make
sure
you
follow
it
if
you're
going
to
contribute.
The
next
slide
just
remind
everybody
about
respectful
engagement.
Here,
please
make
sure
you
follow
the
ietf
code
of
conduct
next
slide.
E
C
E
A
second
slide:
oh,
that's
a
status
light;
yes,
they're
right!
Sorry,
this
is
just
to
say
the
documents
that
had
reached
some
milestone
and
remind
people
that
error
handling
closes
today.
In
terms
of
its
last
call,
I
had
not
seen
any
comments
on
the
list
this
week,
but
we
were
hoping
to
deal
with
any
comments
that
came
out
during
the
session
today
that
there
were,
and
on
the
last
one,
the
the
oob
document
we
had
said
when
the
next
one's
updated.
E
F
G
F
Do
appreciate
all
the
editorial
cleanup
that
happened,
especially
in
the
abstract
and
intro
there's
it's
been.
The
document's
been
obviously
changing
for
a
while.
Now
and
mostly
there
were
changes
to
bring
things
up
to
date
with
some
of
the
changes,
and
I
added
some
examples
and
some
other
things
like
that
there
was
one
normative
language
change.
That
was
actually,
I
think,
ben's
comment.
I
changed
a
must
to
a
should
in
the
security
considerations
section,
and
I
have
the
exact
quote
down
there
ben
you
have
a
comment.
B
E
B
F
F
C
F
C
Outside
of
shaken
like
contexts-
and
so
I
don't
think
an
itf
specification
should
you
know,
stipulate
anything
too
strongly
there.
I
agree.
The
wording
here
is
kind
of
tortuous
right.
It's
got
the
varsity
passport.
Lowercase
must
follow
some
form
of
vetting
in
which
and
then
should
follow,
and
it's
like
a
policy
of
an
ecosystem.
C
C
B
D
D
G
C
G
H
B
H
E
I
C
What
this
draft
basically
is
suggesting
is
that
the
systems
we
built
for
stir,
especially
the
certification
systems
that
are
now
widely
deployed
and
are
being
more
worldly,
widely
deployed
worldwide,
you
know,
probably,
could
be
repurposed
to
handle
text
and
multimedia
messaging
instead
of
just
setting
up
telephone
calls
and,
of
course,
the
systems
we
have
set
up
for
this
in
certification
are
limited
to
telephone
numbers.
So
we're
not
talking
about
you,
know
messaging.
That
has.
C
Telephone
numbers
and
there's
a
ton
of
that-
and
it's
super
interesting
messaging,
but
for
the
moment
the
restriction
of
the
scope
of
this
draft
is
to
that.
I
will
remind
people,
however,
that
is
not
a
restriction
inherent
to
passports
or
to
their
transmission,
in
stir
just
to
the
certification
systems.
We
have
specified
here
in
the
itf
so
far.
Why
are
we
doing
this?
Well,
you
know,
robocalling
is
like
super
annoying,
but
message
bam
is
becoming
a
problem.
C
That's
equally
annoying
in
a
lot
of
places,
and
so
you
know
you
can
kind
of
you
have
some
different
tools
you
can
bring
to
bear
on
trying
to
prevent
spam
and
messaging,
but
especially
as
encrypted
messaging
rises.
These
kind
of
bayesian
tools
we
use
for
email
analysis
to
figure
out
is
this
about
some
sort
of
pharmaceutical
that
perhaps
is
being
widely
advertised
or
something
like
that.
Can't
really
do
that
for
encrypted
messaging.
So
we
think
this
could
help
next
slide.
C
C
C
I
don't
think
there's
like
a
ton
more
to
talk
about
about
this.
You
know,
there's
a
couple
of
topics
that
I
think
we
can
go
through
that
maybe
are
still
open
issues.
We
were
just
talking
about
on
the
list.
One,
for
example,
would
be
allowing
the
message
I
parameter
in
other
passport
types
than
the
message
passport
type.
What
is
message
I
this
is
basically
like
a
hash.
That's
over
the
content
of
the
message,
in
particular
the
mind
body.
C
C
Could
there
be
other
passports
than
message
in
which
we'd
want
to
include
message
on
following
the
great
tradition
where,
for
example,
we
allow
rcd,
which
is
just
an
element
that
appears
in
the
passport
to
also
appear
like
in
a
shaky
passport?
If
people
want
to
do
that,
are
there
similar
cases
or
it
might
make
sense
to
have
this
like
message-
integrity
parameter
in
some
other
passport
type?
C
And,
like
I
think,
the
opportunity
for
confusion
around
this
is
too
great
and
that,
moreover,
getting
into
this
polymorphism,
as
we
discussed
on
the
list
where,
how
do
you
mix
and
match
between
these
different
passport
types?
This
is
like
all
this
aggravation
and
complexity
and
household.
I
see
there,
so
I'm
not
super
psyched
about
that,
but
I
thought
I'd
give
an
opportunity.
If
anybody
here
would
like
to
talk
about
go
to
bat
for
the
notion,
there
could
be
other
passport
types.
Where
message
I
could
appear
anybody
care.
B
B
Who
wants
to
specify
another
use
for
this,
and
you
know
if
we
say
must
not,
then
any
if,
if
we
come
up
with
another
kind
of
message
passport
in
the
future,
this
is
where
the
polymorphism
came
in
maybe
some
kind
of
combination
of
rcd
with
message
eye,
or
you
know
just
throwing
something
off.
We
have
to
come
back
and
update
this
draft
to
allow
something
else
to
do
it.
C
B
A
A
C
I
am
going
to
I'm
willing
to
entertain
and
contemplate
that
for
a
moment
we
called
the
draft
stir
from
messaging
we're
using
message
pretty
generically.
We
have
a
pretty
generic
definition
of
message.
In
the
sense,
it's
not
limited,
merely
textual
messages,
but
also
incorporates
multimedia
messaging.
I
mean,
I
guess
I
look
at
it
like
you
know.
We
define
two
streams
for
these
things
that
could
effectively
appear
in
the
message.
C
C
C
A
A
Naming
is
one
of
the
three
hard
computer
science
problems
and
I'm
willing
to
leave
it
alone.
I
just
wanted
to
kick
it
around
for
a
minute,
so
you
know
the
the
kind
of
potential
confusion
I
can
see
at
an
implementer's
layer,
especially
if
your
implementers
aren't
native
english
speakers
is.
Is
this
thing
some
sort
of
you
know
integrity
check
over
at
the
datagram
that
the
passport
appears
in
kind
of
thing,
so
you
know,
but
I'm
I'm
perfectly
willing
to
leave
it
alone.
C
C
I
I
kind
of
don't
care
from
a
message
point
of
view,
but
the
I'm
slightly
more
worried
about
the
fact
that
it's
not
like
this
could
end
up
with
some
slightly
odd
side
effects
like
verifiers
that
understand
this
message.
Spec
will
mark
these
as
invalid,
but
those
that
don't
will
treat
it
as
valid,
because
they'll
just
ignore
the
message
I
and
assuming
it's
not
like
a
ppt
like
sorry.
C
Yeah,
I
mean
that's,
that's
why
I
don't
want
to
allow
it
right.
I
said
this
on
the
list,
like
I'm
totally
worried
about
those
side
effects.
I
I
want
this
to
be
scoped
to
message
passports
for
that
reason,
but
I
think
robert
was
like
poking
at
something
else
like
is,
is
message
really
the
best
description
for
this,
or
is
there
a
crisper
thing
that
is
closer
to
capturing
like
what
we
mean.
I
Kind
of
missed
the
point
of
what
I
was
trying
to
say,
which
was
that,
like
you
can't,
if
you
like,
there's
a
question
of
enforcement
on
the
verifier
side
like
a
verifier
that
enforces,
this
will
look
very
different
to
one
that
doesn't,
and
that
might
cause
problems
like,
admittedly,
like
designer
should
have
never
done
this
in
the
first
place.
The
air
should
have
never
done
this,
but
like
from
a
vs.
That's
just
accepting
random
things
from
the
internet,
like
you
kind
of
have
to
worry
about
that.
G
I
If
a
future
or
weird
a
s
creates
a
passport
with
a
message
eye
on
it,
that's
not
a
not
that
that's
not
a
that's
like
ppt,
chicken
or
rcd,
or
whatever
a
verifier
that
does
not
implement
this
bag
will
carry
on
just
fine,
we'll
go
yeah,
everything's,
fine!
There's
this!
There's
this
weird
message:
I,
but
I
don't
understand
it
so
I'm
going
to
ignore
it
and
ppt
rcd
lets
me
do
that
right,
but
a
mirrorfile
that
does
understand
this
will
go
that's
message!
Eye!
C
I
Oh
yeah,
yeah
yeah,
but
like
this
is
the
internet
we're
talking
about
yeah,
the
so
like
yeah,
I'm
not
I'm,
not
convinced.
This
is
definitely
a
problem,
but
it
just
seems
very
strange
to
me
that
verifiers
will
verify
these
passports
correctly
or
incorrectly,
depending
on
whether
or
not
they
implement
this
spec.
C
D
J
J
J
C
Is
this
is
basically
again
it's
a
way
to
prevent
there's
a
particular
confusion
that
is
like
the
inverse
of
what
jack
was
just
discussing
that
I'm
worried
about?
Okay,
which
is
a
case
where
somebody
intends
to
be
saying,
there's
a
message:
I
want
integrity
over,
they
send
it
in
a
non-message
passport
type
and
the
semantics
of
the
fact
that
suppose
we
had
a
message
are
lost.
C
If
the
verification
service
doesn't
recognize
message
eye
at
all,
and
so
a
passport
was
intended
to
be
securing
a
message
could
be
viewed
as
being
valid
for,
like
a
telephone
call
right
and
I'm
concerned
that
there's
like
a
little
bit
of
security
weakness
in
that.
If
we
don't
clamp
this
down
the
language
I
was
discussing
with
jack,
I
mean
it's
a
you
know
it's
a
much
crisper
and
you
know
more
specific
version
of
the
language
it's
in
the
draft
today.
I
think
that
gets
at
what
I'm
trying
to
prevent.
J
C
F
C
The
other
thing
that
really
came
up,
if
there's
nothing
more
than
this-
is
anybody
else
in
queue
on
this.
No
okay,
the
only
other
thing
that
came
up
that
I
thought
was
like
worth
mentioning
from
last
call
is
really
what
we're
opening
the
door
to
without
a
band
for
this
and
just
to
make
sure
you
know
we
all
here,
understand
and
are
comfortable
with
the
notion
that
much
like
with
stir
out
of
band.
You
know
what
we
mean
by
out
of
band
is
non-sip.
C
We
mean
that
you
know
there's
something
like
an
http
service
that,
like
is
carrying
these
passports
and
it's
adjacent
to
the
telephone
call
in
some
fashion.
The
way
it's
stipulated
in
8816
there's
a
call
placement
service.
This
is
a
web
service
due
to
upload
passports
in
which
they
can
be
accessed
by
verification
services.
C
Like
you
know,
this
could
apply
to
basically
any
kind
of
messaging
right
that
you
could
build
a
web
service
to
be
adjacent
to
from
vanilla
sms
to
very
complex.
You
could
do
this
for
like
facebook
messages
right
there.
I
mean
that
would
be
in
scope
of
this.
I
guess
they
don't
use
telephone
numbers
so.
C
So,
like
I
just
want
to
make
sure
people
get
it
that
there's
nobody
who's
present
at
this
meeting.
That
really
feels
like
this
is
too
broad
a
scope
to
allow
what
that
will
be
for
doing
message.
I
think
it's
fine,
I
think
it's
potentially
useful.
I
think
we
get
some
actual
like
leverage
out
of
it.
Ben
thoughts.
B
B
Right
so
it
might
be
worth
having
some
disclaimer
language
saying,
but
someone
else
has
to
go
specify
how
to
do
that
this.
That
problem
is
not
solved
by
this
draft.
It's
merely
hinting
at
a
at
a
solution,
direction
that
someone
might
take,
but
in
general
the
idea
that
we
could
conceivably
use
this
for
messaging
types
that
do
not
have
some
way
to
carry
a
passport
in
band,
I
think
is
like
is
a
road
that
we
should
not
close
yet.
C
Yeah
I
mean
again
pointing
to
8816
it's
not
like
out
of
band
says
you
know,
and
he
puts
any
stipulations
like
that
right
I
mean
it's
very
much
just
like
hey,
whatever
communication
system
is
you're
using,
it
doesn't
happen
to
be
safe.
Like
you
know,
cps
can
help
you
out
with
that,
and
I
think
we're
saying
the
same
thing
here
and
I
I
don't
really
know
that
we
need
any
additional
kind
of
hazard
tape
around
that
to
get
that
across.
D
John
max
I
mean
the
one
concern
I'd
raise.
Is
that
once
you
know
since
you're
doing
a
cryptographic
hash
over
the
message,
you
better
make
sure
that
whatever
you're
doing
is
a
100
percent
unambiguous
way
of
concluding
itself
as
a
mind
body
and
not
you
know
anything
like
you
know,
oh
hey,
we
did
unicode
normalization
or
something
weird
like
that.
So.
D
C
Hope,
it's
not
all
right.
I
just
want
to
make
sure
we
aired
those
two
issues
other
than
that.
I
don't
think
there's
much
by
way
of
open
issues
remaining
here.
I
think
we
got
it
and
I
think
we
should
declare
working
last
call
has
occurred
and
that
we
did
this
and
we
should
ship
it.
Unless
does
anybody
here
think
this
requires
more
before
we
ship
it.
B
C
F
And
I
did
miss
adding
a
request
for
that
parameter
name.
So
I
added
that
as
well
and
then
probably
the
most
substantive
thing
that
I
have
here
is
that
I
made
the
compact
form
the
recommended
form,
given
the
security
issues
that
have
all
been
brought
up,
and
I
think
we
sort
of
discussed
that
at
the
last
meeting-
and
I
think
had
talent
of
agreement
on
that.
I
have
not
removed
support
for
full
form,
but
you
know
have
all
the
caveats
in
the
document
for
potential.
F
A
C
To
say
I
mean
and
correct
me:
this
is
a
good
rubber
question
and
then
question
and
other
sit
mafia
people
here,
there's
no
like
supported
required
whatever,
for
a
reason
is
there
in
any
I
I
went
glanced
back
at
whatever
that
is
33
28
or
wherever
we
specified
reason.
I
didn't
see
anything
like
that.
So.
B
A
Support
signaling
thing
and
had
it
did
come
up
the
last
time
we
were
seriously
punching
through
reason
and
kind
of
remembering
it
coming
in
through
history
info
and
every
time
we've
driven
our
way.
Through
the
conversation
in
the
past,
we've
ended
up
on
that
that
kind
of
implicit
signaling
is
not
helpful
and
that
we
wouldn't
do
it.
F
D
F
H
F
B
E
F
Yes,
thank
you.
Okay
next
comment.
This
is
from
paul
and
I
guess
robert's
probably
the
most
relevant
person
to
talk
about
this.
Whether
or
not
we
should
finish
multiple
reasons,
or
I
think
paul
specifically
was
saying.
Have
it
at
least
get
to
working
group
last
call
before
we
move
on
with
this
going
to
working
group
groups.
Well,.
A
If
it
turns
out
to
not
be
true,
you
know
things
going
to
be
part
waiting
for
it
anyhow,
so
you
know
it
can
always
be
a
yank,
so
I
think
we
should
just
go
ahead
and
let
the
process
move
forward
for
this
draft,
while
the
the
other
one
proceeds
now
I'll
apologize
on
multiple
reasons.
I
missed
brian's
call
for
the
zip
core
working
group:
zero
zero
at
the
beginning
of
june.
I
didn't
see
it
until
I
was
preparing
for
this
minute.
That's
in
now
I'll
have
a
zero
one
in
shortly.
A
H
C
C
F
Yeah,
I
think
the
identified
privacy
issue
was
that
we
included
the
full
passport
that
had
you
know,
you
know
the
call
the
originating
number
and
destination
number
we've
addressed
that
by
recommending
compact
form.
So
I
think
that's
the
only
thing
that
could
potentially
be
an
issue
there,
or
at
least
that's
come
up
as
an
issue.
F
C
Yeah
I
mean
this
john
peterson,
sorry
and
I'm
not
using
the
q
thing
at
all.
I
should
be
better
yeah,
I
mean
the
the
constraint
that's
in
rfc
224,
really
we
intended
that
cause
codes.
Sip
cause
codes
sent
in
backwards
direction,
hopefully
indicate
repairable
conditions
right.
It's
giving
you
information,
you
could
use
to
reoriginate
this
request
and
this
time
use
a
trust.
Anchor
that's
supported
by
the
other
side
or
you
know,
fix
whatever
your
syntactical
problem
is
or
something
like
that.
I
mean
prima
facie.
C
I
I
guess
I
viewed
it
like
you
would
do
it
onesie
twozy,
but
you
know
so
I
mean
I
mean
I
would
be
fine,
because
this
is
the
decision
we
made
in
824
was
effectively.
You
know,
you're
gonna
have
a
single
expression
of
something
that's
wrong.
That
needs
to
be
fixed
that
you're
sending
back.
That's
a
reason
for
rejecting
it.
It's
also
important
to
note
there
can
be
like
cascading
conditions
like
okay.
This
is
what
I
thought
was
wrong,
and
so
I
rejected
it
at
this
vs.
C
For
this
reason,
then
you
send
it
through,
and
it's
going
to
go
to
some
further
element
that
will
have
some
different
problem
with
it.
That'll
result
in
a
different
cause
code
being
sent,
so
I'm
not
even
sure
that
it's
possible
to
try
to
consolidate
what
all
the
multiple
potential
errors
are
associated
with
these
things,
simply
because
it's
an
orchestrated
service
right
yeah,
so
I'd
be
fine
with
with
having
that
constraint,
but
I
also
think
it
would.
It
would
probably
be
okay
if
you
want
to
have
multiple
ones.
F
C
C
F
F
G
C
F
F
C
G
I'm
just
thinking
probably
better
to
remove
it,
because
that
way,
if
you
have
a
feature
implemented
somewhere
down
the
line
from
like
some
device
like
there
is
a
there
is
something
which
is
signing
and
then
it's
getting
back
to
reason
to
move.
The
reason
passes
this
thing
through
and
essentially
whatever
is
the
device
upstream
is
not
going
to
see
any
of
the
store
reasons
or
any
of
the
new
features.
F
Yeah,
I
think
that's
actually
a
really
good
point.
Like
you
know,
if
you
get
the
reason
header
with
stir
and
you
don't
have
a
ppi,
you
don't
know
what
to
do
so.
I
guess
back
to
my
comment
of
like
do
we
do.
We
is
that
even
a
use
case
that
we
care
about
and
want
to
give
the
details
of,
I
I
sort
of
yeah,
maybe
might
have
a
stronger
opinion
about
just
removing
the
reason
matter.
I.
C
F
F
A
F
F
F
B
F
J
H
C
C
F
F
D
D
F
C
C
F
F
F
B
F
C
B
C
C
Probably
we
need
some
kind
of
real-time
freshness
check
for
these
certificates
and
that
the
check
would
be
a
little
different
than
what
you're
used
to
in
ordinary
like
web
pki
or
something.
Why
is
that?
It's?
Because
the
certificates
that
we
defined
in
a226
have
this
new
field?
That's
called
a
tn
off
list
and
the
tn
office
can
be.
It
can
contain
a
couple
different
kinds
of
identifiers,
one
of
the
things
we
call
service
provider
codes,
which
are
basically
in
north
america.
C
These
fancy
codes
that,
like
identify
who
carriers
are
another
thing
they
could
take
could
contain
are
telephone
numbers
or
lists
of
telephone
numbers,
and
these
are
like
baked
into
the
search
themselves
so
that,
when
you're
signing
for
a
call
with
the
cert,
you
have
some
sense
of
like
what
the
scope
of
authority
is
of
the
signing
entity,
and
so
there's
an
issue
with
that.
Though,
when
you
start
doing
telephone
numbers
and
baking
them
in
desserts,
the
problem
is
people's
ownership
of
telephone
numbers.
It's
kind
of
dynamic.
C
C
Is
this
particular
telephone
number,
because
if
you're
a
verification
service
you
just
got
a
call
right
call
comes
from
some
particular
calling
party
number,
and
the
only
thing
you
really
want
to
know
at
that
moment
is:
should
the
entity
that
sign
for
this
call
be
able
to
vouch
for
this
number,
and
so
I
asked
ross
and
sean
turner,
who,
I
don't
believe
could
join
us
today.
What's
the
right
way
to
do
that,
we
talked
about
a
whole
bunch
of
ways
to
do
that.
C
We
added
this
ocsp
extension
to
the
original
draft
version
of
8226
that
basically
contained
a
url
in
it
that
you
know
you
could
you
know
ocsp
extension
in
it,
you
could
use
that.
Would
then
let
you
be
able
to
inquire
with
ocsp
just
pass
fail.
This
particular
tn.
Is
it
in
scope
of
the
cert
or
not
get
back
a
yes
or
a
no
answer?
C
Ultimately,
we
decided
when
we
were
doing
rfc
2082-26.
We
didn't
like
have
enough
incentive
frankly
to
include
that
mechanism
or
initially
in
the
scope
of
this
work.
A
lot
of
people
are
using
crls,
because
a
lot
of
people
are
using
service
provider
codes.
These
spcs
the
great
thing
about
having
what
speaking
to
your
search,
be
just
like,
I'm
etnt
or
I'm
orange
or
I'm
joyce
telecom.
C
Is
that
you're
not
worrying
about
that?
Like
individual
level
number
stuff,
and
so
you
know
basically,
whether
they
assign
port
or
nods,
whether
you
trust,
att
or
orange,
or
who,
whoever,
but
now
we're
actually
starting
to
get
into
certificate
delegation
into
the
idea.
You
might
have
an
entity
like
an
enterprise
that
owns
like
a
couple
thousand
blocks
or
that
owns
like
specific
number
ranges:
they're,
not
a
carrier.
C
C
Now
you
know
there
is
one
open
issue
I
want
to
talk
about
today,
and
this
is
the
major
thing
you
will
see.
That
is
different
from
the
current
draft
of
this
from
the
last
one.
We've
talked
about
two
ways
of
approaching
this
and
these
ways
model
how
tls
has
utilized
ocsp
in
the
past
to
either
have
this
query
by
the
relying
party
on
the
terminating
side,
in
our
case,
the
verification
service
or
to
staple
it,
and
what
is
stapling
entails.
C
C
The
ca
that
issued
the
cert
believes
you
know,
basically
what
the
osp
response
ocsp
response
would
have
been
if
you
went
and
asked
on
the
terminating
side,
you're
just
going
to
pre-generate
that
and
ship
it,
along
with
the
passport
to
reach
the
termination
side,
and
this
is
really
cool
and
there
are
some
trade-offs
around
it
that
are
beneficial
for
privacy
and
a
bunch
of
other
things.
But
my
proposal
here
today
is:
let's
not
do
that.
C
C
D
C
J
I
The
point
of
this
without
stapling,
as
in
you,
you
said
the
like
kind
of
one
of
the
benefits
of
politics
at
the
moment-
is
that
they're
very
cachable
which
speeds
up
verification.
But
if
you
have
to
do
an
os,
ocsp
dig
every
time,
then
that
kind
of
negates
the
point
of
that
and
you
might
as
well
just
download
a
certificate.
C
C
C
Because,
like
I
was
happy
to
do
tn
by
ref
right,
I
mean
that's
all
in
8226
already
and
if
your
telephone
number
list
is
very
simple
and
you
aren't
concerned
about,
you
know
a
relying
party
learning
what
the
total
set
of
numbers
are,
that
the
certificate
has
a
scope
of
authority
for,
like
you
know,
tn
bireftist
works,
then
largely
people
in
addis
pushing
back
on
that
and
saying
like.
No,
that's
completely
unacceptable.
I
I
We
probably
want
something
that
looks
more
like
ocsp
or
short-lived
certs,
and
the
discussion
actually
went
towards
like
ocsp
is
basically
identical
to
short-lived
certs,
and
we
already
know
how
to
do
trouble
assets.
So
we
should
probably
go
think
about
that.
Not
that
any
thinking
then
happened
as
far
as
I'm
aware.
C
Yeah
I
mean
on
the
bottom
of
the
slide.
You'll
see
me
saying
we're
to
continue
to
explore
the
shirt
live
path
separately
and
again.
I
think,
as
I
said,
the
the
properties
of
stapling
and
doing
short-lived
search
look
real
real
similar.
I
mean,
I
think
the
issue
is
doing
short-lived
circuits.
The
best
way
we
needed
we
know
to
do
that
is
acme
and,
like
that's
an
even
heavier
lift
than
any
other
development
thing
that
we're
entertaining
to
this.
I
J
C
You
can
still
cash
the
cert
right
yeah.
This
isn't
a
cert
caching
problem,
there's
just
you
eating
the
rtt
of
ocsp
on
on
everything,
but
again
like
getting
a
short
you
know.
Stapling
requires
the
same
thing
on
the
authentication
service
side
right,
it's
just
a
matter
of
like
which
side
pays
the
cost.
F
F
C
I
think
we
have
a
better
idea
of
how
to
do
this
without
stapling
than
with
it
in
the
sense
of
what
does
it
look
like
with
stapling.
So
this
is,
every
authentication
service
has
a
connection
to
a
ca.
It's
going
to
issue
them
these
staples
right,
there's
a
push
or
pull.
I
assume
that
it's
paul
right
in
the
sense
of
asses
are
going
to
dip
the
ca,
get
the
staple
and
then
send
it
to
the
vs
unless
they
can
anticipate
what
those
staples
are
gonna
need
are
in
advance.
C
D
C
C
And
I'm
not
saying:
let's
not
do
service,
I'm
just
saying
as
far
as
I
know,
that
means
doing
acme
and
like
that
you
know-
or
at
least
that
is
the
best
way
we
know
to
do
that,
and
we've
tried
to
get
acme
down
people's
throats
in
this
forever
and
it's
been
like
a
real,
a
real
problem
I
mean
russ.
Can
you
is
there
anything
you
can
fill
in
for
me?
Am
I
am
I
adequately
describing
the
trade-off
for
ocsp
versus
stapled
and
not
in
terms
of
how
the
rtt
costs
are
paid.
C
C
J
C
C
Do
it
once
a
day
right,
and
so
you
only
pay
that
cost
for
generating
the
short-lived
cert
once
a
day,
and
so
it
does
not
impact
call
processing
where
you
do
pay
the
cost,
for
that
is
in
cash
ability
of
the
cert
on
the
verification
service
side,
because
the
more
frequently
you
update
it,
the
more
frequently
the
vs
is
going
to
have
to
execute.
You
know
dereference
the
x5u
and
actually
get
a
new
server
to
validate
passports,
and
so
the
overall
cost
of
that
or
less
like
and
there's
certainly
less
for
call
processing.
C
J
C
C
C
C
I
say:
let's
keep
looking
at
it.
Let's
look
at
this.
I
think
this
is
kind
of
easier
to
do,
which
is
why
I'm
presenting
this
today
and
not
short-lived.
There
is
a
short-lived
draft
it.
You
know
at
least
lays
out
what
the
major
parts
of
this
are.
This
the
fruit
of
this
looks
more
low-hanging
to
me
than
any
others,
and
we
need
something
I
think
to
cover
the
delegation
cases
that
are
now
more.
D
Jonathan,
I
mean
I
just
I'll
say
first
to
reply,
someone
comment
on
that
and
then
something
I
actually
have
to
say.
I
think
the
question
important
question
is
not.
How
often
does
it
change,
but
how
quickly
does
it
change?
How
soon
do
you
know
how
soon
you
need
to
say?
Yes,
this
is
dead
after
you
know
it's
done.
You
know
which
is
basically
what
you're.
D
It's
the
you
know,
dns
ttl
problem,
but
what
I
was
going
to
say
is:
if
you're
not
doing
no,
if
you're
doing
the
terminating
side,
doesn't
this
and
you're
putting
the
tns
and
the
oscp
queries
doesn't
mean
the
ca
or
the
ocg
verifier
gets
to
know
every
number.
That's
telephone
number!
That's
calling
that
vbs.
C
C
Nonetheless,
I
think
it's
it's
an
easier
path,
and
it's
something
can
like
be
bolted
on
to
this
again,
because
when
you
look
at
it
like
changing
the
as
side,
you
know
for
this,
then
what
happens
if
some
ases
implement
stapling
and
some
don't
versus
what
happens
in
the
vs
side
of
this?
If
some
vs's
implement
this
and
some
don't
right,
it's
really
a
question
of
you
know-
is
the
relying
party
in
the
driver's
seat
to
this,
or
is
the
a.s
in
the
driver's
seat
of
this?
C
E
C
I
promise
I
promise
we
will
get
the
stapling
part
of
it
again.
I
just
think
it's
it's
a
lift,
but
I
will
say
that
if
we're
agreed
about
that,
I
think
this
is
probably
pretty
close.
Actually
like
I,
I
asked
sean
turner
to
take
a
look.
He
sent
me
a
mail
earlier
saying,
he'd
taken
a
look
at
it.
He
thought,
because
we
did
this
like
five
years
ago
or
something
is
when
we
respect
this
out.
You
still
thought
it
was
cool,
really
russ.
C
C
You
know
make
sure
that
this
doesn't.
Nothing
has
changed
in
the
last
like
five
years
that
we
should
have
been
thinking
about,
but
not
this.
This
could
be
close
to
shipping.
Actually,
that's
my
my
general
impression,
so
I
I
would
ask
the
chairs
to
identify
some
reviewers,
who
can
take
a
look
at
this
and
explain
to
me
why
my
previous
statement
about
that
was
incorrect.
E
E
E
I
E
C
E
C
C
There
are
some
very
technical
like
stupid,
sip
reasons
why
that's
true,
but
it
basically
means
we're
restricted
to
you
know
putting
passports
only
into
sip
requests,
not
just
responses
and
like
that
means.
We
need
pracs
and,
like
all
this
other
stuff-
and
I
just
don't
know
if
people
are
going
to
do
it
and
like
I
don't
you
know
so
looking
at
it,
I'm
wondering
do
we
need
to
figure
out
something
weirder
right
that
is
weirder
than
john
elway
was
thinking
when
we
did
4916
that
we
think
people
would
actually
implement.
F
C
G
C
C
Well,
I
mean
it's
not
like
we
actually
have
to
solve
for
a
fetus
office.
It's
just
like
you
know.
It's
really
just
the
simple
fact:
the
problem
is,
if
you
get
back,
you
get
back
a
sith
response
that
tells
you
like.
This
is
the
identity
of
the
other
side
and
the
response
is
broken
in
some
way.
There's
no
way
to
reject
a
response
right.
That's
the
fundamental
problem
like
if
you
get
back
200,
okay
or
183
with
early
media.
C
Okay,
you
know
and
like
what
what
is
actually
in
it
is
a
passport
and
that
passport
does
not
support
you.
Don't
support
a
trust,
anchor
or
there's
something
like
wrong
with
the
number
that's
being
asserted
and
like
that,
then,
and
of
course
you
need
the
identity
track
of
getting
the
from
header
field
to
correspond
to
who
you
actually
reached
instead
of
the
original
transaction
mapping
identifiers,
that's
how
you
end
up
with
like
prac,
and
it
sucks.