►
From YouTube: IETF96-LAMPS-20160722-1220
Description
LAMPS meeting session at IETF96
2016/07/22 1220
A
A
D
A
B
D
B
A
F
F
F
F
Here's
the
note!
Well,
you
probably
have
seen
it
by
now
a
lot
this
week.
Please
review
it
and
if
there's
an
and
the
rfcs
that
it
points
to
here's
our
agenda,
so
we're
going
to
talk
about
the
enhancements
to
s/mime,
to
support,
authenticated
encryption,
email
addresses
that
use
or
internationalized
email
addresses
in
certificates
and
then
one
of
the
curdle
action
items
deals
with
the
new
curves
and
how
to
carry
them
in
certificates.
F
Since
the
people
who
understand
certificates
are
in
here,
we're
going
to
talk
about
the
which
object
identifiers
will
be
used
to
occur
in
that
situation,
that's
the
three
things
and
then,
at
the
end,
we'll
do
some
calls
some
homes
for
whether
some
documents
should
get
adopted
by
the
working
group.
Any
agenda-
bashes,
okay,
Jim
Europe,.
C
C
C
This
is
how
we
do
you
authenticated
encryption,
which
is
what
the
Charter
says.
We
can
declare
victory,
go
home
and
be
happy
at
this
point
in
time.
Next
slide.
Okay,
I
didn't
quite
hit.
The
right
I
lied
on
two
issues:
issue
number
one:
what
version
of
of
s/mime
is
this
right
now
the
document
says
3.5,
because
that's
what
Shawn
Turner
wants
I,
don't
care,
there's
an
open
errata
from
Peter
Gutman,
which
says
oh
look
at
there's
these
things
that
are
called
examples
in
this
document
and
guess
what
they
actually
aren't
examples.
They
aren't
formed
right.
C
They
actually
don't
do
what
they're
supposed
to
do
so.
The
question
is:
do
we
modify
the
titles
on
these?
To
say
they
aren't
examples,
or
do
we
actually
really
make
them
examples
either
way,
works
and
I?
Don't
think
it
matters
then
there's
a
set
of
other
issues
which
we
can
talk
about
in
terms
of.
If,
since
we
have
the
document
open,
do
we
want
to
fix
them
basically
after
discussion
earlier
this
week
with
Russ?
F
C
Issue
number
one:
do
we
change
from
88
syntax
of
a
and
went
to
modern
date?
Syntax
at
this
point
in
time
my
I
would
say
we
leave
things
alone.
It
looks
since
we're
not
actually
changing
the
ace
in
one
module
itself.
There's
note
if
there's
no
particular
reason
to
update
the
module
and
do
something
new
there
may
be
some
additional
security
considerations.
People
want
to
bring
up.
I've
got
a
couple
that
I
probably
need
to
write
relative
to
authenticated
encryption,
but
other
than
that.
C
E
G
A
H
C
Most
of
the
people
are
going
to
want
to
say,
since
we
got
the
document
open,
we
want
to
just
algorithms.
We
want
to
adjust
key
sizes.
There's
a
whole
slew
of
questions
do
do.
Do
we
def
account?
How
hard
do
we
deprecate?
Some
do
we
want
to
add
things
other
than
the
minimums
that
I
currently
have
in
there
and
I
think
that's
probably
a
discussion
that
just
works
better
if
we
take
them
on
one
into
one
one-time
money
at
time
on
the
list
on
next
slide,.
C
Since
we're
adding
this,
we
may
want
to
change
some
of
the
text
in
section
2.7.
In
terms
of
we
give
recommendations
on
what
you
should
do.
If
you
come
up
in
a
situation
where
I
want
to
send
an
encrypted
message
to
somebody
and
I,
don't
know
what
they
do
so
right
now
it
tends
to
be
if
you
want
to
go
all
the
way
down
to
Triple
DES,
because
that's
what
was
supported
in
some
ancient
version
of
s/mime,
that's
fine.
It
may
not
be
the
best
choice,
but
it's
an
acceptable
choice.
C
I
think
we
may
want
to
definitely
eliminate
Triple
DES.
We
may
want
to
think
about
whether
we
want
to
make
language
a
little
bit
more.
You
probably
don't
want
to
think
about
using
AES
CBC,
but
here's
where
you
want
to
say
you
do
so.
That's
is
as
guidance.
It's
not
armed
2111
language,
arts,
a
21-19
language.
This
is
very
hard.
It's
all
shoulds
next.
C
We
talked
earlier
about
header
protection
with
a
small
group
of
people
this
week
right
now
that
the
default
position
on
this
is
we're
not
doing
anything
in
this
document.
If
we
do
something
we'll
do
something
later
after
recharter
said
because
this
is
a
hard
issue,
we
don't
only
want
to
touch
it
right
now.
Next,
actually.
F
C
We're
updating
email
addresses
and
certificates
to
use
the
international
mail
at
email
addresses
interesting
question.
Do
we
need
to
update
the
SYM
certificate
document
to
talk
about
international
email
addresses
as
well
right
now?
That's
not
it's
not
clear
whether
the
Charter
says
do
that
or
not
to
do
that.
I
think
the
Charter
shows
do
that.
C
F
C
I
Student
viral
and
so
Anna
clarity,
kind
of
thing,
so
I
think
there's
a
lot
of
changes
that
we
could
suggest
to
make
to
the
documents
which
would
be
kind
of
good
improvements
to
the
documents
and
I
just
want
to
check
that
we're
all.
On
the
same
page
that
we
accept
that
we
there's
only
a
point
in
doing
those
if
implementations
are
liable
to
follow
them.
H
Hi
sean
leonard,
I
think
we
should
update
s
mine
to
discuss
ai
ai,
also
update
s
mom,
to
talk
about
how
the
inner
s
my
own
content,
which
is
binary,
clear,
clean,
has
or
ought
to
have
utf-8
hitters
consistent
with
the
AI,
and
should
there
be
s/mime
company
compatibility
OID
for
EA
I,
just
topic,
I!
Think
about.
F
C
J
F
F
K
K
So,
what's
being
done
in
this
draft
is
changing
or
creating
a
new
name
type
for
email
addresses
that
would
represent
the
email
address
as
utf-8
as
opposed
to
the
current
RFC,
a
22
name,
which
is
in
ascii,
and
so
this
allows
for
the
local
park
in
particular
to
be
utf-8.
This
dress
also
specifies
that
the
domain
should
be
you
label
or
a
ski,
but
excludes
intentionally
a
labels
and
I
can
get
into
that
later.
K
So
let
me
just
get
into
some
of
the
interesting
sort
of
choice
points,
and
these
could
be
potential
also
open
issues,
but
I'll
try
to
describe
some
of
the
reasoning
behind
this
and,
first
with
regards
to
other
name
versus,
say,
adding
2
to
general
names.
So
the
let
me
first
get
into
the
downside,
so
other
names
means
that
there's
going
to
be
potential
overhead,
there
is
going
to
be
a
new
object,
identifier
added
and
this
will
slightly
increase
the
size
of
the
certificate.
K
The
reason
for
the
reason
for
going
for
other
names
is
that
this
is
the
plate,
the
the
extension
point
in
these
name
types
and
there's
a
lot
of
assumption
that
implementation
seems
to
have
made
about
this.
So
the
types
in
general
names
seem
to
be
hard-coded,
at
least
in
the
places.
Look
like
I've
looked
in
openssl
and
I.
A
comparison
of
general
names
is
basically
just
a
switch
statement
with
all
the
currently
enumerated
names
and
there
isn't
a
default
that
says:
okay,
here's
what
you
do!
K
K
K
However,
this
will
mean
that
then,
if
you
want
to
have
named
constraint,
potentially
a
for
international
email
addresses
or
just
pure
ASCII
local
part
addresses
you'll
have
to
then
have
the
name
constraint
with
both
rc8
you
to
name
as
well
as
smtp,
utf-8
name,
which
could
potentially
increase
the
size
of,
and
usually
these
are
done.
You
know
in
the
CA
certificates
that
it
would
cause
some
expansion
there
potentially
next
slide.
K
Okay,
just
talking
about
the
version
history
and
the
closed
issues,
so
in
Trastevere
one.
Basically,
this
was
about
getting
feedback
that
we
ought
to
just
have,
or
we
should
try
to
minimize
the
choices
for
the
domain
encoding
and
the
worry
with
that
implementations
may
get
additional
choices
wrong
and
then
also
a
request
to
minimize
the
conversions
between
the
different
types
when
doing
the
canonicalization
safer
comparison,
and
also
to
provide
language
in
the
draft
for
specifying
name
constraints
and
comparisons
for
version
02
and
03.
There's
significant
amount
of
language
and
specification
cleanup,
particularly
for
unicode.
K
You
know
changing
the
terminology
from
ace
ascii
compatible
encoding
to
a
labels,
cleanup
of
some
of
the
type
specification
and
also
cleanup
of
the
references
for
the
various
internationalization
RF
seeds.
There
is
also
a
request
to
to
restrict
SMTP
utf-8
name
to
non-ascii
local
parts
and
then
essentially
reserved
RFC,
822
name
for
a
ski
local
parts.
So
you
can
see
then
this
would
then
have
like
you
know,
cause
this
name
constraint
issue
to
to
be
slightly
more
important.
There's
also
a
request
for
additional
line,
comparison,
language,
clean
up
next
leg
and
then
inversion.
K
04,
there's
language
cleanup
and
a
diagram
added
to
help
illustrate
the
name
constraint
and
its
interactions
with
you
know,
between
SMTP
utf-8
name
and
RC,
eight
you
to
name
so
for
the
deployment
situation.
Basically
I've
contacted
the
openssl
folks.
They
say
that
it
should
be
very
doable
to
get
something
added
for
this.
It
would
take
them
about
a
year
because
that's
a
normal
release
cycle
for
doing
updates,
I
have
for.
K
L
That
are
given
it
from
inside
seeker.
One
question
about
the:
what
happens
if
we
have
both
RFC
822
antes,
especially
in
the
security,
because
the
contrary
sections
doesn't
say
anything
about
this,
having
no
both
of
these,
which
in
some
cases
for
action
ipsec
their
matching.
You
know
identities
and
if
you
some
applications
take
you
know
RFC
822,
part
of
that
and
some
applications
taking
out
the
utf-8
version
of
it.
It
might
cause
security
issues.
So
I'd
like
to
answer
that,
one,
because
I
think
the
answer
isn't.
L
Key
yeah,
but
I'm
yeah,
okay,
so
I
mean
yes,
I
was
meaning
that
if
you
have
an
email,
if
I
have
a
I
basic
confessing
to
have
an
email
address,
mm-hmm,
it's
a
it
doesn't
say
it's
in
going
to
be
in
RFC
822
for
a
part
of
that,
it
doesn't
say
it
in
that
utf-8
part.
It's
outside
an
email
address,
so
I'm
supposed
to
match
it,
probably
in
after
T
sub
supposed
to
match.
It
involved
feels
great.
F
C
H
C
We
now
a
slight
digression
into
the
curdle
meeting,
okay
next
time.
So
right,
if
you
remember
with
the
slides,
are
again
so
so,
basically
we
start
with
just
implementing
zobelle.
If
we're
looking
at
EDD,
SA
and
Ed
diffie-hellman.
There
are
some
simple
things
that
we
need
to
keep
in
mind
when
we're
making
decisions.
Private
keys
are
always
octet
strings.
In
this
case,
they
aren't
introduce
a
public
King
public
key
is
also
not
pestering.
However,
the
format
of
what's
in
that
octet
string
is
different.
C
If
you're
doing
ed,
the
sa
vs
is,
if
you're
doing
EDC
ed
ed
cdh
get
my
kit,
my
yeah.
That
means
that
one
of
the
things
we
have
to
make
sure
we
do
is
we
identify
what
which
one
of
those
which
size
were
dealing
with
a
private
key
which,
whether
it
is
for
diffie-hellman
or
whether
it's
the
signatures
and
there's
also
question
whether
there's
other
potential
dippy
home
and
key
agreement,
algorithms
that
may
show
up
again
in
the
future.
The
original
ed
the
H
document
did
talk
about
mqv.
C
It's
just
not
clear
how
much
m
QV
is
actually
used
in
anything
in
the
real
world.
Next,
so
trying
to
go
through
Simon's
document.
This
is
basically
the
table
of
what
I
came
up
with
where
things
go
and
what
boys
would
be
put
in
two
different
places.
It's
something
that
I
don't
think
actually
works
with.
C
What
we
currently
have
I
did
call
out
each
of
the
courage
separately,
because
one
of
the
things
that
has
been
made
clear
by
the
people
who
have
wrote
the
e
dds
a
document
is
that
we
have
to
make
sure
we
keep
the
pre
hash
and
the
non
pre
hash
keys,
separate,
because
otherwise
you
can
make
it
there
are
attacks
between
them
if
used
them
on
the
same
on
both
of
them.
So.
F
C
I
wanted
to
make
sure
that
the
document
originally
used
an
enumeration
in
in
terms
of
looking
at
the
cigna,
the
public,
the
signature
algorithms
on
there
was
suggested
that
basically,
we
should
probably
go
to
a
noite
to
mix
things
life
simpler
arm
but
well,
but
we
kind
of
basically
have
looked
at
this
and
said
it's
kind
of
fun.
Okay,
next
slide!
C
So
if
we
do
this
based
upon
what
we
actually
currently
have
and
do
all
the
logical
extensions,
obviously
we
have
to
kill
the
ID
ec
public
key
portion
out
of
all
of
the
signature
algorithms,
but
it's
a
little
bit
clearer,
moving
things
straight
across
so
that
the
same
always
are
showing
up
straight
across
in
a
little
bit
better
fashion
than
what
they
are.
Otherwise,
we
as
I
sighs,
exchanged
mail
with
Kenny,
and
he
basically
says
we
really
ought
to
be
removing
the
I
Dec
public
key
from
the
first
two
lines
as
well.
C
There
are
any
known
attacks
that
we
actually
currently
have,
but
historic
evidence
suggests
that
we
don't
know
that
attacks
may
not
come
in
the
future.
The
tighter
you
bind
the
key
to
an
algorithm,
the
better
off
you
are,
and
so
this
is
actually
at
you
know
a
plight
Lee
cleaner
one,
then
the
one
of
the
current
draft.
However,
if
we
go
to
the
next
slide,
we
come
up
with
one:
that's
actually
in
some
respects,
even
clean
up,
because
it
doesn't
have
any
of
the
if
it
were
reducing
everything
down
to
a
single
oi.
C
C
So
real,
fast
review
of
the
benefits
between
the
last
two
proposals
up
there
arm
the
a
encoding
is,
is
more
or
less
six
of
one
half
a
dozen.
The
other
is
that
both
easy
to
do
they're
both
reasonably
unwell,
understood.
There
are
some
potential
issues
in
terms
of
publishing
and
negotiation
of
algorithms.
C
I
can't
come
up
with
anything
specific,
but
that
was
my
one
worry
about
it
in
that
it
may
be
easier
to
say,
I
make
currently
what
you
say
is
I'm
going
to
negotiate
an
ecdsa
algorithm
I'm,
not
specifying
I'm
negotiating
these
ecdsa
for
specific
key
with
it,
with
with
the
bend
with
the
Benjamin
proposal,
basically
we're
when
you
do
that
ago,
you're
negotiating
the
algorithm
and
the
key.
At
the
same
time,
there
was
actually
somebody
on
the
list.
C
I
cannot
remember
who
it
was,
who
basically
says
the
fact
that
you
can't
negotiate
them
separately
is
really
good,
because
he,
when
he
goes
off
and
looks
at
the
certificate
transparency
stuff,
he
can't
figure
out
whether
or
not
he's
going
to
support
that
algorithm
until
he's
actually
grabbed
the
certificate
and
done
all
of
that
work
because
he
doesn't
know
what
the
actual
curve
is
he's
playing
with.
He
just
knows
that
it
is
ecdsa.
C
There
is
a
possibility,
as
future
algorithms
come
along.
If
in
if
you've
used
the
the
middle
proposal,
you
just
define
the
curve
Voyager
done.
We
use
the
Benjamin
proposal.
You
have
to
define
all
four
of
those
or
all
four
of
those
guys
all
three
new
oils,
so
you
have
to
have
one
for
you
see
da
e
cdh
you
have
to
want.
We
have
one
for
EDD
SI.
If
you
have
one
for
EDD,
SI
prehaps,
it's
not
that
hard
to
get
eggs.
C
C
H
C
Maybe
one
symmetric
key
is
actually
essentially
which
you
get
a
peek
ses-8.
It's
been
updated
so
that
the
public
key
field
is
down
there
in
the
bottom
other
than
that
is
essentially
the
same
thing
as
being
a
csa.
So
if
you
do
diffie-hellman
or
DSA
or
RSA
is
very
simple,
you
do
what
you
do
was
on
the
left
hand,
that
you
do
when
symmetric
key.
You
put
that
integer
or
that
price
of
that
private
key
structure
into
the
octet
string,
you're
done,
if
you
do
ecdsa
or
e
cdh
today.
C
What
you
do
is
you
put
the
easy
prey
private
key
in
that
field
and
look
at
all
the
nice
duplications
you
have
there.
So,
basically,
what
we
want
to
do
is
for
the
the
Montgomery
curve
for
all
these
new
curves.
We
want
to
say
that
the
private
key
is
going
to
be
an
octet
string
and
you
put
the
octet
string
into
that
private
key
field
in
the
PKS,
a
blob
and
you're
done.
You
know
you
don't
have
any
worry
about
whether
this
matches
that
and
so
forth
as
you
go
along
next.
F
F
C
H
C
C
H
F
Questions:
ok,
I
want
to
take
a
quick
home
at
this
point.
Does
this
group
want
to
recommend
to
curdle
that
the
david
benjamin
proposed
will
be
adopted?
Yes,
hum
no
dick
hum
now,
if
you
think
this
group
should
recommend
the
david
benjamin
proposal
to
the
curdle
group,
how?
Now,
if
you
think
this
group
should
not
make
that
recommendation,
thank
you.
F
F
C
F
Can't
adopt
something
we
haven't
had
had
opportunity
to
read
yet
so
once
coming
to,
we
have
in
hand
the
two
we
have
in
hand
the
ones
I
want
to
talk
about.
So
the
first
one
is
the
one
that
Jim
presented
about
message,
which
is
basically
the
update
of
the
what
the
sm
I'm
working
group
had
called
the
message
spec
and
it
is
to
incorporate
what
is
needed
to
do
authenticated
encryption
in
SF
I'm.
F
F
You
and
the
second
term
has
to
do
with.
Are
we
ready
to
adopt
the
document
that
way
walked
us
through,
which
is
for
the
eai
email?
Internationalized
email
addresses
how
to
carry
them
in
certificates,
so
you'll
be
home
now
for
adoption
or
not
ready.
So
if
you
think
it's
ready
for
this
working
through
to
adopt
home
now,
if
you
think
it's
not
ready
home
now
very
straightforward,
alright,
so
we've
agreed
to
send
the
recommendation
to
the
colonel
working
group.
We've
adopted
the
two
documents
and
that's
all
the
business
we
had
for
today.