►
From YouTube: IETF115-OPENPGP-20221108-1300
Description
OPENPGP meeting session at IETF115
2022/11/08 1300
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
Okay,
so
good
afternoon
welcome
to
the
open,
pgp
working
group-
I'm
Stephen
Farrell,
my
co-chair,
because
he
is
a
large
head
to
my
left
on
the
screen
and
we
have
90
minutes
today.
So
I
don't
think
we're
short
of
time,
but
we'll
see
how
the
discussion
runs
so
tkg,
you're
you're,
you
have
the
slides,
open,
I!
Guess
you
want
to
advance
one.
A
You
so
this.
B
Is
the
note
well
go
ahead?
Do
you
wanna,
do
you
want
to
do
it?
Stephen
I
can
just
run
the
slides
yeah.
You
you've
got
the
button,
so
you
go
ahead.
Okay.
This
is
the
note
well
we're
on
day
two.
Hopefully
you've
already
seen
the
Noel
just
covers
what
to
do
here
within
the
IDF
a
couple
more
slides
here,
breaking
that
down
a
bit
further,
so
we
have
hybrid
meeting
tips
here.
B
Please
make
sure
if
you're
in
the
room,
you're
connected
to
the
meadeco
light
client
link
from
data
tracker
agenda.
If
you
are.
D
B
B
We
are
aiming
for
courteous
discussion.
Please
communicate
slowly
limit
the
use
of
slang
and
jargon.
B
I
might
run
a
Fallout
of
some
of
those
things
myself
feel
free
to
encourage
me
to
correct
if
I
do-
and
we
argue
through
a
reason
not
through
intimidation
or
personal
attack,
and
we're
aiming
for
solutions
that
work
for
the
whole
internet
ecosystem
not
just
for
one
particular
vendor
or
one
particular
Tech
stack,
and
we
are
all
here
to
contribute
to
the
ongoing
work
here.
B
So
this
is
the
basic
agenda
that
we
have
coming
up,
but
it's
a
series
of
discussions
of
points
that
have
been
raised
during
working
group
last
call
we've
been
in
work
group
last
call
for
several
months,
we're
now
on
draft
of
seven
of
the
cryptographic
refresh,
which
is
the
only
chartered
work
item.
So
the
main
point
of
the
meeting
here
today
is
to
review
the
points
that
have
been
raised
in
the
working
group.
B
Last
call
and
if
we
happen
to
have
some
time
at
the
end,
Aaron
Worcester
is
offered
to
present
some
material
on
post
Quantum
potential
for
open
pgp,
which
would
need
to
be
done
as
a
recharger
eventually.
So
you
know
if
we
have
time
in
the
session
today,
where
we've
covered
the
issues
of
the
last
call
and
people
are
committed
to
reviewing,
we
can
get
into
some
of
the
other
pieces.
Anybody
want
to
try
to
push
the
agenda
around
a
little.
C
B
C
A
Okay,
so
yeah,
so
Pikachu
is
going
to
run
this
because
he
prepared
the
slides
and
actually
knows
it
much
better
than
I
do
anyway.
So
so
he's
going
to
run
these
issues
again
for
the
no
takers,
if
you
can
kind
of
take
note
of
any
actions
or
conclusions,
that's
the
main
thing.
B
Yep,
so
the
Baseline
just
to
make
sure
everybody's.
On
the
same
page,
we
had
some
discussion
on
the
list.
We
believe
that
the
crypto
refresh
draft
zero
seven
is
going
to
be
the
basis
for
a
working
group
work
going
forward.
Our
goal
is
to
avoid
we
did
decide
on
the
list
that
there
seemed
to
be
a
rough
consensus
towards
trying
to
avoid
conflicts
with
an
alternate
drafts
draft
cook,
where
it's
possible.
B
That
will
be
on
the
agenda
here
today,
but
what
we
also
need
to
confirm
for
working
group
last
call
is
we
need
reviews,
as
you
can
see,
from
the
slides
here.
Several
interesting
and
useful
topics
have
been
raised
in
working
group
last
call,
but
those
are
not
the
same
thing
as
a
in-depth
review
of
what
is
basically
a
pretty
lengthy
document.
So
I
do
encourage
you.
B
If
you
have
an
opportunity
to
read
through
the
document,
give
a
review,
even
if
the
review
says
advert
this
documented,
it
looks
good
or
even
better
I've
implemented
it.
Those
are
great
reviews
to
have,
but
we
need
vocal
responses,
reviews
on
list
even
from
people
who
have
been
contributing
to
the
document
actively.
If
you
can
speak
up
with
a
review,
that
would
be
really
important.
B
If
we
can't
get
this
out
the
door
and
straps
out
the
door,
then
we
don't
get
to
move
on
to
any
of
the
future
work
that
I
know
some
people
in
the
group
have
been
interested
in
so
that
represents
the
state
of
play.
I
hope
that
that
matches
what
everyone
else
has
seen,
I,
don't
think.
There's
anything
new
here
just
want
to
make
sure
that
everybody
here
is
aware
of
where
we're
at.
A
So
so,
if
you
go
back
on
so
on,
the
can
I
just
check
how
many
people
have
or
how
many
people
would
consider
they're
they're
pretty
familiar
with
the
latest
draft
or
the
previous
one.
D
A
Remote
and
that
kind
of
seems
like
not
really
enough,
I
have
to
say
so
so
yeah
so
I'm
asking
how
many
people
would
consider
they're
pretty
familiar
with
draft
six
or
draft
seven
of
crypto
refresh
and
we
had
three
hands
in
the
room.
One
was
the
editor
another
one
was
a
member
of
the
design
team
and
a
coloring
and
a
co-chair
so
that
that
seems
a
little
bit
short.
A
Would
anybody
be
willing
to
kind
of
volunteer
to
do
a
review
of
the
documents
in
the
next
number
of
weeks
so
and
can
the
note
takers
get
their
names?
So
Rick
is
one
of
the
note
takers
of
volunteered
himself.
A
B
A
A
A
Okay,
so
add
yourself
to
the
list
of
victims:
please
and
Jonathan
Hamill
is
the
jump,
the
other
person,
volunteers,
Jonathan.
So
thank
you.
Jonathan
yeah.
A
B
B
So
this
is
the
the
one
of
the
largest
concerns
that
was
raised
on
the
list
during
the
most
recent
discussion,
which
is
that
there
is
this
competing
draft
called
draftkook,
which
has
a
little
bit
of
a
confusing
name,
RFC
4880
bits,
even
though
it's
an
individual
draft,
it's
unlikely
to
actually
be
coordinated
Abyss,
but
it
does
try
to
use
some
of
the
similar
code
points
and
version
numbers
to
what
we
are
using
and
they're.
B
You
know
the
honest
discussion
was
about
whether
or
not
it's
possible
for
us
to
safely
avoid
conflicts
with
that
draft,
since
it
doesn't
look
like
that,
draft
is
going
to
try
particularly
hard
to
avoid
conflicts
with
the
crypto
refresh,
so
I
went
through
the
document
and
did
a
bit
of
a
review
to
look
for.
B
You
know
where
are
the
places
where
there
are
actual
conflicts
in
terms
of
code
points,
and
the
current
the
slide
represent
here
represents
my
understanding
of
the
current
situation
from
the
best
that
I
could
understand
of
what's
missing
the
two
main
things
are
the
new
public
key
format.
It's
called
version
five
in
both
drafts
and
it
yet
it
behaves
slightly
differently
exactly
differently
and
the
new
signature
format
is
called
version,
five
in
both
drafts,
and
it
also
behaves
slightly
differently.
B
So
one
possible
way
that
has
been
proposed
on
list
to
deconflict
is
to
Simply
move
the
crypto
refresh
draft
to
call
those
things
V6
and
that's
an
option.
So
it
would
be
interesting
to
hear
from
folks
who
have
an
opinion
on
that.
I
will
note
in
the
right
hand,
column
on
the
side
here.
B
The
design
team
already
did
a
fair
amount
of
work
to
ensure
that
there
is
no
conflict
on
other
parts
of
the
code
points
and
there's
a
there's.
A
list
on
the
side
here
feel
free
to
ask
for
clarifications.
I,
don't
know
that
I
need
to
read
through
all
of
the
details,
but
there
are
some
subtle
differences
between
the
two
drafts
that
already
do
not
conflict
because
of
the
work
the
design
team
already
did.
B
So
it's
mainly
a
key
and
signature
versions
that
we
need
to
change
in
my
understanding
of
the
two
documents
to
avoid
a
full
conflict,
so
I
wonder
whether
anybody
here
I
got
two
questions
for
the
room.
One
is:
did
this
review
miss
anything
and
obviously
we
don't
have
to
be
conclusive
here
and
two
is
if
this
is
the
only
thing
or
if
this
is
a
work
group
interested
in
making
this
kind
of
a
change
to
avoid
a
conflict.
F
Hi
I'm
Paul
Walker
speaking
as
an
individual
from
a
process
point
I
find
it
a
little
strange
that
the
working
group
that
basically
sort
of
owns
the
Ayana
Registries
now
has
to
see
if
it
can
use
its
own
Ariana
Registries,
because
some
of
the
squatting
on
the
numbers
so
from
a
process
point
of
view.
I
think
we
should
just
continue
going
on
using
our
registry
numbers,
and
if
anyone
is
squatting
on
them,
then
it's
their
problem
right.
They
should
not
do
that.
F
They
should
use
private
use
numbers
or
they
should
pick
experimental
numbers
or
like,
like
the
the
fact
that
that
someone
just
unilaterally
decides
to
use
their
power
of
deployment
to
sort
of
interfere
with
our
Registries
I
think
is
from
a
from
a
more
principled
point
of
view.
I
would
just
say
we
should
ignore
that
I
agree
that
that
could
cause
operational
issues.
G
Also,
I
think
that
the
points
that
were
already
conflicted
were
already
conflicted
because
there
was
a
wide
deployment
or
at
least
a
deployment
of
these
in
the
wild,
while
I
think
signature
version.
5
is
not
yet
so
I
understand
using
the
C
by
dv2,
but
I
would
not
justify
now
switching
already,
because
someone
threatens
let's
say
it
like
this.
B
Yeah,
secure
Daniel
I
believe
you're
next.
Thank
you.
H
Yes,
so
Daniel
Heavens,
proton,
I
I
do
want
to
note
that
Werner
said
at
some
point
that
well
he
seemed
open
to
still
changing
key
version.
5
and
signature
version.
Five
since
yeah
as
Aaron
noted,
it's
not
yet
deployed.
H
Although
I
worry
that
well,
I
I'm,
not
sure
if
he
would
be
open
to
using
it
in
the
way
that
the
crypto
refresh
defines
and
yeah.
It
would
be
nice
if
he
were
here
in
my
opinion,
so
that
we
could
ask
that
question.
H
However,
I
I
do
worry
that
if
we
deploy
version
5
and
and
he
deploys
version
five
in
a
way
that
it's
currently
implemented,
that
will
have
some
incompatibilities
and
that
I
mean
the
worst
case
scenario.
I
see.
Is
that
we'll
end
up
with
try
catches
everywhere
to
you
know
parse
one
way
and
then,
if
it
fails
Parts
the
other
way
I
I
would
prefer
to
avoid
that,
if
at
all
possible.
H
So
even
though
I
agree
with
the
the
comments
that
we
shouldn't
necessarily
throw
our
hands
up
in
here
and
say:
okay,
let's
go
with
version
six,
but
that
might
still
be
be
preferable
to
that
outcome.
Although
I
mean
Devil's,
Advocate
would
say
that,
maybe
if,
if
werners
really
contrary
and
then
later,
he
would
deploy
some
other
version,
6,
which
is
a
continuation
of
his
current
version
5
and
then
we're
in
an
even
bigger
mess,
although
I
I
would
I
mean
that
would
be,
you
know
really.
H
If
version
6
is
by
then
already
deployed.
I
would
really
doubt
that
but
yeah
it's
something
to
consider.
A
So
two
two
points.
I
guess
you
know
we
can't
really
speculate
as
the
the
motivation
or
action
of
somebody
who's
not
present.
I
A
I,
don't
think
there's
that
much
more
than
that.
The
second
point
is
that
I
mean
we.
You
know
in
the
discussion
as
to
whether
to
go
forward.
Crypto
refresh
I
think
there
was
a
pretty
clear
consensus
to
go
forward
with
crypto
refresh,
but
also
to
avoid
conflict
where
feasible,
I
mean
I.
Think
that
was
a
pretty
clear
outcome
of
that
discussion.
I
think
so,
while
you
know
we
there
might
be
some
gritted
teeth,
but
I
think
that
that's
essentially
what
the
I
think
the
conclusion
of
that
fairly
dented
discussion
was
so
I.
H
Guess
here
it
seems
quite
obvious
that
the
avoiding
conflict
is
feasible,
but
it's
not
100
certain,
whether
there's
conflict.
Yet
right,
it
seems
version
5
of
werner's
draft
is
not
deployed
yet
as
far
as
I
know
so
I
guess.
The
question
is
whether
we
should
anticipate
that
conflict
or
not,
but.
H
H
A
We're
gonna
take
this,
but
again
we
do
what
the
working
group
wants,
but
it's
it's
a
tricky
and
undesirable
situation,
but
dealing
with
it
is
what
we're
here
for.
B
Sorry
about
that
so
yeah,
so
I
will
frame
a
conquer
proposal,
I'm
not
even
sure
whether
I'm
in
favor
of
it
or
not,
but
the
conquer
proposal
would
be
to
move
the
current
draft
from
V5
to
V6
or
Keys
signatures.
B
B
We
could
also,
if
we
wanted
to
move
this
SCI
PD
V2
to
V6
if
we
wanted
everything
to
be
V6
but
I'm
proposing
the
proposal
I'm
making
here
is
that
we
leave
sapd32
sv2
and
we
just
change
the
other
four
version
numbers
to
V6
in
the
draft.
So
if
that
is
one
option
that
we
could
do
I'm
kind
of
tempted
to
do
a
show
of
hands
here,
whether
people
want
to
do
that
or
actively
do
not
want
to
do
that.
A
A
A
F
Okay,
pass
begins,
so
just
one
note
down
so
I
don't
want
to
end
up
in
a
match
about
who
has
the
latest
newest
shiniest
version
right,
because
if
a
response
could
be
that,
then
the
the
persons
from
version
5
will
bump
to
version
eight
or
something
so
that
they
are
seen
as
the
latest
version,
then
we're
going
to
jump
this
game
in
a
number
of
iterations,
sir,
so
so
I
mean
it
kind
of
depends
a
little
bit
on.
A
So
I
I
guess
again,
I
I
think
I
would
disagree
with
you
Paul
on
the
basis
that
we
seem
to
have.
It
demonstrated
evidence
that
we're
not
going
to
get
that
information.
A
B
And
there
is
information
in
the
form
of
a
draft
of
draft
Pro
that
says
here's
what
we
plan
to
do
for
version
what
we
will
do
for
version
five
I
agree
with
with
Paul
with
Paula
like
version
number
escalation,
is
a
silly
silly
outcome:
I'm
not
proposing
B6,
because
it's
bigger
than
E5
I'm
closing
it,
because
it's
different
foreign.
J
Hi
everyone
Carnegie
Mellon
University,
not
as
A.D
I,
wanted
to
just
to
kind
of
ask
we're
worried
about
this
version
escalation.
Do
we
care
we
specified
six,
so
someone
else
says
seven.
If
we
got
to
do
something
else,
we'll
do
it
so
we
have
a
lower
version.
Number
I
mean.
Can
someone
explain
why
that's
a
problem
other
than
I
guess
this
idea
of
semantic
versioning
higher
is
newer.
B
I
mean
it
depends
on
how
we
play
the
game
right.
I
mean
there.
There
are
256
versions,
We
have
a
one
octet
version
number
in
multiple
places
here
so
I
guess
it
could
get
Super
Silly
there,
but
I
don't
think
anyone
is
proposing
to
do
that
level
of
escalation.
Yeah.
J
Yeah
I
mean
there's,
certainly
a
code
Point
space
to
manage
the
reason
why
I
make
that
comment
is
just
I'm
fresh
off.
You
know
out
of
the
quick
working
group,
they
are
defining
quick
V2
who's
I,
whose
version
number
is
not
V2,
but
that's
the
name
of
the
draft
and
from
talking
with
them,
there's
no
guarantee
in
the
future
that
the
the
how
big
or
small,
the
number
is
you
know,
indicates
any
lineage
or
kind
of
sequence.
I
wonder
whether
we
can
just
do
something
like
that
to
make
progress.
A
Yes,
so
I
I
I,
don't
think
we
have
a
huge
blocker
here.
You
know
it
is
the
case
that
it's
easier
for
quick
to
to
upgrade
versions
than
for
a
store
and
forward
thing,
but
but
yeah
I
don't
think
it's
a
huge
deal.
So
so,
okay
I,
don't
see
other
people
joining
the
mic
line.
So
should
we
try
the
poll
tool
and
see
what
if
people
think
dkg's
suggestion
has
typed
into
the
chat,
is
worth
pursuing?
A
A
A
H
I
mean
so
just
the
only
thing,
as
I
said
as
I've
as
far
as
I
understood,
Werner
was
still
open
to
changing
things.
H
A
I'm
happy
to
take
an
action
to
try
that
so
once
we
have
outcomes
in
this
meeting
in
terms
of
minutes
and
so
on,
I'll
certainly
Reach
Out
and
bring
any
new
information
back
to
the
list.
Thanks.
B
And
I'm,
assuming
that
that
process
Stephen
would
have
some
termination
date
if
we
don't
get
any
response,
yeah
yeah
and
we
can't
just
wait
indefinitely
Samuel
in
the
chat,
is
asking
if
it's
possible
to
remove
one's
vote.
I'm,
not
sure
what
that
means.
A
So
you
can
change
your
mind
during
the
poll.
So
I
just
click.
You
know
just
toggle
the
the
radio
button,
but.
I
Rick
foreign
personal
here
I
think.
The
point
is
that
we're
not
dealing
with
versions
but
variants
here
so
V5
should
be
or
V6
should
be
right,
varying
six
and
that
can
coexist
because
that's
actually
what's
offered
us.
It
just
uses
it
as
a
switch
deck.
It's
not
like
a
is
larger
than
b,
so
the
race
for
first,
nothing
doesn't
exist.
C
A
Okay,
so
I
think
we've
is
there
anything
on
the
right
hand,
side
of
tkg
slide
that
people
would
disagree
with
or
I
think
requires
some
more
discussion
here,
or
is
he
correct
about
these
d-conflicts
having
been
done
already.
A
Okay,
I,
don't
see
anybody
looking
like
they're
I,
see
a
bunch
of
people
who
don't
know
like
me,
but
I
trust
EKG
to
get
it
right.
I,
don't
see
anybody
because
I'm
saying
that
there
is
something
on
the
right
hand,
side
of
the
slide
that
we
may
need
to
decide
on
right
now.
F
B
Yep,
so
one
of
the
issues
that
came
up
during
working
with
Glasgow
was
from
Aaron,
who
I
believe
is
in
the
room.
We
have
there's
links
in
the
slide.
If
you
want
to
look
at
the
slides
to
abandon
This
Thread
and
to
an
open
issue
in
gitlab,
The
Proposal
was
to
try
to
So
currently
the
version
5
signatures
which
may
be
version
six.
If
we
do
this
change,
everything
here
is
still
as
soon
as
Baseline
version.
B
Five
on
these
slides,
they
have
a
salt,
a
16,
octet,
salt
and
Aaron
was
recommending
moving
that
to
a
larger
assault
in
preparation
for
some
of
the
post
Quantum
signing
schemes
that
need
a
larger
salt,
Aaron
offered
sort
of
menu
of
options
there
either
all
the
cells
could
be
larger
or
you
could
make
the
salt
variant
in
size
based
on
like
the
hash,
algorithm
and
I.
Wonder
whether
folks
want
to
speak
to
that
Scott
during
the
queue
mm-hmm.
K
Yes,
I
just
happen
to
be:
have
looked
at
the
various
posts,
Quantum
signature,
algorithms-
they
all
have
all
three
of
them-
have
some
some
prefix
in
front
of
it
much
larger
than
16
octets,
some
of
them
based
either
based
on
the
public,
key
values
or
just
some
random
values
that
Designer
picks.
Now
you
could
either
build
that
into
the
one
pass.
Signature
message
or
just
another
possibility
is
just
do
maybe
a
sold
it
a
standard,
solid
hashtag.
K
K
All
right
and
so
avoid
getting
in
the
details
of
how
things
dilism
and
Falcon
work.
B
So
you're
saying,
then
that
for
the
Post
Quantum
schemes
they
would
their
signature
packet
would
contain
a
salt
that
salt
would
be
pre-pended
to
the
digest
the
open,
pgp
style
digest.
So
you
don't
need.
K
K
It's
a
little
more
complex
because
sometimes
it's
it's
depending
on
the
algorithm.
It's
either
for
in
the
signature
or
in
the
public
key.
G
So
also
in
the
next
presentation,
as
long
as
I
have
something
about
this
very
problem,
the
lithium,
for
instance,
has
the
propense
with
the
public
key.
Whilst
things
has
a
right,
an
optional,
random
salt,
the
idea
would
be
basically
to
disable
the
option
on
random
salt
into
Sphinx,
for
instance,
yes
to
the
side
yeah.
So
it's
sorry.
B
K
A
correction
how
things
Works
it
has
the
option:
the
optional
salt
is
to
the
signer.
The
signer
always
picks
a
random
value.
It's
just
that
is
it
this.
The
designer
may
use
a
actual
random
to
to
further
randomize
it
or
go
with
a
default.
The
verifier
doesn't
know
or
care.
G
G
The
deletion
case
I
think
it
would
be
fine
still
with
the
pre
with
this
construction,
because
you
still
apply
the
the
public
key
at
the
prefix
of
then
a
hash.
So
you
basically
hash
together
the
public
key
and
then
they
already
derived
a
hash
that
you're
signing
from
openpgp.
G
The
the
request
here
comes
the
there.
Are
these
two
options?
Either
we
want
to
make
this
Sim
simple
implementation
and
put
32
octets
for
everything
or
whether
we
want
to
bind
it
to
the
hash
algorithm.
In
my
opinion,
because
the
thing
we're
trying
to
to
solve
the
issue,
we're
trying
to
solve
is
a
collision
into
the
hash
when
signing
and
we
need
an
unpredictable
sold
for
whether
it's
signing
for
whoever
is
creating
the
signature.
D
G
So
if
we
bind
it
to
the
hash,
algorithm
I
still
have
a
proposal
later
when
we
do
pqc
to
bind
the
hash
algorithm
to
the
public
key
algorithm
in
signature,
for
instance,
first,
like
the
lithium
uses
chapter
internally
using
Chateau
and
then
shatri
would
be,
in
my
opinion,
a
bad
idea.
So
you
expanded
the
the
attack
surface
still
I
think
that
it
makes
sense
to
this
change
now,
because
the
hash
algorithm
that
we
Define
into
B5
would
mean
doing.
G
Basically,
we
would
already
have
longer
souls
for
existing
hash
algorithms
and
if,
instead
we
want
to
buy
directly
to
the
publicly
public
key
algorithm,
then
that's
fine.
We
can
just
do
it
later.
G
So
my
concrete
proposal
is
binding.
The
signature
salt
length
to
the
hash
algorithm
used
to
derive
that
salt
to
derive
that
the
signature,
so
you
use
Shadow
shot
256,
you
have
a
16
opted
salt,
you
use
sha
512,
you
get
a
32,
octet
sold
and
yeah.
B
B
So
I
I
have
a
if
we're
going
to
bind
to
the
hash
algorithm
used,
then
it
seems
like
one
other
option
would
be
to
say
that
you
get
a
different
hash
algorithm,
for
we
could
introduce
a
novel
hash
algorithm
specifically
for
the
Post
Quantum
stuff
right.
So
for
for
sorry,.
A
D
B
Variation,
if
the
but
I
just
heard
about
dilithium,
which
is
leading
to
Hash
the
public
key
material
in
as
well,
doesn't
line
up
with
open
pgp's
one
pass
signature
framing,
because
the
one
pass
signature
doesn't
know
anything
about
what
Pub
Key
algorithm
is
going
to
be
used.
It
only
does
the
it
only.
Does
it
digest
before
calculation
Aaron
yeah,
please
so.
G
When
you
hash,
as
far
as
understood
when
you
hash
at
first
like
the
when
you
start
the
hash
with
prefix
the
hash
with
the
public
key,
that
is
not
meant
to
avoid
Collision,
because
the
public
key
is
known,
so
an
attacker
could
just
like
doesn't
need
that,
like
it's
not
met
there
for
Collision
is
therefore
kind
of
binding,
let's
say
so.
If
even
if
we
put
the,
if
we
use
it
later
in
the
hash
within
the
opaque
algorithm,
let's
say
it's:
it's
fine
I
think.
D
B
So
so
the
current
proposal
is
that
we
bind
it
to
the
hash
out.
We
bind
the
length
to
the
hash
algorithm
and
it
is
the
length
of
the
hash
algorithm
output.
G
It's
it's
actually
the
security
level
of
the
hash.
So
it's
half
of
the
length
because
of
the
collisions
thing
so
I
think
the
shadow
physics
has
a
32
octet
and
we
use
16
and
so
on
got
it.
B
Okay,
so
let
me
propose
a
separate
variant
just
to
see
if
people
have
a
preference
here,
which
is
that
we
add
a
column
to
the
hash
algorithms
table
that
says
the
length
of
the
salt
for
this
hash
algorithm
is
X.
B
And
then,
if
you
encounter
and
we
set
them
all
initially
to
16
octets
and
then,
if
you
have
a
post,
Quantum
algorithm,
we
say:
oh,
you
need
a
special
hash,
we'll
bind.
It
will
allocate
a
new
point
in
the
space
and
it'll
be
shot
356
with
longer
hash,
and
it
has
the
same
code
path,
but
it
lets
us
put
a
larger
hash
in
when
we
need
it
and
we
don't.
If
we
don't
know
what
the
larger
hash
is
now
we
can
just
put
the
larger
hash
in
later.
B
K
Well,
obviously,
if
they
don't
know
the
hash
algorithm,
they
can't
actually
verify
any
signatures.
On
the
other
hand,
I
don't
see
the.
Why
is
there
making
distinction
between
post-quantum
or
non-post
Quantum
terms
of
salt
size?
The
attack
they're
addressing
collisions
are
it's
the
same.
Both
both
cases.
D
E
I've
been
confused
for
the
whole
time
so
I
that
the
thing
is
for
the
lithium
and
for
falcon
the
for
the
Falcon.
The
results
is
the
fixed
size
and
that's
come
along
with
the
message
when
you
have
it
for
the
deletion.
E
The
salt
is
basically
the
internal
value
which
can
be
either
derived
from
a
part
of
the
public
key
or
you
could
make
a
fresh
or
truly
random
value
as
a
salt
internally
for
the
signing,
but
the,
but
the
signature
itself
does
not
have
any
salt,
and
also
even
internally,
that
source
is
a
fixed
value,
five
terabits
law.
So
that's
why
I've
been
confused.
I,
don't
really
know
what
the
discussion
we
have
been
talking
about.
B
F
B
Think
here
is
that
open
pgp
has
an
expected
frame
for
all
signatures
where
it
does
a
digest
and
then
the
digest
is
passed
to
a
public
key
algorithm,
and
that
is
peculiarity
of
openpgp
and
not
a
frame
that
we
have
proposed
breaking.
B
Should
new
algorithms
come
along
I,
don't
think
it's
the
right
time
for
us
to
figure
out
how
to
do
Post
Quantum,
exactly
the
the
goal
for
right
now
is
to
figure
out
what
should
we
do
about
the
cells
themselves
so
that
we
don't
have
too
much
breakage
when
we
get
to
PQ
stuff.
C
E
So
I'm
talking
about
signature
along
the
the
Falcon
needs,
assault
must
have
assault
and
the
salt
is
fixed
in
its
back
the
false
lens
fixed
in
in
this
bag.
But
the
lithium
signature
does
not
contain
assault,
but
internal
signing.
There
must
be
a
student
random
number
of
bit
string
of
five
terabits
long
or
you
have
a
truly
random
bit
string
five
terabits
long
used
in
the
signing
procedure.
E
A
Yeah,
so
so
great
I
think
my
so
my
my
understanding,
which
is
probably
worse
than
most
people
in
the
room,
is
that
pgp
is
already
hashing
the
the
message
and
it's
only
the
hash,
that's
going
to
be
fed
into
the
new
signature
algorithm.
So
now
we
want
to
also
add
a
hash
from
from
the
pgp
protocol
plus
assault
for
the
pgp
protocol
and
get
that
signed
and
whether
the
the
signing
algorithm
involves
other
assaults
or
the
randomness
is
a
different
matter.
I.
E
G
I
I
think
that,
like
the
lithium,
as
far
as
understood,
contains
the
it's
meant
to
randomize,
the
signature
is
not
meant
as
a
soul
to
avoid
Collision.
G
Basically,
what
the
attack
we're
trying
to
to
towards
here
is
the
following:
I
create
a
second
text
that
hashes
to
the
same
result
as
the
first
text,
so
we
have
two,
and
this
basically
lowers
the
security
on
the
whole
setting,
because
we,
instead
of
instead
of
just
a
the
hash,
is
that
if,
if
we
use
an
unpredictable
sword,
we
just
need
second
pre-image
resistance
onto
the
hash.
G
Well,
instead,
if
we
just
use
an
unsalted
salt
and
salted
hash,
we
need
Collision
resistance
into
the
hash
and
we
have
seen
with
Shawan
that
Collision
resistance
can
disappear.
Let's
say
it
like
this,
so
I
think
that
this
is
just
like
a
a
little
change
to
match
the
security
level
of
of
of
sphinx
plus
I
personally
think
that
16
often
sold
being
it
an
online
attack.
So
you
need
a
someone
to
sign
that
message.
Many
times
till
you
get
the
right.
G
So
it's
still
a
very
large
value,
so
I
see
the
value
into
dkg's
proposal,
I.
Just
don't
like
it
personally,
because
I
think
it
is
like
it
creates
another
Edge
case.
Instead,
if
you
bind
everything
to
the
hash
algorithm,
no
matter
is
if
it's
post
or
pre
Quantum
I,
think
it's
better,
but
that's
a
personal
opinion.
Okay,
Mike.
C
C
Personal
vote,
dkg
I,
would
say
just
go
ahead
with
this.
This
is
well
into
splitting
hairs.
I'd
also
want
to
point
out.
This
is
a
perfect
I
mean
you've
sort
of
stepped
in
a
bear
trap.
This
is
a
perfect
topic
for
Roman's
new
pqc
working
group,
because
everyone's
going
to
have
to
face
this
question
of
whether
we
pre-hash
dilithium
and
falcon
or
not-
and
if
we
prehash
it,
do
we
salt
it
or
not,
and
this
is
going
to
come
up
absolutely
everywhere.
A
So
I
think
we
have
three
options.
One
is
the
status
quo,
which
is
a
fixed,
then
16,
octet
cells.
Oh
pardon
me,
Robin,
go
ahead.
L
Hi
is
the
mic
working
yep,
okay,
yeah,
just
sorry
to
to
preempt
your
your
summary.
L
If
I
remember
correctly,
a
few
itfs
back,
cfog
I
think
it
was,
was
discussing
a
a
dual
or
hybrid
signature
scheme
where
you
would
have
an
algorithm
that
was
thought,
probably
not
to
be
post,
Quantum,
safe
and
one
that
you
thought
was
post
Quantum
safe,
and
you
would
actually
doubly
sign
things
that
you
wanted
to
sign
with
the
goal
that
you'd
you'd
have
compatibility.
L
You'd
have
Legacy
compatibility
because
of
the
non-safe
algorithm
until
such
time
as
you
wanted
to
stop
using
that
or
had
to
stop
using
it,
but
you
would
be
signing
things
now
with
an
algorithm
thought
to
be
post
Quantum
safe
and
the
the
driver
of
that
was
simply
the
length
of
time
for
which
you
might
want
a
signed
object.
The
signed
artifact
to
persist,
so
is
there
an
alternative
here
to
say,
treat
these
different
salt
lengths,
as
if
you
like,
probably
not
Quantum,
safe
and
probably
Quantum
safe
variants
and
do
a
dual
signing.
G
Aaron,
you
are
like
reading
my
slides
that
come
in
the
next
presentation.
This
is
another
topic,
so
I
would
like
to
say
maybe
of
this
length
of
salt.
We
could
discuss
after
the
second
presentation,
because
there
is
a
better
explanation
there
and
also
the
idea
of
signing
twice
with
the
pre
and
the
post
Quantum
key.
So
so,
yes,.
A
And
no
so
we're
not
chartered
to
do
work
on
postponed
crypto.
So
we
need
to
make
this
decision
regardless.
A
So
I'm
going
to
suggest
that
we
have
a
try,
a
poll
with
three
options:
one
is
the
status
quo,
which
is
a
fixed
length,
16
octet,
salt.
The
second
is
the
proposal.
Iron
maid,
where
the
salt
length
is
tied
to
the
Collision
resistance
size
of
the
hash,
and
the
third
proposal
is
I.
Think
what
dkg
suggested
is
that
we
add
a
column
to
the
Ayana
registry
for
each
signature
type
receipts
for
each
signature,
algorithm
that
we
have
a
salt
length
parameter
in
the
registry.
B
I,
just
wanna
I
wanna,
I
wanna
point
out
that
I
think
we'll
need
a
column
for
the
registry
in
either
case,
because
the
registry
needs
to
know
what
is
the
Collision
resistance
of
each
algorithm.
I
mean
if
you're
an
expert
in
the
algorithms.
You
know
what
that
is,
but
we
will
need
the
table
in
any
case.
The
question
is
whether
we
want
the
table
to
exactly.
We
want
the
column
to
match
the
Collision
resistance
and
okay,
given
the
discussion,
I
I'm,
definitely
not
I'm,
no
longer
interested.
A
Oh
okay,
so
proposed
dkg's
proposal
was
withdrawn.
Does
anybody
else
want
to
put
tkg's
proposal
back
on
the
table?
Okay,
so
then
we
have
two
proposals.
One
is
Aaron's
suggestion
that
the
salt
length
is
tied
to
the
Collision
resistance
of
the
hash
function
and
the
second
one
is
the
status
quo.
Where
we
have
a
16
octet
salt.
Do
you
want
to
start
the
pole
dictator
should
I.
B
Okay,
so
raise
your
hand
if
you
think
we
should
have
the
Collision.
The
salt
length
match
the
Collision
resistance
of
the
hash
function
and
do
not
raise
hand
if
you
think
we
should
stick
with
the
status
quo
and
if
you
want
to
abstain,
you
do
that
by
abstaining
foreign.
A
So
if
you
raise
your
hand,
if
you
want
Aaron's
proposal
to
make
the
salt
lens
the
the
Collision
resistance
size
of
the
hash
and
click,
the
do
not
raise
your
hand
if
you'd
like
to
stick
with
the
status
quo
of
a
fixed,
16,
octet
salt
and
it
seems
to
be
stable
and
relatively
clear,
and
we
have
15
raised
hands
and
one
not
raised
hands.
It's
useful
to
check
with
the
person
who
clicked
do
not
raise
hand.
Would
they
like
to
say
at
the
microphone?
Why
that
can
that
can
be
helpful
information.
K
Yes,
this
is
me.
The
reason
is
that
why
is
there
assault
there
if
it's
to
provide
to
provide
Collision
resistance,
which
means
that
a
collision
would
apply?
It
would
apply
only
if
they
managed
to
guess
the
salt
first
and
someone
blindly
guessing
a
16
octet
value
is,
is
sufficiently
improbable
not
to
worry
about.
Okay,.
A
So,
thanks
to
that,
even
Aaron
is
nothing
but
that,
but
we
picked
something.
So
that's!
That's.
That's
not
fair
grab
the
feet
from
the
jaws
of
victory,
I.
B
B
A
B
B
Demi-Marie
open
hour
noted
that,
as
currently
described,
a
version
5
signature
over
a
message
that
is
less
than
four
gigabytes
in
length
can
be
transformed
into
a
version
3
signature
over
a
subtly
different
data
but
signed
by
the
same
key.
So
it
is
possible
for
an
attacker
to
take
a
version.
5
key
and
a
version.
B
5
signature
extract
the
cryptographic
key
material
from
the
key,
transform
it
into
a
V3
key
and
then
make
take
the
take
the
V5
signature
and
apply
it
to
a
weird
variation
of
the
text
that
was
originally
signed
and
the
signature
will
still
validate
for
those
things
that
validate
B3.
B
B
B
So
it's
not
clear
that
we
need
to
do
this.
On
the
other
hand,
the
change
is
not
particularly
big.
It
just
basically
moves
some
bites
around
to
prevent
the
the
signature
from
being,
at
least
in
the
same
way,
be
relatively
easy
to
do
the
change
and
avoid
it
for
those
things
that
are
failing
at
their
rejecting
V3
signatures.
B
I,
don't
know
who
else
I
know
that
there
are
at
least
a
few
people
who
have
read
this
issue
and
commented
on
it.
I
think
Eustis
is
there
and
has
read
in
commented
on
it,
I
don't
know
whether
anybody
else
wants
to
speak
to
this
or
not.
B
B
Yes,
Robin,
you
are
reading
that
correctly.
The
the
issue
here
is
that
D5
signatures
Hash
a
trailer
that
consists
of
an
eight
octet
size
value
of
the
message
and
the
fourth
signature,
the
three
signatures
as
a
trailer
hash,
the
timestamp
of
the
signature
prefix
by
the
the
signature
type.
So
as
long
as
as
long
as
the
fifth
octet
from
the
end
is
a
zero,
then
the
remaining
bits
will
appear
as
a
time
stamp
when
you
interpret
the
hashed
stream
as
a
V3
as
a
V3
signature.
B
This
is
a
weird
thing:
it's
not
clear
that
we
have
a
specific
attack,
but
that's
the
that's
where
the
four
gigabyte
boundary
comes
from.
This
is
not
an
issue
for
V4,
because
V4
hashes
the
file
size
at
the
end,
but
it
before
the
file
size
comes
as
0xff
octet
and
there
is
no
signature
type
0x.
D
A
The
does
anybody
think
they're
in
a
position
to
does
anybody
need
more
information
before
having
an
opinion
on
this,
or
do
you
think
you
have
enough
information.
B
B
A
H
So
we
don't
support
V3
signatures
anymore
already,
since
a
long
time
and
haven't
had
major
issues
as
far
as
anywhere
so
I
don't
have
a
particularly
strong
opinion
on
this
I'm
I'm
fine,
with
changing
it
I'm
also
fine,
with
not
changing
it.
So
I
yeah.
A
B
B
And
so
that's
that's
why
we
have
this
aliasing
problem.
If
the,
if
the
version
number
was
hashed
in
at
the
beginning,
then
we
would
not
have
this
issue.
The
trouble
is
that
that
we
have
this
this
regular
pad.
This
pattern
of
changing
open
hours
proposal
would
make
it
so
that
the
version
of
the
signature
is
always
a
fixed
length
from
the
end
of
the
hash
stream,
whereas
right
now
V3
doesn't
have
a
version
number
in
it.
B
The
four
has
a
version
number
at
the
sixth
octet
from
the
end
and
B5
has
a
version
number
at
the
ninth
octet
from
the
end
Yeah.
I
B
You
know
the
concern
is
we
have
the
sequence
of
data
that
goes
into
the
hash.
If
we
know
that
that
sequence
of
data
is
a
version,
is
a
version
three
signature,
there
is
no
way
to
find
that
it
is
version
3
from
that
sequence.
If
we
know
that
the
signature
is
a
V4
signature,
we
find
the
version
number
from
the
sixth
octet
from
the
end.
If
we
know
that
it's
a
V5
signature,
we
find
the
version
number
from
the
10th
octet
from
the
end
in
the
current
proposal.
A
Okay,
so
so
again,
just
as
a
time
check,
we've
got
a
half
hour
left.
So
there's
a
couple
other
issues
to
get
to
I
I
think
we
have.
You
know
we
have
input
on
this.
It's
clearly
in
One
Direction.
We
have
eight
raise
hands
and
two
not
raised
for
the
record.
It's
a
little
bit
less
strong
than
the
previous,
so
I
I
guess.
The
action
here
will
be
to
make
that
change
but
be
open
to
somebody
on
the
list
raising
new
information
in
the
next
short.
A
A
B
Recommended
a
context
parameter
for
encryption
to
ensure
that
things
could
not
be
decrypted
in
surprising
contexts.
This
is
part
of
the
work
on
defending
against
detail.
B
B
However,
doing
this
requires
a
definite,
a
shared
definition
of
a
context
and
no
one
has
proposed
well
Brinkmann
proposed
a
specific
context
for
email
signatures,
but
it
is
not
clear
if
we
would
be
able
to
use
a
V5
signature
for
email
without
this
context
in
like
this
might
delay
the
adoption
of
the
additional
signatures
or
additional
encryption
of
using
the
signatures
or
encryption.
B
B
D
H
Yes,
so
I'm
quite
in
favor
of
this,
as
you
know
and
I
think
for
for
me,
this
is
most
important,
possibly
for
new
applications
that
might
want
to
use
open
bgp
that
want
to
ensure
that
messages
or
signatures
can't
be
that's
a
transplanted
into
different
contexts,
contexts
or
different
applications,
so
having
even
just
an
application
identifier
in
the
context
Plus
in
my
opinion,
having
some
application,
specific
contexts
parameter
that
that
can
be
defined
in
in
you
know,
the
applications,
usage
of
open
b2p
would
be
very
useful.
H
I
do
also
agree
that
for
email
moving
to
a
shared
understanding
of
what
the
context
should
be
is
a
lot
of
work,
and
it's
not
clear
that
we
can
do
that,
like
you
know
in
in
the
next
few
weeks
or
so,
but
nevertheless
I
think
it
would
be
valuable
to
add
context
parameters
in
the
spec
so
that
new
applications
can
start
using
it
and
and
then
we
can
separately
think
about
how
to
move
email
to
that.
H
Yeah,
yes,
so
that
could
be
one
option.
Another
option
could
be
to
to
have
a
registry,
as
I
I
think
dkg
perhaps
suggested
having
a
registry
of
application
identifiers,
and
then
we
could
still
already
Define
one
for
email.
Just
so
that
sign
messages,
messages
and
signatures
for
email
are,
are
separate
and
can
be
transplanted
to
other
applications
but
and
and
then
have
after
that,
an
application
specific
context
parameter
that
we
could
figure
out
later
what
that
should
be
for
email
and
each
other
application.
If
that
makes
sense,.
A
H
A
Okay,
so
I
I
yeah,
that's
starting
to
sound
like
a
bunch
of
work,
but
so
Rick
you're
annoying.
I
Rick
for
Ryan,
responding
to
Daniel's
proposal,
I
like
the
ability
to
separate
applications
you
mentioned
the
registry-
is
that
a
deliberate
proposal.
Is
that
just
something
that
pops
up?
Because
it
means
you,
you
require
a
lot
of
extra
work
for
registering.
You
could
also
consider
no
ID
which
anyone
could
register
or
you
you
ID,
which
is
even
simpler.
These
are
not
security
attributes
anyway,
so
it's
good
to
think
about
what
form
of
identity
you
want
to
use.
B
So
what
the
reason
for
the
registry
I
believe
is
to
coordinate
among
users
to
say:
oh
I
get
it
I'm
in
this
context,
I'm
going
to
use
this
particular
Machinery.
My
concern
there.
Even
if
we
just
have
a
registry,
that's
email
and
not
email
is
if
I
send
you
an
email
with
an
attachment
that
is
pgp
encrypted.
Should
it
be
decrypted
with
the
email
context,
or
should
it
be
decrypted
without
the
email?
B
I,
don't
actually
know
what
that
means.
So
so
then,
the
registry's
job
is
to
coordinate
that
kind
of
thing.
So
I
I'm,
just
saying
I,
don't
if
we're
doing
a
registry
I
still
like
I
kind
of
think
it's
necessary,
but
I
also
don't
even
know
what
would
go
in
the
registry.
So
if
someone
wants
to
propose
that
I'm
I'm
game
to
read
it
over
and
try
to
review.
A
G
B
The
other
option
that
was
mentioned
in
the
discussion
on
list
was
we
can
just
say.
We
know
that
we
know
where
the
context
would
go
in
these
constructions,
both
for
encryption
and
for
signatures,
and
we
could
say
you
know
the
null
context
is
what
we're
defining
here
and
if
somebody
wants
to
define
a
particular
context
in
which
a
the
thing
should
be
used
and
what
the
context
string
should
be.
B
We
can
just
simply
Define
a
V3,
SCI,
PD
and
figure
out
how
to
signal
that
user
supports
that
as
a
separate
work
in
recharger,
word
converter,
because
that's
another
way
forward.
A
A
A
B
B
B
That
would
mean
that
the
public
key
format
would
differ
for
these
things
between
version
4
and
version
5
or
version
six.
If
we
call
it
version
six
I,
don't
know
if
folks
want
to
have
folks
want
to
comment
on
this.
Come
on.
G
I
am
against
this
specifically
because
we
kept
a
hack
in
the
Easy,
Ed
25519,
and
also
the
curve
to
519
implementation,
to
be
consistent
with
V4
and
in
general.
I.
Don't
see
that
much
advantage
in
switching
to
X
only
representation
when
we
have
one
more
issue
and
then
Computing
the
point.
Second,
one
is
not
so
compact,
but
we're
still
talking
about
the
elliptic
curve
keys.
So
I
don't
really
see
an
advantage
in
in
in
in
bandwidth.
B
A
B
Cool
thanks
folks,
moving
on
oh
already,
I
see
you
on
the
list.
There.
L
M
Or
steel
transmute,
just
because
this
issue
has
come
up
on
several
other
lists,
if
you
have
interacted
on
any
of
those
other
lists
and
you
feel
the
same
way
as
you
voted
in
this
context,
please
share
your
opinions
on
those
other
lists,
I'm
thinking
specifically
of
the
Cozy
lists
regarding
key
types
and
key
representations
in
Hosey
and
cozy.
Thank
you.
B
Moving
on
okay,
this
is
our
last
chartered
topic
for
this
meeting,
which
is
about
how
we
handle
the
Ayanna
updates.
We
had
a
call
about
this
last
meeting
and
you
can
see
the
results
of
that
poll
in
issue
140
on
gitlab.
This
is
a
reminder.
The
crypto
refresh
is
going
to
change
almost
all
the
Registries
to
specification
required,
which
means
we
will
have
a
designated
expert
whose
job
is
to
determine
whether
something
is
a
sufficient
specification.
B
The
only
two
Registries
that
will
remain
RFC
required
are
for
version
numbers
wherever
they
show
up
in
the
spec
and
packet
types,
so
the
packet
type
numbers
will
both
require
an
RFC,
so
that's
a
higher
bar
to
meet.
B
This
is
a
reminder
that
that's
you
know,
I
think
we
had
a
rough
consensus
on
this
move
at
the
last
one,
and
we've
talked
about
this
for
over
a
year
now,
but
when
I
just
like
to
confirm
that
that's
what
we
want
to
do
and
we
also
are
going
to
need
people
to
volunteer
to
be
designated
experts,
or
maybe
who
would
be
willing.
People
could
identify
themselves
as
being
willing
to
be
designated
experts
and
I.
Believe
we
will
need
to
choose
those
doesn't
be
experts,
Stephen,
I,.
A
Yeah,
so
the
isg
make
this
Choice,
because
it
it
can
outpass
the
working
group
and
so
on.
So
it's
it's
not
our
call,
but
we
can
certainly
provide
input
to
the
isg
and
if
people
are
willing
to
volunteer
for
it
great,
so
please
do
that
and
I
guess
the
more.
The
more
interesting
question
for
today
is
what
guidance
should
we
have
include
in
the
specification
for
those
experts
and
typically
the
guidance
is
around
you
know
what
level
of
specification
is
consist
considered.
Okay,
is
it
okay
to
have
a
random
web
page?
A
And
this
is
a
topic
where
people
don't
get
excited
until
it's
too
late,
so
I
think
it
would
be
good
to
get
some
input
and
it
gets
too
late
when
somebody
proposes
that
they
want
to
add
something
based
on
what
we
turn
out,
not
to
like
later
Aaron.
G
Given
the
history
of
openpgp,
I
would
say
that
a
draft
is
probably
what
we
want
like
we
have
like.
Wkd
is
a
draft.
The
PKS
is
a
draft
like
they're
all
the
things
that
are
a
bit
related
to
open
pgp
and
they
all
seem
to
be
drafts.
A
So
you're
suggesting
an
internet
yeah
okay,
which
can
be
submitted
that
has
like
a
personal
internet
draft,
is
fine
or.
M
Right
or
steel,
transmute
I
agree
with
what
he
said.
You
said
about
it
being
any
web
page
on
the
internet,
not
that
okay.
M
J
Going
I
want
to
jump
in
in
line
there
are
former
in
real
IDs
kind
of
also
in
this
room
by
my
read
specification
required
is
not
really
an
ID,
because
to
your
point,
it's
mutable
yeah,
just
pointing
that
out.
I
B
Especially,
we
have
a
concern
about
mutability
and
about
reli
like
reliability,
like
being
able
to
find
it
that
it
doesn't
disappear
right,
which
is
I,
guess
an
extreme
type
of
mutability
do
folks
have
an
opinion
about
whether
we
need
something
like
interoperability.
Like
could
you
know,
I
can
publish
any
garbage
as
an
internet
draft,
and
it's
out
there
and
I
can
say.
Oh
just
use
version
zero.
Two
of
my
you
know
thing,
but
that
doesn't
mean
anybody
else
has
actually
done
it
before.
B
J
Just
a
yeah
not
coming
on
the
application,
just
to
kind
of
comment
on
the
ID
draft
to
sensitize
everyone
a
way
to
write
the
considerations
you
know:
IDs
can
change,
you
can
also
do
I'm.
Sorry,
you
could
do
kind
of
specification
required
which
could
mean
ietf
stream.
It
calls
for
me
ISE.
So
that
means
you
know
you're
not
going
through
the
working
group,
and
so
when
we
say
RFC
required,
I'm
actually
not
sure
which
one
we
need
is
that
standards
action
so
ietf
stream
or
is
that
any
kind
of
RFC.
A
J
Yeah
right
but
but
it
needs
a
destination
designated
expert,
because
you
can't
have
a
specification
required
without
a
GE.
You
can
have
a
I,
you
can
have
an
ietf.
You
can
have
one
I'm,
sorry
I'm
just
staring
at
the
right
words.
You
can
say
standards,
action
and
that
can
be
without
a
de,
but
that's
always
bad.
So.
A
A
D
A
J
Thank
you,
yeah
I
mean
the
thing
I
would
kind
of
caution
is
when
we
think
about
what
we
want.
Imagine
the
working
group
is
God.
Yes,
who
are
you
going
to
trust
with
the
code
points?
Because
that's
pretty
much
what's
going
to
happen,
it's
going
to
be
the
de
making
a
recommendation
to
the
isg
plus
that
D
may
be
Consulting
at
work.
I'm.
Sorry,
a
mailing
list,
but
it's
going
to
be.
You
know
what
what
do
you
want?
That
group
of
individuals
to
tell
the
isg
yeah.
G
A
F
F
You
should
really
think
about
I
I,
don't
think
adding
features
that
might
not
get
deployed
widely
is
a
problem
as
long
as
the
registry
is
big
enough
or
do
we
have
any
Registries
that
are
so
small
that
we
want
to
avoid
wasting
numbers
on
them,
and
if
you
don't
have
that
problem
and
I
think
specific
specification
required
is
most
suitable
for
most
of
them.
C
A
Okay,
so
I
think
so.
I
think
it
sounds
like
the
the
guidance
essentially
is
open,
stable
and
likely
to
Foster
interoperability,
and
we
need
to
figure
out
some
words
to
say
that
and
put
it
into
the
ionic
considerations,
who
wants
to
take
an
action
to
craft
that
into
words
I
get
tkg.
You
and
I
should
probably
do
that
right
and
we
should
we'd
hunt
around
for
other
rfcs
that
have
such
guidance
to
try
to
find
a
good
example
to
to
base
on
sorry.
C
A
B
B
I
recognize
that
we
have
10
minutes
left
in
the
in
the
slot
here,
and
we
had
offered
a
potential
chance
to
talk
about
post
Quantum
work.
We
already
did
a
bunch
of
talking
about
post
Quantum
in
the
extended
in.
B
Do
folks
have
any
other
issues
that
were
raised
during
working
group
last
call
that
you
want
to
discuss
now
or
do
you
want
to
try
to
give
Aaron?
You
know
five
to
ten
minutes
to
talk
about
the
post,
Quantum
stuff,
I,
don't
know
if
that's
a
fair
slot
for
him.
A
I,
don't
see
anybody
in
queue,
okay,
so
so
I
guess
we're.
We've
got
a
few
people
agreed
to
do
reviews
additional
reviews.
We've
got
some
actions
to
change.
That
means
we're
extending
the
working
group
last
call
essentially
by
some
number
of
weeks.
Dkg
and
I
will
discuss
off
lists
and
declare
another
date
for
it,
and
hopefully
that
will
encourage
people
to
do
those
reviews
by
that
date.
So
that's,
okay
should
I.
Do
the
slide
sharing
locally
here
at
tkg.
It
might
be
easier
sure.
I
A
G
G
So
the
idea,
the
main
ideas
are
you
to
use
composite
multi
algorithm
for
kyber
and
the
lithium
and
Standalone
Sphinx
plus
to
offer
backwards
compatibility
to
have
two
certificate
to
recommend
a
user
to
have
two
certificates:
one
V4
Legacy,
with
basically
pre-quantum
and
and
Legacy
input
for
legacy,
implementation
and
1v5
with
both
Quantum
or
V6.
G
At
this
point
and
to
ensure
compatibility
on
the
protocol
level
of
adding
multiple
signatures,
so
you
sign
with
both
with
both
keys,
we
use
ECC,
so
we
would,
since
they
are
new
algorithms,
we
would
basically
fix
the
existing
inconsistencies,
use
actual
i65519
x448
as
they
are,
as
they
are
standardized
next
slide
please.
G
So
these
are
the
algorithms
we
thought
of
and
to
maintain
consistency
with
the
crypto
refresh
25509.
It
must
for
for
it
and
shoot
and
everything
else
in
May
things
we
off,
we've
thought
about
offerings
both
Chateau
and
shake.
The
reason
is,
Chateau
is
twice
as
fast,
more
than
twice
as
fast
as
shake,
and
it's
not
even
not
it's
not
really
a
security
company.
A
security
trade-off
seems
like,
but
shake
for
future
compatibility
with
what
comes
next
slide.
G
Sphinxplans
will
have
several
parameters
because
some
users
might
want
to
have
smaller
signatures,
but
very
slow.
So
this
means
like
256
s,
that
takes
even
seconds
to
be
issued,
but
all
these
signatures
are
very
fast
to
be
verified.
So,
on
the
verification
end,
there
should
be
no
issue,
so
it's
just
a
signer
who
decides
how
slow
they
want
to
make
their
work
next.
G
So
basically,
the
basic
design
for
the
cam
is
to
use
ecdh
as
like
a
prime
curve
or
x2519
or
x448,
and
omit
the
key
derivation
step
and
just
keep
the
derive
everything.
So
the
key
encryption
key
is
derived
from
ecdh
with
kyber
and
with
some
fixed
information
is
a
simple
chatri
concatenated
hash
construction
because
of
the
sponge
construction
of
shattri.
We
can.
We
can
do
that
next
slide.
G
So
these
are
the
topic
that
we
already
talked
about.
So
is
basically
the
fact
that
they
are
not
for
like
they
expect
both
the
the
whole
data,
the
whole
message
to
be
fed
into
the
algorithm.
We
cannot
really
do
that
because
we
do
streaming
so
we
we
can't
expect.
We
don't
have
the
information
about
the
signature
at
the
beginning.
Unless
we
put
it
into
the
one
pass
signature,
but
it
will
be
a
big
change
on
the
protocol
level,
and
this
is
as
much
as
we're
doing
right
now
with
EDSA.
G
Plus
deleting
propens
the
public
key,
but
that
is
still
fine
in
our
opinion,
because
it
just
ensures
that,
like
the
the
that
will
still
be
there
just
after
the
hash
and
yeah
next
slide,
and
basically
these
are
the
differences.
G
The
fact
that
we
want
to
in
the
future
bind
the
hash
algorithm
to
the
embedded
hash
algorithm
into
the
post,
Quantum
algorithm,
so
basically
say
you
cannot
use
sha
2
to
then
create
a
signature.
That
is
the
lithium
that
uses
internally
as
much
as
the
sold
size.
G
Slide,
yeah,
and
also
this
is
a
big
problem
we
have
nowadays,
especially
for
my
messages.
Clients
tend
to
parse
just
the
first
signature.
If
it
validates
good,
if
it
doesn't
well,
it's
not
validated,
and
if
we
want
to
put
multiple
signatures,
we
need
to
ensure
that
there
is
compatibility
for
this
and
also
in
open
pgp
messages.
So
in
the
embedded
signatures
we
need
additional
testing
in
internal
purposely
Suite.
That
is
not
done
as
of
now,
but
this
is
an
action
item
we
have
on
our
side
next.
K
G
So
next
steps
we
would
like
to
wait
for
the
publication
of
the
Khyber
intellectual
property
from
nist
that
they
told
us
yesterday.
It
would
be
that
tomorrow,
so
sorry
by
this
month,
so
I
I
will
very
warmly
looking
for
that.
We
also
would
like
to
publish
the
draft
we
have
right
now.
We
wanted
to
do
it
by
now,
but
we
still
some
parts
are
missing
and
we
do
have
an
experimental
goal.
G
Implementation
at
proton
and
MTG
will
work
soon
on
to
open,
lead,
decrypt
and
rmp
implementation
and
also
improve
the
testing
Suite
to
include
that
missing
tests
next
slide.
So
in
the
last
minute,
I
would
ask
if
anyone
has
comments.
Questions
please
come
to
sorry.
G
These
are
the
questions
we
have
for
you
and
they
are
the
algorithm
selection,
if
you
like
it,
whether
you're,
okay,
with
binding
a
signature
size
to
the
hash
ID
that
were
discussed
and
whether
you
would
be
okay
with
also
the
further
change
of
the
hash
function
to
the
algorithm
ID.
Now
I,
don't
think
we
have
times
for
question,
but
we
are
having
a
meeting
in
next
slide
in
20
minutes,
so
at
mezzanine
12,
where
we
will
see
the
draft
for
real
and
we
will
discuss,
we
can
discuss
it
all
together
to
see.
G
G
E
E
A
A
This
won't
be.
This
won't
become
a
chartered
item
until
there's
an
interim
meeting
anyway.
So
so
you
won't
totally
miss
out
on
anything.
So,
okay,
thank
you
all.
Let's
try
and
get
this
crippery
first
thing
done
at
the
door,
and
then
we
can
move
on
to
these
topics.