►
From YouTube: IETF106-COSE-20191121-1550
Description
COSE meeting session at IETF106
2019/11/21 1550
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
A
A
A
A
B
B
B
Oh
six
updated,
and
when
I
went
back
to
double-check
earlier
this
month,
I
figured
out
that
the
data
tracker
had
the
wrong
version
and
at
a
point
where
it
actually
had
the
didn't,
have
a
date
that
I
updated
it
in
so
I'm,
not
too
sure
what
happened
on
the
data
driver
that
I
have
a
local
version,
which
has
one
additional
set
of
issues
that
came
from
Lawrence,
where
I
have
harmonized
out
the
difference
between
headers
headers
parameters
in
parameter
to
make
sure
that
they
all
are
consistent.
So
header
by
itself
is
no
longer
exists.
B
B
Next,
please,
oh,
the
Interop
status
is
basically
the
same
as
it
was
at
the
last
meeting.
I've
been
making
wine
I
haven't
been
looking
at
trying
to
get
any
air
up.
Work
done
still
need
some
idea
of
what
the
iesg
thinks
it
wants
Nord
er
to
assess
whether
or
not
we
actually
have
Interop,
but
once
we
get
that
we
I
can
do
some
sort
of
write
up
and
be
fine.
B
B
Ok,
the
cosy
algorithms
draft
next,
so
this
document
went
through
last
call
at
the
same
time
as
the
structured
document.
So
it
finished
we
have
one
at
there's.
One
open
issue
that
is
in
the
current
version
of
the
document
boat
needs
to
be
ratified
by
the
working
group
that
it
actually
is
what
it
wants
to
be,
and
then
the
the
standard
Shepherd
right
up
and
go
to
the
area
director
for
publishing
next.
B
So
I
follow
the
same
basic
structure
that
they
had
where
they
had
a
set
of
capabilities
based
on
the
algorithm
and
a
set
of
capabilities
based
on
the
key
I
thought
and
at
one
point
about
combining
them.
But
I
thought
that
was
probably
gonna
be
more
trouble
than
it
was
actually
worth
in
the
long
run.
So
the
algorithms
based
capabilities
will
always
start
with
a
key
type
if
there
is
actually
a
key
that
is
used
by
that.
B
So,
for
example,
a
hash
algorithm
would
not
have
the
key
type
in
there
because
there's
no
actual
key
used
by
the
algorithm.
You
also
have
the
ability
to
put
capabilities
which
are
not
represented
by
parameters
in
in
the
headers
in
there.
So
one
example
of
that
is
what
I
have
now
for
the
hacks
based
signatures
is
I
actually
have
I
was
actually
in
in
the
Hat
and
it
and
the
key
structure,
but
the
hash
which
the
key
was
based
on,
even
though
that's
actually
not
a
parameter.
B
There's
also
the
key
based
capabilities:
again,
they
always
start
with
a
key
type,
because
without
knowing
that
key
type,
you
don't
know
for
sure
what
the
capabilities
are
supposed
to
be.
In
that
key,
the
assumption
for
algorithms
is
the
algorithm.
Identifier
will
always
be
transported
someplace
else,
but
it
may
be
that
we
want
to
actually
put
that
into
the
into
the
capability
structure
as
well.
B
B
Algorithm
I
attempted
to
minimize
things
so
that
there
wasn't
overlap
between
the
two
of
them,
so
in
the
aw
score
and
the
group
score
stuff,
they
had
think
of
the
curve,
both
in
as
per
as
a
parameter
for
the
algorithm
as
a
parameter
for
the
key,
and
my
assumption
is
they're
gonna
tend
to
actually
be
show
up
in
pairs
or
in
combinations,
so
that
you
only
need
to
specify
things
once
in
general.
The
one
exception
that
is
going
to
be
is
the
key
type
and
I've
got
a
little
bit
of
stuff
here.
B
D
B
A
second
so
I
got
a
set
of
feedback
from
Francisco.
Earlier
this
week,
I
have
made
a
pull
request
which
contains
responses
to
that
and
there's
a
couple
more
things
that
she's
commented
on
since
then,
and
if
I
need
to
make
sure
that
people
want
to
put
the
hash
algorithm
from
in
in
the
hash
signatures
capabilities,
it
could
either
be
in
there
or
it
could
not
be
in
there
either
way.
Probably
it
will
work,
I,
don't
know,
there's
any
other
capabilities
that
should
be
put
into
that
as
well.
B
D
B
D
I'm
a
bit
confused.
If
you
would
because
in
this
case
that
we
have
defined
right
now,
then
you
would
just
go
and
look
at
what
are
the
cover,
your
disease
of
the
key,
and
you
would
use
that
for
the
rhythm
and
if
we
define
something
that
is
different,
I,
don't
know
if
these
are
additional
ones
or
would
replace
the
one
for
the
key
type.
B
They
would
be
additional
ones.
For
example,
if
you
did
the
diffie-hellman
key
agreement
once
right
now,
we
basically
pack
everything
together
into
one
identifier,
so
that
identifier
describes
not
only
whether
you're
doing
a
femoral
static,
but
whether
you're,
the
fact
that
using
HK
DF
for
the
key
derivation
function.
The
fact
that
you're
doing
AES
128
for
the
key
rap
and
the
fact
that
using
a
particular
structure
for
the
context,
one
could
envision
in
the
future
that
you
might
define
a
diffie-hellman
key
where
those
are
all
actually
header
parameters.
D
C
B
This
document
has
gone
to
working
group
last
call
that
finished
on
September
24th
I
have
not
gone
through
this
document
to
put
in
the
capabilities
definitions
but
they're.
Pretty
simple,
since
is
just
plain
hash:
algorithms
they're
all
going
to
be
empty,
empty
array
either
on
DME,
because
there's
not
Noth,
nothing
relevant,
milkie's,
so
I'm
planning
to
do
that,
modifications
and
publish
that.
B
A
B
B
B
A
B
B
C
B
I
have
actually
pushed
up
a
more
algorithms
document.
Next,
it
contains
one
algorithm
right
now
and
that's
the
AES
padded
key
wrap
algorithm.
It
is
currently
defined
only
as
a
key
wrap
algorithm
at
the
point
where
I
talked
to
Russ.
He
wanted
it
to
be
both
a
here
algorithm
and
a
content.
Encryption
algorithm
the
step
this.
The
structure
document,
however,
has
a
statement
that
says
every
content.
Encryption
algorithm
must
be
an
AEA
D
algorithm.
B
B
So
we
got
a
piece
of
mail
today
from
Bob
Moskowitz
I,
don't
remember,
it
went
to
the
list
or
if
it
just
went
to
the
chairs
myself
saying
that
he
thinks
we
should
add
the
new
C,
HC
Shaykh
algorithms,
to
the
set
of
algorithms,
which
we
have
I,
don't
have
any
problems
with
that
I.
Don't
have
any
other
algorithms
at
this
point
in
time
to
add.
C
B
E
E
You
just
saw
on
my
slides
by
mistake.
So
what's
happened
since
we
last
met
our
heroes
in
Montreal,
we've
had
a
working
group
last
call
with
substantive
and
useful
reviews
by
many
parties,
including
JC
Jones
and
Kevin
Jacobs
of
Mozilla,
our
own
Jim
shod,
Neo,
Madden
and
Ben
Caidic
I
am
the
co-authors
addressed.
Those
working
group
last
call
reviews
replying
to
all
the
comments
received
on
our
public
mailing
list.
I
will
note
that
no
normative
changes
to
the
document
resulted.
E
B
Far
as
I'm
concerned,
I
still
have
one
concern
that
is
outstanding
from
your
document.
From
the
from
my
last
call
I
believe
you
need
to
describe
why
the
approach
of
assigning
points
was
was
used.
It
doesn't
need
to
be
very
long.
It's
just
I've
just
wanted
in
the
document
telling
me
is
not
sufficient.
E
Okay,
I'm
perfectly
willing
to
do
that.
That
issue
for
those
of
you
who
may
not
have
followed
everything
on
the
list
and
Jim
correct.
My
description,
if
you
would
like
is
that
for
both
Jose
and
Jose,
we
defined
an
algorithm
identifier
whose
meaning
is
ECDSA
signature
with
the
sec,
P
256
K
one
curve
and
the
P
R
in
the
sha-256
hash
algorithm.
E
Useful
working
group
last
review
comments.
He
had
asked.
Well,
why?
Don't
you
just
use
the
existing
Jose
algorithm
identifier
for
ECDSA
and
part
of
the
answer
is
to
be
consistent
with
Jose,
where
in
each
case,
the
algorithm
identifier
is
specific
to
a
serve
so
that
when
you
look
at
the
algorithm
identify
er,
you
have
a
complete
description
of
what
you're
doing
I
and
several
others.
That
I
talked
to
were
unaware
that,
because
they
didn't
follow
that
route,
but
that
doesn't
mean
that
for
new
algorithms
we
can't
do
that
and
shouldn't
do
it
and.
E
So
in
part,
Jim
had
also
asked
a
question
in
review
in
his
review.
How
do
you
know
if
somebody
has
changed
the
curve
on
the
key
that
you're
presented,
and
the
good
news
is
that
if
you
have
this
because
a
algorithm
identifier
that
is
key
and
or
that
is
curved
and
hash
specific,
you
can
tell
if
somebody's
changed
it
if
you're
just
using
a
general
ECDSA
algorithm
identifier,
it's
amenable
to
attacks
where
you
can
change
the
curve
and
still
get
the
person
to
perform
the
computation
Mike.
B
B
More
or
less
that's
actually
what
I
want
to
hear
in
the
document?
Suppose
I
were
to
take
AP,
256
key
and
change
the
the
curve
to
the
2
to
the
K,
algorithm
and
hands
you
a
message
sign
with
a
kit
with
the
K
algorithm
and
that
key.
How
can
you
tell
that
I
changed
the?
That
would
be
what
used
to
said
as
what
caps
that
problem
would
not
catch
that
problem.
E
So
I
think,
because
there's
a
generic
ECDSA
algorithm
identify
are
already
in
COEs
a
the
protections
only
operate
in
one
direction:
that
if
you're
using
SEC
P,
256,
K
1
and
it's
corresponding
algorithm
identifier,
you
can
be
assured
that
nobody
can
change
the
curve
to
P
256
and
get
away
with
it.
No.
E
B
E
B
E
E
C
E
C
That
was
everything
we
had
in
our
agenda
for
today.
I
think.
The
only
other
thing
to
note
is
the
the
draft
ITF
cozy
hash
sig
document
is
currently
in
is
G
evaluation.
It's
tell
chat,
is
I
believe
the
first
tell
chat
after
after
this
this
meeting
week,
so
hopefully
we'll
be
progressing
all
the
way
to
putting
one.
Our
first
document
into
the
RFC
editor
queue
here
soon.
So.