►
From YouTube: IETF105-LAMPS-20190723-1330
Description
LAMPS meeting session at IETF105
2019/07/23 1330
https://datatracker.ietf.org/meeting/105/proceedings/
C
Then
we
have
one
active
working
group
deliverable
that
has
not
been
sent
to
the
is
G
and
that's
regarding
header
protection.
So
we'll
spend
some
time
on
that
and
then
there's
some
things
that
have
been
proposed
for
reach
our
during,
and
that
is
the
going
to
be
the
next
topic
we
really
dive
into
so
the
the
lightweight
CMP
profile
Hendrick
couldn't
be
here,
but
he's
planning
to
present
this
remotely
so
we'll
see
how
that
goes.
C
I
do
know
that
he
ran
a
test
at
everything,
worked
fine
during
the
tests,
so
it's
as
best
as
we
can
do,
but
Murphy
lose
and
then,
if
time
allows
we're
going
to
talk
about
two
other
proposals
that
have
not
yet
been
talked
much
about
on
the
list.
One
regarding
update
to
RRC,
40,
54
80
regarding
the
key
usage
pieces
and
one
about
post
quantum
composite
signatures,
any
agenda
bashes.
C
C
Thank
you,
okay.
The
next
one
is
mine,
which
is
the
hash
of
root
key
certificate
extension.
We
got
a
couple
comments,
non-blocking
comments
from
romans
review.
I
have
shown
him
all
the
text
for
that.
He
pushed
it
forward
to
IETF
last
call
and
so
I'll
deal
with
posting
those
things
that
are
in
my
edit
buffer
when
I
deal
with
any
ITF
last
call
comments.
E
F
C
C
H
C
J
K
K
K
Well,
it
was
like
use-case
and
requirements
plus
an
implementation
description,
so
we
took
from
this
pole
from
this
trophy,
took
the
use
cases
and
requirements
and
added
the
trough.
Melnik
inflames
header
protection,
which
had
some
real
holes
already
going
towards
solutions.
So
the
content
is
now
we
have
use
cases,
we
talked
about
interaction,
cases
and
protection
levels.
Then
there
are
requirements,
and
then
these
additional
considerations
mainly
taken
from
Alexis
elder
draft
that
contains
possible
solutions,
considerations
for
the
sending
side
and
receiving
side.
K
So
the
goal
of
this
meeting
of
this
talk
is
that
we
learn
which
protection
levels
are
in
scope.
I
will
come
back
to
later.
What
protection
level
means
here
and
reach
requirements
we
are
going
to
address
in
lamps,
so
set
of
requirements
made
up,
may
not
be
complete.
There
may
be
too
many
even,
and
there
certainly
will
be
some
adjustments
to
the
existing
requirements.
K
Ok
protection
levels,
so
we
see
three
cases
like
one
is
signature
and
encryption
like
in
our
case.
We
only
use
this
AC,
which
end
encryption,
nothing
else,
but
there
are
other
implementations
that
use
this
signature
only
case
actually
customer
demanding
this
obviously,
and
we
have
the
case
encryption
only
which
we
are
not
quite
sure
whether
it
makes
sense
or
melody.
This
is
all
relevant,
the
head
of
protection
or
whether
it
can
be
merge
to
a
we
have
discussion
last
year
in
lamps.
K
K
K
Now,
if
not,
we
are
probably
going
forward
with
trying
to
avoid
the
encryption
only
case
in
specification
and
documenting
it.
What
would
happen
when
you
get
one
that
is
only
a
cryptid,
sted?
Fine,
nobody
seems
to
care
okay,
I
structured
requirements,
a
big
team
general
requirements,
then
sending
site
requirements
and
receiving
site
requirements
and,
at
the
end,
I
feel
and
some
backward
compatibility
requirements.
So
there
are
four
slides
that
kind
of
put
requirements
together.
So
Alex
I
want
to
say
something
just.
M
Fine,
you
know
we
are
not
doing
requirements
just
for
the
sake
of
requirements.
Is
some
of
the
requirements
are
things
that
we
need
to
document
in
the
final
solution
document
and
other
grounds,
hopefully,
will
help
us
decide
between
couple
of
variants
we're
trying
to
pick
between.
So
if
people
want
to
comment
on
relative
priority
of
requirements,
how
important
they
are
I'll
bring
up
new
things.
So
please
please,
so
that's
the
sort
of
the
intent
of
this
section.
K
K
K
We
see
that
there
should
be,
if
possible,
only
want
for
format
for
all
protection
levels
so
that
you
do
not
have
different
formats
between
encryption
and
signed
versus
signed
only,
and
it
should
actually
mitigate
many,
the
middle
and
downgrade
attacks
as
good
as
possible.
So
these
sort
of
all
general
requirements.
If
there
is
any
comment
in
the
room,
it's
not
so
many
people
write
the
draft.
The
silence
is
not
surprisingly
coming
okay,
not
in
here,
then
we
have
to
send
the
requirements.
K
K
Principles
so
that
we
are
not
leaking
too
much
what
shouldn't
be
leaked,
but
this
is
probably
only
shoot
and
also
like.
There
are
some
special
cases
that
are
header
fields
that
we
should
not
include
in
any
header
protection.
Part
one
case
is
the
BCC,
which
is
somewhat
special,
so
some
implementations
it
should
get
out.
So
the
receive
of
a
message
should
not
get
to
know
who
has
been
in
the
BCC,
but
Alex
I
found
an
interesting
cases
that
the
BCC
should
be
in.
He
may
elaborate
on
it.
Yeah
I
was.
M
Trying
to
implement
as
my
encryption
with
BCC
under
depending
how
you
implemented
you
know
there
are
actually
three
kind
of
types
of
messages.
If
you
are
to
NCC
recipient,
you
should
never
see
BCC
right
because
they're
supposed
to
be
secret
from
you.
If
you
are
one
of
BCC
recipient,
you
might
get
a
special
copy
which
contain
only
us
BCC
and
this
copy,
but
it's
a
special
version
of
the
message
being
sent
out.
M
C
M
Make
people
think
about
what
PCC
is,
or
they
can
probably
figure
it
out,
but
I
think
spelling
out
cases
might
be
useful.
If
you
have
a
can
you
send
a
message,
maybe
to
me
directly
with
the
point
and
then
I'll
have
a
look
and
then
sure
that
maybe
there
is
nothing
to
do
just
point
to
this
document.
I
know
that
email
spec
itself
also
has
a
little
blurb
about
BCC
would
sort
of
try
to
describe,
but
it
doesn't
talk
about
encryption
or
signing
it.
Also,
it's
a
little
extension
of.
O
C
G
M
C
M
C
M
O
G
G
C
Sort
of
it's
not
that
simple,
because
you
don't
want
to
generate
a
message,
a
copy
for
the
twos
and
the
CCS
for
each
BCC,
and
so,
if
that
header
stuff
gets
looked
at
in
the
submit,
you
end
up
generating
a
bunch
of
stuff,
a
bunch
of
messages
that
go
to
the
wrong
people.
You
end
up
having
to
make
a
to.
Each
BCC
has
to
become
a
two
in
the
subsequent
messages.
G
G
G
G
C
L
L
L
O
C
O
K
G
K
Okay,
receiver
requirements,
so
what
you
found
there
was
basically
if
we
have
protected
headers
and
then
you
have
the
output
unprotected
headers.
You
have
potentially
two
different
versions
of
headers
and
you
need
to
figure
out
what
is
paid
and
usually
just
is
paid
in
the
inner
ones,
because
the
outer
ones
could
be
have
tempered
with
in
any
case
it
needs
to
be
documented.
Then
we
need
to
found
out.
There
are
exceptions
to
this
rule
and
then
it's
again,
the
same
receiver
needs
to
be
able
to
detect
many,
the
middle
attack
or
downgrade
attacks.
K
So
then
we
have
they
called
compatibly
requirements.
There
are
kind
of
two
areas
of
requirements
we
need
to
discuss
like
one
is
how
to
distinguish
between
forwarded,
interrupt
messages
that
has
to
be
the
source
of
many
issues,
of
displaying
message
that
some
clients
interpreted
an
encrypted
wrapped
message
as
a
forwarded
message
and
just
enjoy
it
or
like
int
allowed
to
show
it
or
let's
say
it
was
it
was
not
possible
to
actually
look
at
it.
K
It
was
just
an
attachment
should
we
help
these
clients
to
fix
their
implementations
because
also
like
in
the
simple
form
of
the
case,
is
basically
an
issue.
If
you
can't
like
read
the
follow
the
message,
this
kind
of
laundry
needs
to
be
one,
and
then
we
talk
later
about
the
rest
think
alexei
to
say
something
about
this.
What
I
just
mentioned.
M
M
M
O
R
O
O
C
S
C
T
So
we
are
like
trying
to
be
interoperate
with
whatever
is
out
there
in
the
end,
of
course,
with
the
preference
is
wrapping
approach,
but
I
think
it's
not
that
application,
usually
in
in
clients
which
can
show
rock-rock
messages
and
they
get.
What
is
that
has
at
least
one
advantage
is
that
you
can
still
see
the
headers
I
mean
you
can
at
least
see
what
the
subject
was
intended
to
be
in
the
memory
roll
approach.
You
don't
see
that
so
this
you
have
always
liked
when
features
and
disadvantages.
T
M
In
a
way,
it's
artifact
in
the
UI,
but
it's
a
useful
artifact,
which
is
sort
of
the
soul
of
you,
know.
Yeah
I
think
I
understand
what
you
and
I
can't
under
Bert
you.
If
you
have
an
method
message,
you
can
see
some
headers
in
the
nested
message
where
in
memory
call
approach
it
wouldn't
see,
it
will
just
be.
T
Results
in
any
mail
nowadays,
and
if
you
cannot,
you
cannot
I
mean
you
have
to
open
up.
You
decrypt
your
email
manually
and
look
for
this
mind
parts
where
the
actual
subject
stands
and
I
think
this
might
be
for
normal
users,
even
a
bigger
issue
than
if
you
stop
by
to
eat
what
I
mean
yeah
that
Rebecca.
T
K
Even
further
thinking
about
this
fault
equals
no
propose
of
Alexei,
we
have
also
like
forward
equals
yes,
and
we
have
forwarded
something
neutral
or
nothing
now
for
feeding.
We
are
getting
like
of
three
different
meanings
of
this,
which
is
kind
of
beyond
the
head
about
the
actual
thing,
but
I
think
for
today's
tell
the
client
hate
as
a
form
of
the
message
handle
it.
It's
not
just
an
attachment,
nothing,
we
don't
know
thing
about
it,
or
maybe
it
has
the
snowfall
other
than
no
encrypted
message.
It's
just
an
attachment.
K
Ain't
in
the
our
case
would
be
for
what
recourse,
no,
which
means,
if
an
encrypted
message
is
just
dropped.
So
just
something
to
think
further
about
the
proposal
we
are
making
up.
Okay,
so
any
further
comments
to
this
forward
versus
Rob
messages.
Or
can
you
go
to
the
next
thing
which
I'm
just
doing
is
next
for
requirement?
Ps,
one
two,
three
and
PR
on
this
is
mainly
about
the
negotiation
mechanism
or
like
or
indication
of
support,
feature
indication
of
support
of
something,
and
we
are
not
quite
sure
whether
we
need
that.
K
But
basic
idea
is
that
a
client
can
indicate
that
it
implements
full
support
of
this
RFC
to
be
which
you
are
now
generating,
and
the
receivers
I
conceded
and
tender
and
possibly
behave
differently.
If
he
knows
the
other
side
understands
the
full
hata
protection,
it
can
behave
differently,
then
clients.
He
doesn't
know
anything
about,
not
sure
whether
this
is
needed.
But
if
we
have
that,
then
it
means
we
need
an
indication
mechanism.
K
We
need
the
mechanism
to
figure
out
where
the
other
side
is
supporting
it,
and
we
need
a
way
to
figure
out
the
subject:
header
field
to
be
displayed
to
the
use
of
unaware,
clients
and
the
receiving
side.
We
need
to
detect
for
support
of
new
header
protection.
Probably
the
requirements
need
to
be
cleaned
up
a
bit,
but
before
we
probably
need
to
have
a
discussion,
whether
we
include
that
requirement
or
not
I'm,
not
sure
about
that
theory
at
all
needed.
K
W
C
T
M
C
M
If
we
design
and
drive
I
think
it
will
still
be
reasonable
in
all
clients
you
will
have.
You
know,
maybe
you're
not
going
to
see
as
much
information
or
maybe
it's
going
to
present
the
in
out
of
the
way.
But
you
used
to
be
able
to
do
something
with
it.
Where
in
your
client,
they
will
just
handled
automatically.
M
G
M
You
know
whether,
when
you'd
like
and
you
try
to
feel
saying,
you
know
I'm
this
deal
shiny
for
the
perfection
thing,
because
on
the
flip
side
there
is
you
know
there
is
a
mime
mime
header
saying
you
know,
question
one
zero
I
think
then
ten
at
some
point
was
that
would
be
more
four
versions
that
it
would
never
be
multiple
versions.
So
it's
actually
more
genetic
versioning
is
not
useful
unless
we
make
a
mistake
and
have
to.
T
Money
I
just
wanted
to
say
that
even
inside
the
same
male
clients
by
instance,
it
may
there
is
a
mess
because
there
are
different
approaches
off
as
a
protection
and
all
of
a
sudden
the
software
gets
leaked
or
you
just
receive
like
replied
to
Todd,
stop
don't
and
stuff
like
that.
So
it's
it's
really
a
mess
which
we
should
even
inside
one
client.
T
M
I
think
we're
probably
couldn't
solve
the
problem
by
fixing
all
all
evolved
implementations
by
working
around
a
work
around
them.
I,
don't
think
it's
going
to
work,
but
that's
right,
I
think
we
should
collect
the
issues
we
see
and
see.
If
there
is
any
pattern-
and
maybe
you
know
dr.
implementers
work
out
well.
K
Okay,
so
for
me
it
is
like
the
indication
of
support
thing.
We
could
put
it
like
this,
that
we
only
look
at
it
if
we
see
coal
after
we
have
chosen
a
solution,
because
it
kind
of
really
depends
on
the
solution
we
are
taking
and
so
probably
should
leave
it
in,
but
like
degrade
it
to
a
way
that
it's
not
the
must.
So
it's
my
feeling.
Okay,
any
further
comments.
I
Y
K
T
Elan
is
going
to
say
something:
I
can
turn
on
Marcus
from
the
foundation.
I
mean
I
can
talk
for
pretty
surprised
what
we
are
doing.
We
are
indicating
like
if
your
message
is
private
or
not
with
symbols
and
texts,
so
we
are
somehow
taking
us
into
consideration
and,
of
course,
also
showing
that
the
rights
of
check
in
the
end
to
be
that
memorable,
would.
U
T
That
path,
but
as
soon
as
we
got
in
interaction
with
other
clients
which
are
not
aware
of
these
protocols
and
things
might
get
a
little
business,
I
mean,
of
course
you
can
still
touch.
The
indicate
is
that
the
messages
is
secure
because
it's
because
it's
encrypted
and
sign
it
or
if
you,
if
you
trusted
other
peers
and
we
show
it
to
Greene,
so
this
stuff
cannot
show
we
interact
with
like
classic
PGP
users
or
later
on,
as
my
muses,
which
should
be
supported.
So
we.
T
O
K
M
Yeah
I
think
it's
not
idea
of
strength
to
talk
about
you
guys
I
would
agree
to
that.
I
think
this
is
understanding
of
this
is
changing
and
it's
not
I
personally
find
this
discussion
to
be
useful.
You
know
whether
this
is
going
to
be
a
document
or
separate
document.
I,
don't
know,
but
I
think
having
discussions
about
what
that
but
better
ways
of
representing
the
itself
as
metaphors
for
both
display
on
the
receiving
side.
M
What
level
of
protection
message
you
receive
an
on
the
sending
side,
you
know
what
kind
of
choices
you
know
because,
like
typical
clients
provide,
you
separate
choice
for
encryption
for
signing
and
you
can
do
encryption
only
messages
and
then
it's
like
well,
you
generated
one
of
these.
What
do
you
do
with
it
from
where
they
are
right
again?
There
are
duis
are
possible,
but
you
I
saw
for
doing
this
sort
of
thing.
K
K
K
Q
Though
I
just
want
to
give
him
an
update
on
what
discussion
took
place
at
IDF
104
in
Prague
and
after
that
ruskin,
you
switch
to
the
next
slide.
So
yeah
this.
This
is
more
less.
The
summaries,
though
we
got
discussion
on
whether
cm
changes
to
the
MP
needs
to
be
a
standard
track.
Rfc
and
therefore
must
be
approved
by
some
working
group,
and
we
we
discussed
that
the
profiling
and
referencing
on
the
the
CNP
RFC
could
either
be
an
individual
contribution
or
working
group
item
and
Stephanie's.
Q
G
Q
Q
G
Q
Q
Q
X
Q
Q
The
second,
the
second
part
I
was
working
on
was
the
to
change
this
revocation
use
case,
revocation
on
behalf
of
ment
entity,
so
revocation
by
some
management
station
and
revoking
an
end
entity
certificate
from
optional
to
recommend
it.
This
was
a
feedback
from
within
my
company
that
this
is
quite
an
important
use
case
and
that
it
should
be
supported.
Q
Q
No,
so
I
will
continue
to
the
update
CMP
document,
so
there
are
mainly
two
topics
addressed
in
this
document.
The
major
yeah
reason
why
why
having
this
document
is
that
we
need
envelope
data
instead
of
encrypted
values
for
protected
delivery
of
centrally
generated
private
keys,
and
we
had
some
discussion
with
Jen
on
mail
on
how
to
do
that,
and
he
pointed
us
to
this
encrypted
key
the
choice
in
the
CRM
F
document
and
yet
in
CRM
F.
Q
There
is
some
discussion
going
on
in
my
company
whether
just
exchanging
encrypted
value
with
an
encrypted
key
is
offices
enough
and
and
proper
backward
compatibility,
but
yeah
I
have
a
backup
slide
on
on
that
and
so
I'm
yeah
happy
to
get
any
feedback
from
other
s1
experts.
So
what
the
best
way
to
do
this
so.
C
Why
are
you
just
wrapping
this
as
opposed
to
putting
a
whole
pkcs
8
package?
In
there?
You
know
the
which
and
with
the
recent
extension
58
something
that
Shawn
did.
It
would
allow
you
to
distribute
the
the
public
key
and
the
private
key
and
the
algorithm
identifiers,
and
all
that
in
one
big
wrapped
thing:
okay,.
Q
G
Q
O
P
G
Q
Published
synchronously
and
yeah,
so
I
didn't
really
get
why
that
was
not
adopted
in
CMP,
but
yeah
Jim,
as
you
just
explained,
and
and
that's
wall
as
a
the
goal
of
updates
EMP
to
open
up
the
agility
to
have
also
yeah,
in
the
first
case,
protect
private
key
delivery
with
ECC
key
material.
What
is
not
possible
with
encrypted
value
yet.
Q
Okay,
so
neck.
A
second
point:
I
also
discussed
with
with
Jim
little
bit
whether
this
is
needed
to
be
in
update
cmp,
but
I
think
it
could
be
there
if
we
have
this
document
anyhow-
and
this
is
introduction
of
an
extended
key
usage
for
cmp
service
like
registration
or
certification
authority.
This
is
similar
to
to
what
has
been
done
and
I
think
CNC.
Also.
That
was
an
a
comment
from
Martin
Pino.
He
said
this
would
be
quite
useful
to
better
identify
these
authorities
yeah.
So
this
is
it
more
or
less
at
the
moment.
Q
F
I
F
P
F
Q
Okay,
so
that
that
was
it
from
my
site
on
the
updates
to
the
CNP
work.
If
there
is
time
I
could
I
would
like
to
follow
up
with
a
discussion
on
the
crypto
agility
in
the
envelope
data
part,
so
could
could
share
the
feedback
I
got
from
from
other
colleagues
within
my
company,
but
I'm
also
happy
to
do
that
of
racket
on
the
mailing
list.
If
we
are
tight
with
time
in
the
meeting,
what
do
you
think
I'm.
S
Q
R
Hi
Shawn
Turner
I
have
to
give
you
some
time
back
here.
The
last
ITF
meeting
my
co-author
came
up
to
me
and
said:
hey
you've
got
this
great
document,
RFC
54
80.
You
know
it
came
out
of
his
pickax
Tiger
team
to
specify
the
key
usages
for
elliptic
curve.
You
kind
of
didn't
mention
two
of
them.
What
are
we
supposed
to
do
so?
I
shot
of
mailing
I
shown
the
mail
off
to
the
man
list
and
I
got
two
different
answers.
R
Alright,
why
are
we
here
right?
So
basically,
I
want
to
do
a
simple
update
to
fifty
four
eighty
Section
three
to
say
what
the
requirements
are:
qisas
extensions
in
the
subject:
public
key
for
these
three
Fri
DC
public
key
ee
c
mq,
v,
ID
e
cv,
h
to
specify
one.
So
the
two
values
are
and
that's
all
we're
trying
to
do.
That's
it
I'm
not
trying
to
adopt
anything
else.
I
want
to
care
anybody
else's
water
and
quicken
done
next.
R
So
really
all
we're
doing
is
say
must
not
set
these
values,
so
don't
set
them.
You
don't
for
key
insight
from
it,
and
data
and
cipher
man
don't
set
them
for
high
GC
public
key,
don't
set
them
for
C
and
Q
v-nec
th.
One
thing
about
the
way:
50
480
is
written.
I
Dec,
public
key
is
for
unrestricted
key
since
for
e
CD
s
keys,
that's
that's
what
it
says.
When
is
it
for
anything
else?
That's
up
to
you,
but
this
is
only
for
these,
and
so
just
do
that
and
that's
it.
R
R
So
what
am
I
here
for
so
whopping
three
pages,
I
love
a
pony,
but
if
I
can't
get
that
I
love
just
adopt
the
draft
working
group
last
call
and
do
whatever
you
do
just
pump
this
out.
It's
three
pages:
it's
like
eight
lines
of
text.
Really
all
I
want
to
do
is
add
a
cup
of
those
words.
Basically,
don't
must
offer
those
things
there.
R
C
P
R
F
L
R
L
L
R
R
C
X
P
F
Well
folks
was
coming
up,
I
mean
the
reason
again.
The
reader
as
I
grew
through
the
Charter.
Why
need
your
did
you?
Some
updates
is
the
last
tab
where,
if
it's
reads
in
addition
to
the
Lance
work,
the
other
updates
to
documents
produced
by
cheap
pica-x
blah
blah,
but
we
shall
not
adopt
any
of
these
potential
items
without.
C
H
Hi
my
downs
right
so
I'm
gonna,
try
and
do
this
quickly.
I've
got
more
slides
than
I,
maybe
intend
to
go
hearing
death
but
we'll
be
in
there
for
the
archives,
difficult
rule,
Mike
Oh,
sir
tunes
microphone
more
better.
So
this
is
post
quantum.
This
is
trying
to
figure
out
how
we
use
post
quantum
inside
existing
at
self
and
ion
CMS
whatever
it
is.
You
do
with
your
crypto.
H
So
what
came
out
of
sort
of
a
lot
of
the
academic
conferences
I've
been
to
is
that
in
the
transition
period
to
post
quantum,
you
don't
know
if
RSA
is
broken,
you
don't
know
if
you're
new,
whatever
new
thing
you're
using
is,
is
broken
and
just
not
announced
yet.
So
you
really
want
to
sign
everything
twice
so
picture
in
the
bottom
corner.
There
Alice
sends
to
Bob.
Alice
really
wants
to
do
two
signatures
on
every
document
and
send
two
signatures:
Bob
wants
to
verify
two
signatures.
H
This
is
sort
of
the
transition
strategy
and
I've
heard
arguments
that
maybe
this
is
going
to
be
a
long
term
strategy.
We
don't
know
so
we
need
some
sort
of
mechanism
to
specify
how
this
is
gonna
work.
We
as
a
group
and
Trust
data
cards
cisco.
I
sarah
max
at
cable
labs.
We've
been
talking
about
this
for
what
almost
two
years
now,
how
do
you
do
this
mechanism
in
a
way
that's
easy
and
transition
safe
and
simple,
and
yet
yet
yadda,
I
sarah
put
in
a
draft
Rusco
ski
year
ago.
H
That
was
one
kick
at
the
can.
This
is
a
second
kick
at
the
can.
What
we're
trying
now
is
to
say
all
right,
let's
define
a
new
algorithm
that
algorithm
is
composite.
The
value
of
the
algorithm
is
a
list
of
public
keys
or
a
list
of
signatures
in
sn1
sequence
and
we're
proposing
that
this
is
the
simplest
way
to
accomplish
this.
H
C
H
Think
we've
addressed
and
thought
through
most
of
it
but
more
pairs
of
eyes.
Please
welcome
so
sir.
Why
do
we
do
it
generally
simplicity?
You
think
we
believe
this
is
the
simplest
way
to
accomplish
this.
We
believe
it
just
drops
into
existing
protocols.
We
believe
that
you
don't
need
the
protocol
there
to
be
aware.
If
you,
if
you
define
a
new
algorithm
ID,
then
it
goes
down
to
the
library
level.
The
libraries
is
asked
to
verify
a
signature.
What's
the
algorithm,
the
algorithm
is
composite.
H
This
is
all
handled
by
the
low-level
crook,
the
library
your
protocol
doesn't
need
to
change.
We
think
it's
simple.
There's
a
few
security
wins
over
sort
of
competing
strategies
for
doing
it
on
the
gloss
over.
If
the
details
are
there
in
the
slides,
if
you
want
to
look
them
up,
the
open
design
questions
that
Russ
just
alluded
to
there
are
a
number
of
sort
of
big
ones.
We've
taken
what
we
think
are
reasonable
decisions.
H
Having
had
you
know,
lengthy
debates
among
the
authors,
yeah
big
chuckle
from
Scott,
but
there
are
some
questions:
I'm
aware
that
they're
big
I'm
aware
that
they
need
to
be
talked
about
and
I
welcome
this
discussion
too
right.
We
haven't
really
bubbled
it
over
into
the
mailing
list
yet,
but
maybe
I
should
start
being
more
aggressive
about
that,
and
so
the
first
one
I
think
is
Russ's
point
is
what
do
you
do?
What
does
a
verifier
do?
If
they
receive
say
they
received
a
document?
H
G
H
One
of
the
other
things
is
broken.
I
think
we've
defined
that
fairly
rigidly
and
I.
Think
it's
I
think
we
believe
that
what
we
have
is
a
water-type
implementation,
but
we
admit
that
there's
it's
sort
of
tricky
to
get
right
and
the
algorithm
is
a
little
bit
finicky.
So
if
there's
a
way
to
simplify
that
and
tighten
that
more,
please
do
want
to
be
open.
H
Questions
I
think
is
straightforward,
key
revocation,
if
you,
if
you
declare,
if
you
contact
your
CA
and
say
please
revoke
my
key
I,
think
all
of
the
component
keys
get
revoked
I.
Think
that's
obvious.
I've
been
doing.
Anything
else
leads
to
problems
if
you
are
submitting
a
CSR
to
a
CA
and
one
of
your
component
keys
was
previously
declared
revoked
through
some
other
thing.
You
know
the
CA
point
needs
to
do
component
wise
checks
against
all
other
keys.
That's
all
that
complicated
it's
hard
to
do
right,
but
I
think
I
mean
I.
G
H
L
H
AA
U
AA
H
H
The
last
sort
of
open
design
question
that
we're
still
hotly
debating
within
the
author's
group
is
key,
usages
and
extended
key
usages.
Do
they
apply
to
all?
Will
they
apply
to
all
component
keys?
So
if
you
say
this
is
a
signing
certificate,
do
you
have
to
only
put
signing
keys
in
it?
People
have
numerous
people
are
called
us
and
said:
hey.
You
could
bring
back,
do
a
usage
search
with
this.
G
Z
H
B
AB
AB
H
So
think
about
think
about
it,
as
you
have
a
key,
you
have
a
single
key.
It
happens
to
be
composed
of
multiple
algorithms,
but
that's
not
your
problem.
You
have
a
key
in
a
PEM
file,
the
inside
making,
maybe
more
than
one
thing,
but
it's
still
ace.
Think
of
it
as
still
as
a
single
key.
So
it's
still.
C
AC
H
Q
U
Q
H
H
U
Not
sure
I
totally
understand
your
question,
so
there
are
two
signatures
in
the
composite
signature.
Yes,
yes,
it
turns
out
tomorrow
that
Sphinx
is
broken.
Yeah
I
can
forretress
things
to
now.
Yeah
I
can
make
a
certificate
that
has
an
invalid
Aris
a
signature
for
the
balance
make
signature.
Is
that
valid?
Alternatively,
can
it
be.
U
Then
the
entire
certificate
is
portable.
Sorry,
let's
forget
affordable
strongly
for
two
bullet
that
so
I
can
produce
a
second
signature,
that's
download
on
the
same
certificate.
So
if
any
of
them
is
not
strongly
unforgeable,
then
the
the
whole
certificate
is
not
strongly
unfortunate.
You
get.
This
is
like
a
you,
get
a
security
property
of
the
strongest
signature
or
the
most
right.
The
weakness
of
the
weakest.
You
get
the
certain
security
property
the
week
is
their
their
verified
in
parallel,
not
series
as
well
as
that's.
U
U
L
AC
U
H
I
made
to
generalize
your
comment:
if
I
can
take
a
stab
at
generalizing
way
out,
I
think
we
can
agree
that
there
we're
putting
a
lot
of
security
properties
on
the
verifier.
The
verifier
has
to
be
comfortable
in
what
it
supports
the
verifier
has
to
reject
if
it
sees
a
lot
of
things
that
doesn't
support
their
IQ
turns
it
be
having
these
strong
policy
on
the
side
of
the
verifier
is
that
does
that
cover
your
argument?.
H
H
AA
That
robbed
it
for
sure.
The
save
that
will
attack
can
be
done
with
a
single
key
celebrity
right
and.
U
U
AA
AA
U
AA
Z
X
X
X
AC
AD
You
know
the
question:
how
many
libraries
aren't
committing
policy
decisions?
Certainly
the
major
Kirk
graphic
letters
wearing
a
self-balancing
house
was
having
the
Mac
OS
implementation
sobriety
gear,
Chrome
browser
always
to
put
their
policy
logic
and
the
verifier
he's
doing
there
for
verification,
largely
response
to
sha-1
and
can
get
policy.
So
the
look
is
there
that
said,
there's
a
messy
part
of
this
we're
separating
this
from
the
protocol.
C
So
Brian
I
would
like
to
what
I
think
you
said,
but
and
I
would
just
want
I
want
to
make
sure.
Is
that
you're
not
sure
we
got
any
better
than
having
two
signatures
and
two
certs
right?
It's
like
did
I
get
that
right.
AA
So
the
next
panel
turbulence
one
of
the
consideration
I,
don't
remember
exactly
they
comment
there,
but
it
was
about.
Do
we
protect
against?
You
know
one
two
more
other
type
of
attacks
right.
The
idea
here
is
that,
with
this
tool,
you
can
have
your
PGI
to
the
point
rhythms,
where
some
of
the
clients
might
not
support
all
of
that
today,
and
this
is
something
that
can
happen,
for
example,
devices
in
the
field,
some
of
them
you
can
update
them.
AA
Some
then
cannot-
and
in
some
cases-
and
one
thing
that
I
want
to
point
out
is
that
is
usually
the
verifier
right
who's
exceptionally
certificate
or
not.
Ultimately,
that
takes
the
risk
or
not
about
do
I
trust
this,
this
information
or
not
right
once
you
verify
all
the
crypto,
depending
on
your
level
of
risk,
you
might
decide
well.
U
AA
AA
E
AA
Verify
sing
today
and
on
that
and
I
can
take
the
risk
and
I
can
say
you
know
I.
You
know
the
other
algorithms,
because
they
were
broken
now
and
I,
just
trust
that
that
is
sufficient
for
me
or
I
want
to
or
time
or
I
want
three
of
them.
So
from
this
point
of
view,
actually
it
does
gives
you
the
protection
today
that
you
can
rely
on
twenty
years.
From
my
point
of
view,
for
example,
when
I
want
to
deploy
something
like
yeah,
this
is
very
important
for
me
for
CHF.
If
it's
mostly
more.
U
AA
U
O
Yeah
Tim,
Holly
I
think
the
one
mistake
the
draft
might
currently
make
is
prematurely
specifying
a
verifier
policy.
Instead
of
saying
here's
a
variety
of
verify,
our
policies
and
here's
what
their
security
policies
or
properties
are,
for
example,
if
you
wanted
something
that
was
strictly
better
than
RSA,
you
might
choose
a
verifier
property
that
says
the
RSA
signature
must
100%
be
validated,
and
then
you
know
you
get
policy
choices
with
respect
to
the
additional
signatures
that
you
see
and
you
may
choose
to.
O
You
may
choose
to
require
that
those
if
you're
in
a
high
security
use
case,
you
may
choose
that
those
have
to
verify
it
as
well.
I
think
the
one
thing
that
we
do
want
to
prevent
is
having
people
at
the
developer
or
protocol
level
having
a
entirely
free
and
uninformed
choice
about
what
their
verify
policy
is.
So
I
think
it
would
be
very
smart
to
have
a
a
list
of
a
couple
of
good
verified
policies
and
what
those
security
properties
are.