►
From YouTube: IETF112-COSE-20211110-1430
Description
COSE meeting session at IETF112
2021/11/10 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
A
A
A
A
A
A
C
C
B
So
there
is
a
pr
on
the
on
the
struct
draft,
which
is
doing
just
that,
adding
adding
the
int
and
then
what
it
was
in
the
mail
exchange
on
what.
How
should
we
handle
this?
Given
that
the
draft
is
in
a
progress
state-
and
I
think
the
proposal
was
that
we
should
actually
try
to
make
the
change
in
the
document
now.
But
the
question
is:
do
we
need
to
have
further
reviews,
or
how
can
we.
D
D
B
B
C
E
E
E
I
I
don't
have
a
strong
opinion
on
the
point
itself,
whether
we
need
the
the
numeric
key,
but
I'm
also
not
working
with
the
protocols
that
would
benefit
from
that
most.
So
I
leave
it
to
others
to
make
that
point,
but
I
want
to
say
that
the
process
argument
is
important,
but
I
don't
think
it
actually
applies
to
this
particular
situation.
D
B
G
Yeah,
I
I
agree
with
what
harrison
said
that
this
is
something
that
is
learned
from
experience
and
can
very
well
be
done
in
an
infinite
standard.
I
definitely
don't
think
this
is
a
breaking
change,
as
this
is
as
breaking
as
registering
a
new
algorithm.
If,
if
you
use
that
new
algorithm,
none
of
the
old
deployments
will
be
able
to
talk
to
you,
so
I
I
don't
really
understand
why
this
would
be
more
breaking
than
registering
like
kiran
said.
As
a
bit
surprised.
I
think
this
was
discussed
quite
long
and
was
from
support.
G
D
C
C
Last
call
and
I
believe,
also
an
itf
last
call
because,
as
mike
points
out,
this
is
in
some
sense
a
significant
change.
It's
not
something
I'm
comfortable
just
doing
at
the
last
minute.
In
all
48,
there
is
the
potential
for
real
consequences
for
implementations,
and
so
it
would
be
something
that
we
need
focused
attention
on.
D
C
D
F
Decades
and
I
can
find
going
from
proposed
to
standard
cases
where
important
changes
were
made
because
there
were
oops
or
we
lack
something
or
whatever
and
we've
had
to
make
changes
and
because
we've
fielded
things,
we've
learned
that
we
don't
have
the
flexibility
we
need,
for
whatever
reason
almost
always,
there
was
some
versioning
that
we
could
use
to
make.
So
we
didn't
break
what
was
deployed
and
make
products
migrate
cleanly
to
what
is
standard.
F
So,
hopefully,
there
is
some
version
that
we
can
use
for
making
this
change
as
to
what
was
just
mentioned
in
the
in
the
in
by
dkg.
If
we
got
products
that
don't
look
at
version
before
they
start
decoding
the
things,
that's
their
problem,
that's
why
we
have
versioning
in
in
these
sorts
of
things.
So
we
hope
we
have
urgently
so
I'll
just
wrap
up
with
that
that
at
as
a
community,
we
do
make
these
sorts
of
changes
as
a
community.
That's
why
we've
learned
painfully
to
include
versioning.
E
A
E
So
a
version
would
probably
only
cloud
the
issue
here.
So
the
the
essentially
the
the
major
type
in
that
field
plays
the
same
role
that
a
vagina
would
play
in
another
situation.
So
if
I
were
going
to
build
a
separate
extension,
I
would
simply
say:
let's
extend
the
data
type
of
that
element,
and
people
will
notice.
If
they
don't
interpret
it.
A
So
then
tell
us
two
documents
on
this
page
are
the
x509
that
we
will
discuss
on
the
next
slide.
It
is
in
its
pasta,
adhd
evaluation,
but
there
are
still
a
few
small
things
that
we
need
to
improve
before
it
can
be
progressed
after
that
and
the
last
one
is
the
countersin
draft
which
needs
to
be
sent
to
the
is3,
and
this
will
be
done
right
after
this
meeting.
I
think
yes.
A
A
A
A
A
G
A
A
A
B
B
B
The
results
from
the
rust
code,
which
is
in
the
github
repo,
there
was
one
proposal
we
discussed
this
last
time
during
the
interim,
and
that
is
that
the
revocation
parts
that's
currently
only
talking
about
crls
should
be
moved
to
a
separate
draft.
So
we
should
try
to
complete
this
part
without
revocation
and
then
have
serials
and
other
revocation
aspects
in
a
separate
drafts.
B
G
Not
much,
I
think
we
will
have
more
time
for
c
579
here
after
after
I
theft
hundred
and
twelve,
so
I
will
I
plan
to
do
some.
I
already
have
some
updated
code
or
some
bugs
in
the
old
code,
and
it
didn't
support
everything,
so
the
code
has
been
updated.
I
will
share
that
in
a
month
when
I
have
checked
it
also
yeah.
E
E
E
C
There
are
multiple
ways
to
do
so,
which
include,
but
are
not
limited
to
crls
and
ocsp
as
specified
in
this
other
document.
But
if
you
want
to
do
your
own
thing
that
also
meets
the
requirements
of
this
spec.
That's
the
sort
of
construction
of
the
relationship
between
documents
that
we
see
with
some
regularity.
B
I
Some
concern
to
move
forward
with
this
draft
without
having
you
know
a
crl
draft
or
some
kind
of
revocation
draft
that
you
could
point
to
that
would
follow.
I
mean
it
seems
like
it
would
be
kind
of
a
gap
that
could
you
know
during
sector
review
or
something
else
could
be
raised
and
kind
of
block
moving
this
d509
from
moving
forward.
C
Yeah
you're
sort
of
pointing
out
that
there's
a
risk
that
we
end
up
in
a
state
where
we
try
to
publish
c509
and
the
other
stuff
just
isn't
ready
yet,
and
you
know
we
could
sort
of
force
the
issue
by
putting
in
a
normative
reference
so
that
the
rfc
will
not
actually
be
published
until
they're.
Both
ready-
and
you
know
I
I'm
amenable
to
that-
for
many
of
the
reasons
you
described,
but
I'm
reluctant
to
say
that
it
is
definitely
required
without
getting
some
further
input.
J
J
J
I
don't
think
that
means
that
this
should
necessarily
hold
it
up.
You
could
reference
the
existing
x-509
must-staple
questions
and
granted
that
wouldn't
work
for
it
wouldn't
necessarily
work
for
a
native
c-port,
but
you
could
normatively
reference.
Existing
x-509
must
staple
stuff
start
work
on
the
must
staple
ocsp
or
crl
work.
That's
cbore
specific
and
leave
that
out
of
a
normative
reference
in
this
particular
draft.
Just
have
that
subsequent
draft
update
this
one.
E
E
G
A
A
H
Okay,
all
right,
thank
you
just
as
a
bit
of
background.
This
is
work
that
was
started
in
the
suit
working
group
where
this
same
set
of
authors
was
working
on.
How
do
we
encrypt
a
firmware
load
and
we
decided
that
it
might
be
better
to
have
a
the
hpke
mechanism
in
in
cos
a
because
we
probably
weren't
the
only
ones
who
were
going
to
need
it,
and
so
basically
we
extracted
that
piece
out
of
the
suit
document
and
are
proposing
that
the
cos
a
working
group
adopted.
H
You
can
see
that
the
document
suit
firmware
encryption,
zero,
zero,
basically,
is
there
we
wanted
to
be
able
to
support
pre-shared
keys,
and
that
was
already
offered
by
cos
a,
but
we
also
wanted
to
do
the
hpke
approach,
which
was
not
already
straightforward.
In
cos
a
so
we
wrote
our
own
structures
and
we
wanted
to
bring
them
here
so
that
others
can
make
use
of
that
same
work
as
opposed
to
it
being
tied
tightly
to
the
firmware
encryption
next
slide.
H
H
We
wanted
to
point
out
that
there's
already
some
implementation
experience
with
this.
The
folks
at
arm,
in
particular
honest,
has,
has
done
this
work,
but
it's
based
on
steve,
farrell's,
happy
key
work
that
was
done
before
that
happy
key
relies
on
openness,
cell
and
so
on.
But
this
is
the
point:
is
it's
not
just
a
paper
spec?
H
So
I
think
that's
the
last
slide,
but
I
did
want
to
point
out
that
yesterday,
there's
been
some
discussion
on
the
main
list
about
this
document
already,
and
you
know
we'll
will
of
course
take
the
spec
wherever
that
discussion
leads.
If
the
group
chooses
to
adopt
it,
I
think
that's
it
over
to
the
chairs.
A
I
H
No,
we
don't
so
in
suit.
We
always
have
a
signature
and
we
optionally
have
encryption,
and
so
we
were,
depending
on
that.
We
kose
has
a
similar
structure
where
there's
a
signature
or
an
encryption,
but
we
could
look
at
that.
If
there's
a
need
for
it,
but
that's
that's
the
current
way.
We,
the
the
division,
is
done.
K
K
Yeah
thanks,
so
you
mentioned
you
wanted
to
add
a
deterministic
authenticated
encryption
mode.
I
had
brought
up
adding
such
a
mode
to
the
hpke
and
cfrg
and
I
received
a
lot
of
pushback.
Yes,
I'm
wondering
if
you
have
a
better
use
case
than
what
I
was
suggesting.
Could
you
explain
what
your
use
case
is.
K
H
K
H
G
Yep,
I
think
this
is
great
work.
I
think,
because
I
should
work
on
this.
Just
the
more
high
level
question
to
cool
see.
How
do
we
see
is
hpk
the
future
of
key
exchange
in
in
cozy
or
do
we
continue
to
add
more
non
hpk
algorithms,
also
to
cosi
in
very
shortly
there
will
be
new
pqc
cams,
they
will
probably
be
added
to
hpke
and
they
will
need
to
be
supported
in
cosi,
will
be.
G
H
Yeah,
I
I
don't
know
the
answer
to
that
either.
I
think
lamps
is
struggling
with
the
same
question
as
the
post-quantum
kem's
come
along.
What's
the
cleanest
way
to
embrace
them,
we're
talking
about
a
kem
recipient
info
in
that
environment,
a
similar
thing
could
be
considered
here.
I
don't
know
what
the
best
answer
is,
and
it's
really
hard
to
guess
what
future
algorithms
will
will
look
like
and
what
parameters
they
all
need.
So
I
guess
this
is
part
of
the
pain
of
being
algorithm,
agile,.
H
A
A
A
C
L
L
L
All
right,
good
morning
afternoon,
everybody
I
see
I
have
less
than
five
minutes
left,
so
it's
probably
going
to
be
hard
to
go
through
the
slides,
but
I
will
try
anyway,
I
to
catch
the
main
concept.
So
what
I
wanted
to
do
today
is
try
to
introduce
a
way
to
use
ecdsa,
which
is
very
well
known
and
has
been
over
20
years
in
a
way
that
allows
faster
verification,
and
I
think
it's
a
useful
effort
for
this
group.
L
So
this
is
a
very
nice
algorithm
and
has
been
widely
adopted,
but
the
problem
with
it
is
that
it
doesn't
really
allow
a
fast
batch
verification,
so
checking
a
number
of
sequences.
At
the
same
time,
there's
also
a
way
to
speed
up
a
single
verification,
but
that
is
only
possible
if
we
use
similar
to
like
ed
dsa,
so
the
essentially
the
bernstein
signature,
where
the
signature
instead
of.
L
L
Ecd
is
a
star
slide,
and
then
it
suddenly
becomes
only
an
algebraic
equation
that
has
to
be
checked,
and
so
that
allows
a
speed
up
of
roughly
30
percent
in
the
single
verification
case,
and
if
you
have,
for
example,
a
certificate
chain
or
you
have
for
whatever
reason
you
want
to
check
multiple
signatures,
the
same
load,
balancing
or
something
like
that,
then
you
can
get
a
speed
up
of
roughly
a
factor.
Six
and
the
downside
is
that
that
the
speed
up
only
applies
if
we
use
a
slightly
different
format
for
the
signature
itself.
L
L
L
What
he
can
do
is
he
can
try
to
pick
any
ecdsa
signature
of
these
two
options
at
will
and,
as
you
see
if
we
have,
for
example,
the
rule
that
we
always
want
to
have
the
y
corner
to
be
even
then,
we
in
this
case
pick
option
two,
but
in
in
any
case
in
in
all
in
all
signatures.
We
have
two
options,
one
of
them
with
the
assigning
keys
y
corner
to
be
odd
and
the
other
one.
Even
so,
let's
look
at
this
suppose.
L
L
So
it
remains
an
ecdsa
signature,
but
since
the
signature
consists
of
the
the
x-coordinate
of
the
signing
key
and
the
y-coordinate,
if
we
know
this
the
parity
of
that
y-coordinate,
we
can
uniquely
recover
the
thermal
signing
key
from
the
signature
itself
without
first
doing
the
entire
verification
and
that
allows
to
speed
up
so
the
procedure
to
get
to
more
of
these
two
signature
schemes.
Versions
together
is
that
we
generate
the
signature,
always
in
the
same
way
as
we
have
done
the
like
the
last
20
years.
A
L
Interest
yeah
yeah
go
to
the
last
slide,
so
I
think
we
don't
really
have
time
to
go
over
all
the
details,
but
the
main
reason
that
I
wanted
to
present
something
is
right
now:
there's
lots
of
interest
in
initiatives
that
use
josie
signatures,
for
example,
in
e-health
initiatives,
for
example,
just
to
get
in
a
restaurant.
You
have
to
show
you
qr
codes,
there's
lots
of
things
and
that
uses
jws
signatures
and
I
think,
there's
an
excellent
opportunity
to
make
some
of
these
things
speedier.
L
A
Yes,
thank
you
for
the
presentation.
If
people
are
interested
for
sure
be
sure
to
reach
out
to
renee,
he
hasn't
smells
to
demonically,
so
you'll
find
also.
There
are
his
coordinates
and
we
are
quite
over
time.
So
unless
there
are
any
special
comments,
I
think
we
can
close
at
that.
Thank
you
very
much
for
the
participation
and
have
a
nice
day.