►
From YouTube: IETF113-LAMPS-20220325-0900
Description
LAMPS meeting session at IETF113
2022/03/25 0900
https://datatracker.ietf.org/meeting/113/proceedings/
C
C
C
D
G
E
G
E
E
We
referenced
fur
to
further
documents
with
regard
to
random
number
generation.
We
did
open
the
ca
search,
support
message
to
also
transfer
trusted,
root,
ca
certificates
and
addressed
and
security
consideration
with
that
regard,
and
we
rolled
back
a
change
to
the
root
ca
updates
support
message
to
not
to
need
to
register
new
oids
next
slide.
Please.
E
I
didn't
get
feedback
yet
from
roman,
whether
the
rest
was
was
sufficiently
addressed,
but
coming
to
the
two
open
issues,
roman
suggested,
to
have
a
42,
10
bis
document,
though
the
cmp
updates
offers
quite
a
number
of
changes,
so
the
authors
are
open
to
do
so,
but
the
working
group
back
then
decided
to
go
with
this
cmp
updates
approach.
And
finally,
if
not
having
the
cmp
updates
approach,
we
would
also
probably
need
to
do
a
6712
bis,
because
there
are
also
some
updates
of
60
20
712
in
the
cmp
updates
document.
E
H
That's
we
don't
need
to
make
a
change.
We
just
need
to
explain
our
rationale
and
I
believe
the
rationale
is
exactly
what
what
you
said
and
what
we
talked
about
in
the
in
the
email,
which
is
historically,
that's
not
how
lamps
has
done.
The
updates
and
lamps
is
continuing
to
follow
the
the
same
path
it's
done
before,
and
I
can
use
that
to
discuss
that
in
the
isg.
C
Roman,
the
other
thing
is
that
we
thought
this
was
going
to
be
much
more
modest
when
we
started
okay
and
it
kind
of
grew
like
we.
We
took
the
opposite
approach
with
logo
types
where
we
actually
decided
to
do
the
bis,
because
we
we
wanted
to
merge
two
rfcs,
so
I
mean
I.
I
think
this
was
a
reasonable
decision
at
the
time
we
made
it
right,
and
I
think
it's
just
a
lot
of
work
to
to
get
from
here
to
abyss.
C
C
I
H
I
you
know
just
we're
having
the
conversation
with
this
good
and
for
me
you
know
the
resolution
of
this.
Let's
just
document
it
in
the
shepherd
right
up
and
I'll
have
this
in
my
back
pocket
that
we
talked
about
this
from
the
minutes
and
I'll
use
that
when
we
ballot
and
I'll
get
the
feedback
of,
why
didn't
you
do
the
best.
H
H
E
J
You
have
yeah,
given
it
so
coming
back
to
the
updates
and
these
documents
we
ended
up
in
similar
situation
right
pc.
Maybe
we
started
doing
dc
encapsulation
guidelines
and
implementation
notes
and
so
on,
and
then
we
realized
that
you
have
to
update
and
change
things
and
then
we
decided
it
actually
is
easier
to
make
a
piece
document,
because
it's
actually
it's
much
easier
for
implementation.
Where
everything
is
in
one
document,
you
don't
have
to
go.
Oh
yes
implement
this,
but
you
always
have
to
implement
everything
in
it
here
and
and
that's
so.
J
E
Yeah,
so
I
had
a,
I
had
a
look
into
the
4210
and
6712
and
talked
to
the
rfc
editors
and
got
some
yeah
some
kind
of
xml
version.
So
what
what
the
authors
think
we
could
could
offer
is
just
providing
an
xml
having
all
the
changes
done
as
discussed
in
cmp
updates
and
that's
it
so
that
would
be
kind
of
a
reasonable
update
or
a
reasonable
effort
going
through.
All
of
the
sections
in
cmp
updates
is
probably
more
that
what
we
plan
to
do.
L
Michael
richardson,
so
I
think
that's
a
great
idea.
The
problem,
I
think
I
I
understand
is
that
I
don't
think
that
the
work
that
we're
doing
here
is
simply
is
simply
removing
things
that
we
didn't
implement
before
and
the
stuff
that
I
think
you
are
doing
is
new
work
that
we
won't
have
a.
We
won't
be
able
to
point
to
two
years
of
interoperation
or
something
like
that
to
be
able
to
get
to
that.
D
L
L
It
would
also
be
good
that
we
could
rip
out
stuff
that
we
never
used
when
we
go
to
internet
standard,
and
that
would
also
be
a
good
best
thing
if
we
can
get
rid
of
20
of
the
document.
That's
stuff
people
don't
have
to
review
so,
but
I
don't
think
that
we
can
do
that.
I
just
would
be
a
lot
nice.
I
just
don't
think
we
can
get
there.
H
H
J
So
so
one
more
comment
also,
if
I
understand
correctly,
we
can
go
to
the
enter
standard
later.
If
we
have
a
beast
document,
if
you
actually
do
this
document
and
then
we
have
implementations
and
after
two
years
we
when
we
are
ready-
and
we
notice
that
nothing
has
to
be
changed,
we
can
then
go
to
data
standard
without
making
a
new
rfc
at
all.
E
Yeah,
so
with
regard
to
readability
for
implementers
with
all
the
erratas
and
the
changes
implemented
or
proposed
in
cmp
updates,
it
would
definitely
be
much
easier
to
have
a
best
document,
but
yeah.
As
I
said,
my
approach
would
be
to
really
just
just
do
the
changes,
as
discussed
in
cmp,
updates
and
and
not
like
michael
also
said,
stripping
off
20
of
the
text.
That
would
be
just
resetting
the
effort
and
and
kind
of
starting
over
again,
and
I
yeah
don't
think
that
this
is
what
is
yeah
planned.
D
C
E
E
So
the
second
point,
as
I
said
it
came
up,
was
brought
up
by
ben
during
the
cmp
over
co-op
review
and
as
as
pointed
out,
the
the
past
segment
that
is,
implementation
specific,
pointing
at
a
c
certificate
profile
to
be
used
for
the
enrollment
or
a
ca
to
be
addressed
in
the
past.
In
between
of
the
protocol
portion
and
the
operations
portion
like
like.
Here,
we
see
the
arbitrary
label
in
between
est
and
simple
enroll
or
in
the
cmp
example,
between
cmp
and
the
initialization
operation
portion.
E
M
Go
ahead
yeah,
I
guess
the
the
short
explanation
here
is
that
the
well-known
path
is
designed
so
that
there's
parts
of
the
uri
namespace
that
are
under
the
control
of
the
protocol,
because
by
default,
the
ui
paths
are
in
the
control
of
the
site
operator
and
it's
perfectly
reasonable
for
us
to
say.
Okay,
we've
got
this
well-known
stuff,
that's
part
of
the
protocol,
but
we
want
to
redelegate
some
of
that
back
to
the
operator.
M
But
my
concern
here
is
that
we
should
not
re-delegate
all
of
it
back
to
the
operator,
leaving
us
stuck
without
any
path
for
expansion.
If
we
need
to
make
new
parts
of
the
protocol-
and
so
I
don't
object
to
having
this
sort
of
arbitrary
label
or
profile
label
present,
I
just
think
we
need
to
make
sure
we
do
it
in
a
way
that
we
retain
a
scope
for
expansion
in
terms
of
parts
of
the
path
that
are
under
the
control
of
the
protocol.
M
Still
so
the
easiest
way
to
do
that
would
just
be
to
add
another
sort
of
sub
component
that
prefixes
what
these
arbitrary
labels
will
be,
and
we
were
sort
of
only
delegating
that
subtree
back
to
the
site
operator,
but
there's
a
bunch
of
other
ways.
We
could
imagine
leaving
us
room
for
future
protocol
expansion.
E
Maybe
next
slide,
so
we
discussed
with
also
some
some
ways
to
move
forward
here.
So
number
one
is,
as
we
specified
it
today.
Number
two
is
kind
of
if
we
move
have
to
move
away
from
that
to
do
it
in
the
in
the
query
component
of
the
uri
to
specify
the
certificate
profile
here
this
example
shows
if
you
want
to
enroll
to
a
local
domain,
and
you
want
to
specify
that
you
want
to
enroll
the
ldf
id
certificate
profile,
then
you
could
could
do
it.
E
E
The
third
approach
is
to
switch
the
operations
label
and
the
profile
label,
but
yeah.
That
seems
not
to
be
that
the
logical
order
and
the
fourth
option
is
to
to
move
away
from
that
well
known
at
all,
but
that
is
also
something
the
authors
would
yeah
did
wouldn't
like
to
do
so.
Yeah
ben
you
proposed
additional
options.
I
didn't
fully
get
them.
G
M
M
Like
that,
so
my
proposal,
like
currently
we've
got
done.
The
bottom
line
is
the
well-known
cmp
profile
label
initialization,
and
I
was
saying
that
we
could
do
like
that.
Well
known,
slash,
dmp
and
then
add
a
new
path
component,
but
call
it
p.
So
we
would
do
well
known
cmp,
slash,
p,
slash
profile
label,
slash
initialization
and
adding
that
extra
like
p
path
component
or
whatever.
We
want
to
call.
It
is
a
signal
that
the
stuff
after
it
is
a
protocol
or
is
a
profile
label
followed
by
the
rest
of
the
stuff.
So.
L
I
L
So
just
the
the
profile
in
this
case
is
called
profile
label
right.
Just
so
everyone
knows.
That's
not
a
literal
and
and
ben
is
suggesting
that
it's
a
cnp,
slash,
p
slash,
you
know
profile
label
and
then
I
don't
understand
how
initialization
is
not
the
label
myself.
But
I
guess
it's
initialization.
Oh,
that's!
That's.
L
I
think
we
have
a.
We
have
we've
discussed
this
a
lot.
We
know
we
have
a
discovery
problem
here,
but
but
we,
but
I
think
that
in
many
cases
that
essentially
someone
else
is
going
to
say
you
know
for
for
light,
bulb
systems
that
that
the
following
profiles
are
in
process
and
that
there's
no
no
discovery.
You
can
go
forward.
One
slide
again.
L
So
I
don't
like
number
two,
I
don't
like
queries,
but
other
than
that
I
have
no
particular
choice.
I
just
wanted
to
say
that
I
think
the
query
makes
it
more
difficult
than
anything
else
and
we
can
put
the
slash
p
or
whatever
it
is
we
want
to
put
in
in
their
bin.
I
think
that
I
think
that's
reasonable.
E
So
coming
to
cmp
algorithms,
the
authors
addressed,
I
guess
all
of
the
feedback
coming
from
the
working
group
after
112
and
from
the
area
director
review.
We
mainly
added
in
section
seven
a
table
showing
all
the
algorithms
and
sorted
by
by
their
cryptographic
strength,
and
we
got
a
very
valuable
feedback
from
quinn
and
his
colleagues
on
the
shake
and
kmac
and
yeah.
Also
on
the
table
itself.
We
added
some
security
considerations
and
I
yeah
and
we
managed
to
also
remove
the
pre-work
disclaimer.
E
H
E
Next
slide
is
on
the
status
of
the
lightweight
cmp
profile,
so
this
was
not
yet
reviewed
by
roman,
as
we
were
still
discussing
on
cmp
updates.
So
that
is
great.
We
will.
We
did
some
changes
to
the
lightweight
profile
since
one
one
two,
we
did
change
to
recommend
it
for
implicit
confirm
with
enrollment.
We
did
a
section
on
on
conformance
requirements
in
section
7.,
we
added
some
clarifications
and
we
aligned
with
the
changes
done
in
cmp
updates.
E
So
next,
so
open
points
would
be
also
to
to
address
and
implement
the
changes
on
the
dot
well
known
as
discussed
before
and
from
discussions
with
with
implementers.
We
got
some
some
feedbacks
that
clarification
on
error
message,
protection
and
the
section
7,
the
the
the
pki
management
operations
support
level
would
be
required.
So
we
would
like
to
do
that
and
yeah
afterwards
start
into
the
the
area
directory
view.
C
C
C
N
N
C
O
C
O
Yep
hi
this
is,
I
guess
I
can
need
to
update
the
the
link
there,
but
this
is
a
working
group
draft
for
a
new
extended
key,
so
just
for
document
signing
next,
the
draft
is
in
the
o2
version
was
published.
I
think
at
the
beginning
of
the
month,
then
it's
currently
in
working
group
last
call:
we've
received
some
comments
and
we're
going
to
address
those
before
being
done.
What
we
need
to
do
shocking
that
we
defined
an
extension
and
didn't
indicate
the
criticality.
O
O
O
C
C
The
big
change
in
this
document
was
to
get
rid
of
sha-1
and
say
where
a
hash
is
needed,
use
the
same
one
that
was
used
to
sign
the
certificate.
That
way.
We
won't
have
to
do
this
again
for
an
algorithm
change.
It
is
also
in
working
group
last
call.
We
have
no
comments
at
this
point,
plus
no
slide,
so
please
take
a
look
at
it.
Otherwise
we're
going
to
advance
it
to
the
isg
next
week
and
the
next
one
is
sean
again
for
the
clarifications
on
the
missed
curves.
O
C
I
O
O
So,
what's
in
this
id
right,
so
this
text
that
I'll
look
really
really
familiar
to
you.
It's
basically
another
version
of
the
5480
clarifications
that
was
published
in
rc
8813,
but
this
time
it's
for
the
edie
star,
algorithms,
the
other
draft
or
the
other
rfc
that
had
these
define
these
key,
that
the
keys
which
is
defined
for
this
particular
set
of
algorithms,
was
to
find
an
8410.
O
O
Oh
there
are
so
go
to
the
next
one.
So
there's
there's
this.
This
draft
is
so
short
that
I
think
I
put
the
whole
thing
in
these
slides.
So
basically
all
we're
saying
is
we
added
some
text?
You
know
the
first
two
were
already
there.
So
basically,
what
we're
adding
is
the
block
at
the
bottom,
which
basically
says
don't
use
any
of
the
digital
signature
related
ones.
O
So
we
just
made
those
must
not
kind
of
slam
the
door
on
those
and
that's
really
it,
because
if
we're
using
key
agreement
you
don't
use
in
you,
don't
use
key
and
ciphermen
or
data
and
cipherman.
So
it's
kind
of
just
straightforward.
Now,
if
you
remember
at
the
beginning,
I
asked
simon
why
they
did
this
and
basically
he
said
nobody
asked
for
it.
So
this
is
just
kind
of
like
fully
enumerating
all
of
the
possible
options
to
make
it
clear
to
people
the
things
they
shouldn't
do.
O
So
it's
basically
removing
ambiguity
next,
and
you
have
to
do
that
both
for
the
the
the
encryption
algorithms,
as
well
as
the
signature
algorithms.
So
it's
the
255
ones
and
the
x448
or
above
and
then
you
have
to
do
it
for
the
signature
ones
as
well.
So
you
have
to
do
it
for
the
ed255
and
the
ev448,
and
so
then
the
only
difference
is
you
have
to
do
it
for
the
e
certificates,
which
is
what
this
says
so
for
e
certificates.
O
O
O
N
O
I
I'll
look
usually
I
mean
to
be
honest,
I
think
most
people
that
are
sane
usually
don't
blow
this,
but
there
are
people.
I
think
that
sometimes
willfully
try
to
misunderstand
and
make
things
difficult.
So
this
is
mostly
just
trying
to
slam
the
door
on
that,
but
I'll
definitely
take
an
action
to
review
the
examples.
Draft.
N
O
You
shoot
me
that
link
if
you
shoot
me
the
link
for
the
off
48
thing.
I
can
look
at
it
like
before
the
end
of
today.
Yep
we'll.
Do
thanks
awesome
thanks
all
right,
so
lexi.
I
think
we're
moving
to
the
last
slide,
and
so,
since
you
guys
have
seen
all
this
stuff-
and
I
know
it's
just
an
oo
version-
I'm
actually
asking
for
a
working
group
last
call
now.
I
think
that
this
shouldn't
come
as
a
surprise.
It's
pretty
non-controversial
and
basically
we're
just
aligning
with
the
previously
published
rfc.
C
P
C
C
C
N
Hey
folks,
daniel
kahn
gilmore,
here
presenting
about
the
header
protection
draft,
which
is
work
with
bernie
and
the
lexi
and
myself,
where
the
the
editors
on
it
just
wanted
to
report
back
to
where
we
are,
I'm
gonna
give
a
brief
recap
and
then
talk
about
some
changes
that
have
been
made.
We've
made
good
progress
on
it,
it's
since
the
last
weekend,
so
that's
good.
N
So
to
recap:
when
we
were
defining
this,
there
were
two
different
schemes
for
header
protection
that
is
cryptographically:
protecting
the
headers
in
either
signed
or
encrypted
and
signed
emails.
The
type
that
was
specified
way
back
in
sm3.1
has
not
seen
much
deployment.
That's
the
wrapped
message
that
you
see
on
the
left
there
you
take.
The
these
things
are
the
cryptographic
payloads.
N
So
next
slide,
please
the
reason
that
we
weren't
really
satisfied
with
the
wrapped
message
is
that
for
one
thing
it
wasn't
widely
implemented.
There
were
not
a
lot
of
senders
that
actually
did
this
and
when
it
did
come
out
like
this,
a
lot
of
the
existing
clients
that
were
capable
of
decryption
would
present
the
message
in
a
weird
way.
It
might
look
like
a
forwarded
message.
N
N
They
would
be
invisible
to
the
legacy
clients
and
we
had
a
fix
for
that
in
the
previous
version
that
was
called
a
legacy
display
mime
part
that
stuffed
a
decorative
representation
of
the
message,
headers
that
were
obscured
into
the
message
body.
So
it
changed
around
the
the
cryptographic
payload
to
add
this
decorative
part
to
unobscure
to
to
to
unhide
those
header
fields
for
clients
that
don't
know
how
to
interpret
this
the.
N
N
N
What
we
do
is
we
modify
the
main
main
body
part
of
the
message,
that
is
the
text
plain
part
or
the
text
html
part
that
is
sort
of
the
first
leaf
of
the
message
itself,
and
you
can
see
here
how
the
this
is
a
text
plain
example
here,
where
you
did
we
just
dec?
We
just
add
this
legacy
display
element
directly
into
the
text,
plane,
part
next
slide
or
if
the
main
body
part
happens
to
be
html,
you
can
see,
we
add
it
in
this
particular
way.
N
Next
slide,
please
with
that
change
the
as
the
draft
authors
we've
made
some
decisions,
one
of
the
biggest
issues
with
the
draft
was
that
we
still
had
these
two
schemes
lying
around
in
it.
It
wasn't
clear
what
implementers
should
do,
and
here
we're
saying,
we've
made
a
decision
with
the
legacy
display
element
instead
of
legacy
display
mime
part.
We
believe
that
injected
headers
is
something
that
is
going
to
be
is
going
to
work
for
pretty
much
all
the
legacy
clients,
so
conformant
muas
must
be
able
to
generate
injected
headers.
N
We're
also
saying
that
conform
and
use
may
generate
the
wrapped
message
and
that
all
message,
you
know
the
receiving
message,
user
agents
or
mail
user
agents
must
be
able
to
consume
and
render
both
schemes.
In
practice.
We
have
not
seen
much
adoption
of
rendering
the
wrap
message,
but
we
think,
with
the
legacy
display
and
injected
headers,
that
even
male
user
agents
that
don't
adopt
know
that,
don't
that
don't
handle
the
rendering
in
a
deliberate
way.
We
think
the
legacy
ones
will
be
able
to
at
least
show
the
user.
N
What
they're
looking
at-
and
this
gives
them
an
incentive
to
step
up
their
rendering
and
parsing,
because
they
will
now
get
some
security
advantages
of
the
protected
headers
so
must
generate
injected.
They
generate
rap
message
next
slide.
Please
alexa
thanks.
So
the
way
that
we
got
here
was
a
meeting
of
the
design
team,
which
is
the
group
of
us
who
are
listed
as
editors
plus
hernani
from
the
pep
group.
We've
been
meeting
about
every
two
weeks
we've
been
working
with
the
git
lab,
so
we've
been.
B
N
Issue
tracking
and
merge
requests
and
things,
and
that
has
actually
been
pretty
productive.
We
welcome
anybody
else,
who's
interested
in
participating
to
join
these
meetings.
You
can,
let
us
know
either
directly
on
the
lamps
list
and
say
you're
interested
or
you
can
mail
one
of
the
authors
directly.
If
there's
anybody
else,
who's
interested
in
joining
we'd
be
happy
to
have
you.
N
We
are
particularly
looking
for
an
implementer
of
a
major
mail
user
agent,
in
particular
outlook
or
mail.app
who's
interested
in
this,
because
we
think
we
are
getting
pretty
close
and
we
would
love
to
have
one
of
the
major
male
user
agents.
You
know
an
implementer
from
their
way
in
so
if
anybody
who
is
currently
in
the
meeting
right
now
is
an
implementer
of
outlook
or
mail.app
or
knows
somebody
who
is
and
wants
to
get
in
touch
with
us.
N
N
N
If
you
can,
we
would
love
anybody
in
the
lance
working
group
to
help
us
take
a
look
at
these
again.
Take
a
look
at
them
with
your
mail
user
agent.
Take
the
sample
messages
and
route
them
through
various
mail.
Transport
agents
see
how
they
get
mangled.
What
happens
to
them
test
automated
systems
if
you've
got
things
like
mailing
lists
or
bug,
trackers
or
other
systems,
you
know
we'd
love
to
try
to.
G
N
N
So
a
couple
questions
for
the
working
group-
a
couple
I
think,
there's
five
in
this
deck
here.
You
may
recall
that
one
of
the
definitions
in
this
draft
is
the
header
confidentiality
policy.
So
just
a
quick
recap
about
what
that
is
when
you
are
sending
an
encrypted
email
message
and
you
want
to
do
header
protection,
not
every
header
is
going
to
be
secret.
N
We
had
a
couple
variants
in
the
draft
http
minimal,
which
basically
just
says,
protect
the
subject
line
and
here's
how
you
do
it
and
http
strong,
which
basically
says
protect
everything,
but
by
stripping
it
out
everything
but
the
from
to
cc
date.
We
obscure
the
subject
line
with
that
and
we
put
in
new
message:
ids
there,
the
design
team
we
have
sort
of
feeling
like
we
need
to
recommend
one
for
initial
implementers
to
do.
We
don't
want
people
to
have
to
make
hard
decisions
when
they're
implementing
this.
N
N
I
N
Predicting
the
subject
we
think
is
a
win
in
terms
of
confidentiality
next
slide
by
the
way.
This
is
our.
These
are
questions
for
the
working
group.
We're
just
you
know.
In
some
cases
we
have
some
ideas
about
what
we're
going
to
do,
but
if
you
all
have
any
particular
comments
that
you
want
to
make
on
these,
you
know
I
welcome
comments.
Now
we
could
also
have
questions
and
suggestions
afterwards
and,
of
course,
messages
to
the
list
would
be
great.
N
When
you
are
composing
a
message
using
injected
headers,
you
need
to
decide
whether
to
put
the
legacy
display
element
in
the
main
body
parts
as
described
earlier
or
not.
We
would
love
it
in
some
future
world,
where
all
male
user
agents
that
are
decryption
capable
are
capable
of
actually
dealing
with
protective
headers.
Like
this,
we
would
love
to
abandon
the
injection
of
legacy.
Display
elements,
that's
the
goal,
because
it
makes
things
much
simpler.
You
have
to
think
about
them,
but
the
question
is
how
how
do
we
get
there?
N
If
I'm
composing
a
message,
how
do
I
decide
whether
I
need
to
put
in
a
legacy
to
play
or
not?
The
draft?
Currently
is
silent
on
how
you
make
this
decision.
It
just
says
the
mail
user
agent,
you
know,
sets
a
boolean
flag
when
it's
doing
message,
composition
do.
I
include
legacy
or
not,
and
the
guidance
in
the
draft
I
think
currently
says
you
know
if
you
don't
know,
just
set
it
to
true
and
carry
on
so
there's
a
couple
different
ways
that
we
could
get
rid
of
legacy
display
elements.
N
N
If
we
at
some
point
in
the
future,
we
just
do
a
survey
of
all
the
decryption
capable
clients
and
we
say
you
know:
can
they
render
injected
headers
correctly
without
dealing
with
legacy
display?
We
don't
need
the
legacy
to
play
for
them
and
if
enough
of
them
say
yes,
then
we
update
all
the
clients
in
one
more
round
and
we
set
legacy
display
to
false.
N
Alternately,
each
recipient
could
try
to
sort
of
somehow
signal
that
they
can,
that
their
email,
user
agents
can
render
obscured
injected
headers
and
don't
need
the
lexi
display
in
that
case,
but
figuring
out
how
to
signal
what
specifically
the
signal
is
pretty
tricky
and
if
you
look
at
the
link
at
the
bottom
of
the
page
here
that
url
points
to
some
discussion
that
we've
had
about
what
what
would
be
some
of
the
drawbacks
of
signaling?
What
are
some
of
the
things
we
could
try
to
signal
ways.
N
N
So
one
of
our
concerns
about
the
legacy
display
elements
is
that
we're
not
sure
how
they
will
interfere
if
they
would
interfere
with
systems
that
do
command
processing
now
remember
legacy.
Display
elements
only
show
up
in
encrypted
messages,
so
this
might
only
be
relevant
for
an
automated
mail
system
that
uses
encrypted
messages
for
its
control
channel.
That
might
get
confused
if
it
sees
a
legacy
display
element
present.
N
There
are
not
a
lot
of
systems
that
we're
aware
of
that
are
out
there
that
do
this,
that
use
email
as
a
control
channel.
But
if
there
are,
you
know
we
want
to
know
in
particular,
the
schloer
mailing
list
is
an
encrypted
mailing
list
that
uses
pgp
mime,
not
s
mime,
but
the
systems
that
are
described
here
are
probably
relevant
for
both.
So
we've
done
some
outreach
to
the
folks
who
maintain
mailing
lists
like
schleter
and
mailman
bug,
trackers
and
looking
at.
N
If
there's
anything
else,
I
looked
at
joker.com,
which
has
an
email
interface
control
channel
for
the
dns,
but
they
don't
actually
use
any
mime
based
encryption
scheme.
They
just
use
pgp
signatures
inside
the
message
body,
which
has
all
kinds
of
other
problems,
but
we
can't
really
solve
that
here
anyway,
folks
know
of
automated
mail
systems.
It
would
be
great,
as
I
mentioned
earlier,
with
the
test
vectors
to
test
this
stuff
out.
N
N
We
think
this
is
relatively
straightforward
for
composing
male
user
agent
to
insert
that
is,
if
you're
making
the
message
and
you
recognize
that
you've
got
a
main
body-
part
that
is
of
type
text,
html
pretty
straightforward,
to
put
it
in
there,
and
we
think
it's
actually
pretty
easy
for
a
rendering
male
user
agent
to
omit
this.
If
it
needs
to.
We
have
an
example
of
some.
N
You
know,
css
snippet,
that
you
could
slap
into
your
local
css
file
for
rendering
mine
parts
if
they
are
tagged
appropriately,
but
we
also
are
aware
that
you
know
html
and
emails
may
have
some
issues
and
if
you
are
concerned
that
this,
this
div
being
injected
might
cause
a
problem
we'd
like
to
know
about
it,
we
haven't
found
any
case
where
it
does,
but
it
doesn't
mean
there
isn't
so.
We'd
love
any
feedback
from
your
working
group
on
if
they
see
this
as
an
issue,
next
message:
okay,
so
this
is.
N
N
We
think
that
a
male
user
agent
may
want
to
render
and
they
need
to
know
even
if
it
doesn't
render
it
the
cryptographic
status
of
each
particular
header
field.
That's
used
so
in
this
message.
This
is
an
example.
Here
you
could
imagine
that
this
message
was
sent
and
the
entire
message
all
of
the
headers
are
protected
by
the
cryptographic.
N
The
question
is:
how
does
the
rendering
male
user
agent
know
that
the
header
field
which
header
fields
were
encrypted
or
which
ones
weren't?
How
does
it
does
it
just
compare
them
with
the
outside
message
or
or
do
we
need
something
else?
The
current
text
in
the
draft
says
that
we
mark
that
header
field,
where
the
cryptographic
status
that
includes
encrypted
when
the
protected
copy
of
the
field
doesn't
match
the
unprotected
copy.
N
But,
as
we
all
know,
the
unprotected
copy
of
these
message,
header
fields
can
change
in
transit.
That's
why
we
want
these
cryptographic
header
protections
and
we
haven't
really
defined
what
counts
as
a
match.
So,
for
instance,
if
white
space
changes
does
it
count,
does
it
mean
now
they're
different
and
we
should
treat
it
as
encrypted
michael,
I
see
you
in
the
queue.
L
Michael
richardson,
so
I
I
it's
a
your
ui
is
not
terrible.
I
was
gonna
say
your
example
would
be
actually
good
if
alice
was
emailing.
Bob
and
frank
and
frank
wasn't
someone
who
knew
how
to
validate
the
the
do
any
of
this
stuff
right
and
so
the
subject
is
that
frank
sees
is,
of
course,
friday's
dinner
plans
and
thinks,
oh,
I
won't
go
on
thursday
I'll
go
on
friday
and
some
you
know
attack
on
him,
and
so
I
think
that's.
N
That
that
would
be
that
would
be
an
attack
on
the
on
the
signature
status
right,
which
is
different
here,
we're
talking
specifically
about
whether
the
header
field
has
been
successfully
obscured
or
not.
But
but
but
I
agree
with
you
that
there
is
a
separate
attack
on
the
message.
Signature
and
bob
frank
would
need
to
update
his
mail
user
agent
to
be
able
to
get
the
verification
on
the
headers.
L
So
so,
but
the
point
is
I'm
trying
to
say
is
that
bob
would
get
a
a
notice
that
says
that
the
subject
does
not
match
right.
That's
the
goal
here,
because
bob's
actually
done
bob's
actually
done
done,
is
validating
all
of
this
and
realizes
that
there's
something
going
on.
Frank,
of
course,
is
oblivious
to
this
because
he's
just
using
you
know
his
some
old
web
mail
system.
L
L
N
Yeah,
so
the
concern
that
you're
raising
says
we
want
to
know
whether
the
message
headers
were
tampered.
The
outside
message.
Headers
were
tampered
with,
because
we
want
to
make
sure
that
we're
you
know,
we've
got
the
right
ones,
but
we
want
to
know
if
the
one
outside
was
tampered
with.
We
currently
don't
have
any
cryptographic
status.
That
indicates
that
and
the
reason
we
don't
have
it
is
because
if
your
mail
user
agent
can
show
you
the
correctly
signed
message,
then
it
including
the
correctly
signed
headers,
then
it
will
and.
I
N
And
doing
the
kind
of
debugging
that
says,
hey
somebody
filled
with
the
thing
on
the
outside
is
not,
I
think,
for
normal
users
to
to
worry
about
right,
like
if
you,
if
you
say,
hey,
warning
this
thing
changed.
It
makes
the
message
look
even
worse,
when
in
fact
you
have
better
security
properties
and
people,
you
don't
want
when
you're
sending
a
message
it
just
show
up
flagged
just
because
somebody
filled
with
it
going
through.
The
issue
that
this
is
trying
to
raise
here
is
specifically
about
obscured
headers
during
message
description.
L
N
Right
and
in
particular
the
the
concern
here
is,
if
the
sender
obscures
the
subject
by
replacing
it
with
the
square
bracket,
dot
dot
square
bracket,
which
is
the
recommended,
you
know
http
minimal
mechanism,
then
obviously
the
subject
has
actually
been
protected,
because
the
only
thing
on
the
outside
of
the
message
is
a
dot
dot
dot,
but
it
could
be
that
the
sender
did
not
obscure
the
subject
at
all.
Maybe
they
used
some
sort
of
hcp
null.
That's
like
hey
we're.
N
You
know
we're
going
to
protect
everything
from
signature
wise,
but
we're
not
going
to
bother
obscuring
anything
but
some
outside
male
user
agent
injected.
You
know
star
star
spam,
star
star
in
the
subject
line,
and
now
they
differ
right
or
it
re-wrapped
the
subject
line
now
they
differ.
Do
we
claim,
then,
that
it
changed
that
that,
because
those
things
differ,
it
must
be
encrypted.
You
know,
technically
it's
not
a
match
anymore
deb.
I
see
you
in
the
land.
I
N
N
Right
and
that's
the
that's,
the
recommended
header
confidentiality
policy
right.
We
have
this
header
configuration
this.
The
http
in
the
draft
says
when
you're
composing
a
message.
You
need
to
decide
what
to
do
on
the
outside
of
the
message.
Based
on
what
what
the
original
message
headers
would
have
been.
N
Well
so
in
particular
we're
saying
look
when
you're
rendering
the
male
user
agent
probably
wants
to
know
which
message
headers
were
protected
with
what
kinds
of
protection
they
should
all
be
signed,
and
some
of
them
could
be
encrypted
and
signed,
and
how
do
you
tell
which
ones
were
encrypted
and
signed
when
some
of
them
have?
I
mean
obviously
they've
all
been
encrypted,
but
some
of
them
have
also
been
copied
to
the
outside.
It
doesn't
have
the
same
confidentiality
guarantees
that
people
expect.
I
Right
so
yeah,
so
I'm
going
to
make
a
comment
and
then
I'm
going
to
walk
away
so
comment.
Is
that
I'll
tell
you
that,
having
dealt
with
smi
messages
on
a
daily
basis
that
most
users
aren't
smart
enough
to
know
the
difference
between
signed
and
signed
and
encrypted,
let
alone
with
this
sort
of
level
of
detail
that
we're
talking
about?
I.
N
N
So
so
the
re
yes,
so
the
reason
that
we
want
male
user
agents
to
be
able
to
reason
about
these
message.
Headers
this
way
is
that
when
so
one
of
them
is,
you
could
imagine
some.
You
know
expert
mode
thing,
but
we're
not
going
to
get
into
the
expert
mode
thing
right
where,
where
you
really
do
want
to
show
this
a
user
wants
to
inspect
it
right,
you
could
imagine
that
most
people
will
never
use
it.
As
you
described.
L
N
N
But
the
mail
user
agent
might
want
to
know
which
message
headers
had
this
kind
of
protection,
because
it
might
be
relevant
for
for
dealing
with
the
message.
For
example,
when
I
reply
it
might
be
worthwhile
for
somebody
who's
implementing
a
message-
a
male
user
agent,
to
know
that
when
they're
replying,
these
headers
had
been
obscured
previously,
and
we
would
like
to
keep
obscuring
them.
N
The
question
here
is
when
the
mail
user
agent
is
reasoning
about
the
header
fields,
how
does
it
determine
that
this
header
field
was
encrypted?
That
is
actually
confidential
or
not,
and
the
text
currently
says
when
it
doesn't
match
the
unprotected
copy,
but
the
trouble
is.
We
know
that
the
outside
copy
can
change
in
transit,
go
ahead,
aaron.
Q
D
Q
D
Q
N
Yep,
so
if
you
take
a
look
at
the
git
lab
issues,
25
and
26,
there's
actually
a
proposal,
that's
very
much
along
the
lines
of
what
you're
recommending
aaron.
So
I
appreciate
you
taking
a
look
at
that
and
see
if
you
think
it
makes
sense
for
you,
that's
sort
of
the
conclusion
I
came
to
as
well,
but
I
wanted
to
raise
it
to
the
group.
So
we
could
hear
your
suggestions.
N
J
So
one
of
the
things
we
were
actually
pointing
out
there
saying
that
it's
actually
for
the
many
users
email
application
to
know
which
headers
are
you
know
encrypted,
and
so
is
that
you
were
saying.
Okay,
if
somebody
something
was
like
the
subject,
header
was
obscured
with
not
with
the
dot
dot
dot,
but
nothing
here
and
you
are
replying
it.
Do
you
actually
want
to
keep
the
you
know
the
previous
unobscured
version
that
that
was
clear
or
do
you
actually
want
to?
I
J
I
think
actually
and
of
course
we're
talking
about.
Yes,
we
don't
not
talk
about
user
interfaces,
but
we
actually
are
talking
about
to
the
implementers
who
are
implementing
these
things
and
if
we
don't
give
a
clear
instructions
to
the
implementer
saying
that
don't
do
this,
do
that
and
follow
these
rules.
They
are
not
going
to
be
they're
going
to
be
inventing
their
owns
and
which
means
we're
probably
going
to
have
a
mixed
issues
again
when
somebody
says
something
else,
and
somebody
does
some
other
male
implementation
that
then
we
have
a
legacy
legacy
legacy
display.
J
That
shows
you
that
the
subject
that
was
in
legacy
display
because
somebody
did
implemented
it
wrong.
So
I
think
we
have
to
be
very
you
know
strict
on
rules.
How
do
we
actually
say
we
are
talking
about
now
with
everything
trying
to
get
new
implementations
to
follow
our
rules,
so
let's
make
them
very
strict
on
what
they
say
that
do
this?
Don't
try
to
do
anything
else.
D
I
I
think,
if
I
can
interject
this
discussion
also
makes
me
think
that
yeah,
if
we,
we
probably
should
just
decide
on
rules
and
make
make
them
clear,
and
if
we
do
clear
rules,
then
people
will
implement
them
correctly.
If
we'll
allow
a
lot
of
leeway,
then
they
will
be
secondary,
interesting
side
effects
and
bugs.
So
actually,
I
think
dkg.
This
discussion
just
convinced
me
that
your
proposal
is
right.
J
I
J
Fail
wrecking-
and
I
think
this
is
something
that
would
be
probably
more-
you
know
in
scope
with
their
stuff
what
they
are
doing.
There's
lots
of
you
know:
mail,
vendors,
there's
there's
you
know
this
kind
of
people
who
actually
write
the
mail
clients
and
actually
write
the
mass
mail,
mailing
software
and
probably
sending
encrypted
stuff
banks
and
so
on.
So
I
would
actually
recommend
actually
taking
some
of
these
things
and
try
to
get
it
in
present
in
the
air
or
something
like
that.
N
N
C
E
N
There,
so
I
I'll
give
you
just
a
brief
overview.
I
don't
have
slides
for
the
e2
email
guidance.
There's
been
one
update
since
the
last
one,
which
was
just
defining
a
set
of
headers
as
being
user
facing
which
just
lists
things
like
subject
from
to
date
cc,
which
are
typically
presented
to
the
user,
as
opposed
to
the
other
message.
Headers
that
that
definition
of
you
know
what
is
presented
to
the
users
directly
is
useful,
turns
out
to
be
useful
in
the
cryptographic
in
the
header
protection
document.
We
haven't
done
much
else.
N
I
am
actively
reaching
out
to
mail
user
agents
and
systems
that
are
used
to
doing
you
know
cryptographic
end-to-end
protection
in
particular.
Well,
different
values
are
different
implementers,
I'm
reaching
out
to
them
privately
to
ask
them
for
their
feedback
and
thoughts
on
the
end-to-end
male
guidance.
So
hopefully
we'll
see
some
more
action
on
that
on
the
next
cycle,
but
that's
it
for
that
draft.
Unless
anybody
has
any
comments
on
it,.
C
L
L
No
there
we
go
yeah,
okay,
so
yeah,
so
it's
a
terrible
name,
so
please
suggest
a
better
name,
and
that
would
be
that's
the
most
important
ask
right
now
so
story
so
far,
so
we
had
a
conversation,
probably
last
summer,
probably
at
the
this
meeting
last
summer
we
wound
up
with
a
virtual
interim
meeting
at
the
end
of
august
to
talk
about
this
problem
and
I
put
the
links
there.
If
you
don't
know
about
it,
they're
recorded
the
and
we
formed
a
design
team.
L
We'll
tell
you
a
little
bit
what
the
problem
is
there,
but
that's
the
story
so
far,
and
we
don't
have
a
lot
of
progress
in
this,
but
I'm
going
to
talk
about
what
what
we
we
have
done.
So
the
fundamental
problem
does
that
work,
yeah,
okay,
so
this
is
your
viewer
viewer
caution
thing
there.
The
fundamental
problem
is
that
it
turns
out
that
a
number
of
us,
particularly
in
the
animal
working
group,
made
a
red
rfc
7030.
We
thought.
L
L
The
sn1
did
not
do
what
we
thought
it
did
and
so
now
they're
having
a
conversation
of
what's
going
on
fundamentally
what
we
need
to
be
able
to
do
as
a
an
est
client
in
anima,
but
in
other
things
as
well
is
we
need
to
be
have
the
the
registration
authority
say-
and
this
is
the
subject-
alt
name
that
you
shall
use
and
any
other
name
that
you
use
will
be
stricken
from
the
record.
Okay,
so
please
request
it.
L
Please
put
it
in
the
in
your
csr
request
and
that
that's
how
it's
going
to
work,
and
it
turns
out
that
we
can't
do
that.
We
can
say
things.
Things
like
please
use
curve123
without
specifying
the
actual
value
of
the
public
key
and
we
can
say
a
whole
bunch
of
things
like
that
about
that
kind
of
thing.
But
we
can't
actually
say-
and
you
will
put
this
value
in
the
attribute
you
request.
L
So
how
are
we
going
to
do
that?
So
one
way
is
the
the
kind
of
simplest
way
right
now
we
have
a
a
sequence
of
attribute
or
oid,
and
you
get
this
choice,
o
id
or
attribute,
and
this
part
in
the
middle
here
I
don't
want
to
use
my
hand
because
people
remotely
won't
see
it,
but
the
part
in
black
in
the
middle.
That's,
what's
there
right
now.
L
I
renamed
that
x,
type
and
x
attribute
simply
because
in
this
slide
to
to
make
it
less
confusing,
to
repeat
the
same
words
and
that's
what
we
have
right
now
and
we
seem
to
believe
you
see
it's
it's
it's
non-trivial
amount
of
asn
1.
and
we
seem
to
believe
that
the
x
x
attribute
actually
would
allow
us
to
put
a
value
in
there
and
we
actually
wrote
code
that
did
that
and
well
it
interoperated,
but
it's
wrong.
Okay.
L
So
this
is
the
simplest
version.
The
simplest
version,
I
think,
is
that
we
add
a
new
choice,
the
top
which
has
a
value,
and
then
we
have
this
new
structure
at
the
bottom,
which
you
see
now
has
three
three
elements
in
it
and
there's
a
thing
in
the
bottom,
which
is
put
the
value
that
you
want
and
I
think
that's
an
octet
string
in
the
end.
But
I
am
not
qualified
to
say
that
for
sure.
L
So
that's
one
version.
Okay-
and
this
is
this-
is
essentially
a
conversation.
Another
mailing
list
is
whether
it
was
upwards
compatible
or
backwards
compatible.
But
what
I
know
is
that
if
you,
if
you,
if
you
ask
for
if
someone
comes
along
and
asks
for
the
expects,
the
old
response
and
gets
this,
that
they
will
be
successfully
able
to
skip
it
and
ignore
it
and
not
understand
it,
which
may
make
them
fail
to
interoperate
to
accomplish
their
goals,
but
they
shouldn't
blow
up.
So
that's
that's
one
part
of
it.
L
O
The
end
I
just
I
just
want
to
say
that
I
think
we're
putting
a
lot
of
stock
in
the
rationale
that
you
have
and
the
example
in
70
30
did
not
include
a
value
in
the
attribute.
I
think
we
should.
I
think
we
should
just
fix
that.
If
you
look
at
the
the
thing
where
you
can
put
a
value
in
where
the
x,
the
attribute
thing
that
you
have
like,
there's
csr,
adders,
adder
or
oid
or
attribute
what
we
didn't
do
to
the
example
was
a
value
for
the
for
the
attribute.
L
O
I'm
thinking
it's
right,
we
just
the
example
was
just
wrong
because
it's
got
an
at
so
you
have
for
the
oid.
Obviously
you
just
include
the
oid
for
the
attribute.
What
you're
saying
is
you
want
to
provide
an
attribute
value
back
to
the
client
to
use
right
the
example
of
70
30
for
the
attribute
just
included
in
the
light,
and
not
the
value
which
is
incorrect
asm1.
L
O
L
Here's
here's
the,
I
believe
the
example
that
may
contradict
what
you're
saying,
which
is
that
you,
the
type
might
be
the
algorithm
yeah.
The
value
now
is
the
name
of
the
algorithm,
like
you
know,
esd,
cdsa
or
es256
right.
But
at
no
point
do
you
include
the
public
key,
which
is
the
value
of
that
thing.
O
L
O
Mean
it's
there.
It
does
because
in
fact
there
is
another
rfc
that
is
defined.
That
is
used
this
way
it,
which
is
you
know,
rfc
8295.
So
it's
it's.
I
wanted
to
provide
an
entire
pki
data
back
to
the
client
using
est
and
I
define
it
there's
an
attribute,
that's
defined
for
that
and
pkcs
whatever
it
is.
I
can't
remember
the
value
it's
like
a
pks
pdu,
so
you
can
slam
the
whole
thing
in
there
and
you
can
include
whatever
values
you
you
want.
You
can
actually
give
the
whole
csr.
P
L
O
What
I'm
saying
is
that,
in
the
examples
that
are
in
section
four,
whatever
that
there's
there's
one
for
just
an
oid
and
so
you're
right,
you
just
provide
the
challenge
password,
but
that's
the
only
order,
you're
just
providing
an
oid
which
is
saying
I'm
not
giving
you
the
value.
If
you
want
to
provide
the
the
value,
you
would
send
the
challenge
password
attribute
type
where
the
value.
O
L
L
L
G
C
D
R
First,
ietf
meeting,
so
it's
a
pleasure
to
meet
everybody
and
unless
I
understand
a
bit,
how
things
work
here
closer
to
the
mic?
Okay,
okay,
just
just
to
say
it
was
it's
my
first,
my
first
meeting
here
so
we
we've
been
working
in
this
area
for
a
while,
it's
going
to
go
into,
let's
say:
maybe
we
go
to
the
first
slide
essentially,
so
this
is
a
piece
of
collaborative
work.
Around
post-quantum
crypto
we've
been
very
active
in
this
domain
with
with
some
collaborators.
R
The
challenge
that
we've
seen
is
that
the
nist,
when
they
were
looking
at
standardizing
this
and
the
round
three
or
the
fine
this
should
be
announced
this
week.
Is
they
really
haven't
looked
very
much
into
how
keys
are
serialized
for
the
competition?
It
was
just
required
to
have
a
a
single
blob.
That
was
what
the
api
required,
and
so
there
wasn't
really
much
thought
put
into
managing.
R
You
know
how
keys
are
serialized
and
identified,
and
things
like
this.
It's
kind
of
a
lot
of
people
have
picked
up
on
it
to
say:
okay,
for
example,
you
can
I
not
having
to
look
at
the
keys
and
just
identify
it
with
oit.
It's
very
nice.
You
know
there's
no
more
passing
of
keys.
It's
simple,
however.
The
there
are
problems
with
that.
Sound
sounds
really
nice
in
theory,
but
I'll
come
on
to
why?
That's!
That's!
That's
not
not
a
very
good
practice.
R
If
we
look
at
the
structures
of
keys,
so
keys
they're,
it's
an
implicit
structure.
Now
that's
going
to
depend
on
whichever
of
the
algorithm
strengths
is
selected,
which
version
of
their
algorithm
have
been
lots
of
versions
already
going
through
the
different
rounds,
and
there
are
a
number
of
hardware
related
alternatives
proposed.
So
you
can
as
a
there's
a
lot
of
just
a
lot
of
different
algorithms
that
you
would
have
different
ids.
R
That
will
need
to
be
tied
to
some
form
of
keef
key
format,
so
lots
of
variants,
if
you
start
tying
those
variants
to
hybrid
schemes,
it's
just
a
combinatorial
explosion.
So
we
also
look
at
open
quantum
safe.
We
have
a
test
server
up
with
over
a
thousand
hybrid
quantum,
safe
and
and
classical
key
formats,
and
that's
only
a
fraction
of
the
ones
we
could
have
implemented
so
and
we
have
lots
of
problems
with
interrupt
testing
just
because
these
things
are
evolving.
R
These
things
are
in
the
field
and
we
just
need
to
figure
out
how
to
manage
the
complexity.
You
can
go
to
the
next
slide.
Please,
as
I
mentioned
it's
nice
in
theory,
to
have
an
implicit
key
format
tied
to
an
oid,
because
people
who
design
algorithms
that
they
they're
all
security,
then
they
say:
okay,
there's
no
passing
involved.
You
remove
all
of
the
passing
vulnerabilities
that
you
can
build
in
you
know
in
practice,
as
I
mentioned,
these
algorithms
are
deployed,
we've
been
deploying
quantum
safe
algorithms
for
over
three
four
years.
R
R
Perspective
is
really
important
and
that's
where
most
of
the
problems
are
so
actually
most
of
the
schemes
proposed
and
this
they
they
detail
compression
schemes
so
in
a
very
unstructured
way,
and
we've
just
found
in
practice
that
these
schemes
are
required,
so
so
we're
trying
to
avoid
a
bit
the
mistakes
in
in
the
past.
I
understand
it's
very
compelling
oid
key
format
very
simple,
but
we
know
that
we're
going
to
have
to
compress
keys.
R
We
know
that
they're
going
to
be
evolutions
of
algorithms,
and
so
what
we're
trying
to
do
is
design
a
format
that
that
handles
that
complexity
in
the
future.
Rather
than
take
the
simple
option
and
then
just
add,
then
these
exceptions
as
and
when
they
come.
That's
a
bit.
The
problem-
that's
happened
in
the
past,
with
with
other
algorithms,
you
can
go
to
the
next
slide.
Please
yeah.
L
L
R
L
I
R
S
R
O
R
So
let's
say
we
we're
contributing
to
some
of
the
candidates
and
most
of
the
candidates.
Certainly
the
ones
we
propose
to
are
all
ipr
free.
So
it's
less
about
the
compression
schemes,
it's
more
about
marking
or,
let's
say
the
the
framing
of
keys
or
let's
say
the
the
you
know
being
able
to
identify
when
you
have
a
compressed
key
and
things
like
this.
It's
not
not
how
these
things
are
compressed
more,
how
they
are
communicated
that
we're
concentrated
on,
but
certainly
what
the
the
the
key
compression.
R
O
I
think
I
think
I
think
nist
is.
I
just
want
to
say
that
the
last
time
that
this
came
out
was
for
elliptic
curve
stuff
and
one
of
the
reasons
why
no
one
would
touch
it
was
because
we
couldn't
get
good
terms,
and
so
I
think,
if
we're
going
to
adopt
a
scheme,
we
just
have
to
make
sure
that
we
understand
that
there
is.
There
isn't,
and
I
think
what
you're
saying
is:
it's
not
my
problem,
it's
whatever.
R
S
Yeah,
I'm
not
sure
this
is
the
right
way
to
go.
The
most
of
the
schemes
that
have
some
compressed
alternative
are
different
schemes.
They
are
not
compatible
with
the
uncompressed
version.
You
can
sometimes
do
all
sorts
of
things
with
secret
keys,
where
you
pre-compute
some
stuff.
You
can
expand
the
lithium's
matrix,
but
that's
all
on
the
secret
key
side,
and
I
don't
see
why
you
would
need
that
for
public
key
representation.
S
R
R
Yes,
of
course,
but
the
schemes
which
currently
look-
and
this
are
looking
at
the
compressed
alternatives
to
those
what
exception
of
rainbow
is.
They
are
just
artifacts
of
how
you
can
compress
the
keys
in
in
a
way
that
is
compatible
with
an
uncompressed
one.
So
you
have
a
trade,
a
trade-off
with
key
expansion
versus
key
size.
S
R
There's
two
things:
one's
being
standardized
ones
being
used,
so
there
are
a
lot
of
schemes,
including
rainbow,
for
example,
was
already
being
used,
but
and
also
dilithium
and
kaiba.
They
are
used
already
in
a
number
of
industries
things.
This
is
a
bit
the
problem
that
you
have
with
anything
that's
about
to
be
standardized,
because
standardization
takes
a
long
time.
They
still
they
start
to
be
used.
R
You
start
creating
legacy,
then,
in
order
to
manage
complexity,
you
you
end
up
with
standards
which
are
very,
very
evolve
very
awkwardly.
So
what
we're
trying
to
do
here
is
let's
say
for
this
aspect.
Look
at.
We
know.
What's
coming
that,
we
will
need
to
use
these
compressed
keys
which
take
out
of
the
equation.
It's
really
about
how
to
manage
those
appropriately
and
and
safely.
S
N
So
thanks
for
bringing
us
to
the
group,
this
is
daniel
gilmore.
So
it
sounds
to
me
like
this
is
just
about
private
keys
right,
we're
you're
in
this
presentation.
You
are
not
talking
about
trying
to
represent
public
keys
at
all
here
that
the
main
concern
you
have
here
is
about
private
key
representation.
Is
that
right.
R
N
An
issue,
but
we
can,
we
can
tackle
it
separately.
So
my
question,
for
you
is
this:
if
an
implementation
is
choking
on,
seek
private
keys
that
are
too
large,
presumably
that
implementation
doesn't
even
have
an
implementation
for
private
key
for
that
algorithm
because
it
can't
because
the
key
is
too
large.
N
R
N
R
I
N
N
G
B
P
R
Legacy
platforms,
I
mean
legacy
platforms,
not
systems,
so
so,
essentially
any
if
you
build
platforms
or
you
build,
you
know
systems
that
actually
you
can't
actually
manage
keys
just,
but
just
because,
because
they're
too
large
for
the
parameters
of
of
the
systems
and
the
protocols
you've
used
I'll
give
you
an
example:
I've
got
a
mainframe
platform.
Yeah
sounds
like
a
very
large
platform.
So
there's
a
lot
of
keys.
You
just
can't
use
just
because
you
can't
transport
them
securely,
they're
too
large,
outside
of
the
design
characteristics.
R
Yeah,
so
that's
the
goal.
Essentially,
I
mean
we've
seen
how
difficult
it
is
in
in
in
applications,
and
it's
really
about
making
sure
that
the
pqc
or
quantum
safe
algorithms
can
be
used
by
the
largest
number
of
applications,
and
that's
a
very
gonna
mean
a
lot
of
them
are
going
to
need
to
use
either
schemes
with
very
small
keys
and
there's
only
really
one
and
or
use
compressed
keys.
R
So
it's
it's
really
just
about
make
widening
the
aperture
for
for
four
systems
to
become
quantum
safe.
Actually,
the
approach
is
really
just
to
think
about
the
complexity
ahead
of
time,
not
go
for
the
easy
case
and
then
add
stuff
on
when
when
things
don't
fit
the
so
it's
really
about
also,
there
are
various
ways
to
actually
to
come
up
with
oids,
for
so
how
you
create
oids.
R
So
so,
in
terms
of
you
know
whether
the
whole
parameter
set
gets
represented
by
a
key
or
not,
I
mean
with
these
with
with
certain
of
the
lattice
schemes.
They
are
that
they
are
matrix,
so
you
can
actually
put
the
matrix
sizes
in
the
in
the
oids
and
things
to
simplify,
essentially
just
to
simplify
stuff
and
then
the
so.
This
is
the
identification
algorithm
approach
and
then
the
high
level
just
the
high
level
api
considerations.
R
Essentially
the
optional
choices
recommendations
for
when
you
would
want
to
use
a
compressed
key
format
and
when,
when,
when
not
what
the
trade-offs
are
stuff
like
this.
So
so
generally,
a
kind
of
like
a
guideline
for
the
the
usage
of
of
of
private
keys
in
in
in
in
a
kind
of
a
future-proof
way
for
for
for
next
generation.
Algorithms.
R
If
you're
using
the
older
keys,
you
might
want
the
ability
to
migrate
to
the
using
the
new
algorithm,
but
with
the
old
key.
That's
that's
very
difficult.
It's
very
messy
and
complicated
if
it's
just
an
in
an
implicit
serialized
blob.
We
have
shared
this
with
the
cryptographic
community.
We
have
received
feedback
from
a
lot
of
the
ski
mortars.
R
We
are
ourselves
authors
of
some
schemes
and
the
approach
has
already
identified
a
number
of
challenges
or
caused
actually
some
of
the
specifications
to
be
updated
because
they
weren't
particularly
clear
in
in
in
in
the
formats
of
private
keys.
So
it's
it's
already
a
couple
of
years
old,
this
this
work
and
I
think
we're
just
looking
for
the
best
place
to
give
it
to
to
sort
of
help
help
the
community
with
awareness
in
this
area.
R
I
think
next
slide,
please,
and
so
in
terms
of
what,
if
you
need
a
structure
to
be
able
to
manage
things
like
uncompressed
and
uncompressed?
It's
what
does
that
structure?
Look
like
what?
What
are
the
trade-offs
when
it
comes
to
complexity
in
passing,
obviously
we
want
anything
that
needs
to
be
specified
needs
to
reduce
any
potential
vulnerabilities.
R
N
It
seems
to
me
that
stateful
signature
schemes
would
require
even
more
infrastructural
overhaul
than
just
expanding
key
fields.
Key
sizes
right
are:
are
we
excluding
stateful
schemes
from
this?
Because,
if
staples
are
included,
then
it
seems
like
there's
gonna,
whatever
transport,
you
know,
plug-in
mechanisms
we're
talking
about
are
going
to
need
an
overhaul
anyway,
right.
R
That's
correct:
that's
a
scope
question!
So
again,
that's
up
for
up
for
debate
or
discussion.
It's
there
are
a
lot
of
complexities
because
of
you
know
the
feedback
mechanism
when
keys
are
used
you're,
absolutely
right.
It
is
another
layer
of
com,
complexity,
state
we're
using
stateful
hash
based
signatures,
but
really
open
to
whether
if
they
should
be
in
here
or
not,
it's
kind.
N
For
the
sake
of
not
touching
a
few
implementation
layers
just
to
widen,
to
widen
the
width
of
whatever
you
know,
wherever
those
limits
happen
to
be,
and
if
you're
going
to
have
to
why
you
know
tamper
with
those
infrastructure
layers
to
handle
stateful
keys
as
well,
then
I
I
would
prefer
to
have
less
complexity
in
the
interop
part
of
the
systems.
That's
just
my
observation.
R
Yeah,
yes,
yeah
complexity
will
come
like
I
said
the
aim
is,
is
to
manage
it,
you
can't
ignore
it
and
it's
a
very
good
point
with
the
stateful
hash
it,
because
this
is
this
adds
a
really
very
different
level
of
complexity.
So
this
again
is
a
scope
thing
very,
very
happy
to
sort
of
have
that
debate.
What
what
you
think
makes
sense,
but
you
will
not
get
away
from
complexity,
because
systems
will
need
compressed
keys.
R
F
Yes,
hello,
everybody,
so
maybe
that's
my
first
attendance
to
the
meeting
so
hello,
everybody,
I'm
julian
pratt,
I'm
working
for
kryptonite
security,
so
dealing
mainly
with
quantum
safe
algorithms,
and
my
question
is
about
the
opportunity
of
defining
all
the
compression
formats
because
I
get.
I
think
that
there
are
as
many
compression
as
there
are
implementations.
F
R
You
know
that's
how
it's
just
an
attempt
to
help
manage
that
journey
going
forward
and
what
you're
talking
about
is
scope.
So,
in
terms
of
when
things
change,
what
to
do
when
things
change,
I
mean
the
point
is
that
round
two
algorithms
around
three
algorithms
are
already
in
the
field
and
being
used.
So
so
it's
kind
of
these
things
already
need
to
be
managed
by
the
organizations
that
have
rolled
these
out
so
then
comes
along
a
a
kind
of
the
nist
standard.
R
Then
they'll,
be
probably,
I
suspect,
there'll
be
some
changes
in
the
parameters,
so
that'll
be
another
one
and
it's
kind
of,
and
I
suspect
after
that,
all
you
need
is
a
is
something
like
a
breakthrough
on
rainbow
where
the
lower
parameter,
lower
strength,
algorithms
get
broken,
and
then
you
need
to
ratchet
things
up
so
they'll
change
and
that's
kind
of
just
gonna,
just
gonna
amp.
Unless
you
manage
it,
it's
gonna
be
difficult.
That's
all.
I
think
we're
trying
to
communicate.
T
Okay,
okay
about
stateful:
this
is
scott
floor.
About
stateful
base
is
a
moving
key
private
keys
for
stateful
based
signatures.
That
requires
a
and
a
whole
bunch
of
other
problems
which
need
be
addressed.
I
believe
this
is
way
out
of
scope
for
this
draft.
It
would
actually
somebody
would
have
to
sit
down
and
work
out
all
those
issues
separately,
totally
independent
work.
Thank
you.
O
Sean
over
to
you,
so
all
right
so
hey.
So
this
is
an
individual
draft
that
I'm
requesting
the
working
group
to
adopt.
There
may
be
one
or
more
of
these,
because
this
is
specifying
the
algorithms
for
our
sorry,
the
an
rfc
5480
like
our
internet
draft
that
hopefully
will
move
to
rc
status,
which
specifies
how
to
put
post
quantum
chem
certificates
keys
in
certificates.
Next.
O
And
so
what's
in
this
right,
basically,
just
it's
actually
pretty
short,
there's
not
a
whole
lot
in
there,
because,
basically,
all
it's
specifying
for
the
pq
kim
stuff
is
the
format
for
the
subject
public
key.
So
it
says
you
know
what
oids
are
we're
going
to
put
in
there
we're
not
defining
any
we're
going
to
take
what
this
gives
us
parameters.
None
we're
just
going
to
use
an
oid
to
specify
whatever
the
two
security
levels
are.
Leave
it
at
that
we're
trying
to
learn
from
the
complexity.
O
That
was,
I
think,
hampered
the
deployment
of
elliptic
curve,
with
all
the
options
that
we
had
we're
just
trying
to
keep
it
simple,
the
key
format,
just
a
bit
string
again,
if
you
remember
the
elliptic
curve,
had
the
first
byte
had
some
weird
values
to
tell
whether
it
was
compressed
or
hybrid
or
whatever
we're
just
gonna
not
expose
that.
Let
the
crypto
let
the
crypto
standard,
specify
that
and
let
the
crypto
engine
deal
with
it.
O
Key
usages
just
set
one:
it's
only
one
that
really
applies
get
rid
of
everything
else
and
again
in
this
in
this
format.
This
is
this:
is
the
one
key
one
certificate
option?
Next
we
got
a
couple
of
questions
whether
to
do
one
or
all.
When
I
was
writing
this,
the
idea
was
that
we
were
going
to
put
all
the
pq
chem
candidates
and
then
the
last
time
we
talked
it
was
like.
O
Well
what
about
all
the
signature
candidates
too
panos
asked
me
he's
now,
one
of
my
co-authors,
I
guess
that's
something
else
I
should
mention
is
that
I
got
co-authors
that
actually
implement
stuff.
So
it's
not
just
me,
writing
it
so
panos
and
jake
from
aws
and
baz
from
cloudflare
to
look
at
this
stuff.
So
we
I
we
could
put
all
of
them
in
there.
We
could
put
one
and
panos
is
like.
O
Why
did
you
do
that,
and
I
said
well,
that's
kind
of
what
we
did
and
like
one
stop
shop
is
really
nice
and
but
that's
not
really
the
the
strongest
of
recommendations,
so
I
think
we
can
kind
of
take
it
to
the
list
to
decide
whether
we
want
to
have
one
draft
with
all
of
it
or
multiple
drafts.
That
would
allow
things
to
progress
differently.
O
C
So
I'm
glad
to
to
hear
the
use
one
away
to
define
the
algorithm
and
parameter
set
and
then
just
put
an
octet
string
with
the
key
in
it
that
seems
straightforward
and
is
going
to
eliminate
a
lot
of
the
silliness
that
we
had
with.
You
know
signed
bits
for
dsa
and
so
on
this.
This,
I
think,
is
a
good
good
thing
mike.
You
have
some
comments.
E
S
U
I
just
wanted
to
make
the
the
point
that
you
know
for
for
one
scheme
per
draft,
because
I
think
you
know
it's
easier
for
an
implementer
to
follow
and
comply.
You
know
it's
easier
to
review
in
the
in
the
list
and
also
you
know.
Camps
and
signatures
have
different
uses
right.
So
probably
it's
cleaner
to
have
them
separate
that
these
were
my
basic
arguments
for
cleaner
one.
One
draft
for
cam
one
draft
for
signatures
thanks.