►
From YouTube: IETF109-LAMPS-20201117-0900
Description
LAMPS meeting session at IETF109
2020/11/17 0900
https://datatracker.ietf.org/meeting/109/proceedings/
B
C
C
C
C
Of
course
you
can
take
a
look
there
yourself
to
make
sure
if
you
make
a
point
that
it
gets
captured
correctly,
the
blue
sheets
are
captured
automatically
by
joining
the
session.
So
you
don't
have
to
do
anything
for
that
and
we
have
two
documents
that
are
with
the
rfc
editor
as
a
matter
of
fact
they're,
both
now
in
auth
48.
C
C
D
D
E
F
F
This
draft
has
probably
the
well-known
structure,
like
other
documents,
lists
message:
digest
algorithm
signature
algorithm,
a
section
on
different
key
management,
algorithms
for
the
envelope
data
stuff.
In
the
document
content
encryption
algorithm
also
used
only
in
the
context
of
envelope
data
and
message,
authentication
code,
algorithms.
F
F
C
F
F
F
F
F
C
C
F
C
F
C
A
G
A
F
F
C
F
F
Variants
here,
as
I
believe
in
in
the
context
or
in
the
kind
of
usage
in
within
cmp
within
certificate
management,
it
doesn't
really
make
sense,
so
you
should
should
always
have
an
ephemeral
part.
So
if
there
is
no
one
having
a
use
case
for
static
static,
tiffy
helmet
variants,
I
would
just
ignore
them
in
this.
E
F
F
A
E
F
F
F
I
also
make
use
of
the
id
rec
control
controls
from
crmf
instead
of
rsa
keylink
variable
in
the
certificate
request,
template
structure
I'll
have
further
questions
on
on
on
that
later
on,
I
also
updated
the
appendix
d2
of
4210
and
just
refer
to
cmp
algorithms
document
for
an
updated
list
of
algorithms
mandatory
algorithms.
Here
I
also
added
the
uri
discovery,
part
from
the
lightweight
profile
document
to
cmp
updates,
as
the
usage
of
dot
well
known,
is
kind
of
changing
the
normative
part
of
60
70
6712.
C
F
So
that
is
what
was
done
since
last
itf
coming
to
the
root
ca
certificate
update
general
message:
this
is
a
general
message
as
it
is
currently
specified,
but
after
discussing
this
internally,
we
figured
out
that
this
is.
This.
Exchange
is
unspecific
on
which
route
ca
for
which
route
route
ca.
We
are
requesting
an
update
so
currently,
if
there
is
a
pki
that
serves
different
root
case,
then
currently
we
have
no
means
to
neither
specify
for
which
root
ca.
F
C
F
C
F
F
C
D
F
F
So
therefore
yeah,
we
also
thought
about
that.
We
have
a
similar
issue
with
sending
a
request
message:
a
certificate
request,
measure
message
to
a
ca.
If
the
ca
supports
different
certificate
types,
it
is
maybe
not
completely
clear
which
certificate
profile
to
use
on
that
ca
and
therefore
the
question
was:
do
we
need
or
how
does
other
certificate
management
protocols
handle
this?
F
C
F
Okay,
good,
thank
you.
So,
let's
move
on
to
the
next
generally,
I
as
as
shown
on
maybe
a
jump
back
as
shown
on
on
this
slide.
We
use
the
controls
here.
So
these
are
attribute
type
type
value,
as
defined
in
rfc
42
11,
and
we
use
it
so
they
are
supposed
to
be
used
in
the
context
of
certificate
requests.
F
Here
we
use
it
kind
of
in
a
different
kind
of
context,
and
we
had
some
internal
discussion
whether
this
is
suitable
here
and
I
just
wanted
to
to
to
double
check
with
the
group
whether
it
is.
It
is
okay
to
register
new
rec
control
types
or
ids
for
the
usage
in
this
certificate
request,
template
general
message
or
whether
we
should
do
it
differently.
E
E
E
E
F
F
C
F
C
C
F
I
did
some
minor
editorial
things
and
the
rest
of
it
is
more
or
less
due
to
the
discussion
and
changes
to
cmp
updates
so
moving
moving,
some
of
the
the
parts
to
cmp
updates
to
get
rid
of
an
asn
1
module
in
lightweight
cmp
and
to
yeah
to
make
use
of
the
asymmetric
key
package
and
yeah.
I
think
this
is
it.
F
E
F
F
F
F
F
H
So
is
my
audio
coming
through
much
better
okay
good,
so
this
is
bernie
hennison,
I'm
making
this
presentation
together
with
dkg
like
I
will
have
a
first
section.
That
is
just
like
saying
what
happened
so
far
and
daniel
will
then
take
over
and
discuss
some
issues
like
more
like.
What's
coming
from
now
on
during
my
part
of
the
presentation,
there
may
be
clarifying
questions,
but
not
contributions
for
discussions.
Those
should
be
postponed
to
danielle's
section
next
slide.
H
H
This
includes
an
editorial
cleanup
that
was
like,
in
particular,
abstract
need
production
needed
to
be
rewritten,
which
was
complained
about
for
good
reasons.
Then
we
started
to
restructure
it
a
bit
regarding
the
definitions,
for
example,
like
we
have
now
cryptographic
clear
cryptographic,
payload
and
cryptographic
envelope.
Those
are
now
defined
in
another
draft
and
this
draft
is
referred
to
and
regarding
this
other
draft,
the
plan
is
to
split
the
current
data
protection
draft
into
us
into
a
draft
that
only
discusses
header
protection,
which
is
the
one
we
are
discussing
and
then
there's
an
auto
draft.
H
H
We
dropped
encrypted
only
messages
case,
as
well
as
any
other
cases
that
are
not
signed
only
and
signed
and
encrypted,
and
we
update
obfuscation,
recommendations
as
per
mailing
list
and,
as
I
mentioned,
dkg
is
now
a
co-author,
and
the
draft
will
substantially
change
in
the
next
version.
Next
slide,
please
so
the
issues
we
discussed
last
time.
I
just
going
briefly
through
that.
You
know
what
the
state
is.
After
the
last
discussion,
these
backwards
compatibility,
things
are
still
open.
H
Protection
levels
is
closed
as
we
are
limited
to
signature
only
and
encrypted
and
signature
or
the
other
way
around
basically,
and
on
the
receiving
side
we
may
need
to
document
auto
use
case.
Basically,
this
is
a
different
story
than
the
sending
side.
Then
the
mind
format
is
still
open.
We
will
have
a
discussion
in
the
next
section
of
this
presentation.
Next
slide.
H
Then
we
also
changed
obfuscation,
header
fields.
We
took
out
the
suggestions
for
obfuscating
date
from
two
and
all
the
stuff
and
what's
left
this
subject
and
message
id
though
message
id
is
still
under
discussion
and
this
will
be
discussed
in
the
next
part
of
the
presentation,
rendering
messages
so
far.
We
discussed
that
we
rendered
the
inner
message
only
or
like
what
is
the
cryptographic
payload
or
whatever
is
in
the
new
terminology,
and
but
some
additional
information
should
be
made
available.
H
How
we
do
this,
it's
not
yet
clear,
but
this
will
be
a
thing
that
is
discussed
in
the
autodraft
guidance
for
end-to-end
encryption.
If
I
am
correct
here,
then
we
had
some
discussion
about
the
bcc
handling
and
we
can
close
this
one,
because
the
text
regarding
bcc
will
keep
minimal
in
this
document,
and
we
will
refer
to
other
comments.
H
E
Okay,
you
fine
great
so
bernie
and
alexa,
and
I
have
worked
a
bunch
on
this
draft
in
the
in
the
meantime
and
we're
gonna
try
to
tighten
it
up.
The
main
goal
is
to
get
it
to
focus
on
implementation
guidance.
I
think
the
the
issue
that
we
really
want
is
we
want
this
to
be
to
provide
a
set
of
pretty
clear
instructions
without
too
many
choice,
points
for
implementers
to
just
walk
through
and
said.
Am
I
doing
these
these
things
yep,
I'm
doing
them?
Okay,
we're
good
to
go.
E
One
concern
that
that
is
raised
here.
Is
you
know
the
user
agent
implementers
are
going
to
be
dealing
with
arbitrary
messages
that
are
out
there,
and
some
messages
are
going
to
be
in
possibly
different
forms,
because
there
are
two
main
schemes
of
header
protection
that
are
found
in
the
wild
and
we've
talked
about
this
in
previous
versions
of
the
draft
and
ultimately,
implementers
are
going
to
want
to
be
able
to
deal
with
either
scheme
that
they
encounter
and
it
turns
out
the
schemes
are
not
that
different,
but
they
are
different.
E
They're
subtly
different
one
of
them,
I'm
referring
to
in
this.
As
wrapped
message,
which
is
what
was
specified
in
s
3.1,
there
are
some
implementations
out
there.
There
are
some
messages
that
are
wrapped
in
that
way
and
the
other
form
is
injected
headers,
which
was
also
known
as
this
draft
autocrypt
protected
headers
or
a
memory
hole
specification.
E
E
It
also
needs
to
give
guidance
about
how
to
compose
them,
although
maybe
we
only
need
to
give
guidance
about
how
to
compose
one
of
them.
If
there's
a
clear,
a
clear
choice
for
what
we
think
implementers
should
do.
That's
an
open
question
I'll
talk
about
that
in
a
second
also
as
you're
encrypting,
a
message
there's
this
question
about
what
do
you?
E
How
do
you
obscure
the
headers
that
are
going
to
be
covered
by
encryption
and
I'm
proposing
here
a
formalization
of
that
called
a
header
confidentiality
policy
to
make
it
easier
to
talk
about
and
again
I'll
get
into
that
in
a
little
bit?
I
also
think
that
the
draft
is
going
to
end
up
growing,
a
bunch
of
test
vectors
and
some
analysis
and
comparison
of
the
different
mechanisms
available.
E
E
But
when
it's
submitting
a
message
there
will
be
some
choices
to
make,
and
we
think
that
the
draft
should
give
clear
guidance
about
what
to
do,
and
so
the
two
main
questions
are:
which
scheme
should
you
use
when
you're
composing
a
message
with
with
header
protection?
And
what
should
you,
if
you're
doing
an
encrypted
message?
What
should
the
header
confidentiality
policy
be?
E
So
I'm
going
to
go
into
those
in
a
little
bit
more
detail,
a
couple
slides
on
each
one,
and
so
you
know
I'm
going
to
be
posing
specific
questions
here
for
the
working
group.
Obviously
this
is
going
to
be
taken
up
on
the
list
eventually,
but
I'm
I
don't
claim
to
have
answers
to
these
things
right
now.
There
should
be
pretty
straightforward
questions,
but
the
answers
are
not
clear.
Yet
I'm
going
to.
I
have
a
proposal
about
ways
we
can
think
about
this
ways
to
ways
to
go
forward
but
no
specific
answers.
E
So
I
just
want
to
highlight
this
because
this
is
the
open
questions
that
we'll
be
working
on
as
the
next
revision
comes
around.
So
here's
the
two
header
protection
schemes
that
are
out
there
on
the
left.
We
have
the
wrapped
message
which
uses
this
message:
rfca
22.
Some
of
that
this
forwarded
equals
no
tag.
I
don't
know
if
anybody
was
on
at
the
dispatch
earlier
this
week,
but
it
was
discussed.
Maybe
it's
not
forwarded
equals.
E
No,
maybe
it's
some
other
mechanism,
but
basically
there's
this
one
wrapping
part
and
then
there's
the
the
embedded
part
that
has
the
headers.
The
bold
in
this
diagram
shows
you
where
the
protected
headers
live
within
the
cryptographic
payload
right.
So
this
is
here.
Regardless
of
what
kinds
of
cryptographic
protections
are
in
place.
You
have
the
cryptographic
layers
on
the
outside
those
form,
the
cryptographic
envelope
and
then
the
protections
arise
because
the
headers
are
present
inside
the
payload
and
in
wrap
message
they're
in
part
b
there
in
this
diagram.
E
There
is
a
weird
corner
case
for
for
an
encrypted
message:
that's
being
sent
to
a
client
that
isn't
going
to
be
able
to
read
that
isn't
going
to
know
about
injected
headers,
and
that
adds
this
legacy
display
part
which
is
a
way
of
just
sort
of
stuffing
an
additional
text.
Part
that
includes
the
headers
that
you
would
think
that
a
legacy
client
would
want
to
know
about
so
that,
for
example,
so
that
you
don't
hide
the
subject
from
them.
The
person
who's
reading.
E
The
message
can
still
see
the
subject,
even
if
they,
even
if
it
doesn't
sort
of
land
in
the
right
place
in
the
mail
user
agent.
So
it's
really
only
this
with
legacy
display
is
a
bit
more
complex
as
a
structure.
But
if
you
look
closely
you'll
see
that
I
j
and
k
in
that
legacy
display
are
the
same
as
d
e
and
f
in
injected
headers,
and
it's
just
about
using
multi-part
mix
and
text
playing
part
to
stuff
an
additional
display
field.
E
The
idea
is
that
an
implementer
who's
receiving
messages
that
look
like
this
can
detect
that
that's
a
legacy
display
part
and
avoid
rendering
it
entirely
because
they
already
know
that
they
get
the
headers
from
the
right
place,
which
is
part
g
or
part
d
in
the
without
a
legacy
display.
So
those
are
the
two
schemes
and
then
the
question
is:
how
are
we
going
to
choose
at
composition
time
or
when
at
implementation
time
which
of
the
two
schemes
we're
going
to
recommend?
E
So
what
you're
seeing
here
is
a
chart
that
I'm
proposing
that
we
need
to
fill
in,
hopefully,
as
a
group
that
describes
different
scenarios
for
message,
composition
and
sending
and
receiving
to
think
about
the
header
schemes.
So
the
vertical
axis
here
is
protections
is:
is
what
kinds
of
protections
you're
applying
to
the
composed
message
right?
Is
it
signed?
E
Which
type
of
signature
form
is
it?
Is
it
signed
and
encrypted?
As
bernie
mentioned,
we
are
not
going
to
deal
with
the
case
where
you're
just
sending
an
encrypted
message.
We
think
the
draft
should
be
should
encourage
basically
only
one
of
two
choices
signed
only
or
signing
encrypted
on
the
receiving
side.
E
Of
course,
lack
of
signatures
or
signature
validation
failures
mean
the
receiver
is
going
to
need
to
deal
with
messages
that
are
encrypted
but
have
no
valid
signature,
but
at
the
generation
time
you
really
there's
only
two
sort
of
choices
signed
encrypted
versus
signed.
Only
of
course,
there
are
two
different
kinds
of
signed
only
in
pkcs7,
but
anyway
the
horizontal
axis
here
is
whether
what
we
think
the
recipient
mail
user
agent
can
do
now.
E
That's
the
green
columns
on
the
right,
and
we
want
to
think
separately
about
how
do
these
male
user
agents
render
the
message
and
also
how
do
they?
How
do
they
behave
when
you
reply
to
the
message?
Because
that
might
be
different
as
well,
and
so
in
the
yellow
column,
on
the
left,
we're
talking
about
male
user
agents
that
have
that
are
legacy,
clients
that
have
no
cryptic
capabilities
whatsoever
and
in
the
blue,
we're
looking
at
legacy.
Clients
legacy
just
meaning
they
don't
implement
header
protection,
but
they
do
have
cryptographic
capabilities
already.
E
They
have
the
standard
cryptographic
capabilities,
but
they
don't
understand
this
header
protection
thing.
I
think
that's
the
majority
of
all
the
male
user
agents
that
have
crypto
right
now,
and
so
those
eight
boxes
that
are
in
there
that
are
unfilled
in,
I
think,
are
the
things
that
are
going
to
make
a
difference,
because
the
ones
that
are
already
filled
in
should
be
the
same.
Regardless
of
header
protection
scheme.
Right,
you
get
unreadable
messages
in
the
four
boxes
in
the
lower.
A
E
If
people
have
concerns
about
this
as
an
evaluation
scheme
where
they
want
to
suggest
additional
nuance,
I'd
be
happy
to
hear
it
both
now
and
on
the
list.
But
just
so
you
know
this
is
sort
of
where,
where
I'm
thinking,
we
need
to
go
to
evaluate
which
scheme
to
recommend
so
not
seeing
anyone
in
the
queue
I'm
going
to
go
ahead
with
the
next
section,
that
was
header
protection
schemes,
different
header
protection
schemes
and.
E
E
So
this
may
mean
that
I
ask
you
on
the
list
to
like
try
out
your
the
mail
user
agent,
that
you
work
on
or
old
versions
of
the
mail
user
agent
that
you
work
on
or
the
mail
agent
that
you
use
and
if
you
want
to
just
you
know,
give
give
some
feedback,
you
know
say:
hey
I
tried
and
it
looked
this
way,
it'd
be
cool
to
to
get
that
from
from
people
on
the
list.
So
I
hope
people
will
consider
doing
that.
E
E
E
So
this
is
just
a
simple
way
that
if
you're
an
implementer
or
you're
a
researcher,
you
want
to
document
how
header
protection
can
work
or
should
work
in
the
future.
You
can
say:
hey
here's,
the
new
header,
confidential
confidentiality
policy,
the
new
hcp.
I
think
we
should
use-
and
we
can
test
that.
E
So
let
me
just
show
you
two
example
hcps
that
I
think
are
candidates
for
what
we
recommend
here,
but
there
are
obviously
you
know.
This
is
a
function.
The
function
space
could
be
arbitrarily
large.
There
are
other
ones
you
could
imagine,
but
here's
two
to
consider
so
the
first
one
on
the
left
is
called.
We
just
named
it
hcp
minimal,
and
it
basically
says
we
look
at
the
headers
that
are
going
to
go
on
the
inside
of
the
you
know.
The
header.
E
E
If
it's
a
subject,
we
we
obscure
it
in
the
same
way
that
http
minimal
obscures
it.
If
it's
a
message
id
we're
going
to
generate
a
new
message
id
on
the
outside
and
all
other
headers
we're
going
to
completely
strip,
so
there
will
be
no
other
headers,
as
the
messages
in
you
know
is
injected
into
the
mail
system
by
the
mail
user
agent.
There
will
be
no
other
headers
on
the
outside.
E
Besides
from
to
cc
date,
subject
and
message
id
where
subject
and
message
id
are
obscured
in
the
ways
defined
here,
this
function,
new
message,
id
just
means.
However,
the
mail
user
agent
would
generate
a
message
id
just
do
it
again,
so
you've
got
one
on
the
inside
and
you've
got
a
different
message
id
on
the
outside
and
everything
else
gets
stripped.
H
E
H
I
Russ,
sorry,
I
just
put
up
the
hand.
Maybe
can
I
just
speak
quickly
sure
go
ahead
from
me
being
both
as
mime
implement
as
well
as
I'm
a
client
implementer
the
positive
thing
about
threading.
You
can
thread
methods
without
downloading
them
in
full,
so
not
being
able
to
thread
them.
Would
you
know
if
you
have
to
download
all
the
messages
before
you
can
thread
them?
That's
way
more
bandwidth
way,
more
cpu
power
and
stuff,
like
that.
G
B
Yeah,
the
only
thing
I
wanted
to
mention
here
is
I'm
maybe
showing
my
former
mathematician
roots,
but
there's
an
implicit
assumption
here
that
your
htc
function
works
on
a
header
by
here
header
basis,
and
I
think
it's
a
correct
assumption
that
there
isn't
a
hcp.
We
would
want
to
think
of
that.
That
doesn't
work
in
that
manner.
But
that's
one
of
the
this
one
of
the
drawbacks
of
this
mathematical
model
that
you
have
here.
E
Yes,
so
there's
a
number
of
sort
of
sneaky
implicit
assumptions
in
the
hcp
as
it's
defined
here
and
if
we
find
that
those
assumptions
are
are
un,
are
you
know
problematically
wrong,
I'm
fine
with
trying
to
refine
how
we
do
how
we
declare
in
hcp.
In
addition
to
what
tim
mentions
it
also,
the
function
is
the
benefit
of
being
sort
of
stateless,
in
that
it's
probably
not
supposed
to
like
keep
track
of
what
other
scrubbing.
It's
done.
E
It's
not,
it
doesn't
appear
to
be
ordered.
It
doesn't
appear
to
have
there's
no
other
inputs,
like
other
special
information
that
maybe
the
header,
maybe
the
mail
user
agent,
happens
to
know
at
message.
Composition
time.
So
it
is.
It
is
actually
a
fairly
constrained
space
to
do
the
reasoning
about,
and
if
people
come
up
with
proposed
hcps
that
require
a
different
function.
Signature
then
you
know
we
can
talk
about
them
and
we
can
talk
about
changing
the
signature
of
it.
Just
you
know
like
new.
H
E
One
additional
note
about
the
hcp,
which
is
awkward,
is
that
the
implementer
of
the
hcp
is
the
sender,
but
the
person
who
is
affected
by
it
in
terms
of
server-side
threading,
for
example,
is
the
recipient
and
it's
possible
that
you
need
some
sort
of.
I
don't
know
signaling
mechanism
between
male
clients.
That
says
I'm
fine.
If
you
want
to
use
hcp
strong,
for
example,
so
again
I
can.
E
C
At
least
you
know
it
hasn't
had
it
hasn't
been
the
wild
success
that
we
hoped
it
would
be
and
other
things
that
were
put
in
there
are
like
whether
compression
was
supported
stuff
like
that.
So
I'm
just
not
sure
whether
putting
a
adding
a
clause
to
the
s
mine
capabilities,
for
which
hcps
you
prefer
is
is
would
be
any
different
than
what
you
just
suggested.
E
C
E
E
I
just
want
to
give
people
a
heads
up
if
you're
a
male
user,
agent,
implementer
and
you're
thinking
about
these
questions.
You
know
I'd
love
to
hear
your
feedback
on
how
you
would
solve
the
problem,
but
so
here's
an
example,
the
sender,
some
you
receive
a
message
from
someone
who
use
a
stronger
hcp
than
you
would
use
by
default.
E
When
you
reply
to
their
message,
you're
going
to
stuff
some
stuff
in
header
fields
that
they
would
have
obscured,
but
you
didn't
now,
we
all
know
that
replying
to
an
encrypted
email
in
the
clear
is
pretty
bad
form
and
you
don't
want
your
mail
user
agent
to
be
the
one
that
does
that.
So
how
do
you
adjust
your
hcp?
E
If
you
receive
a
message
from
someone
with
a
stronger
with
with
a
stronger
hcp
than
than
you
have?
How
do
you
avoid
like
say
they
protect
the
they
pre,
you
know,
say:
they're
using
http
strong
and
they
strip
out
references
and
then
reply
to
and
they
mangle
the
message
id
but
you're
you
suggest
sending
using
http
minimal.
Are
you
going
to
end
up
leaking
all
of
their
references
tags
that
that
they
avoided
leaking
before,
like
that's
a
little
bit
weird
and
awkward?
E
Some
hcps
that
subtly
obfuscate
a
field
not
completely,
but
for
example,
you
know
when
I
send
a
message.
My
date
exposes
my
system's
time
zone
and
I
don't
need
to
do
that.
Why
do
I
need
to
send?
Why
do
I
need
to
expose
that
on
the
wire?
Maybe
I
want
the
recipient
to
know
what
time
zone
I'm
in,
but
I
don't
want
the.
E
I
don't
want
the
mail
transport
system
to
know
what
times
I'm
in
so
maybe
I
have
an
hcp
that
takes
the
date
and
just
translates
it
to
gmt
or
utc
or
whatever
we're
calling
it
these
days
right
or
maybe
it
takes
the
email
addresses
that
are
in
the
to
and
the
from
header
headers,
and
it
removes
all
the
display
names
and
just
puts
them
as
raw
email
addresses
in
those
headers
right.
So
these
are
subtle
obfuscations.
E
They
would
show
up
when
you're,
when
you're
looking
at
at
an
email,
they
would
show
up
as
being
things
that
don't
match
the
outside
of
the
envelope
doesn't
match
the
inside
of
the
the
cryptographic
envelope.
You
know
it
doesn't
match
what's
on
the
inside,
but
it's
not
like
it's
fully
confidential,
because
the
actual
date
is
still
there.
E
H
Yes,
just
a
remark
regarding
this
set
of
confidential
policies:
strong,
it's
basically
what
we
have
implemented
at
pep
and
we
are
only
using
the
inner
message
and
leave
the
auto
message
out,
but
sometimes
comparing
the
outer
and
the
inner
side
may
be
confusing,
as
you
mentioned,
but
I
don't
see
a
problem
with
the
http
strong
in
the
implementation.
Wise
question
is
only
like
what
we
do
with
implementations
that
do
not
implement
it
correctly
and
start
to
leak
data.
E
H
E
Well
but
yeah,
but
so,
but
so
the
way
the
draft
is
written
there
is,
there
are
no
decisions
to
be
made
at
receipt
time.
We
have
the
draft,
outlines
a
deterministic
set
of
ways
to
handle
the
message
and
of
course
you
know
implementers
who
haven't
implemented.
The
draft
won't
do
those
things,
but
there
are
no
choices
to
be
made
at
receipt
time.
It
is,
it
is
an
unambiguous
mechanical
process.
The
only.
E
Have
are
at
sending
time-
and
that
includes
you
know
so.
The
the
tricky
bit,
of
course
is
sending
time
that
involves
a
reply
right,
that's
where
the
subtleties
really
get
really
get
tough
but
but
yeah,
but
but
just
to
be
clear,
like
what
you
know
when
bernie's
saying
that
that
he's
implemented
that
pep
has
implemented
this.
E
I
think
what
you're
saying
is
that
pep
is
implementing
the
hcp
strong
for
sending
time,
and
maybe
that
means
bernie,
that
you
can
report
back
with
some
data
of
what
your
experiences
are
in
terms
of
sending
messages
like
that
to
users
that
have
male
user
agents
that
fall
in
one
of
those
different
categories
that
are
outlined
in
the
in
this
evaluation
slide
right
just
so
we
can.
We
can
talk
about
and
reason
about
how
that
goes.
H
And
yeah
yeah,
like
first
of
all,
I
was
referring
to
the
to
what
you
said
that
the
sender
makes
a
choice
that
has
an
impact
on
the
receiver.
That
was
basically
comment
about.
So,
of
course,
this
is
on
the
sending
side,
but
it
impacts
the
receiver
and
what
I
want
to
say
we
have.
We
have
a
system
in
place
that
didn't
cause
any
of
these
issues
that
we
observed.
That
doesn't
mean
that
they
don't
show
up
with
other
implementations,
but
that's
all
what
I
said
and
yeah.
E
C
A
E
Let's
see
here,
how
does
this
work,
something
like
that
yeah?
So
thanks
I'm
back,
so
I
don't
actually
think
russ
that
I
intended
to
say
that
we
must
recharter
just
that
it
occurred
to
me
that
maybe
chairs
think
we
should
recharter.
I
proposed
a
little
bit
of
oh
no,
you
know,
I
think
the
guidance
I
proposed
was
about
the
the
sample
certificates
anyway,
I'm
fine
if
we
need
to
recharge
her
to
do
this
like
that,
doesn't
particularly
bother
me.
E
E
So
let
me
just
give
you
a
quick
sense
of
what's
in
the
current
draft,
so
it's
got
like
these
concepts
like
cryptographic,
envelope
and
cryptographic,
payload
cryptographic,
layer
which
we're
using
in
the
header
protection
work,
but
those,
I
think,
are
useful
concepts
just
for
thinking
about
how
you
present
a
message
and
how
you
compose
a
message
as
well.
It
tries
to
outline
what
user
expectations
are
for
end-to-end
encrypted
email,
for
example,
users
are
looking
for
things
that
behave
like
email.
E
E
How
should
you
like?
How
should
you
think
about
structuring
it?
What
what
kind
of
indicators
should
you
give
to
the
user,
those
kind
of
things
and
then
room
for
other
pitfalls
concerns
like
common
traps
that
you
find
yourself
running
into
and
then
also
test
factors
like
I'd
love
to
see
some
examples
of
here
are
some
messages
that
people
typically
have
received.
E
E
You
know
encrypt
the
entire
mime
structure,
don't
have
some
subparts
that
are
encrypted
or
or
protected
in
one
way
and
other
subparts
that
are
protected
in
a
different
way.
Don't
render
a
failed
signature
similar
to
the
guidance
that's
in
dkim
right
like
let's
not
treat
a
failed
signature
as
worse
than
no
signature.
Just
don't
render
it
if
it's
not
there,
of
course.
That's
you
know.
Maybe
this
is
controversial.
Maybe
we
should
take
that
out.
This
is
my
my
perspective
right
now.
E
If
the
working
group
does
pick
this
up,
I
would
expect
to
try
to
get
working
group
consensus
on
this
stuff.
You
know,
as
bernie
mentioned
earlier,
like
we're,
encouraging
people
not
to
send
encrypted
but
unsigned
messages.
It's
just
a
corner
case
that
that
causes
weird
rendering
problems
on
on
the
receiving
side
so
forth.
So
so
this
is
the
kind
of
guidance.
E
So,
if
you're
interested
in
this
read
the
current
draft
contribute
suggestions,
there's
a
bunch
of
to
do's
there
and
you're
welcome
to
just
like
pick
one
of
those
out
of
the
to-do's
and
try
to
implement
it,
I'm
currently
working
on
it
in
markdown.
This
is
the
url
for
it.
Here
it's
get
lab
dkg,
e2,
email
guidance,
note
that
that's
gitlab
and
not
github.
E
So
I
would
like
to
see
lamps
adopt
this.
If
that
means
recharging,
I'm
fine
with
that,
I'm
fine!
Being
an
editor
for
it,
if
anybody
wants
to
co-edit
with
me,
that'd
be
great.
If
anybody
wants
to
replace
me
as
editor,
that
would
be
super.
I'm
always
happy
to
have
someone
else.
Do
the
work
that
I
thought
I
would
have
to
do
so
any.
I
just
think
that
we
as
implementers
and
people
who
care
about
protected
email
should
be
trying
to
talk
to
each
other
about
the
expectations
that
we
have
so
yeah.
E
E
E
E
C
E
C
J
I
don't
have
any
concerns
you
know
generally.
I
know,
there's
always
a
tension
with
how
broad
and
how
specific
we
do
things
in
this
working
group,
I'm
in
favor
of
always
a
little
more
general,
so
we
don't
have
to
constantly
recharter
and
I'm
good
with
ux,
because
that's
the
whole
other
part
of
security.
C
C
C
C
C
C
Well,
the
idea
is
to
replace
those
choices
with
something
that's
more
modern
and
so
the
proposed
replacements
after
a
little
bit
of
discussion
on
the
list,
are
the
mandatory
to
implement
being
shot
256
and
hmac
shot
256
at
a
should
aesgmac
and
my
first,
my
zero
zero
version
of
this
had
cmac
there.
That's
what
led
to
the
comments
earlier
that
gmax
seemed
to
have
a
little
more
support,
so
the
way
forward
would
be
to
do
a
working
group
call
for
adoption.
I
think
this
fits
within
the
current
charter
about
supporting
modern
cryptography.