►
From YouTube: IETF-LAMPS-20220420-1400
Description
LAMPS meeting session at IETF
2022/04/20 1400
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
A
A
A
C
A
C
C
C
C
So
then,
for
this
scheme
we've
tried
to
set
some
requirements,
so
here
I
mentioned
the
main:
the
two
main
requirements.
The
first
one
is
that
the
keytransport
mechanism
should
be
secure
against
quantum
computers
and
then
then
that's
what
I
said.
The
key
transport
mechanism
should
be
able
to
take
the
content
encryption
key
as
input.
C
C
So
yes,
just
to
as
a
reminder
here
we
remind
the
what
a
key
encapsulation
mechanism
is,
so
it's
a
cryptographic
algorithm
allowing
secret
sharing
and
it
consists
of
three
functions:
a
key
generation
mechanism,
an
encapsulation
function
and
encapsulation
function
and,
as
I
said
previously,
the
the
problem
comes
from
the
encapsulation
function,
which
outputs
a
random
shared
secret
and
then
it's
impossible
to
encrypt
a
fixed
content.
Encryption
key
with
with
a
with
a
cam,
as
defined
here.
C
C
C
Well,
we
will
allow
the
transport
of
the
king
data
anything
that
data
actually
so,
including
the
cms
content
encryption
key
and
we
will
be
able
to
make
this
mechanism
quantum
safe
by
using
actually
a
chem
algorithm,
a
quantum
safe,
cam
algorithm.
So
this
will
make
us
well
using
a
cam
quantum.
Safe
algorithm
will
make
the
wall
mechanism
can
trans
quantum
safe.
C
Thank
you.
So
after
defining
the
meccan
is
a
cryptographic
mechanism,
then
some
fields
in
the
cms
have
to
be
clarified.
Regarding
this
new
mechanism,
especially
so,
the
recipient
info
type
in
cms
must
be
set
to
quitting
quick
trends.
Recipient
info
and
the
following
values
have
to
be
set.
I
mean
the
algorithm
must
be
id
cam
trans
oid.
So
it's
a
new.
It's
a
an
introduction
of
a
new
oid
for
the
the
sorry,
the
game,
trans
mechanism
and
then
the
different
sub
algorithm
will
be
defined
thanks
to
a
value
of
type
generic
hybrid
parameters.
C
C
C
Thank
you.
So
still,
so
there
are
still
some
open
points
to
be
discussed,
but
mainly
minor
points.
So
the
first
point
is
maybe
the
the
the
way
to
communicate
info
about
the
key
trance
mechanism
which
is
used,
so
it
can
be
used
as
we
propose
in
this
rfc
thanks
to
the
key
trance
recipient
info,
as
it
is
done
currently
in
the
rec
game.
C
But
it
could
be
also
done
by
introducing
a
new
top
level
recipient,
m4
called
chem
recipient
info,
for
instance,
or
as
well.
We
could
use
the
existing
over
recipient
info
and
define
an
instance
of
this
over
recipient
info
as
a
camera
recipient
info,
and
then
the
other
open
points
are
about
the
certificate
conventions.
So
maybe
that
will
be.
C
Discussed
in
the
shen
rfc,
maybe-
and
the
other
points
are
so
obviously
the
new
ideas
to
be
defined.
So
we
have
two
types
of
id
that
should
be
defined:
the
idea
of
the
cam
transport
mechanism
and
also,
of
course,
the
cam
algorithm,
the
new
quantum
safe,
cam
algorithms
and
then
the
last
point
is
about
the
algorithm
limitations.
C
So,
as
I
said,
all
the
free
sub,
algorithm,
kmkdf
and
rap
can
be
chosen
can
be
chosen.
So
do
we
want
to
limit
the
algorithm
to
the
quantum
safe,
for
instance,
cam,
or
do
we
want
to
enhance
the
possibilities
to
also
support
legacy
algorithm?
So
maybe
it's
what
we
can
discuss
here,
and
so,
if
you
have
some
view
on
that,
we
will
be
pleased
to
to
discuss
this.
So
maybe
that's
it
for
this
presentation.
A
A
F
A
G
G
A
H
H
I
G
So
if
I,
I
think
what
he's
going
to
present,
what
yuri's
going
to
present
is
basically
an
xor
wrap,
but
you
still
need
to
choose
a
kdf
question
mark
the
the
thing
to
be
careful
of
here
is:
we
do
not
have
a
guarantee
that
chems
produce
a
whitened
shared
secret,
I.e
like
rsa
chem
may
have
group
theoretic
structure
or
you
know
the
first
bit
maybe
static,
or
something
like
that.
So
you
can't.
A
G
J
G
G
G
Well,
I
think,
I
think,
for
the
post
quantum
ones,
it
probably
is
true
that
they're
whitened
at
least
starting
with
round
two
or
round
three-
they
all
include
like
a
shake
as
their
last
internal
step.
So
I
think
anything
coming
out
of
nist
will
have
the
property
we
want.
I
just
think
we
want
to
be
careful
that
in
general,
like
chem
like,
if
you
make
an
elliptic
curve
based
cam,
it
might
not
have
the
prop
the
same
property.
C
Yes,
basically,
that's
that's
the
case
because
some
of
the
well
current
cams
output,
for
instance,
256
charge
bits
shared
sequence,
while
overs
output
5012
bits.
So
maybe
we
have
to
we
mandatory
to
have
a
kdf
afterwards
to
align
the
size
and
to
be
to
make
it
independent
of
the
symmetric
algorithm
that
will
be
then
used
for
encryption.
K
K
They
they
will
come
out
with
a
share
secret
of
256
bit
likely
likely.
That
is
going
to
be
so.
Whenever
you
run
the
the
encapsulation,
then
you
would
have
a
256
bits
of
shared
secrets
and
that
and
if
technically,
if
you
want
to
use
that
as
a
key
for
aes
1
256,
then
you
can
use
that
to
encrypt
the
data
that
you
want
and
then
you
need
to
send
along
the
cipher
text,
along
with
your
encrypted
data.
That
would
be
enough
for
the
recipient
to
decrypt
it.
K
The
recipient
must
have
the
private
key
and
that
privately
with
the
cyber
tax
would
be
enough
for
them.
For,
for
the
recipient
to
re,
to
generate
the
share
secrets
and
access
secrets
is
a
key
which
were
used
to
encrypt
data,
and
it
would
be
enough
to
decrypt
data
in
case.
If
you
use
as128
to
encrypt
your
data,
then
you
can
job
you.
Can
you
can
do
the
truncation?
K
You
take
one
that
can
be
a
bit
of
of
the
output,
but
knowing
that
you
by
doing
that,
you
basically
you
won't
have
more
than
120
bits
of
security
from
your
whole
scheme.
So
it's
it's!
It's
different
from
from
the
golden
icemaker:
that's
what
you
have
so
very,
very
likely
the
standard
going
to
be
the
share
secret
to
be
256
bits
for
a
cam.
A
G
E
G
K
Yeah,
so
I
I
think
site
is
it's
the
same
for
for
the
cam,
but
I
just
I
just
don't
remember
exact
sure
about
details,
but
the
cam
for
psych
is
going
to
be
to
be
the
same.
It's
around
it's
going
to
be
256
bits,
I
think,
because
for
all
the
cams,
basically
at
the
end
step
you
do
the
the
hash
on
to
generate
the
shared
secrets
and
the
hash
is
to
be
256
bits
more
or
or
512.
It
depends
on
the
hash
you
use.
K
So
yeah,
so
we
can
do
so
yeah
we
can.
We
can
do
a
wrap.
No,
you
know
too
big
to
have
the
same
logic
that
we've
been
using
with
isa.
But
if
you
we
don't
want
that
we
can.
You
can
use
the
the
key
straightly,
because
every
time
you
run
the
cam,
the
encapsulation,
you
have
a
fresh
new
shared
secret,
even
though
you.
C
Yeah,
yes,
excuse
me,
but
I
think
an
issue
in
cms
is
that
if
we
want
to
send
a
message
to
several
receivers,
usually
the
encryption,
the
encryption
key
will
be
the
same
to
for
all
the
receivers,
but
we
have
to
encrypt
them
individually
to
each
recipient,
so
meaning
that
we
have
to
be
able
to
to
to
communicate
to
communicate
a
fixed
key.
That's
why
this
key
is,
in
my
opinion,
the
cam
cannot
be
used
as
such,
because
the
cam
generator,
as
you
said,
a
unique.
C
A
K
L
K
And
and
if,
if
with
that
is
the
same
functionality
with
using
ski
straightly,
so
even
in
the
case,
if
you
would
like
to
generate
unique
key
for
each
recipient,
but
they
are
generated
from
the
same
shared
secret,
then
the
recipient
can
can
generate
the
keys
belong
to
the
order.
The
other
recipients
you
know
by
by
we
run
the
hash,
because
every
recipient
gets
the
share
secret
and
from
there
each
discipline
can
generate
the
other
keys
belonging
to
the
other
recipients.
A
G
A
H
The
slide
is
on
the
way
and
using
the
simple
approach
depicted
on
the
slide
which,
by
the
way
we
used
a
couple
of
decades
ago,
using
that
approach
you
can
use
you,
you
can
a
a
use
post
quantum
s
mime
at
the
cost
of
additional
256
bits
per
each
recipient
eras.
Please,
let
me
know
when
you
receive
my
email.
K
K
C
K
K
It
it
it
looks
okay
right
now,
but
I
I
I
can't
say
something
with
a
short
tone.
You
know
in
a
minute
or
something
like
that
when
they
look
at
something
yeah,
I
think
we
we
we
need
to
to
to
think
about
it
over
the
the
email
list
and
and
then
come
back
to
it
whenever
we
we
later
come
to
it
later,
but
it
looks
okay.
It
looks
okay
to
me.
K
H
K
I
I'm
not
I'm
not
saying
I'm
not
saying
there
is
a
problem.
I'm
just
saying
I
would
like
to
think
I'm
not
saying
that
there's
a
problem
I
I
say
it
looks
okay
to
me,
but
I
would
like
to
think
about
about
some
something
a
little
bit
new.
I'm
not
saying
there's
any
problem,
I'm
not
I'm
not
saying
that
I
I
said
it
looks
okay
to
me,
but
I
would
like
to
think
about
it
from
different
perspectives,
different
angles,
different
attack
scenarios
and
before
I
feel
comfortable
about
it,
I'm
not
saying
there
is
problem.
H
E
E
E
H
G
G
So
the
draft
right
now
is
full
of
you
know.
Algorithms
covered
are
candidate,
tbd1,
the
encoding
for
the
public
key
and
private
key
are
also
provided.
So
it's
just
a
placeholder
draft
to
stick
lloyd's,
public
key
and
private
key
encodings,
and
then
the
open
clash.
Yeah
he's
got
open
questions
defining
oids
in
front
of
parameters.
You
need
to
find
key
usages
and
I
think
sean
has
made
some
opinionated
decisions
on
a
couple
of
these
points.
H
A
H
K
K
K
K
So
if
I
guess
the
bit
for
the
set
the
bit
for
the
chassis
that
wrong,
then
the
other
one
got
to
be
correct,
so
either
one
of
the
two
losing
value
losing
that
security.
So
and
that's
how
you
lose
half
of
this
a
bit
of
security
from
from
the
construction,
so
you
cannot
use
excel.
You
have
to
do
encryption.
A
G
A
G
Done
much,
but
we
have
a
bunch
of
changes
that
we've
been
working
on
with
our
authors
group.
So
I'll
I'll
tell
you
what
changes
are
coming
with
composite
keys,
o2
I'll
tell
you
what
changes
are
coming
with
composite
chems,
0
0,
which
we
haven't
published
yet
and
then.
Finally,
let's
talk
about
terminology
and
whether
the
word
hybrid
is
problematic
next.
G
So
these
are
the
current.
This
is
the
current
state
of
published
drafts,
compositekeys01
explicit
compositekeys01.
So
that's
the
completely
generic
stuff
in
any
oids.
You
want
at
runtime
version
versus
the
define
oids
for
explicit
pairs
version
composite
606.,
that's
the
one
that
we've
has
been
in
the
queue
the
longest
and
then
composite
encryption.
O1
we
did
sort
of
is
much
newer.
I
figured
we
should
cover
content
encryption
also.
G
G
We've
got
a
keys
02,
the
major
difference
being
that
we've
rolled
in
we'll
get
to
the
major
difference
in
the
next
slide,
but
we've
basically
rolled
explicit
and
generic
together
into
one
draft
and
there's
a
few
other
changes
thanks
to
our
co-authors
at
d
trust
composite
sigs.
I
don't
think
we
have
immediate
plans
to
do
another
revision
of
that,
although
we
do
need
to
do
some
minor
work
to
sync
it
up,
especially
once
we
roll
in
explicit
we'll
need
to
do
some
minor
work.
A
G
G
So
keys
changes
from
o1
to
o2.
We
tried
to
keep
this
backwards
compatible.
I
know
there
are
some
vendors
entrust
included
who
are
starting
to
have
commercial
offerings
that
include
composite,
and
so
we've
tried
to
keep
it
backwards.
Compatible
that
keys
produced
under
the
o1
draft
will
still
parse
with
the
same
semantics
under
the
o2
draft
working
copies
in
github,
but
the
link
below
feedback
is
absolutely
welcome.
G
So
here's
the
big
changes
so
we've
merged
dtrust
had
an
intelligent,
composed
algorithm
draft
from
what
was
it
may
2021.
So
it's
been
out
for
a
year.
It's
almost
identical
like
I
think
I
think
our
draft
and
detrust
draft
would
almost
be
binary
wire,
compatible,
they're,
so
close,
and
so
the
fact
that
two
groups
not
aware
of
each
other's
work,
came
up
with
the
identical
solution.
I
think
is
good
news
that
we're
on
the
right
track
here.
G
A
G
Does
it
mean
the
signer
has
to
use
all
their
keys,
but
the
verifier
is
only
is
allowed
to
only
verify
one
signature.
Does
it
mean
the
verifier
has
to
verify
them
all,
but
as
long
as
one
passes,
you're
good,
so
I
think
or
the
semantics
of
or
is
still
not
totally
clear,
and
when
I
hear
presentations
different
people
seem
to
refer
to
it
in
different
ways.
G
So
we're
trying
to
we
defined
any
to
try
and
differentiate
any
in
custom
to
try
and
add
more
differentiation,
but
I
think
we
probably
haven't
quite
got
to
the
bottom
of
that
and
we've
also
added
the
k
of
n
mode,
which
is
out
of
d
trusts.
Intelligent,
compose
algorithms
draft,
so
k
of
n
would
say
you
know,
here's
five
keys,
you're
allowed
to
use
three
of
them,
and
we
would
specify
that
in
the
public
key
next.
G
So
why
are
encodings
the
in
so
now
the
the
wire
encodings
that
are
shared
by
explicit
and
generic
will
be
in
the
upcoming
draft.
In
both
cases,
they
are
a
sequence
size
2
to
max
of
subject
public
key
info
for
the
public
key.
The
private
key
is
a
sequence
2
to
max
of
one
asymmetric
key
in
the
generic
case,
the
top
level
algorithm
identifier
is
id
composite
key
which
we're
just
going
to
define,
and
then
the
component
algorithms
can
be
anything
at
runtime.
G
A
G
So
here's
a
bit
squinty
and
meat
echo,
but
here's
what
this
looks
like
on
the
wire.
So
your
generic
case,
the
top
top
algorithm
identifier,
is
your
id
composite
key
params,
we're
currently
using
params
to
carry
the
combiner
mode
so
I've
here,
I've
done
it's
mode,
id
composite
or,
and
then
the
composite
public
key
is
a
sequence
of
subject
public
key
info.
So
you
just
stick
in
your
normal
ec
public
key
and
you
stick
in
your
normal
rsa
rsa
public
key
and
there
you
go
explicit,
is
identical.
G
G
G
You
need
to
carry
that
integer,
and
so
we
need
somewhere
to
put
that
and
so
that
forced
us
back
down
the
path
of
needing
a
top
level
algorithm
id
parameter.
So
here's
here's.
Our
current
proposal
is
and
is
implicit
via
an
absent
parameter.
So
if
you
leave
the
parameter
absent,
it's
assumed
that
it's
the
strictest
and
mode
and
then
we've
defined
oids
for
or
any
k
of
n
carries.
An
integer
which
is
k.
G
A
G
N
G
Yeah,
that's
a
fair
question.
Does
the
signer,
or
in
fact
the
ca
issuing
the
signer's
key,
have
a
right
to
specify
this
policy?
That's
a
fair
debate.
Question
the
the
real
motivator
for
putting
this
in
the
public.
Key,
though,
is
this
cms
encryption
use
cases
you
go
fish,
someone's
encryption,
cert
out
of
a
directory
and
you
need
to
know:
are
you
allowed
to
send
a
top
secret
payload
with
only
using
one
of
their
public
keys?
G
L
I
wanted
to
echo
michael's
suggestion
that
you
know
that
maybe
it's
mostly
on
signatures.
This
comment
that
I'm
gonna
make,
but
I
think
adding
this
logic
here.
This
logic
that
we
have
not
done
before
or
any
or
k
of
n
adds
a
lot
of
complexity
and
we
shouldn't
do
it.
I
think
this
should
be
up
to
the
very
fire
to
decide
if
he
wants.
L
G
So
we
debated
quite
a
bit.
I
mean
we've
gone
back
and
forth
whether
the
absent
the
implicit
by
absent
should
be
an
and
or
an
or
or
a
do
whatever
you
want.
Panos.
Would
you
mind
starting
a
mail
list
discussion?
That's
probably
the
right
place
to
discuss
this,
I'm
happy
to
change
the
draft.
However,
the
community
wants
panos.
Are
you
willing
to
start
that
thread
for
me.
L
G
G
And
the
the
counter
use
case,
I
think,
is
max
palace
use
case
where
he
wants
to
be
issuing
devices
that
may
or
may
not
know
how
to
use
all
their
keys
yet
like
he
may
want
to
issue
certs
to
devices
that
haven't
been
patched
yet
yeah,
but
but
maybe
that
needs
to
get
off
the
ore.
Maybe
that's
not
an
ore,
maybe
that's
an
annie.
H
G
O
G
G
Another
option
is
this:
doesn't
belong
in
the
public
key
at
all,
maybe
these
modes,
the
modes
obviously
belong
on
a
signature
algorithm
to
state
what
you
did.
We
also
need
to
think
about
the
encryption
case.
How
do
you
convey
to
an
encrypter
that
you
only
want
to
receive
data
under
a
certain
mode?
You
know,
don't
don't
send
me
data
using
only
my
rsa
key.
H
J
Yeah
I
mean,
since
the
discussion
on
this
k
of
n
mode
continues
here.
I
just
want
to
say
the
words
to
this
as
designer
I
or
the
issue
of
public
key
or
signature.
I
want
to
make
sure
under
which
conditions
my
signature
is
valid,
and
I
think
this
is
important
information
that
needs
affair
that
is
needed
by
a
verifier
and
that's
why
we
need
to
put
it
here
just
by
the
text
and
continuous
onto
the
waiting
list.
Okay,.
G
J
Okay,
I
mean,
as
some
guess
already
we
explained
alright.
This
is,
I
think,
not
sure
if
this
adds
any
more
information
or
we
have
an
and
certain
number
of
keys
n
and
a
certain
number
of
keys
used,
which
is
defined
by
says
this
is
a
k,
so
we
can
talk
about
how
this
will
be
used,
but
from
my
opinion,
I
think
we
can.
Let's
go
to
the
next
slide,
for
example,
for
for
for
signatures
in
pkis.
J
So,
with
the
k
of
n
mode,
we
we
can
combine
the
flexibility
of
an
end
mode
with
the
security
of
an
or
mode.
So
we
still
have
like
two
signatures
that
needs
to
be
verified
in
order
that
the
signature
is
valid,
but
if
one
of
the
signage
of
the
three
signatures
is
broken
because
it's
quite,
we
see
a
with
a
pqc
algorithms
to
this
uncertain
future.
J
F
H
H
J
J
H
J
H
G
H
G
P
J
Definitely-
and
this
is
usually
also
now
not
done
in
in
pki
structures,
so
that's
not,
I
think,
the
scope
of
this
group
most
probably,
but
there
are
ways
that
something
is
still
deep
created,
for
example
national
catalogues,
for
algorithms,
at
least
in
germany.
This
is,
of
course
done
and
sebastian.
E
R
Suppose
my
kind
of
short
thought
statement
is,
I
think
this
adds
an
awful
lot
of
complexity
and
therefore
risk
of
like
implementation
and
logic
errors.
I
think
it's
particularly
hard
to
follow
when
it's
because
of
kind
of
what
we're
talking
about
earlier,
because
this
is
tied
to
the
key
rather
than
to
the
signature
or
the
certifica
or
the
chem.
R
So
it's
a
little
bit
hard
to
kind
of
understand
what
the
security
flaws
are.
I
suppose
I
think
the
example
was
given
here
of.
If
an
algorithm
was
found
to
be
broken,
then
you
could
not
reissue
certificates
and
so
like
you
could
just
use
the
other
two
algorithms
and
I
suppose
in
that
case
I
think
it
would
be
easier
to
update
the
certificate
than
to
update
both
the
server
and
the
client
say
that
a
particular
algorithm
is
broken.
J
S
It
just
seems
weird
to
me
that
the
signer
is
going
to
dictate
to
the
receiver
that
they
should
verify
two
of
the
three
to
any
any
two
of
the
fee
and
this
the
motivation
for
all
this
is
the
post
quantum
algorithms,
which
are
new,
and
even
this
k
of
n.
It
doesn't
offer
you
a
way
to
play
at
least
one
classic,
and
at
least
one.
J
S
S
G
So
I
I
think,
if
I'm
going
to
continue
the
presentation,
the
summary
here-
let's
let's
do
it
on
the
list,
so
it's
available
to
more
than
the
32
people
in
this
meeting.
But
it
sounds
like
for
signatures.
It
doesn't
make
any
sense
and
for
encryption
use
cases
it
there's
not
really
a
strong
need,
and
so
it
really
shouldn't
be
in
the
public.
Key
seems
to
be
the
consensus
here.
So
let's
take
that
to
the
list
and
we
can
update
accordingly.
D
Yeah,
so
I
just
so,
I
guess
I've
been
hearing
a
lot
of
the
argument
that
the
relying
party
is
the
one
that
really
cares,
whether
that
really
decides,
ultimately,
whether
they
trust
a
signature
and
obviously
I
think
that's
true,
but
there's
the
I
think,
there's
a
counter
argument,
maybe
for
the
the
non-repetition
aspect
of
signatures
right
where
we,
the
I
guess,
if
I
hold
a
key
pair,
then
I
want
to
make
sure
that
when
somebody
thinks
I've
signed
something
I
really
have-
and
I
don't
want.
You
know
things
that
are
not
my
signatures.
D
D
Now,
I
guess
that's
the
ca,
I
don't
think
you
get
to
control
which
well
I
guess
you
can
pick
the
algorithm
yeah.
So
so
it's
possible
yeah.
So
I
guess
maybe
you
say
you.
You
have
a
key
pair.
That
is
the
combination
of
algorithms
and
then
you
say-
and
this
is
a
you
know-
ecdsa
with
sphinx,
keypair
and
picanoid-
for
the
signature.
That
is
a
yeah.
So
maybe
that's
you
know.
Maybe
that
still
works.
G
D
So
what
in
the
key
you
say
this
is
an
rsa
key
or
you
say
this
is
an
rsa
pss
key
and
I
think
that's
the
difference
right
that
so
so
we
can
imagine
in
the
key
saying
this
is
a
key
for
rsa
sphinx
in
and
mode
right,
as
opposed
to
saying
this
is
just
a
collection
of
keys
that
happens
to
be
rsa
and
and
sphinx,
and
you
can
pick
whatever
signature
algorithm.
You
want.
G
So
last
two
topics:
I
have
one
slide,
each
so
composite
chems
I
mentioned
at
the
top
that
we
have
a
chems-0
that
we
haven't
published
yet
looks
like
this.
It's
we're
basically
going
to
define
a
composite
composite
content,
encryption
scheme
and
we're
going
to
wrap
it
up
to
look
like
a
chem,
and
so
then
it
should
fit
with
fit
nicely
into
the
draft
that
game
presented
earlier
and
we're,
I
think,
doing
the
obvious
thing
here.
G
We
do
have
a
couple.
We
have
a
couple
open
questions.
Maybe
I
won't
burn
time
going
over
them
here,
I'll
leave
that
to
the
reader.
If
you
want
to
look
at
the
slides,
but
I
think
this
is
fairly
straightforward
and
an
improvement
over
what
we
presented
earlier.
So
we'll
get
this
polished
up
and
posted.
G
So
we'll
say
to
that
point
to
my
eyes:
this
is
in
sync,
with
the
tls
hybrid
chems
work.
I
believe
it's
in
sync.
I
mean
with
the
differences
that
it's
got
it.
It's
got
to
transport
a
predict
like
a
predetermined,
c
c
e
k,
whereas
tls
just
rolls
into
the
key
schedule,
but
I
think
it's
as
synchronized
as
it
can
be.
Douglas
stabila
has
looked
over
it
and
didn't
have
any
meaningful
feedback
for
whatever
that
means,
but
yeah.
I
think
we
do
need
to
keep
these
in
parallel.
A
R
R
I
think
the
all
the
words
that
sort
of
fit
are
overloaded,
so
eva
will
wake
up
some
new
words
or
we
you
end
up
with
some
quite
unwieldy
sentences
like
post
quantum,
classical
multi-key,
algorithm
signature
or
something
like
that
which
doesn't
seem
great
either.
So
if
people
on
this
call
do
have
particular
opinions,
I'd
be
really
keen
to
talk
about
your
thoughts,
and
hopefully
we
can
get
something
that
everyone
agrees
on
and
go
from.
There.
B
Yeah,
I
agree
that
the
the
term
ebridar
duo
is
overloaded,
but
at
this
point
they
are
still
way
well.
They
are
now
widely
used
and
so
I'm
afraid
that
it's
maybe
too
late
too
late
to
change
the
terminal,
but
still
yeah,
I'm
agree
is
what
you
said,
but
I'm
just
a
bit
afraid
that
it's
no
it's
too
late.
A
R
A
A
T
Hello,
so
I'm
gonna
just
talk
about
both
of
these
sort
of.
In
conjunction,
so
we
wrote
two
drafts,
there's
an
informational
draft
and
a
technical
draft
and
the
informational
draft
it
just.
It
formally
introduces
a
concept
that
ali
discussed
at
the
last
lamps
interim,
which
is
basically
a
framework
for
hybrid
solutions
that
that
we're
sort
of
looking
at
all
of
this
with
and
so
sort
of
breaking
hybrid
solutions
into
two
categories:
one
composite
and
one
what
we're
calling
non-composite
solutions
and
so
composite
solutions.
T
You
know
we've
been
talking
about
for
a
while.
Non-Composite
solutions
are
sort
of
an
alternative
to
composite
solutions,
and
so
the
way
they
work
is
instead
of
changes
being
made
within
cryptographic,
libraries
and
with
the
format
of
these
cryptographic
structures.
Changes
instead
are
being
made
to
protocol
logic
and
so
maintaining
the
structure
of
certificates,
signatures
keys
and
instead,
specifically,
it's
sending
multiple.
F
T
T
It
gives
an
overview
of
a
couple
issues
that
might
arise
with
non-composite
hybrid
solutions,
and
then
we
also
take
a
quick
look
at
how
non-composite,
hybrid
authentication
can
work
with
ikv2
and
tls
1.3,
and
so
that's
the
informational
draft.
I
guess
I'll
pause
and
if
there's
questions
about
that
before
moving
on
to
the
tactical
draft.
G
O
O
T
T
H
G
Dear
the
non,
what
you're,
calling
non-composite
or,
what's
previously
called
multi-cert
is
I
mean
it's
good.
I
think
it
needs
to
be
defined,
so
it's
great
that
you've
defined
it
in
some
cases,
it's
probably
fine
for
the
two
certs
to
be
completely
decoupled,
come
from
different
cas
blah
blah
blah
the
client
can
handle
that
the
binding
mechanism
you've
defined,
I
think,
also
probably
has
value
in
some
cases
where
you'd
want
to
assert
that
these
two
certs
belong
together.
G
G
The
debate
that
I've
read
through
on
the
mailing
list,
particularly
from
ryan
sleevy,
and
a
lot
of
my
comments,
are
to
focus
on
the
same
is
there's
a
lot
of
edge
cases.
There's
a
lot
of
sort
of
sharp
and
pointy
edge
cases
with
the
bindings.
What,
if
you
bind
what,
if
you
bind
a
key
exchange
key
to
a
signing
key?
What
does
that
even
mean
what,
if
you
bind
keys
from
issued
under
very
different
cert
policies?
What
if
you
bind
like?
T
H
H
S
So
I
think
the
sharp
edges
that
mike
mentioned
we're
bound
to
get
them
they're
always
there,
and
the
real
question
is
whether
we
want
to
handle
them
in
the
pki
part
or
in
the
protocols
tls
or
mike,
and
that's
a
good
question,
I'm
tending
towards
the
icon
tls,
which
points
me
to
non-composite.
But
I
think
that's
really
worth
a
lot
of
discussion.
T
Definitely,
and
based
on
some
earlier
discussions,
we've
had,
there
seems
to
be
maybe
a
benefit
in
different
use
cases
to
doing
this
type
of
decision
making
in
a
protocol
versus
in
a
different
area,
and
so
I
think,
iqv2
for
example.
It
seems
like
a
very
good
place
to
bump
this
to
the
protocol,
and
so
there
there
is
another
draft
actually
in
the
ip.
Second
me
working
group,
which
discusses
how
to
do
non-composite,
hybrid
authentication
in
ikv2.
O
The
close
like
protocol
approach
well,
it's
like
only
for
like
single,
like
no
competitive
or
single
protocol.
Right
like
we
are
not
assuming
like
you,
are
not
assuming
to
use
same
key
or
like
seven
different
protocol,
but
like
this
discussion
is,
for
example,
like
use
like
two
certificates
for
single
protocol,
so
not
discussing
about
like
close
protocol
things,
and
that
is
outside
the
scope
of
this
document.
O
So
so
like,
for
example,
if
you
are
using
same
key
for
different
protocol,
it
will
be
like
there
something
wrong
might
be
happen
but
like
if
you
are
using
different
key
for
like
single
protocol
like
like.
Usually
it
usually
doesn't
matter
so
like
my
understanding
is
use
like
this
document
is
saying
about
like
use,
different
key
for
same
protocol
and,
for
example,
and
and
then
using
the
same
key
for
a
different
protocol
is
auto
outside
the
scope
of
this.
Like
document
right.
O
H
H
G
E
G
H
G
Right
yeah,
I
I
still
think
it's
sort
of
useful
to
do,
though,
what
they
call
composition,
analysis,
you
know,
just
to
sort
of
you
know,
might
as
well
convince
ourselves
that
it's
safe
to
combine
arbitrarily
if
we,
if
we
can,
whether
yeah,
whether
there's
actual
practical
attacks
that
come.
If
you
don't
have.