►
From YouTube: IETF96-OPENPGP-20160718-1400
Description
OPENPGP meeting session at IETF96
2016/07/18 1400
D
B
C
A
First
off
just
to
note
that
Barry
has
stepped
up
as
co-chair,
which
is
much
appreciated,
so
Christopher,
looting,
stop
is
stepped
down,
as
co-chair,
so
just
making
sure
that
really
knows
that
this
is
the
note.
Well,
if
you've
haven't
been
to
an
ITF
meeting
before
you
should
probably
read
this
note
well
and
note
it
well.
This
covers
the
intellectual
property
stuff
that
comes
up
in
the
meeting
among
others,
so
that
we
have
an
hour
and
a
half.
A
A
So
this,
basically,
is
the
original
RFC
4880,
with
some
integration
of
the
elliptic
curve
stuff
and
a
few
minor
changes
are
underway.
So
we're
going
to
do
more
than
minor
changes
here,
going
out
to
fulfill
the
Charter
discussion
happens
on
the
man
list
and
the
draft
is
currently
written
yeah
you
can
bring
it
up
front.
Thanks
draft
is
currently
written
in
markdown.
If
you
want
to
actually
proposed
changes,
we
welcome
concrete
proposals.
You
might
find
it
easiest
to
do
a
diff
from
the
markdown
or
you
can
just
send
the
words
to
the
mailing
list.
A
Please
use
that.
There's
a
git
repo
here
that
you
can
use
if
you
want
to
pull
the
draft,
but
discussion
should
happen
on
the
mailing
list.
So
you're
welcome
to
do
a
pull
request,
but
make
sure
then
that
you
make
a
copy
of
that
to
the
mailing
list
so
that
we
can
have
the
discussion
all
in
one
place
and
archived
by
the
ATF.
A
A
Or
even
necessarily
advisable-
and
we
have
a
very
limited
code-
point
space
because
of
the
way
the
registries
have
been
designed
in
arts
to
4880.
So
I
wanted
to
raise
these
raises
points
and
just
put
forward
a
concrete
proposal.
We
don't
have
a
specific
diff
for
this
at
the
moment,
but
just
a
concrete
proposal
for
one
one
approach
that
could
be
used
and
I'd
like
to
hear
feedback
on
the
proposal.
A
That
is
there
basically
7-bit
registries,
and
if
we,
sir
one
approach,
the
proposed
approach
is
to
loosen
up
our
control
of
the
registries
in
a
similar
way,
to
the
way
that
TLS
is
loosening
up
their
control
over
the
registries,
to
allow
code
point
assignment,
but
not
working
group
endorsement.
So
people
can
get
a
good
point
to
do
that.
We
would
need
a
larger
registry,
probably
than
the
seven
bit
registry
and
because
all
of
our
existing
registries
are
basically
seven
bit.
A
We
can
use
a
high
bit
to
indicate
that
actually
it's
a
two
octet
value
in
the
registry,
and
then
we
get
a
14
bit
registry
inside
of
a
7-bit
registry.
It's
sort
of
a
utf-8
ish
approach,
but
it
would
give
us
enough
space
that
we
could
do
a
first-come,
first-served
and
not
have
to
argue
on
the
man
list
about
whether
we
get
code
point
assignment
or
not.
A
E
So
the
reason
TLS
had
to
go
that
way
is
that
they
made
the
mistake
of
using
sweets,
and
that
means
that
they
don't
have
so
much.
Flexibility
I
would
rather
have
a
divide
between
stuff.
The
ITF
cares
about
and
everything
else.
I
would
like
everything
else
to
be
as
far
away
from
IETF
and
I
honor
as
possible,
so
rather
making
changing
the
registry
in
this
way,
mayra
suggests
is
have
one
additional
code
point
which
would
be
eating.
E
The
algorithm
is
specified
by
annoyed
and
then
stick
the
oil
in
some
part
of
the
packet
or
whatever,
that
you
don't
care
about,
and
the
reason
that
you
do.
That
is
that
then,
since
anybody
can
get
annoyed,
you
know
anybody
can
have
and
I
have
a
narc.
Komodo
has
narc
as
well.
I
mean
like,
in
fact,
I
have
more
than
one
arc.
E
That
puts
the
tagging
of
the
crypto
completely
outside
the
ITF
process
and
means
that
people
can't
come
round
and
say:
oh,
my
algorithm
has
been
blessed
by
the
ITF
and
you
know
and
I
know
that
we
can
say
that
we're
not
implying
endorsement,
but
you
know
neither
that
every
time
we've
done
that
in
the
past
the
people
who
get
the
code
points
then
immediately
go
out
and
their
marketing
dept
say.
This
is
ITF
endorsed
that
we've
got
a
code
point.
E
So
that's
a
way
that
you
completely
isolate
all
the
vanity
crypto
from
the
stuff
we
care
about
and
also
if
we
ever
get
to
the
point
where
we've
used
up
126
remaining
code
points.
Well,
we've
got
a
natural
expansion
thing
and
you
know
what
I
don't
think
people
are
going
to
care
about
how
long
odds
are
or
whatever
or
interpreting
them.
By
the
time
that
you
run
out
of
126
slots.
A
G
Steam
Farrell's,
just
as
a
random
participant
I'm,
not
convinced
if
there's
argument
that
that
would
work
so
well
because
I
mean
I,
think
marketing
departments
can
make
any
claim
they
wanted.
They
will
so
I
mean
who
could
do
that
way?
I
guess
would
probably
work
the
TLS
kind
of
copying.
The
TLS
approach
seems
like
better
understood
thing
unless
you're
convinced
that
fills
arguments
correct
I'm
personally,
not
and.
B
H
I
F
Parker's
so
yes,
we
have
done
this
in
ipsec,
where
we
can
now
use
an
oid
to
decide
what
algorithm
to
use,
but
that
is
a
a
life
happening
right.
I
am
talking
to
remote
surf
and
I
immediately
going
to
decide
whether
or
not
I
am
going
to
find
that
algorithm
acceptable
or
not
with
PGP.
It's
a
little
different.
If
I
need
to
sign
something
or
or
encrypt
something,
and
then
you
know
hours
later,
someone
else
decides
well
actually
I,
really
don't
like
the
bell.
Riddim
then.
E
For
hamburger,
good,
but
part
of
the
idea
here
is
that
it
avoids
the
need
to
have
yet
another
registry,
and
so
when
you're
writing
the
code,
you
know,
because
virtually
every
crypto
library
already
has
a
mechanism
for
here's
annoyed.
Give
me
the
algorithm
that
map's
to
that
I'd
or
I'm
using
an
algorithm,
tell
me
the
oil
of
the
algorithm.
If
you
create
another
registry,
then
that's
another
set
layer
that
I
have
to
put
in
my
coat
now.
E
Obviously,
if
somebody
wants
this
stuff
to
actually
be
interoperable,
then
they're
going
to
have
to
write
a
draft
as
minimum.
However,
my
view
is
that
if
somebody
wants
this
to
actually
into
our
f
/
8,
they
had
better
be
using
something
that
is
in
the
man
interment
or
the
very
strongly
recommended
by
ITF
route,
or
else
it's
not
going
to
work
anyway.
So
to
be
clear,
the
original.
A
Proposal
did
not
indicate
any
creation
of
any
new
registries.
It
indicates
that
we
should
have
columns
in
the
registry
indicating
working
group
approval
and
mandatory
to
implement,
but-
and
it
increases
the
size
of
the
registry
so
that
we
are
able
to
do
first,
come
first
serve
without
depletion,
but
note
none
of
the
proposals
that
on
the
table,
busfare
have
indicated
the
creation
of
a
new
registry.
Well,.
E
A
H
A
Okay,
so
the
less
tricked
from
TLS
is
this
outline
here.
This
is
in
the
slides
I'm
not
going
to
go
over
it
in
full
here,
but
basically,
everyone
who
comes
to
the
IETF
without
without
needing
to
get
working
group
approval
in
this
proposal
would
get
sort
of
first
come
first
serve
gotta
get
a
code
point
assigned,
and
they
could
do
that
through
the
for
all
others
section
just.
A
A
I
I
I
B
K
I
I
A
I
Anyone
questions,
okay,
the
other
thing
is
on
that.
That's
also
pretty
easy
arm.
We
have
in
technet
your
packets
in
turn,
signature.
We
have
the
wrong
key
ID,
so
64-bit
key
ID
are
to
find
pick.
The
key
for
verification
about
64-bit
key
IDs
are
too
short
to
really
find
the
keys,
because
we
can
easily
create
creations
on
the
64
bits
and
that's
a
bit
annoying
and
actually
dangerous.
If
you
always
get
bad
signatures
with
your
ronke
arm.
I
There
is
a
proposal
that
we
put
the
fingerprint
into
an
new
signature,
subkey
a
sub
packet
and
very
similar
to
the
to
the
issue,
a
pocket
with
the
64-bit
key
ID,
and
this
would
fix
our
problems.
There's
a
proposal
there
on
the
mailing
list
and
also
in
the
issue,
tracker
arm
and
I
hope
that,
with
new
Kieffer
matter
later,
we
can
fade
out
the
use
of
the
issuer's,
a
packet
which
needs
to
stay
currently
in
openpgp
data
for
back
compatibility.
But
it's
no
problem
for
implementation
of
our.
I
I
Okay,
fine
iron
yeah!
We
recently
talked
about
the
thing
which
would
be
nice
to
have
its.
It
is
another
encryption,
sub
packet
arm
called
encrypted
to
arm,
which
is
used
to
put
the
recipient
keys.
So
if
you
sign
and
encrypt,
then
you
can
put
the
recipients
of
to
whom
you
encrypt
it
into
the
signature.
So
after
the
the
encryption
layer
has
been
stripped
off,
they're
still
the
signature
and
everyone
can
see,
I
can
check
to
whom
it
was
originally
encrypted
arm.
I
B
I
B
I
Well,
lady,
I
said
I
sang
I
sent
you
and
signed
and
encrypted
encrypted
mail
yeah
and
you
decrypt
it
but
keep
the
signature
layer
and
for
me
and
then
you
send
it
encrypt
it
to
someone
to
someone
else.
Well,
let's
say
to
the
NSA
or
so
Noah's
Georgia
newspaper
and
but
then
they
can
detect.
Okay,
it
has
originally
encrypted
for
for
you,
and
so
it
is.
It
was
legitimate
that
you
are
send
it
forward
again.
I
A
A
I
I
I
Of
course,
it
should
still
be
possible
to
have
on
mon
encrypted
piece
the
s2
case,
I
used
to
on
our
encrypt
keys
or
protect
secret
keys
and
also
for
the
asymmetric
encrypted
integrity.
Packard's
data-
if
you
just
encrypt,
prefers
to
mate
review
before
pass
place.
Yes,
I
get.
There
are
questions
or
comments.
I.
G
I
G
L
Kind
of
work
I
had
basically
the
same
question.
I
want
to
clarify
that.
Do
we
want
to
wait
till
see
if
audrey
has
produced
an
RFC
for
argon
to
or
because,
as
far
as
I
remember,
but
I
don't
recall
you
exactly-
there
was
a
paper
with
attacks
on
our
12
I
and
there
were
some
debates
whether
the
algorithm
should
be
changed
to
counter
that
attack.
So
it
may
be
that
something
else
ends
up
as
being
the
standardized
are
going
to
then
what's
out
there
now
so.
A
A
G
I
mean
I
I,
don't
know
if
the
changes
that
have
been
considered
in
are
going
to
I
or
affecting
drop
or
if
they're,
just
parameters
that
you
can
tweak
anyway
and
so
I
think
yeah
talking
to
the
safe
orgy
folks
is
a
fine
thing
to
do,
but
you
can
also
sort
of
say
to
them.
We
want
an
argon
to
I
Oregon
to
RSC.
You
know,
please
don't
sit
on
this
for
years
and
you
know
it.
We
don't
want
you
to
you
know
it's.
G
I
Okay,
so
are
we
have
a
lot
of
algorithms
and
open
PGP
and
here's
a
suggestion
now
what
your
duplicate
are.
My
thing
p:
if
our
triple
gases
are
interesting
because
it's
the
only
must
algorithm
in
openpgp
currently
are,
but
that's
old,
that's
nearly
20
years,
20
years
old,
that
we
have
it
in
open
PGP,
and
this
should
be
and
is
in
reality,
it
has
been
replaced
by
a
yes,
so
they're.
I
Actually,
the
implementations
which
do
which
don't
even
implement
Triple,
DES,
so
I
think
it's
our
it's
pretty
okay
to
remove
triple
triple
des
md5
it
just
it's
obvious
a
sha-1.
We
also
need
to
duplicate
this
for
obvious
reason
because
of
the
ITF
and
because
we
want
to
use
it
in
a
few
years
so
arm.
That's
all
I
also
suggested
to
remove
char
224
because
it
doesn't
really
fit
it,
thereby.
Why
do
we
need
for
4i
rhythms
and
implement
implement
them?
I
So
it's
it
doesn't
make
much
sense
to
have
this
one
on
the
other
is
right
in
the
160.
It's
not
really
used
and
there's
two
fish,
which
is
actually
a
good
cipher
later
and
128-bit
block
length
is,
it
would
be
okay,
but
why
should
we
used
to
fish?
There
is
no
sound
reason
for
this.
It's
slower
than
other
things.
We
meet
a
lot
of
co2
to
implement
this,
and
so
it's
it
doesn't
make
sense.
Blowfish
for
obvious
reason:
it's
it's
too
old,
it's
yeah
arm.
I
It
might
also
be
useful
to
think
about
whether
we
are
whether
we
allow
arbitrary
length
of
far
as
a
keys,
because
some
implementations
can't
can't
handle
arbitrary
length
you
soon.
This
is
nothing
we
probably
can
can
discuss
right
right
now
here,
but
this
is
stuff
for
the
mailing
list
to
discuss
this.
Are
this
point?
The
last
point.
I
Anyone
want
anyone
wants
to
keep
one
of
the
old
algorithms.
No,
this
tragedy,
a
suggestion
for
the
strategy
is
that
we
have
classes
of
duplicated
algorithms
and
parameter
barriers,
so
there
will
be
a
must,
not
implement,
which
is
definitely
md5,
and
the
other
thing
is
that
we
need
to
have
some
are,
are
back
compatibility
for.
We
need
to
be
able
to
decrypt
our
data
so
arm.
G
I
G
A
I
Maybe
the
next,
oh
ok,
here's
re
are
here
to
profiles.
We
we
came
up
with
so
the
first
one
is
called
the
strong
proposal
arm
what
to
do
what?
What
are
mandatory
to
implement?
Algorithms
are.
The
stronger
browser
includes
a
idea,
cipher
mode.
It
has
not
yet
specified.
We
don't
know
which
one
this
will
be,
but
it
is,
it
will
be
a
must.
Then,
taking
this
a
is
256
and
shall
545
12,
ok
and
the
other
thing
is
the
new
on
82
5519
curve
for
signatures
arm
will
miss
them.
I
We
miss
the
phone,
we
missed
something
we
don't
have
anything
for
encryption
valve
cousin,
so
that
the
255
19
or
was
it's
called
extra
250
19,
which
the
logical
extension
for
this
for
encroaching
on.
This
is
the
one
proposal
on
the
other.
It
seemed
more
competitive
proposal
arm,
which
also
includes
a
Eid
and
but
the
lower
key
sizes
for
a
fasn
fasha,
but
also
eros
eros.
A
that
errors.
A
is
the
manager
to
implement
algorithm.
I
Yeah
I
think
we
should
choose
one
so
because
they
are
mandatory
to
implement
and
I.
Don't
think
it
makes
much
sense
to
require
implementations
to
implement
both
of
them
so
they're.
There
are
certain
reasons
why,
for
example,
the
shower
512
is
a
good
candidate,
even
if
it
is
slower
on
embedded.
Machines
are
because
you
need
to
use
this
for
ED
2519
anyway
arm.
I
G
E
L
Hannah
book,
but
the
post
quantum
thing:
if
we
look
at
the
symmetric
part
of
this,
if
we
choose
the
strong
proposal,
we
basically
have
that
already
covered,
because
as
soon
as
you
go
to
a
500
256-bit
security,
you
have
reasonably
post
quantum
security.
So
if
we
want
to
be
forward
looking
for
postpartum
security,
we
could
say
if
it
was
the
strong
proposal.
That's
there
on
the
slide,
then
we're
already
like
halfway
done
and
the
only
the
asymmetric
part
that
has
to
be
done.
G
B
It
seems
likely
to
me
that
new
implementations
that
are
looking
for
what
they'll
receive
would
would
accept
older
stuff
to
be
compatible.
But
the
issue
is
what
happens
when
they
generate
things:
they're
going
to
generate
stuff
that
older
clients
camp
decrypt,
because
they
they're
using
newer,
algorithm
yep.
But.
I
G
G
I
Ok,
the
other
thing
is
the
fingerprint
to
the
fingerprints.
Kadri
are
based
on
the
sha-1
edges,
and
this
needs
to
be
replaced
that
there's
a
second
point
of
transformation,
mitesh
algorithm
to
use
a
router
user,
how
to
construct
the
fingerprint
and
the
other
thing
is
armed,
whether
to
include
the
creation
time
of
the
key
into
the
fingerprint
on.
This
has
been
discussed
on
the
mailing
list
of
several
times
and
long
threads,
whether
to
whether
that's
a
good
idea.
It's
not
a
good
idea
arm.
I
Another
point
is
that
well
that's
more
kind
of
a
remark
that
we
can
expect
that
keys
are
larger
than
64
K
for
post
quantum,
and
currently
we
for
the
fingerprint
rehash
only
a
2-byte
length
of
the
of
the
key.
So
this
needs
to
be
this
should
in
any
case
we
extend
it
to
24
24
by
it,
so
that
we
have
something
clear
and
don't
need
to
drunk
at
something.
Ok.
So
the
proposal
here
is
something
that
we
don't
put
the
creation
time
in
into
it.
On
that
we
use
sha-512
arbitron
cated
to
200
bits.
A
So
we
had
a
lot
of
back
and
forth
and
bike
shedding
on
the
man
list
about
the
fingerprint
format
and
it
never
seemed
to
reach
any
sort
of
conclusion.
So
I'm
not
sure
how
we
move
forward
in
terms
of
actually
going
with
something,
except
that
we
know
that
we
want
to
move
past
the
existing
implementation.
So
I
don't
know
anything
that
can
get
us
towards
a
consensus
would
be
great
in
my
book,
but
I'm
not
sure
what
the
right
way
to
do.
That
is.
A
I
mean
what
what
what
what
happens,
Steve
and
I'll,
ask
you
as
ad
what
what
what
would
happen
if,
if
there
is
no
connect,
if
there's
four
competing
proposals
for
fingerprints
and
none
of
and
no
one
can
agree
on
them,
I
mean
I.
Think
it's
I
think
we
have
decided
that
we
want
there
to
be
exactly
one
format
for
a
finger
friend.
E
I
feel
hun
Baker
well,
one
way
that
you
can
resolve
this
sort
of
thing
is
to
add
more
requirements
until
you
constrict
to
knock
out
candidates
that
don't
work
so
right,
if
you,
if
you
have
three
people
who
are
saying
well,
I,
want
it
to
be
like
this
because
well
I,
just
like
it
that
way,
and
then
you
have
another
person
who
saying
well.
I
want
to
be
like
this,
because
I
would
like
the
same
fingerprint
format
for
ssh
and
PGP
and
s/mime,
and
everything
else
that
we
want
to
do.
A
E
J
I
So
your
proposal
is
that
to
explicitly
actually
some
more
stuff
with
their
with
it
was
the
key,
but
only
hash
as
and
not
put
anything
else
in
to
the
key
packet
for
this.
So
implicitly,
we
do
this,
though
the
fingerprints
created
for
openpgp
are
different
for
fingerprints
for
and
any
other
protocol,
because
you're
the
meter
data,
what
we
exchanged
our
anyway
different,
but
you
just
want
to
have
the
string
open,
PGP
hash
with
it
I
can't
exactly
remember
the
UDF
okay,
whatever
so
it's
just
hazard
another
string.
So
we
already
have
a
couple.
I
And
the
rationale
for
using
shower
55
12
is
on
that
we
needed
for
eg
2519
anyway,
so
the
implementation
and
yes,
it
is
slower
on
embedded
machines
and
Peter
Goodman
doesn't
like
it.
For
this
reason,
but
well,
modern
machines
is
actually
faster.
So
it's
for
small
implementation,
it's
probably
easier
to
use,
shot,
flattener,
12
and
truncate
it
to
a
reasonable
size.
C
E
So
you've
got
an
upgrade
pack
if
you
ever
choose
to
need
them
as
far
as
I'm
concerned,
though,
if
openpgp
was
to
say
we'll
use,
your
fingerprint
must
be
sure
to
512
that'd,
be
fine
with
me,
I,
just
like
backup
algorithms,
but
I
like
to
have
exactly
two
algorithms
for
everything,
I
like
to
have
one
that
I'm
going
to
use
and
one
that
I
might
have
as
a
backup.
I
do
not
like
having.
A
Three
so
I
think
in
ITF
95
there
was
a
rough
consensus
in
the
room
that
we
wanted
there
to
be
exactly
one
fingerprint
per
key.
So
if
you
have
a
v5
key
that
there
should
be
one
fingerprint
for
it,
so
that
if
I
give
you
a
fingerprint,
you
just
had
to
compute
the
fingerprint
you're
guaranteed
to
end
up
with
the
same
thing
yeah
so
so
having
two
fingerprints
for
a
single
key
seems
to
violate
that
decision.
E
What
I've
been
doing
strike
weren't,
trying
to
work
out
a
profile
that
will
allow
me
to
use
the
same
fingerprint
method,
to
identify
roots
of
trust
in
different
formats
and
use
the
same
fingerprint
format
and
have
an
happen
how'd
it
be
unambiguous.
If
openpgp
wants
to
say
okay
we're
only
going
to
allow
the
512
the
shower
to
version.
That's
fine
with
me.
E
Other
people
might
have
a
requirement
for
something
else:
I'm
just
trying
to
future
print,
improve
the
format
so
that,
if
it
needs
to
change
in
the
future,
I
mean
the
thing
is
at
some
point:
it
is
possible
that
shower
too
may
be
deprecated
and
then
you've
got
a
question
of
how
do
you
distinguish
between
the
old
fingerprints
and
the
new
right
now,
nothing
that
I'm
doing
is
using
to
the
shower
3
version,
because
there
isn't
even
code.
That
does
shot
three
foremost,
so
that
would
be
a.
E
A
E
K
G
I
A
Yeah
there's
actually
another
mic
comment
so
relaying
for
a
derrick
which
I
think
is
derrick
Atkins.
He
says
I
believe
that
the
creation,
time
and
expiration
time
should
be
included
in
the
fingerprint
computation
in
order
to
prevent
an
attacker
from
taking
my
public
key
and
creating
a
new
certificate
around
it
and
causing
confusion,
granted
an
attacker
copy
the
two
times
as
well,
but
then
they
cannot
modify
the
expiration
time
and
maintain
the
fingerprint.
A
So
as
a
participant
I
will
comment
on
this
that
currently,
the
expiration
time
is
not
actually
included
in
the
fingerprint.
There
is
an
expiration
time,
but
that's
not
the
one
that
anyone
uses
as
far
as
I
can
tell,
and
they
can
take
a
given
key.
If
it's
someone
has
your
secret
key,
they
can
reuse
it
in
other
places.
So
I'm
not
Derek
I'm,
not
entirely
sure
that
that
is
a
change
from
the
existing
situation
and
I.
I
Haven't
heard
of
anyone
doing
that
kind
of
attack,
we
don't
have
an
exploration
time
in
the
key
is
in
the
same
signature
and
it's
an
old
proposal
to
put
it
back
into
the
exploration
time
back
into
the
key
packet,
because
this
what
the
case
in
PGP
to
but
the
original
before
director,
the
guy
who
proposed
that
L
mean
but
has
no
interest
in
this.
So
all
we
discuss
it.
A
A
I
So
we
have
these
mgc
arm
modification
detection
code,
and
this
is
supported
by
a
flag
in
the
news
in
a
special
feature,
sub
packet,
which
has
only
the
flag
support,
MDC
arm,
which
is
basically
a
preference
that
implementations
understand,
MVC
and
to
advise
other
implementations
to
use
the
MVC
feature
arm
for
our
the
forthcoming
a
eid
thing
arm.
We
would
add
another
flag,
support
a
ID
very
similar
to
md
to
mbc
arm,
but
also
for
version
5
keys.
So
with
the
new
fingerprints.
I
These
new
keys
arm,
we
would
say,
must
not
use
future
packets
because
arm
they
should
also
you
always
use
a
EIG
done,
because
it's
a
new
keys
and
for
new
kitchen
is
need.
New
implementations
and
the
new
agreement.
Ations
can
use
the
arm
modern
thing
aig,
and
then
we
can
get
rid
of
the
feature
sub
packet,
which
is
well.
You
can
lose
this
very
same
with
notation
of
notations
rotations,
notation
signature
sub
packets
on
so
I
don't
see
a
reason
to
have
this
feature
package
creep
there.
A
I
Yeah
so
authenticated
encryption
of
additional
data
arm.
There
is
a
proposal
they're
using
a
ESN
in
GCM
mode,
and
that's
a
concrete
proposal
for
this
other
is
to
use
OC
OC
b
OC
b
seems
to
have
a
problem
with
patterns
for
some
people.
So
we
don't
know
so
it's
what
we
can.
We
are
pretty
sure
that
we
can
get
an
exception,
for
this
are
similar
to
what
rug
of
a
gift
for
TLS
arm.
I
There
is
also
the
option
to
allow
both
of
them
to
have
a
flag
which
is
supported
them
to
have
two
versions,
and
the
other
question
is
whether
it
needs
to
be
streamable
so
that
or
what
is
called
on
an
online
algorithm
are
that
he
can
can
use
it
streamable.
There
are
also
some
newer
and
developments
so
poet
a
set
on
the
LMD,
so
I
myself,
don't
know
them
exactly
so.
That's
arm,
that's
all
open
for
discussion
now
or
for
long
time.
I
K
A
I
Okay,
I
already
already
mentioned
this
there's
a
problem
in
the
little
data
packet
which,
as
a
long-standing
problem,
we
have
the
file
name
in
the
little
data
packet
are
and
the
Phi
creation
time
about.
You
can't
use
it
because
it's
not
protected
by
the
signature-
it's
of
course
protected
by
the
encryption
layer
but
our,
but
you
can
just
modify
these
flags
also,
the
the
file
tech,
whether
the
binary
or
whether
it's
but
the
proposed
new
mime
thing
or
text
a
unicode
arm
thing.
I
That's
not
that's
not
good
to
decision.
So
the
idea
is
to
have
a
are
to
find
a
new
signature,
class
or
signature
class
are
the
things
we
have
for
signature
class
0,
which
is
binary
binary
data
signature
class
1,
which
is
a
text
from
the
data
which
definitely
a
little
bit.
Different,
is
complicated
thing
like
a
cannoli
realization
of
line
endings
and
by
trailing
whitespace
removal
and
the
things,
and
the
idea
is
to
define
a
new
signature
class
arm
which
I
just
ashes
everything
in
the
little
data
packet
on
budgets.
I
A
I
I
A
A
I
A
So
normal
question
John
that
I
wanted
to
just
talk
briefly
about
the
PGP
mine.
That's
mine,
discussion
that
we
had
on
the
mailing
list
about.
There
was
a
proposal
I
think
about
merging
them.
I
want
to
explain
why
I
think
as
a
chair.
This
is
probably
not
appropriate
to
do
in
this
working
group.
So
I
think
there's
two
things
that
p-gp
my
man
s,
my
I'm
do
there's
message
formats
and
there
are
certificate
formats.
If
we're
talking
about
message
formats,
that's
a
separate
RFC
from
4880.
A
We
are
chartered
specifically
with
revising
4880,
so
I'd
like
to
not
get
into
revising
3156.
If
we're
talking
about
certificate
formats,
I
think
it's
pretty
clear
that
we're
not
going
to
adopt
x509
directly
within
openpgp.
If
somebody
wants
to
propose
text
concrete
text
that
allows
you
to
say,
derive
an
x.509
certificate
from
openpgp
certificate,
or
vice
versa,
and
that
text
doesn't
lay
the
work
of
the
working
group
and
it's
something
that
straightforward
to
implement.
I.
Think
that's
fine,
but
I.
A
A
I
A
E
A
A
B
I
B
B
B
I
I
A
A
C
M
K
J
G
Think
yeah
I
wish
I
would
be
totally
supportive.
You
guys
try
to
close
down
city
descriptions,
I
mean
I.
Think
if
there's
a
bunch
of
these
things,
I,
don't
think
people
really
care
that
much
they're
just
arguing
it's
it's
a
good
definition
of
my
chair.
Yes,
the
OCD
when
I
think
it
might
be,
but
a
few
words
is
going
to
be
there
Marcus
I,
don't
nobody
else
has
done
they
are
they.