►
From YouTube: IETF95-OPENPGP-20160406-1000
Description
OPENPGP meeting session at IETF95
2016/04/06 1000
A
C
A
E
B
G
F
F
Okay,
folks,
this
is
going
to
be
open,
PGP
working
group.
If
you're
here
for
openpgp,
please,
why
don't
you
come
up
towards
the
front
rows
if
you're
not
here
for
openpgp?
Why
don't
you
get
the
get
out,
so
you
can
have
a
conversation
that
doesn't
interrupt
our
conversation,
not
trying
to
send
people
away
we're
happy
to
have
people,
but
extra
conversations
in
a
room
like
this
are
difficult.
So
so
Neil's
are
you.
F
Neil's
is
no
ticking,
so
I
need
someone
to
be
a
jabber
scribe
and
the
jabbers
crab
roll
gonna
be
slightly
more
complicated
here.
So
can
I
had
some
you
to
volunteer
for
it
and
then
I'll
tell
you
why
it's
complicated
or
should
I
tell
you
why
it's
complicated
first.
Thank
you
rich.
The
complication
is
that,
if
possible,
you
could
monitor
the
deprived
jabber
channel
as
well
as
the
open.
Pgb
divert
general
because
of
the
me
dekho
confusion
here.
F
F
F
So
the
agenda
is
relatively
short.
Hopefully
people
have
other
suggestions,
I'm
happy
to
add
them
to
it.
I
want
to
point
out
the
RC
4880
pissed
that
Verner
has
has
produced
I
want
to
see
when
we're
going
to
look
at
that.
There's
a
bit
of
terminology
review
that
rich
salts
and
Robin
Wilton
did
and
I
want
to
ask
other
people
to
maybe
think
about
that
as
well
questions
about
s2k.
We
had
had
some
discussion
some
agreement,
but
we
haven't
had
much
progress
on
it.
F
F
Okay,
so
so
on
the
4880
biss,
we
have
a.
We
have
a
draft
from
verner
call
the
the
the
draft
basically
starts
from
4880
and
has
been
so
far
incorporating
existing
extensions
that
have
already
been
agreed
into
that
so
sort
of
assembling
it
into
one
more
modern
piece
who
here
has
looked
at
the
this
version:
2
of
the
48
abyss
that
verner
posted
okay,
not
too
many
all
right.
So
I
can
do
a
quick
review
of
what
the
changes
have
been
so
far.
We've
they've
included
Derek
Atkins
proposed
notations
for
device-specific
openpgp
certificates.
F
F
The
discussion
should,
as
usual,
take
place
on
the
mailing
list,
but
this
is
one
place
that
you
can
record
things
if
you
want
them
to
go
as
a
you
know,
as
a
sort
of
issue
tracker,
so
there's
issues,
tickets
and
pull
requests,
and
things
like
that
there.
So,
if
you're
interested
in
a
particular
subset
of
what's
going
on
in
openpgp,
I
want
to
encourage
you
to
clone
that
git
repo,
its
marked
on
text
thing,
you're,
probably
interested
in,
is
called
middle
mkd.
F
F
Anyone
have
any
other
concerns
about
the
next
steps
on
the
Ford
8048
Eddie
biss.
One
question,
I,
guess,
is
whether
we
should
adopt
this
in
the
working
group,
which
this
seems
to
be
the
only
candidate
that
we
have
448
abyss
which
seems
like
it
would
make
sense
to
adopt
it
as
a
working
group
document.
F
But
given
that
almost
nobody
in
the
room
has
read
it
yet
and
given
that
there
haven't
been
any
radical
changes
in
it
yet
I
don't
know
whether
that
makes
sense.
Maybe
folks,
with
more
IETF
process,
can
can
fill
in
the
gaps
here.
Does
it
make
sense
to
say
we're
adopting
this
and
then
just
going
ahead
and.
F
G
F
I
F
Yeah
so
I
really,
it
would
be
really
great
if
we
could
get
some
people
to
just
look
over
the
specific
changes
if
you're
into
reading
revision
history,
instead
of
trying
to
read
the
whole
thing
if
you've
read
all
of
openpgp,
if
you've
read
4880
before
this
really
is
for
dat
with
some
changes
with
some
integration,
there's
nothing
radically
different
there.
But
I
encourage
you
to
just
skim
the
change
history,
see
what
you
see,
what
you
think
of
it
and
a
gift
feedback
on
the
list.
F
So
I
want
to
thank
them
first
off
for
doing
that,
and
I
want
to
also
encourage
people
to
do
this
kind
of
review
and
do
it
on
list
where
possible,
because
I
think
we
could
the
there's
a
question
here
about
how
much
of
the
terminology,
rich
I,
think
actually
had
a
point
saying
that
the
terminology
that's
used
in
the
open.
Pgp
draft
is
not
exactly
it's
like
open,
PGP
terminology,
but
it
doesn't
necessarily
line
up
with
the
same
words
that
we
use
for
similar
concepts
elsewhere.
F
H
You
yeah
sure
the
things
like
both
terms
and
aren't
you
get
rich
songs
are
combined.
There
are
terms
that
aren't
used
like
rapped
keys
and
talk
about
objects
instead
of
like
folk
encryption
keys
and
things
like
that.
So
there's
lots
of
almost
every
term
dates
back
to
the
original
days.
So
those
are
the
two
that
come
to
mind
off
hand
and
I.
The
question
is,
you
know
you
want
to
help
the
open,
PGP
community
or
PG
PG
PG.
H
That's
a
matter
or
align
more
with
the
bigger
the
bigger
IETF
security
terminology
I'd
be
strongly
in
favor
of
doing
that,
but
it's
a
kind
of
invasive
change,
although
its
basic
editorial
failing
that,
then
we
really
need
a
big
terminology
section
at
the
beginning.
For
those
who
aren't
already
a
member
of
the
party
coming
into
this
trying
to
read
the
one.
H
C
F
You
be
willing
to
write
a
paragraph
or
two
that
is
the
that
is
the
translation,
paragraph
I'm
not
asking
me
to
make
the
invasive
change
that
melts
going
through
the
entire
document
and
changing
it,
but
even
one
that
just
lists.
You
know
a
handful
of
terms
that
you
see
that
are
being
used
differently
and
say:
hey
if
we
want
it
to
be.
If
we
want
people
to
be
able
to
understand
it.
Coming
from
this
terminology,
here's
the
section
that
we
need
sure.
H
F
F
Two
key
comparisons:
strang
kiki
is
where
openpgp
converts
user
passwords
into
cryptographic,
keys
and
there's
a
strong
argument
that
we
need
something
better
than
the
traditional
salted
hashed
password
in
today's
era
of
you
know,
password
cracking
supercomputers
and
the
password
hashing
competition.
Has
this
argon
construct
an
argon
to
I
I.
Think
in
particular
is
the
one
that
we
wanted
to
use.
We
had
a
we
had
a
pull
request
or
a
patch
set
coming
from
neil's
Turner
I.
F
Think
that
described
it,
but
argon
to
I
also
recently
had
a
minor
change
introduced
to
try
to
address
a
new
attack
that
was
found
post
password,
hashing
competition.
So
presumably
we
want
to
use
the
revised
version.
The
revised
version
is
not
yet
in
this
I
RTF
draft,
so
maybe
so,
maybe
once
that
draft
is
updated,
then
it's
worth
I
mean
maybe
I
think
I
guess
we
should
refer
to
it
anyway
and
once
the
draft
is
updated,
our
reference
will
magically
become
the
correct
thing.
F
F
But
if
you
want
to
you,
know
prefix
what
you
say
on
that
on
the
jabber
room
with
Mike,
then
rich
will
say
it
at
the
mic.
But
if
you
have
any
comments
on
on
whether
like
if
on
that
pull
request
or
anything
that
would
be
welcome
as
well,
but
I'm
not
hearing
any
concerns
or
objections
about
the
educated
choices
so.
F
F
So,
given
that
we
want
only
one
kind
of
fingerprint
perky,
the
last
question
XO,
there
will
be
a
question
of
how
we
choose
what
that
fingerprint
is.
But
there's
also
a
question
of
what
do
we
put
in
the
fingerprint
with
existing
keys.
They
are
fingerprinted,
including
the
creation
time
step,
which
means
the
same.
Key
material
can
have
multiple
fingerprints
depending
on
the
chosen
creation
timestamp.
So
there's
a
question
here
of
whether
we
want
to
do
that
in.
F
If
we're,
if
we're
making
a
new
fingerprint
for
these
new
keys,
are
we
interested
in
continuing
to
keep
the
creation
time
stamp
present
in
that
fingerprint?
Or
do
we
want
the
fingerprint
to
refer
specifically
to
the
underlying
key
in
some
ways?
This
question
is
similar
to
the
questions
about
keep
inning
that
we
see
in
the
HTTPS
world,
so
the
HP
KP.
F
Initially
they
were
pinned
by
certificate
and,
as
a
result,
the
same
key
could
be
used
in
a
different
certificate
and
the
fingerprint
of
the
certificate
would
change,
depending
on
the
other
metadata
that
was
sort
of
garbled
up
with
the
public
key.
So
I
personally
am
leaning
in
the
direction
of
not
including
creation
timestamps.
If
we're
going
to
rev
the
fingerprint
format,
but.
F
J
J
Yes,
I
say
that
was
a
good
thing.
However,
given
where
PGP
is
now,
my
experience
of
recent
experience
of
PGP
was
I
tried
some
of
these
code.
It
uploaded
my
key
to
a
key
server
without
asking
me,
and
now
people
are
sending
the
encrypted
PGP
mail
to
a
key
that
I
cannot
delete
and
so
having
a
key.
That
I
cannot
delete
that
doesn't
even
have
a
creation
time
stamp
or
I
can
expect
me.
F
J
J
So
if
you
do
need
fingerprints
of
the
key
material
on
the
timestamp
I
would
expect
that
they
would
store
the
time
stamp
with
the
key
material
and
only
generate
another
thing
to
print
with
the
updated
timestamp
that
was
really
exactly
what
they
wanted
to
do.
Otherwise
you
end
up
with
the
context
being
separated
from
the
key
in
ways
that
I
don't
I
don't
think
is
a
good
way
thing
to
do
to
your
existing
third
base.
J
F
C
Yeah
great
for
you,
p
FM
it
so
sorry,
I'm
not
completely
intimately
familiar
with
the
details
or
how
things
work
now,
but
it
seems
like
the
meta
question
here
is:
should
the
fingerprint
you
know
depend
only
on
the
key
or
on
additional
self-signed
stuff
that
the
author,
the
owner
of
the
key,
can
change
if
they
want
to
without
changing
the
key
itself,
and
is
that
a
good
or
a
bad
or
indifferent
property?
C
You
know,
if
that's
a
bad
property,
you
know
kind
of
having
having
the
fingerprint
depend
on
other
self
signed
stuff,
including
creation,
site
types
down.
It
all
means
that
you
know
an
author,
the
holder
of
a
current
key.
Could
you
know
mine
for
a
different
finger
print
for
any
number
of
different
fingerprints
they
want
to,
while
keeping
the
same
same
private
key?
Is
that
a
bad
thing
or
a
good
I?
Don't
know?
C
Of
course
anybody
can
still
mine
for
different
keys
regardless
right,
so
I
don't
know
if
it
makes
a
big
difference,
I'm
just
trying
to
kind
of
think
about
that.
On
the
other
hand,
if
we
decide
that
it's
not
a
bad
thing
for
the
owner
of
a
key
to
be
able
to,
you
know,
pick
different
self-signed
stuff
and
get
different
fingerprints.
You
know
why.
Why
should
that
allowance
be
restricted
to
this
particular
thing?
For
example,
you
know
if
we
allow
it
to
cover
creation
time
stamp.
F
F
C
C
You
know,
as
long
as
the
fingerprint
has
to
change
when
any
of
this
stuff
changes,
probably
I'm
fine
with
that
and
so
I
guess
you
know
in
some
sense
I'm
saying
I
don't
see
a
problem
with
you
know
the
thing
you're
printing,
covering
covering
the
creation,
time
staff
and
if
nobody
else
sees
a
big
problem
with
that,
I
would
even
go
further
to
say
why
can't
it
potentially
we
allow
it
to
depend
on
on
other
stuff
too,
like
the
argon
and
security
parameter.
This
gets
back
to
a
suggestion.
C
Somebody
else
made
in
in
the
last
IETF
meeting
I
think
that
might
be
useful,
that
that
you
could,
you
could
actually
create
a
key
fingerprint
and
choose
you
choose
your
security
parameter
for
it.
You
know
if
you
want
to
invest
a
lot
of
compute
cycles
in
generating
this
fingerprint.
You
get
more
protection
against
someone
else
mining
a
similar,
similar,
looking
fingerprint
right.
So
I
thought
that
was
a
nice
idea.
I
didn't
hear
a
whole
lot
of
other
support
for
it,
but
you
know
it
seems
to
follow
in
the
same
general
category.
F
F
J
Actually,
on
the
mining
thing
about
getting
gas
one
of
the
problems
that
you
that,
because
I
look
to
come,
people
have
got
to
Bitcoin
addresses
that
have
fancy
strings,
and
so
they,
you
know
they
try
and
get
a
key
that
has
something
cute
at
the
front.
I
want
the
security
usability
things
that
you
then
have
is
people
who
do
that
effectively
shooting
themselves
in
the
foot,
because
now
all
people
look
for
is
that
the
first
few
bites
of
the
characters?
Safe,
facebook,
okay,
so
you've
actually
reduce
your
security
of
your
key
to
anybody.
J
F
F
So
one
concern
that
I
have
with
a
variable-length
fingerprint
is
that
it
becomes
difficult
to
tell
whether
you
have
a
full
fingerprint
so
I've
certainly
seen
situations
where
someone
has
the
fingerprint
on
their
business
card
and
the
printer
screwed
up
and
omitted
several
of
the
octets,
and
you
can
tell
that
it's
not
the
full
fingerprint
because
it's
shorter
than
the
fingerprint.
If
we
allow
for
variable
length
fingerprints,
it's
impossible
to
detect
that
kind
of
screw-up
right,
the
guitar,
we
could
override
check
something
or
things
like
that,
but
the
house
starts
to
become
very
complicated.
F
J
However,
if
you
get
somebody
who
gives
you
the
first
20
character,
pin
or
fingerprint,
then
you
look
it
up
in
the
mesh
and
then
you
get
back
to
full
512
it,
and
you
store
that
in
your
contacts
directory
or
whatever
and
so
effectively,
you're,
really
using
the
fingerprint
in
that
point
as
a
calling
card
an
initial
validate
and
it
doesn't
need
to
be
as
long.
Oh,
ok,
but
you
can
have
high
strength
behind
bed
scenes.
C
If
right
for
it
again,
if
there's
time
just
to
on
just
to
kind
of
throw
out
a
variant
of
what
Philip
suggested,
instead
of
say,
you
know
using
the
number
of
zeros
kind
of
thing,
I,
think
kind
of
what
I
was
in
thinking
about
was
was
but
I
think
with
suggestions
say
having
on
incorporating
argon.
You
know
argon
to
into
the
fingerprint
creation
process
with
the
parameter.
F
C
You
know,
if
I'm
a
user
who
wants
to
invest
more,
you
know
time
into
you,
know
both
the
creation
and
checking
of
fingerprints.
You
know
make
it
turn
out.
The
security
parameter.
I
get
a
more
protection
against
other
people
trying
to
create
similar
the
fingerprints
that
look
similar
at
the
beginning.
Addressing
the
you
know,
puddi
kind
of
thing
I
mean
people
can
still
be
picked
low
security
parameters
and
be
surely
hoodie,
but
people
also
have
the
option
of
you
know
of
getting
more
protection
right
so
that
that
was
the
sort.
C
So
the
my
finger,
so
if,
if
we
allow
getting
back
to
this
question,
if
we
allow
on
the
fingerprint
to
cover
anything
but
the
bear
private
key
itself,
you
have
that
property
any
level
the
owner
of
a
key.
Can
you
know
mine
for
different?
You
know
produce
different
self-signed
certificates
with
different
creation,
time
stamps,
whatever
that
will
have
different
fingerprints?
You
have
that
you're.
You
know.
Unless
you
want
to
absolutely
you
know,
go
down
to
the
plate.
The
bear
minimalist
thing
where
the
fingerprint
covers
the
private
key
or
public
key
and
nothing
else.
C
F
C
C
F
Maybe
there
needs
to
be
a
limit
to,
or
you
know,
I
don't
know
so.
I
quit
so
I
feel,
like
I
feel
like
we're
having
a
bunch
of
discussions
about
all
these
kinds
of
things
that
we
could
do
with
fingerprints
and
I
think
would
be
really
useful
for
someone
to
write
down
specifically
what
we
expect
fingerprints
to
do.
F
Well,
it's
gonna
take
us
forever
and
what
may
be
one
thing
to
do
is
to
say
what
has
a
fingerprint
traditionally
done
in
openpgp
and
do
we
have
any
reason
to
expand
that
use
and
can
we
in
any
way
like
minimize
it
and
say
here's
exactly
what
we
expect
to
fingerprint
to
do?
Is
there
anybody
who's
willing
to
do
that
right
up,
Phil,
yeah.
J
J
J
One
of
my
big
issues
is
I
want
to
be
able
to
use
fingerprints
in
ssh
as
well,
because
at
the
moment
SSH
is,
has
some
severe
usability
issues
between
when
using
client-side
skis
and
I
would
like
PGP
in
ssh
to
converge
at
some
point.
So
I
I
understand
your
issue
about
canonicalization,
yeah
and
even
I.
Won't
there
are
ways
you
could
get
round
canonicalization
simply
by
saying.
Okay,
if
you're
leading
objects
are
all
zeros,
then
you
have
to
use
a
fingerprint
compression
that
could
just
give
I.
F
Mean
again
it's
absolutely:
we
keep
adding
things
we
could
do
with
fingerprints
and
I
would
really
like
us
to
be
focused
and
say
right.
Here's
what
we
could
do:
fingerprints
like
here's,
what
we
were,
what
we
are
going
to
do
with
fingerprints
and
not
have
a
wider
and
not
have
a
wider
range,
because
I
want
us
to
I,
want
this
process
to
terminate.
F
F
F
So
we
have
this
open
question
about
symmetric
encryption.
I
believe
that
burner
has
stated
a
preference
for
ocb
Brian.
You
wrote
a
draft
for
AES
GCM,
one
of
the
guys
from
whiteout
put
the
didn't
implementation
of
the
AES
GCM
in
I.
Think
openpgp
j/s
I
spoke
with
raga
way
about
the
potential
IP
constraints
for
a
ESO
SI
b,
and
he
said
he's
fine.
Making
a
grant
so
OCD
is
is
as
a
there
is
a
patent
on
it.
F
K
H
Shoe
is
apparently
dependence
or
invalid
through
the
lack
of
payment,
but
some
of
the
underlying
ones
may
still
cover
issues.
So
it's
still
a
mess.
I'm.
G
F
F
Be
closing
message
on
Cindy
right,
so
do
people
have
specific
preferences
for
what
we
should
be
doing?
I
mean
the
general
sentiment
that
I've
heard
was
we
want
one?
We
want
one
mode,
one
new
mode
that
would
replace
cfb.
That
would
be
straightforward
to
use
I
believe
that
Verner
is
interested
in
trying
to
do.
Is
you
be,
but
I
don't
think
we
have
any
text
for
that.
Yet.
G
H
Joe
Hall
says
yeah:
there
are
some
other
IP
claims
on
a
ESO
que
eso
vc
things
other
than
rogue
awake,
so
yeah,
it's
all
a
mess
red
sauce
yeah.
I
think
we
clearly
want.
You
know
a
EAD
authenticated
encryption
and
I
also
agreed
with
our
ad
that
guten
ins
sa
is
entertaining
reading,
but
he
also
actually
doesn't
say
it's
wrong
right.
So
how
do
we
get
to
this
problem?
And
then
it's
not
clear.
H
It's
a
problem
when
you
read
the
whole
thing,
so
yeah
I,
don't
the
one
reason
why
I
like
a
SG
cm
is
it's
fast,
didn't
best
cops.
C
Not
Brian
for
TB
FL
personally
I'm,
not
particularly
worried
about
the
crypto
monoculture
you
know
concerned
either
I
think
chacha,
20,
poly
30,
no
fire
is
a
great
system.
On
the
other
hand,
we
as
a
kind
of
backward
compatible,
well
known
and
all
kind
of
very
well
understood
a
system
that
has
really
good
hardware
support
all
out
there
I
think
either
a
DSG,
CMEs
or
OC
b
is
a
really
good
thing
to
have.
C
If
I'm,
certainly,
probably,
you
know-
maybe
ideally
just
one,
but
what
would
it
be
worth
considering
having
in
a
1
a
ii
s
based,
cipher
and-
and
you
know,
a
cha-cha,
you
know
a
DK
DK
be
cipher,
you
know
as
a
as
to
providing
at
least
some
diversity,
because
there's
at
least
a
lot
of
diversity
there
for
whoever
is
concerned
with
the
monoculture
thing.
For
example,.
L
I
So
hi
this
is
shawn
turner,
I,
don't
know!
If
you
want
to
do
this,
but
what
s
lime
did
back
in
the
day
when
they
had
this
whole
TSA
RSI
thing
was
they
said
you
could
do
you
could
pick
one
of
two
sending
and
required
to
on
the
receiving
side,
so
that
might
allow
you
to
the
in
terms
of
mandatory
to
implement.
F
I
I
F
I
It
also
helps
getting
people
ready
for
if
you
believe
in
the
whole
idea
of
having
cyber
sweet
agility,
where
you
can
change
one.
So
if
you
get
people
like
okay,
so
we
have
to
support
to
great
and
then
when
you
want
to
clip
one
out,
it
could
be
like
now
we're
just
changing
them.
One
of
the
asymmetric
bits
right.
F
Yeah
I
think
that
would
be
great
I
think
that
would
I
think
that
would
be
a
step
in
the
right
direction.
Just.
F
F
About
the
use
of
signatures
and
a
pattern
that
I'm
seeing
within
the
broader
IETF
that
we're
not
currently
doing
here
and
just
raise
the
question
and
ask
people
what
they
think
about
how
it
would
work
for
openpgp.
So
the
pattern
that
I'm
seeing
is
that
when
there
are
asymmetric,
crypto,
crypto
signatures
being
done
or
when
there
is
an
H
Mac
or
an
H
kdf.
The
pattern
is
that
you
prefix
the
thing
that
you
are
macking
or
signing
with
a
label
so
that
your
signature
or
your
Mac
isn't
replayable
in
some
other
context.
F
F
The
data
that's
being
signed
so
I'm
wondering
whether
people
think
that
it
would
be
worth
so
so
this
this
framework.
It
basically
helps
every
system
that
adopts
this
kind
of
framework
where
you
prefix
the
thing
that
you're
signing
it's
protected
against
cross
protocol
attacks
from
every
other
system.
That
also
adopts
the
same
rough
framework.
F
So
the
question
that
I
have
is
it:
do
we
think
that
this
is
something
that
is
worth
applying
in
open
PGP
in
some
in
this
future
revision,
so
that
open
PGP
signatures
can't
be
confused
with
signatures
from
other
protocol
schemes
if
the
same
Keys
end
up
being
reused
in
some
funny
way.
These
are
sort
of
theoretical
attacks
for
the
most
part,
but
there's
a
sort
of
class
of
cross
protocol
attack
there.
It
would
be
nice
to
say
we
don't
have
to
worry
about.
F
This
I
spoke
with
the
folks
in
DNS
SEC
yesterday,
and
they
seem
like
they
might
be
convinced
bull
to
make
sure
that
new
types
of
DNS
SEC
signatures
have
a
prefix.
Tls
was
already
doing
this.
If
this
is
something
that
we
could
say
that
that
we
had
a
broader
sense
within
the
IETF,
this
was
how
one
uses
macs
or
asymmetric
signatures.
That
might
be
something
that
might
be
a
way
to
say
if
you're,
using
these
newer
protocols,
you
don't
have
to
worry
about
cross
protocol
attacks,
because
we
have
this
bulwark
against
her.
C
F
C
That
was
decided
positively
in
that,
in
that
case,
I.
Don't
think
it
would
be
a
bad
thing
for
openpgp
to
do.
You
know
how
a
similar
mechanism,
especially
given
you
know
the
different
types
of
semi-automated
or
odd
mated
applications
that
p-gp
signatures
are
used
for.
So
you
know
you
have,
you
know,
get
commit
signatures
versus,
so
you
know
different
kinds
of
signatures.
I,
don't
know
how
important
having
that
distinction
is
in
practice
in
the
bigger
scheme,
but
it
really
seems
like
a
like
a
good
safety
measure.
So.
C
You
know
no
comp
when
there's
no
context,
but
when
there
is
a
context,
you
know
when
you're
producing
signatures
for
this
particular
thing,
and
you
want
to
make
sure
they
can't
be
mistaken
for
signatures
for
anything
else.
You
know
you
have
the
application
specify.
Well,
we
always
use
this
context
string
and
that
kind
of
differentiate
you
know
differentiates
the
domain
from
from
anyone
else
and
it
seems
like
it
would
be
easy
and
a
good
just
a
good
thing
if
PGP
had
a
similar
great.
F
C
C
M
Ahead:
okay,
well,
I
was
right
that
so
one
thing
we
ran
into
and
I
think
I
posted
this
to
the
list
many
months
ago
so
might
have
been
lost.
Is
that
signatures?
Don't
actually
tell
you
an
ID
of
the
key?
It
has
you.
It
has
a
unique
ID
number,
but
you,
sir,
I
cannot
lift
it
up
and
we
were
looking
at
publishing
our
keys
in
dns
using
open
beach
picky,
but
there's
no.
F
J
Much
very
support
the
idea
of
putting
in
a
identifier
into
the
signature.
That's
actually
what
I'm
doing
in
my
uniform
data
fingerprint
proposal
and
there
what
I'm
using
is
content
type.
The
one
caveat
is:
is
that
anything
that
prefer
this
to
actually
work?
This
is
something
that
has
to
be
an
ietf
wiping
at
minimum.
J
Yep
now
I
think
there's
an
almost
zero
chance
that
content
types
are
gonna,
be
accidentally
misused
by
other
working
groups,
but
obviously,
and
obviously
any
any
protocol
that
allows
average
which
strings
to
be
signed
is
going
to
die
but
is
going
to
be
vulnerable.
But
content
types
looks
like
a
pretty
good
bet,
because
you.
J
J
Now,
even
now
separately,
I've
been
working
on
this
project.
The
mathematical
mesh
and
I've
now
got
s
mine
usability.
Basically,
the
users
now
can
do
as
mine.
It's
no
hassle
at
all.
Now
the
reason
I
did
s.
Mine
was
I,
knew
that
if
I
did
PTP,
nobody
was
going
to
help
me
with
that's
mine.
If
I
did
s
mine,
then
EGP
people
might
help
me
make
VG
be
easy
to
use
at
the
same
time.
So
there's
a
call
for
collaborators.
Yes,
in
particular
one
of
the
changes.
J
The
time
when
the
changes
since
fills
in
and
created
PGP
is
that
at
the
time,
public
key
crypto
was
really
expensive
in
terms
of
cycles.
Now
it
isn't,
and
so
that
has
consequences
for
how
you
manage
keys
and
how
you
might
want
to
structure
them
and
I
want
to
know
if
there
are
ways
of
doing
it
within
the
deployed
PGP
base
or
whether
I
should
go
with
that
outside
and
whatever
in
my
scheme.
I
have
separate
keys
for
every
device
wherever
possible.
F
Ok,
so
that
sounds
similar
I
mean
Derek.
Atkins
work
appears
to
be
moving
towards
PGP
keys
per
device
as
well.
If
you
look
at
the
those
frames,
so
maybe
Derek
Ariza
me
to
talk
to
ya.
Ok,
so
if
do
people
have
other
questions
or
concerns,
I
think
I
can
give
you
back
35
minutes
of
your
life.
I
hope
people
will
follow
up
on
the
Menace.
F
We
need
to
be
going
to
be
more
active
than
we
have
been
there
and
hopefully
we
can
get
some
patches
flowing
and
get
me
get
a
get
the
draft
underway,
but
thanks
for
coming
everybody
any
other.
Anyone
else
want
to
speak
from
via
me.
Dekho,
I'm
still
not
seeing
anybody
in
the
queue
we're
about
to
wrap
this
up.
J
F
D
J
So
right:
well
then,
actually,
you
might
have
I'll
have
to
think
through
because
one.