►
From YouTube: OPENPGP WG Interim Meeting, 2021-02-26
Description
OPENPGP WG Interim Meeting, 2021-02-26
A
C
B
I've
just
hit
the
record
button
people.
So
if
you
have
a
problem
with
being
recorded,
that's
you
should
have
read
the
note
well
and
and
not
have
a
problem,
but
I
am
recording
now
also
for
people
helping
with
minutes.
That
means
we
can
go
back
to
the
recording,
if
need
be,
so
we
are
being
recorded.
Pardon
me
for
the
introduction.
A
Re-Paste
the
the
either
pad
in
the
because
I've
heard
a
couple
of
doo
doo
sounds
so
maybe
someone
can
replace
the
ether
pad
regularly
in
the
chat
when
that,
when
that
happens,
that'd
be
great.
Thank
you,
so
yeah,
and
once
we
talked
about
how
the
devrap
dress
has
been
developed,
we
will
talk
about
what
the
next
steps
are
for
it
and
then.
A
Finally,
I
want
to
just
make
sure
folks
are
thinking
about
the
meeting
at
ietf
110
and,
if
possible,
to
try
to
think
about
when
the
next
interim
will
be
we're
not
going
to
make
any
specific
decisions
here,
but
we
want
to
try
to
get
a
sense
of
of
what
how
people
think
about
where
we're
going.
Stephen,
you
want
to
take
the
next
slide.
A
Okay,
so
just
a
catch
up
for
folks,
the
the
crypto
refresh
document
is
was
reset
to
rfc
4880.
That
is,
we
had
this
48
abyss.
The
working
group
got
unchartered
like
and
it's
been
sort
of
running
without
a
working
group,
but
with
an
ietf
name.
So
we
reset
to
rfc
4880
and
we're
trying
to
import
the
changes
from
4080
bis
dash
10,
which
was
the
last
draft
on
that
change
on
that
on
that
chain.
A
So
our
goal
here
is
to
try
to
make
to
try
to
make
sure
that
we
import
and
review
all
the
pieces
that
differ
from
4880,
so
draft
zero.
Zero
was
4880
with
some
minor
formatting
changes.
Draft
zero
one
was
fixing
the
open
errata,
the
ones
that
were
confirmed.
There
are
still
a
bunch
of
errata
that
are
mentioned
and
sort
of
reserved
for
document
update
that
people
might
want
to
take
a
look
through,
but
we
incorporated
those
incorporated
the
camellia,
ciphers
and
cleaned
up
a
bit
of
the
terminology
that
technology
cleanup
included.
B
A
A
There
are
only
two
registries
that
are
rfc
required,
as
opposed
to
specification
required,
meaning
that
something
needs
to
get
through
the
ietf
standardization
process
and
those
two
are
packet
version
and-
and
I
believe
packet
type
itself,
but
all
the
rest
required
are
just
specification
required,
which
means,
if
you
write
a
specification,
you
don't
even
have
to
necessarily
publish
it
at
the
ietf.
You
just
have
to
make
sure
it's
in
a
stable
spot,
make
sure
there's
some
implementations
and
talk
to
ayanna
about
it.
A
Full
effect
until
the
draft
gets
published
as
an
rfc
there's
some
deprecation
of
older
cryptographic,
mechanisms
that
we
know
are
broken,
there's
the
inclusion
of
sha-3
and
finally,
there's
the
inclusion
of
curve
255.19,
which
is,
I
guess,
people
are
calling
them.
The
the
the
cfrg
curves,
but
specifically
so
far,
is
only
included
and
mentioned
for
elliptic
curve,
diffie
helmet.
That
is
the
encryption
variant
and
it
is
not
currently
in
the
draft
for
signing.
A
So
we've
had
a
bunch
of
folks
do
some
review
on
the
list.
There's
been
some
nitpicking
and
some
specific
non-nitpicky
details
which
I'm
grateful
for.
I
know
it
hasn't
been
that
long.
It's
only
been
a
couple
days
four
days,
I
guess,
but
I
do
hope
that
other
folks
would
be
willing
to
will
review
this
and
look
at
the
changes
here.
A
If
you
are
unclear
about
where
to
find
that
stuff
next
slide
yeah
there
we
go
so
the
the
document
is
currently
being
worked
on
in
markdown.
If
you
are
comfortable
in
markdown
with
the
text
editor,
you
can
get
to
the
source
of
it.
We've
already
had
a
couple
people
post
some
diffs
to
the
mailing
list,
which
is
great.
Those
are
things
that
will
make
it
easier
to
think
about
applying
changes.
C
A
A
A
There
is
also
rfc488bis.md,
which
is
a
markdown
variant
of
the
last
version
of
draft
ietf
openpgp
4880
bis
dash
10..
The
goal
right
now
is
that
we're
trying
to
bring
the
crypto
refresh
document
up
to
parity
with
that,
and
so
that's
present
in
the
repo
as
a
historical
reminder
and
to
something
that
we
can
compare
against
and
then.
Finally,
the
document
that
we
are
working
on
is
just
named
crypto
dash
refresh.md
in
there.
A
A
What
changes
might
come
next?
I've
been
basically
doing
comparisons
between
rfc,
4880bis.md
and
cryptorefresh.md.
So
I
welcome
anyone
else
to
take
a
look
at
those
and
try
to
look
at
what
the
remaining
changes
are
hope.
This
makes
sense.
If
anybody
has
any
questions
again,
I
hope
you
feel
free
to
shout
them
out.
You
can
also
just
put
a
plus
q
in
the
chat.
A
C
A
B
H
A
A
A
All
right
so
so
I
was
looking
through
the
differences
between
4888bis.md
and
cryptorefresh.md
and
trying
to
identify
topic
level
views
of
what
of
of
what
differences
are.
So
this
slide
shows
us
a
set
of
things,
and
this
is
a
rough
characterization.
This
is
a
characterization
that
I've
done.
It
is
not
necessarily
a
guarantee.
A
Despite
some
of
those
things
being
things
that
I
care
about,
I
have
to
acknowledge
that
if
our
goal
is
completing
the
charter,
we
might
want
to
focus
on
the
columns
further
towards
the
left,
and
we
can
worry
about
the
columns
further
on
the
right
later.
Note
also
that
the
registration
that
the
the
way
that
the
specification,
the
registries
have
changed
so
that
their
specification
required.
A
Yep
that
makes
sense
these.
These
are
not
hard
and
fast
categorizations.
Here.
This
is
my
attempt
to
do
that,
and
I
I
can
see
your
argument
there.
If
you're
concerned
you're,
I
think
what
you're
saying
is.
We
we
see
some
known
vulnerabilities
in
the
current
open,
pgp,
workflows,
cryptographic
vulnerabilities
that
could
be
fixed
by
the
intended
recipients.
Think
fingerprint
sub-packet
right
right
yeah,
so
we
may
want
to.
We
may
want
to
try
to
promote
that
to
the
crypto
related
column,
yeah.
I
A
G
Okay,
should
we
just
use
the
race
and
think
so
so
my
command
is
just
about
the
brainpower
thing
that
it's
here
on
the
agenda,
the
brain
pool
curves
are
actually
actually
in
6637,
and
I
don't
see
that
there's
anything
which
is
relevant
for
for
crypto
revenge
refresh
because
we
already
have
implemented
it
years
ago,
along
with
the
list
curves.
So
let's
just
find
standard
thing.
A
G
Okay,
so
the
thing
is
just
that
637
mentioned
that
you
can
use
any
oid
for
that.
So
what
we
added
is
the
oit
of
these,
which
are
used
for
paint
pool
but
advantage
of
brain
pool
is
that
there
is
only
one
ready
for
these
curves.
So
there's
no,
not
the
problem
we
used
to
have
with
rsa
things
and
so
on
many
varieties.
G
A
G
A
Yep,
that
makes
sense,
so
I
don't
know
that
I
want
to
do
a
full
readout
of
the
slide
here,
just
because
it's
a
lot
of
text,
I'm
hoping
that
everyone
can
see
the
slide.
If
you
can't
see
the
slides,
please
speak
up,
but
I
appreciate
the
comments
from
daniel
and
werner
about
maybe
thinking
about
re-categorizing
a
couple
of
the
things
that
are
placed
on
the
slide.
Does
anybody
else
have
thoughts
about
pieces
here?
Have
I
identified?
Have
I
missed
something
that
was
in
4080
abyss?
A
Sure
that
we
are
in
rough
agreement
on
the
pieces
that
are
necessary
to
try
to
bring
us
towards
our
towards
parity,
and
then
I'd
like
to
stay
on
this
slide
for
a
little
bit.
If
people
don't
have
other
issues
with
what's
on
here
and
talk
a
little
bit
about
how
we
think
what
steps
we
think
we
should
do
like
in
what
order
to
head
towards
something
that
we
can
get
published.
A
A
K
Yeah,
I'm
just
saying
that
I
would
like
to
have
all
the
issues
here
addressed
in
an
update
and
not
to
go
for
another
rfc.
It's
a
huge
pain
in
the
ass
honestly
to
update
certifications
and
so
on
for
a
new
crypt
standard.
So
any
changes
we
are
making
now
they
should
be
valid
for
the
next
10
years
or
something
like
that
and
not
require
a
new
update
immediately
afterwards.
A
C
C
There
are
certainly
items
on
this
list,
for
example
some
of
the
notation
stuff
that
personally
I
put
in
but
other
things
on
here
as
well-
that
I
think
are
fairly
non-contentious
and
should
be
easily
added
in.
We
might
find
that
there
are
some
contentious
issues
here,
at
which
point
then
we
might
want
to
reconsider
whether
or
not
to
what
to
do
about
those
contentious
issues,
but
for
the
non-contentious
issues.
I
think
we
should
include
them
even
if
they're
not
necessarily
directly
crypto
related.
A
B
You
know,
if
we
succeed
in
that
meeting,
that
charter,
we
can
then
go
beyond
it,
but-
and
secondly,
I
think
this
working
group
this
this-
this
is
not
the
first
time
we've
tried
this
and
one
of
the
reasons
I
think
that
that
is
foundered.
Last
time
was
kind
of
trying
to
get
too
much
done
and
kind
of
not
focusing
sufficiently
on
what
needs
to
be
done.
B
A
Yeah,
I
think
that
the
the
point
that
derek
made
might
be
a
pretty
salient
one
for
us
right,
which
is
the
about
the
contentiousness
of
a
feature.
If
something
is
uncontentious
like
there
are
no
objections
from
people
in
the
working
group
and
it
has
multiple
implementations
and
it
doesn't
seem
to
introduce
new
cryptographic
wrinkles
that
we
haven't
seen
an
evaluation
for
maybe
that
is
something
that
we
can
just
go
ahead
and
include,
but
again,
if
it's
anything
that
causes
contention
or
delay,
I
think
that
would
be
a
real
mistake.
A
A
J
Yeah
this
has
been.
I
just
wanted
to
jump
in
and
note
that
in
the
isg
as
a
whole,
we
recently
had
a
case
or
two
where
there
was
a
document
that
came
to
us
from
a
working
group,
and
it
was
sort
of
seen
as
exceeding
the
charter
of
the
working
group
and
that
caused
some
problems,
and
so
I
think
that
the
isg
as
a
whole
might
be
particularly
sensitive
to
staying
within
the
charter
for
the
next
several
months.
J
H
No
worry
it's
not
the
best
ui
yeah.
I
just
wanted
to
also
clarify
that
as
long
as
we're
still
in
a
draft
we
can,
we
can
think
we
have
consensus
on
all
the
previous
versions
that
we've
done.
But
then,
if
someone
joins
and
says,
I
actually
disagree
with
that,
like
the
consensus
is
only
stuck
forever
once
we
publish
the
rfc.
H
So
I
also
would
like
to
make
sure
that
you
know
once
we
have
like
the
largest
chunk
of
crypto
related
things
done,
that
we
that
we
try
to
publish
as
an
rfc
and
bring
in
all
the
other
things
also
as
quickly
as
possible.
But
in
a
separate
document
like
if
it's
small
things
that
fit
in
properly,
we
can
try
and
do
it.
But
as
soon
as
someone
objects,
I
think
we
should
move
it
out
again
and-
and
I
really
don't
want
this
draft
to
live
forever.
B
A
K
A
B
A
A
This
is
a
harder
review
to
do
because
you're
not
just
looking
at
a
diff
and
identifying
things,
but
those
are
the
two,
the
idea
of
including
curve
48,
which
is
you
know,
another
modern
curve
which
is
stronger
than
curve
255.19
and
argon
2.
As
a
as
a
you
know,
the
the
winner
of
the
password
hash
competition
figuring
out
how
to
do
those
things
in
the
context
of
open
pgp
seem
to
me,
like
those
are
things
that
would
be
relevant
for
bringing
open,
pgp's
cryptography
into
the
modern
world,
and
those
were
not.
A
A
A
B
G
Okay,
I
got
to,
I
don't
think
it
makes
much
sense
for
all
pgp
to
extensive
synthetic
encryption
stuff
here
in
particular
for
using
passphrases
or
manual
type
passphrases
and
using
icon2.
The
problem
I
see
with
this
is
that
all
implementations-
it
only
makes
sense
if
it
would
be
mandatory
to
implement
and
for
interoperability
reasons,
and
I
doubt
that
we
can
do
and
will
do
this
because
of
subprops
of
item
two
in
unattended
usage.
B
A
G
G
Yeah,
that's
that.
But
the
other
thing
is
some
metric
encryption
and
if
you
start
to
use
symmetric
encryption
wide
scale,
you
need
to
have
some
way
to
manage
the
metric
keys
and
you
are
surely
not
using
a
kdf
function
to
improve
the
passphrases
but
you're
useful
and
to
be
passed
prices
for
this.
And
so
this
does
not
make
sense
to
make
it
stronger.
I
I
K
K
K
K
B
C
Thanks,
I
was
going
to
point
out
that
there
we
already
have
compatibility
issues
with
2.6.
If
nothing
else,
there's
idea.
I've
got
decades
worth
of
encrypted
emails
sitting
in
my
mail
folders
that
I
can't
encrypt
or
can't
decrypt
and
read
today
because
they're
encrypted
with
idea
and
yeah.
Yes,
I
know
I
can
use
gdpg1.
C
C
You
know
these
old
methods
back
in
or
you
know
you
or
you
just
have
this
cutoff,
where
you
just
can't
read
old
stuff
anymore,
so
there's
multiple
ways:
you
can
do
it
and
there's
multiple
answers.
I
don't
have
the
right
one.
I
don't
have
a
suggestion
for
the
right
one,
but
I
was
pointing
out
that
we've
already
crossed
that
bridge
overall,
so
so
bringing
it
up
again
is
just
a
kind
of
a
non-starter.
So
I
I
mean
it's,
you
know
it's
it's
all.
A
All
right,
I'm
here,
can
you
hear
me
now?
Yes,
so
I
agree
with
derek
that
adding
a
new
sdk
mechanism
does
not
need
to
break
interoperability
with
the
old
stuff
that
was
on
disk.
It
would
use
a
different
s2k
identifier,
I'm
assuming
again.
This
is
a
situation
where
actually
having
text
to
consider
would
make
it
useful.
We
could
say
we
could
determine
whether
that
happens.
A
Secondly,
I
feel
like
the
argument
that
I'm
hearing
that
says
we
can't
introduce
a
new
sdk
mechanism
because
it
makes
it
difficult
to
know
when
you're
allowed
to
use
it
or
not.
I
think
that's,
I
think,
there's
some
truth
to
that
right.
We
can
introduce
new
public
key
algorithms
and
we
can
t
or
or
symmetric
ciphers,
and
we
can
tell
whether
they're
usable,
because
we
can
see
people's
certificates
when
you're
encrypting
to
them.
A
There
is
no
way
for
us
to
ever
add
any
new
s2k
mechanisms
in
the
spec,
and
that
seems
odd
to
me,
like
I
don't
think,
that's
a
great
outcome.
It's
not
a
great
place
for
us
to
be.
It
seems
to
suggest
that
openpgp
password-based
crypto
is
stuck
using
pbkdf2
and
if
there's
any
problems
in
that
openpgp
is
just
dead
for
for
password-based
crypto.
K
I'm
totally
in
agreement
that
we
don't
want
to
have
pkdf
forced
forever.
We
have
this
flexibility
and
we
surely
want
to
have
our
standards
that
they
are
flexible
to
switch
these
standards.
So
when
a
vulnerable
vulnerability
occurs,
then
we
can
switch,
but
currently
it's
something
like
a
switch
in
in
the
sqk
algorithm,
it's
painful
for
our
users,
so
we
have
to
think
about
it
when
we
want
to
enforce
it
and
when
it's
cryptographically
necessary,
we
should
be
prepared
to
do
this
and
to
have
the
option
to
flexibility
or
flexible
changes.
K
These
algorithms,
that's
great,
that's
totally
my
opinion
and
to
have
arkansas
again
two
in
this.
It's
great.
I
have
no
objections
to
this,
but
I
just
don't
want
to
have
a
default
switch,
that's
not
related
to
current
attacks,
so
yeah.
I
think
we
are
basically
on
the
same
line
here
yeah.
So
that's
it
for
me.
A
Thanks,
so
what
I'm
hearing
is
that
we
want
to
be
able
to
switch
to
new
s2k
mechanisms
at
some
point
in
the
future,
but
we
don't
want
to
automatically
start
deploying
and
sending
messages
that
are
encrypted
with
those
mechanisms
in
the
future.
So
that
sounds
to
me
like
what
we
need
is.
We
need
a
specification
yesterday
that
says
here's
what
you
should
do,
how
to
interpret
things
like
this,
and
you
should
not
generate
them.
B
Okay,
so
this
just,
we
have
rendering
queue
we're
coming
up
to
10
minutes
to
the
hour
we
kind
of
promised
to
be
about
an
hour.
So
I
don't
know
how
many
people
can.
If
somebody
has
a
real
problem
with
running
a
few
minutes
over
then
please,
let
us
know
in
the
chat
and
and
just
before,
verner
goes.
I
say
I
guess
what
at
the
least
what
you
should
do
is
create
an
issue
to
to
track
that
there's
there
are,
there
are
things
to
talk
about.
G
Yeah,
okay,
the
I
got
two
thing
has
been
discussed
on
the
melee
on
the
mailing
list
a
lot
and
I
don't
think
it
makes
sense
to
stop
with
this.
Actually,
our
tiny
tiny
item
again
here
in
the
conference
in
the
in
the
conference
either
we
can
include
it
or
when
we
will
have
a
specification
to
that
later,
that
if
that,
if
we,
it
seems
to
be
pretty
clear
that
we
can't
come
to
an
agreement
on
this.
So
let's
better
stop
with
that.
B
B
G
Yeah,
okay,
so
so
in
newport
g
we
we
implemented
448
448,
but
we
also
realized
that
to
do
this
properly
in
the
specification,
we
would
need
to
have
a
new
data
type
for
this
actually
for
for
everything,
so
that
could
delay
us
even
more
so
if
we
could
add
448
with
not
a
really
rock
solid
specification.
That's
that
that's
okay
to
me,
but
we
can
also
leave
it.
Leave
it
out.
B
B
L
K
K
We
haven't
discussed
this
in
this
meeting
yet
and
I
think
there's
a
huge
split
in
our
community
regarding
this
issue,
and
maybe
we
should
discuss
it.
I
mean
we
have
six
minutes
basically
on
our
agenda.
So
that's
not
really
the
time
we
should
take
for
this,
but
yeah
I
mean
just
give
you
my
viewpoint
and
then
I
will
be
quiet.
K
K
B
B
Nice
to
hear,
but
probably
better,
not
to
hear
so
I
I
guess
what
I
heard
you're
saying
basically,
is
that
we
should
create
an
issue
for
dealing
with
keys
without
user
ids,
so
somebody
should
create
an
issue
in
the
in
the
tracker
for
that
I
I'm
hoping
dkg
will
and
then
in
the
queue.
I
guess
people
do
want
to
discuss
this.
I
see
vincent
yeah.
M
M
A
There
are,
there
are
multiple
things
that
people
transmit
that
are
open,
pgp
related
that
are
not
specified
in
the
draft.
I
don't
know
that
we
can
fully
outline
all
of
them.
You
know
one
common
example
that
I've
seen
is
that
people
transmit
a
free-floating,
revocation
signature
and
expect
people
to
incorporate
that
into
their
key
stores.
A
That
goes
under
the
term
revocation
certificate.
I
hear
people
call
it.
It
is
not
in
the
draft,
it's
commonly
widely
done
it's
accepted
and
it
appears
to
be
super
useful.
So
maybe
what
we
want
is
we
want
a
section
that
describes
common
formats
of
things
that
people
transmit
and
that
could
include
both
certificates
with
user
id
stripped
and
revocation
certificates.
F
A
A
A
You
can
do
a
one
day,
registration
fee,
if
you
want
a
smaller
fee
or
there
is
a
registration
fee
waiver
which
can
be
done
on
a
sort
of
no
questions
asked
basis.
I
appreciate
the
discussion
that
we've
had
here
today
and
I
think
we're
making
good
progress
towards
identifying
what
needs
to
be
done,
and
hopefully
we
can
keep
that
momentum
up.
A
If
you
have
a
specific
issue
that
you
think
should
be
on
the
110
agenda
and
you
want
to
present
it
or
you
want
someone
else
to
present
it,
please
mail
either
the
list
or
the
chairs,
and
we
can
try
to
make
sure
that
that
happens.
We
already
have
a
couple
of
folks
who
are
lined
up
to
try
to
give
some
presentations
there,
but
we
welcome
other
suggestions.
B
So
just
one
note
on
the
red
two
notes
of
that:
one
is
under
registration,
fee
waiver,
the
intent
of
that
is
to
allow
people
to
participate,
for
whom
paying
would
be
difficult.
It's
an
honor
based
system,
so
you
know
it's
if
it
turns
there's
no
tracking
of
that
being
done
essentially
other
than
the
number
of
people
taking
advantage
of
a
waiver.
B
A
If
you
want
to
land
directly
between
the
two
ietfs
that
would
be
early
may,
if
we
think
that
meetings
like
this
are
useful.
I'd
like
to
hear
from
folks
on
the
list
how
they
feel
about
that.
But
if,
if
folks
feel
like
meeting
like
this
is
useful,
we
could
also
do
multiple
interims
between
ietfs,
so
that
could
we
could
put
something,
for
example,
in
early
april.
If
we
wanted
to
try
it,
we
could
even
do
like
a
monthly
interim
meeting
if
we
think
that
this
kind
of
discussion
is
fruitful.
A
A
With
more
frequency,
I
would
actually
request
that
people
identify
specific
topics
that
they
want
to
cover.
We
can
queue
them
up.
Some
of
them
will
have
been
queued
already
by
the
revisions
of
crypto
refresh,
but
I'd
like
to
hear
from
folks
on
the
list
about
when
they
think
the
next
interim
would
should
be.
H
D
B
Now
so
yeah,
given
we're
at
time,
I,
let's
assume
that
the
suggestion
of
early
may
is
reasonable
if
people
would
like
to
speak
to
some
other
alternative,
either
doing
it
earlier
or
later
or
at
some
other
cadence.
That
would
be
good
to
hear
again
now
we're
on
the
list.
So
now
is
your
chance.
If
you
want
to
bring
it
up
now,.
B
Okay,
we'll
take
it
to
the
list
in
the
minutes
and
so
on,
but
with
the
suggestion
will
be
early
may
daniel
suggests
semi-regularly.
So
I
mean
I
guess
we
don't.
We
also
don't
want
to
put
too
much
pressure
on
the
editors,
because
kind
of
each
of
these
will
cause
work
for
them
as
well,
so
mostly
might
be
too
soon.
I'm
too
regular.
Sorry,
but
let's
assume
early
may
we'll
organize
that
and
if
compared
to
the
list.
B
A
Yeah,
I
think
we
can
declare
it
closed.
I
saw
a
little
hand
wave
from
werner.
I
don't
know
what
that
actually
means.
I
couldn't
if
that
was
a
goodbye
or
I
want
to
speak
or
or
what
I
failed
to
do
vid
to
get
any
video
working
on
this
session.
I
just
saw
the
slides,
so
I
sort
of
second
uses
his
preference
for
a
different
video
printing
solution,
but
we
can
figure
that
out
on
the
list
too,
but
yeah
borrowing
any
other
business.
A
A
B
Is
always
open,
so
you
can
join
that
anytime
and
there
is
a
option
now
they're
running
some
experiments
that
you
have
a
matrix.org
client
there's
a
way
to
get
into
it,
which
I
tested
earlier
and
it
didn't
quite
work
but
more
or
less
kind
of
work
and
there's
some
other
zoolope
or
something
at
the
name.
Another
messaging
solution
that
can
also
interoperate
with
those
rooms
great.