►
From YouTube: IETF112-LAMPS-20211108-1600
Description
LAMPS meeting session at IETF112
2021/11/08 1600
https://datatracker.ietf.org/meeting/112/proceedings/
A
B
A
Okay,
let's
go
ahead
and
get
started
by
my
clock,
we're
at
the
top
of
the
hour
so
welcome
to
lamps.
This
is
the
last
session
for
today,
at
the
virtual
itf
meeting
and.
A
A
A
A
A
Okay,
hearing
none
we'll
turn
to
the
status
of
the
documents
that
are
with
the
rc
editor
or
the
isg.
The
first
one
is
lamps,
rfc
7299
update.
This
is
in
the
rfc
editors.
Queue.
A
There's
really
nothing
to
report
here,
therefore,
no
slides
the
it
is
really
just
registering
two
object:
identifiers
and
by
the
way
that
has
already
happened,
ayanna
assigned.
C
A
And
pointing
to
this
document
that
is
in
the
rc
editor's
queue
so
we'll
probably
see
an
rfc
out
of
that
in
a
month
or
so
we're
now
ready
to
go
to
the
cmp
algorithms
update
and
I
think
hendrick,
if
you'd
come
to
the
mic,
I'll
share
the
slides.
D
D
D
D
These
pki
management
operations
focus
on
managing
person
certificates.
That
was
the
main
focus
back
in
that
time.
For
example,
the
initialization
request
requests
for
a
signature
certificate
and
an
encryption
certificate
where
the
encryption
certificate
could
be
supported
with
a
centrally
generated
private
key,
and
these
profiles
use
encrypted
value.
Even
though
we
proposed
to
switch
to
envelope
data
for
providing
centrally
generated
keys,
we
thought
that
for
these
profiles
for
backward
compatibility,
it
it.
D
It
is
okay
to
stick
to
encrypted
value
here
and
therefore
the
section
7.1
uses
the
algorithm
identifiers
also
used
in
these
appendixes
and
are
also
focusing
on
usage
with
encrypted
value.
As
one
types
section
7.2.
D
Provided
or
are
introduced
in
lightwide,
cmp
profile,
lightweight,
cmp
profile,
utilizes
envelope,
data
for
transferring
centrally
generated,
keys
and
section
7.4
does
not
specify
any
mandatory
algorithm
sets,
but
just
explains
for
which
algorithm
identifiers,
which
kind
of
algorithms
from
this
document
could
be
used.
That
was
kind
of
decision.
We
took
last
itf.
D
Having
that
said
for
this
introduction
next
slide,
please
sorry,
one
step
back
in
rfc
4210
appendix
d2.
In
this
mandatory
in
this
algorithm
use,
set
for
from
rfc
4210,
some
outdated
algorithms
are
listed,
and
in
section
7.1
we
will.
We
propose
to
deprecate
use
of
some
of
these
algorithms
specified
in
in
4210,
especially
md5
and
char-1
should
be
deprecated.
D
Dsa,
I
think,
is
not
really
a
good
choice.
If
you
look
for
interoperable
implementations,
that
is
also
something
said
in
sp
800-57
part
3..
Therefore,
we
would
also
propose
to
to
deprecate
that
rsc,
rc5
and
cast
128
should
also
be
deprecated
from
our
point
of
view,
as
well
as
triple
des.
Even
though
usage
with
three
keys,
it
is
already
deprecated,
as
of
nist
sp
800
131,
a.
D
This
is
the
in
the
updated
introduction
of
section
seven,
so
roman
commented
that
the
current
section
seven
introduction
was
too
brief
and
not
clear
enough.
We
worked
on
that
and
I
even
provided
some
some
further
update.
So
in
this
introduction
we
said:
okay,
the
first.
D
D
D
D
So
this
could
be
one
table
to
add
to
section
seven
introduction,
which
kind
of
points
out
what
balanced
set
of
algorithms
could
mean
with
regard
to
cmp
usage.
D
F
That
that's,
that
will
be
especially.
F
A
E
G
D
D
Okay
thanks,
then,
we
will
go
ahead
and
I
would
propose
an
update
or
submit
an
update
of
cmp
algorithms
yeah,
hopefully
by
end
of
this
week,
incorporating
the
changes,
the
proposed
tables
and
would
be
happy
to
to
get
feedback
yeah
also
on
the
tables.
If
there
is
something
we
did
not
catch
or
specify
correctly,.
D
D
H
Can
you
hear
me
yes,
great,
there's
been
a
review
just
this
past
week
from
the
area
directors,
which
identified
a
few
minor.
H
I'm
actually
about
to
reply
to
that
on
list.
I
don't
see
any
any
concerns,
but
the
I
think
that
I
think
it's
moving
forward
in
the
larger
review
space
now.
A
Okay,
very
good,
all
right,
so
I
I
saw
that
there
was
one
I
don't
know
error
or
something
in
one
of
the
formatting,
but
good,
just
good
to
hear
that
we're
getting
more
eyes
on
it.
D
D
So
what
happened
since
last
itf
on
cmp
updates?
So
thanks
to
john
gray's,
yeah,
intense
review
and
very
valuable
comments
and
good
discussions
in
the
last
weeks,
we
yeah.
G
D
D
The
relevant
input
in
the
request
message.
We
also
changed
the
root
ca.
Third
message:
where
we
as
of
yeah,
then
back
then
we
contained
the
or
transferred
the
old
root
ca
certificate
where
we
request
an
update
for
in
the
general
info
field,
and
we
switch
this
to
transfer
it
in
the
request
message
in
the
body
of
the
request
message.
D
We
wanted
to
extend
the
polling
mechanism
in
cmp,
currently,
4210
offers
polling
only
for
enrollment
messages
and
we
had
the
the
requirement
to
provide
also
kind
of
handle,
delays
for
all
kind
of
messages
and
last
itf.
We
sketched
one
approach
and
we
worked
on
that
also
with
discussion
with
with
john
and
proposed
yeah
an
update
on
extension
of
the
existing
polling
mechanism.
D
D
D
So
what
else
is
to
do
in
cmp
updates?
We
need
to
register
oids
for
the
new
crl
update,
retrieval
and,
as
we
changed
the
root
ca
third
update
mechanism.
We
would
like
to
to
reorder
some
of
the
pre-registered
oids,
but
I
don't
know
whether
this
is
is
possible.
If
not,
of
course,
we
can
can
stick
to
the
to
the
ordering
as
of
today,
but
maybe
rust.
We
can.
D
A
D
I
understood
so
okay,
we
we
put
this
our
proposal
for
the
the
ordering
of
the
oids
in
the
in
the
draft.
But
if
you
say
changing
the
values
is
no
good,
a
good
idea,
then
we
can
can
stick
to
what
we
have.
F
D
Lightweight
cmp
profile:
what
happened
since
last
itf?
So
mainly,
we
specified
all
that
what
we
prepared
in
cmp
updates
in
more
details
and
profiled
in
the
lightweight
cmp
profile.
We
also
added
references
to
to
sntp
csr
and
brisky
ae
to
the
lightwide
profile
to
the
introduction
main.
Mainly
we
updated
this
root.
Ca3
update,
retrieval
mechanism,
we
simplified
at
one
place
the
sender
recipient
non-handling,
together
with
delayed
delivery
so
with
polling.
D
We
generalized
this
delayed
enrollment
to
a
delayed
delivery
for
all
kind
of
messages
and
also
updated.
With
this
regard,
the
end
entity
state
machine,
we
updated
section
6
a
little
bit
with
regard
to
delayed
message,
transferal
and
also
with
the
wording
topic
switching
from
transport
to
transfer
where
appropriate.
D
D
This
is
the
approach
we
specify
in
the
current
draft,
cmp
updates
and
in
more
detail
than
the
lightweight
profile.
On
the
left
hand
side
you
see
how
polling
works
today,
just
for
enrollment
messages,
ircr
and
kur
and,
on
the
right
hand,
side
the
updated
version.
It
also
works
for
the
other
message
types
used
in
the
lightwhite.
D
D
We
do
not
have
this
in
other
types
of
messages,
but
we
could
send
instead
an
error
message
which
can
transfer
a
status
weighting
doing
so
the
polling
would
be
initiated
for
the
non-enrollment
kind
of
messages.
With
this
error
message
containing
status
weighting
and
then
the
polling
mechanism
kind
of
goes
as
usual
for
enrollment.
D
For
for
those
cases
where
no
certificate
request
is
available
in
the
request
message
and
then
the
polling
mechanism
goes
as
currently
also
as
usual.
No
further
changes
needed.
So
the
only
thing
we
added
mainly
is
to
introduce
the
error
message
with
status
waiting
to
initiate
polling
for
non-enrollment
messages.
D
This
is
mainly
what
was
discussed
on
the
mailing
list,
so
introduction
of
two
new
general
message
types,
one,
the
request
message:
providing
a
status
of
a
crl
which
contains
an
or
less
a
pointer
to
source
and
a
timestamp
of
the
crl
and
in
the
response
message,
then
an
updated,
crl
or
no
update.
If
there
is
no
more
current,
more
recent
crl
available.
D
A
So
my
big
question
is:
does
anyone
have
concerns
with
going
to
working
group
last
call
when
the
author,
after
the
authors,
make
the
next
update.
A
Okay,
I'm
not
hearing
anyone.
So
let's
plan
to
do
that,
you
guys
make
the
the
changes
that
you've
talked
about
here
on
this
slide
and
then
we'll
do
the
call:
do
you
have
a
preference
for
an
order
or
do
you
want
them
to
go
together.
D
A
Okay,
then
we'll
start
the
working
group
last
call
after
you
do
one
more
update,
yeah
thanks
great
and
now
we'll
go
on
to
the
next
presentation.
A
I
think
dkg
is
doing
the
speaking
on
the
header
protection.
A
Let
me
do
it
this
way,
then.
J
H
Okay,
go
ahead,
hi,
folks,
sorry
for
being
offline
for
a
second
there,
so
the
lamps
email
header
protection
document
has
been
stalled
next
slide.
Please.
H
So
recap
for
folks
who
haven't
looked
at
this
in
a
while.
The
draft
specifies
at
least
two
major
options
for
how
to
protect
headers
in
signed
messages
and
encrypted
messages,
and
it's
been
unclear
how
we
select
from
them
about
what
guidance
we
give
for
generation
for
generating
encrypted
or
signed
messages
in
the
last
round.
We
propose
a
list
of
criteria
about
specific
problems
we
might
see
and
we
got
basically
no
feedback.
H
So
yeah
so
next
slide,
please
this
presentation,
I
basically
just
want
to
suggest
a
way
to
get
unstuck
and
see
if
folks
have
other
suggestions
for
how
we
might
get
unstuck.
I
think
one
of
the
things
that
we've
been
seeing
is
that
of
the
proposals
that
are
specified.
H
Any
of
them
will
work
for
new
clients
that
all
cooperate,
and
the
concerns
we've
been
stumbling
over
is
what
happens,
how
protected
messages
are
handled
by
legacy
clients?
I
see
bernie
in
the
cube
bernie,
you
want
to
jump
up.
K
Okay,
just
spin
on
your
knives
yeah.
I
pretty
much
agree
with
the
statement
daniel
made
and
I've
been
thinking
about
the
way
forward,
which
I
would
like
to
throw
into
this
discussion,
not
necessarily
that
I'm
fully
behind
that.
But
to
summarize,
we
have
no
clear.
We
know
in
a
way
between
the
two
between
the
legacy
between
the
wrapped
and
injected
message
scheme.
K
There
is
sometimes
the
interrupt,
and
sometimes
they
check
that
the
scheme
is
better
so
to
change
the
standard.
This
is
basically
two
weak
argument.
If
you
change
the
standard
two
from
wrapped
to
injected
in
more
detailed,
if
you
have
signed
and
encrypted
the
current
standard
dropped
prevails,
it's
overall
better
than
injected
and
it's
easily
fixable,
because
it's
minor
issues
basically
need
to
tell
the
clients
to
avoid
that
the
use
has
to
open
an
attachment,
designed
only
it
looks
a
bit
different
there.
K
We
make
the
difference
between
s,
mine,
capable
and
non-smart,
capable
clients
in
s,
mime,
cables,
clients,
the
two
schemes
they
are
more
or
less
equal
in
one
you
have
to
open
attachment
in
the
autobahn
is
only
protected.
It's
only
the
unprotected
subject
shown
in
the
injected.
So
this
is
kind
of
balance.
I
don't
see
any
kind
of
prevailing
in
here
for
non-smine
clients.
In
case
you
have
a
client
that
doesn't
understand
any
mess
mime.
They
are
not
only
there
and
only
in
the
multi-part
scheme.
K
However,
to
help
clients
which
I
just
described
like
legacy,
clients
that
don't
understand
mass
mimes
allow
an
option
to
use
the
injected
message.
Help
scheme
is
multi-part
signed
for,
but
this
for
sign
only
message.
Only
the
default
file
would
remain
wrapped,
but
for
this
case
we
would
introduce
the
injected
message
head
scheme.
I'm
not
sure
that
this
got
a
bit
clear,
but
I
think
that
could
be
a
way
out
of
this
situation
and
hoping
for
comments
here.
H
So,
thank
you,
bernie.
That's
a
that's
a
useful
suggestion.
It
would
be
great
to
have
that
in
in
writing
about
what
we
specifically
want.
You
know
a
proposal
about
how
to
move
forward
there.
I
I
actually
have
a
different
set
of
so
so.
H
My
concern
about
sticking
with
the
standard
as
it's
as
written,
which
is
not
currently
implemented,
is
that
people
have
not
been
implementing
it
for
some
set
of
reasons,
and
one
of
the
reasons
I
think
is
that
people
are
afraid
of
damaging
how
their
messages
show
up
on
the
other
side.
So
I
wanted
to
propose
a
different
in
particular
to
legacy
clients
and
when
we
say
it's
easy
enough
to
fix,
I
agree
with
you
that
I
don't
think
it's
actually.
H
These
are
hard
problems
to
fix
in
male
clients,
but
we
haven't
seen
folks
fix
them,
and
so
just
saying
we
just
need
to
specify
it
better
is
is
a
troublesome.
So
let
me
let
me
the
slides,
actually
have
a
separate
proposal
about
how
to
evaluate
these
things
that
I
think,
might
be
useful.
Can
we
take
the
next
the
next
slide,
and
you
know
I'm
hoping
to
hear
some
feedback
from
the
rest
of
the
working
group
about
how
we
do
this.
So
this
is
a
proposal.
H
This
is
my
proposal
for
how
we
think
about
evaluating
these.
I
think
we
could,
in
this
proposal,
aim
for
minimizing
any
change
in
experience
for
legacy.
Clients
is
a
legacy.
Client
shouldn't
be
able
to
really
notice
much
of
a
difference
between
what
they're
doing,
right
now
with
regular
emails
that
have
no
header
protection
and
emails
that
do
have
header
protection,
so
minimize
the
change
in
experience,
and
that
means
also
ignoring
any
security
increase
for
legacy
clients.
H
So
if
a
legacy
client
could
get
a
security
increase
by
doing
some
additional,
you
know
with
one
of
these
schemes
by
doing
some
additional,
workarounds
or-
or
you
know,
interaction
with
the
with
the
message,
and
that
gives
you
some
sort
of
protections.
H
H
Next
slide,
can
I
drive
the
slides
here
there
we
go.
Okay.
The
rationale
is,
I
want
to
incentivize
clients
to
adopt
this,
so
we
want
to
give
clients
that
can
adopt
this
a
reason
to
adopt
it.
That
is,
give
them
the
security
benefit
once
they've
adopted
it,
and
and
and
hopefully
this
set
of
decisions
will
break
us
out
of
the
existing
log
jam,
which
is
we
have
a
specification
nobody's
implementing
it
we're.
H
I
think
people
are
rightly
concerned
about
what
it
will
do,
and
so,
if
what
we
do
is
we
say,
hey
look.
If
you
adopt
this,
your
messages
are
going
to
get
through
just
as
likely
as
they
are
before,
and
if
you
implement
it
on
the
receiving
side,
then
you
get
additional.
Your
users
get
additional
security
benefits,
so
it
gives
a
clear
incentive
on
both
sides
to
adopt,
and
hopefully
that
would
break
up
the
long
term.
H
So
next
slide,
please
right!
So
that's
the
that's
my
proposal
and
we
can
run
down
what
we
think
the
outcome
of
that
proposal
would
be.
I
mean
I
have.
I
have
some
guesses
at
it,
but
I
think
it
comes
close
to
some
of
what
bernie
is
proposing
in
terms
of
allowing
different
mechanisms.
A
So
so
I
I
think
you're
partly
right,
but
partly
it's
because
the
document
contains
two
approaches
that
we
haven't
sent
a
clear
message
to
the
community
of
what
they
should
be
implementing.
H
Right,
so
what
I'm
referring
to
is
so
bernie's
bernie's
claim
earlier,
when
what
he
just
said
was
this
doesn't
warrant
changing
the
standard
right?
I
think
the
document
takes
as
a
starting
point
the
idea
that
I'm
forgetting
now
the
number
of
s
mine
that
said,
oh
yeah,
here's
how
you
protect
headers,
you
just
wrap
a
message
that
has
been
around
for
a
long
time.
Even
before
this
document
was
present
and
no
one
adopted
it
right.
People
had
the
mechanism
to
do
it
and
I
think
people
were
concerned
about
doing
that.
H
Maybe
they
were
just
lazy.
Maybe
people
don't
care
about
the
male
user
agents
anymore,
in
which
case
everything
is
hopeless,
but
maybe
they
had
good
reason
not
to
adopt
it
and
the
the
main
reason
I
could
see
was
the
the
effect
on
legacy.
Clients.
A
Right
well,
the
previous
one
was
basically
just
use
rc
822
message:
right
encapsulate
the
whole
thing.
That's
right
and
people
didn't
do
that
right.
Very
few.
A
K
A
B
So
we
have
existing
experience
here
with
the
rc
822
message:
wrapping
that
mailman
does
for
dmarc
right.
We've
submitted
this
in
the
itf
lists
and
some
other
lists
that
I've
run.
I've
done
this
and
universally.
It
confuses
the
less
technical,
the
user,
the
more
they're
confused
by
this.
B
So
that
message
attachment
really
is
this
point
a
serious
non-starter
to
me
for
older,
older
clients.
Now,
if
you're
going
to
tell
me
that
that
does
not
apply
to
latest
version
of
outlook,
then
I
say:
go
ahead:
let's
do
it,
but
it's
primarily
these
most
vulnerable
users
that
don't
seem
to
understand.
What's
going
on.
K
What
here
is
missing
like
the?
What
I
said
is
that
it's
easily
fixable
this
message
in
message
thing
and
if
we
give
instructions
how
to
fix
that,
I
believe,
like
microsoft,
outlook
could
fix
that
and
then
we
have
a
big
proportion
of
the
clients
of
the
user
base
that
has
fixed
for
this.
So
this
really
easy
thing,
and
if
you
do
this
auto
scheme,
the
injector
scheme,
it's
more
difficult
to
fix
or
more
difficult
to
implement,
because
the
instructions
are
not
anymore,
so
clear,
straightforward.
As
for
the
wrap
scheme
that
is
currently
standardized.
H
Do
we
have
a
anyone
from
the
outlook
team
who
has
committed
to
fixing
it
I'm
concerned
about
really
like
claims,
are
really
easy
to
fix.
Coming
from
someone
who's,
not
working
on
the
client.
H
I
guess
that
means
no
right,
so
so
that
that
I
mean
claims
that
things
are
easy
to
fix
by
the
implementer
is
different
from
claims
that
are
that
that
something
like
is
actually
going
to
be
fixed
and-
and
I
I
tend
to
agree
with
michael's
concern
about-
I
think
you
coined
the
term
confuser
there,
but
the
confused
user
is
a
is
a
risk
that
people
are
grappling
with.
H
So
I
I
recognize
that
the
that
one
of
the
pieces
that
are
in
the
current
so
so
let
me
let
me
let
me
just
outline
a
set
of
ideas
that
that
come
from
the
the
proposal
for
how
we
might
try
to
break
up
the
log
jam
here.
It
looks
like
we
don't
have
anything
that
really
addresses
the
problem
of
for
encrypted
messages
with
protected
headers
that
include
confidential.
H
Subject
lines
they
end
up
with
either
an
attached
message
or
they
end
up
the
the
legacy
display
or
the
subject
line
is
totally
invisible
or
the
legacy
display
option
doesn't
render
well
on
some
on
some
major
clients,
in
particular
on
outlook.
So
none
of
those
proposals
actually
seem
to
fix
seem
to
meet
the
goals
that
we
laid
laid
out.
So
you
know,
there's
anoth,
there's
another
approach
which
we
could
do,
which
says
we're
going
to
solve
the
problem
for
messages
that
are
text
html,
where
we
don't
introduce
the
legacy
display.
H
We
use
a
wrap
message
approach,
sorry,
not
a
wrap
message,
but
an
injected
headers
approach.
So
there's
no
additional
attachment
and
we
say
that
html
generating
male
user
agents
should
include
a
div
at
the
top
of
the
html,
with
a
particular
attribute
that
they
put
the
the
obscured
headers
in
particular
the
subject
header
in
that
obscured
attribute
and
then
a
male
user
agent.
That's
capable
of
that!
That's
compliant
can
hide
those
divs
from
that
they
can
avoid
rendering
those
divs,
because
they
can
identify
them
correctly.
H
So
that
seems
to
me
to
to
give
as
close
as
we
can
get
to
the
the
the
scheme
that's
described
here,
which
would
mean
dropping
the
legacy
display
proposal
and
and
and
minimizing
the
amount
of
sort
of
mime
shenanigans
that
are
going
on.
So
I'm
happy
to
write
that
up
as
a
variant
of
the
draft
and
see
what
people
think.
But,
but
it
looks
to
me
like
that,
might
be
something
that
would
that
would
break
out
the
log
gem
here
right.
We
could.
K
So
two
things
I
would
again
like
say:
confuse
the
user
is
in
with
any
proposal
we
use.
We
are
confusing
the
user
in
some
way
and
the
other
thing
is
what
you
propose.
I'm
not
quite
sure
I
understood
it
correctly,
but
is
this
something
pretty
close
to
what
the
pep
has
implemented
as
a
pep
message
for
mart?
1,
basically
just
add,
on
top
of
the
text
at
the
subject
line
or
on
top
of
the
html
right,
the
subject
line
so
that
it's
visible
by
a
legacy
client.
B
So
can
I
have
this:
is
the
do
nothing
situation?
H
The
do
nothing
situation
would
be
that
we
keep
the
standards
as
they
currently
are,
which
says,
use
this
wrapped
message
and
no
one
implements
them.
As
far
as
I
can
tell,
which
means
we
give
up
basically
on
people
actually
protecting
the
headers
of
their
messages.
B
H
If,
if
we
don't
do
anything
to
accommodate
legacy
clients,
then
any
of
the
proposals
that
are
present
in
the
draft
seem
plausible,
but
I
think
that
one
of
the
reasons
that
we're
that
we're
struggling
here
is
because
people
are
afraid
to
emit
messages
because
of
their
interactions
with
legacy.
Clients.
H
H
B
Currently,
protect
headers
from
either
signing
or
encryption
encrypted
messages
typically
have
to
go
to
somebody
who
actually
had
you
have
the
identities
for
right
or
you
can't
encrypt
and
so
there's
a
possibility
in
theory
of
some
negotiation
where
signed
messages
go
to
mailing
lists
in
other
places
and
people
that
aren't
ready
and
so
there's.
You
know
a
different
different
analysis
that
I
think
matters
and
if
you're
signing
it,
then
you're
not
you're,
not
necessarily
you're
caring
about
disclosing
the
subject
line,
because
you
that's.
B
Signed
it,
okay,
you
might
be
in
care
about
making
an
integral
okay.
The
meeting
is
on
thursday,
not
on
wednesday,
as
someone
fabricated,
and
so
maybe
repeating
it
is
more,
is,
is
sufficient.
That's
that's!
That's
enough.
Accommodation
in
the
signing
case-
and
it
sounds
to
me
like
we
just
shouldn't-
do
anything
to
accommodate
legacy
clients
in
the
encrypted
case.
That's
that's
sort
of
what
I'm
thinking.
H
L
H
You
just
can't
expect
that
to
work
at
all,
even
though
they're
running
a
tool
that
claims
to
be
s
mime
compatible
because
the
user
will
end
up
with
a
new
with
an
encapsulated
message,
and
then
they
have
to
do
something
to
view
that
message
and
then,
when
they
reply
to
that
encrypt
encapsulated
message:
they're
not
operating
in
an
effective
context.
There
are
a
bunch
of
situations
there
that
make
me
pretty
nervous
right.
If
we
say
here's
how
you
generate
a
message-
and
we
know
that
that's
going
to
cause
problems
and
say
encrypting
replies.
B
I
I
I
I'm
gonna
say
that
I
don't
care
that
much
about
legacy
encrypting
clients,
because
I
they
so
rare
at
this
point,
alas,
and
so
let's
just
move
forward
on
that
on
the
car,
but
you're
telling
me
that
in
the
sign
case
the
user
might
have
an
empty
subject.
Even
if
it's
signed.
No,
I'm
not
saying
that
in
the
signed
case,
I
really
hate
the
encapsulated
message
and
in
the
sign
case
I
really
don't
want
to
do
that,
and
I
am
agnostic
as
an
encrypted
case
for
whether
or
not
it's
encapsulated
or
not.
K
That,
just
like,
is
pretty
close
to
what
I
proposed
that
we
distinguish
between
signed
and
encrypted,
and
we
would
allow
something
to
make
the
signed
case
legacy
clients
better
and
in
the
encrypted.
We
just
go
forward
with
the
much
easier
case,
as
currently
standardized,
if
understood
correctly,.
H
H
This
I'm
not
either
and
bernie.
Maybe
what
should
happen?
Is
you
and
I
and
maybe
alexei
if
he's
willing
to
join
in,
should
have
a
meeting
sometime
next
week
to
to
just
to
look
at
some
proposed
changes
and
see
whether
we
can
agree
that
those
are
worth
putting
up?
As
last
call,
we
won't
find
out
the
consensus
until
we've,
given
a
concrete
proposal.
I
think
to
the
group,
I
think
that's
the
case.
A
H
Yep
sorry
little
to
report
on
the
end-to-end
encrypted
mail
guidance
draft,
there's
a
bunch
of
fixmes
in
the
draft
I'd
love
to
hear
some
suggestions
from
other
implementers
about
things
that
they've
noticed
or
things
that
they've
read
in
the
draft
that
they
think
are
wrong.
H
A
E
Hello,
I
want
to
start
off
with
a
an
apology
for
publishing
this
document
last
night
super
late,
but
I
would
like
to
thank
you
all
for
getting
up
super
early
and
reading
it
already
I'd
like
to
note
that
my
co-authors
are
actually
online
here,
they're
here,
and
so
they
should
feel
free
to
jump
in
if
they
have
anything
to
add.
So
this
is
just
a
kind
of
an
update
of
what
what
happened
with
our
document
signing
eku
draft
next
slide.
E
So
basically,
what
we've
done
is
we've
made
changes
to
the
draft
based
on
either
direct
or
implied
comments
that
we
received
on
the
list
before
so.
The
first
thing
we
did
was
we
clarified
what
it?
What
you
know
document
signing
is
mostly
to
address
the
concern
that
the
definition
wasn't
technical
enough
and
it's
basically
just
adding
more
words
around
what
it
means.
For
you
know,
the
document
is
digitally
signed
contents
that
are
consumed
by
humans.
E
You
know
that,
as
opposed
to
them
being
just
processed
by
machines,
we
added
a
new
section
with
lots
of
new
text
to
address
concerns
that
the
handling
process
was
undefined
and
to
address
concerns
that
an
eku
as
a
policy
identifier
was
the
was
the
way
to
do
it.
E
So
the
way
we
did
it
was,
we
basically
said
there's
an
example
in
there
for
how
to
do
it
and
it
kind
of
walks
through
how
you
would
do
it
and
the
example
is
based
on
the
the
the
the
rfc
that
russ
wrote,
which
is
how
to
digitally
signed
internet
drafts,
and
so
it
kind
of
walks
through
the
you
know
what
you
would
do.
It's.
G
E
O'clock,
sorry
about
that
and
the
the
basic
plan
is
that
you
have
the
the
implementation
examined:
the
extended
key
usage
values.
If
there's
no
restrictions,
then
you
know
it's
happy
and
it's
happy
to
use
it.
E
If
there
are
restrictions
and
it
can
block
it
now,
the
way
you
can
implement,
that
is
with
something
that's
very
similar
to
the
you
know:
certificate
policies,
constraints
and
name
constraints
stuff
with
the
excluded
and
permitted
eku's
that
an
art,
relying
party
is
perfectly
happy
to
implement,
to
make
decisions
one
way
or
the
other,
and
then
the
last
set
of
changes
were
just
to
kind
of
add
more
text
and
security
considerations
about
cross
protocol
attacks
and
to
note
that
there
are
really
no
privacy
considerations
added
as
a
result
of
this
draft.
E
I
know
it's
kind
of
quick,
but
that's
basically
it,
and
so
the
next
steps
is
the
working
group.
Adoption
call
we're
getting
lots
of
great
comments,
and
so
I
snarkily
suggested
to
my
co-authors
that
if
we
keep
going
at
this
rate,
we
won't
need
a
working
group
to
adopt
it
because
we'll
have
all
the
comments
addressed
and
we
can
just
go
straight
to
an
ad
to
do
it.
E
But
we
are
actually
asking
for
working
group
adoption
because
we
believe
we've
addressed
all
the
outstanding
comments
at
this
point
and
it's
a
starting
point.
So
again,
if
there's
things
that
we've
got
wrong,
we're
perfectly
happy
to
you
know,
hand
over
editing
and
move
forward.
So
I
guess
that's
where
we
stand
thanks.
A
Does
anyone
who's
here?
I
noticed
the
most
vocal
person
against
this
document
is
not
here
so
we'll
take
it
to
the
list,
but
does
anyone
who
is
here
have
concerns.
A
Okay
hearing
none,
we
will
revisit
the.
E
B
They
are
in
front
of
my
mouse
instead
of
in
my
head.
There
we
go
okay,
so
this
is
about
a
new
document
rfc
which
is
esp,
and
this
vfr
attribute
part
next
slide
and
we've
collected
three
or
four
offers,
and
I
think
maybe
a
couple
other
people
that
have
some
opinions.
B
So
the
story
so
far
1730
was
unclear
about
the
csr
attributes
in
the
brewski
and
autonomic
work
in
anima.
We
made
some
assumptions
about
how
they
could
be
used
and
to
be
fair.
Mack
fritikin
was
an
author
of
7030
and
of
eight
995,
and
he
seemed
to
think
that
we
were
doing
it
right
when
we
designed
it.
B
So
I
think
we
had
some
reason
to
believe
we
weren't
wrong,
and
then
it
was
pointed
out
that
it
belonged
that
it
did
not
match
the
easn
one
and
one
was
sufficiently
complicated
that
some
people
said
they
didn't
they
wouldn't
like.
Partly
in
that
list,
we
had
a
virtual
interim
meeting
recordings.
You
can
go
back
and
talk
about
the
relationship
with
the
slide
and
we
created
the
design
team
to
do
some
work
next
slide.
Please-
and
this
is
really
the
short
of
the
proposal
at
this
point-
that's
actually
not
yet.
B
In
the
document
there's
been
a
long
thread
of
muskin
among
the
document
authors,
which
has
not
quite
made
it
to
the
mailing
list,
for
I
don't
want
to
copy
people's
private
emails
to
the
mailing
list,
hoping
that
they
will
start
again
on
a
list.
But
the
short
of
it
seems
to
be
that
one
of
the
proposals
is
that
we
essentially
have
a
very
specific
callouts
for
the
values
of
a
couple
of
things
that
we
need
to
do
and
that
we're
not
going
to
basically
allow
any
arbitrary.
B
So
if
it's
a
name,
then
it
can
only
be
a
dn,
but
a
generic
name
can
be
subject:
alt
name
as
well,
which
is
really
what
we're
interested
in
doing.
Did
I
write
generic
okay?
So
sorry
it
was.
You
know
11
30
last
night
at
night,
and
but
that's
what
we
have
right
now.
This
document
is
not
ready
to
be
adopted.
B
It
is
very
useful
to
discuss
it
on
the
mailing
list
as
to
what
the
goals
are
and
what
other
people
might
people
other
people
might
expect
or
think
that
they
want
to
do
with
it.
I
don't
I'm
not
sure
that
I
want
to
have
a
specific.
You
know.
Here's
the
part
that
fixes
my
problem
and
everything
else
is
screw
that
I'm
not
sure
that
I
want
to
do
that,
but
maybe
that
actually
is
the
simplest
simplest
way
to
do
it.
B
It's
the
least
number
of
things
we
did
conclude
that
we
did
not
want
to
break
from
being
backward
compatible
with
what
was
there,
even
though
most
of
us,
the
specific
use
needs,
are
in
a
somewhat
greenfield
application,
so
we
probably
could
cope
with
anything
we
liked
we
could
even
cope
with
having
a
negotiation
via
mime
type
if
we
needed
to
so.
I
think
those
are
all
on
the
table,
but
it's
not
clear
that
we
need
to
do
that
and
I
think
that's
the
last
slide
next
slide,
maybe
no
yeah,
that
was
a
discussion.
E
Sean,
hey
sorry,
that
this
wasn't
clear,
I
think
maybe
would
have
been
better
back
in
the
day
if
we
had
more
people
review
it.
I
I
guess
I'm
concerned
that
you
would
just
take
the
attribute
and
modify
it.
I
think
you'd
need
to
define
a
new
attribute:
okay,
yeah,
because
it's.
B
E
And
if
you
think
that
there's
a
new
attribute-
and
you
want
to
have
specific
things
to
call
out
because
you
need
them
great-
we'll
include
them-
we
can
use
some
fancier
asn
1
stuff
to
allow
it
to
be
extensible,
so
there's
ways
to
do
this
yeah.
So
I
my
my
attitude
is
feel
free
to
make
the
changes
that
you
think
are
necessary
to
get
this
to
work
with
what
you
need
to
do.
B
I
think
the
question
is
whether
or
not
we
want
to
have.
You
know
a
specific
thing
that
here's
the
name:
here's
the
three
values
that
people
wanted
to
to
specify
and
if
there
are
other
attributes,
then
that's
a
future
revision
right
versus
being
able
to
put
any
attribute
with
any
value
in
the
in
the
in
the
thing,
which
is
what
I
thought
we
were
going
to
wind
up
with
in
the
first
place
and,
as
you
say,
there's
some
asn
1.
That
makes
it
all
happy.
I
just
don't
know
how
to
write
it.
E
B
I
I
think
we
have
enough
enough
people
in
the
authors
they
just
I
don't
think
they're
here
dan's
here.
I
don't
think
david
is
here
and
I
don't
think
the
other
author
owen
is
not
here,
because
it's
middle.
E
Of
the
night
for
him,
another
alternative
is
to
define
those
three
things
as
attributes
and
just
stick
them
in
yeah,
oh
as
new
attributes
as
new
attributes,
or
look
because
there
might.
I
didn't
look
real
closely
at
the
options,
but
that
that
some
of
those
might
actually
already
be
attributes
buried
somewhere.
B
E
B
Right
right
and
that's
the
part
that
that
where
the
existing
asn
one
was
was
unclear
to
non-non-experts,
we
thought
we
could,
but
it
turns
out
that
there's
no
value
there
isn't
a
value
thing
there,
but
it
didn't
stop
me
and
several
other
people
from
putting
a
value
in,
because
asn
was
self-describing
and
we
thought
we
were
doing
it
according
to
the
to
what
was
there
and
even
interoperating.
You
know
pretty
much
as
far
as
I
remember
we
just
like
yeah.
We
did
it
the
obvious
way
and
the
other
says.
B
Well,
I
did
it
the
obvious
way
and
we
did
it
the
same
way.
So
we
could
just
record
that
was
essentially
what
we
thought.
We
were
doing
we're
just
going
to
record
this,
this
extension
or
whatever
you
want
to
call
it
nasa1,
so
that
it's
actually
clear
that
that's
what
we
meant
and
then
these
somewhat
other
proposals
are
are
showing
up
anyway.
I'm
hoping
we'll
have
that
the
authors
will
be
less
shy
about
posting
the
mailing
list
and
we
can
have
a
better
conversation,
sean
that
you
can
actually
contribute
to.
B
Yeah,
I
think
that's
about
right.
I
think,
assuming
that
we
can
get
people
to
talk
that
you
know
somewhere
in
january.
I
don't
think
this
has
to
take
very
long.
B
A
E
Come
up
again
all
right,
so
this
is
a
document.
I
guess
that
I
volunteered
to
write
at
the
last
interim,
which
was
about
how
to
put
nist's
pqc
chem
algorithm
in
a
certificate.
Again,
I
apologize
for
not
getting
this
draft
posted
the
link.
There
is
to
a
github
repo.
I
will
have
it
posted
shortly
and
since
it's
not
yet
in
there,
I
don't
have
any
ipr,
I'm
not
planning
on
inserting
anything
et
cetera,
et
cetera,
et
cetera,
so
the
ids
contents
pretty
straightforward.
E
I
think
that's
the
right
one
for
the
ed25519
stuff
that
drafted
the
kernel
put
the
those
the
the
safe
curves
into
curdle,
and
I
just
basically
followed
the
format.
So
the
basic
premise
is
to
put
the
winners
in
there.
They
have
an
algorithm
identifier
that
with
oids
with
no
parameters
and
multiple
algorithm
identifiers
per
algorithm
to
count
for
parameters,
that's
what
I
have
in
there
now.
E
Alternatively,
we
could
just
use
the
nist
specified
oid
and
then
have
another
oid
for
the
parameters
identify
the
whatever
the
parameter
choices
are
like
kyber
has
like
two
different
or
three
different
sizes.
I
guess
there's
some
others
and
people
can
tell
me
what
those
would
be.
Then
we
have
to
say
what
other
bits
and
certificates
would
would
matter.
So
the
keys
are
the
ones
that
come
to
mind.
E
Obviously
I
think
key
agreement
is
the
one
that
we'd
include
I
put
in
cipher
only
into
cipher
only
as
maze,
and
then
I
thought.
Well,
I
don't
really
know
if
you
do
this,
but
I
put
them
in
there
anyways
just
to
have
a
think
about
it.
E
Then
the
format
for
the
subject,
public
key
fields
and
then
we
went
ahead,
and
I
added
one
for
a
private
key
format
just
to
be
complete,
because
I
think
sometimes
when
we
left
it
out
in
the
past,
it
caused
problems
and
obviously
we'd
have
an
asm1
module
to
kind
of
wrap
this
all
together
for
reference
purposes,
for
anybody
that
really
wanted
to
use
it.
N
A
A
I
was
which
is
key
transport,
so
I
think
that's
the
thing
to
debate
probably
should
go
to
the
list.
E
Yeah,
absolutely
okay,
but
that's
basically
the
idea,
so
the
the
option
is
the
real.
I
think
the
points
of
discussion
are
how
to
to
specify
this,
and
I
think
you
know
whether
it's
it's
one
oid,
where
the
oid
equals
the
parameters
or
whether
it's
the
oid
for
a
generic
algorithm
plus
the
the
algorithm,
the
parameters
being
another
oid
is
kind
of
the
the
big
discussion
here
yeah.
I
think
I.
A
E
A
I,
like
the
no
parameters
approach
myself
mike
you're
in
queue.
C
Yeah,
so
chems
don't
really
fit
cleanly
right
there
and
they're
a
new
api
they're,
not
really
a
key
agreement,
they're,
not
really
a
key
exchange,
we're
having
the
same
I'm
going
to
present
in
a
couple
slides
about
getting
chems
into
cms
for
content.
Encryption.
We're
having
the
same
problem
here
is.
Is
it
is
it
a
key
agree?
Is
it
is
it?
Is
it
an
exchange?
Should
it
be
its
own
top
level
structure?
C
E
Because
your
the
drop
with
multiple
keys
would
include
the
same
things
and
you'd
have
to
indicate
the
the
usages
for
those
individual
keys.
We
we
basically
have
to
agree,
because
if
you
pick
one
and
and
you
know
you
have
two
drafts
that
pick
different
things,
it's
like
it's
like
a
foot
gun
that
we're
firing
off
for
fun.
O
E
Would
hold
sorry
go
ahead,
john?
No,
I
wasn't
gonna
say
it
was
gonna
hold.
I
don't.
I
don't
really
want
to
pick
any
winners,
yet
you
actually
look
in
the
github
repo.
It
says
candidate,
one
and
candidate
two,
so
I
even
put
the
names
of
the
algorithms
in
there
because
I
don't
want
to
be
perceived
as
picking
a
winner.
E
Well,
I'm
hoping
what
they'll
do
is
what
I'm
hoping
they'll
do
is
publish
a
list
of
voids
that'll
go
with
that,
and
then
we
won't
have
to
wait
for
two
years.
Okay,.
E
Q
All
right,
great,
I'm
ali
and
I'm
gonna
just
be
talking
about
joint
work,
I'm
doing
with
rebecca
and
daphne
who
are
also
here
today,
just
on
like
a
general
framework
that
we're
developing
for
a
post-quantum
migration
discussion.
So
we're
excited
to
introduce
these
ideas
and
hear
some
feedback
next
slide
all
right.
So
once
the
post,
quantum
key
exchange
and
authentication
algorithms
are
selected
and
standardized
by
nist.
Q
The
adoption
of
these
into
quantum
resistant
protocols
really
depend
on
the
progress
that
we
make
in
integrating
these
into
protocol
standards.
So
we
know
there
was
a
lot
of
past
work
put
into
building
these
in
a
crypto
agile
way.
So
you
know
it's
important
to
maintain
that
agility
as
we
move
forward
and
migrate
to
post
quantum
framework.
Q
This
idea
has
led
to
a
lot
of
recent
focus
on
hybrid
designs
that
use
both
traditional
and
post
quantum
algorithms
together,
and
we
understand
that
these
designs
are
useful
for
interoperability
reasons
or
just
transitional
purposes
during
the
migration,
but
coming
from
nsa,
we
feel
that
hybrid
is
not
necessary
for
security,
since
we
fully
trust
the
vetting
process
of
these
algorithms
and
we've
assessed
the
needs
for
national
security
systems,
and
we
really
require
a
solution
that
allows
for
a
quick
transition
to
just
post
quantum
protocols.
Q
So
a
lot
of
the
work
so
far
has
focused
on
using
hybrid
to
ensure
backwards
compatibility,
but
we
also
want
to
ensure
that
they
allow
for
forward
compatibility,
and
by
that
I
mean
the
ability
for
a
hybrid
system
to
communicate
with
systems
that
prefer
to
use
strictly
post
quantum
or
next
generation
algorithms.
Q
So
again
we
want
to
make
sure
that
you
can
interrupt
with
non-hybrid
aware
systems,
so
those
that
are
using
strictly
traditional
algorithms
and
ones
that
are
using
strictly
pulse
quantum
algorithms,
so
that
should
both
of
those
capabilities
should
be
there.
If
a
design
is
backwards
compatible,
you
could
should
be
able
to
use
almost
the
same
framework
to
make
the
design
forward
compatible
since,
in
both
cases,
you're
just
telling
the
hybrid
design
hey
only
use.
Q
One
of
these
two
algorithms,
so
if
you
design
protocols
to
handle
forward
compatibility
now
that
minimizes
the
changes
that
are
necessary
for
strictly
post
quantum
solutions
and
again
it
avoids
a
further
transition
down
the
road
from
hybrid
to
post
quantum,
since
you've
already
built
it
in
and
then
we
also
want
to
make
sure
things
like
we
don't
want
to
have
these
hybrid
designs
be
prohibitively
expensive
in
terms
of
computational
performance,
and
then
things
like
the
time
to
establish
a
connection
between
peers
should
not
increase
exponentially
either.
Q
So,
if
you
look
at
a
few
of
the
working
group
drafts
out
there
for
hybrid
methods,
right
now,
there's
a
ton
of
different
terminology
being
used
to
describe
these
designs.
So
we've
seen
dual
signatures
or
combined
negotiation
algorithm
pairs.
You
know
multiple
key
shares
things
like
that,
but
if
you
break
it
down,
there's
really
mainly
two
approaches
that
are
gaining
traction
in
the
working
groups
and
these
choices
fall
into
one
of
two
camps:
the
idea
of
a
non-composite
design,
choice
and
a
composite
design
choice
next
slide.
Q
Okay,
so
here's
the
definitions
that
we
are
using
for
the
idea
of
non-composite
and
composite-
and
this
is
really
the
motivating
factor
of
our
talk
today.
So
we
feel
it's
really
important
to
define
this
framework
within
the
general
hybrid
umbrella
as
a
way
to
invite
a
more
structured
discussion
about
hybrid
designs
that
allow
us
to
really
make
the
best
decisions
moving
forward
into
a
post
quantum.
Q
So
on
the
left,
we
have
a
composite
design,
which
would
be
a
solution
in
which
the
traditional
and
post-quantum
algorithms
function
together
as
one
entity,
so
that
would
be,
for
example,
negotiating
a
traditional
and
pq
algorithm
together
as
a
pair
that
would
be
composite
and
then,
in
contrast
to
that,
we
have
non-composite
a
solution
in
which
the
traditional
impulse,
quantum
algorithms
function
discretely
as
individual
entities.
So
in
this
case
that
would
be
like
having
two
separate
certificates,
one
post
quantum
certificate
and
one
traditional.
Q
But
given
that
lens,
we
want
to
use
this
structure
to
allow
this
design
to
use
a
forward
transition
to
strictly
post
quantum
authentication.
So
the
biggest
difference
between
these
two
methods
is
really
that
most
of
the
work
for
non-composite
is
put
into
updating
the
protocol
to
handle
two
separate
certificates
instead
of
just
one.
So
most
of
the
work
goes
there
versus
the
composite
approach.
Q
However,
the
structure
for
non-composite
of
certificate
signing
and
verification
doesn't
change.
The
protocol
just
needs
to
adapt
during
the
process
twice
once
with
traditional
and
once
with
pq,
so
for
the
next
two
slides
I'll
go
over
like
the
pros
and
cons
of
each
design
in
the
context
of
our
research
of
how
this
would
look
in
two
different
protocols:
ikev2
and
tls.
1.3
next
slide.
Q
Okay,
so
for
composite
authentication,
for
this
slide,
we'll
consider
using
a
composite
signature
and
composite
certificate.
So
as
far
as
deciding
which
algorithms
to
use
a
composite
design
can
really
just
build
on
the
existing
structure
of
the
protocol
and
avoid
having
to
introduce
new
protocol
logic
here.
So,
for
example,
in
tls,
you
can
negotiate
the
algorithms
in
a
composite
way.
The
client
can
offer
a
list
of
pairs
of
algorithms
that
it
can
support
together
and
that
can
be
put
right
into
the
existing
signature.
Q
However,
there's
a
few
downsides
so
first
you'd
have
to
define
new
composite
voids
or
or
group
identifiers
to
describe
the
pairs
of
algorithms
together.
So
in
essence,
your
protocol
really
has
to
support
three
types
of
identifiers,
the
traditional
hybrid
and
the
pulse
quantum
again,
because
we're
thinking
about
this
as
the
most
straightforward
design
that
allows
for
the
protocol
to
be
forward
and
backwards
compatible.
Q
Q
There's
some
questions
regarding
deprecation
of
algorithms.
So
what
happens
if
one
algorithm
in
my
composite
gets
deprecated
since
it's
composite
you
either
need
to
revoke
the
entire
certificate
or
revoke
the
deprecated
algorithm,
and
then
this
opens
up
questions
into
how
you
handle
root
certificate
authorities
and
start
chains.
Q
So,
like
is
the
whole
chain
composite
and
what
happens
if
one
gets
deprecated
things
like
that?
The
last
point,
then,
is
regarding
the
transition
to
strictly
post
quantum
systems.
So
if
we
move.
G
Q
With
composite
authentication,
it's
not
very
straightforward
with
regards
to
backwards
and
forwards
compatibility.
So
how
do
you
drop
one
of
the
two
composites
to
a
non-hybrid
aware
system
and
it's
really
important
to
maintain
that
interoperability
when
we're
going
to
backwards
and
forwards
to
just
pulse
quantum?
Q
So
then,
the
opposite
of
that
would
be
the
non-composite
approach
that
we're
looking
at
so
there's
several
differences
here
from
composite.
So
first,
the
computational
process
for
validation
doesn't
change.
You
just
have
to
do
it
more
than
once,
so
this
will
probably
work
different
for
comes
and
stuff,
but
that
would
affect
the
composite
design
as
well.
So
this
does,
however,
result
in
logistical
changes
at
the
protocol
level.
Q
Using
two
separate
certificates
also
makes
it
quite
easy
to
be
compatible
with
non-hybrid
aware
entities
so
the
same
signature
algorithm
points
are
used
in
a
hybrid
as
they
are
for
a
traditional
system
and
a
pulse
quantum
system,
and
then,
if
you
have
support
for
one
or
the
other,
the
unsupported
certificate
just
won't
be
sent
right.
So,
for
example,
in
iv2,
only
one
set
of
cert
requests
or
an
off
payloads
will
be
sent.
That
indicates
a
non-hybrid
status
for
the
client.
G
Q
You're
really
just
using
the
same
sets
of
algorithms
and
no
new
set
needs
to
get
introduced
also
for
search
chains.
This
is
straightforward,
so
the
non-composite
approach,
it's
really
just
a
matter
of
a
policy
update
to
support
more
than
one,
because
it'll
use
the
same
root
certificate
authorities
and
the
chains
are
unchanged
as
well.
Q
Yeah,
so
we're
really
just
looking
to
get
feedback
for
this.
On
the
list,
like
I
said,
we
have
sort
of
an
informational
draft
in
the
works
that
gets
into
the
gritty
details
of
how
this
non-composite
authentication
design
looks.
And
then
we
have
a
more
technical
report
where
we
look
at
the
details
of
this
in
the
lens
of
two
different
protocols.
A
Okay
dkg,
then
joe
salloway.
H
Hi
there
this
is
daniel
kahn
gilmore
from
the
aclu.
Thanks
for
this
presentation,
it's
really
useful
to
see
the
kind
of
framing
that
you're
talking
about.
I
wonder
if
you
have
any
thoughts
about
how
this
would
map
to
your
analysis,
I
feel,
like
is
very
specific,
to
authentication
here,
and
I
wonder
if
you
have
any
thoughts
about
how
this
maps
to
key
agreement
or
encryption
schemes.
Q
Yeah,
I
think
that
this
framework
of
composite
and
non-composite
can
definitely
be
used
for
key
exchange
as
well.
It's
not
just
for
authentication,
so
I
think
in
some
of
the
working
groups
like
tls,
their
hybrid
approach
right
now
is
a
composite
using
composite
negotiation
for
key
exchange
as
well,
but
you
could
use
this
idea
of
non-composite
there
too.
H
Q
Oh
yeah,
I
was
talking
about
there's
a
hybrid
draft
in
tls,
that's
looking
at
for
post
quantum
migration.
How
that
would
work.
H
Of
the
but
of
the
analysis
that
you
presented,
you
seem
to
have
a
lot
more
pros
on
the
non-composite
than
on
the
composite.
I'm
wondering
whether
that
analysis
applies
to
whether
you
think
that
the
analysis
you've
presented
here
applies
to
key
agreement
schemes,
in
addition
to
applying
to
authentication
schemes.
Q
Oh
yeah,
so
our
our
pro
con
list
is
mostly
looking
forward
to
what
structure
would
make
it
easier
to
move
to
just
a
post
quantum
framework.
So
yes,
this
does.
It
was
not.
You
know
just
authentication
specific,
but
we
were
using
that
as
a
framework
for
today's
talk,
yeah.
N
Oh
yeah,
so
a
similar
question
to
daniels,
I
think,
just
to
come.
I
think
it
would
be
useful
to
kind
of
go
because
I
think
the
key
agreement
hybrid
structure
is
going
to
be
a
little
bit
different
than
authentication,
because
at
the
end
of
the
day
I
think
you
need
to
end
up
with
one
key
or
you
know
some
some
shared
secret.
So
I
think
there's
some
differences,
so
I
think
it
would
be
good
to
if
you
think
this
is
going
to
apply
to
kieron
agreement
as
well,
which
makes
sense
that
it
would.
N
But
I
think
it
would
be
good
to
go
through
some
of
those
pros
and
cons,
lists
and
kind
of
the
analysis.
Specifically
thanks.
D
I
I've
already
talked
to
the
tls
working
group
of
at
least
some
some
people
in
there
and
they
really
want
to
go
with
non-composites
signature
certificate
design
because,
basically,
if
you
they
don't
want,
the
bandwidth
choose
a
bandwidth
for
something
for
a
legacy
client
which
doesn't
need
these
huge
post
quantum
signatures,
public
keys,
the
what
I'm
taking
but
from
that
is.
I
A
Beginning
to
think
that
myself,
scott,
so
that
we
need
to
give
both
tools
to
working
groups
to
implement
or
to
pick
from
in
their
protocol
environment.
Mike.
C
A
couple
of
comments:
first,
scott,
so
I've
been
viewing
the
composite
stuff
as
existing
within
a
multi-cert
environment.
So
I'm
imagining
that
you'll
provision,
your
tls
server
with
an
rsa
cert
and
separately,
an
rsa
plus
pq
cert,
is
how
I've
been
imagining.
This
composite
would
get
used
and,
if
you're
already
sending
a
pq
public
key
slapping
an
rsa
public
key
into
the
same
object.
C
C
I
don't
know
what,
if
that's
commensurate
with
the
discussions
in
tls
or
not.
Second,
while
I
have
the
mic-
and
I
I'm
about
to
present
right
after
this
on
composite
but
ali.
Thank
you
so
much
for
this
framework.
I
think
this
is
really
really
useful.
Work
comment
I'll
make,
so
I
think
I've
speaking
for
myself,
not
for
all
the
authors
here,
but
I
think
I
fully
agree
that
for
online
negotiated
protocols,
ike
tls,
I
think
I
totally
agree
with
your
analysis.
Multi-Cert
gives
more
negotiation
flexibility,
yada
yada.
C
I
think
that's
great,
where
we
keep
getting
stuck
in
our
own
internal
design
sessions.
Is
the
offline
protocols
code
signing
s
mime
those
type
things
where
you're
you're
signing
objects
or
you're
encrypting,
payloads
you're,
just
firing
them
into
the
void,
and
you
have
no
idea
who's
going
to
pick
them
up.
That's
the
cases
where
we
we
don't.
We
just
haven't,
found
a
way
to
make
multi-cert
click.
You
know
if
you
get
an
exe
and
you're
an
exe
running
framework
and
you're
validating
the
signature
on
that
exe.
C
J
J
J
J
It
would
be
required
to
be
able
to
break
this
kind
of
you
know,
because
three
film
is
only
used
to
protect
the
next
10
messages
or
a
couple
of
messages.
After
that,
there
is
also
one
of
the
things
that
we
have
been
seeing
that
people
have
been
complaining
about,
because
some
of
the
post
quantum
methods
are,
the
keys
are
big
and
we
don't
want
to
do
that
before
the
authentication
or
some
form
of
authentication.
J
So
we
have
also
a
way
of
doing.
We
do
a
couple
of
rounds.
You
know
we
might
purely
filament
first,
then
we
might
do
an
authentication
with
traditional.
You
know
some
method
of
doing
out
the
case
like
a
preset
key,
and
then
we
could
do
some
more.
You
know,
post
quantum
key
exchange,
p
agreement
methods
to
actually
be
written
protected
by
the
authentication
done
by
the
preset
key
and
the
precinct
key
is
actually
post
component
safe,
provided
the
preset
key
comp
is
itself
or
ppk
is
strong
enough
to
be
protected.
J
Q
Yeah,
I
guess
I'll
just
say
that
these
ideas
definitely
show
up
in
different
areas
of
the
protocol.
So
it's
not
just
in
authentication-
and
I
know
ike
v2
has
you
know
specific
things
set
up
for
the
intermediate
exchange
and
things
like
that
to
handle
this,
but
I
still
think
it's
a
nice
general
framework
to
have
when
discussing
it.
A
I
heard
a
lot
of
interest
in
the
chat
for
a
paper,
so
I
hope
you
will
do
that
and
I
heard
suggestions
that
you
had
a
store
and
forward
based
protocol
to
your
analysis.
C
Hello:
okay,
aware
that
I'm
the
last
thing
in
the
day,
I
will
try
and
move
quickly.
I've
got
a
this
is
sort
of
a
grab
bag
of
different
stuff,
because
I'm
in
we're
we're
involved
in
probably
six
different
drafts
at
this
point,
which
I've
now
got
less
than
20
minutes
to
power
through
so
go.
C
Next
so
sort
of
two
different
bags
of
topics
here,
one
I'm
going
to
throw
a
single
slide
about
the
work
that
I've
been
doing
with
the
guys
at
crypto
next,
so
that's
not
composite
at
all.
That's
just
trying
to
figure
out
how
to
how
to
how
to
do
the
pipe.
The
plumbing
work
to
fit
a
chem
into
a
cms
content.
C
Ali
ellison's
presentation
was
a
good
load
of
information,
so
I'm
curious
to
see
if
any
of
this
shakes
out
becomes
unnecessary
wants
to
be
re
rewritten.
Given
that
analysis,
I
think
it's
you
know,
we
don't
have
any
horses
in
this
race.
We
just
want
to
see
the
technology
move
on.
So
that's
amazing
that
nsa
is
stepping
up
to
give
guidance
here.
Hopefully
that
will
help
help
to
settle
some
of
these
design
decisions.
C
So
this
is
a
draft
primarily
authored
by
ludovic
pereira
and
julian
pratt.
I'm
they
didn't
sign
up
for
a
speaking
slot.
So
I'm
taking
this
for
them.
Chems
chems
are
a
different
structure
structurally
different
from
either
a
key
trans
or
a
key
agree.
It's
I
mean
you
can
sort
of
convert
one
into
the
others.
You
can
convert
either
a
key
trans
or
a
key
agree
into
a
chem
pretty
straightforwardly,
but
it's
slightly
different
api.
C
So
it's
I
like
to
think
of
a
cam
like
a
diffie-hellman
sort
of
key
agreement,
but
there's
only
a
single
public
key
involved.
So
your
your
sender
does
not
have
a
public
key.
Only
the
recipient
has
a
public
key,
but
otherwise
it
works
the
same
way.
You
take
the
public
key.
A
shared
secret
falls
out
and
decipher
text
falls
out.
So
you
don't
get
to
choose
the
content.
Encryption
key
you're,
given
a
shared
secret,
which.
G
C
The
question
here
is:
how
do
we
fit
that
api
in
and
one
approach
is
to
generalize
what
rsa
chem
5990
did
they
decided
to
turn
it
into
a
key
trends
and
publish
a
key
trends?
External
api
and
that's
the
way
ludovic
and
julian's
draft
currently
is
written
the
other
option,
although
it's
that's
the
weirdity
there
is
that
you
need
an
algorithm
id
that
says
actually
I'm
not
a
key
trans,
I'm
a
chem
and
then
you
need
to
see
algorithm
params,
which
I
think
has
been
hissed
at
already
here.
C
You
need
algorithm
params
on
that
dummy
oid
to
say
actually
I'm
a
chem
and
actually
here's
my
chem
and
here's,
my
kdf
and
here's,
my
keywrap,
which
is
a
little
weird,
especially
I
know
some
other
rfcs
reference.
You
know
allowed
encryption,
algorithms
for
cms,
and
so
now
you
have
a
loud
encryption
algorithm,
which
is
the
generic
chem
dummy
oid.
C
C
The
third
option
is,
we
define
a
new
top
level
recipient
info
called
chem
recipient
info.
That
is
basically
the
recipient
info,
as
defined
in
4210
as
a
choice
of
key
trans
recipient
info.
Key
agree:
recipient
info
password,
keck
other
we'd,
be
adding
a
sixth
element
to
that
list,
and
so
I
think
we'd
have
to
look
carefully
at
whether
that
is
a
backwards,
compatible
change
or
whether
that
would
require
a
bump.
A
rev
of
the
the
version
number
of
cmp,
which
I
think
is
probably
unacceptable
for
a
change
this
small.
C
So
russ,
I'm
gonna,
I
don't
know
if
we
could
take
a
straw
poll
or
a
hum
or
something
is
the
question
here.
Is
this
a
significant
enough
design
choice
to
be
worth
a
full-blown
discussion
on
the
list,
or
are
these
all
sort
of
equivalent,
and
we
should
just
write
one
up
and
submit
it
as
an
oh.
A
A
Exactly
and
and
that's
what
I
that's,
what
we've
seen
in
the
tls
environment
them
doing
more
and
more
because
we
want
to
avoid
strange
parameter
interactions.
N
She
would
be
is,
with
with
respect
to
calling
this
key
trans
does
that
have
any
any
implications
of
like
well
ketrans?
I
usually
think
of
I'm
using
the
public
key
to
do
encryption
of
some
sort
and
and
on
not
all
cams
you're
really
doing
that.
Does
that
have
any
implications
further
down
the
line,
or
is
this
just
a
naming
issue.
A
C
C
Can
I
can
I
take
that
russ
sure
so
I've
got
the
core
idea
of
this
draft
is
sort
of
sketched
out
on
the
side
there.
So
the
idea
is,
you
use
the
chem
to
derive
a
shared
secret.
You
use
the
shared
secret
to
derive
a
kek.
You
use
the
kek
as
an
aes
key
to
wrap
the
cek,
so
you
are
in
fact
encrypting
and
I
and
we've
because
of
that
kdf
we've
kdf
out
any
particulars
of
the
chem
you
chose.
C
M
I
was
just
thinking
because
I've
thought
of
a
lot
about
this
too,
but
I
like
clean
implementations
and
the
fact
that
there's
going
to
be
a
lot
of
can
like
chem,
is
happening
a
lot
more
right,
like
all
the
pq
algorithms.
A
lot
of
them
are
are
chems
and
you
know
rsa
obviously
has
a
chem
as
well,
so
does
not
having
its
own
recipient
info
kind
of
as
it
kind
of
alludes
it
to
its
own
family
of
algorithms.
M
So
I
think
in
that
way
it
just
seems
clear,
like
semantically,
it
seems
clear,
at
least
in
my
mind
so
yeah
I
know
I
know
we
can
make
it
fit
into
the
the
key
trends
and
it
has
been
done.
But
is
there
an
issue
for
semantics
to
to
just
not
have
its
own
kim
recipient
info,
or
is
it
a
big
issue
with
you
know?
We
think
it
would
cause
incompatibilities
if
we
were
to
add
a
new
recipient
info
type.
L
Hi
yeah,
I
also
I.
I
think
that
that
the
other
recipient
info
direction
would
be
better
like
if
we
choose
key
trans
recipient
info,
we're
kind
of
locking
in
that
we
don't
have
the
flexibility
that
key
agree.
Recipient
info
had
for
including
optional
user
keying
material,
whereas
if
we
did
allow
have
a
new
structure
specified
by
other
recipient
info,
we
could
add
that
if
we
wanted
it.
A
That's
a
good
point:
the
the
ukm
field
go
ahead,
sean.
E
Just
not
knowing
the
answer
is
this
leading
us
down
the
path
of
trying
to
say
to
specify
another
key
usage
type
in
x509.
E
Okay,
you
were
good,
so
I
did,
I
did
read.
The
tea
leaves
all
right.
So
I
guess
my
question
is
how
much
of
a
absolute
pita
is
that
going
to
be
and
do
we
think
there's
any
a
chance
that
that
will
get
implemented
in
any
kind
of
timely
fashion?
E
By
both
you
know,
cas
and
relying
parties.
C
A
It's
pretty
clear
to
me:
this
is
a
big
enough
decision.
We
should
take
it
to
the
list.
I
do
think
opening
cms,
which
is
a
full
standard,
does
mean
that
we
need
to
think
pretty
hard
before
we
do
that.
But
if
it's
the
right
answer,
it's
the
right
answer
and
I
hadn't
thought
about
the
lack
of
the
ukm
field
right
next
slide.
I
think
we've
got
about
10
minutes.
C
C
C
So
this
is
just
sort
of
an
update
on
where
we
are
so
we
there's
been
a
lot
of
work
done
by
our
author
group
here
against
these
lamps
milestones
that
are
probably
still
sufficiently
in
the
future
that
I
don't
know
that
the
working
group
is
ready
for
knitty
details.
Maybe
question
mark
so
once
again
I'll
present
a
landscape,
I've
structurally
chosen
to
break
the
dual
composite
hybrid
stuff
up
by
keys
inserts
signatures
and
encryption.
I
think
they
are
sort
of
structurally
separate.
C
C
G
C
C
Thank
you.
We
have
a
plan
to
still
support
generic,
so
if
you
need
something
that
doesn't
have
an
explicit
oid,
although
maybe
that's
not
a
use
case,
we
should
care
about.
But
if
that,
if
that
is
a
use
case,
you
want
to
use
a
pair
that
doesn't
have
a
defined
oid.
C
We
we
could
register
an
oid
for
pkne
with
any,
which
would
still,
which
would
be
an
explicit
pair
but
open
if
that
nomenclature
makes
any
sense.
So
there's
there
is
still
possible
to
make
a
generic
oid
within
the
explicit
framework
yeah.
The
bottom
half
of
the
slide
is
well
covered
by
ellie's
presentation.
G
C
C
Okay,
interest
of
time
signatures
haven't
really
done
any
major
work
on
this
in
a
while.
I
think
it's
sitting
fairly
mature.
We
do
have
some
design
decisions
that
will
bring
up
if
and
when
the
working
group
adopts
this,
but
it
hasn't
really
been
worth
chatter
on
the
mail
list.
Yet
we
also
can
make
this
explicit.
C
C
C
C
Okay,
next
the
font's
a
bit
small
here,
so
the
last
piece
of
work
we've
been
doing.
This
is
where
we've
done
most
of
our
work
in
the
last
six
months
is
composite
content
encryption
for
cms.
How
do
you?
How
do
you
say
you
come
across,
come
across
a
recipient
who
has
multiple
public
keys?
C
Again,
I
don't
particularly
care
whether
that's
in
a
single
cert
or
that's
across
multiple
certs,
but
you
have
a
recipient
who
has
who
declares
that,
if
you're
going
to
encrypt
for
me,
I'd
like
you
to
use
multiple
public
keys
to
do
it?
What
does
that
envelope?
Data?
Look
like
we've
put
out
an
0.
This
is,
I
think
we
proposed
three
completely
different
mechanisms
in
that
oo,
draft
we're
still
working
on
that
quite
heavily.
I
think
we've
found
a
way
to
combine
all
of
them
nicely
together
into
one
max
single
mechanism.
C
C
Although
you
could
also
imagine
it
exposing
a
key
trends,
and
it
can
go
straight
into
key
transverse
up
info,
where
all
there's
also
debate
over
what
the
underlying
mechanism
should
be
and
how
that
should
function.
Should
it
be
sort
of
based
on
a
one-time
pad
xor
for
wrapping
the
cek,
or
should
we
throw
in
an
aes
key
keywrap
layer
that
decision
sort
of
will
dictate
the
key
trends
versus
chem
decision.
C
D
M
John,
I'm
just
gonna
add
to
what
mike
said.
He
mentioned
the
the
composite
chem,
so
we're
actually
thinking
about
creating
a
new
draft
just
for
composite
kim
construction,
because
we
as
part
of
our
debates
for
the
what
he
was
just
talking
about
composite
encryption.
M
We
came
up
with
the
idea
that
perhaps
it's
just
simpler
to
have
a
composite
construction
and
then,
if,
if
there
was
such
a
thing
as
like
a
cam
recipient
info
or
just
you
know
a
chem
usage
type,
it
just
fits
in
there
much
better
and
it
seems
simpler.
So
you
might
see
us
request.
You
know
a
zero
zero
draft
for
a
composite
kim
because
I
think
it'll
be
a
yeah.
I
think
that's
it's
separate
enough
that
it
would
be
worthy
of
its
own
draft.
So
I
just
wanted
to
point
that
out.
C
A
All
right,
given
that
we're
down
to
two
minutes
anything
else,.
C
A
Yeah,
I
think
I
think
that
you
should
start
a
few
threads.
You
know
on
the
higher
order,
design
decisions
and
maybe
see
where
they
take
you
and
then
we'll
see
where
we,
when
we
get
to
a
point
where
we
can
adopt
a
document
after
having
a
few
of
those
design
level
discussions.