►
From YouTube: IETF113-OPENPGP-20220321-0900
Description
OPENPGP meeting session at IETF113
2022/03/21 0900
https://datatracker.ietf.org/meeting/113/proceedings/
A
Okay,
I
guess
we're
out
time
so
good
morning.
All
this
is
the
open
pgp
session
of
the
first
hybrid
ietf
meeting,
so
we'll
see
how
it
goes.
We
have
about
30
30,
odd
people.
In
the
session
we
have
about
a
dozen
in
the
room.
So
tkg,
you
want
to
say
hi.
B
Hello,
I'm
daniel
gilmour.
A
So
tkg
is
remote,
given
that
this
is
the
first
session
of
the
week
in
the
first
hybrid
meeting
we
expect
things
to
go
weird,
but
so
just
logistics
and
so
on.
There's
a
place
to
take
notes.
There's
jabber,
there's
also
a
chat
session
in
the
the
same
chat
session
is
in
java
and
in
my
deco.
A
Oh,
oh!
Yes,
sorry,
if
you
yeah,
if
you're
here,
please
do
log
into
the
data
tracker,
because
that
signs
the
blue
sheet.
Is
that
correct?
Thank
you
paul,
so
again,
yeah!
So
if
you're
in
person
log
in
to
the
data
tracker
and
in
theory-
yes
in
theory,
you're
supposed
to
join
the
message,
the
mic
line
via
the
data
tracker,
I'm
not
sure
how
well
it's
going
to
work
in
practice,
but
we
give
it
a
try.
A
If
it
gets
funny,
we
can
manage
it.
So
if
you
want
to
go
to
the
mic,
the
theory
is,
if
you're
present
in
the
room,
you
should
join
the
queue
and
then
get
to
them.
Go
to
the
mic
at
the
relevant
time
in
practice,
as
paul
just
did
in
practice,
we'll
see
how
it
works
and
again,
if
you're
in
person
then
again
keep
your
audio
video
off
for
remote
participants,
hello
and
I
hope
it's
all
working
for
you.
A
A
The
note
well,
this
is
an
itf
meeting,
there's
a
whole
bunch
of
things.
You
should
note
well
they're,
all
up
there
you'll
get
fed
up
seeing
this
during
the
week.
A
A
I
have
a
couple
of
just
a
couple
of
things
to
say
about
the
design
team
that's
been
running
and
then
justice.
If
he
manages
to
get
into
meat
echo
fine,
I
think
we'll
hopefully
have
him
present
the
difference
between
the
latest
draft
and
the
previous
one,
and
then
there's
a
few
issues
that
the
design
team
felt
would
benefit
from
discussion
with
the
working
group
participants
more
broadly,
and
then
we
have
a
couple
of
presentations
that
again,
the
time
may
kind
of
shift.
A
If
those
take
longer
falco
is
going
to
present
some
work.
That's
starting
on
a
post-quantum
approach
to
pgp
is
falco
in
the
room.
I'm
sorry
I
just
forget
right
now,
for
if
that's
a
remote
presentation
or
not.
A
You
are
remote,
okay,
thanks
for
being
here,
remote
mallory,
I'm
pretty
sure
is
remote
and
it's
an
awful
hour
of
the
morning
for
her
as
it
is
for
other
people
in
her
time
zone.
A
I
don't
see
her
in
the
room
right
now,
but
it's
it's
a
horrible
time
of
the
day
and
then
aaron
has
a
presentation
who
is
his
here
and
aaron
hope,
hopefully
has
agreed
to
help
us
with
taking
notes.
I
would
like
to
get
a
second
taker
before
we
proceed.
A
A
A
So
in
particular,
I
guess
we
have
on
the
on
the
agenda.
We
have
the
latest
id
where
I
guess
daniel
will
go
through
some
of
the
changes
that
were
made
as
he
does
that
I
guess
it'll
be
just.
A
A
C
A
Okay,
so
yes,
we
have
been
running
a
design
team,
basically
to
try,
and
there
was
a
whole
bunch
of
work
done
in
the
past
before
the
working
group
was
recharted,
so
we
have.
It
was
quite
a
bit
of
work
to
do
catch
up
on
that.
The
design
team
has
a
mailing
list.
That's
there.
The
archive
is
public.
You
can
actually
subscribe
to
the
mailing
list
and
receive
mail
and
but
not
post
or
you
can
see
the
archive.
A
Those
are
the
members
there.
We
we
have.
The
kind
of
chairs,
paul
vader's
has
been
helping
as
an
editor
and
then
a
bunch
of
people
who
have
pgp
implementations,
which
has
been
really
helpful
to
try
and
sanity
check.
What
we're
doing.
I
guess
werner
was
only
actively
taking
part
for
earlier
meetings.
He
just
had
more
conflict,
so
couldn't
continue.
A
We
met
kind
of
most
most
weeks
about
29
times.
I
think
it
worked
well,
it's
productive
we're
hoping
to
kind
of
declare
victory
on
that
process
pretty
soon
and
ideally,
then
have
a
draft
that
we
can
start
a
working
last
call
on
and
by
pretty
soon.
I
hope
that's
within
like
weeks,
not
months
and
if
you
know
as
as
and
if
the
the
the
working
group
has
recharted
to
do
more
work,
I
think
that
that
process
worked
kind
of
well,
so
the
chairs
would
be
probably
adopted
again.
A
So
if
we
do
continue
and
continue
to
do
more
work,
there
will
be
an
opportunity
for
people
to
say
they'd
like
to
help
out
there
too,
and
with
that
we
move
on
to
the
current
drafts
now
justice.
Do
you
want
to
take
control
of
the
slide
movement?
Or
would
you
like
me
to
do
the
next
slide
stuff,
for
you.
E
Okay,
so
whenever
you
want
me
to
go
to
the
next
slide,
just
tell
me
right,
so
this
is
a
brief
overview.
D
A
D
A
Yes,
so
who's
read
the
current
drafts.
A
So
I
guess
we
can
use
the
show
of
hands
tool
where's
the
bloody
show
hands.
Still.
Oh,
thank
you
dkg.
A
G
A
All
right
so
about
eight
up
to
speed
justice
next
slide.
I
guess
all.
D
We
had
aad
support
in
the
this
draft,
but
we
changed
that
up
a
little
and
we
decided
to
go
with
the
version
two
of
the
side
d
packet
rather
than
specifying
version
two
of
the
this
aad
packet,
because
we
thought
it
would
be
weird
to
come
out
with
the
version
two
packet
as
the
first
version.
D
Okay,
so
compared
to
the
first
version
of
the
site
d
packet,
we
actually
have
fields
on
the
packet
that
specified
the
cipher
and
aed
mode,
and
we
also
include
a
salt,
and
then
we
introduced
a
key
derivation
step
using
hkdf,
and
that
gives
us
two
things.
First,
it
authenticates
the
context
as
in
the
cipher
and
ad
mode,
so
it
provides
key
separation
between
different
ciphers
and
aad
modes
to
prevent
downgrade
attacks
and
the
per
message.
Salt
gives
a
simple
message
key.
D
So
we
start
out
with
the
session
key
and
that
comes
either
from
the
pk
esk
packet
asymmetrically
encrypted
or
from
an
ske
sk
packet
symmetrically
encrypted.
And
then
we
used
that
as
input
keying
material
for
hkdf.
D
D
D
D
D
D
D
D
D
So
what's
the
status
nibir
has
implemented
that
in
the
branch
called
nupg
and
I've
implemented
that
for
sequoia
and
generated
test
vectors.
With
that,
I
can
report
that
our
support
for
eax
is
good.
Gcm
is
a
bit
problematic
and
ocb
is
not
as
widely
supported
as
we'd
like
because
it
used
to
be
covered
with
patents.
D
D
D
So
obviously,
you
can
no
longer
use
the
old
kind
of
pke
sk
and
sksk
packets
with
the
new
sight
d
packet.
So
likewise
we
defined
a
new
signature
type
and
that
can
only
be
created
with
a
new
kind
of
keys.
A
Yeah,
so
just
to
note
on
the
previous
one
there
in
in
a
jabber
werner,
just
points
out
that
navy's
loopy
g
implementation
is
is
not
a.
What
do
you
think
he
said
that
what
diva
did
our
experiments
to
understand
the
new
things?
It's
you
know
it's
not
an
official
implementation.
He
just
wanted
to
point
that
out.
I
guess.
D
D
Because
we
start
with
symmetric
encryption,
let's
stay
with
symmetric
encryption
for
a
little
while,
because
we
use
the
same
mechanism,
the
we've
seen
the
ske
sk
packet,
which
is
a
symmetrically
encrypted
session
key
packet
in
v5.
We
also
use
aed
there
and
we
use
the
same
scheme
using
hkdf
to
provide
key
separation
and
we
change
the
syntax
a
little
bit
and
can
now
robustly
parse
this
packet.
Even
if
you
don't
understand,
for
example,
an
aad
mode
or
string
to
key
mode
next
slide
piece.
D
D
D
We
also
added
argon
2
id
as
the
new
method
to
derive
a
key
from
a
password.
D
D
D
D
The
body
of
the
padding
package
should
be
random
to
protect
the
padding
from
any
compression
layers
like
like
in
the
transport
protocol.
D
There
are
a
number
of
general
improvements,
so
we
defined
how
to
use
mpis,
multiprecision
integers
to
encode
non-integer
data,
because
modern
ec
algorithms
produce
and
operate
on
octet
strings,
which
are
not
necessarily
integers.
D
We
hope
pgp
has
two
ways
to
express
packets,
the
new
and
the
old
way
where
the
new
wave
was
introduced
in
1998
and
the
old
one
deprecated
in
1998,
and
we
kind
of
made
the
next
step
in
the
deprecation
process
by
calling
the
old
one
the
legacy
format
and
warning
more
sternly
against
it.
D
And
this
has
been
proposed
for
quite
a
while,
and
we
included
it
because
it
is
a
graphic
refresh
thing:
we
changed
how
certificates
look,
notably,
they
are
now
valid.
Without
a
user
id
previously
certificates
had
to
include
one
user
id,
but
there
was
no
requirement
on
it
being
actually
bound
by
signature,
and
now
we
made
the
user
id
optional,
but
there
is
ongoing
discussions
and
daniel
will
talk
more
about
that.
D
D
D
Chart256
is
mandatory
and
that's
also
used
for
fingerprint
calculations.
Md5
sha1
and
drive
md
are
strongly
deprecated.
D
Kds
and
fingerprints
so
version
five
fingerprints
are
the
output
of
share
two
and
32
octets,
and
the
five
kids
are
the
left,
most
eight
octets
of
the
fingerprints.
D
A
H
Well,
I
have
some
concerns,
so
let
me
quickly
tell
a
bit
about
the
history
so
in
I
think
it
was
in
summer
in
summer
or
late
late
summer,
I
dropped
out
of
the
design
team,
because
for
one
I
had
some
time
resource
problems
and
technically
we
have
finished
all
the
critical,
the
critical
questions
why
this
design
team
had
had
been
set
up
then-
and
so
everything
was,
was
fine
at
that
point.
At
that
point,
and
only
a
few
things
had
to
be
done.
H
For
example,
for
example,
mpi
easy
how
to
describe
the
parameters
in
a
bit
in
a
better
way
and
so
on,
and
some
change
some
wording
and
these
well
more
editorial
things
and
things.
H
What
I've
now
seen
is
that
there
are
large
change
large
changes,
changes
which
yeah
so
in
2018
in
january
2018,
four
years
ago,
four
years
ago,
we
have
started
to
deploy,
deploy
aaid
because
on
an
internal
agreement
in
the
in
the
working
group
that
this
is
the
way
we
are
going
with
aed,
and
this
has
been
overthrown
by
this
new
ide.
That's
not
good!
That
is
bad
for
the
reputation
of
openpgp,
because
it's
not
reliable
cannot
be
seen
as
a
reliable
working
working
group.
If
things
like
this
happen,
these
are
my
main
concerns.
H
Having
gcm
is
bad,
but
I
suggested
that
anyway,
because
of
getting
the
certifications
well,
and
there
is
currently
no
way
to
have
ocd
in
in
flips
and
also
not
in
the
next
few
years.
Okay,
that's
for
me.
A
H
Are
in
blue,
including
and
in
rnp,
and
we
did
inter-operate
testing
on
we
had
we
had
in
the
working
group
we
had.
We
had
content
that
that
this
is
the
way
to
to
go
and
this.
So
this
is
the
reason
why
it
has
been
impla.
It
has
been
implemented
now.
Last
summer
things
seem
to
have
changed
then
in
particular
after
I
dropped
out
of
the
design
team.
If
I
knew
about
that,
so
I
would
not
have
dropped
all
of
that.
Okay.
A
A
Or
fixing-
that's
that's
perfectly
normal,
so
I'm
trying
to
understand,
can
you
be
a
little
bit
more
specific
as
to
where,
in
the
current
draft
needs,
fixing
from
your
point
of
view.
H
Well,
you
you
added
new
packets,
deprecate,
duplicated
the
old
aid,
packets,
changed
and
changed.
The
entire
structure
are
so
in
particular,
it's
about
aeid,
which
is
was
one
of
the
main
goals
which
have
been
chartered
are
here
and
that's
that's
a
real
concern.
H
Also,
adding
a
new
new
kd
kdf
is
also
not
a
good
idea
from
the
mentor's
view,
adding
complexity.
H
J
Does
it
work
like
this?
Can
you
hear
me
well,
okay,
good
yeah,
so
I
think
some
of
the
changes
that
were
made
to
aad
were
a
result
of
adding
gcm,
and
I
I
thought
I
would
just
comment
since
that
was
partially
my
proposal.
J
J
You
can
do
a
downgrade
attack
by
converting
it
into
a
message
that
claims
to
be
cfb
encrypted.
Given
that
cfp
and
gcm
are
very
similar
modes,
you
can
then
sometimes
even
successfully
decrypt
the
message
as
cfp.
J
So
this
is
the
main
reason
why
we
added
key
separation
and
eight
and
adding
an
hkdf
was
the
method
we
landed
on
in
the
design
team.
In
the
end,
there
are
other
possibilities,
such
as
putting
the
aad
mode
inside
the
encrypted
public
key
encrypted
session
key
packet
or
the
secret
key
encrypted
session.
Key
packet,
I
mean
yeah.
J
A
H
Well,
okay,
so
the
better
solution
is
not
to
have
a
way
out
to
choose
an
algorithm.
So
now,
without
without
the
pattern
problem
problems
in
ocb,
I
would
suggest
to
drop
everything
else
and
use
only
ocb
and
nothing
nothing
else,
and
then
better
wait
for
for
fips
are
to
get
straight
and
allows
it.
I
can't
see
that
right
now,
but
I've
I've
seen
that
the
brain
build
curves
are
also
or
will
also
go
into
flips.
So
there's
there
is
a
possibility
to
have
lift
and
fibs
in
some
time.
A
H
Yeah
that
that's
right,
it's
that's
one
reason,
and
it
is
in
general,
better
not
to
have
not
to
have
a
way
to
choose
between
algorithms,
and
we
know
that
ocp
is
a
good
algorithm.
I
can't
see
that
there
will
be
any
reason
to
replace
it.
H
They
may,
and
as
we
talk
about
this
gcm
gcm
has
still
a
lot
of
problems,
so,
okay
put
another
packet
into
if
you,
if
they
really
want,
want
to
do
this
as
an
optional
thing
to
have
gcm
with
a
id,
but
for
everything
else
for
everything
else,
we
could
just
live
with
cf
with
cfb
plus
are
one
thing
which
is
also
a
solid
way
of
of
authenticated
encryption,
also
not
standardized,
but
this
works,
and
it
can
be
flips
approved,
be
fips
approved,
can
be
a
part
of
fibs,
approved
implementation.
A
B
Yeah,
I
was
in
the
queue
earlier,
but
I
think
daniel
wiggins
said
what
I
was
gonna
say
about
the
the
cryptographic
justification
for,
including
that
I
want
to
say
I
I
think
I
agree
with
werner's
general
sense
that
fewer
options
is
better,
but
I
just
want
to
know
that
that
would
itself
be
a
major
change
from
the
draft
that
existed
as
of
4
years
ago.
B
No
matter
what
any
of
the
approaches
either
the
one
that's
currently
in
the
draft
or
the
one
that
verner
is
proposing,
would
indeed
be
different
from
the
thing
that
we
never
managed
to
get
out
the
door.
This
person
would
never
manage
to
get
out
the
door
originally,
so
you
know
the
the
changes
that
we're
seeing
are
a
result
of
additional
grip
analysis.
Thank
you
to
lara
who
daniel
mentioned
and
potential
changes
in
the
environment
around
cryptographic,
algorithms
verner.
You
mentioned
changes
to
the
asymmetric
choices
available
for
fips.
B
My
understanding
is
that
chips
has
no
current
plans
to
review
symmetric
cipher
modes.
I
would
love
it
if
they
did,
but
we're
not
working
in
that
world
right
now,
and
so
these
choices,
I
think,
are
the
product
of
sort
of
where
the
world's
at
the
moment
to
try
to
ensure
that
that
open
pgp
has
a
robust
mechanism
going
forward
both
for
people
who
require
fit
compliance
and
not.
A
Okay,
do
we
have
other
people
want
to
chime
in
on
this
topic,.
A
So
would
we
again
just
try
and
clarify
my
understanding
of
this?
Would
it
be
fair
to
characterize
this
as
verner
as
you're,
saying
that
ocd
is
good
enough
and
we,
while
we
might
want
the
ability
to
support
different
cryptographic,
algorithms
having
the
same
level
of
flexibility
for
modes,
is
something
you
don't
think
we
need.
H
Yes,
that's
right,
we
put
eax
into
it
and
they
choose
up
modes
just
because
some
folks
had
problems
with
the
pattern
status
of
oc
ocp.
But,
as
I
said
back
five
year
five
years
ago,
was
there
well
about
this
time
of
the
pattern.
The
plan
and
we
have
expired-
and
we
are
now
at
that
point-
and
for
or
phil
even
dropped
paying
the
fees
for
for
the
patent
yeah.
A
Okay,
so
I
guess
I'm
thinking,
what's
the
best
way
to
kind
of
try
and
figure
this
out
is,
has
anybody
got
a
suggestion
for
the
best
way
to
resolve
this?
To
maybe
would
somebody
be
willing
to
create
a
merge
request
for
the
gitlab
repo
that
would
allow
people
to
see
the
effect
of
change,
or
is
that
just
too
much
work?
I
I'd
have
to
look
at
I'm
looking
at
paulie
as
the
editor.
A
G
I
just
want
to
make
quite
like
I
think
this
is
an
item
for
discussion
before
we
do
a
merge
request,
because,
okay,
it's
like
we,
don't
need
the
exact
text
right
right
now.
It's
the
issue
that
we
need
to
understand
better
whether
we
want
to
go
with
option
a
or
b.
I
don't
think
presenting
text
will
add
clarification
to
the
discussion
at
this
point.
G
A
You're
since
you've
been
in
the
editing,
I
bow
to
your
knowledge.
So
so
is
the
right
outcome
here.
Just
for
the
chairs
to
start
a
thread
on
the
mailing
lists
to
see,
do
we
prefer
what's
in
zero
five
or
do
we
prefer
what
verner
is
kind
of
proposing
I'll,
try
and
burn
it
out?
I
might
drop
uma
and
see
if
I
can
properly
characterize
what
you're
saying
and
then
start
a
thread
on
the
mailing
list.
Does
that
sound
like
a
reasonable
way
to
proceed.
A
Yeah,
okay
vernon
says:
okay,
just
as
I
had
okay,
so
I
guess
if
the
people
taking
notes,
would
just
make
sure
that
there's
an
action
on
the
chairs
to
check
with
werner
and
create
that
thread
on
the
list.
A
J
I
guess
I'll
assume
it
does
until
people
complain.
Okay,
so
as
eustace
hinted
that
there
has
been
some
discussion
and
also
some
proposals
within
the
design
team
about
how
to
structure
a
a
public
key
or
a
certificate.
J
What
elements
to
have
there
so
I'll
I'll
talk
a
bit
about
that
next
slide.
Please
can
I
also
do
so.
A
J
A
J
All
right
so
yeah
just
to
summarize
the
the
current
situation.
There
is
this
convention,
let's
say
in
open
pgp,
to
require
a
self-signed
user
id.
J
Where
you
also
store
various
properties
about
the
key,
such
as
the
expiration
date,
the
algorithm
preferences
etc
and
the
there
there
are
some
use
cases
for
not
having
a
user
id.
For
example,.
J
For
example,
case.openphp.org
has
been
publishing
keys
without
the
user
id
when
the
user
id
has
not
been
verified.
Yet.
J
Thank
you
in
addition
to
that,
we
at
protomail
also
would
like
to
publish
keys
without
a
user
id
in
order
not
to
reveal
personal
data,
for
example,
if
it
contains
their
full
name
and
people
import
their
key.
They
might
not
expect
us
to
publish
it,
and
in
addition
to
that,
we
have
been
getting
some
attacks.
J
Let's
say
where
people
try
to
enumerate
protomail
addresses
via
wkd,
for
example,
so
we
would
like
to
hide
whether
a
certain
email
address
exists
or
not
for
also
for
privacy
reasons,
and
again
this
is
easier
if,
if
there's
no
user
id
in
the
key,
because
the
the
user
id
might
contain,
you
know
very
specific
details
that
make
it
obvious
that
it's
not
an
auto
generated
key,
for
example,
next
type,
please.
J
Yeah
so
rfc480
the
the
preview
or
the
current,
let's
say:
open
pgp
rfc
required
a
user
id
but
does
not
require
a
self
signature,
as
users
also
said,
but
by
convention,
let's
say
some
implementations
did
in
fact
require
a
cell
signature,
which
has
some
advantages,
such
as
being
able
to
express
an
expiration
date
without
an
attacker
being
able
to
remove
the
self
signature,
for
example,
since
that
would
invalidate
the
key.
J
But
this
this
has
not
been
documented
in
the
spec.
The
crypto
refresh
goes
in
the
other
direction
by
also
not
requiring
a
user
id.
So
there
has
been
some
discussion
about
do.
We
need
to
require,
for
example,
a
direct
key
cell
self
signature
to
replace
this
self
signature,
but
yeah
next
slide,
please
so
before
I
get
to
that.
Indeed,
first,
the
question
is:
do
we
need
a
user
id
so
when
encrypting
to
a
key?
J
You
might
think
that
you
want
a
user
id
to
know
whether
you're
encrypting
to
the
correct
key,
but
I
would
argue
that
you
anyway
need
a
separate
mechanism
to
verify
that
either
you
get
the
key
from
wkd
and
therefore
you
trust
that
the
key
belongs
to
a
certain
email
address
or
you
get
it
from
a
key
server,
and
it
also
has
some
third-party
signatures.
J
J
In
any
case,
just
trusting
the
user
id
is
not
sufficient,
because
anybody
can
generate
a
key
with
any
user
id
they
like
for
the
second
point
when
verifying
a
signature
using
a
key.
It's
a
bit
more
tenuous,
because
you
might
argue
that
you
want
to
know
that
the
the
key
owner
claims
to
be
that
person
that
you
think
is
is
sending
you
a
message,
for
example.
J
Otherwise,
in
theory,
someone
else
could
steal
a
public
key
and
a
signature
and
send
you
an
email
and
and
pretend
that
you
know
they
they
signed
it
and
they
came
up
with
it.
J
I
mean
you
might
argue
about
whether
this
this
is
even
a
valid
attack,
since
they
can
also
just
you
know,
sign
the
same
data
but
okay.
J
Another
solution
would
to
this
would
be
signing
the
email
headers
or
you
know,
repurposing
the
the
signups
user
id
subpacket,
even
if
you
don't
have
a
user
id
in
the
key
and
finally,
you
might
argue
it
can
catch
some
mistakes
if
you
have
a
user
id,
for
example,
if
you
upload
the
wrong
key
to
wkd,
then
you
know
the
sender
can
notice
that
they're
using
the
wrong
key,
but
in
general
there
are
not
many,
let's
say,
cryptographic
reasons
for
having
a
user
id.
J
I
would
argue
next,
at
least
then
to
the
question
of
do
we
need
a
self
signature.
I
I
would
argue
yes,
we
do
need
it,
because
if
you
have,
if
you
generate
a
key
for
example,
which
says
I
prefer
as256.
J
J
Because
you
know
that's
the
only
mandatory
to
implement
algorithm,
and
so
you
know
there's
a
downgrade
attack
there.
Of
course
you
might
argue,
then
why
don't
we
make
as256
mandatory
to
implement,
but
in
the
future
the
the
same
argument
still
goes.
If
you
know
a
stronger
algorithm
or
mode
is,
is
added
to
the
spec.
We
might
want
some
robust
mechanism
for
signal
signaling
support
for
that
to
prevent
downgrade
attacks.
J
And
similarly,
if
you
generate
a
key
with
an
expiration
date
of
one
year,
for
example
in
the
future,
then
an
attacker
can't
remove
the
signature
and
remove
the
expiration
date.
If
you
require
having
a
self
signature
in
order
to
use
the
key.
J
As
you
know,
some
current
implementations
do
require,
but
you
know
it's
not
written
anywhere
in
the
spec.
So
the
question
here
is:
should
we
write
that
in
spec
and
if
so,
should
it
be
the
the
user
id
self
signature
as
it
is
today
or
as
an
alternative
proposal?
Should
it
be
a
direct
key
signature?
J
Next
slide,
please
yeah.
So
here
is
a
let's
say
a
tentative
proposal.
It's
it's
not
even
there's
no
merch
request
for
this.
Yet
but
this
is
just
a
proposal
for
discussion
here,
so
the
proposal
would
be
make
user
ids
completely
optional,
also
make
a
user
id
self
signatures
optional,
as
the
current
draft
indeed
does,
but
then
require
a
direct
key
self
signature
in
order
to
have
a
place
to
store
key
expiration
dates
and
preferences
that
can't
be
removed.
J
Then
you
know
yeah,
everybody
can
look
at
the
direct
key
signature
for
the
for
the
key
properties.
You
know
this
would
simplify
what
a
certificate,
let's
say,
looks
like
in
openpgp
and
simplify
usage,
but
with
some
potential
downsides
if
we
care
about,
for
example,
user
id
specific
preferences.
J
So
you
know
that's
that's
part
of
the
topic
for
discussion
next
type.
Please.
B
Hang
on
a
second
daniel,
can
you
just?
Can
you
just
go
back
to
that
proposal?
I
just
wanted.
I
think
it
might
be
missing.
Some
context
is
this
for
all
openpgp
certificates
or
just
for
certificates
with
a
v5
public
key.
J
Right
exactly
that's
a
very
good
point
yeah,
so
this
will
be
for
v5
keys
and
indeed
that's
also
part
of
the
reason
why
we're
discussing
this
now
is
even
even
though
you
might
question.
Is
this
even
in
charger
right?
Is
this
even
relevant
for
the
charter
of
the
crypto
refresh,
and
certainly
the
answer
might
be?
J
No,
even
though
some
of
these
parts
are,
let's
say,
crypto
adjacent,
but
since
we're
releasing
v5
keys
now
it
might
be
a
very
good
opportunity
to
say:
okay,
we
make
a
clean
break,
v4
keys,
had
this
convention
and
v5
keys,
you
know
look
differently
and
we
kind
of
have
a
more
strict
and
more
clearly
defined
certificate
structure
going
forward.
Yeah
thanks
for
that
point,.
J
So
yeah
the
the
questions
to
the
working
group
are
yeah.
First
of
all,
you
need,
or
is
this
even
in
charter?
Do
we
want
to
solve
this
problem?
Let's
say,
of
course,
the
the
status
quo
is
that
you
know
we
have
some
convention.
That
is
not
documented.
J
That
requires
implementations
more
or
less
to
generate
a
user
id
with
a
self
signature,
even
though
the
spec
doesn't
say
so,
and
I
would
say
my
worry
is
that
you
know
if
we
don't
do
anything,
then
probably
that
convention
will
stay
for
v5
keys
as
as
a
sort
of
default,
and
then
we
still
have
this
undocumented
convention.
J
Another
option
might
be
we,
we
document
the
convention,
but
we
don't
do
anything
else
or
another
option.
Is
we
try
to
change
the
the
the
convention,
or
rather
the
the
practice
by
documenting
some
alternative
certificate
structure
that
we
prefer
and
so
yeah?
Some
of
some
of
this
is
crypto
adjacent,
such
as
the
algorithm
preferences.
J
So
you
might
argue
that
it's
in
charger.
Some
of
it
certainly
is
not.
I
mean,
as
I
said,
v5
keys
are
a
nice
opportunity
to
fix
all
of
this,
but
certainly
also,
you
might
argue
that
it's
it's
not
in
charter
and
that
we
should
fix
it
in
in
v6
or
or
whenever.
J
Then.
The
second
question
is:
do
we
care
about
user
id
specific
preferences,
because
so
the
the
tentative
proposal
would
be
to
only
look
at
direct
key
signatures
for
preferences
and
expiration
dates,
etc,
just
to
make
implementations
simpler
and
make
make
openpcp
simpler?
J
Certainly
a
criticism
has
been
that
openpgp
is
too
complex
and
that
you
know
there
are
too
many
differences
in
what
implementations
do
and
certainly
I
think
it
would
be
good
to
simplify
things,
but
you
might
argue
that
you
know
if
you
have
a
key
that
you
use
both
at
home
and
at
work.
You
might
have
different
preferences
for
the
algorithms
that
you
want
to
use
on
those
computers.
J
J
Do
we
care
about
someone
else,
stealing
the
public
key
and
the
signature?
You
might
argue?
No,
we
don't
care
about
it
because
you
know
someone
can
just
steal
the
data
and
sign
it
themselves.
So
perhaps
it's
not
relevant.
If
we
do
care
about
it,
we
could
use
the
signer's
user
id
yeah.
Those
are
mainly
the
the
three
topics
I
had
in
mind
for
discussion,
but
if
anybody
else
has
any
any
other
concerns
or
questions,
then
of
course
feel
free
to
bring
them
up.
A
Okay,
so
just
if
people
want
to
talk
onto
this,
then
jumping
in
the
queue
now
is
the
right
thing
to
do.
Just
to
summarize,
then
you
have
the
you
know.
The
tentative
proposal
was
applying
to
v5
public
keys,
yes
and
the
defaults.
A
A
B
Hi
there,
I'm
just
speaking
with
no
hats
on
here
as
a
implementer
and
maintainer.
The
complexity
of
per
user
id
preferences
is
a
lot
and
I
really
like
the
proposal.
That's
on
the
table
here.
For
the
sake
of
simplicity,
of
understanding,
I
think
there's
a
lot
of
room
for
there's.
B
Even
with
this
proposal,
there's
a
lot
of
room
for
potential
misunderstanding
of
open
pgp
preferences,
but
the
idea
of
dropping
user
id
specific
preferences
is
very
appealing
to
me
from
a
simplicity
perspective
and
I've
never
actually
seen
a
scenario
where
I've
found
the
user.
Id
preferences
were
particularly
desired
or
desirable
or
reliable.
A
I
I
mean,
I
guess
I
can
paraphrase
werner
from
the
jabra,
I'm
guessing
he's
kind
of
not
in
favor
our
favorite.
The
status
quo,
I
think,
is
what
perhaps
he
did
raise
the
point
that
hadn't
been
raised,
but
I
think
I
guess
derek
atkins
had
a
use
case
where
there
was
no
room
for
user
ids
and
that's
that
was
other
than
that.
I
think
werner
would
argue
that
they
should
be
a
must.
A
H
Yes,
we
had
one
idea,
one
idea
on
where
there
was
no
requirement
requirement
for
the
for
the
user
user
id,
and
that
was
ex
particularly
to
eric
derek
atkins
requirement,
so
he
put
it
he
put
it
in,
and
this
was
just
a
discussion
thing
and
later.
I
think
he
retracted
this-
that
it's
not
really
needed
and
I
think
basically
he
could
have
lived
without
are
being
100
compliant
with
your
pgp
specs.
J
Happened,
yeah
so
maybe
just
to
point
out
even
rfc
480,
even
though
it
did
indeed
require
a
user
id
packet
didn't
require
a
self
signature
on
the
user
id
packet,
which
I
mean,
if
you
have
a
user
id
packet
without
a
self
signature,
it
doesn't
really
add
much.
I
would
argue,
of
course,
implementations
require
the
user
id
self
segment
or
some
implementations
required
it.
J
So
I
mean
certainly
another
direction
we
could
go
is
to
put
that
in
the
spec
right,
require
a
user
id
and
require
a
user
id
self
signature.
If
we
think
we
need
them,
but
I
I
don't
know
if
you
have
a
specific
argument
warner
for
what,
whether
we
need
them
or
what's
your
opinion
on
that.
J
A
Java
chat,
he
did
raise
a
couple
of
reasons
why
he
thinks
that
they're
they're
needed
and
then
most
recently
about
a
pgp
263
ia
requiring
whatever.
So
I
I
think
the
action
on
this
we're
not
getting
too
much
more
information
here
in
the
room.
So
I
think
the
action
on
this
is
again
to
create
a
thread
on
the
on
the
list.
Okay-
and
I
guess
the
choices,
are
this
tentative
proposal
or
the
status
quo
and
if
the
status
quo
we
might
want
to
document
it
a
little
bit
better
than
previously
was
the
case.
J
Yeah,
either
documenting
the
cisco
or
even
requiring
the
status
quo
in
the
document
could
be
an
option.
A
G
So
so,
to
paraphrase
the
issue
here
is
that
the
problem
is
that
when
people
are
checking
each
other's
key,
the
minimum
security
requirements
to
do
this
securely
is
more
than
the
vast
majority
of
humans
are
willing
to
invest
to
do
this
process,
and
we
haven't
really
come
up
with
a
solution,
and
we
don't
really
know
what
to
do.
G
But
that
is
really
the
problem
or
we
came
up
with
too
many
solutions,
none
of
which
worked.
No,
because
all
the
solutions
either
require
either
don't
require
enough
work
by
the
human
and
are
therefore
insecure
or
requires
so
much
work
from
the
humans
that
they
won't
do
it,
which
makes
it
insecure.
That's.
A
B
Yeah,
I
think
you
could
provide
a
little
bit
more
color
for
this
problem.
I
don't
think
there's
any
concerns
within
the
working
group
about
the
on
the
wire
use
of
the
fingerprint
and
for
the
changes
that
have
been
made
in
the
crypto
refresh
document.
B
There's
no
place
in
the
modern
formats
where
the
key
id
itself
is
used
on
the
wire
or
in
calculations.
The
full
fingerprint
is
always
used.
You
know
for
people
who
are
interacting
with
v4,
you
know
rfc
4880
compliant
clients.
Of
course
we
can't
avoid
the
eight
octet
pid,
because
that
is
baked
into
the
v4
pkesk
packet,
but
otherwise
on
the
wire.
We're
just
talking
about
full
fingerprints
and
that's
not
an
issue.
The
issue
here
is
for
the
scenarios
like
paul
said
where
humans
are
in
the
loop
for
verifying
a
primary
key.
A
K
Hey
so
I'm
martin
arts,
I
work
for
the
dutch
cyber
security
center
and
I
have
a
question
around
this
topic
for
this
question.
So
if
you
say,
don't
recommend
any
specific
form
would
the
implementers
represent.
The
design
team
expect
there
to
be
multiple
competing,
perhaps
or
different
implementations
surfacing
in
the
user
interface,
because
I
think
well.
At
least
our
experience
has
been
that
it's
been
hard
enough
to
get
people
to
use
pgp
in
general.
So
I
was
wondering
what
your
thoughts
are
on
the
effect
of
this
status
quo
or
recommendation.
G
K
So
yeah,
I
understood
that
I
was
just
wondering
if,
in
a
dash,
in
addition
to
not
having
a
good
solution,
having
multiple
bad
ones
would
be
one
step
worse.
K
This
recommendation,
what
implementers
would
choose
to
do
and
whether
having
them
make
different
choices
based
on
the.
A
So,
just
for
the
for
the
recording,
if
you
stay
here,
said
your
name
before
yes,
so
this
is
daniel
hilkins
again.
J
So
my
position
on
this
is
that
we
shouldn't
show
fingerprints
to
the
user
and
we
should
come
up
with
something
else
entirely
which
could
look.
Something
like
you
know,
showing
a
qr
code
in
order
to
make
it
easier
to
verify
that
you're
using
the
the
correct
key.
J
Of
course,
it's
not
a
suitable
solution
in
every
scenario,
but
I
think
in
my
opinion,
it
would
be
valuable
for
this
working
group
or
a
separate
effort
to
look
into
solutions
like
that
and
that
that's
sort
of
indeed
why
I
would
prefer
not
to
put
a
solution
not
to
put
the
suboptimal
solution
in
in
the
spec
now
in
order
to
you
know,
keep
room
to
think
about
the
the
problem
more
broadly.
If
that
makes
sense,.
A
So
we
have
mallory.
L
Yeah
I
just
wanted
to
follow
on
actually
from
that
comment.
Mine
is
very
similar,
which
is,
I
think,
their
important
user
experience
or
user
interface.
For
this.
It
might
be
very
worthwhile
looking
at
messaging
and
direct
messaging
implementations
of
encryption,
because
users
are
already
being
trained
there
and,
following
on
from
what
the
what
users
expect
actually
might
get
you
the
most.
Even
if
it's
not
a
perfect
solution,
it
will
achieve,
I
think,
harmony
with
again
good
user
behavior
and
that
verification
actually
happens.
A
L
Yeah
I
mean
I'm
suggesting
actually
looking
through
all
the
primary
messaging.
I
mean,
I
think,
that
that
was
probably
the
largest
in
terms
of
user
base,
so
coming
up
with
a
sort
of
survey
of
all
of
the
larger
ones
and
figuring
out
a
solution
that
aligns
with
that,
because
this
is
a
youth
experience
question.
K
Martin
yeah,
so
this
is
martin
again,
so
I
didn't
consider
point
daniel
just
made,
and
I
think
that
makes
sense
to
me
that
if,
if
there's
no.
K
A
Would
it
be
fair
to
say
that
the
sense
here
is
that
to
be
able
to
be
confirmed
on
the
mailing
list?
Is
that
the
the
suggestion
of
the
design
team
to
not
recommend
a
specific
form
is
maybe
the
closest
we've
still
got,
and
but
it
would
be
worth
looking
at
say
what
is
the
messaging
apps
and
someone
are
doing
since
anything?
Anything
better
might
just
exist.
G
So
this
does
require
that
there's
either
a
recharging
or
continuation,
where
we
pick
up
that
work
right,
because
it's
currently
not
in
charter.
A
B
So,
as
far
as
being
in
scope,
you
know
security
area
ads
we'd
be
happy
to
receive
some
guidance
on
that
paul.
Obviously,
you're
you're,
potentially
one
of
those,
but
the
current
charter
might
have
it
be
in
scope
to
say
when
presenting
this
to
humans,
we
believe
that
x,
number
of
bits
of
the
fingerprint
are
are
sufficient
for
human
verification
or
something
along
those
lines,
even
if
we
don't
specify
how
to
present
those
to
the
user
right,
because
there
is
still
this,
you
know.
B
F
F
Hi
everyone
I
just
pulled
out
hop
on
the
mic
and
I
just
cut
the
non-existent
view
with
my
ad
prerogative,
so
just
to
clarify
two
things,
but
first
procedurally
paul
paul
and
I
have
been
splitting
up
the
working
groups
and
I'm
gonna
be
the
responsible
for
for
for
this
working
group.
F
So
they're
going
to
be
seeing
more
of
me
and
to
repeat
what
I
said
in
chat,
I
don't
actually
know
the
answer
and
I
would
like
to
be
very
decisive
in
this
meeting
to
help
the
discussion,
but
I'm
just
not
up
to
speed
on
where
we
are
with
the
working
group
to
make
a
call
here.
F
So
I
I
want
us
to
continue
the
technical
conversations,
but
I
would
like
to
defer
the
in-scope
at
a
scope
decision
until
a
later
point,
so
I
can
have
a
chance
to
to
speak
with
the
working
group
chairs
and
figure
something
out
thanks.
A
B
Yes,
sorry,
I'm
not
showing
video
just
because
my
laptop
will
overheat.
If
I
do
so,
one
of
the
things
that's
come
up
that
is
pending
a
potential
change
to
the
draft
is
to
sort
of
mr
rhett
khan.
Shah
won
when
I
say
retcon,
that's
a
term
from
like.
I
don't
know
online
fandom,
where
people
talk
about
a
storyline
that
has
been
changed
retroactively
to
mean
something
else.
So
we
all
know
that
shot.
One
is
on
the
way
out.
B
B
It
may
be
legitimate
to
use
in
those
places,
but
it
still
seems
potentially
problematic,
because
we
know
that
there
are
collisions
and
we
don't
know
what
else
is
going
to
go
wrong,
and
so
the
thought
was
that
we
might
specify
in
the
draft
that
everywhere
that
sha-1
is
used
should
use
something
like
sha-1
collision
detection
and
there's
some
links
on
the
slide.
B
Here,
if
you're
interested
in
learning
more
about
this,
it's
not
exactly
a
fully
specified
center,
but
basically
it
says
we
can
detect
known
mechanisms
for
collision
creation
and
when
those
happen,
you
can
either
create
a
explicit
failure
right.
There's
no
such
digest
for
this
input
stream
or
you
can
return
a
subtly
different
result
which
would
make
implementations
potentially
break
and
make
collisions
not
collide.
B
So
we
can,
in
the
draft
say
hey
in
the
cases
where
you
still
have
to
use
sha-1.
We
recommend
using
sha-1
cd
or
some
similar
variation
to
avoid
the
known
collision
attacks
on
shot
one.
I
just
wanted
to
flag
that
that's
there.
It
should
have
no
effect
for
people
operating
over
legitimate
data,
and
it
will
just
make
a
noisy
failure
for
implementations
that
end
up
having
tackle
data.
That's
potentially
made
from
one
of
the
collision
attacks
that
we
know
about.
A
Great
thanks,
so
I
does
anybody
want
to
speak
to
you
know,
liking
or
disliking
this
idea
or
to
yeah.
We
see,
I
see
a
thumbs
up
in
the
in
the
room.
I
guess
that
we
should
just
raise
this
as
a
thread
on
the
mailing
list
and
say:
do
people
want
to
go
this
way
and
if
they
do,
then
we
can
figure
a
text.
A
Yeah
that
the
action
is
to
create
a
thread
for
about
this
okay.
So
then
the
last
slide
before
we
move
on
to
the
other
presentations
is
we'd
like
yeah
again,
the
design
team
we've
been
kind
of
operating
well.
Also,
our
editor
has
gone
off
to
become
a
security
area
director
which
is
a
you
know,
unfortunate
future
for
him,
but
but
we
can,
we
won't
be
able
to
expect
as
many
cycles
from
paul,
even
though
it's
it's
relatively,
it's
relatively
straightforward
to
push
buttons,
but
nonetheless
it
requires
a
bit
of
thought.
A
So
we
would
like
to
try
and
get
this
finished
pretty
quickly.
There's
not
many
remaining
merge
requests
in
the
github
gitlab
repo.
There
are
tons
of
issues,
but
not
all
of
which
are
amenable
to
being
represented,
or
not
all
of
which
are
in
charter.
A
So
we'd
like
to
the
chairs,
I
think,
would
like
to
to
try
and
get
to
a
get
some
implementation
experience
with
zero
five
and
then
probably
have
another
draft
at
least
that
we
think
would
be
ready
for
working
group
last
call
so
the
issues
we
called
it
for
resolving
today,
we'd
like
to
do
those
as
part
of
that
I'll
ask
people
to
implement
things
and
check
it
out.
A
Nobody
thinks
it's
crazy
and
then
what
you
know,
I
think,
once
we
get
a
working
group
last
call
started.
I
think
it
might
yeah
depending
on.
If
that
doesn't
far
you
know
fall
down
in
flames,
then
I
think
it
might
be
time
to
think
about
recharging.
But
let's
not
do
that
till
we
have
a
document.
That's
a
working
group
last
call
at
least.
A
There's
teaching:
oh
there's
the
agenda.
There
we
go
okay,
so
now
we
have
falco,
then
mallory
and
then
aaron
and
we're
we
have
35
minutes.
So
I
guess
you
know
if
you
guys
could
be
a
little
bit
quick.
That
would
be
appreciated.
A
I
I
Okay,
yeah.
Thank
you
so
yeah.
My
name
is
fargo
schlensky,
I'm
presenting
to
your
project,
which
should
be
of
interest
to
the
working
group,
because
it's
one
of
its
aspects
is
that
we're
going
to
do
standardization
efforts
and
for
post-quantum
cryptography
in
open
pgp.
I
So
this
project
is
contracted
out
by
the
german
federal
office
for
information
security
on
the
side
of
the
bsi
on
on
the
side
of
the
bsi
stavros
is
leading
the
project
on
the
side
of
the
contractor
mdg,
together
with
the
technical
university
of
eindhoven,
I'm
the
project
manager.
So
next
slide,
please
the
background
is
yeah.
As
I
said,
it's
contracted
out
by
the
bsi
in
order
to
progress
on
the
post-quantum
standardization.
I
The
timeline
is,
we
start
at
end
of
last
year
and
it
goes
for
three
years
till
the
end
of
2024,
so
we
are
doing
we're
going
to
do
standardization.
I
So
I'm
speaking-
and
you
have
to
understand,
I'm
speaking
in
from
the
perspective
of
the
project,
what
are
actually
going
to
happen
in
the
working
group?
That's
not
our
influence,
of
course,
but
we
have
this
this
job
to
do
to
do,
to
drive
forward
the
standardization
of
post-quantum
schemes
based
on
the
selection
by
nist
that
we
are
waiting
now
anytime
and
also
do
proof
of
concept
implementations.
I
We
are
aiming
at
multi-algorithm
key
encapsulation
methods
and
signature
here
for
the
implementation
it
will
be
lattice-based
we'll
implement
it
in
thunderbird
via
rnp
and
botan
is
the
cryptographic
library
but
we'll
also
make
implementations
in
gnupg
and
libgrypt
next
slide.
Please.
I
So,
and
for
the
motivation,
why
do
I
address
it
now
already?
So
that's
the
well-known
problem
for
the
crypt
for
for
public
encryption,
the
store
now
decrypt
later,
which
people
might
be
facing
today
in
certain
applications,
but
also
for
signatures.
We
have
some
applications
where
signatures
cannot
be
redone
efficiently,
so
the
long-term
security
for
signatures
is
also
required
and
we
are
observing
that
post
quantum
cryptography
is
already
entering
generally
already
entering
the
standardization
phase
now,
so
this
contest
is
coming
to
an
end
and
other
standardization
efforts
which
I
will
address
in
the
next
slide.
I
I
So
this
is
just
some
examples
of
drafts.
I
don't
think
we
have
to
go
into
everything
in
detail.
Some
rfcs
already,
based
especially
in
the
context
of
the
firmware
update
the
conscious
binary,
object,
representation
and
yeah
lamps,
is
considering
to
adopt
a
number
of
drafts
around
coast
post
quantum
key
signatures
and
encryption
binary
data
formats,
there's
also
a
draft
for
for
the
icon1
encoding
for
hash
b.
Hash
based
schemes
and
etsy
iso
also
have
the
activities
publishing
documents
on
this
giving
recommendations
already.
I
So
everybody
has
it
on
the
screen.
So
this
just
says
a
bit
of
more
background
summary
for
for
the
motivation.
Okay,
next
slide,
please
maybe
one
more
slide,
please
I'll
reverse
the
order
here,
so
the
design
criteria,
just
as
a
summary
we
we
are
only
starting
now,
we
don't
have
any
content
to
to
present
now
what
we
are
going
to
do.
But
the
aim
is,
of
course,
not
only
to
have
pqc
but
to
have
this
what
is
sometimes
referred
to
as
hybrid
but
more
accurately,
probably
as
multi-algorithm
scheme.
I
So
we
want
to
be
able
to
have
keys
different
keys,
which
is
of
course,
already
possible
in
an
open
pgp
certificate.
So
you
can
decrypt
encrypt
keys,
encrypt
messages
with
multiple
keys
of
a
recipient.
You
can
perform
signatures
with
multiple
of
your
own
keys
and
so
in
order
to
provide
this
fallback.
I
If
the
new
pqc
screams
turn
out
new
pcc
schemes
turn
out
to
be
not
as
secure
as
expected.
I
We
want
the
new
formats
to
be
ideally
processable
by
existing
implementations
that
don't
support
the
new
pqc
standard.
Okay,
one
slide
back.
Please.
I
I
We
target
to
produce
a
first
draft
version
in
the
last
quarter
of
this
year
towards
the
end
of
this
year,
but
in
general,
our
standardization
efforts
last
until
the
the
end
of
the
project,
which
should
very
well
cover
the
this
standardization
phase
which,
as
they
announced
is
this
announced
it.
As
I
understood
it,
should
last
until
the
end
of
2023.
I
So
by
then
we
should
have
the
standards
only
by
then,
of
course,
it
makes
really
sense
to
finish
the
the
open
picture
piece
standard
as
well,
but
there
are
many
things
there.
There
are
not
many
things
that
will
be
that
are
left
open.
Now,
I
I
would
say
more
or
less
it's
the
parameters
nist
will
have
to
specify
maybe
the
apis
as
far
as
that
is
relevant,
but
otherwise,
of
course,
it's
possible
to
already
start
with
many
specifications
at
this
stage
already.
I
Okay,
then
next
slide.
Please
yeah,
then
of.
D
I
The
most
important
aspect-
and
this
is
why
we're
pre
presenting
here,
is
that
we
of
course
seek
the
cooperation
with
the
working
group.
We
are
well
aware
that
there
is
no
charter
for
this
currently,
but
in
any
case,
as
I
said,
it's
a
project,
it
has
a
timeline.
We
have
work
packages,
we'll
do
these
things
and
the
more
we
have
cooperation
with
a
working
group.
The
more
I
think,
of
course,
this
project
will
benefit,
so
we
are
open
for
any
kind
of
input
or
contribution
and
yeah.
I
Currently,
our
plan
is
to
work
on
a
draft
which
is
hopefully
later
adopted
by
the
working
group.
That
is
from
my
side.
Thank
you
for
your
attention.
Thank
you
for
this
opportunity
to
present
the
project
here,
yeah
and
I'll
be
happy
or
we'll
be
happy
to
answer
any
questions
you
might
have.
A
Great
thanks,
michael
florence,.
M
Hi
I'm
flo
uk
ncsc.
I
was
wondering
if
you'd
given
any
thought
to
algorithms
yet
beyond
beyond
lattices.
Also
thanks
was
really
interesting.
Presentation.
I
Yet,
regarding
the
algorithm
choice
for
standardization,
we
plan
to
orient
towards
the
next
decision.
So
basically,
we
would
like
to
standardize
all
or
consider
all
the
missed
schemes
that
are
selected
for
standardization,
also
for
standardization
in
openpgp.
It's
only
that
the
implementation
that
we
make
in
the
project
is
restricted
to
the
subset
of
one
encryption
scheme
and
one
signature
scheme.
I
There's,
of
course,
an
interest
of
us
that
there
are
other
contributions
in
all
these
efforts
that
hopefully
there
is
some
some
more
contributions
of
implementations,
maybe
of
the
other
schemes,
as
there
are
already
existing
implementations
of
all
schemes
that
shouldn't
be
too
difficult
to
to
have
a
proof
of
concept,
implementation
of
each
but
yeah.
This
is
something
that
would
require
more
cooperation
with
other
people.
K
And
also
at
protonmail,
we
are
now
trying
to
consider
an
experimental
implementation
of
post-quantum
cryptography
and
we
have
looked
at
the
schemes
he
also
proposed
on
the
on
the
mailing
list.
They
they
look
practical
and
convenient,
and
we
have
already
we're
starting
on
right
now
onto
let's
say
proof
of
concept:
implementation
as
well.
We
would
like
to
let's
say,
have
a
chat
and
probably
interrupt
like
develop
something
that
is
interoperable,
probably.
A
Thanks
falco,
so
I
guess
this
would
be
definitely
one
to
consider
at
rechartering
time.
So,
okay,
I
don't
see
anything
else
in
the
queue
so
mallory.
If
you'd
like
to
jump
in.
Do
you
want
us?
Do
you
want
to
you
want
me
to
share
the
slides
for
you
or
do
you
want
to
do
it
you're
doing
it
yourself.
B
L
It
doesn't
like
that,
for
the
sake
of
time,
maybe
you
should.
L
That's
fine.
I
appreciate
it
all
right,
hi
everyone,
so
I'm
mallory
notal,
I'm
one
of
the
authors
on
this
draft,
the
it's
a
definition
for
end-to-end
encryption
and
next
slide.
L
I
wrote
it
with
a
few
other
folks
that
you'll
see
here,
I'm
not
sure
if
any
of
them
are
in
this
meeting.
But
if
you
are
feel
free
to
jump
in
or
correct
me
in
the
chat
things
like
that.
L
Don't
see
them
either!
That's
fine
next
slide,
so
the
goal
is
really
quite
straightforward.
It's
just
a
definition
of
into
encrypted
systems
and
encrypted
communications.
You
know
that
that
second
part
is
swapped
around
throughout
the
draft,
but
really
yeah
that
that's
the
it's
really
intended
to
be
very
straightforward.
Next
slide.
L
L
L
Ietf.Org
there's
been
a
little
bit
of
discussion
there.
We
got
new
issues
out
of
out
of
those
discussions,
but
then
in
needing
to
progress
it.
I
think
it
does
also
make
sense
to
for
me
to
come
to
you
to
the
working
groups
that
this
actually
might
affect
and
ask
for
reviews.
So
that's
what
I'm
doing
now.
I
don't
know
that
that
this
should
be
adopted
necessarily
in
any
of
these
working
groups,
but
more
abuse
is
always
required.
So
next
slide
please
to
get
more
into
the
substance
now.
L
The
outcomes
that
we're
hoping
for
with
this
draft
is
that
it
makes
it
more
difficult
to
call
things
into
inter-encrypted
when
they
really
aren't,
and
actually
we
do
see
this
tendency.
Maybe
it's
not
so
much
in
engineering
spaces
like
the
ietf,
but
you
know,
encryption
has
landed
in
the
mainstream
and
the
more
public
discussion
about
user
expectations
on
the
internet
and
apps
they
use,
and
we
are
seeing
a
tendency
for
that
public
discussion
to
discuss
things
that
are
not
actually
indian
encryption
as
if
they
are.
L
L
I
think
it
might
also
be
useful-
and
this
is
a
question
I
guess
through
the
group-
to
put
sort
of
definitional
text
in
one
draft
so
that
it
doesn't
make
your
other
drafts
very
long,
and
you
don't
have
to
worry
about
being
really
specific.
What
you
mean
when
you
invoke
things
like
deniability
or
other
kinds
of
concepts
related
to
this
and
then
the
last
one
is
maybe
a
goal.
L
I'm
not
sure
this
is
maybe
a
question
for
those
sort
of
working
across
these
spaces
in
the
ietf,
so
area
directors
essentially
but
like
you
know,
if
there's
a
possible
goal
or
if
it
is
a
desirable
thing
to
try
to
harmonize
a
sort
of
norms
or
principles,
driven
approach
to
encryption
in
particular,
although
transport
encryption
might
also
have
some
overlap
there,
so
those
are
the
three
outcomes
there
may
be
more.
L
Those
are
the
ones
we
articulated
when
we
are
initiating
this
work
next
slide,
please,
the
the
also
an
important
approach
that
we
wanted
to
be
clear
about
from
the
beginning
is
that
we
didn't
want
to
write
a
draft
that
explained
what
end-to-end
encryption
is
not.
L
That
would
not
have
been
helpful,
although
there
are
very
many
examples
out
there
that
we
could
have
used,
we
wanted
it
to
be
a
definition
that
stands
on
its
own
without
counter
example,
we
yeah
and
to
that
point
also
then
invoking
threats
as
a
way
of
explaining
what
intended
encryption
is,
would
be
a
common
tendency
and
a
lot
of
documentation
sort
of
out
in
the
wild
talks
about
threats.
L
When
it's
trying
to
talk
about
encryption,
we
also
didn't
want
to
invoke
a
threat
model
into
this
discussion
at
all
and
then
the
other
thing
which
this
baby
is
difficult
to
avoid.
We
have
no
control
over
it
is
that
if
there
seemed
to
be
a
lot
of
disagreement
within
an
engineering
space
like
the
internet
engineering
task
force,
that
could
be
counter
to
our
goals
to
try
to
come
up
with.
You
know
harmonization
on
what
is
indian
decryption.
L
So
if
we
all
sort
of
disagree
about
what
it
means,
then
that's
actually
counterproductive,
and
you
know
considering
ietf
meetings
and
mailing
lists
are
well
documented.
That
would
maybe
not
be
useful,
but
we
again
can't
control
it
and
if
we're
totally
wrong
about
what
is
intent
encryption,
then
that
might
happen.
Okay
next
slide.
L
This
should
be
the
table
of
contents
yep.
So
the
this
is
what
the
table
of
contents
looks
like
now.
It
did
not
always
we've
added
quite
a
lot
into
the
formal
definition
piece.
So
it's
a
three-part
draft.
It
tries
to
define
intimate
encryption
in
three
different
ways
and
we
believe
in
aggregate.
L
That
is
what
is
required
to
actually
come
up
with
a
full
definition.
The
first
way,
of
course,
is
a
formal
definition.
What
is
an
end?
What
is
the
end
to
end
principle?
What
is
encryption,
and
then
can
you
summarize
that
in
one
or
two
sentences-
and
we
do
that
in
the
first
part,
but
then
I
think
it's
also
incredibly
useful
to
look
at
what
are
the
features
of
indent
encryption
and
then
what
are
the
challenges
that
features
or
implementations
are
trying
to
overcome
when
looking
at
systems
design?
L
So
the
second
part
is
from
a
developer's
perspective,
what
is
into
encryption
and
then
finally,
user
expectations
should
matter
quite
a
lot,
because
if
the
users
are
not
aware
of
features
or
they
are
not
sort
of
making
choices,
we
were
talking
before
about
user
behavior
around
checking
signatures,
like
all
of
that,
actually
matters
quite
a
bit,
no
matter
what
the
tech
is.
It's
underlying
it
because,
at
the
end
of
the
day,
users
are
the
ones
writing
these
messages
and
receiving
these
messages.
L
So
user
expectation
tries
to
lay
out
sort
of
when,
when
a
when
a
user
hears
that
a
messaging
app
is
indian
encrypted.
What
actually
should
they
expect
and
does
the
technology
fulfill
that
next
slide.
L
So
the
draft
is
now
in
o2,
I
think
so,
since
the
first
draft,
we
had
to
really
expand
the
formal
definition
section.
It
was
too
succinct
and
there
was
a
lot
of
question
about
what
is
an
end.
That
was
a
really
interesting
discussion,
because
it's
not
maybe
just
the
device.
If
you
have,
for
example,
proposals
that
say
if
you
just
scan
the
device
before
content
is
uploaded,
then
you
could
do
some
degree
of
content,
moderation
in
indians
and
encrypted
systems.
L
We
kind
of
feel
like
that's
a
violation
of
the
promises
of
confidentiality
and
privacy
and
end-to-end
encrypted
messaging.
So
then,
what
is
it
into
the
device?
Is
it
the
operating
system?
Is
it
the
person?
You
know?
What
is
that?
So
we
we
dealt
with
that
after
the
first
version
and
then
the
version
we're
at
now
has
changed
again
like
a
little
bit
more
work
on
the
definition,
the
the
formal
definition
section
and
also
having
to
grapple
again
with
this
identity
versus
endpoint
piece.
So
that's
those
are
the
changes.
L
Actually
it's
mostly
been
in
the
sections.
I
think
the
pieces
around.
You
know
what
our
users
expect
and
then
also
what
are
some
of
the
possible
features
for
indian
encrypted
messaging.
Implementations
have
not
really
been
touched,
but
that
actually
might
be
the
ask
for
you
all.
If
you
check
a
look
at
this
so
next
slide,
please
we're
hoping
to
close
a
few
of
the
smaller
issues
in
the
next
version
that
they're
not
terribly
thorny.
The
there's
a.
L
I
think
that
it's
worth
looking
for
people
who
really
are
working
on
the
sort
of
metadata
reduction
angle,
which
sounds
like
a
lot
of
you,
are
with
respect
to
getting
rid
of
user
ids
and
other
kinds
of
things
that
could
use
a
nice
sweep
over
for
folks
wanting
to
review
like
are
we
treating
the
metadata
problem
enough?
As
far
as
I
remember,
it's
just
like
one
sort
of
subsection
in
section
two
thinks.
L
I
think
that
we
have
other
features
in
there
like
perfect
forward
secrecy,
backwards,
compatibility
issues,
disappearing,
messages
deniability,
but
we
want
to
make
sure
that
that's
complete.
Actually,
even
if
not
every
implementation
has
those
features,
we
want
to
make
sure
that
they're
all
there
and
yeah
just
if
we
could
have
more
reviews.
I'd
really
welcome
that
next
and
final
slide
gives
you
all
a
pointer
to
where
this
is
happening
at
github.
L
But
again-
and
I
should
have
put
this
on
the
slide-
I'm
really
sorry,
you
can
email
e2ee
ietf.org
for
with
your
review,
and
it
would
just
be
really
great
to
have
more
reviews
but
open
to
your
thoughts
and
feedback
now
as
well.
If
you
have
any.
A
Great
thanks
mary
any
comments
or
questions.
I
guess
how
many
people
have
read
this
draft
or
you
know
just
in
the
room?
No,
no!
Okay,
so
I
guess
we're
encouraging
people
to
read
the
draft.
It's
the
next
step.
Really,
I
don't
see
anybody
in
the
mic
line,
so
yeah
yeah
again
I'd
encourage
you
to
read
the
draft
and
please
comment
to
on
the
e2ee
list.
K
This
is
your
box.
Oh
thank
you
so
I'll
be
presenting
the
transparency.
That
is
a
project
that
we've
recently
been
developing
at
protomail,
but
it's
also
something
that,
in
my
opinion,
is
very
important
for
the
whole
community
to
have
an
idea
to
propose
an
alternative
to
like
to
verify
other
people's
keys
in
an
automated
way.
K
K
This
is
especially
relevant
for
wkd,
because
wkd
servers
might
like
serve
the
key
and
also
handle
the
the
delivery
of
the
email
itself.
So
you
have
a
single
point
of
failure
or
some
where
a
malicious
actor
might
inject
a
bad
public
key
read
the
message
and
silently
re-encrypt
it
to
the
recipient.
That
might
not
even
notice
that
this
is
happening.
K
So,
oh,
no,
that's
too
many
slides
yeah
too
many
clicks.
I
don't
spoil
the
content,
so
what
do
we
have
right
now
is
for
is
mostly
either
a
key
signing
parties
or
the
the
web
of
trust.
The
we
have
seen
that
this
has
worked,
but
this
not
always
works.
K
K
What
do
we
do
is
basically
create
a
screenshot
of
the
of
the
various
key
in
a
point
in
time
and
you
would
basically
check
whether
your
keys
are
into
the
screenshot
and
you,
and
if,
if
you
see
your
keys
correctly,
everyone
else
sees
your
keys
correctly.
This
is
I
mean,
based
on
to
the
comics
paper
that
has
been
published
in
2014
and
also
google's
key
transparency
project.
So
it's
not
nothing,
let's
say
terribly
innovative,
but
it
is
still
a
good
application
to
open
pgp.
K
So
the
general
principles
is
the
fact
that
we
return
you
some
information
when
you
try
to
fetch
a
key,
and
we
return.
You
also
I'd,
say
a
revision,
a
proof
and
this.
If
everything
matches,
then
you
can
use
this
information
to
verify
that
what
you're
getting
is
what
everyone
else
is
getting
there
or
there
is
also
something
needed,
is
like
auditors,
that
verify
that
we
publish
consistent
ebooks
and
we
don't
cheat
in
publishing
several
ebooks
at
the
same
time,
like
basically
branching
off.
A
Next
one
so-
and
I
just
added
myself
to
the
queue
to
ask
a
question-
oh
yeah,
in
in
this
slide
here,
who
is
we
so
as.
K
Of
now
it
is
protomate,
but
the
idea
is
the
fact
that
everyone
could
run
their
own
implementation
of
key
transparency.
There
could
be,
let's
say
any
kind
of
like
anyone
who
wants
to
participate
into
the
project
might
want
to
register
their
own
merkle
tree
into.
Oh,
it's
falling
the
content.
Okay,.
A
K
Ahead,
go
ahead,
go
ahead,
okay,
so
protonmail
or
somebody
similar
yeah.
Exactly
like
also,
I
don't
know
keys.openpgp.org
might
want
to
do
the
same.
Okay,.
K
And
how
do
we
do?
It
is
miracle
trees.
Basically,
this
is
a
compact
way
to
simply
ensure
that
users
can
verify
their
own
path
without
having
to
download
the
whole
tree,
and
auditors
can
verify
that
the
tree
is
consistent
across
ebooks.
K
We
use
the
verifiable
random
functions
to
derive
the
part
of
the
leaf,
and
so
that
you
can
map
a
single
address
to
a
single
leaf
and
we
cannot
cheat
by
assigning
an
address
to
multiple
leaves
and
well
here.
We.
This
is
an
idea,
but
there
might
be
the
fingerprinter
that
states
which
key
do
you
actually
want
to
use
as
primary
key.
K
K
Okay,
so
how
does
this
fit
into
into
open
bgp?
It's
mostly.
I
think
this
is
an
augmentation
of
like
of
wkd.
B
Thanks
for
raising
this,
it's
I
think
this
is
interesting
work,
I'm
curious
about
your
choice
of
fingerprints
being
at
the
leaves
of
the
tree
as
opposed
to
full
certificates.
B
Basically,
because,
as
we've
talked
about
already
today,
the
openpg
certificate
format
is
composable
and
one
thing
that
a
malicious
wkd
server
could
do
is
serve
up
the
wrong
combination
of
packets
associated
with
a
single
public
key,
for
example,
they
could
serve
say
an
encryption
capable
sub
key
that
they
know
has
been
revoked
because
it's
been
compromised
but
not
serve
the
self.
K
So
in
our
implementation,
we
actually
consider
this.
I
this
was
a
let's
say
a
toy
example
where
we
use
the
fingerprints,
but
actually
in
the
in
the
let's
say,
final
draft
that
we're
trying
to
implement.
We
do
have
a
science
list
where
we
specify
also
all
the
sub
key
fingerprints
and
not
just
and
also
the
the
usage
of
the
keys.
So
if
a
key
is
revoked
or
if
a
key
is
used
to
be
encryption,
only
or
signature
only,
etc,
etc,
etc.
B
K
B
So
the
I
think,
the
only
thing
that
I
mean
we
already
have
a
standard
for
how
certificates
look.
The
one
thing:
that's
missing
for
your
purposes
here,
I
think,
would
be
a
canonicalization
of
an
existing
open,
pgp
certificate
right,
a
transfer
public
key
form,
or
are
you
thinking
that
it
needs
to
be
something
else.
K
B
K
K
Maybe
a
a
stupid
example
could
be.
We
have
external
addresses
that
are
not
meant
for
email
use,
and
we
want
to
specify
this
directly
into
the
miracle
tree.
K
So
clearly,
this
could
also
be
like
this
can
also
be
set
into
the
key
flags,
but
the
key
flags
are
not
specifically
into
the
into
the
miracle
tree
and
therefore
I
don't
know
whether
this
notation
would
include
that
information
directly
into
the
merkle
tree.
G
Okay,
paula
speaking
so
my
question
is
about
so
I
understand
the
merkle
tree
and
the
append
only
properties
and
those
are
great.
But
who
says
that
the
latest
submission
is
actually
the
real
one
like
we
have
a
whole
spam
problem
in
the
key
servers
right
now,
where
anyone
submitting
stuff
like
without
confirmation.
K
The
fact
that
the
only
the
people
like
if
we
use
wkd,
if
we
bind
it
to
wkd
and
not
to
the
to
the
key
servers
that
would
actually
give
us
a
lot
of,
let's
say
flexibility,
disorder
in
this
direction
because
wkd
you
have
already
an
authority
like
the
who
owns
the
domain,
can
choose
what
goes
in
there.
Not
everyone
right.
G
But
so
who
owns
the
domain
is
and
that
that
was
my
next
question?
Actually,
if
you,
if
you
link
it
to
the
domain,
then
you
have
at
least
a
guarantee
that
whoever
controls
the
domain
hopefully
is
also
within
that
domain,
controlling
the
key
and
you
get
the
right
person.
So
if
a
domain
is
sold
to
somebody
else,
somebody
else
will
run
dns
and
point
to
another
wkd
service,
where
you
can
get
the
key.
Of
course.
G
If
you
do
this,
that
I'm
the
author
of
the
open,
pgp
key
rfc,
you
can
also
just
put
it
in
dns
and
protect
it
with
dns
segment.
You
have
to
the
same
property
of
having
the
current
domain
owner,
clearly
owns
that
key,
that
they
currently
publish
and
it's
valid,
and
it
is
the
latest
key
because
that's
the
key
they're
currently
publishing-
and
you
would
avoid
these
at
least
these
moral
three
things
and
having
multiple
keys
with
wkd.
K
I
mean
this
also
provides
the
fact
that
this
lets
you
look
into
the
past
and
see
if
an
email
in
the
past
was
already
let's
say,
was,
was
faked
and
also
would
allow
you
to
see
if
someone
else
has
published
a
key
on
your
behalf
without
you
knowing
like,
like
you,
can
audit
yourself,
that's
the
whole
point
of
the
of
the
thing.
Is
you
should
audit
yourself
into
the
miracle
tree
and
spot
if
there's
any
inconsistency,
so.
A
We're
we're
kind
of
about
time,
okay,
so
in
fact
we
are
a
time,
okay,
so
yeah.
I
guess
this
is
a
topic
that
ct
was
interesting.
There
might
be
a
useful
way
of
making
this
work,
and
in
that
case,
that
would
be
interesting.
I
think
for
to
you
know
having
a
worked
out
thing
like
this.
At
the
time
we
started
talking
about,
recharging
might
be
kind
of
quick,
it's
something
comfortable
yeah
great.
A
So
thank
you
thanks
to
aaron
and
to
florence's
for
for
taking
notes
for
those
of
you
in
the
room
you
you
should
hopefully
have
signed
into
the
data
tracker
and
click
the
on
site.
For
this
thing.
A
So
that's
that's
how
you
sign
the
blue
sheet,
so
I
won't
be
doing
the
traditional
thing
of
running
around
the
room
with
blue
sheets
at
the
end
as
normal,
and
with
that
thanks
for
coming
and
we'll
have
some
discussion
on
the
main
list
and
go
from
there
and
thanks
to
all
the
remote
folks
for
turning
up
as
well,
especially
if
you're
in
a
painful
time
zone.