►
From YouTube: IETF-LAMPS-20210913-1400
Description
LAMPS meeting session at IETF
2021/09/13 1400
https://datatracker.ietf.org/meeting//proceedings/
C
C
C
C
C
C
A
Okay,
I
think
we
have
the
technical
issues
sorted.
What
what
I
was
unable
to
upload
from
the
data
tracker,
but
I
was
able
to
upload
from
my
desktop,
so
we
now
have
the
slides.
We
now
have
audio.
It
appears
we
have
video,
so
I
think
we're
able
to
get
going
here.
We
do
need
someone
to
take
minutes
in
the
cody
md.
A
A
So
if
you're
going
to
contribute,
please
make
sure
you
understand
your
rights,
privileges
and
responsibilities,
and
the
agenda
for
today
is
really
kicking
off
the
whole
post-quantum
portion
of
the
lamps
charter.
These
a
through
h,
are
listed
here
as
the
milestones
that
have
some
pqc
related
activities.
A
E
E
So
my
thought
for
today
was
to
go
through
the
lamp
milestones
as
they're
set
out
in
the
charter,
I'm
going
to
present
them
in
a
slightly
different
order,
rust
than
you
had
them
listed
and
then
and
that
the
lamps
about
page
has
them
listed.
There's
a
bunch
that
are
all
due
in
december
and
I
think
they're
sort
of
alphabetically.
I've
decided
that
clustering,
the
chems
and
then
the
signatures
is
a
more
logical
presentation
flow.
E
Yeah,
that's
fair
and
then
the
second
half
time.
I
think
the
milestones
is
where
we
like
is
the
point
of
this
meeting,
but
time
allowing
we
have
prepared
slides.
We
have
four
fairly
mature
drafts
that
we
think
accomplish
the
hybrid
key
establishment
and
the
dual
signature
milestones
so
time
allowing
we
would
like
to
you
know,
continue
to
raise
awareness
that
we
think
those
meet
meet
the
milestones
but
milestones.
First.
E
A
D
E
E
The
first
one
is
about
chems,
so
adopting
a
draft
for
post
quantum,
crypto
chems
in
cms
and
pkx
and
then
lower
down.
We
have
oh,
I
didn't
adjust
the
order
of
this
as
much
as
I
wanted
to.
If
that
was
a
change
we
made
it
later
so
then
we
have
hybrid
key
establishment
in
december.
We
have
choosing
primitives
for
signatures
in
december
and
we
have
dual
signatures
in
december.
E
So
the
work
here,
as
I
understand
it,
is
to
assign
oids
and
defining
codings
for
the
chem
algorithms
that
are
coming
out
of
the
nist
competition,
presumably
we're
taking
the
miss
candidates
that
I
assume
that's
what's
driving
this
rather
than
you
know
generic
hems
or
comes
from
other
sources.
So
the
charter
says.
E
E
The
lamps
working
group's
job
is
to
assign
oids
and
figure
how
to
pack
them
into
asn.1.
I
assume,
and
then
the
third
bullet
here
is
one
that
we've
really
wrestled
over
is
how
do
these
even
fit
and
there's
a
fourth
bullet.
I
added
later.
How
do
these?
How
do
these
fit
chems
they're
not
really
encryption,
because
you're
not
taking
a
given
content
and
encrypting
it
the
the
they're
sort
of
more
of
a
shared
secret
derivation.
E
E
E
A
A
G
I
Yeah
I've
just
said
what
I
was
going
to
say,
but
yeah.
I
think
they've
essentially
defined
how
you
use
a
cam
to
create
a
key
encipherment,
and
then
it
fits
well.
And
so
we
could
follow
that
model,
or
it
really
depends
whether
we
want
to
expose
the
pure
cam
functionality
directly
or
whether
we're
okay
to
just
expose
the
encryption
scheme
that
that
they're
using.
E
Okay,
so
I
think
that
defines
the
work
I
mean
this
is
all
we
don't.
We
need
to
come
to
an
agreement
on
this
caller.
We
just
need
to
acknowledge
that
these
milestones
is
not
just
about
choosing
algorithms
and
putting
loads
on
them.
There's
some
structural
decisions
to
be
made
here
mike,
you
had
a
hand,
do.
J
E
C
E
A
H
A
G
Well,
I
don't
think,
there's
it's
any
bar
to
adopting
a
draft
that
the
parameters
may
change
our
process
takes
one
or
two
years,
just
like
their
process.
It's
not
like
where
we
adopted
draft
in
december
and
published
an
rfc
in
march,
so
I
think
that
the
possibility
that
parameters
are
going
to
change
is
certainly
no
bar
for
adoption.
F
B
B
Some
of
that
may
change
underneath
us
as
we're
working
on
things,
and
so
that
might
influence
some
of
our
choices
but
to
joao's
point,
there's
plenty
of
time
for
us
to
adapt
to
those
sorts
of
changes
and
if
they
do
impact
some
of
the
performance,
analyses
or
other
things
like
that,
and
that
does
cause
us
to
go
down
a
different
road.
We
have
plenty
of
time
to
do
that.
I
think
yuri
is
mostly
right.
The
we
can
ignore
the
details
of
the
algorithm
until
we
can't.
F
B
A
B
E
E
E
E
A
F
E
E
Now
we
want
to
do
more
than
one
of
them
at
the
same
time,
and
I
apologize,
the
font
is
a
little
bit
small,
so
the
milestone
here,
as
I
see
it
is
the
working
group
hasn't,
I
think,
really
decided
what
overall
direction
russ
and
I
have
presented
back
and
forth
a
few
times
on
multi-cert
versus
some
kind
of
multi-key
composite
is
one
example
of
multi-key.
There
could
be
other
types.
E
We
have
a
we've
recently
completed
a
composite
encryption
draft
that
leverages
our
composite
keys.
So
we
we
wrote
composite
keys
to
service
like
our
composite
signatures,
but
we've
generified
it
and
written
a
composite
encryption
that
we'll
get
to
if
we
have
time
at
the
end
of
the
slides
that
implements
the
cms
key
trends
stuff.
E
E
A
A
J
E
Yes,
we
actually
have
slides
later
on.
If
you
don't
mind,
I'd
like
to
get
through
the
advent
like
I'm
we're
a
half
we're
at
half
the
time
through
the
meeting
here,
I'd
like
to
get
through
the
milestones
first
and
then
in
the
slide
deck
you
can
download
the
slide,
deck
and
scroll
forward.
If
you
want,
we
do
have
slides
explaining
the
hour
draft,
but
I
think
we
should
get
through
the
milestones
first.
I
think
that's
the
more
important
use
of
time
here.
B
E
A
I
A
E
A
E
F
Yuri
I'd
like
to
ask
how
strongly
people
feel
about
the
need
for
hybrid
key
exchange,
because
it
appears
it
would
be
useful
in
only
one
case,
if
a
quantum
computers
do
not
become
cryptographically,
threatening
and
post-quantum
algorithm
fail
to
classic
attacks
in
all
the
other
possibilities.
That
would
be
just
an
extra
burden.
J
And
so
yes
quickly,
commenting
about
this
remark
about
the
usefulness.
So
there
is
one
reason:
maybe
it's
not
a
good
one,
but
I
mentioned
that
is
that
for
certification
of
security
products,
which
are
going
to
be
based
on
the
protocol
that
we
are
deploying
so
the
the
trend
is
that
all
security
agencies
will
require
to
have
a
hybrid
mod
to
make
the
certification.
J
So
if
you
have
not
a
breed
mod,
you
will
likely
be
difficult
to
to
certify
a
product
with
a
responsibility,
and
so
another
thing
that
I
wanted
to
say
about
with
key
exchange.
So
there
is
various
groups
that
are
dealing
with
this
issue.
So
I
think
cls
is
disgusting.
Of
that.
I
I
think
the
the
group
on
ipsec
has
some
discussion
on
on
on
the
topic.
A
That's
going
to
require
people
to
get
comfortable
with
the
new
algorithms
and
the
implementations
of
those
algorithms,
and
so
something
so
hybrid
offers
a
way
where
the
the
classic
algorithm
provides
kind
of
a
safety
net
for
those
people
as
they
develop
comfort
and
the
cost
of
doing
a
classic
algorithm.
If
you're
doing
a
pq
algorithm
is
pretty
small.
F
E
C
E
Thank
you.
I
have
two
two
points
there
so
then
another
need,
I
think
that
drives
hybrid
is-
and
this
is
a
bit
of
a
fear
and
doubt
argument
as
I
make
it.
But
rsa
is
very
well
established
where
you
know,
we've
there's
been
lots
of
cves
and
implementation,
bugs
that
everyone
needs
to
scramble
a
fix
for,
but
it's
fairly
old,
fairly
mature.
E
I
expect
this
new
stuff
is
going
to
have
to
go
through
the
same
wave.
I
expect
it
will
be
a
decade
before
it's
really
done,
having
cves
in
it.
Hybridizing
it
with
rsa
gives
us
that
security
that
a
cve
doesn't
leak.
Your
data
second
argument
I
want
to
make
here
is
within
the
context
of
cms
hybrid
content
encryption.
I
am
sending
you
an
email
here.
It
is
and
the
recipient
has
multiple
keys
and
therefore
the
email
is
protected
by
multiple
algorithms.
E
E
Okay,
so
then
to
this
slide,
which
is
signatures,
so
this
is
very
similar
to
the
first
slide,
although
it's
a
lot
more
straightforward,
how
this
is
going
to
fit
signatures
or
signatures,
signature,
key
usage,
signature
structures,
signatures
and
signatures.
So
this
is
a
much
simpler
slide
than
the
analog
for
chems.
E
So
this
slide
is
very
similar
to
the
one
above
for
key
exchange.
Assuming
we
have
pq
signatures,
then
we're
going
to
want
to
layer
them.
The
word
here
is
dual
by
the
way
I
meant
to
mention
this.
A
couple
slides
back.
The
word
hybrid
key
exchange
I
mean
hybrid
encryption
is
already
a
buzzword
right.
That's
the
aes,
plus
asymmetric,
hybrid
key
exchange,
I
suppose,
is
unique,
but
once
we
start
talking
about
content
encryption
in
cms,
I
don't
know
what
we're
going
to
call
it
all.
E
E
We've
recently
split
out
keys
in
explicit
both
both
generic
and
explicit.
So
these
these
are
fairly
mature.
Itu
has
their
x10,
which
does
something
a
little
bit.
Maybe
if
you
squint
at
it
a
lot
like
this,
although
it
uses
asn
1
extension
marks,
which
don't
line
up
or
aren't
supported
by
the
asn1
modules.
In
5280.
E
E
A
E
A
I
maybe
that's
a
third
dimension
to
suggest,
but
I,
if
you
were
to
take
that
approach
and
have
separate
certificates,
one
for
the
classic
and
one
for
the
post
quantum
right,
which
was
something
we
discussed.
I
don't
know
six
months
ago
you
you
still
end
up
with
the
multiple
signatures
on
the
cms,
with
just
different
certificates,
to
validate
back
different
cert
paths
for
for
each
of
the
signatures.
A
E
A
I
Survey
related
to
the
x510
significant
weather,
so
one
of
the
points
there
is
that
I
guess
x509
has
evolved
a
little
bit
and
added
the
extension
marks
at
the
end
of
the
x
509
certificate
definitions,
but
those
aren't
in
the
ietf
profile
of
fx509
and
5280.,
and
so
I'm
wondering
if
there's
a
history
there
or
whether
this
is
something
we'd
adopt.
If
we
decided
it
was
useful
or
yeah.
What's
the
history.
A
I
K
E
E
I
I
Do
you
require
the
users
to
always
use
all
the
keys,
or
do
you
have
some
policy
that
says
you
only
use
some
of
them
or
it's
okay,
to
only
use
some
of
them
and
you
could
make
that
arbitrarily
complicated.
What
the
current
graph
does
is.
It
proposes
so
by
default
this
id
composite
key.
That
says,
you
always
use
all
the
keys
when
you're
using
the
key
and
when
you're.
So,
if
you're
verifying
a
signature,
you
have
to
verify
every
single
signature
and
they
must
all
be
valid.
I
So,
as
I
said
at
the
beginning,
they're
the
the
subject-
public
key
infos
that
are
in
the
public
key
list.
They
could
be
absolutely
anything
and
if
you
look
at,
if
you
have
a
key
object
with
the
identifier
id
composite
key,
that
tells
you
nothing
about
what's
inside
and
so
other
aspects
of
how
you're
using
this
thing
need
to
tell
you
what's
allowed.
If,
if
there
are
restrictions,
it's
very
very
flexible
and
I
think
that
can
be
a
good
thing
or
a
bad
thing,
depending
on
the
circumstances.
L
E
E
I
think
I'm
imagining
that
for
public
pki
like
like
internet
tls,
you'd
want
to
always
use
the
and
mode
for
closed
pkis
like
cable
labs,
you
know
internal
thing
or
maybe
a
corporate
s
mime
or
something
where
you
have
sort
of
weird
migration
requirements,
but
you're
also
more
able
to
more
tightly
controlled
clients.
That's
where
the
or
mode
might
be
useful,
that
at
least
that's
sort
of
how
we
got
to
writing
it.
This
way.
D
Yeah,
I
was
just
going
to
jump
in
quickly
and
say
that
the
the
or
mode
is
good
from
migration
as
well
like.
So
if
you
wanted
to
use
one
key,
for
instance,
the
classic
algorithm
and
then
switch
to
a
newer
key
like
the
pq
algorithm,
but
not
have
to
update
the
end
decline.
Software
like
say
it's
out
in
the
middle
of
the
ocean
somewhere.
Obviously
you
have
to
update
the
software,
but
maybe
not
the
key.
That's
there
and
you
just
switch
in
software
which
one
is
being
used.
So
I've
heard.
C
E
I
Yeah,
if
we
just
go
ahead
to
the
next
slide,
just
so
I
touched
on
the
explicit
composite
as
well,
because
I
think
it's
an
important
debate.
So
yes,
when
the
generic
composite,
the
container
can
contain
arbitrary
pairs
or
actually
tuples
of
public
keys
in
the
explicit
composite,
where
it's
a
much
more
rigid
approach.
So
the
idea
is
we're
still
providing,
I
almost
say
a
framework,
but
a
structure
whereby
pairs
of
algorithms
can
be
used
together.
I
But
those
pairs
are,
the
types
of
the
pairs
are
fixed
by
the
object
identifier.
So
you
can
see
on
the
left
hand,
side-
and
this
is
using
say
the
fancy
asn1,
the
more
modern
asn
1
and
I'm
definitely
not
an
expert
there.
But
I
so
I
think,
on
on
the
left.
Here
you
have
a
the
definition
of
the
information
object.
I
Class
except
I've
left
out
the
definition,
but
you
can
see
the
the
parameters
that
go
with
it,
and
so
you
can
basically
see
you've
got
an
object
identifier
and
this
is
going
to
bind
it
to
a
first
algorithm,
first
public
key,
first
public
key
type
and
then
the
second
algorithm,
the
second
public
key
and
the
second
public
key
type.
And
then
I
give
an
example
here,
just
with
a
toy
right.
I
You
can
use
this
void
in
this
protocol
they're
only
allowing
those
particular
that
particular
combination
of
algorithms,
the
algorithm
choices
and
the
parameters
that
go
with
them
like
they
don't
need
to
be
transmitted
on
the
wire
because
they're
all
encapsulated
in
the
oid.
Just
as
for
a
ts,
tls
cipher
suite
right,
you,
you
have
all
the
parameters.
Kind
of
embed
well
reduced
to
an
integer
and
yeah.
So
it's
a
lot
more,
but
it
allows
you
to
be
much
more
rigid
in
what
you're
going
to
accept.
I
But
it's
still
because
we're
using
the
framework
you
can
you're
still
making
sure
that
the
the
way
that
the
pairs
of
algorithms
are
encoded
the
way
the
signatures
are
validated
etcetera.
Those
are
all
specified
once
and
it
becomes
very
easy
to
add
a
new
pair
to
the
list
of
supported
combinations,
and
so
I
guess
yeah
there's
a
trade-off
there.
I
think
the
generic
one.
Actually,
if
you
go
to
the
next
slide,
there's
a
little
bit
on
that,
but
you're
yeah.
So
the
generic
one
is
very
flexible
and
I
think
it
means
as
an
application.
I
You
have
to
handle
all
those
cases
and
yeah,
it's
more
just
I
think
more
to
more
to
go
wrong.
Perhaps
the
explicit
gives
you
something
much
more
defined
where
I
kind
of
feel
like
yeah,
you
really
know
well,
when
you're
allowing
certain
algorithms,
you
know
exactly
what
what
people
are
going
to
be
able
to
do.
I
I
A
Likewise,
in
cms,
different
algorithms
were
specified,
but
none
were
mandatory
to
implement
because
things
that
use
cms
such
as
s
mime
were
specifying
which
algorithms
were
mandatory
to
implement
and
choosing.
The
pairing
here
seems
to
be
essentially
making
those
kinds
of
choices,
and
so
I'm
wondering
why
you
think
the
lamps
group
is
the
right
one
to
do
that.
A
A
F
F
A
H
A
A
Okay,
so
I
I
I
bow
to
that
wisdom
that
we'll
pick
this
up
on
the
list.
At
the
same
time,
if
we
have
a
few
minutes,
I
would
like
to
know
if
we
have
some
volunteers
for
the
drafts
we've
identified
regarding
chem
and
hybrid,
I'm,
assuming
that
mike
wants
to
keep
working
on
the
hybrid
stuff,
sean
correct.
J
A
E
I'll
just
try
and
take
15
seconds
here
for
the
the
composite
encryption
key
exchange
draft
we've
proposed
three
different
mechanisms:
one
that
uses
only
encryption
primitives,
one
that
allows
you
to
combine
encryptions
and
cams,
and
one
that
allows
you
to
combine
key
exchange,
encryption
and
cams
in
increasing
complexity.
As
you
go
more
and
more
generic.
A
E
So
option
one
was
so
option.
Three
does
not
allow
you
to
specify
a
content,
encryption
key
that
mechanism.
What
you're
losing
is
you
can't
already
have
an
aes
key?
So
if
you
have
your
documents
encrypted
once
and
you
want
to
distribute
copies
of
that
asd
to
each
recipient,
then
what
you
described
doesn't
work
or
or
you
need
an
extra
layer
in
between
so
method.
A
I
Point
out,
so
we
did
in
that
encryption
part
we
we
are
making
yeah
we're
using
key
fares
so
that
each
of
the
primitives
is
signing
or
encrypting
rather
a
block.
That's
the
same
length
as
the
original
content
encryption
key.
So
I
don't
think
it's
not
like
we're
talking
about
like
you're,
not
going
to
have
the
message
getting
larger
as
you
do
more
encryption
or
anything
like
that.
E
I
don't
know
what
I'm
advocating
we've
done,
design
work.
I
want
to
put
it
to
the
group
and
start
a
discussion.
The
core
question
to
me
seems:
do
we
need
in
a
post-quantum
world
to
implement
key
trends
recipient
info,
or
are
we
okay
to
only
implement
key
agree?
I
think
that's
really
the
core
question
here.
D
I'm
going
to
say,
I
think
we
do
need
heat
transport
if
we're
combining
with
like
an
rsa
right.
So
if
you're
an
rsi
and
a
chem
pq
algorithm,
then
you
do
need
the
key
transport
and
obviously
the
the
last
one
more
for
chems
or
for
like
ecdh
or
something,
if
you're
doing
that,
with
classic
composed
quantum
two.
So
I
think
you
do
need
one
and
three,
and
one
and
two
are
really
two
is
more
of
a
more
generic
of
number
one.
So
so
it's
basically
just
those
two.