►
From YouTube: IETF114 LAMPS 20220727 1400
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Everyone
all
right,
let's
go
ahead
and
get
going,
welcome
to
the
lamps
working
group
that
ietf
114.
A
Remind
you
first
of
the
note:
well,
please
make
sure
you
understand
your
rights,
Privileges
and
responsibilities.
According
to
these,
please
don't
contribute
until
you
do.
A
Of
course
it's
my
brother
has
a
friend
of
me
about
the
sun,
so
please
follow
the
iitf
code
of
conduct
and
you
know
basically
treat
each
other
with
respect
and
that
will
lead
us
to
the
better
technical
solution.
We
don't
want
to
lock
anyone
out
of
the
discussion
and
at
this
particular
meeting.
In
addition,
please
wear
your
mask
in
the
session
and
only
the
presenter
should
be
maskless.
A
We
have
a
long
agenda,
but
it
turns
out
some
of
the
things
are
not
going
to
happen
today,
so
we
might
actually
get
through
it.
We'll
see
the
first
group
of
documents
or
the
things
that
are
with
either
the
RFC
editor
or
the
isg,
and
so
we'll
only
be
talking
about
those
in
terms
of
what's
changed
as
they've
gone
through
the
process,
then
in
the
pkx
related
documents
just
a
day
or
so
ago,
Tim
declared
that
we've
reached
consensus
on
3709
fifths.
A
So
the
only
thing
we're
waiting
for
that
to
move
to
the
higher
category
is
the
shepherd
right
up
and
the
next
one's
the
yes
Mom
documents.
We
have
not
seen
those
documents
updated
since
the
last
ietf.
So
there's
probably
not
much
that
we'll
be
talking
about
today.
B
No
I
just
wanted
to
so
romantic
if
you
could
flip
back
a
slide.
I
just
wanted
to
say
kind
of.
Thank
you
for
everyone.
With
the
agility
we
had
on
the
lamp
CMP
kind
of
update.
When
we
went
to
the
isg,
we
got
some
feedback
on
the
editorial
style
and
the
and
the
length
of
time
in
the
in
the
old
kind
of
new.
It
was
explained
kind
of
how
we
got
there
kind
of
organically
as
a
process
there's
still
kind
of
a
little.
There
was
still
a
little
bit
of
a
rub.
B
C
B
A
Bulk
of
that
thank
you
goes
to
Hendrick
foreign
and
then
there's
a
whole
slew
of
documents
that
we're
going
to
consider
for
adoption
and
of
course
most
of
them
are
post
Quantum
related
there's
a
couple
that
are
not
my
intent
is
to
deal
with
in
terms
of
processing
them
deal
with
the
not
pqc
related
ones,
first
to
get
them
off
the
plate
and
and
then
the
pqc
ones.
A
We
have
a
little
more
Runway
we're
waiting
on
nist
and
so
on,
but
the
the
order
somewhat
reflects
that
and
then
some
other
things
came
in
at
the
end,
so
we'll
deal
with
them
as
they
do
any
agenda.
Bashes.
D
Hi
Russell
I
have
something
Clint,
Wilson
I
know
there
won't
be
time
to
talk
about
it
today.
So
I'll
send
this
over
to
the
list,
but
I
have
a
5019
this
that
I
plan
on
submitting
just
to
kind
of
update
the
sha-1
requirement
in
that
RFC.
A
Okay,
yeah
so
I.
Okay,
that's
news
to
me,
but
please
please,
send
it
along
and
please
post
something
on
the
list.
D
E
A
F
We
got
an
update
done.
We
had
some
minor
clarifications
that
were
requested,
so
we
did
that
and
so.
A
Okay,
so
I
saw
the
document
was
posted
yesterday,
I
looked
at
the
diff
I
hope
others
did
too,
but
they
were
basically
all
to
address
comments
from
Roman.
If
I
remember
right.
B
G
H
A
The
8410
KU
clarifications
is
there
anything
to
share
with
the
group.
A
I
Yeah,
hello,
thanks
we're
getting.
A
I
Thanks
yeah,
first
of
all,
thanks
for
Roman
for
his
mentioning
the
efforts
on
pushing
the
CMP
updates
through
isg
review
next
slide.
Please.
I
I
I
Next
slide
CMP
updates,
so
there
was
some
discussion
in
iesg,
so
the
end
of
March,
end
of
May
iesg
didn't
approve
it,
and
there
was
mainly
discussion
on
the
style
of
the
document
next
to
a
number
of
minor
editorial
stuff
and
yeah.
As
Roman
already
said,
isg
requested
that
we
provide
a
4210
bis
document
and
yeah.
If
we
do
that,
I
would
also
propose
to
provide
a
6712
business
document.
Scmp
updates
also
update
this
RFC.
I
We
discussed
this
already
last
ietf
and
I
will
come
back
to
to
this
topic
on
my
last
slide,
so
I'll
yeah,
just
since
last
ITF,
we
updated
as
discussed
at
IDF
113,
the
well-known
pass
and
the
definition
of
the
pass
segment
PE
for
profile,
RCA
names
good,
likewise,
TMP
profile,
there
were
some
minor
updates
since
last
ITF.
I
Also
some
clarifications
coming
from
implementations
and
alignment
with
CMP
updates
regarding
the
well-known
pass
segment
and
some
editorial
stuff,
but
nothing
much
to
to
say
about
it.
Yeah
we
are
waiting
for
a
d-review
and
looking
forward
to
the
valuable
feedback
will
will
probably
receive
Roman.
Can
can
you
say
anything
about
when
you
think
you
will
have
time
to
to
work
on
this.
B
Hi
this
is
Roman
yeah,
that's
a
fair,
fair
question.
It's
the
next
one
in
my
review
queue.
It's
just
been
hard
getting
through
the
previous
documents,
so
I
think.
If
you
give
me
a
week
or
two
after
after
the
ITF
I'm
gonna
spin,
it
back
up
yeah.
I
That's
funny
good,
coming
to
4210
bits
and
67
12
bits,
as
already
mentioned
this
was
on,
is
on
request
of
iesg.
They
regarded
the
style
of
old
text.
New
text,
as
CMP
updates
was
written
as
yeah,
not
not
well
for
implementers
to
read.
I
fully
understand
this.
So
in
the
beginning
that
was
a
decision
we
took
for
this
document
as
we
didn't
plan
to
do
a
general
update
of
CMP,
but
only
some
changes
and,
to
be
honest,
there
are
only
two
real
changes.
I
One
is
on
exchanging
enveloped
encrypted
value
with
envelope
data
and
the
second
is
to
add
an
explicit
hash
elk
oid
in
the
set
conf
message.
I
All
the
other
stuff
is
either
fixing
errata
or
adding
some
new
oids
were
already.
Flexibility
was
foreseen
like
for
General
messages,
for
example,
or
defining
an
ex
extended
key
usage
value
so
yeah.
Now
we
we
have
the
situation
that
we
we
have
to
provide
these
documents.
I
welcome
everyone,
especially
those
who
were
involved
in
writing
the
original
RFC.
I
But
that
is
it
what
we
would
plan
to
to
provide,
but
from
the
feedbacks
from
iesg
Members
I
understood
that
there
will
be
some
complete
review
of
the
documents,
the
best
documents
and
therefore
I
would
expect
that
there
will
be
some
further
discussion
going
on
and
I
feel
like.
We
need
help
of
the
original
authors
to
get
that
input
on
those
design
decisions
back
2005
in
the
discussions,
because
we
do
not
want
to
define
a
new
certificate
management
protocol,
but,
let's
say
only
do
some
adaptations
to
CMP
where
needed
for
the
lightweight
profile.
I
At
least
that
was
the
original
aim.
Therefore,
everyone,
especially
those
authors
from
the
original
rfcs,
are
welcome
to
join
in
I,
send
out
an
email
to
those.
Last
week,
but
didn't
get
any
feedback
yet
so
any
feedback
is
welcome
also
if
they
step
back
from
co-authoring,
that's
also
good,
but
then
I
at
least
know
and
yeah
do
not
miss
some
some
feedback
yeah.
So
that's
it.
There
are
people
in
the
queue
so
Mike.
J
Ellsworth
I'm
a
co-author
on
this
I,
just
wanna
I,
really
want
to
highlight
what
Hendrick
just
said:
I
mean
opening
up
this
up
to
Abyss
I
think
is
going
to
open
up
questions
like
why
not
TLS.
Why
not
hpke?
And
within
the
author
group
we
have
some
historical
knowledge
here,
but
probably
not
enough
to
field.
All
of
that
so
help
from
the
working
group
to
deal
with
whatever
comes
out
of
review.
Please
so.
A
All
right
completely
agree
that
this
is
a
document.
The
protocol
effort,
not
a
redesigned
the
protocol
effort
further.
This
document
being
from
2005,
is
what
we
call
pre-5378.
A
The
IPR
regime
has
changed
and
5378
is
the
is
the
Watershed
event
where
that
IPR
change?
So
we
do
need
permission
from
all
the
authors
to
get
their
rights.
So
the
original
authors,
yes,
and
so,
even
if
they
don't
want
to
contribute
to
this
effort,
they
need
to
give
us
the
rights
to
continue
and
so
I
hope
that
does
not
become
the
roadblock.
B
Roman
so
hi
Roman,
Union,
responsible
ID,
so
I
want
to
want
to
pick
up
on
two
things
that
might
help
us
help
us
with
a
Glide
slope
here,
and
one
of
them
is
directly
related
to
how
big
of
a
box
we're
going
to
open
here.
So
procedurally,
this
is
actually
going
to
be
an
interesting
situation.
I
haven't
encountered
before
because
what
often
happens
outside
the
SEC
area.
When
you
open
up
you
open
up
the
protocol
security
is
always
very
concerned.
B
Will
you
make
me
update
and
upgrade
all
the
security
kind
of
properties
and
there's
a
bit
of
a
negotiation
that
sometimes
happens
as
to
why
this
document
is
produced,
what
they,
what
the
intent
is
really
to
miss
and
whether
we
we're
going
to
reopen
the
can
of
worms
on
the
security
considerations.
So
one
of
the
things
that
would
kind
of
kind
of
help
me
as
we
talk
about
it
in
the
working
group,
is
let's
kind
of
iron
out
I
mean
we
know
why
we're
making
this
update.
This
is
a
push
from
the
isg.
B
B
So
so
the
so
asked
here
is:
am
I
talking
about
security
considerations
it
could
in
other
in
non-sec
protocols.
It
typically
is
the
security
considerations
and
kind
of
the
assumptions
made
here,
we're
probably
talking
about
fundamental
parts
of
the
protocol,
so
we
we
may
need
a
reason
about
that
and
then
kind
of
the
other
one.
The
other
kind
of
thing
to
do,
which
I
think
is
just
much
much
easier.
B
I
mean
Henrik,
put
in
kind
of
some
good
work
in
documenting
the
implementations,
which
also
helped
with
the
Glide
slope
for
approval
here
so
I.
You
know
I
would
kind
of
urge.
You
know
to
document
that
really
well
as
we
bring
this
document
forward,
to
really
show
that
we're
putting
in
ietf
documents
the
state
of
play
the
state
of
play
and
that
also
kind
of
helps
with
how
wide
of
a
box
we
have
when
we
when
we
reopen
it.
A
So
Roman
are
you
suggesting
in
advance,
in
the
proposed
to
full.
A
Advance
well,
no
I
mean
one
of
the
things
we
often
do
is
document
the
what
implementations
exist
and
so
on.
We
know
we
have
more
than
two
interoperable
implementations,
so
we
could
just
try
to
put
the
best
documents
to
full
standard.
B
Yeah
we
we
could
I,
guess
I,
don't
have
an
answer
of
that
like
right.
Now:
okay,
yeah,
we
should
kind
of
figure
out,
I
mean
if
that's
what
we
want
to
do,
I
mean
I,
mean
I,
see
no
reason.
I
was
thinking
something
less
ambitious,
really
just
document.
It
really
well
in
the
shepherd
report,
as
kind
of
justification
for
the
design
choices.
But
if
we
want
to
go
a
little
further,
I
mean
if
and
we
and
we
clearly
have
the
implementations.
We
certainly
could.
We
do
okay.
I
A
Okay,
can
we
can
we
get
a
couple
people
to
open
up
the
the
notes,
link
and
help
us
out,
please
thank
you.
Two
people
would
be
awesome.
I
So
that
was
a
question
on
the
IPR
thing:
go
ahead:
I,
I,
guess
Ross!
Please
correct
me:
we
fixed
this
with
contacting
the
original
authors
and
they
all
provided
the
right
to
switch
to
the
current.
That's.
A
A
So
the
next
one
is
3709.
Yes,
nothing's
changed
since
this
document
that
has
just
last
week
had
consensus
called
so
the
next
one
on
the
agenda
is
header,
protection,
dkg
or
Alexa.
Here
are
both
here
anything
to
scare
good.
K
We
have
I
think
reach
agreement
about
the
way
to
handle
that
there
was
one
piece
of
subtlety
that
came
up
at
the
last
meeting
that
we
discussed
around
for
header
protection
around
how
the
recipient
should
know
what
happened
when
the
header
confidentiality
policy
was
applied
and
I
I
think
we
reached
an
agreement
on
what
should
happen
there
and
I
have
failed
to
write
it
down
and
produce
the
samples
so
I'm,
still
working
on
that.
Okay,.
A
A
So
was
that
something
that
we're
likely
to
resolve
by
the
next
Ito?
Yes,
awesome,
because
I
I
really
was
hoping
to
clear
this
before
we
dig
into
the
pqc
stuff
yep.
K
So
the
engine
mail
guidance
I
have
not
gotten
a
lot
of
feedback
from
which
is
a
little
bit
distressing
to
me,
because
I
know
that
there
are
people
in
this
room
and
people
who
are
remote
and
people
who
are
on
the
mailing
list
who
have
experience
to
share,
and
we
have
not
gotten
a
lot
of
additional
suggestions.
The
document
has
fixmes.
K
If
you
don't
want
to
say,
hey
I've
got
an
idea,
I
want
to
add,
but
you
want
to
just
pitch
in
and
say
I
think
I
know
how
to
solve
this
particular
problem.
I
would
welcome
that.
K
I
am
trying
to
record
the
things
that
I
have
uncovered
in
terms
of
like
the
kinds
of
paper
cuts
that
people
actually
have
and
I
would
love
to
have
more
contributors
on
that.
I'm
gonna
I
know
that
it
is
expired
right
now
and
I
will
refresh
it
and
I
will
fill
in
some
of
the
fixmes,
but
I
really
hope
that
some
of
the
other
expertise
in
the
room
will
contribute
their
hard-earned
lessons
for
everybody
else.
K
So
again,
I'm
I'm
I'm
behind
on
this,
but
I
really
would
appreciate
more
people
stepping
up
with
with
suggestions.
A
Okay,
so
this
is
Russ
I
promise
to
read
it
and
joining
the
discussion.
Are
there
any
other
s
mime
implementers
willing
to
make
the
same
commitment?
H
H
A
L
Alex
I
did
read
the
earlier
version
and
I
think
I
had
some
minor
comments.
I
think
the
big
part
is
about
terminology
used
just
because
it's
not
fully
aligned
with
email
terminology
but
I
think
once
it's
fixed,
it's
going
to
be
so,
but
yeah
I'm
I'll
commit
to
doing
a
review
again
and
I'll.
Send
you
all
the
comments.
A
Okay,
Michael
Richardson
you're
next.
M
All
right,
I'll
come
back
to
the
first
slide
that
I,
you
know
just
copied
and
pasted
from
last
time.
It's
a
terrible
title.
I
would
love
to
better
title.
You
know
something
more
cool.
M
Me
more
cool,
more
cool
yeah,
with
like
bigger,
smaller,
more
smaller
words,
I,
don't
know
yeah,
so
The,
Story,
So
Far,
so
RFC
70
30,
which
is
EST
enrollment
over
secure
transport,
was
a
little
bit
unclear
about
CSR
attributes,
which
is
a
thing
that
actually
it
created.
M
We
over
in
anima
used
it
the
way
that
we
thought
that
it
worked
and
I
don't
quite
remember
how
we
came
across
the
fact
that
this
was
probably
wrong,
maybe
because
of
the
the
the
CMP
work
that
Hendrick
is
doing
for
me.
I
think
it
was
Sean,
it
was
Sean
yeah.
Someone
noticed
that
we
did
it
wrong
and
anyway
we
had
a
virtual
intro
meeting
at
the
end
of
August
2021
there's
some
links.
M
If
you
want
to
go
see
that
talk
a
lot
more
about
what
what
went
wrong
and
we
concluded
to
that,
we
needed
to
fix
it
and
there
was
a
bunch
of
different
ways
of
fixing
it,
one
of
which
was
that
the
our
interpretation
was
correct
and
the
document
was
wrong
and
another
one
was
that
the
document
was
right
and
our
interpretation
was
was
broken
and
that
you
know
we
went
through
a
couple
cycles
and
we
actually
concluded
the
document
was
vague
and
wrong
and
that
our
interpretation
was
also
wrong.
M
So
so
the
the
last
time
in
Vienna
Sean,
said
you
know
what
we
just
need.
This
extra
layer
of
extension
request
that
that
the
document
was
kind
of
right.
Just
didn't
really
clearly
say
that
so
next
slide
please.
M
So
this
is
what
we
were
doing.
Okay,
we
were
saying
hey.
We
want
this
subject,
alt
name
so
we'll
put
that
in
and
please
do
something:
okay,
and
we
have
writing
code
that
that
does
this
and
it's
wrong
next
slide,
please.
M
M
It's
a
three
item
thing
with
a
critical
bit
in
there,
the
Boolean
subject,
an
oid
and
a
value
at
the
end
or
a
set
of
values
or
a
sequence
of
values
there
and
that's
really
it
so
all
the
other
uses
where
you
say
I
want
you
to
use
algorithm
one
two,
three:
here's
the
oid,
those
all
remain
the
same,
so
I
think
Dan
had
the
question,
but
we
didn't
want
to
break
what
was
on
The
Wire
already
for
other
other
people.
This
is
what
it
looks
like
right
now.
M
M
If
you
have
any
running
code,
that
does
anything
at
all
with
70
30
then
consider
you
know
Conjuring
up
an
example
for
us
and
run
it
through
dump
as
and
one
so
that
we
can
really
say
you
know
to
people
when
I
wrote
my
code,
I
I
I,
went
through
the
three
examples
that
were
in
7030
and
I.
I
didn't
really
understand
the
ASN
one
to
be
honest,
but
I
I
knew
when
I
had
parsed
it
right.
So
that
was
the
that
was
the
key
part.
M
F
Hi
Sean
Turner,
so
someone's
who
caused
all
this
problem,
can
we
adopt
this?
This
seems
like
a
perfect
perfectly
good
draft
for
the
Lambs
working
group.
I,
don't
know
that
the
L
and
lamps
anymore
is
true,
but
this
seems
like
a
perfectly
good
reason.
The
really
The
Joy
de
V
for
this
working
group
was
to
do
this
kind
of
thing.
So
I
would
support
adoption
now.
M
O
O
Name,
my
name
is
Roy
Williams
I'm
Microsoft.
A
long
time
ago
we
had
an
issue
with
Japanese
subsidiaries,
putting
a
stock
ship
on
us
for
using
etf8
for
their
networks
because
of
the
large
explosion
of
content
that
goes
on
the
wire
okay,.
G
M
So
we
want
to
go
back.
One
slide,
I
think
that's
where
he's
reacting,
which
is
probably
just
left
button
there
you
go
so
this
is
the
piece
at
the
bottom
here
can.
E
A
O
M
A
B
A
F
Remote
people-
yes,
the
remote
people-
would
not
hear
me,
but
in
here
they
would.
F
A
new
draft
that
came
up-
it's
basically
came
as
John
Madison
here
I
saw
him
at
the
there
he
is
at
the
back,
so
he
sent
an
email
and
said:
hey.
You
know
the
three
gpp
guys
have
this
way
to
put
Network
function,
types
in
certificates,
kind
of
think
they're,
not
really
doing
it
right.
What
about
what
we
do,
so
we
basically
pumped
out
a
really
simple
draft
to
specify
a
way
to
do
that,
and
that's
really
the
the
whole
thing
one
more
slide,
and
all
on
that
this
is
my
only
slide.
F
I
want
to
make
sure
that
we
talk
about
the
pqc
stuff
more.
So
the
motivation
really
again
was
this.
F
Email
really
is
what
really
happened,
but
the
ideas
for
these
Network
function,
types
for
5G
systems
right
so
they've
got
the
service
based
architecture,
and
these
you
know
things
on
the
network
are
talking
and
they've
got
a
certain
set
of
names,
and
you
know
how
do
we
stick
these
things
in
the
in
the
certificate
and
they're
all
ASCII
strings,
which
is
really
nice,
because
we
don't
have
to
worry
about
these
ETF
explosions
and
they
can
keep
them.
F
F
We
put
justification
for
why
we're
using
ASCII
strings
to
be
able
to
get
us
out
of
this
problem.
So
when
our
responsible
ad
is
carrying
and
the
serum
can
be
like,
they
only
actually
use
ASCII
strings,
and
so
that's
nice
of
them,
because
it
makes
it
a
little
easier
because
it's
smaller
and
so
there's
an
actual
3gp
spec
that
actually
lists
what
those
things
are.
They
are
ASCII,
the
only
really
that's
really
weird
is
they
have
an
underscore
so
we'll
that's?
F
Why
it's
I5
string
and
not
something
else,
but
the
basic
idea
about
hey?
Where
could
you
put
a
name?
Well,
you
can
put
a
name
in
an
existing
naming
attribute.
So
you
have
you
know
you
have
like
a
subject
name
and
a
certificate.
Yeah
country,
oh,
you
know
common
name,
you
can
bang
it
in
there.
Well,
that
doesn't
really
seem
like
it
kind
of
made
me,
but
didn't
make
much
sense.
F
You
can
find
another
name
and
general
name
no
one's
going
to
support
that.
So
good
luck
with
that
right.
So.
Q
F
Q
G
F
That's
really
it
and
that's
kind
of
it
for
the
draft,
and
we
think
that
it'd
be
all
right
to
specify
here
because
usually
in
the
way,
the
references,
the
references
go
right,
3gpp
oftentimes
specifies
and
points
to
the
ITF
rfcs,
and
so
we
figured
we'd
do
it
here.
Do
them
a
solid
and
be
done
with
it,
and
it's
a
very
simple
draft
and
that's
really
it
so
pretty
much
the
ask
is:
hey:
did
anybody
read
it
and
if
you
did,
what
do
you
think
about
adopting
this.
A
So
the
only
thing
I
want
to
add
to
what
Sean
said
is
the
NF
types
that
are
defined
in
the
3gpp.
Spec
are
all
eight
characters
or
less
we,
we
forexed
it
to
make
sure
that
we
weren't
blocking.
You
know
people,
but
yet
not
making
it
unbounded.
We
thought
Forex
probably
was
adequate
to
deal
with
that
and,
of
course,
since
I'm,
a
co-author
Tim
will
make
all
consensus
calls
on
this.
R
John
yeah
some
background,
so
this
is.
This
is
already
specified
in
a
bad
way
in
PDP
which
causes
problems.
It
has
I've
been
identified
by
Erickson
as
a
problem.
I
think
it
has
been
discussed
in
interrupt
tests
and
so
on,
but
I'm
not
100
sure
exactly
how
I
don't
think,
there's
any
any
official
formal
discussions
in
3D
people,
a
new
contribution,
I,
don't
know
if
there
has
been
offline
discussions
there.
R
F
Guess
all
I
want
to
say
is
to
our
80s.
If
there
ever
is
actually
a
fight,
we
they
can
if
they
wanted.
Three
gpp
is
like
that's
a
great
idea.
We're
gonna.
Do
it
over
here
great!
Do
that
like
we're,
not
no
one's
fighting
to
like,
let's
keep
it
here.
You
know
that
yeah.
So
we
figured.
This
was
just
an
easy.
It's
like
a
literally
a
slam,
dunk
kind
of
of
internet
draft
to
get
to
RFC,
not
gonna,
take
typical
three
years.
H
Yeah
I
read
the
draft.
More
importantly,
I
read
the
whole
email
thread
which
I
think
was
longer
than
the
draft.
It.
H
A
F
H
F
Good
right,
so
my
only
concern
when
I
wrote
this
actually
was.
What
was
the
string
type
going
to
be
look?
Do
we
have
to
restrict
it
like
really,
and
it's
it's
funny
because,
like
if
they're
like
oh
well,
they're
going
to
keep
using
ASCII
strings
great
well,
it
makes
it
a
little
easier
because
it
keeps
the
cert
smaller
which,
as
we
know,
is.
E
E
All
right,
so
it
sounds
like
a
lot
of
people
are
in
favor
of
adopting
this
as
anybody
against
adapting
this
document
in
the
working
group,
either
in
the
room
or
remotely.
S
Good
enough,
so
here's
a
link
to
the
draft
for
those
who
haven't
read
it
and
a
link
to
the
editor's
copy
I,
don't
think
there
have
been
any
changes
since
the
zero
zero.
S
Why
is
it
necessary?
Keys
can
be
generated
in
software
or
hardware
for
a
good.
While
now,
a
lot
of
Hardware
modules
have
been
capable
of
providing
verifiable
key
attestations.
S
S
But
when
we
set
out
to
write
this,
there
was
already
a
a
Draft
Brewing
in
the
Acme
group
that
was
using
the
web,
often
wormat,
so
just
to
make
life
easier.
We
we
installed
a
bunch
of
text
and
this
question
here
actually
isn't
a
question
anymore.
S
S
So
we
can't
reuse
the
web,
often
registry
for
attestation
statement
formats
that
aren't
organic
to
web,
often
which
isn't
a
particularly
big
deal
so
we'll
change
the
the
draft
will
change,
at
least
for
that
why
these
various
cert
request
protocols,
because
we
have
a
load
of
them
and
they
all
more
or
less
behave.
The
same
with
respect
to
this.
This
value
can
be
passed
as
an
extension
or
an
attribute
and
because
Acme's
already
covered
a
Brandon
weeks
draft
which
will
be
presented
tomorrow
at
the
Acme
session.
S
S
So
right
now,
if
you
look
at
the
web
Ops
in
the
registry,
all
of
the
statement
formats
are
defined
in
the
web,
often
spec,
but
in
the
future.
That
might
not
be
the
case,
so
we
punt
those
to
the
the
spec
formats.
T
Can
you
hear
me
hello,
oh
hi,
hi
Carl,
incidentally,
we
picked
the
same
web,
often
format
to
to
wrap
different
kinds
of
attestation,
evidence
in
our
tested,
TLS
extension
and
had
we
had
the
same
exact
question
in
regard
to
how
and
where
one
defines
your
performance
is.
Is
that
w3c
Ayana
someone
else?
T
S
That's
the
plan
and
Sean
you
can
chime
in
with
more
detail
on
that.
If
you
like.
S
F
A
U
Yeah
I'm
trying
to
unmute
but
I,
think
I
succeeded.
So
it's
the
the
purpose
of
this
to
to
Signal
the
the
the
aspects
of
the
private
key
that
is
associated
with
these
public
key
of
the
certificate
right.
That's
right,
so
I'm
not
saying
that
you
shouldn't
do
this.
This
way.
I
just
want
to
report
that
there
isn't
a
Noble
app
with
Etsy
has
since
many
many
years
ago,
a
mechanism
in
the
qualified
certificate
statements,
extension
reporting
on
the
aspects
of
the
private
key
associated
with
the
certificates.
U
It's
used
mainly
to
say
that
this
is
a
qualified
signature
creation
device,
but
you
can
you
can
register
any
kind
of
identifier
for
whatever
type
of
key
protection
you
have
there
so
just
to
make
you
aware
that
there
is
such
a
function.
That
is
widely
deployed
already.
S
U
Yeah
I
just
just
wanted
to
point
you
to
to
the
fact
that
this
also
exist.
V
I,
don't
want
to
break
it
all
right
anyway,
Monty
Wiseman
know
a
little
bit
about
the
TPM
and
I've
seen
lots
of,
for
example,
TPM
implications
which
this
would
be
among
the
type
of
items
you.
G
V
You
would
apply
to
this
I,
you
know
looking
through
it.
I
think
in
maybe
the
previous
speaker's
suggestion
needs
to
be
looked
at.
Just
a
simple
binary
of
Hardware
versus
software
I
think
it's
going
to
be
very
difficult
for
people
to
ascertain
or
make
a
decision
on.
There's
lots
of
implementations
isn't
as
hard
to
remain
a
separate
IP
block
inside
the
chip.
A
separate
ship
itself
anyway.
So
there's
I,
think
I.
Think
there's
going
to
be
lots
of
variability.
V
People
are
going
to
want
to
set
the
hardware
bit.
What
sort
of
criteria
do
we
have
for
Hardware
bit?
We've
got
like
things
with
normal
world
and
secure
world,
for
example,
things
over
in
Secure
world.
Is
that
Hardware
it's
the
same
piece
of
silicon.
That's
actually
executing
the
instructions
as
the
normal
world,
so
I
think
this
is
going
to
be
a
a
challenge
to
Simply
make
it
a
binary
decision.
V
Secondarily
go
ahead,
go
ahead!
Oh.
S
S
You
know
that,
as
as
with
what
I
said
to
Stefan
that
exists,
we're
not
creating
that
condition.
We're
just
providing
a
means
to
convey
this
information
to
the
ca
to
appraise,
however,
it
wants
to
appraise
and
and
I
think,
that's
kind
of
what
you're
getting
at
is
is
the
appraisal
process.
Some
folks
are
going
to
do
it
different
than
others,
and
that
seems
okay
to
me.
V
S
E
V
E
V
I'll
I'll,
post,
okay,
yeah
I've
gotta,
have
you
thought
about
adding
something
like
this
key?
Has
certain
attributes,
such
as
policies
associated
with
using
the
keys?
Would
that
be
out
of
scope
for
this
particular
extension?
Maybe.
S
F
Okay,
hello,
Sean
again,
it's
funny.
Actually
the
I
thought
we
thought
about
many
of
these
things
and
was
like
okay.
Well,
what's
gonna
work,
the
funny
thing
is:
can
you
go
back
to
slides
where
it's
like?
Why
and
the
list
of
all
the
various
enrollment
protocols
yeah
back
one
where
it's
just
like?
Why?
Because
there's
so
many
of
them,
because
we
could
never
actually
picked
one.
My
biggest
worry
was
that
we
were
going
to
actually
refer
to
scep
in
normative
format.
F
I'd
have
to
downref
it,
which
would
put
it
on
the
standards
track.
So
I
just
want
to
throw
that
out
there
that
you
know
for
the
ads
that
are
later
going
to
be
passing
this
to
the
thing
everything
else
up.
There
seems
to
be
great,
but
SCP
is
the
really
weird
one
on
the
on
the
list
of
things
to
do
so.
F
S
W
All
right
so
I
think
it's
worth
noting
that,
even
though
we're
both
attestation
is
widely
available-
and
you
know
in
in
some
sense,
extremely
widely
deployed
it-
there
is
not
a
huge
amount
of
deployment
experience
for
relying
parties
actually
processing
we're
both
attestation
and
doing
anything
with
it,
and
in
that
respect,
the
stuff
that
Stefan
talked
about
the
qualified
certificate
extension
is,
in
a
sense
a
little
bit
more
mature
in
the
sense
that
the
in
the
it
essentially
references
a
a
big
Speck
of
Behavioral
Behavior
or
requirements.
W
I
would
refer
you
to
nest's
work
on
this
in
863,
where
they've
gone
back
and
forth
between
requiring
you
know
simple
levels
of
assurance,
the
classical
one
through
four
level
of
assurance,
too
things
that
have
a
little
bit
more
parameter
space
in
them
in
these
vectors
of
trust
stuff
that
they
have
been
using
for
the
last
two
years,
so
it
even
though
it
may
be
very
attractive
to
reference.
W
The
where
both
format
here,
as
in
a
registry
I,
would
take
a
little
bit
more
more
look
at
what's
been
used
in
the
digital
identity
industry
for
for
well,
I
want
to
say
decades
here,
but
almost
well,
it's
more
more
than
a
decade
in
this
space
and
think
about
how
to
how
to
do
this.
W
S
Well,
I
mean
I,
don't
get
to
tell
someone
what
what
attestation
format
to
use
I
I
have
to
consume
it
as
a
relying
party
right
so
and
that's
all
this
is
doing-
is
saying
these
different
products.
They
all
have
different
attestation
formats
I'd
like
a
way
for
my
CA
to
get
a
hold
of
them.
So
this
is
really
just
a
bucket
to
carry
something
from
point
A
to
point
B
I'm
personally,
not
wed
to
web
authen
I,
don't
care
if
we
were
to
go
with
just
oids.
G
W
W
W
Or
maybe
something
that
can
Encompass
where
both
end
and
other
things
in
some
situations
it
is
oids
right
in
other
situations,
it's
going
to
be
something
like
an
Loa
or
a
vector
of
trust
thing
right.
Another
situation
is
just
going
to
be
like
hey
I'm,
it's
a
bit
I'm
a
qualified
certificate,
I
I,
my
key
has
been
generated
using
a
a
QC
capable
device
right.
So
it's
a
range
of
things
and
I
agree
with
you.
Relying
parties
never
never
going
to
dictate
this,
but
yeah
it's
going
to
be
more
complex
than
just
the
weapon.
S
S
S
W
Yeah
well,
the
qualified
certificates
is
one
thing
and
you
can
search
for
that,
and
the
vectors
of
trust
is
another.
That's
another
way
of
specifying
sort
of
assurance
for
authentication
context
and
the
NIS
800-63
is
another
one
right.
The
these
are
these
look
very,
very
different
right.
W
We're
both
in
attestation
was
I
think
an
attempt
to
build
something
quite
simple,
but
you
can
go
back
to
even
to
Kerberos
days,
and
you
will
find
people
have
been
trying
to
specify
sort
of
the
quality
of
of
the
authentication
context
is
something
or
something
it
was
a
Kerberos
PK
in
it
was
it
done
using
a
hardware
context
or
not
right
that
it's
been
tried
right
and
specifying
these
kind.
W
That
kind
of
policy
is
everybody,
has
their
own
idea,
the
web
of
them
people
have
their
specific
idea
on
how
to
do
this.
S
W
M
Michael
Richardson
here
so
I
read
the
draft
and
I
know
I.
Think
I
asked
the
list
why
it
was
very.
What
was
the
rat's
connection
at
one
point?
M
Having
listened
to
the
presentation
now,
I
have
a
much
better
idea
that
it's
a
cross
type
of
thing
and
I
guess
I
want
to
know,
is,
as
lamps
want
to
fight
for
this
rats
for
this
draft
or
does
neither
want
it
or
because
it
kind
of
will
just
it
kind
of
seems
to
to
go
a
little
bit.
You
know
lamps,
as
for
the
syntax
and
racks.
As
for
the
semantics,
I.
S
G
M
No
I
know
that
that
wasn't
the
question
but
you're
still
talking
about
attestations
through
the
type
of
key
that
was
was
created
right
and
so
so.
The
the
fact
that
we're
creating
it
doing
putting
something
a
certificate
is
what
Yanks
it
into
this
working
group.
The
fact
that
we're
we're
talking
about
some
quality
about
the
private
key,
okay
and
who
created
it
and
how
and
in
what
circumstances
is
what
Yanks
it
back
in
the
other
direction,
except.
A
The
Carl's
already
pointing
to
attestation
formats
that
are
already
defined
already
defined.
M
M
S
Actually,
if
you
were
to
Define
one
for
eats,
I,
would
think
that
you
would
Define
a
web
authen
statement,
format
that
would
wrap
the
eat
and.
S
U
That
I
provided
a
link
in
the
jabber
chat
to
to
the
Etsy
work.
A
F
A
Thank
you.
Is
there
anyone
stay
there
you're
not
or
come
up
here
you're
next.
A
Does
anyone
object
to
this
group
adopting
this
document,
or
does
it
need
further
work
before
we
have
asked
that
question.
A
Okay,
so
we'll
we'll
take
it
to
the
mail
list
and.
G
F
So
hey!
This
is
another
one
slide
presentation.
This
is
the
draft
that
we
talked
about
last
time,
which
is
an
individual
submission.
Still
it's
about
PQ,
Kim
certs.
It
was
going
to
specify
it's
going
to
be
the
one
that
ruled
them
all
right.
It
was
gonna.
How
are
you
gonna
put
these
chems,
the
public
keys
and
certificates,
and
what
are
we
going
to
do
we're
going
to
have
this
long
list
of
choices,
and
then
this
picked
one.
So
next.
L
F
Yeah,
exactly
because
I'm,
not
a
cryptographer,
so
I'm
just
throwing
it
out
there
right
again,
the
strap
was
going
to
like
specify
them
all
and
they
just
picked
one.
So,
hey,
that's
nice!
This
draft
is
going
to
be
really
short.
Here's
we're
gonna
we're
gonna
link
it
down
and
make
it
just
be
one.
It's
going
to
specify
what
the
public
key
is.
We
are
not
specifying
the
oid
we're
going
to
take
it
from
nist
whatever.
That
is
we're
going
to
say
no
parameters.
F
You're
gonna
have
an
oid
and
then
they've
got
three
options
for
like
low
medium
high
or
whatever
they're
going
to
call
it,
or
you
know
when
128
to
24
and
56
or
whatever
it
is
we're
going
to
take
those
names,
we're
going
to
go
with
it
and
that's
it,
but
it's
the
encoding
of
the
algorithm
identifier,
where
it's
like
an
oid
and
parameters.
We
are
not
talking
about
parameters,
no
parameters,
I,
don't
know
how
many
ways
it's
going
to
be.
There's
I
think
it's
I,
so
I
talk.
F
When
I
talk
about
panels,
I
hope
there
was
only
going
to
be
like
like
use
and
like
paranoid,
and
then
we
can
just
ignore
the
alien
level.
You
know
security,
but
I,
don't
know,
what's
gonna
happen
and
again,
whatever
they
specify
we're
gonna
do
it.
The
problem
is
that
people
will
just
like
go
for
the
super
high
level
and
no
you
don't
really
need
that
stuff
at
this
point,
so
we'll
do
whatever
they,
whatever
they
specify
there'll,
be
a
number
of.
We
won't
specify
any
parameters.
F
Now,
a
lot
of
us
is
like
super
back
history
rates
like
1997
when
people
screwed
up
their
implementations
and
required
parameters,
we're
trying
to
just
drop
that
baggage.
So
it's
like
just
don't
encode
the
damn
things,
so
it's
Greenfield
we're
hoping
we
can
get
away
with
that
and
then,
of
course,
you
got
to
specify
what
the
key
scissors
are.
Well,
it's
a
chem,
pretty
straightforward
what
the
choices
are
going
to
be
right,
so
there
shouldn't
be
any
real
kind
of
argument
about
this,
and
then
we
have
some
security
considerations.
F
R
So
you
don't,
this
seems
very
connected
to
the
next
presentation
about
signatures,
but
a
little
bit
different,
but
that
presentation
said
nist
will
do
this
for
us,
though
you
say
at
least
we'll
do
this,
and
then
we
will
take
whatever
needs.
Why
these
specify
the
other
presentation
also
have
a
lot
of
discussion.
What
does
the
oid
mean?
Do
we
have
one
and
then
encode
everything
in
the
public
key
value
like
with
LNF
LMS
and
RSA,
or
do
we
have
several
where
these
four
different
security
levels?
How.
F
R
F
So
I
think
I
think
I
think
both,
but
at
the
end
of
the
day,
I
think
that
they've
decided
the
way
they
came
out.
The
signature
stuff
they
kind
of
like
picked.
You
know
three
levels,
essentially
right,
whether
it's
two
or
four
or
three,
whatever
levels
are
we're
just
gonna.
If
it's
three
we're
just
gonna,
go
with
those
and
go
with
the
flow,
we're
not
trying
to
we're
not
trying
to
usurp
nists,
you
know
like
let's
go
write
a
special
publication
or
fips
or
whatever.
That's
clearly,
not
the
intention.
E
B
F
J
Sphinx
aside,
we're
talking
about
yeah
like
three
to
five
parameters.
Oh
it's
not!
You
know
dozens.
The
comment
that
I
got
up
to
make
is
I
will
pick
at
you
about
key
usage,
not
being
straightforward.
Just
for
the
record,
like
chems,
are
a
different
interface,
so
they're,
not
a
key
Trend
and
they're,
not
a
key
agree.
There's
something
new.
We
don't
want
to
make
a
new
EKU
or
KU,
because
gross
probably
we
I
mean
key
trends
are
key
agree.
Both
are
wrong.
I
think.
J
F
Is
yeah
I
did
want
to
make
the
point
that
you
and
I
and
the
other
authors
of
your
draft
have
talked,
and
we
want
to
be
in
complete
agreement
so
that
there's
not
going
to
be
a
fight
over
like
what's
the
bit
and
I
think
we
decided
on
key
trans
and
not
key
agreement,
and
we
were
kind
of
like
well.
We
got
to
pick
one
so
yeah
whatever
it
was.
We
agreed
to
that's
in
the
draft.
F
C
But
it's
just
a
little
trivia.
If
you
start,
if,
if
you
have
to
name
things
anywhere
like
in
the
Ayana
registry
or
or
having
a
shorthand,
please
don't
name
anything
with
a
dash
in
there
or
a
space,
because
there
are
still
some
dinosaurs
that
code
in
the
sea,
and
we
would
really
like
to
map
the
names
one
on
one
and
so
at
least
use
underscores.
F
Interesting,
okay,
well,
that'll
be
nice
input
to
miss,
but
yeah
cool.
We
won't.
We
won't.
We
won't
bother
with
that
description.
H
Yeah,
do
you
actually
really
needs
multiple
oids,
or
can
you
just
determine
what
the
key
is
from
the
link?
That's
encoded
in
the
search,
no
I.
A
A
We
didn't
do
the
question.
Okay,.
F
E
J
Mike
Ellsworth,
so
I'll
make
an
Omnibus
comment
for
I.
Think
all
the
PQ
stuff
which
is
could
we
like
adopt
it
start
getting
the
administrative
work,
the
text
editing
the
sort
of
General
design
out
of
the
way
and
then
like
as
a
group,
just
sort
of
pause
them
and
wait
for
nist,
and
that
way
we
can
synchronize.
F
That's
exactly
what
we're
doing
yeah
exactly
correct
right:
we're
not
trying
to
get
out
in
front
of
our
skis
to
like
fail
miserably
right
here.
It's
like
we
specify
some
stuff
I'm
gonna
put
tbds
in
the
oil
in
the
in
the
play:
I'm
not
trying
to
squat
on
anything
like
we're.
Just
if
people
want
to
experiment
they
can
they
can
do
what
they
want.
F
E
And
also
to
be
clear,
I
mean
you
know.
This
is
nist
time
library
right
here,
we've
got
a
whole
bunch
of
drafts.
We
want
to
make
sure
that
we
get
them
all
done
as
close
to
the
left
side
of
that
timeline
as
possible.
Otherwise,
we'll
fall
off
the
right
side,
so
you
know,
would
rather
hurry
up
and
wait
than
miss
the
deadline.
X
Yeah
so
I
guess
for
those
who
don't
know
me:
Jake
Massimo
I
am
at
AWS.
X
I
did
a
PhD
in
cryptography
under
Kenny
Patterson
WTH,
so
yeah
today,
I'm
going
to
talk
about
similar
drafts
as
the
one
previous
algorithms
identifiers
for
x509.
This
is
the
signature
version
of
the
algorithms
rather
than
the
cameras
here
and
just
get.
I
X
So
a
little
bit
of
motivation.
So
what?
What
is
this
about
so
yeah?
As
I
said
before
the
inclusion
of
the
algorithms
selected
by
nist's
pqc
project
into
x509
right
now?
The
draft
is
focusing
on
dilithium
as
Nestor
stated
it
as
the
primary
algorithm
to
be
implemented,
and
of
course
it
has.
You
know
a
reasonable
wild
balance
performance
throughout
we're,
aiming
here
at
the
description
of
the
pure
certificate,
so
we're
not
focusing
on
the
hybrid
or
non-composite
I
guess
actually
composite
certificates.
X
X
Why
now
just
a
little
bit
more
motivation,
so
we
are
seeing
some
industry
interest
scoping
out
recipients
with
PQ
resistance.
These
are
kind
of
applicable
in
the
the
long
term
rule
of
trusts,
so
things
are
embedded
within
devices
or
things
that
are
difficult
to
reissue,
we're
starting
to
get
some
some
like
custom
questions
and
some
like
examples
from
automotive
industry
having
machinery
and
iot
devices
that
may
sit
on
a
shelf
for
a
long
time
before
they're
ever
switched
on,
and
then
a
look
to
update.
X
Of
course,
this
has
announced
the
the
algorithms
for
adoption.
Don't
listen
Falcon!
This
will
take
some
time,
but
yes,
nice
nice
to
people
this
process.
Now
that
we
have
some
algorithms
selected
and,
as
I've
heard
mentioned
previously,
it
kind
of
aligns,
with
our
the
line
to
Charter,
to
adopt
a
draft
for
pqc
signatures
in
pkix
certificates.
X
For
this
to
be
ratified
after
2024,
what's
you
know,
this
is
fully
finished
specifying
and
describing
the
algorithm
isn't
standardizing
the
algorithms.
X
Slide
yeah,
so
our
goals
and
our
non-goals
we
kind
of
already
focused
or
gone
over
this
before
so
we
will.
Our
guys
are
to
define
the
data
structures
for
the
use
of
dilithium
signatures
in
next
509
and
we
want
a
clean
and
concise
specification.
So
yeah
no
parameters,
we
will
just
have
them
hard
coded
in
the
oids
and
our
non-goals
are
yeah.
We
won't
be.
We
won't
be
trying
to
overthrow
nist
and
say
which
algorithms
to
use
we'll
be
going
with
nests
selection
and
with
nists
selection
of
oids.
X
So,
just
to
finish
up
a
couple
of
key
discussion
points,
obviously
for
signatures,
there
are
multiple
algorithms
that
have
been
selected.
So
we
kind
of
have
this.
You
know
the
the
one,
the
one
ID
to
rule
them
all,
or
do
we
separate
the
each
draft
or
algorithm
per
draft?
X
Of
course,
multiple
algorithms
in
a
single
draft
can
kind
of
bloat
some
security
considerations.
You
know
you
could
imagine
talking
about
the
detailed
intricacies
of
lattices
and
then
also
you
know
hash
functions
and
it
could
be
confusing
as
to
you
know
which
security
consideration
is
talking
about,
which
algorithm
for
people
that
are,
you
know
less
familiar
with
them.
So
right
now
we're
kind
of
thinking,
one
one
algorithm
per
per
draft
and
yeah.
X
Another
question
is
you
know
which
security
levels
should
we
include,
all
of
them,
a
selection
of
them
again,
we'll
be
looking
to
Nest
to
see
what
they
kind
of
put
out
there
first
and
then
being
sensible
about
our
choices.
X
We'd
also
love
to
hear
your
feedback.
I
have
introduced
the
draft
on
the
mailing
list
and
there's
been
some
discussion
on
there
already
about.
X
Bit
strings
versus
octet
strings
and
things
like
this
but
yeah
we'd
love
to
hear
from
your
feedback
and
I
guess:
I
have
to
make
the
the
the
call
to
add
this
as
a
working
group
item
so.
Z
Yeah
hi,
it's
John
Gray
from
entrust
yeah
I
think
I'm,
the
one
that
probably
made
those
comments
on
the
bit
strings
and
then
on
the
draft,
but
yeah
I,
very
much
support.
This
I
think
I
was
saying
on
the
mailing
list.
We
have
already
done
Integrations
with
customers
and
I've
already
had
to
change
my
oids
three
times.
Obviously
we
know
that
they're
going
to
change,
but
it
would
be
great
to
have
you
know
a
final
set
that
we
can
use,
especially.
Z
Q
X
R
John
Mattson.
Obviously
this
is
needed
work.
We
need
to
integrate
everything
in
this
standard,
I
think
for
lamps.
Probably
we
should
do
everything
that
needs
decides
to
stand.
That
dice
I
think
it's
hard
to
know
what
will
be
be
used
in
the
future.
Coming
back
to
this
oid,
it
was
only
two
years
ago
that
lamps
standardizes
LMS
741yd
for
all
security
levels.
R
A
So
let
me
answer
that
the
difference
was
the
way
the
algorithm
of
spec
was
written.
The
algorithm
spec
used
the.
A
Rpc
encoding
of
the
parameters
into
the
key
itself,
so
you
only
needed
one
because
the
key
embedded,
all
the
parameters,
and
so,
if
missed,
were
to
take
that
approach.
Then
we
would
only
need
one,
but
it
seems
based
on
the
way
the
algorithm
specs
that
they
asked
for
in
the
competition
are
not
that
way.
So
that
would
be
a
big
change
to
the
way
they're
specifying
it,
and
that's
why?
Okay.
N
Or
or
steel
transmute
apologies
for
not
queuing
technical
difficulties.
I
appreciate
all
the
comments
you
know
so
I
appreciate
all
the
comments
and
support
this
proposal
working
on
the
Cozy
and
Hosey
representations
to
mirror
what
you're
all
working
on
here
and
I'm
looking
forward
to
collaborating
keeping
everything
in
sync.
A
Okay,
so
this
gets
us
to
the
is
this
the
right
approach?
It
seems
that
we
have
some
choices
on
this
slide.
That
I
think
need
a
little
fleshed
out
in
in
do
we
want
one
PQ
signature
draft
that
has
all
three
of
the
finalists
in
it
or
winners
in
it,
or
do
we
want
one
draft
per
algorithm,
I?
Think
it's
really
important
to
in
order
to
know
how
to
structure
the
call
for
adoption.
F
Get
in
the
queue
here,
if
I
press
the
button
here
so
I
used
to
hi.
This
is
Sean
Turner
I
used
to
be
in
the
camp
for
like
one
draft
to
roll
them
all
and
I've
kind
of
been
slayed
over
to
the
other
side,
where
it's
like
just
have
one
draft
per
per
algorithm,
because
at
the
end
of
the
day
drafts
are
cheap.
These
keys
are
big
literally,
so,
let's
just
keep
them
separate
and
I.
Think
implementers
that
really
care
don't
want
to
Wade
through
all
the
other
crap
right.
F
So
if
they're
picking
one
they
just
want
to
go
with
one
and
again
it's
just
it's.
Okay
to
we're
not
saying
like
this
is
the
one.
This
is
the
one
we're
starting
with.
If
we're
going
to
do
the
other
two
great
we'll
do
those
two
so
I
kind
of
like
the
idea
of
keeping
one
and
it
does
kind
of
like
you
know,
I'm,
not
the
cryptographer,
where
you
know
Jake
is
and
he's
like
well,
I
want
to
write
30
pages
of
security
considerations
about
this
particular
thing.
F
It's
better
to
just
keep
it
all
together,
because
it's
like
then
you've
got
a
I,
don't
know,
I!
Think
it's
just
going
to
be
easier
for
people
to
get
easier.
Very
smart
people
read
these
drafts
and
Implement
them,
but
at
the
end
of
the
day,
I
think
it
just
it'll
be
conceptually
a
little
easier
to
have
them
separate.
Z
Yeah
sorry
I
had
technical
difficulties
with
the
queue
I
was
just
going
to
say
this
test
called
for
a
round
four
for
signatures
as
well.
So
if
you
put
all
three
of
them
in
one,
then
there's
going
to
be,
you
know
another
one
that
comes
out
and
then
you'll
have
to
do
a
separate
draft
anyway.
So
you
might
as
well
just
keep
them
separate.
I.
Think.
N
From
transmute
agree
and
separating
them
in
the
Cozy
and
Hosey
drafts
that
we've
been
developing,
we
have
them
all
together
because
it's
easy
at
the
beginning.
That
way,
but
I
think
for
a
number
of
reasons
that
have
been
mentioned,
all
of
which
I
agree.
It
would
be
good
to
split
them
up,
particularly
because
of
the
call
for
additional
algorithms
from
nist.
A
B
Hi
Roman
I
just
wanted
to
be
I
wanted
to
be
last
so
personal
opinion
I
think
we
should
split
them
into
separate
drafts.
You
know
80
hat
on
I'll
support
what
what
the
consensus
is.
A
Okay,
so
I
started
a
poll.
Should
we
put
each
signature
algorithm
in
its
own
document,
I
I
will
I
will
observe
that
if
nist
publishes
them
at
the
same
time,
we
don't
care
if
this
staggers
publication.
This
aligns
foreign.
A
If
the
one
person
it's
pretty.
E
A
Okay,
he
had
11.,
so
does
anyone
object
to
doing
a
call
for
adoption
for
the
the
lithium
signature,
which
is
the
one
we
have
a
draft
for?
J
J
Worth,
let's
talk
about
the
composite
stuff
next
slide.
J
So
I'll
acknowledge
first
there's
a
lot
of
I
mean
it's
been
going,
discussions
going
for
a
long
time,
but
weather
composite
or
non-complex
like
any
if
any
of
the
hybrid
stuff
is
like
fundamentally
actually
useful
or
if
we're
just
spinning
trying
to
develop
this
stuff
and
I
acknowledge
that's
a
good
debate
and
there's
good
arguments
and
NSA
and
ncsc
have
made
their
points
clear
and
have
good,
solid
arguments
and
I'm.
Not
necessarily
you
know
trying
to
push
that
composite
is
the
way
I
do.
J
That's
been
cfrg
reviewed
is
probably
you
know,
generally
good
for
Humanity,
so
I'm
not
up
here,
trying
to
argue
that
composite
is
the
one
and
only
way,
but
I
am
up
here,
arguing
that
I
think
if
people
are
going
to
do
it,
we
should
standardize
it
and
also
it's
easy
and
we
can
do
it
independently
from
the
algorithm
definitions,
because
it's
totally
algorithm
agnostics
so
like
why
not?
This
is
sort
of
why
I'm
up
here.
J
So
this
slide
deck
is
basically
a
call
for
adoption.
I
think
keys
and
sigs
are
ready
for
adoption.
So
I've
my
Sean
had
no
slides
on
adoption.
I
have
like
six
slides
on
why
I
think
adoption
is
appropriate
and
then
I've
got
a
bid
at
the
bottom
about
Ken's
we
have
a
composite
chem
dropped
up.
So
let's
go.
J
Foreign,
so
here's
the
status
of
the
composite
drafts
Keys
is
an
O2
and
I.
Think
it's
mature
and
ready
for
adoption
signatures
is
an
07
I.
Think
it's
ready
for
adoption.
We've
done
a
lot
of
sort
of
Shifting
stuff
back
and
forth
between
the
keys
and
the
sigs
draft.
I
think
that's
all
sort
of
stabilized
now.
The
one
thing
that's
missing
that
we
like
had
in
and
actively
removed,
is
the
and
or
k
of
n
any
like
all
that
sort
of
policy
stuff
yeah.
J
Once
we
started
having
or
and
any
as
distinct
modes,
it
got
stupid
and
we
just
took
it
out
so
I
think
that
needs
to
go
back
in
like
we've.
Our
co-authored
D
trust
in
particular,
is
like
already
deploying
those
sorts
of
modes.
So
we
need
a
way
to
specify
it.
That's
standardized
I
think
it
belongs
in
the
Sig's
draft.
J
Probably
it
belongs
as
part
of
the
signature
algorithm,
not
as
part
of
the
public
key,
so
that
needs
to
go
back
in
so
these
aren't
final,
but
otherwise,
I
think
they're,
pretty
mature
and
as
you'll
see
in
a
few
slides.
J
We've
got
lots
of
starting
to
have
lots
of
running
code,
which
is
a
sort
of
a
checkpoint
in
itself
and
then
finally,
there's
composite
chems,
so
we
just
got
composite
chem
0
0
up
if
you'll
remember
about
a
year
ago,
we
put
a
composite
encryption
draft
in
front
of
lamps,
and
that
was
really
just
to
sort
of
Garner
feedback,
and
we
got
a
lot
and
we
proposed
in
that
draft.
J
A
number
of
different
ways
of
doing
composite
and
by
encryption
I
mean
like
CMS
encryption,
where
you're
trying
to
encrypt
for
a
recipient
with
multiple
public
keys
on
different
algorithms,
in
a
way
that
the
recipient
will
have
to
use
all
their
keys
to
unlock
the
content.
So
we
put
forward
a
bunch
of
different
proposals.
I
think
we've
settled
on
wrapping
it
all
up
inside
a
chem,
so
you
can
have
an
RSA
key
trans
and
an
x25519
and
kyber,
and
you
roll
them
all
up
together
and
on
the
outside.
J
J
J
I
think
we're
also
starting
to
clear
the
running
code
bar
and
Trust.
Obviously
has
you
know
we?
We
have
this
semi-semi-commercially
bouncy
castle
recently
we
just
did
full
integration
tests
against
bouncy
castle.
So
that's
like
full
supportive
composite.
J
We
are
currently
working
on
an
oqs,
open,
SSL
implementation,
I
think
we'll
have
that
complete
by
115.
and
then
our
co-authors
obviously
have
their
own
proprietary,
which
were
sort
of
in
various
stages
of
integration.
Testing
against
so
I
think
we're
also
clearing
the
running
code
bar
here
dkg.
K
So
thanks
for
doing
this
work,
it's
obviously
something
that
people
want
and
we
want
to
put
it
forward
and
I
just
wanted
to
try
to
clarify.
There's
I
heard
a
lot
of
pushback
in
this
room
earlier
about
parameters
right.
We
don't
want
to
have
parameters,
we
don't
want
to
have
you
know
too
many
fiddly
bits.
We
want
something
specific.
K
This
appears
to
be
it's
not
using
parameters,
but
it
is
allowing
a
wide
range
of
choices
right
because
you
can
it's
it's
abstract
enough
that
you
can
composite
arbitrary
things
together.
K
So
I
I
guess
I
just
wanted
to
highlight
that
this
seems
like
attention
here
we're
going
to
run
into
this
in
the
open,
pgp
working
group
as
well,
when
open
btp
gets
around
to
doing
this,
and
I
wanted
to
try
to
understand
your
thinking
about
or
the
group's
thinking
about
why
we
want
as
much
flexibility
as
there
is
here,
and
what
kind
of
constraints
and
flexibility
you're
willing
to
tolerate.
J
Yeah
so
good
question,
so
we've
written
the
draft
just
trying
to
provide
tools
like
anywhere
people
have
asked
for
a
tool
sure
we
can,
you
know,
try
and
provide
it.
So
the
draft
at
one
point
we
had
like
generic
composite
and
explicit
composite
as
two
separate
drafts
and
we've
now
merged
them.
So
you
can.
You
can
now,
with
the
same
wire
format
say
like
like
have
an
oid
that
says:
I
am
a
generic
composite
public
key
and
you'll
have
to
look
inside
me
to
see
what
I
am
or
you
can
have
an
oid.
K
But
when
we're
talking
about
interop
on
the
actual
Network,
what
we
need
is
clear,
guidance
and
constraints
right.
If,
if
you,
if
you
pave
a
big
parking
lot,
people
will
crash,
but
if
you
give
them
rails
they'll
ride
in
the
direction
that
you
want
them
to
ride.
And
it
sounds
to
me
like
this
is
Paving
a
big
parking
lot
and
there's
going
to
be
some
crashes.
F
Hey
this
is
Sean
Turner
I
just
want
to
say
that
one
of
the
reasons
why
we
went
for
the
don't
do
the
whole
composite
thing
was
a
little
bit
of
that
and
you're
right,
because
there
are
rails,
but
people
can
like
put
three
wheels
on
it
and
like
do
all
kinds
of
fun
things,
and
one
of
the
reasons
why
we
decided
to
go
with
less
right
is,
is.
F
Oh
yeah
so
I'm
not
trying
to
say
good
or
bad
whatever,
but
like
at
the
end
of
the
day
when
this
did
elliptic
curve,
we
had
too
many
choices
and
people
were
like
what
are
we
gonna
do
and
oh
look.
We've
got
this
name
curve
thing
and
we'll
give
you
this
crazy
pants
stuff.
So
we
did.
The
5480
draft
RFC
ended
up
as
a
tiger
team
and
I.
Remember.
We
got
on
the
call
and
the
guy
from
Microsoft
his
name's
escaping
note.
Kelvin
was
just
like
stop
with
the
choices.
F
We
don't
want
to
do
all
this
and
it
was
like.
Let's
just
pick
annoyed
well
great,
then
all
this
crazy,
pants,
asn1
stuff
that
wish
we
would
have
to
specify
just
fell
away.
I,
don't
know
that
helped
I
think
IPR
was
actually
the
bigger
problem,
but
at
the
end
of
the
day
that
was
one
of
the
things
where
it
was
like.
F
There's
too
many,
and
so
that's
why,
from
my
perspective,
when
we're
doing
it,
let's
just
do
less,
because
maybe
that
is
but
if
it's
a
commercial
need
I,
don't
know
because
I
mean
PKS
doesn't
have
a
really
good
track
record
or
the
pki
world
of
picking
a
clear
winner.
There's
like
six
enrollment
protocols
right
if
you're
running
an
Enterprise,
it
sucks
right,
because
you
got
to
support
every
one
of
those
freaking
things
and
it
is.
It
is
what
it
is
right.
So
I
don't
know,
that's
just
some
background
for
for
thoughts
for
future.
J
So
I
was
putting
thinking
putting
on
my
hat
is
like
editor
of
this
draft.
If
that's
what
the
working
group
wants
to
do,
we
want
to
like
use
the
Machinery
we
have
here,
but
then
just
say
you
know
Thou
shalt
to
these
two
algorithms
I'm
fine,
if
it
turns
into
that
that's
a
totally
reasonable
direction
for
this.
J
So,
on
the
topic
of
running
code,
my
co-worker
John,
Gray
and
I
are
gonna
volunteer
to
show
up
at
the
115
hackathon
with
the
interest
implementation,
the
bouncy
castle,
implementation,
the
hopefully
by
then
oqs
implementation,
and
that's
that
would
be
I
guess
like
signatures
and
chems.
If
that
happens
as
well
as
composite
like
if
you
want
to
come
and
test
your
PQ
x509,
you
know
crl
s
mime,
whatever
we're
going
to
be
at
that
we're
gonna
volunteer
to
be
at
the
hackathon
to
come
test
against
I.
M
Next
question
about
your
plans
are:
are
you?
Are
you
Michael
Richardson?
Are
you?
Are
you
going
to
run
some
enrollment
protocols
because
we
have
so
many
of
them.
M
Yeah
yeah,
no
I,
actually
I'm
serious
I
was
thinking
about
this
and
go
well.
There's
no
point
in
me
bringing
my
open,
SSL
implementation
of
a
CA.
That
does
something
because
you
already
have
one
but
then
occurred
to
me,
but
the
the
what
I
have
clients
that
would
want
to
talk
to
it,
because
I
would
now,
of
course
like
to
sign
a
CSR
with
a
PQ
algorithm
right
and
send
it
to
you
and
get
something
so
that
so
that's
why
I'm
seriously
actually
asking
that
question.
Is
that
within
your
your
thinking,
the.
A
Z
J
Okay,
next,
this
slide
I,
don't
know
that
I
necessarily
needed
it,
but
it's
sort
of
a
plug.
I
personally,
don't
view
the
composite
and
non-composite
as
like
competing
in
fact,
I.
Think
there's
a
lot
of
good
uses
for
both
that
are
independent,
like
the
negotiated,
TLS
type
stuff
non-composite
probably
makes
a
lot
more
sense,
but
the
totally
offline
you
know
code
signing
whatever.
Maybe
the
composite
does
make
a
lot
more
sense.
Like
I
think
there's.
J
You
know,
there
exists
at
least
one
strong
argument
use
case
for
each
I
also
want
to
point
out,
because
I
think
this
gets
lost
a
bit
that
it's
totally
possible
to
do
both
together.
At
the
same
time
like
you,
could
imagine
a
non-composite
TLS
handshake,
you
show
up
with
two
separate
certificates
from
two
separate
Cas,
and
one
of
them
happens
to
be
a
composite
x509,
RX,
x2509
and
kyber
together,
and
you
non-composite
that
with
the
RSA
or
like
you
know,
you
can
imagine
he's
getting
used
together.
J
J
Yeah
here's
John's
slide
yeah.
Are
we
ready
to
adopties.
P
Z
P
And
to
me,
I
think
that
how
it
is
now
where
it's
simple,
it's
and
should
be
done
first
and
then
separate
draft
could
do
the
Alternatives
because,
because
they
have
different
security
considerations,.
K
I
I
do
think
that
these
should
be
adopted.
It
seems
like
that's
what
we're
talking
about
in
this
working
group
and
it's
obviously
it's
a
milestone,
so
sure
I
wanna,
my
understanding
from
this
the
point
earlier
about.
Well,
we
we
might
want
to
add
in
add
back
in
the
or
or
the
N
of
K
of
n
or
whatever,
and
adding
that
specifically
to
the
signatures.
K
Worries
me
a
bit
in
that.
If
you're
saying
here
is
one
composite
key
and
it
can
make
two
different
kinds
of
signatures:
you're
now
creating
a
negotiation
problem
right,
because
someone
who's
going
to
be
relying
on
a
signature
is
now
is
to
express
to
the
signer
which
types
of
signatures.
That's
that
key
can
produce
and
I,
don't
know
in
the
places
where
this
plans
to
be
used.
If
we
have
any
clear
documentation
about
what
kinds
of
negotiation
might
be
done
in.
K
J
J
Second
yeah,
the
and
versus
or
I
mean
there
are
use
cases
for,
or
they
exist,
there's
people
who
can
they
want
a
flag
day
now
to
support
composite
and
start
shipping
them
and
then
Flag
Day
later
to
turn
the
algorithms
on
like
there's
those
sorts
of
use
cases
floating
around.
It's
like
I
think
there's
enough
people
who
want
an
ore
and
just
people
who
want
or
in
sort
of
all
sorts
of
weird
permutations
like
every
time
I
take
it
out.
I
get
pushed
back,
so
I
I,
don't
know.
Y
Victor
Duchovny
Google
public
DNS
I'm
wondering
how
this
plays
into
things.
Like
you
know,
tlsa
records
which
carry
a
hash
of
an
spki
you
know
is
this:
does
this
not
become
ambiguous
in
light
of
the
the
new
complexity?
You
know
if
I
will
know
that
I
trust
a
particular
spki.
Y
You
know
if
it
can
be
used
in
a
variety
of
ways.
I
guess
it's
the
same
question
in
some
ways,
what's
likely
to
be
happening.
J
J
Y
You
if
it's
the
same
p,
it
doesn't
really
matter
which
algorithm
if
tlsa
can
specify
TLS
you
negotiate
the
signature,
algorithms
on
The
Wire.
It's
not
a
big
deal.
Yeah.
J
AA
Look
at
that
I
did
it
okay,
so
this
is
Deb
cooling.
Sorry
I
took
my
badge
off,
so
my
while
I
think
it's
very
good
that
you've
got
a
bunch
of
people
interested
in
implementing
these
fancy
tools.
J
Yeah,
that's
a
fabulous
question
that
I've
been
asked
every
time.
I
get
up
here
and
I
still
don't
have
an
answer.
That
I
can
say
publicly
I
mean
we
do
have
customers
who
would
buy
it,
but
I
can't
you
know,
use
them
as
an
example
and
no
one's
really
come
forward
just
as
a
co-author
to
as
a
user
base.
It's
a
fair,
it's
a
fair
question
that
I
acknowledge
so.
AA
My
question
is,
if
you're
going
to
call
for
adoption
and
spend
working
group
time
to
work
on
something
that
is
indeed
a
fancy
tool
and
very
complicated
and
unlikely,
in
my
opinion,
to
be
implemented
correctly
on
a
regular
basis.
If
ever
question
is,
are
you
actually
interested
in
spending
working
group
time
on
it.
Z
Like
the
andon
or
discussion
like
Mike
said,
that's
come
and
gone
and
come
and
gone
so
yeah,
that's
expected
in
terms
of
I
guess,
maybe
to
address
what
Deb
was
just
saying:
I
mean
I,
can't
acknowledge
customers
as
well,
but
I
know
we
have
a
lot
of
people
interested
in
using
this
I
think
the
extra
security
that
it
can
provide,
especially
if
you're
looking
at
the
transition
period,
where
we're
not
sure
we
trust
these
post
Quantum
algorithms
fully
yet,
but
we're
not
sure
if
there's
a
quantum
computer
I
think
that
is
a
very
compelling
use
case
for
using
these
and
I.
J
A
lot
of
maybe
a
bit
of
a
a
completely
hand,
wavy
answer
to
Deb's
question
in
that
it
just
opens
more
permutations,
but
you
could
imagine
using
the
sigs
without
using
the
keys,
like
you
could
imagine
a
multi-certificate
operation
that
wants
to
carry
its
multiple
signatures
in
the
composite
structure.
J
Like
an
example
would
be
the
CMS
sign
data,
you
know
we
can
already
already
carry
multiple
certs,
but
maybe
you
want
to
to
Really
make
it
clear
that
this
is
a
composite
operation.
You
want
to
roll
them
into
a
single
signature,
and
so
you
want
the
data
format
to
have
one
signature
that
points
back
to
multiple
certificates
like
there
might
be.
There
might
be
uses
like
that.
I.
Don't
not
aware
of
any
protocols
that
want
to
do
that
yet,
but
let's
see.
U
O
This
is
Roy
Williams,
if
don't
be
standing
up
to
say,
hey,
they
want
to
build
something,
cool
and
and
far-reaching
on
this.
Just
building
it
and
hoping
somebody
comes
to
it.
I
think
is
a
non-goal
unless
somebody's
willing
to
say
hey.
This
is
what
I
want
to
use
it
for
I.
Think
it's
just
open
up
a
Pandora's
Box.
A
A
E
A
So
so
we
need
to
discuss
that
further
on
the
list
and
is
there
anyone
who
would
speak
against
a
call
for
adoption
on
composite
cigs.
A
Adoption,
okay,
so,
let's
be
clear,
is
anyone
object
to
a
call
for
composite
cigs
with
the
with
the
current
and
structure.
A
J
I
guess
technically,
technically
two
more
slides,
yeah,
so
composite
chems.
Assuming
this
is
a
thing
we
want
to
do
so
this.
This
draft
is
complicated,
cryptographically
and
I.
Don't
want
to
spend
a
lot
of
time
up
here,
other
than
to
say
that
this
has
been
slow
to
come
out,
because
we
had
to
define
a
bunch
of
crypto,
which
is
a
terrifying
sentence.
J
So
the
two
pieces
of
crypto
we
couldn't
avoid
having
to
Define
is
Transformations
from
a
key
trends
into
a
chem
and
from
a
key
agree
into
a
chem.
So
we
can
then
treat
everything
as
a
chem
and
combine
chems
with
chems
I
think
those
Transformations
are
sound.
We
base
one
of
them
at
least
on
Roc
5990,
RSA
cam.
J
Then
it
becomes
a
mess,
there's
a
fair
amount
of
academic
literature
out
there
and
like
fresh
to
the
2018
2019
2021
about
how
to
do
combiners-
and
you
know,
you've
got
some
number
of
shared
secrets
and
some
number
of
Cipher
texts
and
you
want
to
somehow
roll
them
into
one
shared
secret
and
there
seems
to
be
a
lot
of
different
proposals
for
how
to
do
that
with
terrifying
complexity.
So
that's
yeah
that
that's
a
bit
scary
and
that
it's
not
clear
how
to
do
that.
J
Maybe
one
way
is
we
sort
of
we
restrict
ourselves
down
like
restrict
the
problem
statement
down.
So
it's
more
tractable
like
maybe
we
just
ban
key
trends
and
then
a
lot
of
this
goes
away.
J
Tls
doesn't
have
this
much
problem
because
they're
ephemeral,
ephemeral,
you
don't
have
to
worry
about
like
adaptive
attacks,
because
the
server
is
only
going
to
use
its
key
once,
but
in
CMS
you
do
so
I
think
this
is
a
more
difficult
problem
than
what
TLS
is
tackling
and
it's
yeah.
We
need
help
or
Direction,
either
in
doing
the
crypto
rate
or
in
simplifying
the
problem.
A
A
AB
AB
Okay,
so
I'm
just
gonna
give
a
hopefully
brief,
update
on
the
changes
we've
made
since
the
previous
version
of
this
draft.
So
we
uploaded
the
first
version
in
March
we
presented
on
it
at
the
lamps
interim
in
April,
and
we
uploaded
a
new
version
in
June.
Based
on
the
comments
we
received
at
the
interim
and
on
the
mailing
list,
I'm
excited
so
some
general
changes.
We
changed
the
title
of
the
document
and
we
added
a
section
which
just
gives
an
overview
of
the
intended
use
case
for
this
document.
AB
AB
Last
we
narrowed
the
scope
of
the
document,
so
instead
of
using
this
mechanism
for
an
arbitrary
number
of
certificates,
we're
just
focusing
on
the
two
certificate
case
where
you
submit
a
CSR
that
references
only
one
already
existing
certificate,
all
right
next
one-
and
so
this
is
probably
where
we
got
most
feedback
and
I-
think
we
made
a
significant
number
of
changes
here.
AB
So
we
changed
the
name
of
the
the
attribute
and
we
added
a
couple
values
in
as
well,
so
we
added
request
time,
which
is
binary
time
specified
in
RFC
6019,
and
this
is
to
ensure
freshness
of
the
attribute
we
added
in
location
info,
which
is
just
access
description
from
5280..
So
this
up
just
lets.
You
point
to
the
location
of
the
already
issued
certificate.
AB
Let's
see
we
kept
one
of
our
Fields
the
same,
and
this
is
just
the
assure
and
serial
number
field,
and
then
last
we
changed
the
signature.
So
originally
the
signature
was
just
over
that
issue
or
in
serial
number,
and
so
now
what
we're
doing
is
concatenating
that
value
with
the
request
time
and
then
signing
all
right
next
slide.
AB
And
so
when
I
say
entire
certificate,
I
mean
the
already
issued
certificate
that
we're
referencing
right.
That
we
want
to
to
show
is
related
and
I.
Think
that's
about
it.
I
didn't
include
a
slide
about
questions
related
to
adoption,
but
I'm
happy
to
answer
any.
Y
Sorry
I
didn't
join
the
queue.
Is
the
request
time
just
an
answer,
or
is
it
really
expected
to
somehow
line
up
with
the
clock
so.
AB
This
doesn't
already
defined
type
from
RFC
6019,
which
is
just
binary
time.
We
didn't
put
any
normative
statements
about
how
in
sync
this
has
to
be
with
exactly
you
know
when
when
the
CSR
is
submitted,
but
but
the
idea
is
that
this
will
prevent
reuse
of
the
signature
value
specifically.
P
A
Q
Yes,
hi:
everybody
apologies
that
I
can't
be
there
in
person
with
you.
My
name
is
Mike
Osborne
I
work
for
IBM
research
in
Switzerland
and
responsible
for
the
team
that
actually
co-authored
three
of
the
nist
selected
algorithms.
Q
Q
Q
It's
a
nice
starting
point,
but
these
algorithms
never
end
up
like
that
and
depending
how
you
start
is
going
to
influence
how
you
end
up
so
so.
The
aim
of
this
document
really
is
is
a
set
of
learnings
on
how
to
serialize
and
identify
Keys
in
in
the
sense
of
both
wire
formats,
identification,
the
need
to
compress
certain
things
with
the
with
it,
with
with
the
with
the
aim
that
that
would
help,
let's
say,
provide
some
upfronts
understanding
about.
Q
Q
If
I
apologies
I'm
a
newbie
here
in
terms
of
how
to
I,
see
no
yeah,
okay,
that's
my
learning
for
today.
So
so.
Q
Never
told
them
yeah
so
so
we
actually
issued
the
document
with
all
of
the
in
this
finalists
earlier
earlier
in
the
year.
Q
Obviously,
there
was
some
feedback
in
terms
of
guidance
around
oids
or
come
to
oids
in
a
little
bit.
There's
this
concept
about
actually
aligning
with
nist
I
mean.
Actually,
my
team
is
one
of
the
teams
negotiating
and
with
nist
on
how
the
io
IDs
will
look
like
and
be
defined
some
feedback
on
asm1,
syntax
and
things
like
this,
but
and
some
revisions
around
feedback
on
on
some
of
the
in
the
encoding.
So
this
is
really
just
to
step
back
and
say
this
document
is
really
about
the
these.
Q
Are
you
know
you
need
to
encode
private
Keys?
You
need
to
encode
public
Keys.
Let's,
let's
look
at
how
we
can
sort
of
like
you
know,
Define
define
these
such
they
can
be.
Let's
say
the
learnings
can
be
adopted,
then,
by
all
of
the
other
things
that
happen
in
in
all
of
the
other
rfcs.
So
we
have
a
a
draft
update.
Q
You've,
probably
seen
the
next
chart,
which
is
okay,
since
that
draft
update
nist
has
made
their
selections
like
I.
Can
jump
over
that
because
you
know
the
selections
but
essentially
there's
work
underway
now
to
update
the
document
in
terms
of
removing
other
than
this
finalist
algorithms.
Q
I
picked
up
on
the
discussion
about
one
document
per
algorithm
versus
multiple,
something
that
we
can
also
look
at,
but
essentially
we're
restructuring
the
document
according
to
the
nist
decision,
adding
the
swings
algorithm,
because
that
was
an
alternative.
Now
it's
now
it's
to
be
standardized.
Q
There
was
a
set
of
discussion
around.
This
is
a
very
hot
discussion
around
you
know
among
some
of
us
on
the
what's
on
the
Enterprise
side
in
terms
of
the
ASM
one
syntax
I
mean
it
goes
into
things
like
partially
populated
keys.
Q
So
one
of
the
learnings
that
we
as
an
organization
have
had
is
that,
yes,
you
can
start
off
all
nice
with
you
know
you
have
the
full
keys
and
everything
but
but
but
at
some
point
then
actually
these
really
do
not
fit
in
some
some
existing
protocols
and
standards,
and
we
needed
to
start
to
look
at
partially
populated
keys,
so,
for
example,
private
keys
that
do
not
have
the
public
key
inside
them
or
where
or
keys
that
can
be
expanded
from
a
seed,
this
sort
of
thing,
and
so
so
to
look
at
those
those
trade-offs.
Q
Let's
say
that
discussion
we
decided
to
create
a
separate
document
because
there's
essentially
a
debate
around
where
you
want
the
complexity,
you
will
have
complexity,
it's
just
a
question
more
of
where
you
want
it.
Do
you
want
it
really
in
the
serialization
layer
or
do
you
want
it
in
the
layers
above
and
we
thought
it
makes
is
a
more
value.
We
create
a
separate
document
to
sort
of
debate
the
pros
and
cons
about
this.
This
will
essentially
comes
into
the
the
question.
Q
No
parameters-
or
you
know
like
one
OD
is,
is
the
parameters
are
implicit
things
like
this?
It's
not
going
to
be
as
easy
as
that
I
can
tell
you
now.
We
know
already
that
they're
going
to
be
different
forms
of
dilithium,
for
example
deterministic
non-deterministic.
We
know
already
there's
a
lot
of
interest
in
the
underlying
symmetric
Primitives,
those
that
are
accelerated
today,
those
that
are
not
so
we
we
do
see
that
the
this
this
nice
concept
of
of
Simplicity
is
just
not
going
to
be
like
that
going
down.
Q
So
this
is
essentially
it's
just
that
to
help
debate
that
decisions
around
those
sort
of
things.
Q
Q
We
prefer
to
call
these
multi-key
modes
because
for
there's
various
reasons
among
them,
IP
reasons,
so
we
understand,
observe
and
and
and
I
think
it's
great
that
the
other
proposals
going
off
in
this
direction
and
the
it's
kind
of
like
to
understand.
So
so
what
this?
What
that?
Really
this
this
proposal
is
about
is,
is
really
key
Centric.
So
so
it
really
it's
really
kind
of
framed
around
keys,
not
how
these
keys
are
used
in
signatures
or
how
these
keys
are
used
in
into
exchange
protocols
and
things.
Q
But
but
really
it's
it's
the
debate
around,
storing,
defining
and
attaching
keys
to
the
the
algorithms
to
to
support
them.
So
so
so
there
are.
There
are
some
very
ongoing
debates
around
these
multi-key
modes,
as
as
we've
heard
in
some
of
the
discussions
right
now
and
then
so.
If
we
look
at
I
can
give
examples
of
the
platform
that
we
have
now
so
that
the
on
IBM's
larger
platforms,
we're
already
on
our
second
generation
of
these
algorithms,
we're
already
signing
things
that
need
to
be
around
a
long
time.
Q
And
so
then
there
are.
There
is
the
question
of
migrating,
not
keys,
but
actually
Keys,
being
able
to
support
or
migrate
between
different
versions
of
algorithms.
So
so
some
debate
around
insofar
as
that's
possible
and
it
has
been
possible
to
to
look
at
what
it
takes
then
to
actually
migrate
Keys
between
different
versions
of
the
algorithm.
Q
So
as
a
newbie
I
think
that's
the
last
slide.
I
think
that's
the
last
slide.
So
we
will
update
in
the
next
days
the
the
draft
that
we
have
to
to
represent
in
this
selection.
As
mentioned
and
thinking
I
think
I'm
asking
for
this
to
be
adopted
as
a
as
as
a
working
item.
But
then
please
correct
me
as,
if
I'm,
using
the
wrong
nomenclature.
A
So
so
Mike
I'm
kind
of
concerned
that
the
direction
that
you're
taking
and
the
one
we
decided
earlier
are
at
odds
that
you
have
all
the
finalists
in
here.
Well,
you
have
even
more
than.
T
A
But
and
we're
not
sure
that
nist
is
going
to
release
them
all
at
the
same
time,
and
so
we
can't
approve,
we
can't
get
ahead
of
mist
and
so
the
way
you've
structured
it.
We
could
not
approve
this
document
till
all
of
the
algorithms
are
published,
whereas
if
you
had
one
per
algorithm,
we
could
release
the
as
they
were
done.
Q
A
Okay,
Michael's
running
to
the
mic,
Michael.
M
Richardson
so
as
I
understand,
you
are
doing
the
private
key
formats
in
pkcs8
for
the
various
pieces.
That's.
M
Yes,
it
if
you
want
to
put
them
in
pkcs8.
This
is
how
you
do
it
right
correct.
So
so,
I'm
I
have
only
learned
through
your
document
today,
so
I'm
ready
yet
but
I'm
I'm
thinking
that
there's
maybe
a
lot
of
commonality,
and
so
maybe
the
first
document
that
we
approve
winds
up,
having
more
details
about
things
like
that
and
then
the
subsequent
ones
just
say
and
I.
M
Q
G
A
L
F
Hi,
this
is
Sean
Turner,
I,
guess
there'll
be
some
overlap
and
we'll
have
to
do
some
horse
trading
to
figure
out
where
they're
gonna
go,
because
the
draft
that
I
had
actually
put
the
private
key
format
in
the
draft
as
well.
So
there's
a
little
bit
of
like
well.
What
are
we
gonna
do
because
again
one
place
for
the
implementers
to
go
I'm
just
trying
to
figure
out.
F
What's
gonna,
what's
gonna
go
on
so
and
again,
the
only
thing,
the
only
other
thing
I
want
to
say
is
like
in
in
very
not
too
distant
past.
The
choices
didn't
help
so
I
understand
that
some
people
want
to
have
all
the
bells
and
whistles
and
all
the
knobs,
and
that
didn't
help
broadly
speak.
It
didn't
help
adoption,
it
actually
like
slowed
it
down,
and
then
there
was
IPR
in
the
whole
nine
yards.
So
I
appreciate
when
it's
like
hey,
we
can
drop
stuff
out.
That
sounds
like
compressed
Keys.
A
Point,
let's:
let's,
let's
have
the
discussion
of
whether,
when
this
being
broken
up
should
be
put
into
each
of
the
other
documents.
Instead,
that'd
be
a
option.