►
From YouTube: IETF115-LAMPS-20221109-0930
Description
LAMPS meeting session at IETF115
2022/11/09 0930
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
D
A
A
B
B
B
G
E
E
B
A
B
A
All
right
we're
going
to
try
and
work
around
this
problem,
while
the
Secretariat's
getting
someone
in
here
to
fix
it.
So
if
each
of
you
is
set
up
using
the
on-site,
mediko
we'll
use
the
other
one
but
muted,
we
will
you'll
at
least
be
able
to
see
slides
and
while
we're
doing
that,
we'll
get
the
slides
up.
A
A
A
E
I
H
J
K
K
H
A
And
there's
next
slide
so
go
to
like
four
at
this
point,
all
right,
all
right!
So
there's
the
agenda
as
you
can
see,
it's
super
full.
So
this
is
super
frustrating
to
have
lost
this
time,
but
the
first
batch
are
those
that
are
with
the
RC
editor
or
the
isg
I'd
like
to
just
quickly
to
go
down
those
and
see
if
the
authors
have
any
changes
to
report
with
the
back
to
the
community.
A
H
L
L
Okay,
great
thanks
slide,
please
regarding
lightweight
CMP
profile.
So
there
was
a
new
version
submitted
which
addresses
the
comments
from
Roman.
Thanks
for
that
also
the
again
art
and
other
reviews
were
addressed.
I
think
two
reviews
are
still
still
open,
but
anyhow,
the
document
is
on
the
telechat
at
first
of
December,
so
yeah.
H
L
Are
we
are
happily
waiting
for
the
results?
Yeah?
What?
What
did
we
change?
We
added
a
section
that
points
at
40
to
10
bits
and
sixty
seven
twelve
activities
just
to
let
the
people
know,
and
we
extended
the
wording
for
extra
search
to
also
contain
a
trust,
anchor
self-signed
certificates
for
those
devices
who
are
not
capable
to
store
them,
but
are
capable
to
store,
for
example,
a
hash
on
the
public
key
or
the
hash
on
of
the
certificate,
and
we
added
a
security
consideration
on
that
yeah.
A
B
L
L
So.
Regarding
4210
bits,
I
submitted
a
version
0,
which
is
mainly
the
original
RFC
text,
updated
to
current
XML
versions.
So
this
should
be
the
original
text
version
zero
one
includes
the
changes
specified
in
CMP
updates
and
then
a
version,
zero,
two
provided
changes
and
some
minor
restructuring.
The
author's
decided
that
yeah
would
make
it
clearer
while
doing
a
first
review
of
the
whole
document.
L
So
there
is
some
key
generation,
Authority
Extended
key
usage,
which
is
now
specified
in
a
new
section.
There
is
this
original
pki
message,
which
was
kind
of
yeah
specified
within
some
pki
management
operation,
and
we
pulled
that
out
to
the
section
5113
in
a
separate
section
to
properly
introduce
it.
L
We
removed
any
references
to
specific
algorithms
and
pointed
to
CMP
up,
not
CMP,
algorithms
draft.
Then
we
added
additional
references
to
the
profiles
in
appendix
d
and
e,
as
well
as
to
the
lightwide
CMP
profiles
in
the
section
5,
where
the
messages
are
described
and
we
broadened
the
scope
from
Human
users
also
to
devices
and
services.
So
just
a
wording
issue,
and
there
was
one
common
from
ID
Nets
that
we
should
switch
from
ldap
V2
to
lw3.
L
Then,
right
before
this
meeting,
I
submitted
version
3
of
the
document
where
we
fixed
two
remaining
to
Do's
one
was
on
the
specification
of
the
old,
with
new
new,
with
old
and
new,
with
new
certificates.
We
discussed
this
on
the
mailing
list
and
I
added
I
updated
the
section
accordingly,
then
we
also
discussed
on
the
mailing
list
that
appendix
see
could
be
so.
L
The
text
in
appendix
C
could
be
shifted
to
sections
of
subsections
in
section
five,
where
they
they
belong
from
the
content
perspective,
we
did
this
change
and
I'm
I'm
uncertain
whether
I
already
deleted
appendix
C
or
whether
I
added
a
to-do
that
this
has
to
be
deleted.
With
the
next
version,
I
don't
know,
I
will
find
out.
L
L
L
Finally,
the
newly
issued
certificate
is
delivered
in
encrypted
form.
Enter
hash
of
the
certificate
is
provided
in
the
search,
conf
message
as
a
proof
of
private
key
procession.
So
this
this
already
works,
then
CMP
message:
protection
using
chem
keys,
at
least
for
Regis,
for
key
update
requests
and
revocation
requests.
The
yeah
key
to
be
updated
or
to
be
revoked
should
be
used
for
message
protection.
L
L
So
the
idea
mainly
is
if
we
have
a
cam
key
on
the
client
side
that
the
client
sends
in
a
general
message.
The
type
needs
to
be
defined
and
provides
a
its
cam
certificate
to
the
CMP
server.
The
CNP
server
returns
a
cipher
text
from
the
cam
end
caps
function,
and
the
client
then
uses
this
shared
secret.
L
From
from
this
response
to
do
a
Mac
based
protection
for
the
regular
CMP
request,
so
I've
spotted
there
is
some
slight
mistake
on
the
slide,
so
the
CMP
server
should
have
a
server,
cancel
it
and
a
server,
a
private
chem
key,
not
a
signature
certificate
and
signature
key
here.
So
that
was
from
one
additional
slide.
We
were
discussing
for
situations
where
the
server
also
not
has
a
cam
but
a
signature
certificate,
so
this
can
be
extended
to
also
support
signature
keys
on
server
side.
L
M
A
So
the
issue
here
is
that
we
sent
that
update
stock
of
it
forward
in
the
isg
asked
for
a
Consolidated
document.
So
the
question
is:
do
we
proceed
with
this
and
then
do
a
cam
if
needed,
and
that's
really,
the
discussion
here
is:
do
a
proof
of
possession
for
chem
Keys
sorry.
But
if
this
mechanism
works,
we
won't
have
to
do
that.
F
Yeah,
hey,
it's
John,
Turner,
I,
guess,
I,
wonder
because
I
know
this
is
an
indirect
mechanism
and
it's
the
way
it's
been.
You
know
it
worked
before,
but
in
peacocks
we
have
a
our
Peaks.
That
was
a
great
history
of
letting
a
thousand
flowers
bloom.
Do
we
have
to
have
one
way
I
mean
this
is
the
point
that
Mike
is
making
like
it's
going
to
generate
a
bunch
of
discussion.
Is
this
the
one
and
only
way
we're
gonna?
Do
it
I,
don't
know.
F
This
is
the
way
one
of
the
indirect
was
one
of
the
ways
there's
a
direct
mechanism
right,
which
I
think
you
guys
kind
of
looked
on
on
already
and
there's
a
couple
of
other
thoughts
about
it.
So
I'm
just
saying
great,
but
you
know
we
can
think
about
this,
but
like
it's
not
that
we
have
to
get
this
update
done
like
tomorrow,
right
so.
F
Yeah
there's
some
other
there's
some
other
stuff
in
flight,
so
I'm
just
saying
it's
great
that
we
write
this
up
and
it's
an
option,
but
I
don't
want
to
say
it's
the
option
and
I
don't
want
to
like
like
by
not
objecting
now
right,
like
oh
we're,
good
we're
running
off
and
we're
done
so
there
might.
There
also
might
be
more
than
one.
So
we
just
have
to
kind
of
figure
that
out.
M
A
L
Okay,
great
so
we'll
move
forward
specifying
this
okay
thanks
next
slide,
please.
So
this
is
on
6712
bits,
so
mainly
it's
the
same
approach
with
4210,
best
version,
zero,
original
RFC
version,
one
updates
from
CMP
updates
version,
two,
a
minor
review
and
some
alignments
addressing
ID
in
its
topics.
Nothing
special
here
and
the
document
is
quite
stable.
L
H
L
F
Has
more
sorry
I'm
trying
not
to
take
the
table
out
hi?
This
is
Sean
Turner.
Just
a
minor
note.
We
do
have
an
84-46
bis
in
Flight,
which
is
almost
done,
and
so,
if
this
is
another
update,
you
should
just
point
to
the
latest
one.
So
they'll,
all
kind
of
be
I
mean
it's
going
to
create
a
cluster,
but,
like
that's,
it's
gonna
happen
shortly,
we'll
find
out
about
it
tomorrow.
What
does
shortly
mean
I?
Think
Ecker
thinks
he's
done?
Okay,
so
it
really
is
so
like
the
8446.
A
A
Okay,
skipping
that
agenda
item
the
next
one
is
RC
7030,
CSR
attributes
Michael
sent
mail
to
the
list
about
this
I'll.
Just
basically
read
it
out.
He
has
a
conflict
in
this.
This
slot,
so
he's
not
in
the
room.
There
are
still
bugs
in
the
examples
of
the
internet.
Draft
people
have
been
very
helpful
about
pointing
them
out
to
him,
and
so
he
knows
he
has
work
to
do
that.
He
expects
to
do
by
the
end
of
November.
A
A
A
H
A
E
A
D
D
Test:
yeah,
okay,
wonderful,
okay,
okay,
hello,
everyone
yeah,
despite
my
British
accent,
I
am
remote
over
here
in
the
USA,
so
I
I
hope
you're
all
enjoying
London;
okay.
So
just
a
quick
update
on
the
internet,
x509
public,
key
infrastructure,
algorithm
identifiers
for
dilithium.
We
now
have
a
repository
for
this
within
the
Labs
working
group.
Github
and
I've
got
the
link
to
the
ID
itself
as
that,
okay.
D
D
D
D
D
H
D
D
Points
I've
got
a
link
at
the
bottom
here.
These
are
all
being
tracked
in
the
issues
section
of
the
repository.
There
is
one
discussion
point
on
deterministic
versus
randomized
signing
there's
a
bit
of
some
some
discussion
within
the
Forum
on
a
new
version
of
a
hedged
mode
of
dilithium,
where
they're
kind
of
combining
the
idea
of
both
some
randomized
signatures
that
are
seeded
by
the
message
and
the
key,
alongside
a
source
of
Randomness,
to
try
and
facilitate
those
that
may
have
a
weak
random,
a
weak
source
of.
N
D
And
also,
you
know,
consider
some
side,
Channel
analysis,
so
we're
tracking
that,
and
we
might
expect
to
see
something
from
the
authors
soon.
There's
also
quite
a
discussion
about
hash
and
then
sign
we're
involved
in
an
nccoe
effort
and
will
provide
any
findings
that
we
have
there.
That's
me
and
Panos,
it's
also
been
discussed
within
the
cfrg
working
group,
the
lamps
and
the
nist
Alias.
D
So
we're
watching
that
and
basically
for
this
draft,
unless
something
happens
to
change
our
minds,
we're
lean
towards
following
the
at
DSA
x509
from
RFC
8410,
which
does
not
pre
hash,
essentially
one
last
discussion
Point
publicly
encoded
inside
of
the
private
key.
This
has
also
been
some
discussion
in
the
working
group.
D
Where
do
we
want
to
include
the
private,
the
public
key
inside
the
private
key,
or
do
we
want
to
include
values
that
Can
facilitate
the
Reconstruction
of
the
public
key
if
there
are
maybe
perhaps
lightweight
modes
that
don't
want
to
carry
both
the
public
and
the
private?
So,
as
I
said,
these
issues
are
trapped
on
the
on
the
GitHub
for
free,
so
feel
free
to
use
it
or
not.
D
O
Carl
Wallace
I
have
a
question
on
the
definition
of
the
public.
Key
is
an
octet
string.
I
know
there's
precedence
for
this,
but
it
seems
odd
to
to
give
a
definition
if
something
is
an
octet
string
and
then
immediately
in
the
pros
and
say,
throw
away
the
tag
and
the
length.
Why
not
delete
that
definition
and
just
say:
you're
encoding
the
public
key
directly
into
the
bitstring
value.
O
O
Saying
that
I'm
saying
the
octet
string
never
appears
naturally
anywhere
it's
it's
it's
an
it's
an
artifact
here,
because
I
guess
we
feel
like
we
need
to
define
it,
but
then
we
don't
actually
use
it
and
I'm
just
saying,
because
we
had
a
number
of
things
at
the
hackathon
folks
encoding
the
zero
four
and
not
encoding
the
zero
four
and
I.
You
know
I
I
get
it
where
we
have
keys
that
are
sequences.
You
have
a
structure,
but
here
we
don't
so.
B
H
D
M
Follow
up
Carl's
point
before
I
make
the
point:
I
came
up
for
so
during
the
hackathon
I.
Think
Carl.
If
I'm,
not
speaking
ill
of
you,
you
sort
of
skimmed
the
draft
and
you
saw
octet
string
the
definition
you
said
great
and
then
you
went
on
and
then
like
two
hours
later,
you
read
the
paragraph
below
it
and
we're
angry
with
your
life.
M
M
D
D
O
D
M
D
C
Hi
it's
John,
Gray
I
was
just
wondering
in
the
hash
and
sign
case,
so
I
guess
eddsa
doesn't
do
that
I.
Just
think
of
the
use
cases
like
for
hsms
or
if
I
want
to
send.
You
know
my
Gigabyte
file
across
the
network.
Is
there?
Is
there
going
to
be
a
plan
for
some
other
draft
that
addresses
that
kind
of
problem,
because
it
does
definitely
seem
to
be
a
practical
problem
that
you
know
is
all
over
the
place
so
I'm.
D
C
N
Jonathan
Hamel,
so
I
have
to
agree
with
Carl
that
I
think
that
the
that
the
byte
string
like
and
not
specifying
octet
string,
because
that's
as10.1,
but
the
bytes
that
you
get
from
the
crypto
Library,
should
be
just
directly
put
into
the
bitstream.
And-
and
this
is
because,
like
in
in
one
asymmetric
key
the
the
public
optional
public
key
in
there
is
a
bit
string.
And
then,
if
you
start
specifying
your
key,
your
your
private
key
structure,
then
that
uses
a
a
byte
or
an
octet
string
for
the
public
key.
N
P
F
E
F
F
.,
well
all
right,
let
me
just
start
so.
The
the
strap
was
an
individual
draft
and
it
got
accepted
as
a
working
group
draft,
so
we're
still
on
oo.
Basically
IO
and
update
people
are
starting
to
use
this
stuff.
I
need
to
get
off
my
butt
and
actually
produce
an
output,
and
so
this
is
just
kind
of
a
general
status
of
what's
coming.
F
Next,
this
draft
I
think
is
going
to
have
is
a
lot
shorter
than
the
the
lithium
ones,
because
it's
just
about
Keys,
it
doesn't
have
to
talk
about
signatures
and
there's
only
one
place
to
put
it.
So
it's
pretty
simple.
Next
sorry,
it
needs
an
update.
So
the
last
the
the
initial
version
of
this
draft
that
was
the
individual
draft
kind
of
was
like
we
didn't
know
what
this
was
going
to
pick.
Well,
they
picked
cam,
they
picked
one,
so
we're
kind
of
making
it
to
be
only
about
kyber.
F
So
there's
a
whole
bunch
of
text.
That's
going
to
change
that
as
a
result
of
that
we're
going
to
put
some
asn1
stuff
in
there
with
TBD
for
all
the
Lloyds,
because
we're
going
to
wait
for
this
to
assign
those,
and
then
we
want
to
make
sure
that
we
maintain
alignment
with
this,
how
to
do
in
CMS
to
make
sure
that
we
pick
the
right
recipient
info
so
that
we,
you
know
we're
still
doing
key
transport
right.
F
We
want
to
make
sure
we're
aligned
because
otherwise
the
whole
thing's
not
going
to
work
and
then,
of
course,
we
have
this
issue
with
the
private
key
format,
whether
we're
going
to
include
it,
and
we
just
talked
about
that
so
I'm,
not
I,
don't
think
we
should
really
repeat
the
thing
repeat
it.
So
it's
basically
the
same
issue
and
that's
really.
It.
F
Q
Hello,
so
Mark
gray
on
his
own.
It's
just
a
little
note
about
the
private
key
thing,
so
of
course,
in
kyber
it
has
the
difference
that
you
actually
need
the
public
key
in
order
to
do
the
decapsulation
operation,
so
at
least
in
CCA,
which
is
why
it's
being
standardized
so
so
the
private
key
will
always
have
the
public
key
and
it
would
be
better
if
it
didn't
have
it
twice.
So
it's
a
little
optimization
there
perhaps.
Q
So
in
India
lithium,
it
only
has
a
hash
of
the
public
key
and
and
the
public
key
in
the
lithium
depart
and
half
half
of
the
half
of
the
public
key
is
in
the
private
key
anyway,
like
there
are
a
little
bit
32
bytes,
so
they
so
having
having
a
keeper
structure.
You
know
it's
all
right,
but
you
don't
need
the
full
public
key
to
do
a
signature
in
deleting
okay.
H
A
A
I
C
I
I
I
I
I
would
love
to
go
reviewing
it.
It's
not
ready
for
working
group
last
call
because
there's
still
a
bunch
of
to
do
items
in
there,
but
yeah
I
definitely
want
people
to
review
it.
If
you
work
on
a
male
client
or
you
use
a
male
client
and
you
do
anything
when
you
put
the
mail,
please
take
a
look
at
what's
in
there
and
provide
feedback
happy
to
take
feedback
in
whatever
form.
I
P
P
We
introduced
a
new
type,
which
is
a
generic
cam
trans
parameters,
type
to
to
to
store
the
algorithm
parameters,
and
let's
change
is
about
the
algorithm
limitations,
because
at
the
beginning
the
RSC
was,
let's
say,
algorithm
agnostic,
meaning
that
it
would.
It
was
possible
to
use
any
cam
algorithm
and
in
this
new
version
we
limit
the
algorithm
to
kyber
and
to
the
free
security
levels
of
cable,
meaning
kyber,
5,
12,
768
and
1024.,
and
we
associate
the
corresponding
kdf
and
wrapping
algorithm
to
fit
with
the
security
level.
P
So
yeah,
that's
it
for
the
changes
on
this
latest
version
and
next
slide.
Please,
and
so
yes,
the
the
open,
Point,
there's
open
points
that
are
still
open.
So
yes,
Sean
already
addressed
that
there
is
an
open
point
about
the
certificate
convention
which
fills
have
to
be
field
in
the
certificate.
So
there
are
some
new
ideas
to
be
defined,
especially
the
IDK
Trends
oid
and
the
caliber
IDs,
and
a
developing
question
is
about
the
limitation
of
the
algorithm
combination.
P
Q
Q
The
key
expansion
is
really
the
complex
bit
for
192,
but
many
many
Hardware
bits
actually
don't
support
it
at
all,
so
so
I
would
I
would
personally
suggest
dropping
that
and
moving
that
to
two
five
six
bits
192
is
especially
aes192
is
a
little
bit
obsolete.
The
Char
3a4,
for
example,
is,
is
everywhere.
So
that's
I'm
good
with
that.
That's
cnsa,
so
suggestion.
C
You
probably
already
had
this
and
hopefully
I'm,
not
bringing
sir
going
back
circular,
but
they
can
try
and
recipient
info
I
know,
there's
another
recipient
info
and
I
guess
it
never
gets
used,
and
this
is
a
new
mechanism.
So
if
it's
not
worthy
of
using
other
recipient
info
I
guess
nothing
is
but
has
that
I
guess
that's
been
discussed
in
detail
or
I
guess
just
trying
to
figure
out
why
chem
trans
recipient
input
was
used
because
it
it
kind
of
fits
but
not
perfect.
C
A
O
C
O
A
A
K
However,
with
the
the
cam
kyber
cam
I
I,
my
vote
would
be
to
keep
the
the
kyber
768.,
maybe
because
that
that
could
be
really
good
in
performance
and
Trader,
a
security
trade-off
and
might
maybe
a
lot
of
people
are
going
to
use
that
we
just
don't
know
yet
so
with
the
AES.
The
the
story
is
very
clear,
but
for
the
cam
I'm
not
sure
about
that,
so
I
think
I
would
recommend
to
keep
the
cam
kyber
760a
in
there.
F
Sean
hi
Sean
Turner.
We
would
like
to
avoid
some
of
the
problems
we
had
with
elliptic
curve.
By
providing
too
many
choices,
less
is
probably
more
I,
don't
know
how
much
less
we
want
to
go
but
like
letting
us
you
know,
let
it
let
it
picking
picking
80
of
these
is
going
to
be
a
bat.
So
if
it's
three
or
two
I
think
we're
probably
on
the
right
magnitude
of
what
we
want,
if
it's
any
more
than
I
think
waste
of
time.
Q
Your
company,
yeah
Mark,
quick
and
so
one
thing
that
just
popped
into
my
mind,
so
kyber
at
this
lowest
level.
This
has
been
some
talk
if
the
design
team
may
actually
drop
that.
So
that's
that's
because
it's
based
on
current
analytic
results.
It
might
not
quite
meet
the
128
bit
level.
So
so
that's
something
that
mist
is
considering
of
doing
so.
That
would
basically
reassign
the
kyber
7,
the
middle
middle
as
as
the
lowest
lowest
level
here
and
I
I
was
previously.
Q
I
was
just
talking
about
the
AES,
so
so,
even
in
the
AES
based
Scarborough
variants,
which
are
temporary,
the
specification
makes
it
quite
clear
that
those
are
not.
The
final
version
will
use
shot
three
or
Shake.
Only
even
those
used
internally
as256,
so
AES,
specifically
the
AES
algorithm
is
192
bit
is
not
existent
in
kyber.
A
A
R
It
hasn't
changed
since
then
women
presented
in
Philly.
We
got
a
little
bit
of
positive
feedback.
We
got
a
lot
of
don't
care
which
actually
wasn't
surprising
and
I'll
kind
of
get
to
that
it.
It
came
up
for
adoption
and
it
was
quiet,
and
then
we
got
a
bunch
of
objections
and
I'm,
not
we're
kind
of
puzzled.
R
E
R
R
So
anyway,
that
there's
a
transition
scenario
in
the
paper,
but
maybe
it's
not
clear
or
maybe
it's
not
enough.
One
thing
is
that
this,
this
extension
is
not
a
mimic
of
of
composite
it.
Does
you
know
some
of
the
some
of
the
questions
seem
to
be.
How
are
you
going
to
address
this,
or
how
does
this
extension
do
these
things
and
it
doesn't?
It
has
a
very
limited
function
which
is
defined
in
the
draft.
R
R
The
some
of
the
questions
were
like
about
over.
You
know
how
the
validity
periods
overlap
or
revocation
things
like
that.
There's
a
really
important
questions.
This
mechanism
isn't
meant
to
address
that
this
mechanism
is
meant
to
be
used
by
DOD
units.
That
and
I
mean
it
could
be
used
by
anyone.
But
specifically
NSA
is
part
of
the
deal
I'm
I'm
from
the
NSA
Center
for
cyber
security
standards.
R
What
it
does
is
it
allows
it
allows
units
to
create
make
people
for
a
break
transition
scenarios.
It
allows
them
to
do
a
significant.
You
know
signing
for
the
widest
possible
audience,
perhaps
on
a
key
distribution
packages.
Things
like
that
I
mean
things
that
a
lot
of
people,
don't
don't
really
care
about.
R
R
R
It
is
a
it's
defined
as
a
non-critical
extension.
You
don't
like
it,
you
don't
understand
it.
That's
fine,
and
then
there
is
an
Associated
certificate,
signing
request
to
get
the
to
tool
to
give
the
ca
the
wherewithal
to
assert
that
the
private
keys
are
held
by
the
same
entity
and-
and
you
know,
you're
not
in
a
scenario
where
this
is
extension-
is
going
to
matter
to
you.
You
don't
implement
it
so
I'm
we're
not
we're
kind
of
confused
of.
R
M
M
So
let
me
bring
up
two,
maybe
that
we
can
help
drive
to
whether
this
is
worth
adopting
or
Not.
By
discussing
here.
The
first
one
is
someone
pointed
out
on
the
list
that
there
already
is
RFC
5697,
which
is
the
other
certs
extension
and
its
abstract
says
some
applications
that
associate
State
information
with
public
key
certificates
can
benefit
from
a
way
to
link
together
a
set
of
certificates
that
belong
to
the
same
and
entity.
H
R
M
R
M
So
attribute
so
I'm
here
representing
entrust
as
a
public
CA.
What
scares
me
about
this?
Let
me
start
the
other
way.
What
doesn't
scare
me
about
this?
What
I
think
in
your
draft
is
totally
reasonable,
and
so
we
can
start
with
what
I
think
is
totally
reasonable.
Vulture
the
ca
issues,
two
certs
to
someone,
here's
your
two
certs
I've
bound
them
great.
K
M
Those
two
use
cases
I
think
are
fine.
The
genericness
of
putting
this
in
a
CSR
is
I.
Think
what
opens
the
Pandora's
Box
for
me
and
as
a
public
CA,
if
we
receive
a
CSR,
entrust
receives
a
CSR
and
it's
got
a
cert
binding
CSR
attribute
pointing
to
a
digicert
cert.
What
am
I
supposed
to
do
with
that?
I
can't
copy
it
over
into
the
cert
without
validating
it,
because
on
the
ca
I
have
to
validate.
What's
in
the
CSR
I.
M
Also
don't
want
to
get
into
the
business
of
entrust
having
to
figure
out
how
to
cross
validate
certs
that
belong
to
other
public
Cas,
because
that's
going
to
be
a
nightmare.
So
in
the
context
of
Publix,
is
what
am
I
supposed
to
do
with
a
binding
request
attribute
in
a
CSR
that
that's
where
the
messiness
I
think
explodes.
R
M
R
E
E
If
you
do
get
a
request,
finding
a
certificate
to
an
entity,
that's
been
validated
by
another
organization.
I
would
think
you
exits
state
right
immediately
unless
you
have
some
agreement
on
how
to
do
that
with
the
other
organization
or
there's
some
compliance
rules.
Somehow
that
tell
you
how
to
do
that,
but
I
think
that's
just
you
just
look
at
that.
Csr
and
you
just
reject
it
and
say
you're
asking
me
to
bind
to
assert
I
know
nothing
about.
E
F
F
This
are
you
doing
anything
more
than
just
validating
a
certain
past.
Like
past
the
math
checks
like
because
I
know
like
like
you're,
not
sending
in
two
csrs
you're,
sending
in
a
CSR
that
points
to
another
certificate
so
like
when
you're
validating
the
other
sir
you're,
requesting
that
just
like
the
cert
path
validates
back
to
a
trust,
anchor
yeah.
That's
it
right!
F
So
then
I'm
kind
of
worried
about
what
is
this
other
thing
that
you
guys
think
you
need
to
do
that
public
Cas
would
need
to
do
because
all
their
all
they're
checking
is
that
it's
a
valid
certificate
that
hasn't
been
revoked.
Yes,
that's
it
right,
yeah,
so
I'm,
I'm
kind
of
like
what
else
would
you
be
validating.
R
R
R
F
M
R
Right
so
the
the
CSR
contains
something
that
is
signed
by
the
other
private
key
right.
So
the
the
the
evidence
provided
is
that
and
and
then
the
CSR
is
presumably
signed
by
the
pqc
private
key.
So
the
evidence
is
that
the
person
who
holds
the
private
key
for
the
pqc
cert
also
holds
the
private
key
for
the
ECC
cert
right.
M
S
E
E
I
would
think
that
would
be
something
you
would
want
to
do,
but
I
would
then
additionally
have
the
issue
that,
if
it's
another
organization
I
have
to
know
whether
a
my
the
way
that
I
validate
subject
information
is
compatible
and
B.
That
I
actually
trust
the
other
company's
validation.
Well
enough
that
I'm
willing
to
sign
out
on
it.
But
yes,
in
theory,
making
mandating
that
these
subjects
are
identical,
is
a
pretty
reasonable
thing
to
do.
E
E
A
S
Go
ahead,
yeah,
probably
Global,
fine
I,
think
I.
Think
a
lot
of
it's
already
been
said,
but
yeah
I
was
just
gonna
say
that
yeah
there's
definitely
a
challenge,
certainly
in
language,
if
not
in
practicality,
between
making
sure
that
what
the
proposed
RFC
would
say
is
being
guaranteed
versus
what
the
certificate
policy
says.
S
Particularly
you
know:
domain
validation
means
that
there
is
really
not
a
lot
of
guarantees
on
the
entity
that
have
been
verified
by
the
ca
who's
then
going
to
be
signing
this
and
saying:
oh
well,
there's
a
binding
here.
So
it's
the
same
person
when
really
what's
being
guaranteed.
Is
this
the
same
person
who
has
control
over
the
domain
but,
as
I
say,
I
think
it's
already
been
said.
A
T
He's
very
early
here
in
Colorado
us
so
good
morning.
Everybody-
and
thank
you
for
for
being
here
and
thank
you
for
the
opportunity
to
talk
about
this
So
today,
we're
going
to
present
on
the
composite
crypto.
Some
updates
on
that
and
the
reports
from
the
akaton
results,
so
yeah
perfect,
so
just
very
quickly.
T
What's
his
composite
composite
crypto
is
just
a
mechanism
to
combine
keys
and
signatures
by
using
the
same
data
structures
that
we
already
support
like
the
subject,
public
key
info,
just
the
sequence
of
that,
and
so
we
worked
on
the
explicit
combination
that
that
this
working
group
act
really
really
stress
the
importance
of
and
to
guide
The
pki
Architects
in
their
choice
for
the
combination
and
we
actually
removed
the
or
Paradigm
from
the
current
draft.
So
the
evaluation
policy
for
composite
crypto
only
requires
the
all
signatures
validate
correctly.
T
However,
you
know
sometimes
when,
when
it
comes
to
composite
crypto,
so
we
we
discussed
some
several
use
cases
right
for
migration
across
different
type
of
algorithms,
like
for
forward-looking
type
of
properties.
Whenever
you
don't
have
confidence
in
the
algorithms
or
as
a
migration
tool
to
provide
backward
compatibility
across,
you
know
newer
devices
that
my
might
try
to
use
the
new
algorithms
and
you
might
want
to
also
have
their
support
for
the
other
algorithms
together
without
renouncing
to
the
overall
security.
T
But
these
are
not
the
only
use
cases
so
think
about
a
composite
crypto,
as
whenever
you
don't
have
all
the
properties
that
you
require
from
an
algorithm.
You
have
the
possibility
to
combine
with
a
different
one
right,
so
I
want
to
to
make
a
very
extreme
example
of
this
use
case,
for
example,
and
let's,
let's
try
to
think
about.
T
So
many
many
different
type
of
uses
and
in
our
specific
case,
where
we
have
a
very
large
deployment
of
devices,
cryptography,
is
becoming
a
critical
component
right
in
the
device
life
cycle,
especially
in
the
consideration
that
this
type
of
problem-
we
might
you
know
we
were
very,
very
lucky
with
RSA
being
so
long-lived.
It
probably
will
not
be
that
lacking
with
the
new
set
of
algorithms,
so
we
really
want
to
be
able
to
build
in
processes
that
allows
us
to
repeat
this
process
in
a
cost-effective
manner.
T
So
there
are
many
considering
patients
that
we
need.
We
need
to
to
do
so.
Do
we
have
enough
memories
in
our
really
deployed
devices?
Will
our
protocol
supports
is
not
just
on
paper
but
on
Real
unreal
deployments
so
addressing
this?
So
this
is
just
another
example.
Let's
imagine
now
that
we
can
really
measure
and
plan
even
before
we
have
this,
this
algorithms
I
am
available.
T
So,
let's
imagine
that
we
are
actually
in
the
process
of
doing
this,
Pro,
this
and
and
to
and
and
to
transition
to
the
Next
Generation
algorithms
that
we
want
in
our
access
networks,
for
example
like
in
the
DOCSIS
one,
which
is
the
Broadband
one
or
ocf,
or
matter
that
are
new
environments
that
are
coming
coming
along.
So
we
need
to
understand.
How
are
our
networks
can
really
support
these
new
algorithms,
which
ones
can
have
better
performances,
giving
you
know
the
real
deployments
that
we
have,
and
what
about?
T
How
can
we
plan
for
device
replacement,
according
to
our
life
cycle,
for
example,
could
be
7
or
10
years
type
of
Replacements?
Let's
now
imagine
that
we
can
define
an
algorithm
X
right
that
we
could,
instead
of
using
you
know
security
for,
for
you
know,
via
signatures
and
encryption.
Instead
of
providing
this
type
of
properties,
it
actually
provides.
It
tries
to
simulate
different
type
of
algorithm
characteristics
like
the
memory
or
the
CPU
usage
and
requirements
and
collects
measurements,
maybe
in
the
form
of
signatures.
T
T
So
this
algorithm
X
can
really
simulate
different
characteristics,
as
I
said,
and
it
can
become
a
really
important
tool
for
testing
and
planning
for
replacement
for
hardware,
and
this
is
something
that
can
be
very,
very
expensive
in
some
some
environments
now
so
I
hope
that
I
I
provide
you
with
another
another
another
use
of
this
composite
crypto.
That
really
gives
you
an
idea
of
other
possible
use
in
the
future
of
this
type
of
Technology.
T
That
is
not
just
related
to
post
Quantum,
but
post
Quantum
is
really
an
interesting
use
case
for
us
so
coming
to
the
document
updates.
So
there's
major
major
changes
in
the
the
draft
for
the
keys,
especially
you
know.
Following
the
the
work
group
discussion,
we
added
the
explicit
composite
key,
a
signature
keys.
There
are
seven
new
composite
signature,
combinations
and,
together
with
three
different
composite
Camp
combinations
and
other
the
examples
for
most
of
them,
as
in
the
appendixes.
T
One
of
the
important
important
notes
is
this
discussion
about.
Should
we
keep
this
genetic
use
genetic
mode
or
you
know
all
we
need
is
really.
The
combination
of
the
algorithms
I
hope
that
the
the
example
that
I
provided
today
really
opens
up
the
discussion
of
maybe
there
are.
There
are
really
more
use
cases.
For
example,
the
explicit
one
would
be
when
you
want
to
use
an
algorithm.
That
is
not
standard,
so
you
have.
T
You
know
your
own
deployments,
your
own
data,
centers
algorithms,
they're,
not
standardized,
but
you
can
still
combine
them
with
standardized
algorithm
to
maybe
get
some
sort
of
certification,
and
you
know
we
try
to
synchronize
the
terminology
with
the
with
the
draft
for
Drisco
pqt,
a
hybrid
terminology,
and
we
really
appreciate
the
good
discussion.
That's
been
on
the
on
the
mini
list.
For
for
all
these
combinations,
so
thank
you
so
much
it's
been
really
really
great,
and
so
the
other
update
that
we
want
to
bring
in.
T
T
We
actually
removed
it
from
the
current
draft
and
we're
working
on
a
different,
a
different
document
that
we're
going
to
submit
as
soon
as
possible
that
basically
uses
the
same
type
of
approach
and
but
defines
a
new
set
of
IDs
for
the
keys
reuses,
the
same
IDs
for
the
for
the
signatures,
but
introduces
a
public
key
parameter
in
the
in
the
composite
signature.
That,
basically,
is
just
an
integer
that
says
you
need
at
least
a
K,
successful
validation
when
you
do
the
validation.
T
This
allows
you
for,
for
example,
to
achieve
the
perfect
or
authentication
mode.
If
you
use
k
equals
one
k,
equals
n
is
the
same
behavior
as
the
as
a
according
composite
and
you
can
use
you
know
intermediate
cases
when
you
have
the
two
out
of
three.
This
is
the
other
use
cases
that
we
are
pursuing,
so
the
initial
available
is
available
on
GitHub
and
we
are
going
to
upload
it
and
does
the
tracker
as
soon
as
possible.
T
So
the
other
announcement
here
it
was
at
us
on
October
26th
that
you
know
there's
there
were
some
patents
on
another
option
related
to
hybrid
certificate,
and
the
other
option
was
to
use
additional
Keys
as
encoded
in
extensions
in
the
certificates.
Now
this
the
patterns
that
that
encumber,
that
type
of
solution
they've
been
donated
and
I'm,
not
a
lawyer,
so
I'm
not
endorsing
anything
I'm.
T
Just
saying
this
was
the
announcement
please
verify
for
yourself
and,
however,
there
is
a
draft
like
the
draft
trotskowski
Labs,
PQ,
hybrid
x509,
and
maybe
maybe
this
could
be
an
occasion
to
revive
also
that
work
that
could
provide
a
different
type
of
backward
compatibility.
That
is
not
based
on
the
on
the
on
the
key,
but
on
an
extension
there
are
some
some
benefits
coming
from
that,
as
I
said
before,
and
actually
also
brought
in
in
the
in
the
chat.
T
C
H
C
Yeah,
so
this
is
John
again
so
yeah
we
had
the
hackathon
I
know
we've
heard
about
that
before,
so
you
can
go
to
the
next
slide.
So
yeah
we
had
a
lot
of
participants.
It
was
a
great
time,
I.
Think
a
lot
of
people
had
a
lot
of
fun,
go
to
the
next
slide
yeah,
so
our
main
goals
were
to
start
making
use
of
these
new
PQ
algorithms,
also
by
themselves,
but
also
in
combinations
with
the
Composites,
as
Jake
mentioned
before.
C
In
the
previous
presentation,
we
worked
on
some
of
the
asm1
encoding
issues
and
obviously
he's
he's
taken
that
and
he's
he
put
that
on
the
slides,
they've
taken
that
into
consideration
the
draft,
so
that
was
one
of
the
goals
as
well
to
give
feedback
that
way
also
to
obtain
experiences
in
these
new
algorithms
and
also
providing
an
artifact
repository
for
interoperability
testing
for
many
different
implementations.
So
you
can
go
to
the
next
slide
yeah.
So
we
have
a
GitHub
hackathon
repository,
we
kind
of
Define
this
artifact
format.
You
can
see
there.
C
It's
just
simple
object:
IDs,
because
we
they
don't
have
the
official
object
IDs.
Yet
for
these
new
algorithms,
so
we're
obviously
there's
different
sets
of
them
being
used
by
different
vendors
or
different
people
because
of
need-
and
we
have
just.
This-
is
just
an
example
that
we
have
a
different
file
format
for
different
types,
like
ca,
crls,
ocsp,
we're
going
to
add
CMP
and
others
and
hope
to
expand
that
in
the
future
we
had
Severus,
at
least
at
the
moment.
We
have
I
think
at
least
seven
different
yeah
implementations
or
providers.
C
Yeah
they're,
okay,
there's
even
nine
in
the
last
few
days,
there's
been
even
more
that
have
come
online,
so
that's
great,
so
yeah.
So
we
have
the
the
GitHub
repository.
You
can
check
that
out
and
we
Define
that
zip
structure
this
yeah.
The
other
thing
is:
we
have
a
lot
of
open
source
and
internal
vendor
implementation,
so
we
had
the
the
open
SSL
developer
on
there
as
well
bouncy
castle.
C
C
The
octet
string
thing
did
come
up,
so
I
won't
mention
that
basically
I
think
the
the
conclusion
is,
that
is,
we
don't
want
to
have
to
have
extra
encodings
of
you
know,
octet
strings
or
that
zero
zero
zero
zero
four
extra
bit.
If
we
don't
need
them,
there's
no
point
object.
Ids
need
to
be
flexible
at
this
point.
We
all
know
that
we're
waiting.
Hopefully
this
soon
will
give
us
the
final
oids.
C
One
thing
we
did
suggest
until
we
actually
have
those
things
we
could
have
an
arc
number
aversion,
because
that's
the
other
thing
there
are
tweaks
being
made
to
these
algorithms
at
this
time.
So
to
make
sure
that
we
can
interrupt
and
do
our
testing,
we
want
to
make
sure
we're
actually
using
the
same
implementation.
So
that's
one
way
that
can
be
done
at
using
oids
and
yeah.
Most
issues
that
we
found
were
not
related
to
the
PQ
algorithms.
C
It
was
just
good
old,
x509
stuff
one
one
thing
that
isn't
there
is:
there
was
a
bit
with
Falcon.
There
might
be
some
things
to
look
at
because
there
was
a
couple
little
things
that
that
came
up
with
that.
That
might
need
a
little
bit
more
looking
at,
but
that's
also
so
far.
Things
have
gone
really
well
and
I
know
that
was
the
end
of
this
slide.
I
think
that
was
pretty
much
it
yeah,
so
max
I
can
turn
it
over
to
you.
T
Oh
okay,
thank
you.
Thank
you,
John
I,
really,
thank
you
for
you
know,
being
that
champion,
really
the
akaton
would
not
have
happened
without
Jon.
So
thank
you
so
much
so,
just
to
conclude
our
our
little
little
talk,
and
so
we
think
that
actually
we
reach
some
some
level
of
maturity
that
the
work
group
is
really.
We
would
like
the
work
group
to
take
on
this.
This
work,
especially
for
the
keys
and
the
signatures
to
be
adopted
by
the
the
work
group,
we're
not
ready
for
the
koban.
T
So
that's
the
reason
why
we
we
extracted
that,
so
we
continue
to
work
on
separate
separate
on
the
koban,
and
we
hope
that
this
will
help
the
speeding
up
of
the
you
know.
The
work
group
work
on
this
front
and
last
thing
that
I
would
like
to
ask-
and
this
is
a
question
for
the
chairs,
but
really
for
the
whole
Community-
is
that
you
know,
as
as
we
are
progressing
this
work,
which
is
not
just
for
the
composite,
but
also
with
pqc
certificate.
So
it's
just
like
a
double
whammy
right
for
us.
T
You
know
trying
to
prove
the
technology
also
with
the
post,
Quantum,
and
so
one
of
the
things
that
we
are
noticing
is
that
we
are
starting
to
to
see
messages
related
to
you
know,
implementations,
Etc
and
the
question
is:
is
that
appropriate?
We
would
like
to
share
with
the
whole
Community
so
on
the
lamps
work
group.
You
know
mailing
list,
you
know,
but
we
also
aware
that
you
know
we
don't
want
to
clutter
with
implementation,
oriented
type
of
consideration.
T
So
the
question
the
question
for
for
the
chairs
is,
you
know:
do
you
think
that
it's
better
for
us
to
continue
the
conversation
like
we
are
doing
today
in
lamps?
There
might
be
some
more
conversation
related
to
implementations,
or
should
we
set
up
another
mini
list,
still
the
public
mailing
list
but
separate
from
lamps,
so
that
you
know
the
discussion
can
progress
in
parallel.
So
these
are
the
two.
The
two
questions
for
the
for
the
group
and
for
the
chairs
today.
A
F
F
Maybe
it's
just
a
philosophy
thing
and
you
know
maybe
I'm
on
my
little
little
bike
shed,
but
I
just
don't
know
if
there's
there's
really
like,
if
there's
four
ways
to
do
a
certificate,
if
like
what
are
the
public
Cas
think
what
are
they
really
going
to
do?
Are
there
actually
protocols
that
are
going
to
support
this?
Like
is
TLS
going
to
do
this?
U
I
have
the
had
the
same
knee
drag
reaction
as
I
found
not
but
x519.
It's
not
only
used
for
for
the
webpi
for
the
web.
Apk
I
think
having
this
complicated
Composites
is
not
great
and
I.
Think
actually
I
expect.
We
might
not
even
see
signature,
Composites
or
hybrids
at
all
just
for
key
agreements,
but
the
replica
is
not
the
only
thing
we
use
xl9
for
so
if
they
are
convincing
applications
where
this
is
useful,
then
I
wouldn't
be
against,
but
that's
not
my
expertise
of
other
applications.
Q
H
Q
So
it's,
of
course
not
a
mandatory
thing
for
people's
support,
but
it
is
a
technology
that
exists
and
has
been
talked
over
in
these
meetings
for
four
years
now,
and
so
in
relation
to
specific
proposals
like
going
back
to
the
izara
thing:
no
I
wouldn't
I,
wouldn't
like
that.
But
personally
you
know
it's
a
it's
a
Minefield
still
to
be
honest
and,
and
then
these
like
a
little
bit
more
exotic
proposals
here.
H
P
H
P
Yes,
well
just
one
comment,
so
first
many
thanks
for
the
work
you
you
made
during
the
academy.
It's
very
interesting,
and
one
of
the
topic
you
mentioned
is
the
possibility
to
reuse
the
treskowsky
draft.
Rac
I
would
say
that
it's
maybe
a
very
good
option
for
backward
compatibility,
and
maybe
it's
worth
yes
putting
it
on
the
table
during
the
discussion,
because
I
think
it's
an
interesting
option.
A
O
On
the
question
about
the
generic
composite,
that's
mostly
what
we
focused
on
during
the
hackathon
I,
think
that
should
be
discussed.
Perhaps
reverting
back
to
that
mechanism.
Instead
of
the
explicit
composite.
You
still
don't
need
to
let
a
thousand
flowers
bloom.
You
could
Define
a
certain
set
of
algorithms
that
are
supported
via
this
mechanism,
but
that
mechanism
is
a
little
more
natural
to
implement
support
for,
and
we
knock
out
several
implementations,
just
in
the
last
few
days
that
were
interoperable,
so
I
think
that's
a
good
argument
for
the
generic
composite.
H
Q
So
one
more
thing
so
so
this
is
a
separate
issue.
This
is
about
the
debate,
the
composite
composite
works,
but
regarding
the
the
sort
of
extension,
non-critical
extension,
which
is
potentially
proprietary
still,
I
would
suggest
that
that
might
be
something
that
is
an
informative
RFC
that
that
can
exist
so
the
so
the
those
people
who
want
to
support
this
non-critical
extension
can
can
put
together
an
important
RFC
and
that
would
kind
of
people
could
use
it
if
they
want
I
mean
it's
optional
anyway,
so
that
that's
it.
Q
Patent
released
so
that
mechanism
works
as
a
non-critical
extension
in
in
a
certificate
which
contains
the
post
Quantum
thing.
So
this
was
patented
technology,
so
they
they
released
four
translations
of
a
patent
that
deals
with
that,
specifically
so
that
that
previously
is
our
refused
to
release
that
that
IP
and
that
that's,
why
it's
not
there,
but
that's
actually,
technologically
different
from
it's
like
from
the
from
the
composite
Bieber,
interrupt
testing
already
yeah
I.
G
Hi
I
come
from
the
open,
pgp
space,
but
we
also
been
discussing
about
composite
and
like
the
flexibility
of
composite
and
in
my
opinion,
it's
it.
It
can
easily
open
up
a
Pandora
via
the
com
of
combinations
to
allow
generic
generic
like
generic
composite
algorithms.
And
furthermore,
even
if
you
restrict
the
choices,
what
do
you?
How
do
you
handle
those
who
don't
respect
these
restrictions?
G
A
T
I
When
you
embed
the
construction
into
the
certificate
wire
format
itself,
you
are
now
pushing
all
of
the
implementers
to
write
their
own
when
they
consume
a
certificate
that
has
this.
They
now
have
to
have
their
own
complex
decision-making
process
about
what
kinds
of
composite
mechanisms
are
actually
reasonable
and
actually
makes
sense,
and
every
implementation
is
going
to
choose
something
different,
because
it's
very
hard
to
specify
that,
in
a
way
that
everybody's
going
to
just
adopt
the
standard
thing.
I
This
is
a
recipe
for
interoperability.
Failure.
If
the
wire
format
itself
says:
okay,
here's
an
oid
and
it
it
this
oid
means
you
use
this
particular
combination.
Then
implementations
can
choose
to
support
that
oid
or
not
support
that
void.
So
you
can
have
the
generic
composition
logic
that
is
not
embedded
in
The,
Wire
format
and
I.
I
Think
that,
if
you
put
it
into,
if
you
put
the
generic
composition
into
the
wire
format,
you're
going
to
get
a
range
of
certificates
that
show
up
with
weird
combinations
and
every
implementation
is
going
to
have
to
decide
what
to
do
with
the
combinatorial
explosion.
There
of
what
they
receive.
And
that
is
a
mistake.
T
A
A
C
Was
just
going
to
say,
I
think
the
generic
and
the
explicit
can
co-exist
generic
is
we
learned
from
the
hackathon
too
two
implementations
we're
born
there
that
use
generic?
It's
it's
not
difficult
to
implement.
If
people
are
worried
about
you
know
the
explosion
of
combinations
I
mean
we
have
there
I
mean
that
was
proof
right
there
they're
able
to
interrupt
without
issue
the
explicit
one
that
we
took
the
feedback
for
that.
C
Because
of
the
you
know
the
comments
at
the
last
iitf
saying:
there's
you
know
this
explosion
possibility
so
with
with
that
one
you
you
do
have
to
basically
do
the
checking
to
make
sure
that
that
the
void
that
you
specify
lines
up
with
the
algorithms
you
use
so
the
I
guess
the
issue
is
I.
Think
there's
always
going
to
be
that
you
know
use
case
out
there
somewhere,
where
someone
wants
to
use
a
combination
that
isn't
in
That,
explicit
combination.
C
C
Because
we
wanted
to
to
to
have
you
know
an
option
that
was
open,
that
people
could
use
but
hearing
feedback.
We
went
to
more
explicit,
but
I
think
in
the
real
world,
I
mean
there's
always
going
to
be
those
generic
use,
cases
that
the
people
might
want
to
use.
So
that's
why
it
is
the
way
it
is
so
we're.
S
T
And
and
John
to
complement
your
argument
so
for
the
generic
one
actually,
dkg
I
think
that
your
argument
would
be
true
if
we
did
choose
not
to
reuse
the
same
data
structures
in
a
recursive
way,
so
that
choice
actually
prevents
us
from
having
really
that
problem
that
that
you
say
that
the
explosion,
because
is
actually
just
a
sequence
of
what
you
already
support.
So
the
validation
policy
is
built
in
into
the
system.
G
You'll
also
have
to
worry
about
like
a
big
metrics,
and
if
you
restrict
that
Matrix
artificially
by
saying
hey,
you
can
only
do
X,
then
just
Define,
those
X
algorithms,
because
if
you,
if
you
don't,
if
you
don't,
if
you
leave
it,
unrestricted
people
are
gonna
mix,
weird
stuff
together,
because
that's
what
fits
them
best
and
then
they
will
they're.
Gonna
have
interoperability
issues,
and
if
you
don't-
and
if
you
do
restrict,
then
you
have
the
same
situation
as
defining
them
explicitly.
T
Yeah
I
I
kind
of
disagree
with
that,
in
the
sense
that
if
you
use
standard
algorithms,
you
will
not
have
any
problems,
but
if
you
want
to
do
your
specific
ones
right,
your
your
non-standard
ones,
you're
still
allowed.
You
would
not
have
other
clients
to
validate
exactly
as
if
you're,
not
supporting
that
particular
post
Quantum
algorithm
or
that
particular
classic
algorithm.
So
it's
not
a
different
way,
so
the
way
that
you
can
actually
very
simply
limit
what
you
wanted
to
set
is
I
want
to
set
this
algorithm.
T
G
T
Well,
these
are
you
know
if
the
individual
algorithms
have
some
problems,
you
have
bigger
problems,
so
you
know
these
are
signatures
that
I
will
not
changing
the
way
that
signatures
are
performed.
It's
signatures
perform
exactly
the
same
way
and
that's
the
powerful
thing
that
the
property-
this
is
the
security
properties,
are
maintained
for
each
single
algorithm.
T
You
might
want
to
still
use
your
classic
classic
algorithm
because
you
you
validate,
that
that's
that's
appropriate
and
you
know-
and
this
is
something
that
one
of
the
things
that
we
are
worried
about,
especially
in
our
environment-
is
that
their
placement
of
identities,
especially
in
the
in
device
that
I
have
access
networks
that
we
have.
You
know
many
many
hundreds
of
millions
of
devices,
that's
where
we
really
need
to
have
a
plan
for
the
long
term
and
actually
what
we're
trying
to
do
is.
T
Maybe
you
know
when
we
whenever
in
the
future,
we
have
an
algorithm
that
doesn't
provide
with
all
the
characteristics
that
we
want.
We
might
just
just
add
these
characteristics
by
by
replacing
the
identity
of
that
device
issue
a
new
certificate.
That's
all
we
need
to
do
to
actually
add
this,
this
new,
this
new
property.
T
G
C
You're,
the
last
one
yeah
I
know
our
time
is
getting
it.
I
was
just
going
to
mention.
Kim
was
mentioned,
so
we
do
have
a
draft
for
comps
at
chem
as
well.
There
wasn't
really
any
updates
this
time
for
it,
but
the
big
thing
for
that
one
is:
we
do
have
the
question
on
the
key
combiner:
that's
why
we
made
it
flexible
on
that
draft.
C
So
if
we're
still
looking
for
feedback
on
that,
obviously
the
trivial
xor
is
I
mean
what
we
thought
you
would
have
to
do,
but
then
we
started
reading
papers
and
it
gets
into
Quagmire.
So
if
anyone
can
have
a
disc
I,
don't
know,
maybe
that's
an
ifrg
discussion
or
whatever,
but
anyway
there's
a
composite
chem
draft
and
the
key
combiners
is
kind
of
the
big
discussion
on
that.
One.
J
J
J
So
you
should
now
see
my
screen,
so
it's
basically
an
early
version
of
our
an
internet
draft
that
we
want
to
bring
forward
and
it's
based
on
some
previous
work
by
Scott,
Cura
and
Daniel
fungist,
and
it's
because
we've
talked
to
quite
a
lot
of
people
lately
who
want
to
actually
use
hash
based
signatures
in
ex-wife
of
nine,
and
it's
mostly
for
yeah
having
like
a
root
ca
for
the
pki.
So
we're
talking
about
some
secure
key
server
or
some
HSM.
J
So
some
means
of
secure
Key
Management
on
the
root
level,
and
they
want
to
use
hashbest
signatures
as
like
the
quantum
safe
alternative
for
the
classical
schemes,
and
they
want
to
use
it
for
the
root
CA,
because
you
can
trust
cash-based
signatures
right
now,
while
they
don't
really
why
they
aren't
true
what
to
use
on
the
levels
below
so
on
the
levels
below,
for
example.
Of
course,
you
could
like
use
lithium
or
something,
but
they
want
to
have
like
this
real
secure
route
C8
and
that's
what
we
want
to
bring
this
forward.
J
So
it's
some
sketches
that
we
made
and
don't
be
scared
of
what
we
did
so
far.
For
example,
you
use
asn1
sequences
for
the
data
structures
because
we
wanted
to
show
the
differences
in
the
different
schemes
that
we
provide
here
and
that's
nothing.
We
have
hard
feelings
about,
but
the
problem
is:
there's
like
a
lot
of
hashback
signatures
right
now:
there's
LMS
and
HSS
there's
also
xmss
and
xmss
Mt,
which
are
defined
by
RCS
already
by
the
cfrt
group.
Then
there's
the
stateless,
Sphinx
plus
and
the
nist
process.
J
There's
a
new
scheme
called
pyramid
that
is
quite
promising
that
overcomes
some
issues
between
xmss
and
sphinx,
plus,
which
means
you
could
have
like
one
scheme
with
a
very
small
verifier
for
a
stateless
scheme
as
well
as
a
stateful
scheme
and
they're
quite
similar,
but
still
there's
a
lot
of
difference
in
the
details,
and
we
wanted
to
have
one
document
where
we
can
have
like
a
more
unified
nomenclature,
so
more
unified,
naming
and
also
providing
like
information
about
the
differences
so
making
an
implementer's
life
easier.
In
order
to
show.
J
If
you
want
to
use
this
signature
scheme,
you
have
to
do
this
and
for
the
other
one
you
have
to
do
that
and
there's
quite
some
interest,
because
we've
talked
to
people
from
agencies
who
have
to
provide
like
an
pki
for
a
national
agencies.
We've
talked
to
trust
centers,
but
also
to
some
people
from
industry,
and
we
are
interested
if
Lambs
is
interested
in
picking
something
up
like
this,
and
if
you
have
any
other
needs
for,
like
any
other
use
cases,
and
of
course,
please
feel
free
to
have
a
look
at
it.
J
Please
tell
us
your
opinions.
As
I
said,
it's
like
more
like
a
sketch
right
now.
We
don't
have
too
hard
feelings
about
the
content.
We
will
extended,
for
example,
with
information
about
what
not
to
do
with
your
private
key
or
how
to
handle
your
priority
securely.
There's
some
more
references.
We
want
to
include
that.
In
short,
the
ideas
have
like
one
content
about
hashvest
signatures
in
x559
for
all
those
relevant
schemes
out
there,
because
we
also
know
that
there's
some
people
who
prefer
like
LMS
there's
other
that
want
to
settle
for
XMS.
A
N
N
L
J
Yeah
we
have
to
update
it
soon,
there's
again
some
questions
that
we
wanted
to
clarify.
First,
let's
like
an
issue,
that's
taking
quite
some
time
right
now
and
I'm.
Sorry
about
that,
but
there's
like
other
changes
that
are
supposed
to
come
for
xmss
and
that's
what
we
wanted
to
clarify
first,
but
hope
that
the
xcr
stuff
will
be
clarified
soon.
So
there
will
be
an
Errata.
Yes,.