►
From YouTube: IETF104-LAMPS-20190326-1120
Description
LAMPS meeting session at IETF104
2019/03/26 1120
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
C
That
said,
this
is
an
ITF
meeting.
Note
well
applies
by
this
time.
You've
seen
this
slide.
A
lot
of
you
know
in
your
various
meetings,
but
please
these
are
the
the
rules
about
the
standards
process
and
and
conduct
code
of
conduct
and
IPR
disclosures.
So
we
recently
completed
two
sym
documents:
sort
of
they're
in
the
earth
48.
So
we
know
if
there
are
see
numbers
are,
but
we
don't
they're
not
yet
we
haven't
actually
seen
the
official
publication
announcement
yet.
C
D
C
E
F
F
C
All
right,
the
next
one
is
the
hash
of
root.
Key
third
extension
that
went
through
a
fairly
long
last
call
came
back
to
the
working
group
to
sort
some
issues.
They
were
sorted
there's
a
couple
things
that
were
declared
in
the
rough,
but
then
it
was
sent
back
to
the
is
G,
so
I
believe
ITF
last
call
is
over,
but
iesg
evaluation
is
not
yet
finished,
but
they
have
not
sent
any
issues
back
to
us.
So
there's
nothing
to
talk
about
the
next
two
are
the
shake
documents:
P
kicks
and
CMS
Quinn.
C
They
in
the
room,
okay,
well,
I,
don't
see
them
the
we're
in
the
same
situation
with
them.
They're
with
the
is
G.
We
have
not
received
any
comments
yet
so
nothing
to
do
until
they
do
the
next
one
is
hash
based
digital
signatures.
That
one
was
just
sent
to
the
is
G
I.
Have
some
slides
posted
I'm
just
going
to
jump
to.
B
C
C
The
last
issue
that
was
sorted
was
how
to
deal
with
the
two
situations
in
CMS
when
they're
signed,
attributes
and
there's
not
signed
attributes.
That
was
the
last
discussion
on
the
list.
Thanks
Jim,
for
that
one,
he
pushed
really
hard
for
the
same
approach
being
used
across
different
places
and
anyway
that
was
the
winning.
So
we
completed
last
last
call
and
it's
been
sent
to
the
isg.
We
have
not
yet
heard
of
security,
ad
review
being
done.
A
C
G
C
Alright,
the
first
is:
why
would
you
want
to
mix
a
PSK
with
other
key
management
techniques?
The
answer
is
for
quantum
protection.
This
is
a
short-term
solution.
The
long-term
solution
is
quantum
resistant,
public
key
crypto
algorithms,
there's
a
whole
list,
competition
going
on
regarding
that
I'm
not
trying
to
usurp
it
just
trying
to
have
something
for
now.
C
Next,
so,
basically,
what
you
do
is
you
mix
a
PS
k
with
a
key
that
comes
from
one
of
the
other
approaches,
key
transport,
meaning
an
RSA
like
algorithm,
so
you
mix
a
PS
k
with
the
key
that's
distributed
under
RSA
and
key
agreement.
A
diffie-hellman
like
scheme,
so
the
resulting
shared
secret
gets
mixed
with
the
PS
k
to
produce
the
resulting
key.
So
there's
a
mechanism
defined
for
each
of
those
in
the
draft.
C
This
is
slides
unchanged
from
last
time.
It
just
explains
the
two
approaches
which
I
just
summarized.
This
is
more
detail
next,
so
summary
to
the
recent
changes.
C
We
talked
about
using
the
key
agreement
scheme
to
produce
ke
k1,
mixing
it
with
the
PSK
to
produce
ke
ke
to
its
just
so
that
the
terminology
lines
up
across
documents
once
we
have
so
to
do
that,
the
a
key
derivation
function
is
used,
and
so
we
defined
this
one
called
the
CMS
Ori
for
PSK
other
info.
Okay
and
basically
that
is
the
other
info
used
as
part
of
the
key
derivation
input.
And
that
is
the
place
where
we're
putting
the
PSK.
In
the
previous
version,
we
were
concatenated
the
shared
secret
and
the
PSK.
C
This
basically
provides.
If
you
go
read
about
h,
KDF
and
some
of
the
other
structures.
They
talk
about
other
private
info
as
one
of
the
inputs
to
at
the
PS
k
and
that
that
seemed
to
be
the
place
to
put
it
just
from
a
aligning
with
the
terminology
section.
So
that
was
the
change
that
was
made
and
then
we
added
examples
to
append
to
Appendix
A
and
appendix
B.
1
does
a
key
trans
example
in
one
does
a
key
agreement?
C
Example
next
slide
so
I'm
calling
for
review
I
think
the
draft
is
now
ready
for
working
group
last
call
now
that
it's
got
examples
it
but
I'd
love
for
someone
to
check
the
examples,
because
they're
just
a
Python
script
that
I
threw
together
to
the
slam
it
all
together.
I
found
some
Python
asn.1
libraries
and
anyway,
please
send
comments
to
the
list.
Since
I'm
author
of
this
document,
Tim
will
make
all
of
the
consensus
calls
related
to
it.
C
C
H
J
K
So
how
do
we
sit
in
order
and
myself
wrote
the
draft
on
the
topic-
header
protection
that
contains
some
generic
use
cases
and
a
first
set
of
requirements
to
be
a
discussion
on,
and
then
there
is
some
implementation
report
on
the
topic
most
describing
how
the
Peck
implementation
is
doing.
The
header
protection,
which
is
pretty
similar
than
what's
in
the
s/mime
button
complete
later
next
slide,
please
so
to
make
room
for
this
presentation
is
that
we
have
a
pending
reach.
K
Otto
is
adding
this
shot
item
for
adding
a
topic
to
encrypt
all
signature
of
petals
I'm
not
going
to
the
details
of
this
next
slide.
Please
so
I
thought
the
picture
says
11,000
volts.
So
basically,
what
we
have
a
channel
is
the
left
side.
He
has
a
head
on
and
we
have
a
content.
The
content
can
be
protected
easily,
but
the
header
cannot
be
protected
as
such
that
s
my
proposed
since
version
3.1
is
to
put
the
whole
message
and
drop
it
into
a
new
mail
message
so
that
you
can
protect
also
head
apart.
K
There
is
one
for
sure
and
a
couple
of
other
implementations
that
may
have
implemented
in
s
mine,
and
if
you
go
to
the
next
slide,
please
there
is
a
pimp
lamentation.
It
doesn't
do
it
for
s
mine
yet,
but
is
planning
to
replace
mine
or
test
on
it
for
PGP.
In
this
way
it's
pretty
similar,
except
for
the
message.
We
also
include
the
public
key
to
the
header
protection.
K
Next,
please
so
now
it's
a
site
that
doesn't
require
kind
of
feedback
from
the
stage
over
the
floor.
This
kovitch
protection-
they
will
use
case
science
group,
so
we
have
for
sure
signature
and
encryption
is
a
use
case.
There
is
probably
also
a
use
case
for
signature
only
what
is
being
done
clear
if
we
need
to
address
a
use
case
encryption
only
also
or
whether
we
can
just
like
consider
this
as
the
same
as
it's
the
first
one
like
signature
and
encryption,
all
that
this
needs
to
be
separate
or
we
can
lift
it
completely
out.
G
This
is
the
no
can't
go
more
from
this.
He
are
you
so
I
think
we
need
to
say
something
specifically
about
see
yeah,
just
because
it's
gonna
happen
and
I
do
think
that
there
are
user
interface
concerns
that
come
up
when
you
have
encrypted
headers
in
an
encrypted
message
that
doesn't
have
a
signature,
so
I
do
think
that
we're
gonna
need
to
deal
with
see
one
way
or
the
other
I.
Don't
like
it.
It's
kind
of
annoying
that
we
have
this
messiness,
but
that's
the
you
know
we're
inheriting.
You
know
this
is
the
problem.
G
L
L
G
This
is
DK
Jaden,
sir
I'm.
Sorry,
if
what
we
say
if
we
decide
that
what
we
want
to
say
is
user
agents
receiving
a
message
like
this
should
not
display
any
sort
of
security
indicators.
That's
fine,
but
we
still
need
to
say
something
right.
That's
what
I'm
said
like
the
use
case
needs
to
be
addressed.
L
K
Okay,
thanks
so
I,
don't
think
you
have
so
much
discussion
on
this.
It's
basically
which
interaction
case
we
need
to
support,
like
certainly
if
both
clients
have
bought
new
head
protection
mechanisms,
but
we
also
need
to
probably
support
that
if
trying
to
supports
that
new
mechanism
is
talking
to
a
client
who
doesn't
know
anything
about
header
protection,
we
probably
also
have
say
something
about
the
other
thing.
K
This
is
probably
causing
more
discussions
like
how
well
we
deal
with
the
legacy
stuff
I
heard
different
statements
like
we
should
leave
the
legacy
completely
out,
probably
can't
do
that.
We
probably
have
to
deal
with
what's
already
in
standard
since
s/mime
3.1,
and
we
also
probably
need
to
think
when
we
extend
this
to
the
PGP
world
about
other
implementations.
G
Dkg
again,
we
do
need
to
think
about
what
these
interaction
cases
are,
and
so
again,
like
I
mean
this
is
the
same
comment
that
I
made
before
but
like
this
is
tedious,
and
this
is
what
we
signed
up
for
a
long.
We
deal
with
encrypted
email,
so
I
really
do
appreciate
that
we
have
this
list
of
the
different
cases.
I'm,
not
sure,
maybe
there's
a
way
that
we
can
coalesce
some
of
them,
but
I
do
think
that
we
need
to
be
thinking.
G
We
do
at
least
explicitly
say
here's
what
happens
with
it
with
legacy
clients
and
here's
what
we
expected.
Here's,
what
we
expected
to
be
done,
and
if
the
answer
is,
we
can't
figure
out
how
to
fix
them
and
that
interaction
and
that's
fine,
but
we
need
to
call
that
out
in
the
draft
and
say
this
is
something
that
we
don't
like
it.
D
Just
very
much
in
line
with
this,
if
we
know
of
I,
know
inside
the
facts
and
major
clients
which
a
legacy
then
and
depending
on
the
course
we
you
know,
we
decide,
you
know
then
we'll
it.
But
if
we
can
document
at
least
and
say
you
might
observe
this
in
the
wild.
This
is
the
sort
of
behavior
and
we
might
or
might
not
have
a
recommendation.
K
K
We
probably
don't
have
time
to
go
into
the
requirements
whether
or
not
it
makes
sense
that
I
should
be
changed.
So
we
probably
don't
have
the
time
today
to
discuss
about
tech,
but
for
me
it
would
be
most
helpful
if
I
know
if
I
missed
something
or
if
we
missed
something
so
I
speak
to
in
general
requirements
set
aside
and
receive
site
requirements
in
general.
We
need
to
specify
the
format
you
are
going
to
use
the
mime
structure,
content
type
and
so
on.
K
This
will
be
in
the
next
presentation.
Malik
say
we
explained
that
you
need
probably
to
find
the
means
to
distinguish
between
a
robot
message
or
just
a
rocked
message
for
encryption.
Next,
please,
then,
the
sender
requirements
is
in
the
signature
case.
You
need
to
define
which
header
fields
we
should
protect.
K
In
the
encryption
case,
we
need
to
figure
out
which
header
fields
need
to
be
left
in
clear,
but
we
also
need
to
think
about
what
should
be
not
in
clear,
send
a
waterway
on
and
there's
also
like
requirement
which
other
fields
you
should
not
include
in
any
header
protection
part.
For
example,
the
BC
seemed
a
better
idea
to
include
that
to
have
a
protected
field
because
that's
probably
not
meant
for
the
final
destination.
K
Then
draft
I
also
discussed
a
bit
about
kind
of
the
future
negotiation
mechanism,
not
sure
we
need
that
or
not,
but
probably
we
should
be
able
to
tell
we
support
this
new
header
protection
just
to
reach
the
cording
to
the
new
one,
and
also
we
should
probably
think
about
how
the
subject
header
field
can
be
piece
displayed
to
have
a
protection
on
our
clients.
So
if
we
do
something
with
the
message
and
the
receiver
needs
to
figure
out,
there
is
the
subject.
So
what
we
need
to
think
about
that
receiver
requirement
is
next
slide.
K
We
need
to
think
about
if
there's
conflicting
information
in
the
protected
area
and
the
unprotected
area,
how
we
deal
with
that.
We
solve
it
at
unprotected
areas
overwritten,
but
a
lot
of
people
like
to
have
other
requirements,
and
we
need
again
to
think
about
the
detection
of
the
man
in
the
middle
attacks,
especially
downgrade
attacks
and
again,
the
indication
of
detection
for
support
of
new
header
protection
comes
here
as
well.
In
a
receiver
side,
next
I
skip
the
requirements
for
interaction,
incorporation
with
the
legacy,
clients.
K
D
K
G
This
is
DJ
G,
so
I
think
this
is
a
great
enumeration
of
requirements
that
we
can
nitpick
about
which
things
belong
exactly
and
under
what?
What
section
here,
but
I,
think
you've
done
a
good
job
of
identifying
the
concerns.
I
will
note
that
ps3
there
is
actually
is
actually
about
legacy
clients
right,
so
you
you
haven't
skipped
legacy
clients,
that's
that
in
fact,
ps3
made
and
yak
be
the
specific
question
about
legacy
clients,
so
yeah.
K
K
So
for
those
of
you
who
want
to
know
more
about
our
implementation
and
what
we
intend
to
do,
yeah
just
got
a
mailing
list
approved
for
missing
elements.
For
this
same
is
centralized
usable
privacy.
You
find
here
the
information
how
we
can
sign
up
and
we
decided
to
make
a
non
working
group
meeting
on
Thursday
evening.
It's
after
all
the
sessions
there
will
be
an
introduction.
K
There
will
be
some
researchers
from
University
of
Luxembourg
speaking
about
specific
topics
in
the
area
and
we'll
give
a
status,
update
documents
and
probably
talk
about
some
issues
and
how
we
go
on
to
further
and
there's.
Also
a
link
to
the
current
agenda
welcome
to
join
there,
and
they
also
have
some
list
if
you
could
indicate
that
you're
coming
so
or
if
we
know
how
many
people
to
expect
it
yeah,
that's
I
think
it's
my
last
slide.
If
there
are
any
questions,
feel
free
to
ask
them
now.
Otherwise,
Alex's
continue
with
the
same
topic.
G
Alright,
sorry,
this
is
dkg
one
more
one
comment
about
about
hiding,
so
I've
been
alive.
Half
written
draft
that
I
meant
I
have
a
draft
email
of
comments
on
this.
That
I
haven't
something
to
list
yet
and
I
will
shortly,
but
I
wonder
thing
I
want
to
mention.
You
talked
about
the
mime
structure
issues
I!
G
If
your
message
payload
happens
to
have
the
following
structure
right
I
think
we
can
say
stuff
about
how
the
cryptographic
envelope
is
going
to
be
structured
to
make
sure
that
this
works,
but
I,
but
I
think
it
would
be
good
to
make
sure
that
we
prune
out
stuff.
That
says
you
have
to
have
a
structure
in
this
way.
We
may
need
so
I'm,
just
wary
of
that
particular
issue,
and
so
I'm
happy
to
work
with
you
to
try
to
try
to
make
sure
that
we
can
get
that
in
shape.
G
K
Just
a
short
answer
to
that,
this
is
like
stuff
that
I
made
in
pretty
short
time,
and
this
is
probably
what
happens
if
you
have
in
mind
14
implementing.
Then
it's
probably
coming
like
this,
but
for
sure
I'll
put
this
for
discussion
and
it's
not
meant
to
be
like
just
what
we
won't
tell
so
it's
super
fit
for
everybody.
Everybody
should
be
happy
about.
It
sounds
good.
So
it's
not
it's
not
my
intention
to
enforce
anything
of
our
implementation.
You
go
I'm
happy
to
help.
D
D
D
Right,
so
this
is
basically
stating
the
problem
and
previous
presentation
done.
A
very
good
job
and
talking
about
requirements
are
specific.
You
know
disagreeing
in
an
outer
headers
and
you
know
what
exactly
you
want
to
put
in
an
outer
if
the
inner
is
encrypted.
You
know
the
office
gate
and
all
kind
of
scenarios.
D
Right
and
the
main
reason
why
we
have
this
problem
is
because
most
of
the
Boyd
clients
they
don't
support
the
text
in
accountancy,
so
something
needs
to
be
done
next
slide
right
and
just
yeah.
Ideally,
actually
it
might
be
possible
requirement.
We
might
want
to
try
to
address
the
problem
in
the
same
way
for
sy
man,
open
PGP.
That
might
not
be
a
strong
requirement,
but
it's
nice
to
have.
D
So
the
problem
with
What's
in
I
think
the
document
is
on
all
48.
People
already
know
their
RFC
number,
but
so
there
is
ambiguity
about
whether
you
know
if
you
want
to
throw
the
message
or
if
you
want
to
protect
header
some
clients,
you
know,
wouldn't
have
a
way
to
distinguish
that.
Oh
so
it
would
be
nice
to
have
a
extra
field
signal
in
the
difference.
D
D
Proposal
what
we
do
next
will
started
talking
about
requirements,
so
I
don't
suggest
we
should
publish
our
vision
requirements
but
I
think
it's
very
useful
to
discuss
them
and
agree
on
the
main
goals,
and
at
least
you
know,
must
have
nice
to
have
this
sort
of
thing.
I
suggest
between
now
and
Montreal.
We
try
to
test
like
I
will
be
able
to
update
my
implementation
to
implement
a
the
approach
and
I
can
generate
messages.
We
can
try
to
test
and
see
how
they
display
in
legacy
clients
and
try
to
see.
D
If
there
are
any
unusual
you
artifacts
or
our
error
conditions,
these
sort
of
things-
and
maybe
we
can
do
something
for
hackathon
this
Montreal,
then
once
we
have
more
information,
we
can
have
a
discussion.
Working
group
pick
one
solution
and
then
the
final
step
is
try
to
write
these
specific
instructions
about
minimizing,
unprotected
header
fields.
You
know
what
the
recommendations
are
sounds
very
easy,
but
we'll
see
how
it
goes.
N
Can
you
guys
hear
me
yeah,
okay,
great
so
I'm
in
case
you?
Don't
man
Krista
Bennett
I
am
the
code
monkey
for
the
engine-room
pep
and
I
have
no
religious
feelings
about
this,
but
I'm,
probably
one
of
the
few
people
who's
actually
tried
to
implement
both
so
far
and
I
just
wanted
to
give
a
quick,
I
guess
a
quick
impression
of
what
the
main
problem
for
me
was
as
an
implementer
and
again
I
have
no
religious
feelings
here.
We
didn't
actually
try
to
implement
generation
of
memory
hole,
and
this
was
early
on.
N
So
the
draft
was,
you,
know,
kind
of
funny
statements,
kind
of
hard
to
tell
what
was
intended.
Well,
it
wasn't
from
memory
hold.
The
problem
for
us
is
that
you
really
can't
tell
implementers
what
kind
of
mind
libraries
they're
going
to
use
right.
We
all
have
different
things
that
we
have
behind
behind
the
scenes
and
parsing.
That
was
a
real
pain
because
I
had
to
hack
the
mind
parser.
N
The
latter
approach,
where
you're
just
saying
okay
I'm,
going
to
move
the
message
down,
I'm
going
to
take
out
the
stuff,
I
need
and
stick
it
in
the
envelope
and
off
we
go
so
it's
it's
not
it's
not
really
anything
more
than
a
comment,
but
if
we
had
some
sort
of
mechanism
to
distinguish
between
wrapped
messages
and
unwrapped
and
forwarded
messages,
that
will
be
incredibly
helpful
because
what
we
see
in
Thunderbird
right
now
also
because
I
made
a
little
implementation
boo-boo,
but
that's
another
story.
N
What
we
see
in
Thunderbird
right
now
is
that,
of
course,
it
does
look
fairly
ugly
because
people
get
a
forwarded
message
and
they
don't
know
why
so
I
think
that's
an
important
thing
to
do,
but
I
also
just
like
I,
said
from
an
implementation
point
of
view,
manipulating
a
data
structure
where
you
move
something
from
one
node
in
a
tree
and
you
wrap
it
in
something
else
and
stick
it
in
another.
Node
in
a
tree
makes
generation
and
parsing
a
lot
easier
for
most
people,
because
most
parsers
will
actually
accept
this.
D
G
This
is
deer,
I
mean
my
main
comment
is
just
like
I
think
that
this
draft
and
and
Bernie's
draft
seem
like
there.
There's
probably
should
be
one
draft
ultimately
that
the
working
group
works
on.
So,
if
I'm
happy
to
talk
with
folks
about
how
we,
how
we
join
them
and-
and
it
doesn't
make
sense
to
have
two
drafts-
that
each
specify
two
different
mechanisms
so
I
hope
we
can-
we
can
just
consolidate
into
one
and
if
we
can
get
the
Charter
updated,
then
maybe
we
can
make
it
just
the
one
document.
O
These
cases
that
we're
looking
at
are
because
it's
a
flow
signatures.
You
should
be
using
an
HSM
to
do
the
signing,
we're
looking
at
CA
certificates
and
code
signing
certificates
because,
mostly
friend
entities
you
might
not
want
to
be
using
an
HSM
to
sign
entity
certificates
or
to
do
interactive
signatures.
O
There
is
a
question
on
the
list
whether
CMS
hash
tags
was
enough.
Our
draft
also
defines
X
MSS
and
XM
s,
SMT
algorithm
identifiers
so
know
also
RFC
84,
1080
419,
defying
EDD
si
in
two
different
drafts:
I-
guess
not
honest
Oh,
so
I
presented.
Actually
this
no
I
presented
this
remotely
in
Bangkok,
and
this
is
just
an
update
of
the
changes
since
then,
basically
aligning
with
Russ's
draft
to
sign
the
full
message.
O
Instead
of
signing
the
pre
hash
of
the
message-
and
there
was
also
just
an
sn1-
including
fix
I-
got
some
clarification
from
Jim
that
we
didn't
need
this
extra
octet
string.
Wrapping
of
the
signature
and
I
just
wanted
to
make
a
note
about
full
message.
Signing
we
got
this
from
a
partner
and
HSN
partner,
basically
saying
that
for
large
messages,
if
you're
gonna
sign
the
full
message
streaming,
avi
may
be
needed
because
HSM
can't
store
the
entire
message
in
memory
and
they
may
not
like
streaming.
O
Api
is
because
it
adds
session
state
to
do
their
api's.
This
might
not
be
so
much
of
a
problem
for
x.509
and
CMS.
If
messages
are
generally
small,
maybe
more
so
an
x.509,
if
you're
starting
to
add
large
quantum
safe
public
keys,
but
even
then
I,
don't
think
those
keys
will
be
so
large
that
a
HSM
can't
store
them
in
memory.
Next.
O
So
really
just
asking
for
adoption
of
this
draft
and
whether
there's
any
comments
I've
been
aligning
it
with
CMS
hashtags.
If
it's
adopted,
we
could
also
possibly
align
it
with
RFC
84
Toni
just
so
that
has
similar
structure
for
the,
because
EDD
DSA
also
does
the
full
message
signing
might
make
sense
to
have
similar
structure
between
the
drafts
so.
G
Yeah,
that's
funny
yep!
It
would
be
really
useful
if
the
draft
says
anything
about
a
streaming
API
to
clarify
that
it
is
specifically
a
streaming
API
for
signing.
Only
we
have
a
long
history
of
making
screwing
up
streaming.
Api
is
for
verification
where
you
start
emitting
data
before
you
emit
the
signal
that
the
data
is
actually
secured
so
I.
It
sounds
to
me,
like
the
reason
why
you
might
need
this
form.
G
O
M
G
So
my
understanding
was
that
you're
saying
we
need
the
streaming
API
for
signing,
because
it's
an
HSM
doing
the
signing
and
the
HSM,
but
is
not
an
HSM
during
the
verification,
I
hope
right.
No,
so
if
the
rationale
for
the
streaming
is,
HSMs
have
limited
memory
and
they
can't
handle
the
entire
document.
That's
just
signing
only
requirement.
Agreat,
okay,.
L
O
F
L
F
P
Quinn
dang
at
NIST
since
I
see
there
a
lot
of
people
here.
I
have
a
question
for
the
group
thing
about.
So
when
we
sign
certificates,
the
the
key
generation
time
is
is
not
a
problem
here.
So
why
do
we
have
to
go
to
multiple
level?
Three,
instead
of
just
one
one,
one
one
three
one
big
tree
so.
P
P
Q
C
To
my
understanding,
is
it's
a
trade
off
there
of
time
to
generate
the
keys,
because
if
you
use
multiple
trees
in
the
HSS,
you
only
have
to
generate
the
top
tree
and
one
of
the
branches
under
it.
You
don't
have
to
generate
all
the
entire
tree
of
trees
key
until
you
need
to
produce
the
first
signature
in
the
next
tree.
That's.
B
P
F
Q
P
F
C
O
I
Q
There,
the
hour,
okay,
after
these
exhausts,
these
slides,
are
exciting.
Basically,
you
again
we're
looking
at
postponed
certificates,
this
basically
saying
gee.
Why
do
we
want
them?
I?
Think
we
can
pass
on
that?
Hello?
Okay,
sorry
about
that
post.
We
this
about
first
slide
about
those
clown
certificates.
Why
we
need
them?
Q
We
can
pass
on
that
when
we're
looking
at
post
kalam
certificates
are
to
prop
me,
it's
easy
enough
to
say:
well,
these
this
candidate
will
basically
consign
it
and
I
identify
algorithm
identifier
and
just
use
it
that's
easy,
but
there
are
two
remaining
problems.
One
is
that
we
not
fully
trust
these
new
algorithms
and
because
of
quantum
computers,
we
may
not
trust
the
old
Algren
leader,
and
so
what
we
do.
The
suggestion
we
have
is
to
have
new
composite
certificate
signatures
which
actually
combine
multiple
algorithms,
so
that
we
don't
trust
any
one
of
them.
Q
We
can
trust
that
not
all
of
them
will
be
broken.
The
other
thumb
that
we
do
not
address
in
my
recurrent
to
draft
is
backwards.
Compatibility
yeah.
What
we
plan
to
do
is
actually
use
both
parallel
certificates,
one
with
the
old
RSA
or
ECDSA
certificates,
algorithms,
and
one
with
these
new
post
quantum
algorithms,
which
would
most
likely
include
the
the
composites.
Q
What
are
basically
our
algorithmic.
It
has
public
key
public
keys
and
signatures
as
outcome
identifiers,
and
so
we
simply
do
is
just
combine
them
to
into
a
larger
algorithm
which
is
treated
as
a
single
signature
algorithm.
So
if
public
key
would
basically
be
just
be
a
sequence
of
the
various
public
keys
for
the
various
algorithms,
the
signature
would
be
just
a
sequence
of
the
very
signatures.
All
signing
the
exact
same
data
and
the
algorithm
ID
would
be
just
be.
Q
The
standard
arbitrary
ID,
followed
by
a
sequence
of
the
various
component
identifiers,
and
so
with
doing
that
we
can
basically
all
the
certificate
looks
basically
like
a
normal
certificate,
just
with
a
different
with
a
different,
a
newer
algorithm,
and
we
also
would
need
to
take
a
look
at
how
to
make
sure
that
the
signer
and
and
the
receiver
can
all
understand,
understand
this
newer
algorithm.
But
that's
going
to
we're
gonna
have
to
address
that
or
any
sort
of
new
algorithm.
Q
C
L
L
R
Hello,
yes,
I'm
the
primary
editor
on
this
draft
so
max
we
had,
we
showed
to
you
in
August
I
think
we
just
cross
because
we
wanted
to
get
involved
in
what
you
were
writing,
but
then
we
didn't
get
involved
in
your
group,
so
yeah
I
would
love
to
be
involved
with
you,
I
think
we
can
should
really
merge.
I!
Think
it's
I
think
we
sort
of
developed
the
idea
independently.
Maybe
your
language
came
in
yeah
I
would
love
to
be
involved
here.
That
wasn't
meant
to
be
a
slight.
R
C
I
Welcome
everybody
I
will
hurry
up
with
my
slide,
so
I'm
going
to
present
a
work
we
did
at
Siemens
on
a
profiling
CMP
for
industrial
use
cases
next
slide,
so
currently,
CMP
is
quite
in
practical
use
for
for
a
number
of
years,
so,
on
the
one
hand,
see
a
vendors
use
it
for
our
a
to
see
a
communication
and
also
in
the
mobile
network,
backbone.
Cmp
is
in
use
for
over
10
years
now
and
in
the
train
control
environment.
Cmp
is
also
used
for
certificate
management
and
therefore
the
next
slide.
I
Please,
and
we
see
quite
a
lot
of
features
in
CMP
too
much
features.
Then
then
I
used
to
need
it
really,
but
we
see
quite
a
lot
of
features
that
are
yeah
very
good
in
industrial
machine
to
machine
environments
like
self-contained
messages,
support
for
end-to-end
security
over
a
number
of
hops,
or
out
of
bantam
transport
mechanisms
or
very
small
polling
messages
and
invent
conformation
and
things
things
like
that,
and
that's
why
we
yeah.
J
I
That
is
quite
quite
good.
Use
for,
for
industrial
use
cases
yeah.
These
are
the
the
typical
use
cases.
Everyone
knows
like
initialize
update,
revoke,
but
also
some
some
further
use
cases
that
that
may
be
implemented
with
CMP.
But
what
may
be
more
important
and
CMP
is
quite
easily
extendable
with
a
general
message
concept.
So
if
someone,
for
example,
wants
to
transport
an
83
66
voucher,
then
this
can
be
easily
implemented
with
a
general
message.
I
From
our
experience
from
our
company,
we
see
not
only
the
mobile
network
and
rail
communication
amuse
cases,
but
we
also
see
use
cases.
For
example,
in
the
charging
environment
there
is
a
protocol
called
CPP
open
charge.
Point
protocol,
that
is
from
the
standardization
body
used
to
be
the
only
protocol.
The
charge
point
is
using
and
CMP
as
it
is.
Self-Contained
can
easily
be
transported
using
the
container
messages
from
OC
PP,
but
also
for.
I
Rolling
stock
equipment,
which
is
not
has
not
always
connectivity
to
back-end,
this
self-contained
messages
can
be
transported
in
a
store
and
forward
mechanism.
So
we
see
quite
quite
a
number
of
use
cases
in
the
back
up
of
the
slides.
There
is
a
bit
more
details
to
these
use
cases
so
for
everyone
who
is
interested
in
looking
that
up
and
driving
you're
welcome,
the
slides
are
online.
I
Okay,
so
profiling,
from
our
point
of
view,
is
essential:
a
tool
to
get
to
see
MPs
of
quite
power,
feature-rich
CMP,
stripped
down
to
the
needed
functionality
so
that
it
is
easy
to
implement
and
interoperability
is
possible,
but
we
not
only
see
the
end
entity
to
PKI
communications
that
is
typically
addressed
in
certificate
management
protocols,
but
especially
in
industrial
environments.
We
see
engineering,
tooling
management
to
its
asset,
inventory,
monitor
systems,
network
access
control,
so
we
think
also
the
lab
between
the
LRA.
I
Our
ACA
would
be
good
to
to
do
some
standardization
work
on
that
part
because
we
see
in
the
future
more
and
more
interoperable
needs
of
multi
vendor
environments.
There
too,
and
CMP
offers,
from
our
point
of
view
the
needed
functionality,
but
it
needs
to
be
specified
in
more
detail,
ok
yeah.
So
what
what
is
to
be
done?
This
is
an
example
may
be.
A
formatting
is
a
bit
broken,
but
this
this
would
be
an
example
how
this
such
initial
enrollment
could
work.
I
One
of
them
doing
the
authorization
on
the
request
and
attaching
its
are,
a
signature
and
forwarding
it
to
the
CA,
and
then
the
CA
can
verify
not
only
the
proof
of
possession,
but
also
the
authorization
of
the
RA
and
issues
a
certificate
and
return
the
certificate
back
transparently
through
the
hops
to
the
end
entity,
and
we
have
a
confirmation
message
exchange
where
the
messages
are
really
small
to
ensure
that
the
enrollment
worked
properly.
So
this
can
be
exchanged
but
not
necessarily
needs
to
be
exchanged.
This
can
also
be
skipped
if
needed
yeah.
I
So
what
is
our
our
request
or
question
what
this
work
be
interesting
to
to
the
working
group
as
updating,
let's
say,
CMP
RFC,
with
some
more
concrete
profiling
on
industrial
use
cases
and,
of
course,
we
are
happy
to
get
use.
Cases
learn
about
use
cases
from
from
other
companies
to
see
whether
they
are
covered
in
in
the
current
draft
or
figure
out
how
they
could
be
addressed
with
transactions.
L
Max
Monica
believes
we
actually
have
some
news
cases
in
the
medical
industry
and
some
other
parts
that
actually
are
struggling
with
coming
up
with
a
profile
for
CMP
that
they
understand.
I,
think
that
this
work
can
be
really
important
for
those
environments.
So
I
would
support
this,
and
the
other
other
use
case.
That
I
have
is
a
presentation
that
we
gave
in
the
email
working
group
about
provisioning
credentials
through
EEP
and
simpie
is
one
of
the
use
cases
that
we
would
like
to
support.
G
Hi
Scott,
Turner
I
think
I
sent
some
of
this
to
the
mailing
list
already
there's
other
groups
that
are
in
the
ITF,
like
ace
they're,
looking
at
exactly
this
thing
for
industrial
control,
stuff
for
IOT
type
devices,
so
it
seems
like
if
we
adopt
this
we're
stepping
on
toes
you're
gonna
have
to
do
some
kind
of
coordination
to
figure
out
who's.
Gonna
do
what
to
whom
it
would
be
weird
I
mean
the
P
key
I
can
be
screwed
up
and
had
CMP
CMC
blah
blah
blah
blah
right.
G
So
we
can
pick
one
so
as
an
infrastructure
people
I
supports
are
like
I
gotta,
do
four
things
right
to
get
certs
in
and
that's
not
great.
We
maybe
should
try
to
not
burden
the
industrial
control
world
with
the
same
problems
at
the
web
hat
so
it'd
be
good
to
see
if
we
could
get
some
kind
of
coordination
to
figure
out
what
ones
to
use.