►
From YouTube: COSE WG Interim Meeting, 2021-10-12
Description
COSE WG Interim Meeting, 2021-10-12
A
Hello.
Everyone
welcome
to
the
cozy
virtual
interim
meeting.
This
is
again
an
idf
meeting
and
as
such
not
well
applies.
Please
read
it
carefully.
If
you
haven't
done
so,
and
if
you
have
any
questions,
do
not
hesitate
to
ask
me
or
any
of
the
other
chairs.
A
A
So,
yes,
is
there
anything
else
that
you
think
we
should
discuss
during
today's
meeting.
B
A
Okay,
okay.
Well,
I
believe
we
should
have
plenty
of
time
for
a
discussion
if
there
are
any
other
topics
at
the
end,
but
for
now
let's
get
started
so
the
minutes
will
be
taken
at
the
following
address.
A
Please
take
a
look
at
them,
especially
if
you
have
some
comments,
make
sure
that
they
are
if
there
is
anything
important
to
be
taken
from
them.
They
are
represented
in
the
minutes
or
if
there
are
any
action
items
that
they
are
at
the
top
of
the
minutes
in
the
appropriate
section.
A
Otherwise
I
will
try
to
take
a
look
at
that
and
I
believe
matu
will
also
be
helping
me
a
bit
with
that
and
I
will
not
be
monitoring
chopper.
Is
there
anyone
that
will
be
monitoring
it
and
in
case
there
is
anything
to
be.
A
And
with
that,
I
think
we
can
go
to
the
next
slide,
so
there
are
three
documents
that
are
fairly
advanced
already
in
the
rfc
editor
had
the
hash,
algorithms,
the
rfc
8152
piece,
which
will
be
rc
1953
it's
in
hot
48,
and
for
that
one
I
believe
pretty
much.
All
the
questions
are
answered
and
we,
the
rfc
editor,
is
only
waiting
for
a
final
confirmation
for
the
rfc
1952
2p.
A
I
don't
think
ben
is
here
at
the
call
right
now,
but
I
will
reach
out
to
him
and
make
sure
if
there
is
any
needs
for.
A
A
I
think
that's
the
status
of
those
three
drafts.
There
will
be
a
separate
flight
with
few
items
for
the
x509
draft.
That's
I
think
we
should
discuss
and
for
the
counter
sign
draft
there
is
the
shipper
tried
up
which
somehow
it
shares
missed
and,
and
now
we
saw
it's
there,
so
I
believe
we
are
ready
to
request
a
publication.
A
A
A
A
A
C
Yeah,
thank
you.
So
there
is
a
big
danger
here
of
of
dreaming
up
some
specific
policy
and
then
trying
to
to
make
the
mechanism
enforce
that
policy,
and
that's
often
the
mistake
that
is
made.
There
is
also
this
mistake
of
made
that
if,
if
a
particular
policy
is
is
kind
of
universal,
maybe
you
actually
do
want
to
make
it
part
of
the
mechanism,
but
the
the
problem.
With
the
discussions
about
putting
these
x5
parameters
into
the
the
protected
the
header
really
was.
C
So
unless
the
the
presence
of
that
certificate
in
the
communication
heads
has
an
additional
semantics
that
we
didn't
make
explicit,
it
should
never
necessarily
never
be
necessary
to
do
that.
You
still
may
want
to
put
them
into
protected
to
to
possibly
gain
protection
against
disclosure,
but
you
know
when
you
want
to
do
that
so
so
there
is
no
need
to
actually
make
this
part
of
the
mechanism.
C
It's
it's
enough
to
point
out
that
this
is
the
place
you
would
put
them
if,
if
the
environment
is
doing
encryption
for
you
and
you,
you
need
to
have
confidentiality,
but
I
think
that
that
we
have
to
be
really
careful
about
not
imparting
any
any
weird
additional
semantics
to
these
attributes,
except
that
this
is
information
that
may
be
useful
for
the
recipient
to
have
it.
It's
not
an
instruction
to
change
their
behavior.
C
It's
just
things
that
that
are
in
there
that
that
may
make
the
life
easier
for
the
recipient,
and
whenever
we
actually
want
to
to
change
the
behavior
of
the
recipient,
then
we
should
have
attributes
that
make
this
very,
very,
very
explicit.
A
D
So
karsten,
I
encourage
you
to
go.
Read
that
section
of
rfc
2634.
D
I
think
you'll
find
that
what
they're
concerned
about
here
is
two
ca's
who
have
authority
over
the
same
name,
space
stepping
on
each
other.
D
That's
a
different
kind
of
a
problem,
and
I
agree
with
everything
you
said,
but
they're
just
trying
to
deal
with
it
with
that
and
so
carrying
enough
context
to
know
to
deal
with
that
situation.
But.
E
E
Unless
you,
you
know
you
are
secure,
not
doing
that,
but
now
I
think,
there's
two
possibilities
here:
to
make
it
secure
you
put
it:
either
you
put
the
bank
chain
or
in
protected,
or
you
put
the
x
additional
x5t
and
protect
it.
I
think
I
think
the
the
current
remaining
discussions
are
how
hard
or
loose
these
recommendations
should
be.
There
was
some
discussion
between
michael
richardson
and
lawrence
lund
dale.
I
think-
and
I
I
think,
as
long
as
there
is
a
recommendation,
I
can
leave
with
any
any
normative
text
here
should
remain
or
yeah.
E
E
A
Any
other
comments
on
the
how
a
strong
color
encouragement
of
using
the
protected
headers
should
be.
I
saw
that
michael
just
joined,
so
I
guess
he's
not
exactly
aware
of
the
discussion
so
far.
But
yes,
we
said
so
far
that,
as
long
as
there
is
a
recommendation
to
put
the.
A
A
So
the
discussion
was,
I
believe,
between
john
and
carson
any
comments
on
what
is
necessary
to
to
bring
this.
E
I've
yeah,
I
seen
I
open
this
issue.
I
added
something
very
quick
to
the
the
pr
that
we
just
discussed
and
then
I
think
I
asked
for
more
information
more
comments
on
the
on
the
list.
I
think
carlston
provided
some
very
general
feedback
on
media
types,
but
without
any
concrete
suggestion
for
this,
I
think
I
personally
don't
have
much
any
strong
opinions,
but
it
would
be
good
if,
if
whatever
we
do
here
in
line
with
general
guidance
and
best
practice
when
it
comes
to
media
types,.
C
I
don't
know
whether
that's
actually
always
true,
whether
you
can't
have
a
chain
plus
a
bag
of
other
stuff.
So
it's
the
thing
either
unordered
or
is
it
linear?
I
think
it
might
be
a
tree
and
I'm
trying
to
understand
how
important
these
these
cases
are
and
well.
If
we
don't
want
to
have
media
types
for
all
the
the
37
structures
we
can
imagine
here,
we
could
have
one
media
type
and
just
make
the
the
object
itself
expressed,
whether
it's
a
chain
or
a
bag
or
a
tree.
A
A
And
maybe
even
the
more
general
question
how
we,
how
we
decide
on
that,
I
mean
right
now
to
me
personally,
it
seems
fine
to
have
only
one
media
type,
but
how?
How
can
we
decide
that.
E
C
C
E
E
C
C
A
E
I
think
the
name
is
c5s.
C509
could
define
something
different
from
this
for
this,
I
think
we
need
to
decide.
Do
we
need
do
the
see
x5
you
need.
Does
it
need
to
support
both
bag
and
and
chain,
or
is
one
of
them
enough,
and
if
we
need
to
support
both,
do
we
have
two
different
media
types
or
a
single
media
type
with
some
internal
information
differently
between
bag
and
chain?
E
Everything,
except
that
I
think
it's
not
a
discussion
about
media
type.
Then
then
we're
going
into
should
be.
Is
this
the
right
header
parameters.
C
A
A
At
the
same
time,
I
don't
think
we
should
delay
indefinitely
the
publication
of
this.
C
So
I
think
that
the
cleanest
solution
is
to
have
a
media
type
called
cosi,
x,
509
sets
where
the
the
plural
is
in
the
word
sats,
and
then
we
we
just
have
maybe
a
slightly
more
expanded
wording.
C
A
E
A
Either
today
or
tomorrow
and
yeah,
let's
start
from
there,
okay.
Well,
thank
you
for
this
discussion.
If
is
nothing
else,
maybe
we
can
go
to
the
flights
from
jordan.
A
B
Okay,
so
these
are
four
four
things
which
have
three
of
them
have
been
discussed
on
the
mailing
list
and
the
fourth,
the
last
one
is
is
new
and
the
first
one
is
the
only
one.
That's
really
strict.
The
other
is
a
little
bit
more
more
loose.
B
B
So
there's
been
a
discussion
starting
off
in
the
lake
working
group,
moving
over
to
the
cozy
working
group
with
the
the
mail
referenced
here
about
defining
key
id
or
extending
key
id
to
the
key
identifier,
cosy
header,
to
be
an
int,
and
this
is
turns
out
to
be
useful.
It
saves
bytes
needed
for
for
lake
and
and
it's
kind
of
a
natural
way
of
identifying
keys.
B
B
And
then
there
was
a
discussion
on
the
cosy
mailing
list
and
we
agreed
that
it's
better
to
at
least
those
who
participated
in
the
in
that
discussion.
Agree
that
it's
better
to
extend
the
existing
kid
to
int
and
then
the
question
was:
should
we
make
this
in
a
separate
draft,
or
should
it
be
done
in
lake?
Should
it
be
done
in
coast?
It
was
the
first
question
and
ben
chimed
in
and
said:
he'd
rather
see
this
happen
in
cozy,
because
there
would
be
charter
changes.
B
If
we
were
updating
the
struct
draft
in
lake
and
then
the
question
was,
if
we,
if
it's
a
separate,
should
we
do
it
in
a
separate
draft,
or
should
we
do
it
in
the
struct
draft,
which
is
a
very
late
of
course
change,
and
there
was
a
proposal
from
francesca
to
actually
consider
doing
it.
B
Indestruct
draft,
which
was
agreed
by
john,
I
think
so
we
are
in,
was
48
with
this
track
draft,
but
we've
been
in
auth
48,
for
I
think
two
and
a
half
months,
so
it
would
would
extend
the
it
would
delay
that
draft,
but
perhaps
not
significantly
and
the
to
illustrate
the
changes.
B
There
is
a
pr
number
34
and
there
are
four
commits
or
actually
no,
it's
actually
four
changes
in
of
the
kind
you
can
see
on
this
page
here
where
bit
by
string
is
this
slash,
isn't
added
to
byte
string
and
that
that's
essentially
it
everything
else
seems
to
work
just
fine.
B
So
that's
the
proposal
to
to
merge
that
pr
and
yeah
what
what
do
you
think.
D
This
is
russ.
What
happens
if
one
party
is
using
into
another
parties
using
the
the
beester.
B
B
You
have
different
seaboard
types
and
you
identify
by
this
by
the
seaboard,
whether
it's
it's
a
byte
string
or
an
int.
So
you
would
note.
B
Oh
sorry,
maybe
maybe
I'm
confused
so
if,
if
you
identify
it
with
the
with
a
byte
string,
when
the
both
party
needs
to
identify
it
with
the
byte
string,
basically.
D
D
Yes,
subject:
key
identifier
and
authority
key
identifier
are
octet
strings,
which
is
why
I
think
this
was
a
bit
of
easter
was
to
just
copy
those
values
in.
B
Sorry,
I'm
not
following.
Maybe
someone
else
is.
D
B
C
D
E
C
Again,
generally,
you
you,
you
use
a
key
id
that
that
is
identifying
the
key.
So
if,
if
the
property
of
the
key
is
that
it's
identified
by
a
byte
string,
you
use
a
white
string
and
if
the
property
of
the
key
is
that
that
it's
identified
by
an
integer,
you
use
an
integer.
So
I
think
that
the
potential
for
confusion
is
is
very
limited.
Unless
there
are
keys
that
naturally
map
to
both
byte
string
and
integer
key
ids,
in
which
case
you
would
actually
have
to
say
what
what's,
what
you
should
use.
D
Uses
an
octet
string,
the
byte
string
is
the
one
that
avoids
exactly
conversion.
C
C
C
So
the
integer
is
meaningful
if,
if
the
context
from
which
you
interpret
the
key
id
actually
counts
or
enumerates
keys,.
D
C
Make
sure
we're
not
going
to
yeah?
I
just
think
the
potential
for
confusion
is
limited
unless
we
have
the
the
weird
situation
that
you
can
use,
both
a
byte
string
and
an
integer
to
try
to
identify
keys,
and
there
may
be
confusion
which
one
you
actually
mean.
F
Yeah
process
wise
since
the
document
is
in
auth,
48.
ben
is
not
here,
but
I
would
expect
that
there
will
need
to
be
some
sort
of
last
call
or
call
for
community
feedback.
I
mean
there
has
been
discussion
in
the
working
group,
but
maybe
russ
or
people
with
more
experience
can
say
something
about
that.
D
A
Question,
have
you
considered
what
would
be
the
implementation
cost
of
having
this?
Is
it
something
that.
B
Was
part
yeah
yeah,
great
great
question
that
was
actually
part
of
the
of
the
mail
thread.
Lawrence
landblade
had
one
comment
about
this
and
he
was
asking
if
this
really
worthwhile
and
and
then
in
the
end,
I
think
he
was
convinced
by
the
arguments,
so
it
has
been
brought
up
on
the
mail
mailing
list.
B
A
B
B
This
slide
is
here
just
because
it
appeared
on
the
on
the
draft
agenda,
but
it's
not
only.
It
was
taken
out
from
the
draft
agenda,
so
I
don't
know
if
I
need
to
say,
but
just
just
for
the
status
update
on
this
draft
this
the
base
specification
is
stable.
B
B
B
I
suppose
that
there
it
was,
we
didn't
plan
to
make
an
update
for
for
the
next
meeting.
So
we're
basically
looking
for
comments
until
until
the
meeting.
Okay,
basically
that
that's
when
we'd
like
to
have
a
well,
preferably
like
a
week
or
two
before
for
the
meeting.
B
B
B
E
E
E
Then
we
got
to
comment
that
we
should
add
crls
and
ucsp
from
uri
and.
E
At
the
beginning,
I
felt
like
maybe
a
different
draft
is
better
for
that,
but
now,
when
I
started
adding
them
the
you
can
reuse
very,
very
much
from
the
original
things.
So
adding
them
to
this.
Everything
to
the
same
draft
would
not
be
so
much
extra
work
and
might
be
worth
it,
but
I
guess
it
depends
on
on
how
soon
we
will
have
want
to
have
the
base
specification.
C
When
you
not
only
have
to
add
text
to
the
draft,
you
also
have
to
implement
it
and
and
get
it
reviewed
and
throw
some
real
world
class
at
it
and
and
see
what
happens
and
so
on.
So
it's
not
entirely
trivial
and
I,
I
think
that
doing
it
in
a
separate
document
is
fine.
Even
if
we
publish
that
six
months
later.
E
B
Okay,
thanks
karsten
and
more
more
comments
are
welcome,
but
in
the
interest
of
time
I
propose
we
move,
move
on
to
the
next
slide.
B
So
here's
the
thing
that
we
have
been
working
on
in
in
in
lake
and
we
think
that
this
really
belongs
to
cozy.
The
question
is
yeah
to
what
extent
this
should
be
a
separate
draft,
so
this
is
this:
is
the
use
of
cwts
and
cwt
claim
sets
in
as
authentication
credentials
or
as
credentials
containing
public
keys?
B
So
in
lake
we
have
defined
two
cosy
header
maps
and
the
oh
sorry,
cosy
headers
for
for
cwt,
containing
a
cozy
key
in
a
cnf
claim
and
for
a
cwt
claim
set
containing
a
cozy
key
and
the
the
question
for
cozy
is:
do
we
need
to
specify
some
more
general
use
of
cwts
authentication
credential,
and
that
would
be
the
analog
of
the
draft
idf
cosy
x509
but
use
seeing
zebra
web
tokens
containing
kosekis
instead
of
x509?
B
I
don't
hear
any
opinion
here.
Okay,
so
I
raised
the
topic
and.
C
B
Yeah
I
mean
exactly-
I
mean
this
is
so
so
the
thing
we
we
would
like
to
do
with
zebra
web
tokens
is
to
identify
them
like,
like
x5t
and
x5u,
or
to
be
able
to
retrieve
them
or
to
handle
things
like
chains.
So.
B
So
that's
I
mean
that's
basically
a
question:
how
how
do
we
do
we
need
to
specify
those
headers
and
all
the
considerations
around
how
you
use
them.
B
B
So
the
I
mean
basically
what
what
x509
the
co-cx-59
draft
is
only
specifying
how
you,
how
you
identify
the
chains.
E
I
I
don't
know
if
the
tls,
maybe
sean
remembers,
that
but
the
tls
has
its
own
change
structure.
So
if
you
have
a
certificate
format
which
now
is
cwt
according
to
harness
draft-
and
you
automatically
get
the
chain
in
okay.
E
B
B
A
No,
I
think
if,
unless
someone
else
has
other
topics
to
discuss
the
next
idf
meeting
is
soon
enough,
so
I
don't
have
anything
close.
B
Okay,
good,
then,
then
I'll
take
take
the
time
to
look
at
this.
So
this
is
basically
a
question
for
x509,
which
I
I
think
it's
fine
what's
in
there,
but
I
I'm
a
little
bit
interested
in
in
another,
an
extension,
so
cosi,
x59
distinguished
between
cozy
headers
for
sender
and
recipient
in
the
case
of
tiffy
helmond.
B
B
Certificate
containing
his
public
key,
which
it's
digital
signature,
public
key
or,
if
you
use
put
it
in
the
cosy
recipient
object,
it
will
be
used
to
identify
the
certificate
for
the
recipient
of
the
message.
B
But
in
section
three,
it's
added,
as
you
know,
these
sender
tags,
so
the
headers
are
used
to
specify
and
identify
the
the
senders
of
sender's
key,
and
it
is
pointed
out
specifically
for
statics
that
the
key
agreement,
algorithms.
B
So
from
from
my
point
of
view,
I
mean
this.
It
certainly
makes
sense
that
if
you
have,
if
you're
doing
diffie-hellman,
you
have
two
key
pairs
and
you
might
need
to
identify
both
the
the
sender's
public
key
and
the
recipient
public
key.
So
so
far
so
good.
But
I,
what
wasn't
clear
to
me
is:
why
is
this
limited
to
static
static?
B
So
if
we
compare
the
the
table,
one
at
the
top
right,
which
is
basically
just
the
cosi
headers
for
as
we
are
used
to
with
with
the
this
corresponding
sender
headers,
this
specifically
points
out
the
algorithms
used
with
static
static
and
in
my
view
you
should
be
able
to
use
something
similar
for
ephemeral
static.
So
let's
say
that
you're
saying
you're
sending
an
ephemeral
key
and
you
want
to
point
out.
B
B
B
E
E
D
So,
if
you're,
trying,
if
you're,
trying
to
form
the
keep
the
shared
secret
you
need
in
in
the
static
static
case,
they
might
both
be
certified
right
and
and
in
the
static
ephemeral
case,
only
one
of
them
is
certified.
D
Usually
you
just
send
the
ephemeral
itself
in
one
direction
or
the
other,
and
in
this
case
I
think
the
sender
is
providing
the
ephemeral
and
he's
telling
the
recipient
which
of
his
certified
publix.
He
is
using.
E
I
don't
understand
if
you
can
do
statistic
with
kid
header
parameters.
Why
could
you
not
do
statistic
with
two
x5
t
parameters
or
phrase
differently?
If
you
cannot
do
it
with
to
x5t
without
this
x5t
cylinder?
Why
can
you
do
it
with
the
kid
completely
forgetting
ephemeral
he's
only
talking
about
static,
static.
D
B
D
They
are
adequate
to
identify
the
you
know
in
the
universe
of
all
cozy
keys,
right.