►
From YouTube: IETF103-LAMPS-20181106-0900
Description
LAMPS meeting session at IETF103
2018/11/06 0900
https://datatracker.ietf.org/meeting/103/proceedings/
A
B
B
B
B
B
C
All
right,
thanks
so
real
short
update
on
RFC
sixty
eighty
four
six,
eight
four
four
bits
and
went
through
it's
last
call
I
believe
it's
about
to
be
on
its
way
to
iesg.
I
got
a
couple
real
small
editorial
fixes
at
the
last
minute
from
Rob.
Those
are
in
the
github
copy.
Russ
should
I
upload
a
fresh
draft,
or
should
we
catch
those
in
the
editor
q?
What's
your
suggestion
there.
B
C
B
This
is
an
overview
of
what's
going
on
when
you
generate
your
first
key
pair,
you
generate
the
second
key
pair
as
well
and
include
the
hash
of
the
public
key
of
the
certificate,
the
trust
anchor
certificate
and
then,
when
you
roll
to
the
second
one,
you
generate
the
third,
when
you
include
its
hash,
so
you're
just
staging,
creating
a
way
that
relying
parties
can
confirm
which
public
key
to
trust
when
they
see
it
next
slide.
This
is
the
certificate
extension.
B
The
syntax
is
pretty
straightforward.
It's
just
a
which
hash
algorithm
was
used,
followed
by
the
hash
itself
of
the
de,
are
encoded.
Subject:
public
key
info
next
we're
in
working
group
last
call,
as
I
said,
the
security
considerations
were
expanded.
Based
on
the
discussion
in
Montreal,
then
the
working
group
adopted
it
I'm,
asking
you
as
part
of
the
working
group.
Let's
call
please
review
it
send
comments,
and
this
is
intended
to
be
an
informational
document
and,
of
course,
since
I'm
offering
it
Tim
will
make
all
of
the
consensus
calls
related
to
it.
Any
questions.
A
A
D
D
The
first
thing
we
did
was
replace
the
the
ECDSA
with
a
random
k
with
the
deterministic
version
and
yeah,
and
then
the
the
chairs
told
us
to
go
ahead
with
the
deterministic
tape.
Version
of
the
algorithm,
and
also
we
proposed
to
replace
the
kmac
in
the
key
generation
method
would
shake
because
we're
using
a
shake
for
the
signature.
So
we're
not
you
say
instead
of
h,
mac
and
and
we
need
comments
or
any
consensus
from
the
chair
on
Dass.
D
Also,
we
replace
the
mass
generation
function
in
the
in
the
in
the
X
non-standard
was,
the
shake
shall
shake
now
is
the
new
gia
TF
naturally?
Is
it
fits
well
and
it
works
well
and
also
we
updated
the
Security
section.
Consider
security
considerations
and
also
we
pointed
out
the
property
of
a
shake
functions.
Is
that
similar
to
like
any
flesh,
Mac
or
sha-512
function,
for
example,
for
the
H
Mac
sha-1?
D
Sometimes
people
use
you,
know,
truncated
outputs,
like
96
bits,
instead
of
the
4
before
hash
function
or
something
and
the
shake
has
the
same
property.
So
when
somebody
desire
of
protocols
or
looking
at
different
protocols-
and
they
need
to
to
take
a
closer
look
to
make
sure
they
don't
have
related
or
potential
witnesses
in
in
all
uses
in
an
inner
protocol
or
across
protocols,
but
mostly
it's
just
natural
deterministic
function,.
B
So
when
Jim
proposed
this
on
the
list
that
we
use
shake
as
the
mask
generation
function,
we
asked
the
see
if
our
G,
if
there
was
any
problems
with
that
they
had
a
brief
discussion
which
basically
everybody
who
read
the
document
said
yep.
That
seems
like
a
completely
good
fix
in
terms
of
compatibility.
So
then
Queen
updated
the
document,
so
we
just
I
just
wanted
to
make
sure
everyone
aware
it
was
aware
we
got
the
C
FRG
review
of
that
idea.
E
F
I
just
wanted
to
ask
about
the
ECDSA
I
think
it's
fine
German
that
I
guess
what
is
interrupt.
Impact
of
that,
namely
I,
don't
believe
there
is
because
my
understanding
is
that
they
were
c4
no
way
validating
that
you
use
your
mystic
a
terminus.
Take
a,
but
this
is
just
this
is
this
is
merely
this
is
merely
our
advice
on
how
to
implement
it.
Maybe
it's
mandatory
advice,
but
that's
all.
It
is
right.
I.
D
D
F
Mean
I
make
I
guess
my
point
is
that,
like
you
have
a
you,
have
like
a
box
which
is
ECDSA
and
like
and
and
generally
they're
only
from
the
phoenicians
perspective,
that
box
does
whatever
it
does,
and
that
box
has
like
some
function.
It
uses
for
like
for
determinate
for
generating
K
right,
and
maybe
that
function
is
realistic.
Me
it's
not
for
mistaking,
maybe
use
Shah
movie
uses
these
a
yes
or
whatever
right.
So
I
guess
like
I
guess.
F
D
F
G
F
There's
the
best
of
my
knowledge,
no
reason
to
believe
that,
like
that,
the
key
generation
function
in
that
is
not
as
perfectly
satisfactory
and
and
the
and
there's
no
interoperability
impact,
whether
you
use
that
key
generation
function
or
some
new,
like
my
point,
is
you're
now
creating
a
new
implementation
of
key
CDSA.
That
is
no
interoperability.
In
fact,.
D
We
we
did
point
it
down
to
the
the
deterministic
version
of
EC.
They
say
they
are
I've,
seen
yes
right,
but
so
what
is
this
support
me?
Ye?
The
support
in
that
I
out
see
I,
don't
believe
it
provides
a
complete
back
for
EC.
They
say
it
mentioned,
describe
several
things,
but
I
I.
Don't
think
that
I
don't
think
it
is
a
complete
spec
for
deterministic
easy.
They
say
it's
pointed
to
some
other
standard
for
respect,
and
then
it
pointed
out
here
is
K
should
be
generated
differently
from
the
from
the
other
standard.
Okay,.
D
D
B
D
F
But
wait
a
second
like
say:
I
have
say:
I
have
an
implementation,
let's,
like
let's
take
out
the
entire
limitation
system
right
I
have
a
key
generation
function,
starting
with
randomness
that
key
generation
function
starts
like
May
or
make
me
use.
H
back
internally
may
use
a
yes
and
let
me
use
anything
right.
It's
just
it's
just
it's
just
a
PRS
appear
in
G
right
like
that
uses,
H,
Mac
or
use.
This
document
can
also
say
like
stop
using
H
Mac
there.
It's
just
none
of
your
business,
no
okay,.
D
That's
that's
no
point
of
view,
but
I
think
anything.
We
we
if
we
should
say
something
or
we
allow
something
expect
something.
We
should
be
more
concrete
about
what
we
people
should
or
should
not
do.
For
example,
instead
of
you
know
random
K,
we
not
normally
say
okay
case
randomly
generated,
but
how
this
is
you
know
the
methods
we
believe
we
feel
comfortable
with
how
to
do
two
random
K
generation.
D
F
Is
not
about
deterministic
versus
random?
This
is
about
implicitly
updating
the
deterministic.
You
see,
I
say
expect
to
including
a
hash.
Our
include
I,
just
don't
for
them,
which
is
not
like,
like
the
scope,
if
you
want,
if
you
want
to
write
a
what
is
it
if
you're
on
already
to
a
t-33,
to
Biff's
guys
soon,.
D
D
D
B
D
D
D
D
F
F
Just
a
smack
in
saying
was
he
like
I
guess
blind?
What
well
I
would
like
you
to
be
able
to
do
it.
Maybe
clear,
well,
I!
Think
they're,
reasonable
thing
for
the
Stockton
to
do
is
I
think
this
document
watch
to
be
like
I
assume.
What
your
attempt
to
achieve
is
a
protocol,
specific
implementation
which
does
not
use
shot
anywhere,
right
and
so
saw
shot
to
anywhere
and
so
I
think,
if
to
send
to
which
you
know
so.
F
Well
so
I
mean
that's
like
okay,
like
I
mean
so
it's
like,
like
it's
generally
unfortunate,
if
we're
citing
like.
If
we
have
like
again
I'll
I,
don't
have
the
facts
are
so
on.
Maybe
I
should
zoom,
but,
and
we
just
look
it
up
but
like
it's
generally
unfortunate,
if
we're
telling
people
to
use
deterministic
ECDSA
and
that's
tying
them
into
one
hash
function,
but
that's
like
a
problem
with
that
that
specification,
which
would
be
sure
which
we
should
fix.
F
So
if
the
objection
is
that
nobody
could
nobody
in
that
IETF
can
use
deterministic
ECDSA
without
using
shot.
Then
we
should
miss
that
specification
and
and
say
and
and
make
it
and
say
it
has
to
be
a
PRF
and
then
get
and
then
give
examples,
the
PRF
what
we
shouldn't
do
is
like
attempt
to
piecemeal
patch
here.
D
D
H
H
D
I
Malik
give
elapsed
to
the
point
the
acre
was
making
before
in
the
draft.
I.
Think
now
is
written.
Must
you
must
use
kmac?
Could
that
be
a
me
so
that
you
can
use
other
constructions
and
you
don't
limit
so
if
I
want
to
have
an
implementation
that
is
compliant,
I,
don't
have
to
use
kmac
and
I
can
use
something
else.
That
would
be
a
way
to
do
it,
but
not
the
only
way
to
do
it.
Yeah,
but.
D
That
has
this
reason,
but
the
thing
is
when
we're
saying
that
and
then
we
both
you,
know,
feel
like
I
can
use
anything
I
want
that
doesn't
seem
to
be
a
good
idea.
You
have
to
be
specifically
what
what
do
you
feel
comfortable
for
you
to
recommend
people
instead
of
say
we
will
use
anything
I
want
now
and.
I
The
Senate
I'm
just
saying
that,
if
you
put
the
must
any
implementation
has
to
use
that
cannot
use
anything
else.
If
you
use
me,
we
can
have
some
implementation
that
use
other
constructions
that
are
still
secure,
and
you
know
the
brief
occasion
is
not
a
problem.
It's
just
a
way
that
you
can
strike
there.
Yep.
D
D
That
would
that
would
make
imitation
in
a
more
complex.
You
have
char,
and
then
you
have
shout
to
you
know
K
generation,
and
then
here
you
do
have
seen
everything
here
with
H
man
with
kmac,
so
it
makes
us
situm
later
Baker,
but
that's
not
what
you
want.
Then
I
have
no
objection
to
that.
Okay,
yeah!
It's
fine!
I!
D
Think
you
have
no
thing
nothing
wrong
with
the
the
H
Mac
will
shout
nothing
wrong
in
my
understanding
it
just
if
you
want
things
more
efficient
and
you
don't
want
to
have
two
different
headphones
and
running
everywhere
in
your
application,
why
you
don't
need
both
of
them
in
the
same
time,
the
only
one
of
them
at
the
same
time,
but
it's
you
know
if
you
want
one
application
with
two
headphones
in
India
on
a
security
perspective.
I
don't
see
prop
in
a
problem
with
them
in
this
particular.
J
Application,
descriptor,
Pro
thinker
magic,
win
for
the
presentation.
I
just
wanted
to
support
expeditions
that
if
we
want
to
generalize
the
construction
with
deterministic
ECDSA,
it's
definitely
a
good
way
to
go
only
to
piece
the
document
not
to
include
some
additional
ways
to
implement
that
in
other
protocols.
So
it's
just
a
not
good
way
to
go,
because
we
really
need
I
believe
that
it's
they
say
in
deterministic.
J
K
F
Thank
you
so
I'm
not
bothered
to
like
look
through
since
89.
So
yes
clear,
it
does
say,
H
back
so
clearly,
any
said
age
to
69
79
like
would
imply
using
H
buck.
The
correct
fix
for
this
is
so
like
I'm
concerned
about
the
ITF
going
forward
and
the
correct
fix
for
this
is
to
be
69
79
so
that
it
specifies
so
a
it
specifies
like
basically
any
suitable.
F
Like
PRF
and
b
and
b
then
b
specifies
kmac,
and
I
don't
know
how,
like
as
a
registry
or
some
such
nonsense,
that's
basically
the
point
being
that
what
I
want
to
do
is
I
want
to
say.
69
79
had
that
cover
on
a
variety
of
CCDs
instantiations
with
other
prfs
and
so
and
not
have
to
have
like
everybody.
Either
say
it
say:
69
79,
but
it's
also
fine.
If
you
use
k,
mac
or
$6.99
with
them
a
fight
there.
So
it's
like
the
appropriate
place
to
piss.
That
is
a
forgery.
F
F
F
J
Okay,
so
if
again,
Alexei
Melnikov-
not
here
but
I,
believe
that
if
we
have
any
reasonable
updates
for
our
C
69
79,
then
I
believe
that
Sarah.
She
will
support
this
book
because
it's
really
useful
or
C
and
it's
quite
good
ideas
daisies
with
sha
fat
reconstruction,
but
I,
don't
see
the
reasons
for
guys
in
suffrage
e2
not
to
do
this
work.
If,
if
you
were
volunteer
to
be
the
one
who
pushes
it
I,
certainly.
J
J
D
Yeah
we
need
to
to
generate
the
iesson
and
one
module
for
for
the
CMS.
A
draft
and
also
you
know
more
reviews
are
better
own
ways
and
also
Jim
raised
a
question
he
asked
about
whether
or
not
we
should
allow
short
detects
for
for
kmac
in
in.
In
many
cases
it
makes
sense
have
short
attacks.
If
you
cares
about
the
size,
but
for
security,
I
would
go
to
the
for
size
and
I
feel
happy
about
it.
D
B
B
D
B
D
F
I've
always
assumed
that
this
was
fine
to
truncate
yeah,
but,
like
I'd
like
to
see
a
statement
from
somebody
who's,
fine,
a
truncate,
so
here
either
cfrt
should
say
it
or
you
should
have
a
citation.
That
is
fine.
You
know
I,
don't
know
which
I.
If
we
have
those
things
to
hand,
then
I
think
it's
fine,
but
I.
Think
like
like
like
again
like
working
so
I
Michigan
step
back.
My
thesis
here
both
with
the
previous
point
in
this
is
regional
IETF
wide
understanding
of
what
constructions
are.
F
D
F
D
Like
that's,
why
I
said
I
feel
comfortable
with
two
for
size,
but
if
some
other
people
like
Jim,
wants
you
short
attacks
and-
and
it
depends
on
you
know
what
application
and
where
situation
is
in
a
dorm
for
for
me
to
write
some
some
good
recommendation.
But
so
that's
why
I'm
asking
the
group
how
to
handle
this.
D
That
would
be
a
fine
option
to
me.
The
only
thing
is
that
I
really
don't
worry
about
to
use
too
short
text
yeah,
because
if
they
use
like
64-bit
tech
and
then
they
use
in
a
high
volume
traffic-
and
that
would
maybe
make
me
feel
extremely
nervous-
but
if
they
use
of
the
for
tech
like
that
and
like
in
almost
all
of
the
practical
applications
in
the
world
is
still
safe.
D
But
you're
right,
it's
up
the
application.
They
decide
what
tech
size
I
want
to
use.
That
would
be
fine
with
me,
but
I
would,
if
we
did,
that
and
I
would
hope
to
put
some
advice
into
the
the
document
saying
you
know
how
how
much
traffic
they
they
they
should.
They
should
restrict,
depends
on
the
tech
side,
I
use
if
a
text
size
like
this
tune
this
a
bit
and
it
seems
to
be
good
for
for
everywhere.
F
L
F
I
would
suggest
that
use
a
full
length
hike
here.
If
someone
wishes
to
promulgate
a
tag,
truncation
mechanism,
then
they
can
probably
come
along
at
that
for
both
kmac
NH
mac,
but
like
this
seems
like
since
I
understand
the
purpose
this
document
be
to
to
allow
you
to
prusik
a
Mac,
only
a
shot.
Three
only
suite
like
I,
don't
see
who
any
reason
any
different
from
each
back
and
I'm
not
opposed
to
shorter
tags,
but
I'm
saying
like
let
us
do
them,
but
a
special
ties.
Orthogonal.
M
L
D
N
D
B
The
research
group
has
completed
their
last
call
on
the
gurus
hash.
Sigdoc
provide
a
bunch
of
things
about
what's
going
on
there.
The
bottom
line
is
that
you
have
a
small
amount
of
code
to
validate
a
signature.
That's
very
can
be
done
very
quickly.
However.
The
signature
itself
is
quite
large,
and
but
these
signatures
are
quantum
resistant
Thanks.
B
B
B
Rfc
4108
describes
one
way
to
do
that
using
CMS
and
I
think
this
is
important,
because
we
want
to
deploy
a
quantum
resistant
signature
now
so
that
when
you
want
to
deploy
code
in
the
future,
you
if
a
quantum
computer
of
significant
scale
comes
to
pass
in
the
next
decade
or
so
then
we'll
be
able
to
validate
the
signatures
on
the
code
that
deploys
the
new
quantum
resistant
capabilities
next
slide.
So
some
recent
errors
were
fixed
found
by
Daniel.
Thank
you
for
the
review.
B
We
I
think
we're
ready
for
working
group
last
call
soon.
That
is
when
the
draft
McGrew
arrives
in
the
RFC.
Editor
queue,
that's
what
I
mean
by
soon
should
be
soon,
since
the
research
group
has
finished
their
last
call
anyway,
I'm
asking
for
review
and
comment
now
that
document
seems
to
be
stable
and
once
again,
since
this
document
I
picked
up,
the
pen
Tim
will
make
all
the
consensus
calls
any
questions.
B
So,
following
on
the
let's
be
ready
for
quantum
computers,
just
in
case
this
is
an
another
solution.
The
idea
here
is
to
mix
a
PSK
in
with
either
a
diffie-hellman
or
RSA
type
results,
so
that
we
can
so
that,
even
if
a
quantum
computer
is
invented,
we
have
the
attacker
has
to
learn
the
PSK
as
well
as
break
the
public
key
algorithm
next
slide.
B
B
What
the
concern
is
is
that
an
adversary
will
save
a
content
that
is
produced
today
and
then
Sunday
and
save
it
away
and
then
someday
when
they
do
get
a
hold
of
a
large-scale
quantum
computer
they'll
be
able
to
break
the
key
management
and
the
solution
is
to
mix
a
strong
PSK
with
it
and
then
that's
the
near-term
solution.
The
long-term
solution,
of
course,
is
to
deploy
a
quantum
safe,
public
key
technique
that
is
the
winner
of
the
nist
competition.
B
Next,
this
approach
that
I've
proposed
in
this
document
deals
with
two
kinds:
key
transport,
that's
RSA's,
style,
key
management
and
key
agreement,
that
is
to
ECDSA
style
and
it
mixes
a
PSK
in
with
the
result
of
either
of
those
techniques.
Next
slide,
this
provides
an
overview
of
how
that
actually
works
in
each
of
the
cases.
B
Uses
the
public
key
of
the
recipient.
We
pass
along
an
identifier
of
that
key,
so
the
recipients
can
find
which
piece
of
CMS
is
for
them
and
in
the
case
of
key
agreement,
the
long-term
public
key
is
put
in
a
certificate
and
either
the
issuer
serial
number
or
the
recipient.
Key
identifier
identifies
the
recipient
anyway,
so
including
the
additional
PSK,
an
identifier,
isn't
making
it
any
easier
or
harder
for
an
attacker
to
learn
who's
talking
to
who.
F
I'm
generally
sympathetic
to
this
argument,
but
if
I
had,
if
I
had
to
PS
case,
if
I
had
suppose
it's
supposed
to
situation,
we
have
one
recipient
who
has
two
PS
case
with
different
people.
Then
the
then
when
then
you'd
be
able
distinguish
the
sender's,
even
if
the
even
the
recipients,
so
so
the
recipient
for
sitting
in
for,
as
you
say,
would
say,
I'm
sending
to
you.
But
you
share.
One
piece
came
with
me
and
one
with
then.
Maybe
in
this
case
you'd
be
able
to
tell
Sakura,
be
Hotel
weather.
B
F
F
B
O
B
E
P
B
I
think
it
can
be
used
in
groups,
and
the
question
is
how
big
is
the
group,
where
they're
all
using
the
same
PSK
in
the
ayah?
Of
course,
the
bigger
the
group,
the
more
likely
it's
going
to
leak
and
so
on.
So
you've
got
to
balance
those
things.
But
the
idea
is
that
say:
the
finance
department
could
all
have
one
PSK
and
so
on,
like
that,
so
that
they
can
continue
to
do
things
pretty
much
as
they
do
today.
Someone
and
you
have
to
roll
like
any
other
symmetric
algorithm.
C
Q
B
Q
Q
Q
Q
B
A
K
G
G
G
So
there
is
some
use
cases
for
this
at
x.509
and
entity,
not
really
a
good
use
case,
because
managing
state
is
hard
and
if
you
fail
to
manage
state
securely.
That
means
you
could
end
up
reusing
the
one-time
signatures
in
these
algorithms
and
if
you
have
a
limited
number
of
signatures,
then
increasing
the
number
of
signatures
will
increase
the
signature
size
interact
in
the
interactive
protocols.
It's
not
great.
You
can
use
it
each
SM
to
manage
state
and
you
have
more
control
over
the
number
of
signatures.
But
it's
okay.
If
you
can
live.
C
G
The
same
exercise,
the
best
use
case
for
this
is
certain
non
interactive
protocols
that
is
ca,
certs
and
code,
signing
which
Russell
agreed
to
earlier.
His
first
draft
is
appropriate
for
climbing
you
can
use
HSM
to
the
understate.
You
have
more
control
over
the
signatures
exercise,
not
so
much
with
issue,
and
the
important
thing
is
that
these
signatures,
signature,
algorithms,
are
ready
to
deploy
now
for
longer-lived
certificates
such
as
IT
and
automotive,.
G
Next
slide
so
I
mean
basically,
this
is
it.
This
is
it.
This
draft
is
going
to
send
dispatch
later
well
for
me
tomorrow
morning,
but
for
you
guys
later
today
to
see
what
they
think
about
it,
maybe
send
it
to
lamps
and
for
us
and
lamps
is
there
interested
in
this?
Will
people
be
commenting
or
reviewing
on
it
and
just
as
a
note,
it's
already
been
partially
aligned
with
Russ's
first
draft
in
hashtags
and
CMS,
and
it
would
continue
to
be
aligned
with
that.
B
Wait
for
sec
dispatch
yeah,
so
I
asked
Daniel
to
talk
about
this
a
little
bit
here
today,
because
if
SEC
dispatch
says
oh,
it
comes
to
lamps
I,
try
to
peek
further
along
then
hearing
about
it
for
the
first
time
at
the
neck
at
IETF
104.
So
what
let's
talk
as
though
sick
dispatches
said?
Let's
send
it
to
lamps
and
see
see
if
there's
interest.
I
This
is
forward
forward.
Looking
we
have
a
kind
of
a
similar
proposal
goes
in
the
direction
of
adding
the
possibility
to
have
different
type
of
signatures
and
keys
in
certificates,
and
many
other
PK
acts
objects.
So
when
we're
each
other,
maybe
we
can
include
you
know
this
type
of
work.
That
would
be
great.
K
Hi,
my
name
is
sean
turner
and
read
the
strafes
real
quick.
It's
not
that
long.
Basically,
it's
got
exactly
what
needs
to
be
in
there
to
do
the
things
to
marry
up
with
Russ's
draft.
So
if
it
were
to
be
accepted
good,
it
would
be
fairly
short.
I
would
think
discussion,
hopefully
leading
quickly
to
over
in
group
last
call
because
there's
just
not
a
lot
there.
It's
asn.1
and
formats
that
are
based
in
RFC,
59,
11
and
12
off
you
go
that's
what
I
was
hoping.
B
Okay,
there's
a
one
other
bit
of
any
other
business
that
has
come
up
since
we
published
the
agenda
and
that
is
Alexi
stopped
me
in
the
hallway
yesterday
and
said:
hey,
you
know,
I
presented
that
thing
in
Montreal
about
header
protection
and
then
I
wrote
a
draft.
Can
you
adopt
it
and
I
said
no,
we
can't
adopt
it.
So
we
do
a
charter
change,
and
so
we
had
a
some
email
discussion
with
Acker,
pointing
him
to
what
was
going
on
and
so
Eric.
Would
you
support
a
charter
change
in
that
direction?
I.
F
Guess
I
have
two
preliminary
questions.
One
did
the
chairs
feel
like
they
have
that
or
clears
the
dam
with
state.
This
work
on
yeah,
I
think
I.
Think
it's
a
pretty
straightforward
document.
Okay
and
the
second
is
people-
and
this
working
group
understand
what
this
is
about
and
do
they
want
to
do
it.
That
is.
G
P
This
is
dkg,
so
I've
offered
to
co-author
the
draft
with
Alexei
I
do
think
it's
important
I
think
it
is
travesty
that
we
actually
don't
have
the
stuff
widely
implemented,
I'm,
also
working
with
other
folks
who
are
mail,
user
agent
implementers
who
have
implemented
header
protection
that
is
working
between
multiple
user
agents.
Today,
that's
simply
in
a
mechanism
that
is
not
documented
here
and
I
think
the
header
protection
draft
that
we're
working
on
is
going
to
work
for
both
PGP
mom
and
s/mime
with
the
same
mechanism,
and
so
yes
I
fully
support
this.
R
Spell
new
horizon
and
you're
speaking
for
the
pepper,
pretty
easy
privacy
guys.
We
have
four
implementations
that
use
had
a
protection,
but
in
a
way
that
is
small
s
just
end
up
way.
Now,
like
encapsulating
the
whole
message
into
as
a
mime
attachment
to
the
normal
message,
except
that
is
fought,
equals
no,
is
not
yet
there,
of
course,
because
it's
new,
but
if
this
is
going
forward,
people
just
implement
it
as
well,
because
it's
useful
feature
for
the
presentation,
and
you
would
also
support
this
work-
to
go
forward.
Hopefully
now
away
I.
E
B
A
P
Just
say
that
there
are
multiple
implementers
who
are
already
implementing
it.
So,
in
the
event
that
we
don't
document
it
that'll
be
fine.
It'll
just
be
documented
somewhere
else,
but
it's
kind
of
sad
if
the
ETF's
working
group
that's
supposed
to
be
dealing
with
with
the
way
that
email
works
can't
document
the
things
that
people
are
actively
doing
today,
so.
C
P
I
spoke
with
several
folks.
There
was
an
open,
PGP
summit
about
a
month
ago,
where
there
were
people.
There
were
about
two
dozen
people,
many
of
whom
are
mail
user
agent
implementers
and
there
was
active
interest
in
it
and
yes,
I
can
get
more
people
to
participate.
I,
don't
know
that
I
can
get
them
all
on
the
Lance
list,
we'll
see
but
yeah
fair
enough
to.
B
P
Terms
of
like
a
timeline
and
folks
are
doing
this.
They're
people
are
gonna
be,
and
people
are
already
working
on
this.
That's
already
implement
they're,
already
implementations,
so
just
I'm
just
trying
to
make
sure
that
I
can
report
back
to
them
in
a
way
that
they're
not
gonna,
be
like.
Oh
so
you're
telling
me
wait
two
more
years
and
then
there
will
be
a
second
all
implemented.
Then
no
I
mean
I
know
it
might
happen.
I've
been
at
the
hay
tip
for
awhile,
like
I've
seen
I've
seen
the
process.
F
So
chartering
takes
two
to
three
months:
yeah
I
mean
this
computer
charted
in
two
months.
If
he's
our
the
discretion
to
list
now,
I
mean
that
the
hard
deadlines
are
all
present.
We
take
you
four
weeks
like
deal
with
it
and
then
have
to
do
it
to
a
guy,
tell
us
call
and
hospital
chassis
you
looking
at
like
six
to
eight
weeks,
but
you.