►
From YouTube: IETF111-LAMPS-20210729-2200
Description
LAMPS meeting session at IETF111
2021/07/29 2200
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
A
A
B
All
right
so
next
slide.
Please
we're
talking
about
header
protection
here
so
yeah,
so
we
are
looking
at.
I
hope
some
folks
have
read
the
draft.
The
point
of
the
header
protection
draft
is
to
extend
the
end
and
cryptographic
protection
for
email,
headers
that
we
currently
have
just
for
the
body
since
last
ietf
we've
had
several
revisions
which
are
fairly
minor,
but
the
big
change
is
that
we
added
40
test
vectors
to
the
draft.
B
B
We've
also
taken
the
time
to
try
to
enumerate
the
list
of
problems
that
we
see
with
different
legacy
clients
when
they
are
dealing
with
these
different
structures
of
messages
as
they
come
in
and
in
this
presentation
we're
going
to
be
making
some
asks
of
the
working
group,
so
you'll
see
that
yellow
color
come
up
with
that
next
slide.
Please.
B
B
B
We
look
at
the
different
header
protection
schemes,
as
you
probably
remember,
from
last
time,
or
if
you've
read
the
draft.
There
are
two
proposed
header
protection
schemes.
One
is
called
wrapped
messages
and
one
is
called
injected
headers.
We
also
compare
messages
that
don't
have
any
header
protection
for
the
sign
in
encrypted
messages
using
the
injected
headers.
We
also
potentially
use
a
legacy
display
or
no
legacy
display,
so
the
legacy
display
is
a
mechanism
to
try
to
stuff
the
subject,
in
particular
in
a
way
that
the
legacy
client
would
be
able
to
view
it.
B
A
lot
of
this
work
is
about
thinking
about
how
these
messages
interact
with
legacy
clients.
We
also
look
at
different
header
confidentiality
policies,
whether
the
there's
a
minimal
policy
and
a
strong
policy
we
look
at
whether
replies
are
we
look
at
some
of
the
messages
are
replies
to
others,
so
we
look
to
be
able
to
look
at
threading
for
signed
only
messages.
B
There
are
two
different
kinds
of
signed:
only
messages,
because
s
mine
has
these
different
features
where
you
use
the
sign
data
mechanism
where
you
have
multi-part
signed
and
the
message
body
itself,
the
cryptographic
payload
could
either
be
simple
text
plain
or
it
could
be
more
complex
with
like
a
multiple
multi-part
alternative
text
and
a
image
attachment
so
there's
all
of
these
features
are
covered
in
the
40
different
email
messages.
It's
a
lot
to
cover
and
if
folks
think
it's
too
much,
I
sympathize.
B
I
think
I
think
it's
too
much,
but
I
don't
know
how
to
cut
it
down
next
slide.
Please,
potentially,
we
want
even
more
this
scares
me,
but
we
might
want
to
see
replies
for
the
unprotected
or
plain
s9
messages
to
see
where
the
threading
works.
For
that,
we
might
want
to
consider
having
tampered
variants
of
all
of
the
s-mine
messages
so
that
you
can
see
what
happens
in
a
client
if
a
tampered
message
comes
in.
That
would
probably
be
useful,
but
that
basically
double
the
number
of
messages.
B
We
may
also
want
to
consider
creating
these
test
vectors
using
certificates
that
are
issued
by
certificate
authorities
that
everyone
widely
trusts
the
trouble
with
doing
that
is
that
those
vectors
will
expire
rapidly,
because
I
don't
think
anyone
is
issuing
certificates
from
like
the
that
that
will
last
more
than
a
year,
and
so
if
we
were
to
build
variants
of
these
test
vectors.
That
would
that
that
would
you
know,
work
with
pre-trusted
cas
those
test.
B
Vectors
would
expire
very
rapidly
and
wouldn't
be
useful
for
implementers
who
could
pick
this
up
a
year
from
now
next
message.
Next
slide.
Sorry,
so
this
is
the
ask
for
the
working
group
have
people
here
in
the
working
group
tested
their
clients
against
these
test
vectors.
If
you
haven't,
please
check
it
out,
we
would
like
to
so
there's
a
link
there
there's
a
bunch
of
different
ways.
You
can
get
these
test
vectors.
You
don't
have
to
extract
them
from
the
draft
yourself.
B
C
Can
you
hear
me
yep,
okay,
just
remarked
the
last
slide
why
we
want
to
do
this
with
cas
that
are
pre-installed
in
the
clients?
It's
some.
One
of
the
difficulties
we
had
is
to
import
the
test
certificates
to
the
clients
and
if
we
have
like
pre-installed
cas
this
is
expected
to
be
easier.
It
was
just
a
remark
for
the
last
slide.
B
Yeah,
so
stefan
asks
why
don't
we
use
test
vectors
with
infinite
validity?
Well,
I
don't
think
there
are
any
infinite
validity
x,
509
certificates
that
are
out
there.
The
test
vectors
that
we
use
come
from
the
draft
lamp
samples
which
I
will
talk
about
in
a
subsequent
presentation
and
those
have
validity
of
several
decades.
B
I
suspect
that
several
decades
from
now
we
will
have
new
information
and
we
may
want
to
regenerate
them.
If
folks
look
at
the
repository
that
builds
this
draft,
you
will
actually
find
the
code
that
generates
the
test
vectors.
So
we
should
be
able
to
regenerate
the
test
vectors.
Should
we
decide
at
some
future
point?
We
want
to
rebuild
them,
but
but
yeah
right
now,
it's
several
decades
of
validity,
and
hopefully
that's
enough
for
folks
to
get
these
implementations
done
before
we
stop
caring
about
email
but
yeah.
B
B
The
trouble
with
doing
with
regenerating
them
every
month
is
that
these
things
can
change
and
if
somebody
does
a
snapshot
at
time
t
I
definitely
don't
want
to
ask
them
to
do
another
snapshot
at
time.
You
know
one
month
down
the
line.
I'd
like
people
to
be
able
to
say,
okay,
I
looked
at
the
same
thing
and
it
worked
out
the
same
way
and
I'm
you
know
the
the
software
that
is
generating
these
made
themselves
get
updated
and
I'm
a
little
bit.
I
just
don't
want
it
to
be
a
moving
target.
B
B
B
Just
so
folks
are
thinking
about
this.
It
may
this
may
be
obvious
to
some
of
the
people
here,
but
I
just
want
to
like
call
out
the
specific
complexities,
so
one
of
them
is
that
every
message
is
an
interaction
between
two
different
user
agents,
at
least
two
different
user
agents.
Some
people
have
checked
their
mail
in
multiple
places,
and
so
it's
difficult
to
know
for
a
given
message
when
it's
being
generated,
you
know,
there's
no
live
negotiation
between
the
mail
user
agents,
so
so
so
that's
a
challenge.
B
Some
of
the
mail
user
agents
that
are
involved
will
not
be
upgradable.
Furthermore,
when
you're
sending
a
message,
you
have
no
idea
which
mail
user
agent,
the
recipient
uses
that's
by
design.
I
think
that's
a
healthy
part
of
the
email
ecosystem,
but
it
does
sort
of
handicap
us
here
when
you're
receiving
a
message.
You
don't
necessarily
know
what
user
agent
the
sender
used.
So
that
is
so.
B
That
is
an
additional
issue
and
then,
on
top
of
that,
different
people
who
are
evaluating
these
schemes
may
have
different
priorities
in
terms
of
usability
confidentiality,
authenticity,
other
things
like
that,
those
trade-offs.
You
know
the
sender
may
have
a
different
priority
than
the
receiver.
In
the
case
of
a
specific
message.
B
B
So
this
is
like
it's
a
pretty
complicated
space
because
of
the
classic
ietf
deployed
legacy
base
next
slide,
please
so
bernie
and
alexi,
and
I
and
hernani
also
from
pep,
took
a
stab
at
trying
to
enumerate
all
of
the
problems
that
we
are
seeing
with
legacy
male
user
agents
when
they
encounter
the
messages
that
are
in
the
vector,
the
the
test
vector
corpus
that
we
have.
We
created
a
list
of
those
concerns
that
list
is
in
the
new
draft.
I
hope
folks
will
take
a
look
at
that
list.
B
It's
a
pretty
shorthand
list.
I
didn't
try
to
get
into
a
lot
of
detail,
but
you
can
see
specific
things
that
we
suspect
our
problems
with
legacy:
email,
user
agents.
We
did
not
try
to
prioritize
those
things.
We
didn't
say
this.
One
is
worse
than
that
one
and
you
may
find
that
for
some
legacy,
clients,
there's
no
good
outcome
like
there's
no
way
to
have
a
legacy.
Client
that
does
that
that
solves
all
of
them.
You
basically
have
to
implement
the
draft
to
solve
all
of
them.
That's,
hopefully
a
good
thing.
B
The
three
contacts
that
we
identify-
and
this
is
a
little
bit
tricky
here
too-
but
one
of
them
is
viewing
messages
in
the
list.
One
of
them
is
rendering
a
message
specifically
on
its
own
and
the
third
one
is
replying
to
a
message,
because
we
find
that
there
are
different
problems
that
show
up
there.
B
There
are
some
duplications
in
these
lists
in
that,
for
example,
some
of
the
same
problems
show
up
on
rendering
assigned
only
message
versus
rendering
assigned
an
encrypted
message,
but
they're
not
exactly
the
same,
and
it's
possible
that
the
prioritization
that
we
have
will
be
different
for,
for
example,
the
same
problem
in
a
signed.
Only
message
might
be
worse
or
better
than
having
the
same
problem.
B
When
render
you
know
the
same
problem
for
rendering
a
signed,
only
message
might
be
worse
or
better
than
the
problem
than
the
same
problem
when
rendering
assigned
an
encrypted
message,
and
one
example
for
that
is
requiring
user
interaction
for
a
signed.
Only
message
might
be
significantly
worse
than
requiring
user
interaction
for
a
signed
and
encrypted
message.
B
We
can
discuss
whether
that
priority
is
is
correct,
but
the
that's
sort
of
the
intuition
that
I
want
to
put
forward
right,
like
we
might
user
agent
developers,
might
think
it's
okay
for
the
user
to
have
to
do
some
work
to
decrypt
a
message,
but
they
shouldn't
need
to
do
any
work
to
read
a
signed,
only
message-
or
maybe
we
decide
it's
the
opposite,
but
my
point
is
that
these
are
broken
out
by
by
category
here.
Next
slide,
please.
B
So
these
are
some
asks
for
the
working
group.
I
hope,
if
you're
here
in
the
working
group
you're
thinking
about
these
questions,
we'd
like
you
to
take
a
look
at
the
enumeration
of
problems
that
we
have
they're
in
appendix
a
of
draft
six.
Please
take
a
look
at
those
and
give
us
feedback
on
the
list.
Did
we
miss
a
problem
that
happens
when
we
look
at
these
messages
or
reply
to
them
in
the
mail
use
region
that
you
care
about?
B
B
And
since
the
last
time
we
have
added
some
screenshots
from
outlook,
365
and
apple's
mailbot
app
so
kudos
to
bernie
and
hernani
for
pulling
all
the
other
screenshots
in.
Hopefully
they
will
make
it
into
the
repository
soon,
but
I'm
going
to
show
you
we're
going
to
show
you
some
screenshots
coming
up
from
those,
but
next
slide.
Please.
B
So
this
is
the
ask
we
have
for
you.
I've
already
asked
you
to
test
your
client.
If
you
could
screenshot
your
client
doing
these
different
things.
That
would
be
great.
We
I
I
note
that
we
have
no
mobile
clients
screenshots,
yet
at
all.
So
if
you
have
the
opportunity
to
use
a
mobile
client
and
check
these
messages
out,
that
would
also
be
very
good
yeah
next
slide.
Please
so
I'm
gonna
have
bernie
take
over
here
and
give
us
a
bit
of
a
talk
about
to
walk
us
through
screenshots
from
outlook
365.
B
C
C
Then
the
legend
will
be.
I
made
some
frames
around
the
most
important
points
and
in
the
orange
frame
we
have
the
unprotected
subject
where
in
a
yellow
frame
we
have
the
protected
subject
in
a
blue.
We
have
the
body
and
in
a
big
frame
we
have
the
security
indicators
in
the
problem
frame.
We
have
the
buttons
to
forward
or
reply
to
the
message.
C
B
Slide
please
to
be
clear.
These
frames
are
pointing
to
features
that
we
see
the
frame
doesn't
mean
that
there's
a
problem.
It
means
this
is
the
feature,
and
then
we
can
describe
the
problems
that
we
see
about
those
features
right.
So
the
fact
that
there
is
a
security
indicator
is
not
a
problem,
but
it
may
draw
our
attention
to
some
problem
or
other.
C
As
on
the
previous
slide,
you
see
the
orange
frame
that
is
indicating
the
unprotected
subject.
There
is
no
difference
between
the
two
like,
on
the
left
hand,
side,
we
have
the
wrap
message
and,
on
the
right
hand,
side
we
have
the
injected
message
drop
message.
Actually,
the
current
s
mime
standard
with
the
wrap
message
you
have
to
open
an
attachment
that
is
shown.
C
C
Everything
is
fine
from
usability
point
of
view
or
almost
everything
like
the
user
sees
the
protected
subject
and
the
body,
whereas
on
the
injected
part,
like
the
alternative
that
is
proposed,
you
see
the
body
and
in
a
sign
only
it
looks
fine,
except
for
that
you
don't
see
the
protected
subject
at
all.
You
don't
have
any
chance
to
get
the
protected
subject
visible
regarding
the
security
indicators,
they
are
where
we
expect
them
like.
C
B
So
let
me
let
me
just
jump
in
for
a
second.
I
want
to
highlight
here
that
as
editors
as
co-editors
of
this
draft
bernie-
and
I
don't
always
agree
on
the
issues
here
so
bernie
describes
the
left-hand
side
as
looking
fine
here
and
the
right-hand
side
is
not,
and
I
want
to
just
point
out
a
few
of
the
things
that
we
enumerated
in
our
list
of
problems
that
do
show
up
on
the
left,
hand,
side
and
don't
show
up
on
the
right.
So,
on
the
left
hand,
side
in
the
wrapped
message.
B
If
you
look
at
the
message
that
has
been
double
clicked
right
once
that's
been
opened,
there
are
no
security
indicators
anymore.
While
this,
the
message
was
opened
from
the
message
that
shows
a
security
indicator,
there's
no
security
indicator
anymore.
That
shows
that
the
message
was
signed.
The
user
basically
has
to
remember
that
it
was
open
from
this
particular
message
in
the
background
and
you
could
navigate
away
from
the
message
in
the
background
to
some
other
message.
So
that's
a
concern
missing
security
indicators.
B
Secondly,
when
you
want
to
reply
to
this
message,
you
now
have
two
different
places
where
you
could
reply.
If
you
look
on
the
the
wrapped
message,
you
can
see
that
there's
a
set
of
options
at
the
top
that
are
reply
boxes.
Those
are
outlined
in
brown,
there's
a
second
set
of
reply
boxes,
so
that's
a
confusion
that
the
user
has
to
navigate.
Thirdly,
the
fact
that
they
have
to
interact
at
all
is
potentially
a
problem.
Users
might
be
confused
as
to
why
a
message
is
coming
in.
B
They
have
to
do
some
additional
work
to
get
to
it.
So
the
fact
that
the
you
know
there
is
a
an
advantage
here,
which
is
that
the
secure
the
protected
header
the
protected
subject
is
shown,
but
if
those
two,
if
those
two
subjects
differ,
it's
not
clear
how
the
user
is
supposed
to
identify
which
one
is
the
correct
subject.
B
We
know,
because
we're
designing
this,
that
the
one
that's
outlined
in
yellow
is
the
protected
one,
but
a
user
who's.
Simply
looking
at
this
isn't
necessarily
going
to
know
what
the
relationship
between
those
two
things
are.
So
there
are
potentially
a
bunch
of
issues
and
granted
there
are
issues
in
the
other
one
as
well
in
the
injected
header.
But
it's
not
it's
not
clear
that
we
have
a
like.
I
think
bernie
and
I
disagree
about
what
the
best
outcome
is
here.
C
Yeah
I
mean
I
was
about
to
talk
about
reply
buttons
as
well,
but,
as
I
say,
with
security
indicators,
you
don't
see
them
in
the
inner
message
or
in
the
protected
message
itself,
but
you
basically
see
them
where
it's
expected,
so
the
whole
inner
part
is
protected.
I
don't
see
that
as
a
main
problem.
Danielle
sees
that
differently.
C
Regarding
the
reply
buttons,
as
you
see
on
the
wrap
message,
has
two
options
to
reply,
but
the
user
is
most
likely
opening
the
message
via
the
attachment
and
then
goes
forward
from
there
and
leaves
the
the
rest
be
a
destressed
alone.
That
is
how
I
expect
most
users
will
flow,
not
all,
but
most
will
flow,
and
you
will
see,
then
how
the
reply
will
look
like
after
the
user
has
opened
the
attachments
in
the
two
slides
from
now.
C
To
summarize
the
differences
here,
the
wrapped
case,
the
current
s-mime
standard.
You
have
to
change
to
see
everything
you
need.
You
see
the
protected
subject
and
the
unprotected
subject.
You
can
actually
compare
whether
it
has
been
tampered
with
manually.
You
have
the
chance
where,
on
the
injected
message,
you
don't
have
the
protected
subject,
and
you
also
don't
see
if
someone
is
tampered
with
the
subject.
Basically,
ss
mine
works
now.
C
We
chose
the
signed
and
encrypted
case
in
a
way
it
looks
pretty
similar,
but
there
are
some
differences,
especially
around
the
unprotected
subject.
The
unprotected
subject
is
now
obfuscated
so
that
it's
not
visible
for
an
attacker
on
the
path
and
again,
in
the
wrapped
case,
in
current
s,
mime
standard,
you
see
an
attachment
and
if
you
open
that
attachment,
in
my
opinion,
everything
is
fine.
C
You
have
another
email
in
an
email
where
that
you
can
do
everything
you
need,
and
you
see
the
protected
subject
and
the
content
as
well
as
reply
buttons
that
you
can
use.
However,
in
the
injected
case,
you
don't
see
any
subject
at
all.
That
is
useful.
You
only
see
the
obfuscated
subject
like
the
unprotected,
subject
obfuscated.
C
B
If
that
is
not
the
case,
no,
it's
the
same
comments
as
last
time
right,
there's,
user
interaction,
there's
weird
security
indicators,
there's
two
there's
two
different
things
that
you're
looking
at
trying
to
make
sense
of
two
different
ways
to
reply
right,
there's
a
bunch
of
of
usability
stumbling
blocks
on
the
left
hand,
side,
but
I'll
let
deb
go.
I
don't
want
to.
D
C
B
C
To
actually
solve
the
missing
subject
with
injected
headers,
there
is
the
legacy
display
mode.
That
is
adding
something
else
in
several
clients.
This
really
helps,
but
not
in
the
outlook
case
in
outlook
case
it
looks
really
weird
and
for
you
so
it's
difficult
to
understand.
What's
going
on
here,
so
on
the
left
upper
corner,
you
see
what
this
displayed.
C
When
the
user
opens
the
message
with
the
orange
box,
it's
marked
unprotected
subject
that
has
been
obfuscated:
the
dot
dot
dot,
which
is
not
so
useful
and
in
the
content
you
see
three
attachments,
plus
the
on
plus
the
protected
subject,
which
is
marked
in
yellow.
So
what
you
can
do
is
here
is
opening
the
attachments.
If
you
try
to
open,
for
example,
the
text
attachments,
the
the
stuff
in
the
middle
is
displayed,
which
is
a
security
warning
which
is
a
nuisance
security
warning
the
text
message
could
be
from
a
dangerous
source
or
whatever.
C
C
Okay,
if
assuming
we
want
to
see
the
text
attachments-
and
we
say
yes,
preview,
the
file
and
everything
is
fine.
With
this
there's
no
security
issue,
then
you
see
what
is
opening
on
the
right
hand,
side
in
the
right,
lower
corner.
Actually,
a
text
editor
opens
displaying
the
text
message.
You
finally
see
the
content
of
the
message.
C
B
B
At
some
point,
we
don't
have
the
time
to
go
through
all
of
them
right
now,
but
if
you
grab
these
slides,
there's
a
collection
of
slides
in
the
deck
at
the
at
the
end
that
show
thunderbird
and
mailbot
app
as
well,
which
are
which
shows
significantly
fewer
failures
on
all
of
these
things.
But
outlook
is
a
particularly
nasty
one.
C
C
C
So
we
are
not
showing
what
happens
if
he
clicks
the
reply
button
on
the
original
message
on
the
auto
message
to
save
you
from
too
many
screenshots
here
so
wrapped
after
the
attachment
has
been
opened
and
clicked
that
will
reply
inside
the
attachment.
Everything
looks
fine,
however,
in
the
attachment.
It
also
looks
fine,
though
the
subject
is
not
the
protected
subject,
it's
actually
unprotected
subject
that
is
used.
That
plays
a
role
if
the
subject
has
been
tampered
with.
On
the
other
hand,
this
is
actually
the
same
as
s
mine
works.
C
So
here
we
show
the
s.
Mime
standard
dropped
on
the
left
side
in
the
middle
injected
case,
and
this
legacy
display
mode
to
help
with
the
subject
is,
on
the
right
hand,
side
again
in
the
rubbed
case
after
you
have
opened
the
attachment
everything
looks
as
expected.
You
have
the
protected
subject
and
the
protected
body.
C
C
C
C
B
B
It's
certainly
useful
to
see
it,
but
in
this
case
outlook
is
basically
guaranteed
to
leak
the
protected
subject.
User
doesn't
pay
attention
to
that.
So
there's
a
there's,
a
booby
trap
built
in
to
this
mechanism
for
outlook
here.
That's
worth
thinking
about
in
terms
of
if
confidentiality
of
the
subject
is
one
of
the
goals
of
this
process.
B
C
B
C
E
B
Okay,
thank
you
so
that
that's
the
sort
of
question
that
we
hope,
folks
who
are
doing
screenshots,
will
will
take
note
of
as
they
do
the
screenshot
but
yeah
this
this
view
of
the
of
apple
mail.
You
can
see.
This
is
an
issue
with
apple
mail's
s,
mime
implementation
period
and
not
an
issue
like
the
fact
that
replies
to
encrypted
messages
are
not
are
not
encrypted
by
default
is
a
is
a
peculiarity
that
is
unrelated
to
header
protection
and
I'll.
B
C
B
We
have
not
had
as
much
engagement
on
the
list
as
we
would
like.
I,
you
know
I
welcome
more
engagement.
I
also
welcome
suggestions
about
how
we
could
get
more
engagement.
I
think
perhaps
we've
had
maybe
too
much
conversation
off
list
and
more
of
our
conversation,
more
of
the
conversation
between
the
editors
could
go
on
list,
but
but
we
really
would
like
to
see
more
help
from
the
working
group
here.
We
are
thinking
about
forming
this
as
a
design
team,
but
we
would
if
we
do
a
design
team.
B
This
is
an
ietf
mechanism
where
a
smaller
group
of
people
who
are
interested
in
a
particular
draft
push
forward
and
and
and
propose
something
concrete
and
then
bring
it
back
to
the
working
group.
But
if
we
do
that,
we
definitely
need
to
have
more
than
just
the
editors
participating
with
that.
We
have
asked
the
chairs
about
that.
B
So
I
think
you,
I
think,
you've
now
seen
a
bunch
of
the
decisions
that
we
are
trying
to
tackle.
With
this
draft
the
open
questions
I
think,
you've
seen
some
of
the
mess
that
the
legacy
clients
have
that
we're
that
we're
that
we're
struggling
to
deal
with.
I
don't
think
any
of
the
proposals
that
we
have
in
the
draft
are
problematic
in
terms
of
fully
implemented
clients,
but,
as
usual,
the
deployed
base
is
the
the
anchor
that's
weighing
this
draft
down.
B
A
Yeah
yeah
I'd
like
to
know
whether
people
are
interested
in
participating
in
such
a
design
team.
If
we
form
it,
if
you
could
just
put
something
in
the
chat,
so
we
can
know
we're
already
40
minutes
into
our
one
hour
slot.
So,
while,
while
they're
all
your
presentations
at
this
point,
we're
continuing
on
this
will
take
time
from
the
other
two.
B
B
So
alexei
says
in
the
chat
that
it
would
be
good
to
reach
out
to
some
s.
Mom
implementers
in
particular
folks,
with
with
popular
male
clients,
would
be
very
welcome.
I
don't
know
if
there's
anybody
from
outlook
who's
here,
if
you
are,
I
hope
you
don't
feel
that
we
just
savaged
you,
but
we
would
love
to
help.
You
figure
out
how
to
make
that
work
better.
If
you're,
here
from
from
outlook,
likewise
from
apple
mail
or
or
google,
which
has
you
know,
they
have
a
gmail
app
on
on
mobile,
that
would
be.
B
You
can
certainly
reach
out
to
me
and
give
them
their
contact
information,
and
I
will
track
them
down
and
you
know
and
ask
if
you
don't
feel
like
you
want
to
spend
the
political
capital
of
encouraging
them
to
participate,
but
those
those
are
some
of
the
the
wrinkles
that
we're
going
to
need.
If
we
want
this
draft
to
actually
reach
a
successful
conclusion,
I'm
a
little
bummed
that
nobody
else
in
the
working
group
seems
to
be
volunteering
either
for
for
the
design
team
would
folks
be
willing
to
participate
on
list
more.
B
B
B
B
B
B
C
Well
for
the
screenshots,
I
would
say
we
are
most
interested
in
the
widely
spread
email
clients
like,
for
example,
on
the
mobile
clients,
the
apple
email
client
on
mobile
clients,
as
well
as
the
gmail
could
be
interesting
if
there
are
some
s,
mime,
implementation
available
and
other
clients
that
are
widely
spread
out.
Most
interest
here.
B
So,
even
if,
if
you
have
a
non-slime
capable
client
feel
free
to
just
take
a
few
screenshots
of
normal
message,
plus
s,
my
message,
plus
the
protected,
signed,
only
messages
and
ignore
all
the
signed
and
encrypted
stuff.
That
also
is
useful
jonathan.
If
you
want
to
take
screenshots
of
fine,
that
would
be
great.
Like
seriously.
You
know,
I
don't
have
a
problem
with
seeing
that.
B
A
B
B
Since
we
last
checked
in,
we
now
offer
cross-sign
verification
paths,
which
means
it's
possible
to
test
things
like
trans
valid
certificates.
I've
fixed
some
things
in
the
certificates
like
the
domain,
the
distinguished
names
were
not
ordered
by
scope.
They
are
now.
Thank
you
to
folks
who
commented
on
the
list
to
improve
that
next
slide.
Please.
B
The
certs
that
are
in
the
draft
there's
a
bunch
of
them,
as
you
can
see
from
this,
there
are
about
12,
there's
two
root
certificate
authorities
and
different
using
different
cryptographic
mechanisms.
The
yellow
here
means
rsa,
the
blue
means
curve
2p519
for
signing,
obviously
that's
255.19
and
for
encryption,
that's
the
x25519.
B
You
have
direct
cert
paths
between
rsa
and
alice
and
bob
allison
bob.
All
of
the
end
entities
have
both
signings
certs
that
are
distinct
from
their
encryption
certs
with
the
ed
55
255
19
cert.
We
have
carlos
and
dana,
and
then
we
have
these
cross
certs,
where
each
ca
signs
the
other
root.
Ca
next
slide,
please
so
that
permits
us
to
have
two
different
certificate
chains.
You
know.
B
Just
looking
at
alice's
signing
cert
either
you
believe
either
you
have
the
rsaca
as
your
root
cert
and
you
have
a
direct
signature.
That's
a
complete
chain
or
you
have
edt
5519,
see
it
root
ca
as
your
trusted
root,
cert
and
then
there's
this
cross
signature
that
lets
you
validate
alice's
signing
cert
anyway.
So
it
lets
you
look
at
both
of
those
if
you
want
to
test
them
out
next
slide.
Please.
B
So
the
certificate
authorities
are
just
secret
key
and
certificate,
both
pem
encoded,
the
end
entity
certs,
we
have
the
same.
You
know:
secret
keys,
pema
coded
certificates
come
encoded
and
then,
for
each
end,
entity
alice
bob
carlos
dana.
We
have
one
pkcs
12
blob
that
is
password
locked.
It
includes
both
certificates,
both
keys
and
the
cross
certificates
that
are
needed
and,
of
course,
that
pkcs
12
valve
is
pen
encoded
so
that
we
can
include
it
in
the
draft.
B
B
I've
heard
some
reports
that
some
male
user
agents
and
some
certificate
stacks
can't
import
the
pkcs12
object.
In
particular,
I
did
some
testing
on
that
last
night
after
I
wrote
this,
you
know
this
slide
that
was
already
published,
so
I
don't
have
the
screenshot
for
you
here,
but
like
apple's,
keychain
access
app
can't
import
the
pkcs12
objects
that
are
here.
I
don't
have
great
tooling
for
unpacking
a
pkcs12
object
and
seeing
how
it
differs
from
one
to
another.
Some
possible
issues
are
the
pkcs12.
B
B
Yeah
russ
was
saying
he
had
trouble
with
the
earlier
version
as
well,
so
we
may
be
finding
bugs.
Also
here
like
maybe
these
pkcs12
objects
are
perfectly
fine
and
they're
just
bugs
in
the
implementations,
but
this
is
exactly
why
we
want
sample
sample
documents
to
work
with
deb
asks
whether
apple
allows
key
import
raw
key
import.
I
haven't
tried
that
what
I
did
it,
what
we
found
that
works
is
to
take
so
the
thunderbird
certificate
manager
does
accept
these
particular
pkcs12
objects
and
the
pkcs12
object.
B
If
you
then
re-export
it
in
thunderbird
to
a
different
peaky
cs12
object,
then
apple
mail
actually
does
import
that
object.
I
think
it's
there's
also
some
weird
caching
issues
that
I've
seen
with
how
apple
mail
deals.
Apple,
keychain,
access
deals
with
these
things,
so
it's
hard
for
me
to
tell,
without
like
wiping
the
operating
system
and
starting
from
scratch,
so
yeah.
B
If
anybody
has
any
pkcs,
12
knowledge,
tooling
expertise
and
wants
to
take
a
crack
at
looking
at
these
pkcs12
objects
and
telling
me
either
what's
wrong
with
them
or
what's
wrong
with
apple's
keychain
access.
That
would
be
great
if
you
want
to
test
it
on
other
stacks.
That
would
also
be
great.
Reports
to
the
list
would
be
awesome.
B
B
I
don't
know
how
folks
feel
about
having
software
specific
stuff
saying,
like
you
know,
when
this
draft
was
written
in
you
know,
august
of
2021
we
took
the
following
steps
on
the
desktop
on
the
apple
desktop
macintosh
operating
system
to
import
this,
and
this
is
what
we
found.
We
could
include
those
things
just
so
people
are
used
to
using
them.
So
folks
want
to
report
back
on
the
list.
We
don't.
B
B
Barring
the
appendix
and
the
possible
appendix
and
the
weirdness
with
pkcs12,
I'm
not
sure
what
else
there
is
to
do
on
this
draft.
So
I
think
we
are
approaching
a
working
group
last
call-
and
I
would
like
to
hear
from
folks
about
that
so
bob
talks
about
making
real
certs
with
the
command
line.
So
if
you
want
to
check
out
this
draft,
this
draft
contains
a
make
file.
The
repository
contains
a
make
file
that
generates
all
of
these
certs.
B
These
shirts
are
generated
from
scratch
in
a
principled
way,
so
that
they
are
re
re
that
they
are
deterministic.
That
was
a
that
was
a
deliberate
choice
to
try
to
ensure
that
we
can
see
how
the
stuff
is
built.
The
different
command
lines
are
versatile,
but
but
they
necessarily
give
us
a
nice
view
of
like
what's
in
a
pkcs12
object.
B
A
B
B
B
So
we
just
adopted
this.
It
is
built
in
gitlab.
If
you
want
to
take
a
stab
at
making
edits,
you
can
use
the
gitlab
interface
to
pull
it
down
and
look
for
edits.
As
usual,
edits
should
go
to
the
mailing
list,
but
you're
welcome
to
also
create
merge
requests
or
issues
in
gitlab
I'll
just
make
sure
that
they
are
echoed
to
the
main
list
they're
there.
The
scope
of
this
is
for
male
user
agents
that
have
that
offer
end-to-end
cryptographic
protections.
B
I
want
those
opinions
to
come
from
experience
with
and
I
don't
think
the
draft
needs
to
assume
any
particular
user
interface,
but
it
does
need
to
assume
that
this
is
that
these
male
user
agents
are
used
by
humans
and
the
humans
care
about
the
security
properties
that
they're
encountering.
The
draft
currently
is
agnostic
about
pgpmon
versus
s,
mine,
which
is
fine
by
me.
If
folks
have
an
issue
with
that,
we
can
tweak
it.
I
guess,
but
I
don't
think,
there's
a
need
right
now
for
it
to
care
specifically
about
pgp
versus
s9.
B
B
So
this
is
the
outline
of
the
document
if
you've
read
the
draft
already.
This
is
no
surprise.
We
start
off
with
expectations
about
what
what
the
user
agents
goals
are
and
what
the
and
some
shared
definitions
we
talk
about.
What
are
reasonable
types
of
protection
we
say
signed
only
and
encrypted
and
signed
plus
encrypted
is
really
it.
We
are
not
in
this
draft
encouraging
science
encrypted
only
but
unsigned
the
draft
is
opinionated
about
what
are
reasonable,
mind
structures
and
it
outlines
how
to
think
about
nested
cryptographic,
mime
layers
uses.
B
It
introduces
these
terms,
cryptographic
envelope
and
cryptographic
payload,
which
are
themselves
used
in
the
in
the
header
protection
draft.
There
are
the
sections
about
how
to
compose
a
message
and
how
to
interpret
messages
when
they
come
in
a
section
about
certificate
and
key
management
and
a
section
about
common
failures
that
are
observed
next
slide.
Please.
B
So
there
are
a
lot
of
to
do's
in
this
draft
and
if
you
all
are
implementers,
you
probably
have
some
opinions.
Please
propose
please
propose
guidance
for
how
you
think
that
users
should
work
even
if
you're,
not
an
implementer,
if
you're,
just
a
user
of
cryptographic
email,
you
probably
have
some
opinions,
they're,
probably
not
unreasonable.
If
you're
here,
please,
please
make
suggestions
for
things
that
are
missing
in
the
draft.
B
B
Peace,
so
what
this
draft
currently
does
not
have
is
any
test
vectors.
Any
renderings
of
these
are
interface
elements
or
even
a
checklist
of
what
implementers
should
work
through.
We
could
potentially
add
those
things,
I'm
not
sure
that
we
need
them.
I
think
the
textual
guidance
is
the
primary
goal
here,
but
if
folks
think
that
these
other
things
are
useful,
I'd
be
happy
to
add
them.
Also,
if
folks
want
to
propose
them
concretely
or
to
propose
other
elements,
please
go
for
it.
B
B
I
expect
us
to
come
up
with
new
ideas
and
that
this
document
will
probably
change
going
forward.
So
I
don't
know
how
I
feel
about
it
ever
being
sort
of
statically
an
rfc,
but
if
the
header
protection
draft
is
a
standard
and
it
needs
to
reference
this,
then
at
some
point
we
do
need
some
sort
of
stable
rfc
point.
I
think
so,
I'm
not
sure
what
the
right
life
cycle
expectations
are,
but
I
welcome
working
groups
proposals
on
that.