►
From YouTube: COSE WG Interim Meeting, 2020-12-16
Description
COSE WG Interim Meeting, 2020-12-16
A
So
this
is
an
official
itf
meeting,
it's
a
cozy
interim
meeting
and
has
an
official
idea
of
meeting
the
note.
Well
applies.
A
B
Is
russ
I
sent
you
some
slides
for
counter
sign.
A
Yes,
that,
for
now
is
put
under
the
update
of
draft
status.
C
A
Yes,
thanks
for
checking
this,
so
okay,
let's
continue.
If
there
is
no
bashing
that
the
agenda
then.
A
So
already
presented
the
note.
Well
minutes
will
be
taken
at
this
url.
For
now
we
don't
give
an
official
minute
taker.
We
are
looking
for
someone
to
help
us
with
the
action
items.
I
need
volunteers.
B
This
is
russ
I'll
I'll
help
with
the
minutes,
but
somebody
else
used
to
do
it.
While
I'm
talking.
A
Okay,
that
sounds
perfect,
dangerous
and
yeah.
I
think
we'll
be
able
to
handle
the
jabber
with
some
macho
okay.
Yes,
if
you
want
to
see
the
flights
here
is
another
link
at
white
arrows
in
the
data
tracker
and
if
you
haven't
put
your
name
in
the
minutes,
please
add
yourself
to
the
attendees
there.
A
Okay,
so
with
that,
we
can
move
to
the
document
status
for
the
hash,
algorithm
and
rfc
8152.
This
alks
they
are
in
the
rst
editor
queue
waiting
for
the
struct
document.
A
Okay
and
then
for
the
509
document,
I
submitted
a
new
revision
like
one
or
two
days
ago,
and
there
were
a
few
things
that
were
still
raised
as
comments
or
things
that
might
be
considered.
A
If
anyone
has
any
objections,
please
let
us
know
another
point
that
ben
raised
was
that
maybe
there
would
be
something
for.
A
X,
509
and
counter
signature,
there
are
some
overlappings,
maybe
between
them,
and
we
need
to
see
which
of
the
two
documents
would
be
handling
that.
A
So
yes,
this
is
an
action
item
for
me
and
then
the
reference
to
rfc
8152
was
informative
and
that
was
changed
to
normative
because,
as
ben
pointed
out,
it
didn't
feel
correct
to
have
the
document
reference
rfc
8152,
just
as
informative.
A
And
similarly,
as
for
the
counter
signature,
I
think
there
was
a
question
whether
we
want
to
be
able
to
directly
support
cyborg
certificates
in
x
or
what
is
exactly,
maybe
it's
in
the
document
for
cbor
certificates
and
that
we
are
going
to
add
this.
But
we
might
just
want
to
make
sure
the
text
in
the
x
509
draft
doesn't
doesn't
stop
us
from
doing
this.
E
And
this
is
jonathan.
It
was
pointed
out
in
reviews
that
the
previous
version
referenced
the
github
examples
and
that
there
were
no
examples
for
x
509,
so
that
text
was
removed
in
the
latest
version.
But
I
did
submit
a
poll
request
to
the
examples,
repo
with
some
examples
for
x,
509.
A
A
And
logans,
I
think
you
might
also
have
some
points
to
discuss.
I
thought
it
could
be
an
easier
to
discuss
them
now,
but
yes,.
F
Okay,
so
one
way
to
frame
this
might
be
harmonization
with
the
the
really
similar
header
parameters
in
jws,
because
hgws
has
a
nx5t
an
x5
chain
and
an
x5u
doesn't
have
an
x5
bag
and
there's
a
few
things
that
are
different
between
them
or
maybe
not
as
clear
in
the
the
x
509
kozai
x,
509
draft,
as
they
are
as
clear
in
the
jws
draft,
so
one
of
them
is
identification
of
the
end
entity
certificate.
F
I
wrote
an
email
on
that.
The
other
is
the
whether
the
headers
are
protected
or
not,
and
in
my
view,
jws
section.
Six
handles
that
really
well
and
it
seems
like
it
would
be
good
to
have
the
same
thing
in
jose
x509
and
I've
mentioned
this
a
few
times.
F
I
I
don't
know
if
you
want
me
to
file
issues
or
just
emails
or
whatever
what
you
think
is
best,
but
those
are
those
are
two
and
then
maybe
there's
also
some
harmonization
with
on
the
x5u
parameter
in
terms
of
the
way
it's
treated
from
a
security
point
of
view.
I
haven't
looked
at
that
one
as
closely,
but
it
seems
like
they're.
They
are
also
different.
A
Yes,
yes,
it's
possible.
Could
you
file
issues,
for
example,
in
github
yeah?
I
will.
I
will
look
into
that
in
more
details
and
also,
if
you
have
any
suggestions
for
text
for
the
harmonization
that
would
be
really
appreciated.
A
Okay,
okay,
thanks
any
other
comments
about
this
document.
E
E
It
says
that
they
only
must
be
integrity
protected
if
the
information
conveyed
is
utilized
in
a
trust
decision
and
if
it's
not.
If
the
trust
decision
only
uses
the
key,
then
they
need
not
be,
and
so
I'm
not
sure
that's
entirely
clear
of
what
the
decision
should
be
made,
particularly
when,
when
you
take
the
example
of
of
cms,
where
certificates
are
not
protected
by
signatures
or
and
it
and
the
and
the
signatures
on
the
certificates
themselves
protect
additional
parameters.
I
don't
know
if
anyone
else
had
thoughts
about
that.
F
Yeah,
I
have
a
few
thoughts
about
that.
This
is
lawrence
again.
My
understanding
I
mean
I,
I
was
kind
of
thrown
for
this
thrown
for
a
loop
on
this
myself.
F
But
two
things
changed
my
mind
or
I
guess
the
way
I
would
frame
it
is
cms
didn't
address
this.
This
was
a
this
is
kind
of
a
new
attack
or
a
new
sort
of
new
vulnerability,
and
it's
you
know,
ben
in
his
discussion
of
x5u.
F
You
know
kind
of
brought
up
the
the
point
and
then
the
fact
that
jws
addresses
it.
That
was
kind
of
the
two
points
there
and
I
agree
that
they
should
not
always
they
don't
always
have
to
be
in
protective
headers
they,
but
sometimes
they
should
be,
and
my
understanding
is
the
the
the
basic
attack
here
is
that
a
a
ca
issues,
two
certificates
with
the
same
key
but
different
extensions
like
or
usage
things
like
usage
like
extended
keys
or
you
know,
path,
length
constraints.
F
E
Me
so
so
from
what
ben
said
he
he
argued
specifically
on
the
x5u
parameter
to
be
unprotected
headers,
because
of
it
was
that
there
was
no
trust
between
the
accessing
the
url
for
to
to
obtain
the
certificate,
and
in
the
example
you
gave
with
the
certificate
authority
changing
the
certificate
parameters.
E
I
think
that
that
that
that's
a
really
I
don't
know
I
don't
know
about
of
of
a
ca
that
would
would
actually
do
that
without
revoking
the
other
without
the
revoking
the
other
certificate
changing
properties
of
it,
particularly,
it
could
change
like
issue
a
new
expiry
date,
but
changing
key
usage
without
provoking
the
other
one
would,
I
think,
would
be
a
dangerous
operation
for
for
a
ca
to
to
do,
and
but
I'm
also
not
sure
what
like,
like,
particularly
what
the
attack
is
like
the
attack
would
only
be
if,
if
your,
if
they
actually
restricted
the
key
usage
further
in
the
second
issue,
issuance
and
didn't
revoke
the
original
one,
and
so
if
they
that
that
to
me,
it
would
be
a
failure
in
the
in
the
x
509
certificate
management.
F
I
do
think
that
the
expiration
date
is
is
of
similar
consequence
here
as
the
key
use
and
half
length
and
other
other
things
in
the
certificate
and
then
on.
You
know,
ben's
argument.
When
I
read
ben's
argument,
I
thought
that
you
know
it
was
about
this
other
other
fields
in
the
certificate.
F
So
it
seemed
to
me
that
ben's
argument
extended
to
all
forms
of
identification
of
the
end
entity,
not
just
x5u.
F
He
never
followed
up
on
that
to
answer
that,
whether
he
thought
that
was
true
or
not,
so
I
don't
really
know
what
he's
thinking
and
then
and
then,
when
I
read
the
section
six
of
jws,
it
seems
to
line
up
with
that.
So
I
I
agree.
It's
kind
of
an
obscure
thing,
but
you
know
in
a
way,
but
I
think
the
the
lineup
with
jws
is
good.
E
Yeah,
I
I
don't
want
to
take
too
much
longer
with
this
in
the
agenda,
but
if
you
can
propose,
if
you
have
some
text
that
would
clearly
state
when
it
should
be
in
a
protected
header
versus
allowing
it
in
an
unprotected
header,
I'd
be
willing
to
review
that.
A
And
ben
also
joined
so
we'll
be
able
to
ask
him
I'm
wondering
how
much
time
will
we
need
for
the
other
points
and
whether
that
is
something
that
we
can
follow
up
on
the
mailing
list
with,
but
yes,
so
ben
just
a
little
bit
of
context
for
what
we're
discussing
is
the
protected
headers
in
x509
and
yes,
there
was
a
discussion
in
the
mailing
list.
A
B
A
B
Okay,
just
a
little
while
ago,
zero
two
was
posted
next
slide.
B
B
I
I
know
that
michael
richardson
had
previously
said
that
he
found
the
examples
were
necessary
to
understand
exactly
how
to
implement.
So
it's
good
that
we
have
more.
I
notice
he's
not
here,
but
I
think
with
that
change.
The
documents
now
ready
for
last
call
within
the
working
group.
Hopefully
somebody
can
check
the
examples
as
part
of
that
last
call.
E
B
Okay
chairs,
I
hope
we're
ready
for
last
call
not
hearing
anybody.
A
A
A
D
Yeah
so
we
emerged
the
tpr's
and
then
I
think
goran
had
some
concerns
with
that
that
you
may
have
to
back
those
out.
They
were
around
around
the
certificate
stuff
with
certificate
options.
There.
C
Here
I
I
need
a
reminder
here.
I
don't
know
what
what
I
promise
to
do
or
what
I
should
do.
D
No
no,
this
is
you.
You
had
mentioned
at
some
point.
Some
concern
with
the
latest
test
around
excuse
me
text
for
in
the
charter
around
the
certificate.
C
C
Gone
beyond
the
charter-
and
I
wanted
to
have
that
since
there
was
an
agreement
in
the
in
the
working
group
around
what
what
the
seaboard
certificate
draft
should
be
about.
I
wanted
that
reflected
in
the
charter.
That
was
basically
my
input.
G
G
A
D
I
mean
what
what
the
chairs
can
do
is
we
can.
We
can
push
this
in
its
the
only
other
pull
request.
That's
in
there
right
now
is
to
delete
all
the
essentially
all
the
stricken
out
text.
D
A
A
G
G
Yeah
next
slide
again
so
just
very
quickly:
summarizing
changes
from
zero
three
to
zero.
Five.
I've
not
received
any
comments
on
the
list,
but
so
basically
compressed
and
then
removed
in
the
whole
document.
G
We
will
update
the
file
name
at
a
later
point,
probably
when
it's
adopted
and
we
have
to
change
the
file
name
anyway.
G
We
added
a
reference
to
ieee
dev
id
and
made
optimizations
for
dev
id,
and
it
was
a
comment.
It
was
not
really
un
clear
how
this
mapped
to
version
three,
so
we
have
added
version
three
in
a
lot
of
places
to
make
it
very
clear
that
this
is
for
version
three
and
version
three
is
encoded
in
the
seaboard
certificate
type
removed,
some
optimizations
that
was
not
necessary,
changed
serial
number
to
unwrapped,
simple,
big
num
change,
time
to
see
board
epoch
time
added
the
special
encoding
for
no
expiration
date,
which
is
basically
the
maximum
time
positive.
G
A
G
Added
organization,
identifier,
change
that
utf
strings,
have
a
positive
signs
in
the
native,
enable
encoding
of
email
address,
fix
the
ambiguity
with
hex
encoding,
pointed
out
by
rus
added
support
for
other
name
and
also
added
the
optimization
for
hardware
module
name,
that's
a
type
of
other
name
which
is
used
in
their
id.
G
G
These
are
basically
used
in
all
certificates
on
the
web
added
and
also
yeah
serial
distribution.
Point
and
authority
in
for
access.
Same
theory
is
also
used.
G
G
G
G
You
well
used
x,
509
profiles,
the
ca
browser
forum,
baseline
requirements,
that's
basically
used
by
all
browsers
and
therefore
all
certificates
on
the
web,
and
also
to
see
an
essay
x509
profile
which
has
been
published
as
an
rfc
recently
got
several
requests
to
add,
see
an
essay
cypher
suits
to
ad
hoc.
This
might
so.
This
might
be
useful
here.
G
G
Where
the
I
don't
know
the
quick
terms,
but
the
server
hello
can
basically
be
only
three
times
larger
than
the
client
hello.
What
the
client
sent
so
unless
you
can
fit
in
that
restrictions,
you
will
add
another
round
round
trip
this
I've
seen
being
discussed
by
cloudflare
in
a
blog
where
they
show
that
tls
certificate
compression
is
important
here
and
improves
performance.
I
think
seaboard
certificate
could
potentially
also
help
here,
but
we
would
need
concrete
data
on
that.
In
that
case,
then,
the
ad
we
would
like
to
add
an
example.
G
Encoding
of
the
dev
id
certificate
would
be
very
good
good
if
somebody
has
such
a
certificate,
so
we
can
make
it
more
relevant
instead
of
trying
to
create
one
just
from
the
devide
specification
that
could
lead
to,
it
would
be
a
probably
a
corrective
id,
but
maybe
not
how
they
are
used
in
practice,
and
I
don't
think
I
think
michael
richards
on
us.
Maybe
he
could
help.
I
don't
think
he's
on
this
call
today.
H
I
didn't
quite
understand
the
question
because
I
was
actually
trying
to
send
a
message
to
the
group.
G
G
H
Can
compress
it
and
uncompress
it,
but
I
was
actually
then
I
had
a
different
thought,
which
was
probably
there's
some
advantage
in
dtls
to
compressing
the
certificate,
even
if
the
rest
of
the
dtls
is
is
big
because
a
certificate
is
could
be
especially
if
it's
a
chain
could
be
more
than
a
kilobyte
in
size,
and
so
I
was
thinking
how
could
we
put
test
this
whole
thing
in
practice
with
dtls,
and
so
I
was
actually
wondering
to
myself,
and
maybe
it
speaks
to
the
previous
point
as
well.
G
That's
great
so
then
we
then
I
expect
some
example
dev
id
certificate
from
you.
If
you
provide
a
I
could.
I
can
compress
it
and
add
it
to
the
to
the
draft
and
try.
G
Yeah
sounds
great
no
hurry,
then
we
are
planning
to
the
draft
already
have
an
example:
https
rsa
certificate,
the
ones
from
toolstorebydev.org
we
plan
to
add
one
ecdsa
certificate
as
well,
and
then
coming
back
to
basically
what
michael
just
said,
we
would
like
to
have
more
more
realistic
data
on
what
compression
you
could
do
in
tls
and
as
we
have
found
all
our
understand
is
that
broccoli
is
what
is
used
in
practice.
So
we
are
planning
to
change
from
said
lib
to
broccoli.
G
G
G
G
So
that's
the
plan
for
zero.
Six
has
been
request
for
more
deployment
guidance
for
it.
What
you
just
choose
and
so
on
this
is
more
high
level
point.
It
should
probably
be
added
at
some
point,
but
I
don't
have
a
clear
view
of
exactly
how
this
deployment
guidance
should
look
like
could
also
be
in
other
drafts
than
this.
G
Then
we
tested
the
encoding
on
on
the
set
of
https
certificates
on
the
web,
and
we
found
out
that
there's
quite
a
lot
of
attributes
that
we
had
not
registered.
For
example,
street
address
postal
code,
business
category,
jurisdiction
of
incorporation,
country,
name,
etc.
There's
we
only
looked
after
a
quite
small
set
of
certificates
and
already
found
four,
then
street
address
and
postal
code
are
are
included
in
this
browser
forum
baseline
requirements,
so
we
made
registrations
for
them
for
all
other
attributes
we
made
so
that
you
can
use
the
oid
byte
string
encoding.
G
Then
last
slide
which
no,
it
was
not
the
last
night.
So
it
also
received
quite
a
lot
of
comments
about
the
the
iana
tables,
especially
the
algorithms,
that
it
was
a
bit
unclear
which
parameters
was
supported
and
not
and
also
expect
encoding,
and
that
the
identifiers
were
a
bit
unclear
as
we
completely
rebuilt
them.
We
removed
identifiers,
we
gave
them
more
descriptive
names,
and
then
we
skipped
the
old
format
and
now
there's
a
one
mapping
between
the
c
board
value
and
the
their
encoding
of
the
whole
algorithm
identifier.
G
G
It
allows
registration
of
algorithms
with
any
form
of
parameters,
and
we
now
added
a
we
all
previously
supported
rsa
with
null,
which
may
or
may
not
be
a
parameter
and
named
curved.
But
now
we
can
also
support
rsa
psf,
which
is
at
least
mentioned
in
both
the
browser
baseline
requirements
and
see
an
essay.
Even
if
I
haven't
seen
any
use
on
the
web.
G
So
this
was
discussed
on
the
list
raised
by
lawrence
about
how
is
it
easy
or
hard
is,
is
to
implement
the
current
draft
or
the
siebel
sequences
and
cdl
with
current
keyboard,
encoders
decoders
and
the
question
is:
should
we
make
any
changes
to
make
it
easy
to
use,
and
the
problem
correct
me
if
I'm
wrong
lawrence
is
that
it's
hard
to
access
a
subpart
of
the
encoded
c
board
to
verify
the
to
put
as
the
input
to
the
signature
to
verify
that,
and
one
of
the
suggestion
was
to
wrap
the
to
be
signed
structure
in
a
byte
string
that
makes
it
easier
to
parse
out.
G
H
G
That
himself,
but
yeah.
I
So,
basically,
when
we
did
people,
we,
we
focused
on
having
a
single
data
item
and-
and
so
all
the
the
initial
cbo
apis
focused
on
that.
But
then
we
found
out
about
the
streaming
and
and
zebra
sequences,
and
all
that
and
and
most
or
many
zip
implementations
I
haven't
done.
The
scientific
study
of
that
actually
grew.
I
Some
some
apis
to
to
actually
work
with
sequences
and
working
with
with
sequences
doesn't
just
mean
that
you
have
sequences
of
encoded
data
items,
but
it
also
means
that
you
can
have
a
situation
where
you
have
one
or
even
maybe
more.
In
this
case
it
would
be
10,
encoded
c
bar
data
items
and
then
something
else
following,
and
this
would
work
with
a
specific
situation
we
have
here.
So
I
gave
some
examples
for
for
decoder,
apis
of
decoders
that
I
have
written.
I
But
of
course
I
I
couldn't
do
this
work
for
all
65
implementations
that
are
on
cbo
that
I
o.
So
we
probably
need
to
do
a
little
bit
more
surveying
there.
But
right
now,
I'm
I'm
pretty
optimistic
that
we
wouldn't
create
ourselves
a
big
deployment
problem.
By
going
with
the
the
way
things
are
done
in
the
show
five.
F
This
is
lawrence.
What
one
other
comment
here
is
that
if
you
did
the
byte
string
wrapping,
you
would
guarantee
that
just
about
any
c
board
decoder
would
be
able
to
to
you'd
be
able
to
work
with
just
about
any
c
board.
Decoder
would
be
more
or
less
a
guarantee
where
you
know
as
it
is.
F
You
know
I
haven't
done
a
scientific
study
either,
but
you
know,
as
it
is,
there's
definitely
some
seaboard
decoders
that
would
have
to
be
modified
or
couldn't
be
used.
G
Do
we
do
we
think
these
seaboards
libraries
will
stay
like
they
are,
or
will
they
in
the
future,
support
sybil's
sequences,
which
was
not
so
long
ago
published
as
an
rfc
kersten
in
a
similar
question,
custom
commented
before
this
was
better
to
change
the
tool
than
the
specification.
I
Trade-Off-
and
there
is
no
correct
answer
here-
so
we
essentially
just
have
to
see-
is
the
deployment
headache
that
lawrence
has
identified
as
not
entirely
trivial.
Is
that
worth
saving
two
or
three
bytes?
And
then
that's
really
a
decision
that
I
don't
have
a
strong
position
on.
All
I
wanted
to
say
is
the
the
headache.
Is
there,
but
it's
probably
not
a
splitting
headache.
E
G
G
F
So
one
other
comment
on
my
own
seaboard
decoder
has
a
couple
of
extra
features
that
help
it
deal
with
by
string
wrapping,
particularly
for
cos
a
so
I
I
it's
one
of
the
reasons
I
like.
That
is
that
you
know
we
already
have
this
convention
of
doing
it
for
cos
a
and,
and
maybe
some
decoders
have
a
way
of
dealing
with
cose
in
inefficient.
F
A
Okay,
yes,
for
the
last
topic,
I
think
that
sounds
good.
Let's
take
some
more
time
to
think
about
it
and
discuss
it
again.
But
yes,
for
now,
it's
not
clear
which
way
is
better.
A
I
So
procedural
question:
what
is
the
point
in
time
when
we
actually
want
to
adopt
this.