►
From YouTube: IETF112-OPENPGP-20211110-1200
Description
OPENPGP meeting session at IETF112
2021/11/10 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
If
anybody's
willing
and
there's
a
really
good
time
to
volunteer
if
you're
willing,
we
only
need
actions
to
be
minuted.
We
don't
need
the
blow
by
below
details,
because
the
meeting
is
recorded,
of
course,
so
feel
free
to
jump
in
and
volunteer.
A
Thank
you,
jonathan
welcome,
so
the
link
to
the
etherpad
is
at
the
top.
If
that
works.
For
you
that's
great,
if
that
doesn't
work
for
you,
you
can
just
take
notes
and
email
them
to
us
later,
but
the
ether
pad
is
it
works
pretty
well,
I
think.
A
Fantastic,
thank
you.
So
again,
we
only
really
need
kind
of
decisions,
actions
that
kind
of
thing
minutes.
The
rest
is
fine.
C
I
can
keep
an
eye
on
the
jabber
I'll,
also
be
keeping
an
eye
on
jabber.
A
Okay,
so
I
think
with
that
we're
kind
of
ready
to
rock
and
roll
am
I
right,
dkg.
A
Okay,
great
so
welcome.
This
is
the
open
pgp
session,
not
in
madrid,
sadly,
but
hopefully
that'll
get
fixed
over
time.
We
have
a
notetaker.
Thank
you
again,
jonathan.
This
is
the
links
to
the
various
bits
and
pieces
about
the
working
groups
and
this
the
mailing
list
and
the
charter
etc,
and
the
etherpad
notes,
and
so
on
the
media
materials.
A
So
this
is
the
note.
Well.
So,
if
you've
been
in
other
itf
sessions,
you
may
have
seen
this
there's
a
whole
bunch
of
things.
A
good
itf
participant
will
pay
attention
to
including
ipr
rules
and
you
know
being
being
reasonable
with
one
another
and
being
behaving
well.
So
there's
a
whole
bunch
of
texts
around
that
that
you
probably
should
make
yourself
familiar
with
if
you're
involved
in
the
itf
study
degree.
A
But
again
you
should
have
seen
this
at
the
start
of
many
sessions
and
my
last
slide
is
our
agenda.
We're
in
the
we're
in
item
zero-
and
we
will
be
next
up
with
paul
voters.
A
Summaries
summarize
excuse
me
the
recent
changes
in
the
crypto
refresh
draft,
which
is
our
main
piece
of
charter,
our
sole
piece
of
charter
work.
Really,
then
daniel
will
talk
about
some
more
choices
that
we
have
to
make
still
and
what's
to
be,
have
to
be
done.
Daniel
another
daniel
daniels,
pkg
we'll
cover
another
best,
and
then
justice,
we'll
talk
about
in
drop
test.
Suites
just
to
describe
what's
happened
recently,
I
guess
for
those
who
maybe
you're
not
following
the
readiness
that
well
or
that
closely.
A
We
we
have
a
design
team
which
consists
of
the
chairs
and
a
bunch
of
open
pgp
or
people
who
implement
open
pgp,
and
we
have
about
three
or
four
different
implementations
represented
plus
the
editors
of
the
documents,
that's
paul
mainly
as
a
non-implementer,
and
actually
we've
been
meeting
weekly
in
the
last
couple
of
months,
making
pretty
good
progress
and
working
kind
of
very
productively
together,
I
think
everybody's
been
quite
open
and
collaborative,
and
now
that's
resulted
in
a
draft
that
we
just
admitted
a
couple
weeks
before
this
session.
A
The
design
team
is
an
ietf
design
team,
which
kind
of
means
it's
a
closed
group,
but
the
mailing
list
for
the
design
team.
The
archive
is
open,
so
everybody
can
read
the
messages
to
that
design
to
your
archive,
which
mostly
consists
of
meeting
notes
every
week
and
again,
I'd
like
to
thank
the
the
people.
Who've
been
involved
in
that
because
it's
it's
been
very
productive.
A
A
Okay,
if
not
we'll
start
to
move
on
to
paul,
then
so
one
other
note
is
that,
unfortunately,
I
have
to
apologize.
I
need
to
to
leave
after
about
an
hour,
so
I
might
make
to
the
end
agenda,
but
I
might
have
to
just
bail
a
bit
before
the
end.
Apologies
again,
it's
just
a
local
interrupt
like
can't
avoid
and
dkg
is
aware
of
that
and
willing
to
do
without
me
for
the
end,
which,
which
should
be
no
problem.
A
So
again,
apologies
in
advance
if
I
have
to
bail
just
few
minutes
before
the
the
end
of
the
session.
Okay.
So
with
that
we're
on
to
paul
so
paul,
I'm
stopping
sharing
slides.
If
you
want
to
share
your
audio
video
and
again
that
share
predominant,
slides
button
is
just
beside
the
join
cue
button
and
you
should
have
a
choice
to
pick
your
slides
to
share.
D
A
D
Okay,
so
stefan
mentioned
this
a
little
bit
already.
So
just
a
really
quick
history
of
what
happened.
We
opened
a
working
group
to
work
on
rfc,
4880
bis
that
work
continued
for
a
while
and
then
after
a
while
there
were
too
many
things
happening,
but
that
also
caused
that
nothing
was
happening
anymore
and
it
sort
of
stalled.
So
what
happened
to
us
next
slide
is
that
the
working
group
got
restarted.
D
So
one
of
the
things
was
that
that
stephen
farrell
was
added
as
a
working
group
chair-
and
I
was
added
as
a
document
author
in.
D
To
try
and
and
sort
of
add
more
neutrality
to
the
discussion
and
sort
of
try
to
to
stick
to
the
ietf
process
and
move
along
and
to
to
make
this
start
more
clean
is
what
we
did
was
we
took
the
items
off
that
was
already
in
the
base
document,
but
started
from
rfc
4880
from
scratch,
and
so
we
we
then
started
adding
chunks
of
you
know
what
we
thought
was
agreed
upon:
work
by
the
working
group
and
started
adding
that
into
the
crypto
refresh
document
and
that
stepped
onward
for
a
bit.
D
It
started
making
some
progress,
but
then
it
also
sort
of
slowly
became
bogged
down
in
discussion,
because
it's
very
it's
very
easy
to
to
end
up
in
in
endless
discussions
when
there's
lots
of
people
and
lots
of
opinions
and
lots
of
good
good
discussion
happening,
but
we
needed
more
of
a
basis
to
continue
so
next
slide
to
to
avoid
making
the
same
mistake
again.
D
What
we
did
was
the
additives
design
team
that
stephen
already
mentioned,
and
this
allowed
us
to
get
a
few
more
focused
discussion,
going
a
few
more
items,
ticked
off
and
more
items
from
the
best
document
merged
into
the
crypto,
refresh
it
stuck
to
weekly
meetings,
and
so
there's
a
bit
of
a
good
good
push
to
get
things
done
and
to
to
have
more
regular
face-to-face
time.
D
Get
good
decisions
made
that
especially
all
the
implementers
agreed
on
and
since
the
design
team
is
mostly
implementers
and
a
few
people
steering
the
process
that
gave
us
actually
a
much
better
basis
to
to
continue
to
work
and
then
to
pull
everything
in
so
that's
sort
of
where
we
are
we've.
We've
pulled
in
most
of
the
old
this
document.
We
added
some
new
things
along
the
way
as
well,
and
I
think
the
work
is
is
progressing
nicely.
D
But
just
to
to
to
reiterate
the
design,
team,
workflow
and
everything
that's
being
done
is
completely
open
and
transparent.
You
can
see
all
of
these
links
that
tells
it
tells
you
what
what
we're
doing
we're
using
git
and
we're
trying
to
make
a
good
good
git
commits
that
are
readable
per
issue
that
make
the
discussion
a
little
easier
to
follow.
We're
using
a
tracker
with
with
merge,
requests
or
prs.
D
We're
using
topic
ranges
to
to
get
these
these
chunks
of
new
text
into
the
document.
We're
having
discussions
on
on
the
on
the
tracker
there
and
everybody
is
welcome
to
to
to
join
that
process.
It
might
just
be
that
you
know
we,
we
upvote
or
downvote
some
of
that
work
in
a
design
team
to
either
be
postponed
for
later
or
we
might.
D
We
might
say
that
that's
for
now
out
of
scope
or
not
for
the
crypto
refresh
document,
but
for
more
suited
for
another
document
or
will
will
will
obviously
take
take
the
obvious
fixes
that
people
are
proposing
in
so
do
not
feel
excluded
as
a
working
group
everybody's
still
there.
The
output
of
this
work
will
also
be
the
input
to
the
working
group,
we're
just
trying
to
make
sure
that
we're
not
getting
stuck
again
with
with
you
know,
there's
a
sort
of
four
month.
D
Next
slide,
where
are
we
most
of
the
4880
bits
has
been
merged
into
the
crypto
refresher?
I
think
we're
not
actually
technically
further
than
we
were,
except
that
there
are
still
some
things
we
need
to
just
pull
in
some
some
last
minute
things
if
you're
curious.
Most
of
that
work
was
tracked
in
a
step-by-step
range
and
it
was
created
to
sort
of
logically
pull
the
data
out
of
the
old.
This
document
into
into
the
new
crypto
refresh
work
some
work.
D
So
that
is
something
that
that
we
expect
to
to
have
a
more
full
open,
php
working
group
discussion
about,
but
at
least
some
sort
of
the
menial
task,
the
little
clarifications
and
updates
and
rewrites
and
making
fancier
tables
to
make
it
more
readable.
All
of
those
things
we
can.
We
can
now
more
quickly
go
through.
D
Done
and
we're
continuing
to
move
this
process.
So
a
few
more
details
next
slide,
you
can
see
that
daniel
had
sent
out
an
email
earlier
with
some
of
this
data
in
it
already.
D
So
the
notable
work
done
between
the
last
two
versions
of
the
crypto
refresh
is
that
the
ad
packet
got
defined
and
slightly
updated,
and
it
was
actually
a
little
more
work
than
I
expected.
D
88
protection
of
secret
key
material
internet
recipient
subpacket,
sks
v5
for
aed,
the
archon
2
got
added
the
curves
to
the
fact.
1948
got
added
and
there
was
some
slight
fairly
long
discussion
actually
about
how
the
exact
format
should
be
encoded
and
what
the
best
ways
were,
especially
because
some
implementations
implemented
something
slightly
different
or
different
from
what
we
would
like
to
see.
Now
we
had
good
discussions
with
all
the
implementers
and
and
managed
to
move
that
forward.
That
was
actually
really
great.
D
D
Some
notable
work
not
done,
like
I
said,
mandatory
to
implement,
there's
going
to
be
a
presentation
after
this
about
this
v5
signatures.
We
have
an
a
fairly
active
discussion
on
what
to
do
there
in
issue.
45.
G
D
You're
interested
fife
keys
is
also
an
ongoing
issue.
I
think
we're
almost
there,
but
there's
still
some
some
some
things
in
the
pipeline
before
we're
fully
done.
So
you
can
see
that
on
the
on
the
merch
request
or
pr
7789
so
expect
that
to
sort
of
flow
into
the
document
next
week
or
the
week
after
next.
F
D
There
were
some
things
that
was
done
after
the
last
draft
was
published
because
we
have
been
meeting
every
week,
mostly
still
so,
some
more
clarifications.
Some
terminology
update
like
not
talk
about
nest,
curves,
because
who
knows
what
nist
curves
are
in
this
document
five
years
from
now
when
this
has
updated
their
guidance.
D
And
sort
of
that's
where
we
are
so
next
slide,
so
we
think
this
process
is
working.
I
think
we're
seeing
good
progress
and
we'd
like
to
continue
this
way,
but
if
anyone
has
any
advice
or
comments
or
suggestions
about
this,
this
process
of
the
design
team
and
please
let
us
know
so-
we
can
maybe
adapt
and
be
more
inclusive.
D
With
that,
I
think
this
sort
of
an
overview.
The
next
slide
is
the
end.
I
think-
or
this
is
the
last
slide,
yeah
okay.
So
any
questions
comments.
A
A
H
Yeah
I'll
try
great,
I
clicked
the
button.
I
don't
know
what
I
need
to
do
after
that.
H
A
H
Share
my
videos:
well,
there
we
go
hello.
Yes,
it's
a
bit
cut
off.
Is
that
the
case
for
you
as
well?
No.
H
For
me,
the
slides
are
a
bit
cut
off,
but
that's
fine,
I
I
know
what's
on
them,
okay,
so
yeah
this.
This
presentation
is
about
first
I'll
I'll,
give
a
bit
of
an
overview
of
the
cryptographic,
algorithms
that
were
in
rfc,
480
and
6637,
which
this
crypto
refresh
is
meant
to
replace
right
and
then
I'll
give
an
overview
of
the
the
sort
of
the
current
consensus,
more
or
less
of
the
design
team,
of
which
algorithms
should
be
mandatory
or
recommended
to
implement.
H
Some
of
it
is,
you
know,
still
more
tentative
than
other
things,
or
some
of
these
things
have
had
more
or
less
discussion,
but
I'll
I'll.
Try
to
make
that
clear.
Okay!
So
then,
as
for
the
cryptic
cryptographic
algorithms
in
rfc
480
before
you
all
fall
off
your
chairs,
at
least
you
know
for
the
people
that
are
not
familiar
with
rfc
480.
H
You
know
this
document
was
released
in
2007,
so
you
know
high
time
for
an
update,
but
anyway
rfc480
says
that
you
must
implement
dsa
for
signing.
You
must
implement
algamal
for
public
key
encryption.
You
must
implement
sha-1
for
hashing.
You
must
implement
triple
des
for
symmetric
encryption.
H
You
must
implement
the
cfp
mode
of
encryption
and
you
must
implement
the
modification
detection
code
or
mdc,
which
is
a
method
of
integrity,
protection
using
xiaowan
and
then
encrypt.
So
you
know
obviously
not
really
up
to
you
know
modern
standards
of
authenticated
encryption,
but
okay,
we'll
get
to
that
and
then
finally,
it
says
that
well
finally,
v4
keys,
which
are
the
latest
version
in
rfc4a0,
use
sha-1
for
fingerprints
as
well.
H
It
also
says
you
should
implement,
cast
5
and
zip
and
zip
is
also
the
default
in
the
sense
that
if
a
key
doesn't
specify
any
preferences,
then
the
implementation
can
assume
that
it
prefers
zip,
although
it's
not
mandatory
to
use
compression
but
obviously
given
the
compression
attacks
that
have
come
out
more
recently,
it's
not
ideal
and
then
finally,
the
strongest
method
of
string
to
key
or
password-based
key
derivation
is
salted
and
iterated
hashing,
for
which
you
can
use
any
of
the
hashes
in
the
standard,
including
xiaowan
or
sha
256.
H
But
again,
it's
obviously
those
hashing
algorithms
are
way
too
fast.
And
it's
you
know
not
not
a
very
strong
method
of
key
derivation,
then
to
look
on
the
bright
side
of
rfc480.
At
least
it
does
say
that
you
must
not
use
md5
when
signing,
although
you
may
still
verify
it.
According
to
this
document,
at
least
to
be
fair,
most
implementations
are
already
way
stricter
than
this.
H
They
already,
I
I
believe
all
implementations
already
reject
any
five
signatures
using
md5
and
some
implementations
also
reject
xiao1
signatures
and
also
just
to
go
back
for
a
second
to
the
previous
slide.
The
the
algorithms
that
are
used
in
in
practice
is
usually
either
rsa
or
ecc,
often
using
curve25509
already,
even
though
it's
not
in
any
released
standard.
H
Yet
and
of
course
all
the
implementations
are
already
using
aes,
so
I
it's
it's
not
quite
as
bad
as
this
slide
may
make
it
seem,
but
yeah
for
sure
an
update
was
needed.
Then
our
does
say
that
you
must
not
use
a
symmetric
algorithm.
H
That's
not
in
the
recipient's
recipient
keys,
algorithm
preferences,
so
you
know
the
key
can
say
that
it
prefers
aes
and
all
implementations
do.
I
believe,
however,
it
does
say
that
since
triple
des
is,
must
implement,
then
it's
sort
of
implicitly
in
the
preferences
and
you
can
always
use
it
and
then
finally,
it
says
that
you
should
not
implement
keys
of
less
than
1024
bits,
and
that
goes
for
dsa,
algomal
and
rsa.
H
H
You
must
implement
nist
curve
p256,
you
must
implement
shot
to
256
and
as128
and
as
a
bonus,
sha-1
must
not
be
used
when
using
ecc.
So
this
this
rfc
sort
of,
even
though
it's
about
ecc
it
kind
of,
does
or
did
update
the
the
mandatory
algorithms,
which
is
good,
and
then
it
also
says
that
you
should
implement
p521
and
you
should
implement
sha,
384
and
sha
512,
and
it
also
says
you
should
you
should
implement
as356.
H
Okay,
then
going
ahead
to
the
crypto
refresh,
and
this,
I
believe,
sort
of,
as
I
said,
represents
the
the
consensus
of
the
design
team.
But
you
know,
if
I
misrepresent
anything,
then
you
can.
You
know
call
me
out
afterwards,
so
what
we
would
like
to
say
in
the
crypto
refresh
is
that
you
must
implement
eddsa
for
signing
and
ecdh
both
using
curve2559,
and
you
should
implement
curve
448..
H
Then
the
the
specific
mode
of
aad
encryption
has
not
had
that
much
discussion
in
the
design
team,
but
I
think
it
would
make
sense
to
require
implementing
ocb
since
it's
a
cfrg
requirement.
Currently
in
the
draft
there
is
ocb
and
eax,
but
ex
is
not
a
cfrg
or
sorry
recommendation.
H
So
to
me
it
would
make
sense
to
require
ocb.
But
again
this
is
still
up
for
debate.
H
H
H
Then
there
are
also
some
deprecations
that
we
would
like
to
do
in
the
crypto
refresh.
This
again
has
has
not
had
as
much
debate
as
some
of
the
other
stuff,
but
this
is
basically
one
proposal,
so
that
would
be
to
say
that
implementations
must
not
generate
rsa
keys
of
less
than
2048
bits
must
not
encrypt
sign
or
verify
using
less
than
1024
bits.
H
Keys
rsa
keys
should
not
encrypt
sign
or
verify
using
less
than
2048
bit
rsa
keys
and
should
not
decrypt
using
less
than
1024
1024-bit,
rsa
keys
and
then
finally-
and
this
is
perhaps
most
controversial
to
say-
that
implementations
must
not
implement
the
sa
or
algamal
at
all,
meaning
not
generate
encrypt
sign,
verify
or
decrypt,
the
main
reason
being
so
there
have
been
so
there
has
been
one
paper
coming
out
about
vulnerabilities
in
algomal
stemming
from
you
know,
differences
across
different
implementations,
and
then
my
colleague,
lara
brussahini,
has
also
is
also
publishing.
H
Some
research
about
key
validation
issues
or
key
override
attacks,
using
both
dsa
and
ogamal,
and
basically
dsa
and
algamal
keys,
are
very
difficult
to
verify
and
basically
use
securely,
and
in
addition
to
that,
most
of
the
dsa
and
algamal
keys
out
there
are
1024-bit
keys,
so
most
of
them
are
essentially
insecure
anyway
or
should
not
be
considered
very
secure.
H
But
again
this
is
yeah
still
up
for
debate.
Okay,
then
part
two
of
the
applications
is.
We
would
like
to
say
that
you
must
not
use
md5,
sha1
and
ripemd
when
signing,
and
I
I
believe
there
there's
consensus
on
this
or
it's
it's
less.
H
You
know
controversial
and
you
must
not
use
md5,
sha1
or
ripemd
when
verifying
new
signatures,
and
you
should
not
use
them
when
verifying
old
signatures,
where
old
is
defined
as
predating
the
discovery
of
vulnerabilities
in
those
specific
algorithms,
if
you're
sure
that
the
signature
has
been
under
your
control
since
that
time,
basically,
and
then
we
would
like
to
say
that
implementations
must
not
encrypt
data
with
idea
triple
des
or
cast
5,
but
made
still
decrypt
data
and
must
not
use
a
simple
string
to
key
key
derivation,
meaning
the
unsalted
variant
and
should
not
use
salted
but
united
or
non-iterated
string
to
key
key
derivation.
H
Unless
the
implementation
knows
that
the
the
pass
phrase
is
basically
a
high
entropy
randomly
generated
string,
for
example.
H
Okay,
then,
what's
still
left,
at
least
in
in
terms
of
algorithm
choices
for
the
crypto
refresh.
Well,
one
discussion
that
still
needs
to
happen,
perhaps
in
the
working
group
at
least,
is
on
brain
pool
curves.
H
H
The
the
charter
of
this
working
group
does
explicitly
point
out
that
the
the
goal
of
the
working
group
is
to
add
curves
that
are
cfrg
recommendations,
so
that
might
exclude
the
brain
pool
curves.
But,
okay,
that's
still
up
for
this
question
and
then,
similarly
for
the
mandatory
to
implement
algorithms,
there
was
some
question
of
do
we
want
to
require
algorithms
such
that
a
minimal
implementation
is
fips
compliant
and
for
now
we've
sort
of
decided
not
to
because
we
well
there
is.
H
There
is
a
draft
out
from
nist
which
includes
curve25509
and
girl
for
freight,
so
hopefully
that
will
become
a
a
final
document
sooner
rather
than
later
and
then
finally,
there's
still
some
question
about,
should
as256
be
mandatory
to
implement
the
primary
argument
being
to
prepare
for
post
quantum
crypto
given
source
algorithm
and
halving
the
search
space.
H
That
being
said,
the
the
counter
argument
would
be
that
to
be
both
quantum
resistant.
We
would
need
to
do
a
lot
more
also.
You
know
at
post
quantum
public
key
encryption,
algorithms
etc,
which
brings
me
to
the
next
slide,
which
is
what's
next
after
this
crypto
refresh
meaning
if
we
were
to
recharge
the
the
rfc
aft,
the
working
group
after
this
rfc
has
been
released.
H
H
A
So
thanks,
I
I
just
as
you
know,
as
a
chair-like
thing,
we
really
are
keen
to
get
feedback
from
the
broader
working
group
about
these
design
team
ideas.
I
mean
we
can
kick
off
the
thread,
the
main
list,
but
that
was
a
really
good
chance
and
I'd
really
be
happy
to
get
feedback,
whether
it's
positive,
negative
or
whatever,
as
it
is,
and
again,
if
you
kind
of
agree
with
these
choices,
that's
good
feedback.
If
you
disagree
with
them,
that's
also
good
feedback,
so
please
do
join
the
queue
and
or
chatting
jabber.
A
C
A
And
again,
if
somebody
has
audio
issues,
you
can,
you
know,
feel
free
to
type
in
the
jabra
and
we
can
relay
if
need
be
so
queen
if
you're
having
audio
issues,
maybe
we'll
jump
over
to
jonathan
and
but
stay
in
the
queue
and
as
you
try
to
resolve
things,
jonathan.
B
So
you
mentioned
post
quantum:
do
you
figure
that
that
would
be
done
after
publishing
the
crypto
refresh
that
it
would
be
a
net
an
update
after
that,
or
are
you
going
to
be
holding
the
crypto
refresh
until
afternoon?
This
process
completes.
H
I
would
imagine
the
former
I
I
would
imagine
that
this
would
be
one
of
the
first
items
after
this
rfc.
I
I
don't
think
it's
I
I.
I
don't
think
it's
worth
it
to
hold
this
rfc,
because
yeah,
as
I
said,
there
are
already
many
updates
to
the
cryptographic
algorithms
in
this
crypto
refresh
that
are
long
overdue
in
my
personal
opinion,
so
I
I
think
it's
worth
it
to
get
that
out,
even
without
the.
H
Post
quantum
algorithms,
also,
given
that
the
nest
competition,
if
you
will,
is
still
not
completed
so
it
might
still
take
a
while
to
get
that
done.
A
G
Thank
you,
griffin,
ready
for
that.
I
just
admitted
myself.
I
uploaded
uploading
the
the
team
for
working
on
this.
I
think
the
work
has
been
done
really
nicely.
I
see
a
lot
of
good
stuff
over
there.
I
I
really
do
hope,
and
you
know
we.
We
have
some
some
some
some
options
so
that
you
know
people
who
who
want
to
use
fips
validated
modules
for
for
for
their
security
purposes,
to
be
able
to
get
you
know,
approved
or
allowed
in
many
places
outside
u.s
government
as
well.
G
I
know
in
europe
in
asia,
in
in
many
places,
but
for
sure
I
don't
know
exactly
how
it
has
been
used.
You
know
in
in
in
what
places,
but
I
expect
they've
been
used
everywhere
and
a
lot,
and
that
applies
to
pgp
software
as
well
for
the
ocb.
G
Personally,
I
like
it,
but
right
now
we
don't
have
a
plan
to
prove
it.
So
for
the
curves
we
we
we
want
to
prove
the
cubes
and
the
new
nsa
signatures
with
those
two
curves
from
the
cfrg,
and
we
thank
you
sebajee
for
for
doing
that,
making
faster,
curves
and
and
with
you
know,
more
properties
that
people
like.
So
I
expect
those
curves
and
signature
algorithms
will
be
approved
at
some
points
in
the
officially
in
the
future.
G
Right
now,
you
cannot
get
them
validated
yet
because
it's
not
officially
approved
yet
we're
waiting
for
a
you
know,
a
big
signature
on
it
and
you
know
it's
it's
it's
been
a
while.
So
I'm
I'm
on
behalf
of
this,
I'm
sorry
for
that.
I
I
think
it
needs
to
be
speeded
up
for
the
e.
G
I
I
don't
think
we
we're
going
to
prove
eax
either
we
we
haven't
talked
about
that
for
a
while,
because
we
right
now
we
expect
to
have
a
new
algorithms
or
of
a
few
for
the
lightweight
crypto,
and
some
of
them
might
be
just
good
at
general
purpose
use
as
well.
So
so
I
so
I
participation
and
wait
for
that.
G
H
Yeah
makes
sense
thanks
a
lot
for
your
comments.
Yeah,
so
gcm
is
not
currently
in
the
in
the
crypto
refresh.
I
I
suppose
that
could
still
be
a
topic
for
discussion.
If
people
feel
that
having
a
nist
approved,
authenticated
encryption
mode
is
valuable,
we
do
implement
it
in
openphp.js
and
google
pgp
as
an
experimental
module
a
remote,
even
though,
of
course
gcm
is
not
experimental,
but
in
the
context
of
open
bgp
it
is,
but
but
yeah.
G
We
we
we
could.
If
the
team
agreed
to
you
know
we
we
could
have
ocp
or
something
else.
You
know
another
good
crypto
to
be
in
the
recommended
should
implement
column.
A
Great
thanks
quinn
and
again,
if
you're,
if
you
can
dequeue
yourself
after
when
you're
done
that
that
helps
so
it
depends.
Thank
you,
stefan.
Thank
you.
A
lot
yeah.
I
Thank
you.
I
just
wanted
to
hop
in
on
the
post
quantum
crypto
topic,
because
I
had
come
up
a
little
bit
earlier,
so
we
are
currently
working
to
charter
a
semi-dedicated
working
group
for
the
word.
Maintenance
has
been
used-
it's
not
a
great
word,
but
for
like
sort
of
adding
the
ability
to
use
post
quantum
crypto
to
algorithms
and
protocols
or
protocols,
mostly
that
don't
currently
support
it
and
do
not
have
a
better
home.
I
Obviously,
if
this
working
group
is
going
to
stay
open,
it
would
be
a
fine
place
to
add
post
quantum
crypto
to
pgp,
but
this
other
working
group
that
we're
working
on
will
be
a
body
of
expertise
in
that
general
topic
and
we
would
want
to
be
able
to
coordinate
with
them
when
we
do
start
picking
up
the
postcard
work.
But
I
agree
with
you
that
we
should
not
try
to
do
it
in
the
current
document
that
we're
working
on
thanks.
H
Makes
sense
yeah
we
should
collaborate
on
that.
Obviously,.
D
Hi
paul
speaking
just
as
an
individual,
I
just
want
to
remind
people
as
well
that
whatever
we
decide
for
the
mandatory
to
implement,
even
though
it's
a
base
in
the
document
that
we're
producing,
we
should
also
in
parallel-
you
know
revise
these
anyway,
and
so
maybe
six
months
or
12
months
after
we
after
this
rfc
is
published,
we
will
do
an
update
to
the
mandatory
to
implement
section.
I
have
done
those
kind
of
documents
for
for
dns
for
ike
for
ipsec.
H
Yeah,
I
believe
dkg
has
also
been
working
on
updating
those
tables,
also
indeed,
so
that
we
can
update
them
in
in
the
iana
tables,
without
necessarily
releasing
a
new
document
right.
Correct
me.
If
I'm
wrong.
C
Yeah,
that's
correct,
I
mean
part
of
the.
The
updates
that
are
in
crypto
refresh
is
changing
the
rules
for
how
we
add
items
to
these
tables
to
make
it
to
loosen
them
up
a
little
bit.
It
had
been
relatively
strict
before
and
I
think
we're
moving
in
the
direction
of
it
being
looser.
A
Okay,
so
I
don't
see
anybody
else
in
the
queue,
I
guess
they're,
probably
a
good
action
to
put
on
the
chairs
and
design
team
members.
I
guess
send
a
summary
about
this
mti
topic
to
the
working
group
list,
because
I
do
expect
to
be
more
discussion
needed
just
to
check
everybody's
ideas
about
this.
A
C
C
That
is
the
users
of
openbgb,
and
it
is
deliberately
agnostic
to
some
of
the
wire
format
details.
It's
called
the
stateless
open,
pgp
interface,
so
we
abbreviate
that
to
sap
and
it's
stateless,
meaning
that
there's
no
weird
side
effects
right,
that
everything
that
you
specify
is
going
to
be
directly
there.
It's
on.
C
So
why
am
I
talking
about
this
here?
Given
that
it's
not
in
charter?
I'm
mentioning
it
because
it
has
proven
to
be
useful
for
interoperability
testing
and
that's
something
that
we
care
about
a
lot
as
we're
building
this
crypto
refresh
track.
We
want
to
make
sure
that
we
actually
have
functional
implementations.
C
I
think
it
also
is
helpful
in
clarifying
the
concepts
that
users
of
openpgp
are
likely
to
want
to
do,
and
it
tries
to
be
very
simple
in
in
describing
behaviors
that
that
users
will
find
useful,
and
hopefully
it
will
encourage
best
practices
and
implementations
as
well
to
ensure
that
that
things
behave.
The
way
that
we
sort
of
expect
them
to
this
could
help
with
algorithm
deprecation,
as
well
as
support
for
new
algorithms.
C
So
again,
it's
stateless,
because
we
really
want
to
make
sure
that
there's
no
strange
side
effects
that
if
you
run
it
once
you
get
the
sort
of
the
the
same
thing.
This
does
not
mean
it's
the
right
way
to
use
it,
that
you
should
always
use
something
like
sop
in
an
implementation,
but
it
is
definitely
useful
for
exercising
implementations
to
make
sure
that
they
do
what
people
expect.
We
also
think
that
the
reason
we
chose
a
command
line,
sorry
daniel.
C
I
think
I'm
getting
echo
from
your
audio
thanks,
which
is
command
line
because
it's
sort
of
common
dominator.
We
have
lots
of
different
implementations
they're
in
different
languages
and
would
be
nice
to
make
sure
that
that
we
can
test
them
with
each
other
without
having
one
particular
language,
be
the
framework
that
that
everybody
has
to
sort
of
push
themselves
into
pretty
much.
Everybody
can
build
a
command
line
tool.
C
So
at
the
moment
the
softcraft
is
focused
on
data
management.
There
is
a
secret
key
and
certificate
generation
utility
in
it.
The
interface
describes
encrypting
again
very,
very
minimal
controls.
We're
not
it's
not
the
kind
of
thing
you
could
say.
Do
it
with
this
particular
algorithm?
We
just
want
to
say:
do
it
and
then
see
what
it
was
generated
by
default
and
then
can
other?
Can
other
implementations
read
the
encrypted?
C
We
also
do
signature
identification,
so
it
goes
on
data
management.
It
doesn't
get
into
any
of
the
funky
certificate
off
at
a
moment.
So
here's
some
examples
of
how
you
would
use
it
on
the
command
line.
Ben
sorry.
I
To
jump
in
speaking,
your
audio
is
getting
a
little
choppy.
So
maybe,
if
you
turn
off
your
video,
your
laptop
will
have
more
cpu
for
the
audio
cycle.
C
Thank
you.
I
turned
off
my
video.
Hopefully
this
will
be
better
appreciate
the
heads
up
yeah.
So
this
is
an
example
of
how
the
how
you
might
use
sop
there's
a
key
generation.
You
can
extract
the
public
key,
the
the
certificate
from
the
secret
key.
You
can
sign,
verify
encrypt,
etc.
C
C
We
care,
because
we
don't
want
to
expose
the
algorithm
specific
details,
the
version
specific
details,
but
we
do
want
to
see
whether
you
can
consume
objects
that
are
created
like
this.
So
that
means
that
the
interop
test
suite
can
take
a
wire
format,
object
and
say:
hey.
Who
can
read
this
thing
or
who
can
encrypt
to
this
key
and
and
we've
found
that's
pretty
useful
in
identifying
incompatibilities
actually
with
the
existing
rfc
4880,
and
hopefully
it
will
be
more
useful
going
forward
with
the
stuff
that's
in
the
crypto
refresh
as
well.
C
Users
will
talk
about
the
test
a
little
bit
later,
a
couple
of
things
about
what
might
change
in
stop
in
the
future.
One
thing
that's
missing
is
inline
signatures.
Current
sop
draft
really
expects
to
work
with
detached
signatures,
so
you
have
the
data
that's
signed
and
you
have
a
separate
signature.
C
This
is
much
cleaner
to
reason
about,
but
in
fact
we
do
have
an
open,
pgp,
bundled
signature
and
message
objects,
and
we
have
a
history
of
some
kind
of
failure
with
that.
We
need
to
figure
out
how
to
represent
that
in
soft
and
we
haven't
done
it
yet.
It's
issue
25,
the
links
are
in
the
slides,
there'll,
be
a
link
at
the
end
as
well.
If
you
want
to
see
that
one
thing
that's
been
really
interesting
over
the
last
year
is
we
have
three
different
language,
specific
frameworks.
C
So,
if
you're
writing
an
open,
pgp
implementation
in
java
in
rust
or
in
python,
you
can
pull
in
these
language
specific
frameworks
and
they'll
they'll
auto
generate
the
command
line
interface
for
you
in
general.
The
language
specific
frameworks
are
kind
of
idiomatic
for
the
specific
language
which
I
think
is
good.
C
Other
thing
that
has
been
sort
of
pending
for
a
while,
but
nobody's
bothered
to
specify
it
our
certificate
management
functions.
So
again,
we've
really
only
been
handling
data
management,
thus
far,
but
it
might
be
nice
to
be
able
to
merge
certificates
together.
You
know,
certificates
have
multiple
multiple
certifications
in
them,
you'd
like
to
merge
them
together
and
get
the
union
of
those
verifications.
C
Validation
of
user
ids
people
call
the
web
of
trust,
maintaining
a
certificate.
So
if
you
have
a
secret
key,
do
you
need
to
do
any
updates
to
it
like
what?
If
it's,
advertising
support
for
md5
it'd
be
nice
to
be
able
to
say?
No,
let's
remove
that
advertisement
issuing
replications
certifying
other
user
ids
that
sort
of
thing
adding
sub
keys.
Maybe
these
are
things
that
that
might
be
useful
to
add,
but
we
don't
need
to
get
into
the
details
here.
Hopefully
folks
will
consider
doing
that
on
the
issue.
Tracker.
C
The
recent
update
that
was
pushed
out
a
couple
of
weeks
ago
has
very
minor
changes
a
little
bit
of
tweaking
letting
you
use
multiple
secret
keys
where
you
used
to
only
be
able
to
use
one
and
a
bit
more
expanded
output
for
the
version
function,
which
will
help
report
better
detail
in
the
test
suite.
C
So
that's
a
rough
overview
of
what
the
what
sap
is,
what
the
stateless
openpgp
interface
is.
I
hope
folks
will
take
a
look
at
that
if
you're
an
implementer
and
you
haven't,
got
a
sop
implementation
or
no
one's
written
one
for
you,
I
encourage
you
to
take
a
look
the
more
that
you
have
a
sap
implementation
that
you
feel
comfortable
with
the
better
represented
you'll,
be
in
the
interrupt
testing.
C
F
So
I
also
want
to
mention
that
the
idea
of
having
you
know
language,
specific
apis
kind
of
standardized
by
sub
is
also
useful
for
application
developers.
So
if
you
are
looking
into
using
pgp
in
some
kind
of
application
or
server
side
application,
maybe
sub
is
a
good
fit
for
you.
C
A
Great
directors,
no
one
else
in
the
queue
again,
if
you
want
to
join
the
queue
now,
that's
fine
if
you
want
to
join
at
the
end
at
the
end,
that's
also
fine.
So
if
there's.
B
F
F
So
if
you
missed
the
last
presentation,
there
are
around
90
tests
in
the
test
suite
currently
and
all
in
all.
We
are
feeding
around
800
test
vectors
to
every
implementation.
A
We
don't
actually
see
you
just,
but
we
hear
you
fine
and
there's
some
non
moving
video
of
a
an
avatar
icon.
That's.
A
F
Yeah,
so
I'm
happy
to
report
that
we
found
at
least
92
bucks
in
10
different
implementations,
which
I'm
very
very
happy
about,
and
I
think
it
also
improved
implementations
a
lot
and
our
understanding
of
the
p2p
ecosystem
in
general.
F
F
F
Many
tests
there
are
two
kinds
of
tests,
one
where
the
test
suite
creates
test
artifacts
and
feeds
them
to
the
implementations
and
the
other
one
where
we
do
maybe
more
traditional
interop
testing,
where
we,
for
example,
ask
some
implementation
to
encrypt
the
file,
and
then
we
try
to
decrypt
it
with
every
other
implementation
and.
F
F
F
Most
tests
start
with
the
base
case
to
establish
that
the
kind
of
setting
is
sane
and
works
as
we
expect
and
then
most
of
the
time.
If
we
have
a
consumer
test,
we
start
with
a
well-formed
variant
or
a
form
variant,
maybe
some
kind
of
weird
or
slightly
out
of
spec
variant.
F
And
then,
if
you
look
at
the
columns,
you
see
the
consumers
and
to
the
right.
There
is
an
expectation,
so
some
of
the
test,
vectors
have
an
expectation
or
mostly
my
expectation
and
or
a
comment,
and
the
the
colors
in
the
boxes
indicate
whether
the
implementation's
outcome
matches
the
expectations
so
green
background
or
earmark
in
the
top
left
corner
means
the
implementation
matches.
The
expectation
and
the
red
background
or
an
earmark
in
the
top
right
corner
means
it
did
not.
F
F
It's
a
bit
tricky
because
most
artifacts
in
the
case
of
consumer
tests
are
created
by
sequoia
and
if
sequoia
does
not
implement
the
feature.
Yet
we
can't
use
it
to
generate
an
artifact,
but
I'm
not
above
simply
using
files
to
to
fill
in
the
gaps
where
sequoia
does
not
or
does
not
yet
implement
some
feature.
F
F
Maybe
people
can
still
contribute
at
least
ideas
or
specific
guidance
on
what
would
be
useful
to
test
and
then
once
the
tests
are
written
and
executed,
reviewing
the
results
and
providing
feedback.
That
is
also
a
lot
of
work,
and
you
could
help
with
that
too,
and
now,
if
you
want
to
participate
in
this
experiment
as
an
implementer,
that
would
be
also
great,
and
there
are
two
problems.
F
F
That
is
a
bit
of
a
problem
right
now
for
the
test
suite,
because
unfortunately,
I'm
the
only
one
who
who
runs
the
test
suite-
and
I
don't
have
a
good
trigger
mechanism
on
when
to
run
the
test
suit
again
in
general.
F
F
I
implemented
sub
interfaces
for
gpgme
and
rnp
and
sequoia,
and
I'm
kind
of
maintaining
the
sub
interface
for
gpgme
and
rnp,
and
you
know
that
could
lead
to
me
misrepresenting
your
implementation
and,
if
I
do
please
talk
to
me
or
you
know,
even
better
write
your
own
implementation
and,
finally,
I
encode
lots
of
my
own
expectations
into
the
test
suite
and
I
maybe
wrong
about
stuff.
So
if
you
disagree
with
some
test
results
or
with
some
expectations,
please
also
talk
to
me
on
the
right.
F
And
in
general
this
has
been
a
bit
of
a
one-man
show,
which
is
a
bit
unfortunate.
F
I
don't
mind
the
work,
but
it
would
be
great
to
get
more
people
involved,
and
maybe
you
can
have
a
bit
of
a
chat
on
what
the
barriers
are
to
to
joining
and
how
we
can
improve
that,
and
with
that
I'd
like
to
open
up
four
questions.
C
So
I
just
want
to
point
out
that
the
work
uses
done
here
has
really
been
super
valuable
to
the
community.
G
C
It
actually
is
as
easy
as
it
as
it
shows
to
run
the
test
suite
it's
a
pretty
straightforward
process,
so
I
want
to
say
a
big
thanks
to
eustis
for
doing
this.
This
is
this
is
really
critical
for
us
ben
go
ahead.
I
And
basically
say
the
same
thing,
not
a
question,
but
a
huge
thanks
for
getting
the
test
suite
together
and
maintaining
it.
I
know
some
of
the
other
itf
work
we've
done
recently
with
like
tls
and
quick,
have
had
a
good
interop
test
matrix
with
many
different
implementations
and
that
really
improved
the
quality
of
the
spec
to
have
so
many
different
implementations
that
were
following
with
a
spec
and
pointing
out
bugs
or
inconsistencies
or
incomplete
parts
of
the
spec.
So
it's
really
really
useful
to
have
this
sort
of
automated
test
suite
available.
A
Okay,
thanks
jesus
and
again
people,
you
know
you
have
links
there.
Please
keep
an
eye
on
them
and
and
download
it
twice.
A
A
Yes,
I
I
am
vanishing
momentarily
I've
got
about
two
minutes.
So
sorry,
this
is
our
agenda.
We're
at
the
aob
part
now
so.
A
C
And
I'll
be
here
after
stephen
steps
off
if
if
there
is
aob
going
on,
but
if
there
is
no
other
aob,
I'm
happy
to
give
y'all
a
chunk
of
the
meeting
time
back.
C
The
weekly
the
weekly
meetings
of
the
design
team
have
been
ongoing.
We
spent
about
an
hour
every
week
together
and
probably
a
significant
amount
of
time
more
than
that
between
the
meetings
tweaking
at
the
specs.
So
I
think
that
the
design
team
folks
are
might
be
might
be
meeting
out
then
go
ahead.
I
Yeah,
sorry,
I
skipped
training
queue
because
it
was
just
me,
but
I
want
to
thank
again
the
design
team
for
all
the
great
work
they're
doing
do
you
have
a
sense
for
if
we
can
try
and
extrapolate
from
the
current
rate
of
progress
in
the
design
team
for
looking
forward?
C
C
I
Okay,
thanks,
that's
pretty
reassuring
to
hear
so
I
look
forward
to
it
and
I
think
jonathan
was
maybe
in
the
queue.
C
Okay,
I
see
steven
has
stepped
away.
C
C
So
I
see
steven
has
stepped
away.
I
don't
know
whether
y'all
can
hear
me
yeah
yeah.
We
can
hear
you
daniel
okay
yeah,
so
it
looks
like
stephen
has
stepped
away,
but
if
we
don't
have
more
folks
in
the
queue
robin,
I
see,
you
have
your
vote.
Your
mic
on.
B
C
C
All
right:
well,
I'm
going
to
give
folks
the
rest
of
the
queue
back
the
rest
of
the
time
back
here.
If
there's
nobody
else
who
wants
to
talk,
we
will
continue
with
the
design
team
meetings
and
we'll
continue
posting
notes
and
thanks
for
everybody,
for
your
input.