►
From YouTube: IETF111-LAMPS-20210726-2130
Description
LAMPS meeting session at IETF111
2021/07/26 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
So
today
we're
going
to
talk
about
cmp
the
three
cmp
related
documents
and
then
we'll
talk
about
the
the
document
where
some
folks
want
to
assign
an
additional
extended
key
usage
for
document
signing
and
then
on
thursday.
A
A
Okay,
seeing
no
hands
then
we're
going
to
proceed
with
this.
So
henrik,
I
think
you
are
going
to
be
the
presenter
for
the
next
topic
is
that
right.
A
B
Let
me
are
you
sharing
or
should
I
share.
A
I'll
share
that
way:
they're
gonna
come
straight
from
the
data
tracker.
Okay,.
C
A
A
And
and
audio.
B
B
To
make
things
easier,
we
also
introduced
two
new
oids
on
root,
ca,
third
update
and
on
third
profile.
These
will
be
used
in
later
support
messages
to
indicate
for
which
root
ca.
The
update
is
requested
and
which
certificate
profile
is,
is
to
be
referenced,
so
this
can
be
used
in
support
messages
to
get
a
template
for
such
a
certificate
request,
as
well
as
for
a
certificate
request
itself
to
indicate
which
profile
should
be
used
to
issue
the
certificate.
B
The
optional
field
to
yeah
indicate
directly
a
hash
algorithm
for
those
signature.
Algorithms
who
do
not
have
this
as
part
of
the
the
signature
algorithm
oid,
then.
As
already
said,
we
updated
the
certain
support
messages,
so
the
oids
for
the
support
messages
to
make
use
of
the
indications
explained
before
we
also
updated
the
local
key
id
attribute
after
discussion
and
feedback
from
rus
and.
B
B
So
what
is
the
next?
What
are
the
next
steps?
So
there
are
some
updates
that
popped
up
after
submitting
our
update
rfcs
for
this
meeting,
so
we
will
introduce
or
will
update
the
rfc
that
draft
respectively,
and
I
will
also
do
some
updates
to
the
asm1
modules
addressing
feedback
from
rus.
B
Then
a
final
internal
review
is
ongoing
on
the
three
documents,
so
maybe
some
feedbacks
pop
up
there
and
will
need
to
be
addressed
in
an
update
as
well,
but
yeah.
Any
further
feedback,
of
course,
is
always
more
than
welcome
and
we
plan
to
come
to
a
stable
version
to
proceed
to
working
group.
Last
call
before
next
itf
meeting.
B
Okay
next
slide,
please
so
with
cmp
algorithms,
we
did
some
changes,
more
minor
changes
and
addressing
mainly
what
was
going
on
in
and
after
last
itf
meeting.
I
also
want
to
welcome
john
gray
as
one
of
the
co-authors.
He
did
a
very
welcome
review
of
the
document
and
contributed
quite
some
parts,
so
we
will
edit
him
to
the
list
of
authors.
B
B
B
B
The
the
use
case
on
changing
a
protection
of
a
message
to
adding
a
protection,
because
this
is
easier
to
handle
when
forwarding
messages.
B
But
probably
this
is
not
something
really
major,
but
I
I
just
wanted
to
point
point
on
this
change
in
section
3,
which
provides
the
the
the
header
for
the
cmp
messages.
So
there's
a
generic
header.
We
also
made
references
to
the
hash
elk
field
that
is
used
later
on
and
we
added
three
new
sub
sections
which
put
together
the
prerequisites
for
pki
management
operation.
B
Yeah
we
harmonize
the
error
reporting
so
to
have
now
we
will
have
now
one
generic
error,
reporting
section
that
nicely
fits
right
after
this
validation
section
to
to
make
it
easier
and
more
straightforward.
Also
for
implementers.
B
This
is
how
a
pki
management
entity
forwards
a
message
to
a
further
upstream
pki
management
entity,
and
in
this
section
we
also
rework
the
section
on
nested
messages
a
little
bit,
and
then
we
introduce
section
5.3,
which
was
there
partly,
and
this
is
how
a
pki
management
entity
acts
on
behalf
of
some
other
entity
and
then,
of
course,
we
also
removed
the
former
error
handling
section
and
referenced
section.
3.6.
B
In
section
6,
we
combined
or
removed
the
https
section
and
integrated
this
in
the
http
section
as
discussed
last
itf
meeting,
and
we
added
a
list
of
co-op
endpoints
to
the
co-op
section
as
the
co-op
cmp
over
co-op
draft
and
the
ace
working
group
is
improving
and
will
forward
to
working
for
is
already
in
one
group
last
call
and
so
yeah.
We
thought
that
it's
reasonable
now
to
to
also
add
a
list
of
endpoint.
There.
B
Please,
during
the
internal
review,
one
point
was
brought
to
our
attention
and
this
is
currently
in
cmp.
There
is
one
mechanism
for
kind
of
delayed
enrollment
which
only
addressing
certificate
request
messages
like
ircr,
kur
and
p10
cr,
but
which
does
not,
is
not
capable
of
yet
delayed
delivery
or
asynchronous
delivery
of
other
messages,
like
confirmation
messages,
revocation
requests
or
general
messages,
and
we
we
discussed
in
internally.
How
could
we
cope
with
this
deficiency?
B
Because
in
some
use
cases
we
have,
we
would
like
to
to
bridge
an
offline.
B
Trend
an
offline
communication
using
nested
messages
like
like
batches,
and
for
this
we
need
some
yeah,
some
mechanism
like
polling,
also
for
these
other
messages,
especially
support
messages,
and
therefore
we
thought
about
changing.
This
delayed
delivery
to
a
mechanism
where
we
first
sent
the
initial
request
and
answer
on
this
request:
message
with
error
messages,
with
a
status
waiting
and
in
the
wait
time
in
the
error
code
field.
B
After
this
wait
time
elapsed
and
just
resent
the
original
message
and
then
get
the
response
to
the
message
indicated
in
in
in
the
first
time,
this
comes
with
some
hurdles
with
regard
to
to
non-sampling
in
cmp
messages.
But
as
long
as
we
do
only
have
a
request
response
mechanism,
then
the
non-sampling
does
not
bring
bring
much
value.
B
Therefore,
this
is
an
idea
we
would
like
to
yet
to
explain.
Maybe
in
in
some
more
concrete
texts
in
in
this
version
and
approach,
we
see
that
it
will
simplify
and
simplify
and
more
generalize.
This
delayed
delivery
mechanism.
This
would
not
require
any
changes
to
the
asm1,
syntax
and
yeah.
What
would
nicely
fit
from
from
our
perspective,
but
yeah?
It
would
need
some
some
more
time
to
to
put
this
in
in
concrete
text
in
the
in
the
draft.
B
B
B
B
We
will
probably
add
some
paragraphs
to
the
security
considerations
and
yeah
waiting
for
some
some
final
feedbacks
from
the
internal
review,
but
hopefully
we
will
also
manage
to
to
get
this
draft
ready
for
working
group.
Last
call
in
advance
to
the
next
itf
meeting.
B
A
I'm
not
seeing
any
hands,
I
don't
see
anything
in
the
chat,
so
I
think
that
means
people
are
happy
with
the
direction
you're
taking.
Okay,
we'll
really
find
out
at
last
call.
E
All
right,
good,
hey!
So
thanks
for
having
me
this
is
an
idea
that
is
myself
have
been
working
on.
It's
basically
a
general
purpose.
Eku
for
document
signing.
I
won't
bury
the
lead
here.
It's
a
short
document
we'd
like
the
working
group
to
adopt
it.
So
next
we'll
go
into
the
motivations.
E
So
some
background
here
so
there's
extended
keys
extension,
which
is
defined
at
5280,
which
allows
the
extension
to
indicate
one
or
more
purposes
for
which
the
certified
public
key
can
be
used
and
you'll
see
on
the
right.
There's
a
whole
bunch
of
them.
They've
been
defined
over
time
in
various
rfcs,
and
you
know
they're
used
all
over
the
place.
E
They
were
probably
used
a
little
bit
more
at
the
beginning
than
they
were
later,
but
you
know
they
are
out
there
and
so
there,
the
one
thing
is:
there's
there's
once
there's
general
purpose
ones
for
like
signing
of
of
emails
and
other
things,
but
there's
not
one
specifically
for
signing
documents
per
se.
Next.
E
So
you
know,
since
it's
one
or
more
purpose,
we
could
pick
an
existing
oi,
that's
already
defined
or
an
extended
existing
eke,
that's
already
defined,
so
you
know
we
could
do
email,
protection
or
code
signing
or
one
other
thing,
but
we
think
there's
too
many
issues
with
unexpected
behaviors
or
ad
adverse
impacts.
That
could
happen
if
we
were
to,
like
basically
add
an
additional
usage.
I
think
that
would
be
probably
bad.
E
We
also
think
that
there
is
possibility
that
there
are
already
some
vendor
defined
eku's
for
document
signing,
for
example,
adobe
and
microsoft
and
others
that
have
document
signing
products
and
there's
really
no
issue
with
using
vendor
defined
voids.
But
you
know
they're
not
really
it'd
be
weird
to
kind
of
adopt
them
someplace
else.
So
the
idea
is
that
we
kind
of
like
to
define
a
generic
purpose.
One.
E
Next,
so
what's
our
choices
right?
Well,
we
could
you
know,
let
oids
be
define
each
one
initially
defined
by
whoever
you
know,
nation
state
forum,
consortius
software,
vendors
individuals
etc.
Those
those
those
might
well
might
work
well,
but
it's
a
lot
of
effort
to
get
them
defined
and
used
and
implemented
and
understood
elsewhere.
So
really
kind
of
the
idea
is
that
we'd
like
to
have
kind
of
a
generic
one
one
place
to
find,
and
that
would
be
in
the
ietf.
E
And
so
our
proposals
define
a
general
purpose
eku
for
document
signing,
so
the
intent
is
that
they
would
be
used
for
signing
contents
that
are
consumed
by
humans.
Content
is
something
that's
printable
or
displayable,
rather
than
processed
by
a
machine.
E
The
oid
would
be
defined
under
the
iana
arc,
that's
id
kmkp,
and
so
we
can
keep
using
the
existing
dock.
The
existing
oids
without
doing
any
kind
of
cross-contamination
and
as
the
cas
can
include
multiple
eku's.
E
You
know
they
can
kind
of
knock
themselves
out
to
include
one
or
not,
and
I
believe
that's
it,
and
I
should
note
that
I
know
that
itason
and
tomofumi
are
on
here
thanks
thanks
for
staying
up
late,
and
so,
if
there's
any
questions
you
can
please
ask
them
now,
and
one
of
the
three
of
us
can
try
to
answer
them.
F
Good
afternoon,
sean
and
and
russ
good
good
afternoon
to
others
good
evening
to
those
of
us
in
europe
good
morning
to
you
boy
that
was
long.
The
the
question
I
just
have
is
a
simple
one.
After
all
of
that,
which
is
have
you
been
talking
to
any
of
the
cas
and
and
had
any
reaction
from
them
in
terms
of
willingness
to
implement.
E
I
will
turn
this
over
to
tomofumi
and
song,
but
I
believe
they
have.
There
was
actually
a
blog
post
by
the
ca
browser
forum.
I
guess
that
seemed
to
be
at
least
supportive,
so
they're
there,
and
I
know
that
tomafumi
and
edison
both
actually
work
for
ca
for
cas,
and
there
have
been
requests
for
such
a
thing
that
they
could
then.
E
E
Dishonored
are
you
did.
F
A
A
second
ago,
do
you
want
to
please
please
speak
yes,.
G
Thank
you,
so
we
we
had
a
similar
case
where
the
customer
wants
to
well.
They
they
issue
certificates
for
document
signing,
but
they
don't
necessarily
want
to
use,
is
mime
or
code
signing
or
any
other
existing
eks
for
document
signing,
because
they
don't
they
don't
want
to
be
governed
by
this
particular
consortium
or
trust
program.
D
A
Personally,
I
think
this
is
a
good
idea
to
assign
this.
I
would
love
to
hear
support
for
that
idea
or
reasons
why
you
think
it's
a
bad
idea.
E
F
H
A
So
he
posted
a
lot
on
the
mail
list,
some
of
which
was
a
discussion
of
the
general
differences
between
key
usage
and
extended
key
usage
and
not
really
commenting
on
this
one.
So
I
but
there's
he
has
like
three
or
four
messages
in
the
thread
about
this,
that
people
should
review.
I
found
his
his
meandering
among
those
hard
to
come
down
to
support,
not
support.
H
A
Going
against
so
what
I
would
propose
is
the
next
step
is
we
do
a
call
for
adoption
and
I'll
start
that,
sometime
this
week,
whenever
I
have
a
break,
does
that
work
for
people.
A
Okay,
all
right,
thank
you
sean.
Since
we
have
a
few
minutes
here.
I
wanted
to
share
a
document
that
I
just
posted
as
an
update
to
rfc
7299.
A
It
turns
out
that
when
I
did
the
work
to
gather
together
all
of
the
oids
that
were
assigned
by
the
pkix
working
group
and
turned
them
into
iana
registries,
I
missed
two
oids,
so
this
document
simply
points
out
that
those
two
hoids
which
were
from
rfc
4212
did
not
get
included,
includes
them
and
asked
that
I
anna
create
a
registry.
It
is
literally
the
iana
considerations
is
the
whole
document,
except
for
explaining
that
they
should
have
been
included
in
rfc
7299.
A
All
right,
all
right
that
we've
surprisingly
bashed
today's
agenda
really
quickly
and
so
we're
going
to
wrap
up
a
few
minutes
early
and
we'll
be
able
to
talk
again
on
thursday.
When
we
talk
about
the
s,
mime
and
astrolated
parts
of
the
agenda
enjoy
the
itf
and
not
seeing
any
hands
for
any
last-minute
topics.
So
all
right
have
a
great
week.