►
From YouTube: IETF-OPENPGP-20230209-1200
Description
OPENPGP meeting session at IETF
2023/02/09 1200
https://datatracker.ietf.org/meeting//proceedings/
A
B
C
C
D
C
E
D
C
C
G
F
G
C
C
C
So
just
in
case
people
don't
know,
the
convention
here
is
like
when
an
ITF
meeting's
in
place.
So
if
you
want
to
say
something
you
can
put
up
your
hand
and
join
the
queue,
if
just
under
your
name
at
the
top
left
the
screen,
there's
a
join
queue,
kind
of
hand,
symbol
that
you
can
click
like
I
just
did,
and
then
you
appear
at
the
top
of
the
roster,
and
we
can
call
on
you.
C
A
You've
probably
read
these
things
when
you've
been
in
previous
iitf
meetings,
I
think
I
see
hang
on.
There
was
the
people
who
are
in
attendance
or
just
as
a
reminder.
This
is
an
idea
meeting
and
please
make
sure
that
your
video
and
audio
are
off
unless
you're
chairing
or
presenting
or
speaking,
obviously,
once
you're
in
the
queue
and,
if
you're
speaking,
we
recommend
using
a
headset,
because
otherwise
we
get
feedback
loops.
D
A
A
There's
been,
all
of
them
have
been
raised
individually
in
separate
threads
of
an
analyst,
and
hopefully
we
can
have
those
discussions
on
that
thread.
Those
threads
clearly
which
document
I
would
hope
that
we
can
have
a
chance
during
this
meeting
to
just
clarify
the
specific
details.
These
are
the
major
substantive
changes
that
are
standing
that
are
proposed
and
outstanding
for
refresh.
C
C
I
hope
that
if
we
manage
to
figure
out
all
these
topics
that
we
then
managed
to
get
this
document
out
of
the
working
group
very
very
soon-
that's
my
goal
because
the
longer
it
kind
of
hangs
around
the
more
issues
we
find
we'll
just
end
up
on
an
infinite
kind
of
Never,
Getting,
finished
kind
of
mode,
which
is
part.
So
hopefully
we
try
and
decide
these
things
today.
If
possible
and
move
the
document
along.
A
C
A
However,
we
also
do
need
to
make
sure
that
those
those
conclusions
are
posted
publicly
to
the
list,
and
so,
if
you
reach
any
special
Insight
today
or
you
just
realize
that
you
have
a
clear
opinion,
one
way
or
the
other
on
these
things
and
you
choose
to
express
it
on
the
list.
That
would
be
much
appreciated,
because
activity
analyst
is
where
the
the
funnel
decisions
are
made.
A
A
A
A
So
I
would
like
to
hear
from
folks
who
are
I
would
like
to
hear
from
folks
whether
they
think
they
still
think
this
is
a
good
idea.
There
seemed
to
be
a
consensus
in
the
room
in
115.
that
this
was
a
good
idea.
Now,
there's
a
merge
request
for
it.
I
don't
know
whether
anybody
has
had
a
chance
to
take
a
look
at
the
merger
quest
to
see
whether
it
looks
right
to
them
or
whether
anybody
has
any
new
objections
to
this
change.
H
Just
to
face
up
that
I
am
one
of
those
people
who
has
shipped
code
that
supports
the
V5
format
as
supported
by
DPG
onac
out
of
the
support
back
in
2019
based
off
the
test,
key
that
was
sent
to
the
open
pgb
mailing
list.
So
I
have
a
vested
interest
that
we
don't
get
the
income
part
of
elevating
that
we
do
to
B6
for
something
that
is
essentially
a
different
format.
H
C
C
H
A
D
C
C
A
So
in
a
V3
signature,
the
these
blocks
here
are
broken
up
as
by
octets,
so
the
V3
signature,
the
last
four
octets,
are
a
signature,
Giants
Tab
and
the
octet
before
that
is
a
signature
type
and
before
that
is
all
of
the
signed
data.
So
the
document
for
the
star,
a
V4
format,
appends
a
trailer
to
the
sine
data
and
then
the
0x04
octet
and
then
0xff,
and
then
a
four
octet
length
of
the
trailer
itself
that
was
appended
to
the
sine
data.
A
So
this
cannot
be
aliased
with
a
V3
signature
unless
the
V3
signature
was
of
type
0xff,
which
is
not
defined
for
V5,
which
we've
added
in
the
current
draft,
it
uses
an
8
octet
trailer
length
instead
of
a
four
octet
trailer
knife,
and
the
trouble
here
is
that
most
trailers
are
significantly
less
than
2
to
the
32
bytes,
which
means
that
the
fifth
octet
from
the
end
will
be
zero,
which
means
that
the
actual
sine
data
will
basically
be
a
time
stamp.
Will
look
like
a
V3
signature.
A
The
thing
that's
signed
can
be
transformed
into
a
V3
signature,
where
the
length
of
the
trailer
is
transformed
into
a
timestamp
and
the
signature
type
is
zero
is
possible
with
an
insane
signature
to
have
the
trailer
length
be
slightly
more
than
two
to
the
32
octets,
in
which
case
the
fifth
octet
from
the
end
would
be
a
one
which
would
Alias
to
a
V3
signature
of
type
1.
signatures
of
type
zero,
and
one,
of
course,
are
binary
and
text
mode
signatures.
A
So
so
this
is
an
issue
because
it
means
that
if
you
are
signing
things
with
what
are
currently
called
V5
Keys,
it
will
be
V6
keys.
Go
forward
with
that.
Your
signatures
can
be
transformed
into
a
subtly
different
signature
over
a
sorry,
a
V3
signature
over
subtly
different
data,
that
is
the
the
signed
data
and
the
trailer
will
be
merged
together,
and
it
will
look
like
a
V3
signature.
A
We
don't
know
what
the
consequences
of
that
would
be,
but
it
seems
like
not
a
great
property
of
crypto
system
if
people
are
still
validating
through
three
signatures.
So
the
proposal
currently
is
to
revert
the
five
signatures
from
using
an
ADOT
type
field
to
a
four
octet
field.
I
mean
that's
in
merger,
Quest
220..
A
The
result
would
be
that
the
0xff
D
aliases
V5
and
V4
from
B3
that
merge
request
explicitly
has
it
says:
You
must
not
Define
a
signature
of
time
0xff
and
you
must
not
validate
signature
of
type.
It's
your
xff
to
ensure
that
the
da
listing
works
and
yeah
and
there's
some
discussion
on
that
on
that
on
that
merge,
request
about
whether
this
is
safe
to
do
or
not,
in
the
possibility
that
a
trailer
is
greater
than
232,
octets
I
believe
there's
reasoning
on
there.
A
I
Hi
I'm,
just
wondering
I,
didn't
I,
didn't
see
anything
like
this
on
the
ticket,
but
I'm
just
wondering
the
dense.
Since,
as
Jonathan
said
earlier,
the
V5
signatures
are
already
implemented
in
the
wild.
Is
there
a
danger
of
her
being
here?
Let's
see
the
other
way,
so,
for
example,
it
can
can
we
ensure
that
nothing
created
using
the
current
draft
back
could
possibly
be
Alias
to
a
future
format,
including
V6,
potentially.
A
This
is
the
problem
with
implementing
pre-specified
things.
This
was
not
found
until
relatively
recently
any
signatures
that
are
made
by
the
implementations
that
use
the
unspecified
V5
are
indeed
aliens
equal
to
V3,
which
means
you
can
change
the
signature
type
to
a
binary
signature
and
just
have
a
weird
suffix
running
off
the
end
of
the
data.
I
Sure,
but
the
question
is
that,
given
that
it
is
already
given
that
that
horse
booted,
so
that
that
that's
kind
of
out
of
the
bag
already,
can
we
do
something
with
V6
and
future
keys
to
make
sure
that
whatever
has
already
been
implemented
as
V5
is
not
aliasable
to
B6
or
V7
or
whatever,
like?
Is
there
guidance
for
that?
So.
A
A
A
But
it
will
not.
You
know
the
specification
in
merge,
request.
220
explicitly
says
you,
you
know
this
is.
You
must
always
keep
the
fifth
octet
from
the
end
to
zero,
xff
and
sixth
octet
from
the
end
to
be
the
version
number
for
everything
above
version
three,
and
so
that
is
the
it
includes
explicit
documentation
to
Future
specifiers
how
to
avoid
the
aliasing,
how
to
avoid
the
aliasing
for
future
versions.
Does
that
make
sense.
A
A
A
C
D
C
I
mean
you
know,
I,
guess
it's
worth
checking
you
know,
I
mean
just
you
know.
Does
anybody
want
to
kind
of
speak?
The
you
know
require
more
time
or
you
know
it's
nothing
explained
sufficiently.
I
I,
as
you
know,
because
you
might
my
brain-
has
kind
of
unbuffered
everything
to
do
with
open
bgp
in
the
last
few
weeks.
So
I
understood
it
I
suspect
others
did
too
so.
But
would
you
give
people
a
chance
to
express
a
need
for
more
information.
A
Okay,
seeing
no
further
company,
we
got
positive
feedback
on
the
poll,
so
I'm
going
to
move
on
to
the
next
slide
here
so
yeah
with
the
length
of
the
salt,
so
Aaron
Whistler
raised
his
concern.
He
sent
his
his
regards
and
regrets
that
he
was
not
able
to
be
here
so
I'm,
hopefully
representing
these
this
proposal
correctly.
A
So
Aaron's
concern
is
that
someplace,
Quantum
algorithms
will
want
more
than
16
octets
of
salt
and
the
current
specification
for
the
V6
signatures
says
they
only
have
that
they
have
a
fixed,
60
knot.
Cuts
The
Proposal
here
is
to
bind
the
salt
size
to
that
hash,
algorithm
used
in
the
signature,
and
it
recommends
this
merge
request.
A
C
A
None
of
the
packets
currently
have
the
salt
size
embedded
in
them,
and
so
so
this
change
would
mean
that
all
current
signatures
are
yeah.
Signatures
that
have
been
made
from
current
implementations
would
not
be
valid,
because
the
first
octet
of
assault
would
be
treated
as
a
as
a
size
indicator.
Falco.
A
A
Don't
you
know
don't
do
this
and
then
all
the
signatures
would
by
definition,
fail
because
they
don't
match
the
recommended
hash
algorithm.
So
those
are
those
it
doesn't
seem
like
the
two
options
that
that
would
be
reasonable.
I
guess
you
could
also
do
a
zero
yeah,
but
that
doesn't
zero
feels
wrong
to
me
as
well.
So
I
think
I.
Think
your
proposal
is
is
one
of
the
two
reasonable
options
that
we
have.
D
A
C
Nonetheless,
but
every
additional
change
yeah
create
some
other
issue
that
somebody
raises
later.
That
causes
us
to
hit
an
infinite
Loop,
so
I,
I
I,
would
I
think
it'd
be
great.
If
people
support
indicating
making
this
wire
form
a
change
and
indicating
the
salt
size
I
think
that
if
they
speak
to
this,
supporting
that
I
think
that
would
be
useful.
G
C
C
A
The
so
so
far,
I'm
hearing
I
think
that
people
are
in
favor
of
indicating
the
salt
size
on
The
Wire,
specifically
for
the
reason
that
this
is
articulated,
they
I
don't
believe
anyone
is
objected
to
rejecting
signatures.
If
the
salt
size
on
The
Wire
doesn't
match
the
expected
size
for
the
algorithm
itself,
and
the
only
person
I've
heard
voicing
a
strong
opinion
that
he
has
maintained
on
this
all
test
for
deprecated
hash
algorithms
is
Andrew
Gallagher
for
not
applicable
Falco
suggested.
C
Do
we,
you
know,
is
that
something
that
other
people
agree
with
or
I
mean
I'd
like
you
know,
if
we
can
bottom
out
and
get
it
saying,
here's
that
if
we
can
just
say
that
you
know
this
enter
a
meeting
at
least
had
a
an
answer
that
was
acceptable
to
people.
That
would
be
good,
I
guess
I'm
asking
is
Andrew's
answer
acceptable
to
people
or
do
people
object
to
it.
A
Ready
I'm
gonna
run
a
poll
right
now.
You're
gonna,
raise
your
hand
for
choosing
not
applicable
and
you're
going
to
choose,
do
not
raise
hand
if
you
want
16,
octets
and
you're
not
going
to
choose
anything.
If
you
don't
understand
the
question
so
here's
the
poll,
the
salt
size
for
deprecated
hash
algorithms,
raise
your
hand
if
you
think
it
should
be
not
applicable
and
do
not
raise
hand
if
you
think
it
should
be
16
octets.
A
A
I
think
that's
a
pretty.
We
have
a
pretty
clear
sense
that
that's
the
way
forward
next
slide
here.
Contact
signatures,
context
parameter
for
signatures,
so
we
have
proposed
context
parameters
from
a
threat,
threads
started
by
Marcus
Brickman,
for
both
signing
and
for
encryption.
We've
been
going
through
signing
steps
here
and
I'd
like
to
focus
specifically
on
a
context
parameter
for
signatures.
The
next
slide
is
for
Conex
parameter
for
encryption.
D
A
I'd
like
to
focus
on
them
separately,
because
I
do
think
they're
separate
questions.
The
answers
might
be
the
same.
It
is
not
clear
to
me
whether
we
want
to
include
a
context
parameter
explicitly
here
or
not.
If
we
do
it's
not
clear
how
the
signer
who's
making
sure
knows
what
the
Codex
parameter
should
be,
and
yes,
V5
should
be
read
as
as
V6.
A
B
B
We
could,
if
we
want
to
make
if
we
want
to
bind
a
signature
to
a
specific
application
and
make
sure
it
can
be
used,
it
can't
be
used
elsewhere.
Then
you
could
add
a
critical
notation
data,
Supply
kit
and
then,
when
verifying
check
that
it's
there,
for
example-
and
we
have
some
support
for
that
in
our
implementations.
But
it's
still
a
very
manual
thing
that
you
have
to
do
right.
A
Thank
you
Daniel.
Can
you
speak
a
little
bit
to
how
that
would
work
with
existing
deployments?
My
concern
here
is
that
the
elevated
API,
you
know
the
more
visible
context
field,
as
you
said,
would
encourage
people
to
use
it
and
then
for
implementations
that
can't
decide
on
what
to
use
that
it
would
produce
interoperability,
failures,
signatures
that
could
not
be
verified
because
for
a
non-green
field,
implementation,
there's
no
consensus
on
what
the
what
the
value
of
the
context
parameter
would
be.
B
Out
right
so
I
think
it's
very
specific
to
each
existing
application
right
so
for
email.
There
was
this
concrete
proposal
to
add
a
header
which
would
signal
that
the
context
parameter
should
be
used.
Although
that
proposal
was
focused
on
encryption,
but
I
think
the
same
could
be
used
for
signing
right
and
then
for
other
applications.
A
Know
so
hold
on
the
header
would
signal
whether
the
context
should
be
used
for
that
message.
But
when
you're
composing
the
message
you
have
to
decide
whether
to
do
that,
so
there's
a
different
there's,
two
kinds
of
signaling
one
is
was
it
was.
It
was
a
context
perimeter
used
and
the
other
one
is,
should
I
use
a
context,
parameter.
B
Yeah
I
mean
you
might
so.
If,
if
we
build
this
parameter
in
to
V6
signatures,
then
you
would
at
least
be
able
to
know
that,
when
using
V6
the
the
implementation
has
to
support
it
right,
I
I'm,
not
necessarily
saying
that
that
automatically
means
that,
when,
when
using
V6,
that
means
that
you
can
use
it
in
like
every
existing
application,
but
that
that's
what
I
at
the
email
level,
that's
what
we
could
decide
right.
B
A
B
So
the
proposal
for
email
specifically
was
to
have
a
header
that
says
which
of
the
other
headers
to
put
there.
So
you
could
have
like
the
the
sender,
the
recipient,
the
the
date
header.
Maybe
the
message:
ID
I,
don't
know
exactly
what
they
proposed,
but
you
would,
you
know,
compile
those
let's
say
into
the
context:
parameter
right.
B
A
A
B
A
B
A
A
B
B
G
C
Well,
I
I,
just
as
a
slight
interrupt
I
think
we
started
we're
beginning
to
start
to
head
towards
going
around
in
circles.
I
think
I
think
I
understand
the
choice
here
myself,
so
I'd
be
interested.
If
other
people
wanted
to
weigh
in
like
I
understand,
dkg's
hesitance
I
understand
the
desire
that
Daniel
has
both
both
say
about
it.
F
C
B
It
it's
true
that,
technically
speaking,
we
can
already
do
that
using
notation
data
sub
packets,
but
I
I,
don't
agree
that
that's
a
better
solution,
also,
because
to
do
to
use
that
you
need
to
put
the
actual
context
string
in
the
signature
right
in
order
for
it
to
go
in
the
hash.
Whereas
here
the
idea
of
the
context
parameter
is
to
just
add
it
to
the
hash
directly
without
having
it
in
a
signature
packet
which
obviously
saves
bytes.
B
Okay,
that's
not
a
huge
concern,
but
the
the
other
risk
of
putting
it
in
a
notation
data
sub
packet
is
just
to
is
that
people
will
just
verify
the
signature
without
actually
knowing
what
the
context
is
right.
Having
an
actual
context
parameter
basically
forces
you
to
actually
compute
it
from
the
headers
or
whatever.
The
context
is
Right,
which
I
think
is
better.
C
Sure
and
and
I
think
that
the
the
the
tension
is
between
you're
wanting
that
context
parameter
essentially
out
of
band
in
order
to
make
cross
protocol
attacks
harder
versus
not
knowing
what
to
put
in
there
at
the
beginning
and
having
people
who
are
verifying
signatures
go
wrong
later
or
have
archives
of
signatures
that
no
longer
verify
right.
So.
C
C
I
Hi,
it's
okay!
This!
This
is
a
bit
left
field,
but
it
it
suddenly
occurred
to
me
there
listening
to
the
to
the
discussion
that
we
could
have
a
third
way
in
between
the
two
which
doesn't
specify
a
literal,
an
actual
contact
parameter
in
the
definition
of
the
signature.
But
we
use
the
notation
sub
packet
as
previously
discussed,
but
you
could
then
subsequently
mangle
the
signature
to
make
the
notation
sub
packet.
I
The
the
explicit
notations
are
back
in
the
signature
unreadable
and
then
you
would
have
to
reconstruct
that
again
using
a
similar
procedure
before
you
could
verify
the
signature.
Now.
That
would
be
that
that
probably
comes
Under,
The
Heading
of
abusive
spec,
but
I
just
thought
it
was
worth
throwing
in.
H
I'm,
not
clear
I
really
see
the
benefit
of
separate
context.
Packet
and
I
don't
understand
what
we
get
over
the
notation
sub
packet.
Now,
if
we
want
to
particularly
say
this
is
a
context
we're
using,
can
we
not
then
have
a
particular
flag
in
it,
I
think
from
looking
at
the
spec,
we
only
Define
human,
readable
and
the
notation
flag
registry.
So
why
can't
this
just
be
a
different
type
of
notation
right,
like
an
application
contact
or
something
under
the
existing
packet
type.
H
I
H
First
octet
of
the
notation
subpocket
would
lie
is
to
say
this
is
a
context.
I
mean
you're
getting
down
to
something
that
is
very
much
application
specific
right.
This
is
an
application
problem
really,
then,
a
protocol
level
problem,
so
you're,
relying
on
emitter
operation
from
all
applications
to
understand
that
hey
this
part,
this
this
signature
can
only
be
used
in
this
context
that
doesn't
feel
like
it
deserves
a
new
sub
packet
or
a
contact
parameter
on
it.
It
feels
like
it's
a
notation,
because
things
can't
ignore
it
right.
H
E
B
E
D
A
So
we
have
one
merge
request
that
actually
covers
both
of
these,
which
has
worked
for
Quest
214.
It
is
still
unclear
from
the
merger
Quest
how
a
signer
knows
what
context
parameter
to
use.
The
idea
here
is
that
encryption
and
decryption
would
require
economics
parameter
and
your
decryption
would
fail.
If
you
do
not
include
it,
and
this
would
be
for
seipd
version
2
encryption
only,
we
would
not
be
able
to
include
the
context
parameter
for
the
earlier.
You
know
already
specified
scitp
version
one.
B
Yeah
just
to
say
that
for
for
encryption,
there
is
currently
no
way
to
rigorously
provides
domain
separation.
Since
there's
not
an
equivalent
thing
to
the
to
the
notation
data
sub
packets
right
I
mean
there's
basically
no
way
to
get
something
into
the
additional
data
of
the
encryption,
and
even
if
you
put
something
in
the
body
there
there's
no
guarantee
that
I
mean.
However,
you
structure
the
body.
B
A
A
F
A
F
B
I
I
think
there's
a
sort
of
underlying
philosophical
question
here
about
who
is
open
pgpe
for
right?
Is
it
an
API
for
developers
or
is
it
an
API
for
end
users
or
another
API,
but
like
do
we
expect
indeed
users
to
take
a
signature
from
a
backup
application
and
then
manually
verify
that
open
pgp
signature
on
the
comment
line
or
with
with
some
open
HP
implementation,
or
do
we
primarily
want
to
design
open
BHP
as
as
something
that
can
be
used
by
applications
to
well
to
encrypt
stuff,
right
and
I?
B
Think
currently,
open
bgp
is
indeed
yeah,
maybe
more
focused
on
end
users
in
that
sense,
which
I
think
makes
it
a
poor
fit
for
applications
trying
to
use
open,
bgp
and
I
I.
Think
in
the
end,
if
applications
use
open
bgp
and
provide
the
the
interface
for
the
user
to
decrypt
our
data
and
so
on.
In
the
end,
I
would
say
the
the
usability
will
be
better
and
we
shouldn't
expect
users
to
take
out
the
signature
from
a
backup
application
and
then
manually
try
to
verify
it
somehow.
F
E
E
I
think
I
really
support
the
idea
of
having
a
context
because
it
defeats
some
very
yeah
dangerous
attacks
that
are
out
there
for
a
long
time
are
known
for
a
long
time
and
should
be
defeated,
but
I
think
it
should
be
something
that
that
is
optional.
I,
don't
think,
there's
a
way
to
introduce
this
a
solid
way
to
introduce
this
requiring
the
context
parameter
coming
from
outside
I.
Think
your
context
parameter
for
decryption
that
travels
with
a
message
would
be
a
at
least
for
phasing
in
and
maybe
permanently
would
be
a
good
idea.
G
C
C
A
C
C
Yeah,
so
you
know
in
the
next
you
know:
should
we
accept
this
marriage
request,
essentially
I
think
I
think
it's
it's
comes
out.
You
know,
there's
clearly
people
see
some
benefits
to
context
parameters,
but
introducing
them
is
tricky.
Maybe
we
don't
have
a
you
know.
Maybe
somebody
will
figure
out
a
great
way
to
do
that
introduction
a
little
bit
later
on.
C
Perhaps
I
can't
remember,
who
made
a
kind
of
a
third
third
suggestion:
I'm
gonna
fit
in
the
signature
discussion,
but
yeah
I
think
the
question
is:
should
we
do
this
now,
or
should
we
kind
of
leave
this
to
be
something
that
we
try
and
revisit
because
clearly
there's
some
interest
in
doing
it,
but
how
to
do
it
well
and
introduce
it?
Well,
it
seems
to
be
the
hard
part
yep.
B
C
Yeah
I
think
I
think
I
would
kind
of
agree,
except
with
one
part
of
what
you
said.
I
mean
I
think
it
is
true
that
introducing
these
kind
of
context,
parameters
in
email
is
is
hard
to
do,
but
it's
also
hard
to
do
in
the
general
case
as
we're
as
I
suggested
by
this
merge
request.
There
are
difficulties
associated
with
doing
it
now
as
well.
A
D
B
So,
if
you're,
assuming
that
the
key
is
only
used
by
one
application,
then
you
don't
actually
need
this
domain
separation
at
all,
because
I
mean
using
one
keeper.
Application
is
in
fact
another
way
to
achieve
domain
separation.
If
we
want
to
say
that
you
should,
you
should
only
use
one
keyboard
application.
That's
that's
also
reasonable
answer.
The
advantage
of
having
an
explicit
parameter
for
the
main
separation
is
that
you
can
use
the
same
key
that
you
fetch
from
wkd
for
different
applications
right.
F
So
you
said
you
can't
use
the
same
key.
That's
only
half
true
Daniel,
because
we
have
sub
keys,
and
then
we
have
key
capabilities,
and
one
thing
that
we've
been
thinking
about
a
bit
is
adding
different,
like
encryption
back
ends,
so
for
Matrix
or
for
MLS
or
or
age,
and
then
one
would
indicate
that
by
using
a
different
flag
and
the
what
do
they
call
the
key
key
capabilities?
Are
you.
F
A
C
A
A
Okay,
yeah.
Let
me
just
try
to
Praise
Jonathan
McDowell's
question
from
the
chat
as
well.
He
says
I'm
not
clear
if
the
intent
is
to
keep
the
data
secret.
Unless
you
know
the
context
or
just
prevent
an
application
from
decrypting
verifying
something
that
was
encrypted
signed
in
a
different
context,
so
Jonathan
I
think
the
goal
is
the
latter.
A
H
If
the
intent
is
application,
cooperation
and
ensuring
non-missuse
of
signed
data,
then
there's
absolutely
no
reason
why
the
over
the
wire
format
should
change
in
the
AED
should
change
a
notation
packet
that
the
application
pays
attention
to
achieves.
All
of
that,
if
there's
no
requirement
for
actual
inability
to
decrypt,
then
a
notation
pocket
in
the
harsh
signed,
harsh
area
I
think
achieves
all
this
unable
to
access
your
data.
Should
you
not
have
the
application.
A
I
think
for
signatures.
I
think
that's
the
case.
I'm
not
sure.
That's
the
case
for
encryption,
because
the
the
concerns
on
the
attacks
for
encryption
is
that
someone
can
take
a
message
that
was
encrypted
to
you
in
some
other
context,
feed
it
into
email
and
then
give
it,
and
then
your
mail
user
agent
encounters
it
and
does
terrible
things
with
it.
A
I
think
I
think
that
was
the
that
was
the
primary
place
where
the
increase.
That
was
why
I
sort
of
wanted
to
separate
out
kind
of
expenditures
for
encryption
from
county
square
numbers
for
signing.
They
behaved
differently
here
and
then
the
the
paper
that
introduced
this
was
specifically
concerned
with
exfiltration
of
exfiltration
of
clear
text
from
encrypted
data
based
on
flaws
and
existing
values
or
agents.
A
C
A
C
A
C
A
As
per
the
emerging
yeah,
so
should
we
add
iconics
parameter
to
P6
signatures
in
this
draft
without
any
specification
of
its
value?
Michael
Richardson
and
the
chat
says
since
this
is
a
new
version,
can't
we
say
that
the
previous
versions
have
an
implicit
email
context,
but
open
Michael
I'm,
not
sure
we
can
say
that,
because
I
think
openpgp
has
been
used
for
many
things,
other
than
email,
whether
it's
package
signing
or
backup
encryption
or
other
things
which
are
not
email.
C
A
C
C
D
A
A
Ksk
already
has
the
symmetric
algorithm,
so
that's
not
actually
being
hidden,
and
it's
known
outside
of
this
and
all
session
keys
are
block
size,
multiples
of
eight
octets,
so
there's
no
need
for
padding,
and
so
this
is
saying
look
when
we're
using
the
ecthq
app.
We
really
don't
need
to
stuff
all
this
other
stuff
in.
We
can
just
make
it
simpler
and
put
this
thing
in
that
makes
the
esk
slightly
smaller,
more
Compact
and
doesn't
introduce
room
for
potential
failures.
A
There
there's
no
additional
checks
and
calculation,
there's
no
potential
risk
for
a
symmetric,
algorithm,
mismatch
and
I'm
here
to
worry
about
the
Panic.
So
this
is
another
change
on
The
Wire.
If
we're
talking
about
changing
pksk
from
V5
to
V6,
there
will
be
changes
on
the
wire,
as
it
is
again.
I
hear
Stephen
Stephen's
point
that
this
is
not
necessarily
a
great
reason
for
making
other
changes,
but
this
has
been
proposed.
There's
a
merge
request
out
there.
B
B
We
wrap
which
actually
okay,
it's
a
bit
specific
to
our
use
case,
but
we
have
a
as
key
wrap
implemented
in
web
crypto,
but
only
that
we
could
use
with
the
new
format,
but
we
can't
with
the
existing
one
and
there
may
be
other
libraries.
That's
that's
offer
that,
although
I'm
not
sure
so
that
kind
of
simplifies
using
it
so
yeah
I
would
be
in
favor.
G
D
C
A
A
A
C
A
A
D
C
A
A
C
D
C
C
A
A
For
him
individually,
so
you
know
the
more
the
more
folks
can
step
up
and
make
sure
that
the
merger
quests
are
clean
and
that
they
can
confirm
that
the
merge
requests
that
they're
in
favor
of
are.
You
know
if
they
approve
of
them
that
they
work
the
easier
things
will
be
so
do
we
need
to
meet
in
ietf
116
Yokohama?
A
C
C
But
the
question
nonetheless
is:
should
we
do
we
want
to
meet
I
mean
there
are
a
couple
of
people
who
want
to
do
Post,
Quantum
things,
we
talked
about
context
parameters,
there's
a
bunch
of
things.
People
might
want
to
do.
I.
Think
dkj
and
I
had
a
call.
Yesterday
where
we
basically
said
we
have
to
make
a
request
for
a
meeting
slot
by
tomorrow.
C
Yeah.
It
seems
to
make
sense
to
assume
that
there's
enough
interest
in
rechartering
to
do
those
kind
of
the
known
things
that
people
want
to
do
to
make
it.
You
know
it
seems
to
justify
a
meeting
unless
a
bunch
of
people
are
going
to
say
no,
that
they
either
won't
be
physically
present
or
can't
participate
because
of
time
zones
or
something.
E
E
C
Cool,
so
can
I
suggest
that
just
in
we'd
like
to
get
done
with
4880
bits,
so
I
I
don't
want
to
disturb
that.
So
maybe
just
for
the
moment,
if
you
have
items
that
you
would
like
to
suggest
to
re-chattering
if
you
drop
a
mail
to
the
chairs,
we'll
collate
those
and
in
the
next
kind
of
you
know
few
weeks
before,
Yokohama
will
at
some
point
kind
of
post
to
the
list
to
to
list
those
things
that
people
have
suggested.
C
A
F
C
A
Yeah,
thank
you.
That
is
my
mistake
for
I
screwed
up
the
slides
and
lost
track
yeah,
so
I
posted
a
draft
of
designated
revoker
guidance
to
the
list.
Man
Paul
sort
of
picked
it
apart.
My
goal
of
posting.
It
was
not
that
I
thought
what
I'd
written
was
perfect,
but
was
just
to
try
to
get
people
talking.
So
all
at
least
had
some
critique.
If
not
concrete
suggestions,
that'd
be
great.
If
folks
could
weigh
in
on
what
they
think
is
the
right
thing.
There.
C
A
B
B
Thing
is
that
so
werner's
new
draft
that
I
think
he
published
this
week,
reps
out,
EX,
I,
think
and
purely
from
a
perspective
of.
If,
if
we're
looking
at
the
differences
between
werner's
draft
and
the
crypto
refresh-
and
we're
worry
if
at
some
point,
we
have
to
justify
those
differences
and
what
we
put
in
the
RFC,
then
it
might
become
difficult
to
justify
having
three
aad
modes
right
and
I
on
GCM.
There
has
been
a
lot
of
discussion
and
we.
B
B
C
So
I
guess
again,
that's
probably
one
to
take
to
the
list.
I
mean
I,
think
yeah.
It
is
lace,
even
if
we
have,
even
if
people
have
relatively
good
ideas
at
this
point,
we
might
be
better
off,
not
actually
new,
that's
a
possibility,
but
by
all
means
bring
bring
to
the
list.
The
other
point
I
would
make
is
that
kind
of
raises
the
prospect
of
the
working
group
being
vulnerable
to
a
denial
of
service
attack.
C
If
changes
are
made
just
to
to
werner's
draft
proximate
to
the
working
group
meeting,
and
then
we
react
to
those
every
time,
then
we
never
get
finished.
I'm,
not
saying
that
burner
is
trying
to
do
that.
I'm.
Just
saying
that
you
know
making
reactive
changes
in
that
way,
could
expose
us
to
that
risk,
and
so
I
guess
probably
want
to
bring
to
the
list.
I
think.
A
Dkg
I
I
I'm,
not
I,
don't
know
that
I
have
particular
perspective
on
that
I'm
I
am
worried
about
the
about
terminating,
but
I
agree
that
a
simpler
draft-
and
it
is
marginally
simpler
without
eax-
is
probably
a
little
bit
easier
to
review.
There
certainly
are
fewer
test
vectors
to
verify.
If
you
remove
one
of
the
axes
of
variation
but
I
I,
don't
really
have
a
and
we
we
have
reserved
code
points
in
there
for
things
that
have
been
specified
in
the
past.
A
That
are
no
longer
advisable,
so
it
could
be
doable,
but
if
you're
going
to
propose
it,
I
would
hope
that
you
make
it
clear
about
the
specific
changes
are
kind
of
the
easiest
thing
to
do.
There
would
be
there
if
you
think
it's
a
good
idea,
and
you
want
to
push
for
it,
have
a
very
clear
merge
request
that
people
could
consider.
C
A
B
C
B
C
No,
no,
no,
no,
no
I,
I!
Don't
think
we
should
be
doing
polls
for
here's
the
thing
we
might
do.
Should
we
do
it
it's
too
dangerous
that
we
end
up
with
people
saying
oh
yeah,
that's
a
good
idea,
and
then
we
end
up
not
finishing
at
all.
This
working
group
has
been
through
this
like
five
years
ago
or
whatever.
It
was
well.
B
C
A
B
A
I,
don't
think
that
we're
going
to
get
pushback
saying
given
there's
a
register
there
I,
don't
think
we're
gonna
get
pushback
saying.
Why
would
you
have
added
eax
here?
We
have
historical
reasons
for
having
added
it
and
you
know.
There's
a
registry
somebody
could
re-specify
eax
it's
it's
not
I,
don't
I,
don't
think
we're
going
to
get
the
pushback.
That
says.
There's
too
many
modes
here:
okay,.
C
I
I
I
think
we're
done,
let's,
let's
start
break
being
done.
If
there's
something
to
bring
to
the
list,
bring
it
to
the
list
by
all
means
please,
but
again,
only
if
you're
convinced
it
really
needs
to
happen.
It
really
needs
to
happen.
Now
it
doesn't
cause
a
you
know,
a
risk
of
the
working
group
never
finishing,
because.
D
A
Take
your
feelings
on
this
stuff
to
the
list.
We
do
want
to
make
sure,
even
if
your
feelings
are
like
yeah,
I'm
glad
we're
doing
this.
Let's,
like,
let's
move
it
along.
This
is
the
right
thing:
confirmation
on
the
list
that
shows
that
there
is
active
participation.
You
can
say
yeah
I
checked
these
test
vectors
against
my
implementation
and
they
check
out.
All
of
that
kind
of
confirmation
is
valuable
on
the
list
and
moves
Us
in
the
direction
of
completion.
So
please
do
weigh
in
that
way.