►
From YouTube: IETF106-LAMPS-20191118-1810
Description
LAMPS meeting session at IETF106
2019/11/18 1810
https://datatracker.ietf.org/meeting/106/proceedings/
B
Have
four
documents
that
are
with
the
arrests?
One
thing
so
we
had
this
I
did
a
presentation
a
while
ago,
which
was
an
odd
amount
working
draft
about
a
key
update
for
fifty
four
eighty,
it's
not
on
the
list,
so
I
didn't
think
it
actually
had
to
be
on
there,
because
this
is
updates
in
the
drive
harder
so
five
seconds
at
the
end,
if
you
got
it,
okay,.
A
Unaware
of
any
thing
on
the
first
three
that
needs
to
be
reported
are
there
well,
maybe
I'll
just
it
this
way.
Quinn
do
you
have
anything
on
on
either
of
the
shaykhs
documents?
No,
okay,
the
there's
nothing
on
the
hash
sigdoc
and
we
had
ad
review
on
the
you
know
wrong
document.
So
nothing
on
that
one
either.
C
A
C
C
A
A
D
A
D
D
I'm
building
a
nice
clothes.
Okay,
now
you
can
hear
me,
my
name
is
Fiona
and
I
will
talk
about
data
protection
requirement
in
use
cases.
We
have
been
talking
already
during
two
IDF's
about
the
topics.
So
this
time,
you're
not
anymore,
going
to
into
you're,
not
anymore,
go
into
the
details
of
the
requirements.
D
So
we
wrote
our
summary
that
quick
recall
what
you're
talking
about
on
the
left
side,
you
have
a
typical
email
like
we
have
a
head
on
the
orange
part
and
the
content,
the
green
part.
The
content
can
be
protected
by
the
means
we
have,
the
headers
usually
cannot
be
protected
or
the
header
section
can
usually
not
be
protected
and
s/mime
fredo
tom
says:
ok,
put
the
whole
message
and
drop
it
inside
another
one
which
is
the
in
the
redhead.
D
Oh,
there
cannot
be
protected,
but
all
the
rest
can
be
protected,
including
the
original
headers
like
the
orange
ones
yeah.
So
this
is
just
like
to
remind
you
to
remind
you
what
you're
talking
about.
Then
we
made
a
document.
Traffic
requirements,
use
cases
based
on
the
feedback.
We
got
last
time
and
some
other
feedback
we
get
the
following
things
move
the
implementation
considerations
appendix
because
this
is
kind
of
really
early
work
in
progress
and
may
have
been
not
recommend
that
is
talking
about
the
solution
then
simplified
one
requirement.
D
D
Good
then,
the
next
one
we
had
one
requirement
that
was
not
clear
whether
it
should
be
in
or
not
like.
Do
we
want
to
require
a
single
format
that
cause
all
protection
levels
like
signed
only
or
signed
an
encryption
which
are
left?
Do
we
want
the
single
format
or
is
it
okay?
If
it's
a
shoot
or
should
it
be
a
must
or
don't
we
want
to
talk
about
that
at
all?
Are
there
any
opinions
on
this.
C
How
do
I
put
this?
The
receiving
end
is
going
to
receive
messages
that
are
encrypted
whose
signatures
they
cannot
validate,
simply
because
we
are
terrible
at
validating
signatures
effectively,
there's
using
too
many
error
cases.
So,
yes,
we
will
need
to
handle
the
case
where
your
hat
message
is
encrypted,
but
the
signature
cannot
be
validated,
but
I
don't
think
we
should
be
encouraging
people
to
create
encrypted
messages
that
are
not
signed.
Okay,
they.
D
F
To
do
a
clarification,
this
requirement
is
actually
was
about
the
way
we
do
how
the
protection
will
be
done,
the
same
way
for
signing
an
encryption
case.
We
don't
want
two
different
ways
of
doing
this.
Yeah
I
think
it's
more
of
an
implied
assumption.
So
I
hope
nobody
contest
this,
but
this
is
just
to
confirm.
Okay,
yeah!
Is
this
this
one
yeah?
Am
I
right,
yeah
yeah,
let's,
okay,.
D
D
Actually
it
was
all
referring
to
before
we
left
it
open.
We
started
the
clearest
start
at
an
email
discussion
which
nobody
was
really
engaging
in
to
let
extent
we're
like
addressing
the
backward
compatibility
requirements
and
not
sure
whether
we
get
anything
out
today,
which
we
drink
it
out
last
time,
but
maybe
I
should
sort.
D
So
my
backup
slides
it's
basically
about
these
requirements
and
we
are
pretty
clear
on
the
b1,
but
all
the
rest
is
a
bit
unclear
whether
we
should
do
this
or
not.
Basically,
it's
about
feature
negotiation
kind
of
stuff.
Like
do
we
need
to
tell
other
clients
what
kind
of
stuff
we
support
and
one
issue
was
like
if,
if
different
clients
rating
the
same
mailbox,
you
end
up
with
being
in
a
clear
area.
F
Alex
here
think
these
to
eat.
Well,
this
is
sort
of
two
types
of
issues
distinguishing
between
for
the
unwrapped
and
mobility
negotiation,
I
think
we'll
get
to
them,
but
I
think
there
are
probably
simpler
issues
that
the
main
choice
we
need
to
make
about
how
we
protect
the
header
and
once
we
make
the
choice,
it
will
be
much
easier
to
decide.
You
know
which
ways
it's.
C
This
is
Daniel
con
Gilmore,
so
I
think
that
this
is
the
main
sticking
point
that
we're
running
into
in
thinking
about
ways
to
address
header
protection
and,
in
particular,
just
to
be
clear.
Backward
compatibility
means
a
legacy
client
that
is
capable
of
reading
the
message,
but
maybe
doesn't
know
about
header
protection
scheme
that
we
settle
on
what
happens
for
them
when
they
receive
a
message
that
has
protected
headers.
C
D
F
D
E
D
F
A
A
chair,
I
I,
don't
think
the
requirements
are
helping
us
make.
Decisions
at
this
point.
I
think
that
we
need
to
propose
solutions
to
go
forward
and
have
the
discussion.
From
that
perspective,
the
I
think
the
requirements
got
us
to
a
good
place
where
we
are
now,
but
let's
focus
on
getting
a
solution
that
everybody
can
live
with.
I
think
it's
going
to
be
a
balancing
act,
as
we've
just
heard,
and
so
it's
can.
We
find
a
balance
point
that
we
can
all
live
with
or
we're
all
equally
unhappy
with
right.
Okay,
so
yeah.
A
D
Okay,
so
the
next
two
slides
will
be
probably
causing
some
more
lively
discussions.
It
is
one
aspect
that
actually
track
of
these
things,
not
the
only
one
but
one
aspect.
We
already
had
some
comments
on
a
Mike
on
this.
Basically,
how
do
we
deal
with
rendering
issues
at
the
receiving
site?
Alexei
is
term,
for
this
was
Fiat
artifacts,
so
some
out
some
situations
that
the
receiving
users
are
confused
or
how
do
we
help
broke
clients
that
cannot
handle
encapsulate
the
messages
and
does
also
not
of
all.
D
D
And
what
you're
talking
about
this
some
messages
you
receive
if
you
receive
an
empty
message
in
best
case,
you
see
there
is
an
attachment
and
sometimes
are
able
to
open
it
attachment,
sometimes
not,
and
these
kind
of
things
they
have
been
discourse
some
time
ago,
not
true
or
whether
all
of
these
quarries
are
still
apply
or
whether
they
have
been
has
been
some
improvements
in
clients
because
anyway,
need
to
fix
this
for
for
other
messages,
yeah.
So
that's
what
we
assume
that
there
is
a
problem
in
that
area.
D
D
This
is
like
one
way
to
solve
it
and
the
other
one
is.
We
are
making
a
new
standard
that
helps
the
broken
implementation
or
like
that
all
comes.
There
are
weaknesses,
so
I
call
it
the
workaround
to
the
broken
implementation,
which
some
people
in
the
room
probably
don't
created,
so
walk
around
or
but
I
see
this
way
the
clients
are
broken
and
are
we
fixing
the
clients
or
are
we
going
to
to
do
it?
The
clients
don't
make
this
anymore
like?
Are
we
fixing
something
in
the
format
that
the
clients
don't
do
this?
C
E
D
D
In
a
structure,
so
it's
not
like
putting
the
whole
message
here
in
a
row,
it's
putting
like
speaking
up
the
message
in
headers
and
content
and
make
to
mime
attachments,
I
hope,
I
explained
it
correctly.
Otherwise,
you
can
correct
later
it's
not
correctly
explained.
In
any
case,
it
means
it's
deviation
from
the
current
mime
standards,
which
says
like
you're
up
the
whole
message
in
it
would
allow,
depending
on
the
interpretation,
would
allow
also
such
things,
but
it's
not
like
how
it
has
been
designed
earlier.
D
D
One
thing
is:
if
you
do
such
a
work
around,
what
kind
of
problems
causes
this
we
already
know
of
some
impacts
on
mime
libraries,
especially
if
you
don't
write
them
on
your
own
libraries.
If
you
use
some
and
you
need
to
adjust
them,
and
so
on
is
I.
Call
him
as
well.
Side
effects
have
been
discovered
and
also
like.
If
it
would
is
a
memory,
hole
approach
or
then
there
may
be,
or
there
are
auto
wield
artifacts
whether
or
not
there
were
also
battle.
D
I,
don't
know
at
this
time,
but
still
also,
some
clients
do
not
display
well
what
we
would
do
in
a
workaround,
as
described
by
the
draft
op
mention
above,
and
we
need
to
update
the
existing
research
that
has
been
done
earlier
on
the
real
artifacts
alike,
on
the
clients
that
do
not
behave
well
when
header
protections
apply
it
as
its
defined
in
s/mime.
I.
Hope
I
could
provide
a
good
summary
and
open
the
discussion
about
this
topic.
How
we
go
on.
C
Hi
Daniel
Kongo
I'm,
one
of
the
authors
of
the
the
draft
that
describes
the
legacy
display
part
up
there.
So
thank
you
for
including
that
and
mentioning
it.
So
the
I'm
not
sure
how
many
people
have
read
the
the
draft
auto
crypt
lamps
protected
headers
up
there.
Can
we
people
up
for
raising
your
hand
if
you've
read
if
you've
read
that
draft
okay,
so
the
same
relatively
relatively
small
number
as
well,
so
just
to
be
clear.
C
That
draft
just
describes
two
different
things
that
are
used
in
conjunction
to
try
to
offer
a
form
of
header
protection.
One
thing
is
basically
placing
the
mime
headers
that
you
care
about
at
the
top
of
the
primary
mind,
part
that's
sort
of
the
cryptographic
payload
and
it
describes
how
to
how
to
find
the
cryptographic
payload.
C
The
it
does
not
stick
all
of
the
additional
protected
headers
right.
Every
header
is
protected
in
the
sense
that
it
is
within
the
cryptographic
envelope,
including
you
know,
message
ID
and
things
that
the
user
is
never
exposed
to.
But
the
only
things
that
show
up
in
the
legacy
display
part
are
the
parts
are
the
things
that
the
user
would
typically
be
expected
to
see.
C
We
call
them
user
facing
headers
in
that
document,
so
that
legacy
display
part
is
really
only
to
make
sure
that
a
an
obscured
user
facing
header
is
visible
to
the
user
of
a
legacy.
Client,
that
is
a
client,
that's
capable
of
decrypting
the
messages
and
but
it
but
doesn't
know
about
protected
headers.
So
the
goal
is
explicitly
backward
compatibility
for
that
part,
but
that
part
is
not
intended
to
be
treated
specially
by
the
receiving
client.
C
The
only
actual
special
thing
that
the
client
that
a
non
legacy
client
does
when
it
sees
a
legacy
display
part,
is
hide
it
because
it
actually
knows
what
the
actual
protected
headers
are
by
looking
in
a
mime
structure
of
the
of
the
of
the
received
message,
so
I
wanted
to
point
out
that
that
this
legacy
display
mechanism
is
one
piece
of
of
a
broader
puzzle
for
how
for
how
the
stuff
fits
together.
I
recommend
I
would
appreciate
more
comments
on
the
document.
It
will
get
updated
again
shortly.
C
C
F
It
looks
like
the
only
way
we
can
make
progress
is
to
analyze
how
big
of
impact
legacy
display
issue
is
with
you
know,
wrapping
messages
as
well,
as
you
know,
memory
hole
approach
and
as
well
as
look
at
api's
and
their
limitations
in
open
source
projects
and
other
things.
I
know
it's
somewhat
open-ended
question.
F
How
far
do
we
look,
how
many
implementations
we
evaluate,
but
it
would
be
nice
at
this
point
to
collect
both
screenshots
trying
to
send
you
know
this
heather
protected
messages
to
old
clients
and
see
how
they
display
to
see
how
bad
the
problem
is
and
for
people
to
report
issues
with
API
how
difficult
is
for
them
to
handle
on
the
receiving
side.
Both
approaches.
A
C
This
is
dkg,
so
in
draft
autocrat
lamps,
protected,
headers,
0
1,
there
are
test
messages
and
if
anybody
wants
to
try
to
and
those
test
messages
work
from
using
their
open,
PGP
PGP
mime
messages
and
they
can
be
decrypted
by
the
secret
keys
that
are
available
in
the
reference
draft.
That
draft
refers
to
another
draft
that
has
some
sample
open,
PGP
secret
keys
and
open
PGP
certificates
that
are
capable
verifying
the
signatures
and
decrypting
those
things.
C
C
F
If
it
helps
wait
in
my
email
client,
which
is
what
my
waist
I
can
generate
it
the
type
of
messages,
so
it
might
be
easy
for
me
to
just
very
cool
if
people
want
to
volunteer
so
that
I
send
them
messages
and
they
send
back
screenshots
and
describe
you
know,
or
this
crush
my
client
or
you
know
this
didn't
display-
or
this
is
truncated.
I
think
this
would
be
very
useful
at
this
point
right
I.
We.
A
Do
need
to
do
this
for
us
mine,
because
that's
what
the
Charter
is
here
don't
mind,
helping
the
other
community
along
as
well,
but
that's
what
the
focus
needs
to
be
yeah
if
we
can
just
have
the
test
messages
and
have
a
discussion
about
what
the
user
experience
is
with
each
of
the
approaches
to
find
that
equally
unhappy,
point.
C
So
the
other,
the
other
question
that
Alexa
asked,
so
one
of
them
was
how
do
you
leg
acedia
with
these
messages
and
the
second
question
that
he
asked
was:
how
do
the
libraries
deal
with
them?
So
this
effect,
this
address
is
Bernie's
question
here
about
adverse
side
effects
on
mime
libraries
right
and
I
I'm
wondering
if
we
can't
ask
that
as
a
more
specific
question
as
well
right,
so
we
said
I
think
in
this
case
we
want
test
vectors
for
the
UI.
We
want
test
vectors
and
basically
screenshots
yeah
right.
A
F
Some
well
sometimes
you
can
imply
the
answer
from
how
it's
displayed
or
not
displayed,
and
sometimes
you
might
need
to
dig
a
bit
further
right.
So
the
answer
might
not
be
obvious,
so
I
think
you
know,
for
example,
one
issue
might
be
if
people
have
a
limit
on
how
big
this
header
can
be
from
memory.
Keyhole
approach,
that's
arguably
it's
a
bug,
but
if,
if
it
trans
gates,
it
then
would
be
nice
to
know
and
who
does
it
things
like
this
right,
so
yeah
I
don't
actually.
C
Sorry,
the
question
about
the
UI
for
legacy.
Clients
says
what
do
legacy
clients
do
right,
we're
gonna!
We
all
acknowledge
that
the
legacy
clients
will
be
with
us
forever,
because
this
is
email
and
we
just
want
to
know
what
they
do.
So
we
know
what
what
kinds
of
things
work
we
are
emitting,
but
the
mine
libraries
is
more
I.
Think
a
question
of:
do
we
think
that
existing
mail
user
agents
will
be
able
to
do
something
better
with
this
than
what
the
legacy
clients
do
right?
Will
your
mind?
Will
your
mind
live?
C
C
A
C
C
D
One
has
to
implement
to
actually
understand
what
problem
she
ran
into
and
I
would
like
to
bring
the
risk.
Another
aspect:
I,
don't
know
how
many
s1
implementations
to
be
have
in
the
world,
and
is
this
really
an
issue
for
s/mime
implementations
we
have
so
far.
We
have.
No.
You
know
that
this
has
been
a
problem
with
PGP
mine,
but
I,
don't
know
about
concrete
s,
mine
cases-
maybe
you
have
known
somehow.
D
B
B
To
the
mic
so
way
back
in
the
day,
we
did
these
things
called
implementation
reports
when
you
move
standards
along
the
standardization
path
and
when
one
was
done
for
CMS
and
so
I
believe
that
there
were
nine
implementations.
I
have
no
idea
whether
they're
alive
or
not,
but
I
can
certainly
provide
the
pointer
to
the
thing
about
what
it
tested.
Yeah.
F
A
E
A
F
C
A
F
A
D
D
That
brings
us
some
basis
to
choose
a
solution,
so
what
I
see
is
next
steps
we
already
discussed
on
the
second
last
more
research
and
a
bit
artifacts,
we
already
like
decided
now.
I
would
like
to
close
the
open
issues,
but
probably
are
not
going
to
close
them.
So
you
know
I
have
to
update
to
the
first
forum.
D
Do
we
need
to
confirm
the
set
of
requirements
on
the
mailing
list,
which
test
so
reach
out
to
implement
us
would
also
be
a
good
idea.
Maybe
this
can
be
combined
with
the
current
approach
like
to
see
whether
this
is
it
it's
based
on
requirements
and
update
requirements,
ID
and
at
some
point
in
time
you
should
start
on
the
solution.
Id.
H
H
H
Okay,
so
this
is
the
status
of
the
results
of
the
last
two
meetings
already
for
the
July
meeting.
I
split
the
profile
document
into
a
profile
and
and
updates
document,
as
we
discussed
in
in
Prak
I
included
since
July
the
encrypted
value
exchange
with
encrypted
key,
as
this
was
discussed
as
a
preferred
solution
to
enable
envelope
data
further
the
encrypted
key
packages.
H
H
Okay,
so
status
of
the
lightweight
cmp
profile.
Since
the
last
version
from
july,
I
mainly
completed
the
the
content
of
the
document,
so
I
added
the
support
of
legacy:
PKI
szeliga
CCA's
with
transport
of
p10
requests,
I
added
this
yeah,
quite
quite
large
chapter
on
the
central
key
generation
and
the
encrypted
transport
of
key
packages
with
different
key
transport
and
n
key
establishment
mechanisms.
I
added
the
section
on
the
delayed
enrollment
part
with
a
polling
mechanism
and
I
added
some
examples
for
support
messages.
H
Using
this
a
general
message,
general
response
feature
of
CMP
and
yes,
oh,
they
are
optional,
but
we
know
that
there
are
quite
some
use
cases
where
I'm
getting
a
see
a
chain
updating
a
root
certificate
with
this
total
of
certificates
and
getting
some
request
parameters
in
advance
to
an
enrollment.
So
there
are
some
examples
of
how
to
utilize.
Is
this
general
message
concept
in
NC
MP
yeah?
H
So
we
have
a
request
response
profile
specified
for
enrolling
to
a
new
PKI,
so
it's
quite
academic.
We
could
also
use
this
for
an
existing
already
trusted
PKI,
but
in
CMP
this
is
handled
with
a
different
message
type.
So
we
could
discuss
whether
to
specify
also
this.
So
it's
it's
it
not
not
really
different
to
the
one
with
a
new
PK
I
actually,
but
we
could
could
address
this
as
an
optional
one
if
yeah
I'm
happy
for
for
feedback
on
on
the
for
this
central
key
generation.
H
Management
technique:
you
need
to
make
use
of
a
shared
secret
if
you
have
some
one-time
password
mechanism
that
you
also
want
to
use
for
the
protection
of
the
cmp
message
you
may
want
to
derive
a
different
shared
secret
from
that
one-time
password
for
the
key
transport
mechanism
and
therefore
we
propose
to
use
this
Mac.
This
password
based
Mac
parameter
mechanism
from
the
cmp
Mac
Protection,
even
though
it
it
does
not
fully
fit
and
I
left
some.
Some
comments
in
the
in
the
draft.
The
profiling
draft
and
I'm
happy
for
feedback
on
that.
H
Whether
people
think
that
mechanism
fits
so
there
is
a
section
on
the
transport
of
cmp
messages
for
file
based
transport,
so
I'm
not
sure
whether
to
really
fully
specify
that
maybe
I
just
do
some.
Some
references
in
some
more
general
description
on
what
route
to
think
about.
If
you
want
to
do
the
message,
transport
on
an
offline
or
file
based
a
transport,
but
yet.
C
H
There
is
a
feelings
about
this
section.
Please,
let
me
know,
then,
in
the
update,
CMP
I
will
come
to
that
and
then
on
the
next
slide,
we
added
three
extended
key
usages
for
use
in
in
CMP
and
I
would
like
to
incorporate
and
describe
how
to
make
use
of
this
in
the
context
of
the
profile.
So
this
is
something
I
didn't
manage
to
do.
Since
the
last
update
yeah,
we
have
some
our
IDs
that
are
needed,
especially
for
the
support
messages
they
need
to
be
specified
and
registered
at
the
Ayana
and
yeah.
H
H
Okay,
so
the
CMP
updates
is
much
shorter,
so
what
I
did
since
the
last
update
I
added
the
section
on
these
extended
key
usages?
So
we
think
three
extended
key
usages
are
quite
quite
helpful:
one
to
specify
keys
of
a
CMP
certification,
Authority
one
for
CMP
registration
authority
and
one
for
the
a
CMP
key
generation
authorities
specifically
used
when
you
have
central
key
generation,
because
generating
a
public/private
key
pair
on
behalf
of
some
other
entity
is
a
really
specific
role,
and
this
I
think
should
probably
be
yeah
identified.
H
H
We
do
make
use
of
nested
messages.
Also
for
bundling
messages
on
an
array
sigh
to
forward
that
and
we
cease
as
a
disadvantage
if
you
are
restricted
to
only
incorporate
the
same
message,
types
in
one
nested
message
and
therefore
we
would
propose
or
like
to
propose
to
to
just
delete
the
sentence.
Actually,
we
didn't
find
any
good
reason
why
to
to
restrict
ourselves
that
much.
H
The
second
part
is,
while
writing
the
profiling
on
the
polling
mechanism.
We
realized
that
the
polling
was
not
or
whether
the
the
pkcs
10
certificate
request.
Transport
was
not
covered
by
polling
and
we
thought
quite
a
while
about
it.
This
is
finally
I
think
because
a
pkcs,
10
or
P
10,
CR
CMP
message
has
no
request.
A
A
C
H
C
H
At
the
extended
key
usages
to
the
profile
document
asset,
adding
the
oids
for
these
key
usages
and
register
them
at
Ayana.
Of
course,
at
the
security
considerations
part,
there
is
a
completion
of
the
asn.1
module
needed.
Maybe
I
I
need
some
guidance
on
how
to
do
and
how
much
railing
is
needed.
To
add
to
this
draft
and
yeah,
of
course,
polishing
and
typos
need
to
be
done.
Yeah.
C
B
B
B
A
I
I
A
I
B
B
54
80,
section
3
provides
some
information
about
key
usages,
first,
the
sort
being
subject:
Pablo
key
info
for
our
IDC
public
key
ID,
ECM,
PvE
and
hi
de
CDH,
but
only
only
seven
of
the
nine
values
are
described.
That
seems
like
a
flaw,
so
we'd
like
to
fix
that.
So
what
we're
proposing
is
to
provide
new
requirements
for
the
key
insight
from
it
and
data
insight
from
Ian
say
that
they
must
not
be
set
for
those
things.
I
will
chanter
channel
Ryan
sleeve
he
he
was
not
here.
Who
said
yes,
please.
B
B
A
A
If
you
have
CMS
embedded
in
your
brain
you'll
understand
quickly
that
when
you
could
there's
two
hashes
computed
to
sign
a
message
one
is
you
hash
the
content
that
value
gets
put
in
a
signed
attribute?
Then
you
take
all
the
signed
attributes
and
compute
the
hash
over
that
and
that's
what
gets
signed.
The
issue
is
that,
with
the
number
of
hash
algorithms
we're
getting
that
have
all
the
same
lengths,
it
might
be
possible
to
do
a
hash
substitution
attack.
A
If
it
turns
out
that
one
of
these
hash
algorithms
is
weak,
so
the
proposed
text
says:
use
the
same
hash
algorithm
in
both
cases
don't
get
tricked
and
points
to
RFC
62
11,
which
is
include
a
message
that
has
the
identifier
for
the
hash,
as
well
as
the
hash
values
themselves.
That's
it
it's
kind
of
a
situation
where
we
used
to
have
only
one
algorithm
that
was
256
bit
long,
and
that
is
no
longer
the
case,
and
so
we
just
want
to
include
the
algorithm
identifier,
the
protection
max
you
asked
for
sometime
in
the.