►
From YouTube: IETF109-COSE-20201116-0730
Description
COSE meeting session at IETF109
2020/11/16 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
So
this
is
an
official
idea
meeting
it's
the
cozy
meeting.
Has
you
know
it's
virtual
meeting
and
that's
using
the
bangkok
time
zone
and.
A
A
A
So
the
document
status,
we
have
a
few
documents
that
are
waiting
for
edits,
otherwise
they
are
in
iesg
evaluation.
Those
are,
namely
the
81
52
bis
struck
document
and
the
x
509
document
on
my
site
for
the
x509
document.
There
are
a
few
more
things
I
need
to
to
look
at
and
then
I'll
be
able
to
publish
a
new
revision
of
the
document.
A
And
we
have
two
documents
that
are
waiting
that
has
missing
preferences:
those
are
the
51
82
51
8150
b
sucks
and
the
hashtags
documents,
and
we
have
the
counter
sign
document
that
we
are
going
to
that
is
going
to
be
presented
separately.
A
A
A
Okay,
so
yes,
I
there
is
a
pull
request
that
should
be
making
some
improvements
on
the
language
of
the
charter,
but
are
there
any
points
that
you
would
like
to
discuss
now
about
the
proposed
new
charter?
A
B
B
Okay
next
slide,
please.
B
So
the
the
first
thing
is
this
is
jim
shad's
work.
He
deserves
all
the
credit
for
it
and
I
agreed
to
serve
as
the
document
editor
since
jim
passed.
B
B
At
this
point,
the
body
of
the
document
is
done,
but
the
examples
jim
envisioned
five,
two
of
which
he
did
and
three
of
which
are
just
placeholders
next
slide.
B
Please
it's
the
code
that
jim
used
to
make
those
examples
is
available
in
github.
B
B
It's
interesting
that
michael
was
also
the
one
who
said
without
working
through
one
of
the
examples
he
didn't
understand
the
body
of
the
document.
So
I
take
michael's
comment
to
mean
that
the
two
examples
that
are
there
are
enough
to
get
that
understanding.
B
A
B
So
if,
if
that's
the
direction
or
if
no
one
is
willing
to
help
make
make
those,
I
will
be
glad
to
remove
those
three
empty
sections
and
and
post
it
I'll
do
that
promptly.
C
C
C
So
we
have
done
quite,
we
had
done
quite
a
lot
and
made
a
zero
two
version
incorporating
some
of
the
comments,
and
then
I
had
more
time
and
made
it
zero
three
version
incorporating
trying
to
address
basically
all
the
comments
that
was
receivable
during
the
summer
from
hank
and
russ
and
hillary,
and
also
the
last
weeks
from
or
a
month
ago,
or
something
from
jim
can
move
on.
This
is
quite
a
lot
of
slide.
Trying
to
describe
the
whole
quite
a
lot.
We
don't
have
time
to
discuss.
C
C
So
I
think
first
is
quite
early:
it's
not
adopted
it's
not
even
in
the
shorter
yet,
so
I
think
to
be
able
to
decide
on
to
discuss
detailed
encoding.
We
need
first
what
the
scope
is
and
the
periscope
the
scope
of
the
authors.
How
this
began
was
to
create
a
seaboard
encoding
of
a
very
small
or
not
very
small,
but
a
subset
of
rfc
795.
C
Then
it
grew
to
the
whole
of
rc
7925,
and
then
people
started
wanting
I
triple
e
and
generalized
time
and
so
on.
So
this
scope
in
number.
What
should
be
encoded
has
grown,
and
so
at
this
point
we
believe
that
the
best
way
forward
is
to
create
a
seabor
encoding
of
a
quite
large
subset
of
five
zero,
eight
c
five,
two
eight
zero.
C
Basically,
what
is
in
active
use,
at
least
among
for
the
use
cases
that
would
have
any
relation
to
cosi
and
what
we
have
done
the
last
last
month
is
to
try
to
make
sure
that
we
can
do
this
while
still
achieving
extremely
high
compression
or
encoding
for
very
constrained
certificates,
for
example
7925,
and
we
believe,
that's
possible.
So
we
don't
think
these
contradicted
each
other.
We
can
support
very
much
of
five
to
eighty
and
still
achieve
138
140
bytes
compression
of
very
constrained
ot
certificates.
C
C
I
don't
think
that
has
really
been
discussed,
but
I
think
in
the
proposal
is
to
only
support
their
encoded
circuits.
As
you
can
see
in
this
list,
there's
a
lot
of
other
encodings.
C
C
The
suggestion
is
to
differentiate
encoding
in
the
specification
from
profiling.
Profiling
could
be
done
in
other
documents
like
seven
nine
to
five,
but
I
think
we
probably
want
some
section
or
appendix
in
the
document
documenting
how
how
you
achieve
very
small
sizes,
which
might
refer
also
might
refer
to
other
drops.
C
C
Changes
so
there's
two
updates.
One
was
submitted
two
weeks
ago
and
the
zero
three
was
submitted
this
morning.
The
changes
has
been
communicated
in
the
past
weeks,
so
the
encoding
of
issue
and
subject
is
completely
rewritten,
as
suggested
by
people
on
the
list.
In
this
during
summer,
they
can
now
encode,
most
rfc
5280
subject
and
issues
they
only
currently
only
printable
string
and
utf-8
is
supported,
and
these
are
the
thing
rfc
5280
says
that
it
says
that
you
must
use
this
for
new
certificates.
C
C
02203
is
added
generalized
time,
as
suggested
by
jim,
to
support
dates
between
2050.
This
is
one
thing
that
moves
this
draft
to
support
more
than
seven
nine
to
five,
then
the
tls
registry.
It
was
previously
suggested
to
do
this
as
a
tls
compression
hillary
suggested
that
this
is
more
a
type.
So
we
have
updated
this
document
to
do
that.
C
This
should
be
coordinated
with
the
tls
working
group
in
the
future.
Add
the
support
for
a
lot
more
algorithms.
C
Tried
to
reduce
the
number
of
ins
hank
commented
that
he
did
not
like
the
large
number
of
negative,
but
I
think
they
are
very
efficient
for
the
encoding,
so
they
are
not
gone,
but
they
are
fewer.
Then
the
title
is
updated.
Based
on
a
comment
from
jim
and
kirsten
just
commented
on
the
list
that
we
should
change
the
file
name
also.
C
C
Then
abstract
and
intro
was
updated
to
sorry
it's
up
to
date
with
the
rest
of
the
document
added
text
on
what
is
not
supported
in
five
to
eighty
added
support
for
raw
relative
yds
for
algorithms
and
extensions
you
can
encode
this
as
a
daring
code
string
can
discuss
whether
that
should
be
done
or
not.
It's
added
now
to
show
that
it's
possible.
C
More
info
than
the
cdl
is
updated
to
follow
the
recommendations
in
rfc
8742
and
that's
an
array
and
states
that
it's
a
separate
sequence
can
be.
Has
us
that?
Maybe
it's
better
to
add
this
to
to
array
anyway,
if
that's
one
byte
and
might
have
benefits
in
understanding
and
maybe
to
use
cdl
courses,
I
think
138
or
139.
C
C
B
I'm
just
a
little
bit
confused
why
you
need
relativoid,
nothing
in
5280
uses
a
relativoid.
Where
do
you
see
it
coming
in.
C
It
was
in
for
to
support
extensions
when
I
post
a
lot
of
certificates.
I
saw
that
it
pops
up
a
lot
of
extensions
and,
for
example,
u.s
government.
Also
there
is
a
lot
of
private
extensions
that
probably
nobody
else
use.
So
this
my
understanding
of
a
relative
oil
is
that
you
don't
have
you
just
skip
the
zero
six
and
the
size
and
it's
the
rest
or
have
I
misunderstood
relative
oids,
so
relativoid
is
an.
B
Asn-1
type
of
its
own,
okay
and-
and
you
have
to
know
the
base
that
you're
adding
the
transmitted
parts,
basically
there's
an
assumed
prefix,
you
set,
you
transmit
the
suffix.
If
you
don't
know
the
prefix,
you
can't
create
it.
C
B
The
rest
out
fro
without
that
yep,
but.
C
A
C
A
C
C
No,
let's
next
slide
on
so
more
low
level.
Discussion
about
the
details.
C
I
think
here
is
nothing
new.
This
is
just
a
summary
version
is
to
be
zero.
Three
is
your
unique
id
and
subject
unique
id
is
not
supported
and
draft
adds
a
zebra
certificate
type
that
currently
the
difference
between
a
compressed
and
the
natively
signed
certificate,
and,
of
course,
it
could
be
used
for
other
things
in
the
future.
C
C
C
D
Yeah,
I
even
checked
the
city,
but
but
what
I
wanted
to
to
avoid
is
that
we
have
remnants
of
weird
der
sein
bit
handling,
which
are
always
a
bad
thing
when
you
have
hashes
or
public
keys
and
things
like
that,
because
they
might
happen
to
have
their
topmost
bit
set.
And
then
you
run
into
the
dr
signed
integer
trap,
and
I
would
like
to
keep
us
free
of
that
trap.
C
C
C
C
C
C
Some
other
values
on
the
octet,
so
what
is
added
if
zero
four
is
the
value
for
uncompressed
in
in
in
in
the
their
encoded
certificate,
and
two
and
three
are
used
for
compressed.
C
So
this
in
the
seaboard
encoding,
we
use
two
and
three
now
for
something
that
was
uncompressed
in
the
certificate
and
minus
two
and
three
four.
If
it
was
already
compressed
in
the
certificate,
then
signature
algorithm,
this
duplicate
signature
is
removed.
C
Then
signature
algoriths,
it's
in
general.
These
are
in
the
city
bits.
This
is
an
oid
plus
a
parameter
which
is
of
type
annie.
C
Many
or
most
algorithmic
parameters,
some
exceptions
are
or
is
the
encryption
public
keys
and
signatures.
Pkcs
1.5
they
have
parameters
equals
null.
The
draft
now
states
that
you
just
treat
them
as
they
are
not
there,
and
then
you
have
to
put
back
the
null
of
used
for
the
pss
algorithms
and
ecc
public
keys.
They
do
have
parameters,
I
don't
know
how
well
used
pss
or
it's
some
of
the
pss.
The
pss
with
short,
two
is
using
parameters.
It
says
which
short
tree
is
not
ecc.
C
So
the
suggestion
in
this
in
the
draft
is
to
not
support
pss
with
short
two
and
only
support
ecc
public
keys
with
named
curves
and
then
encode
the
name
code
curve
in
the
integer
also
added
a
relative,
or
it's
not
a
relative
way-
support
for
a
raw
or
id.
So
you
can
support
keys
public
key
size
that
have
not
been
registered.
C
And
here
is
so
in
the
last
versions
we
made
tables
with
supported
algorithms
and
basically
looked
at
all
the
algorithms,
without
parameters
that
have
that
are,
could
potentially
be
used
and
also
like
future
things
like
hash
based
signatures
that
have
registrations,
but
I
don't
know
if
they're
in
use
in
practice
should
also
probably
differentiate
between
one
and
two
byte
identifiers,
so
that
things
that
are
used
for
constrained
iot
and
are
actually
used
get
one
byte
and
the
rest
get
two
byte
identifiers
and
two
five,
five
and
by
stress
coordinate,
should
probably
be
added
in
the
future
and
as
a
comment
from
carson
this
summer,
one
is
needed
in
root
certificates,
which
is
self-signed,
so
the
signature
doesn't
really
matter
if
it's
weak
there
yeah
are
there
any
comments
which
algorithms
to
support
is
this?
C
Is
the
assumptions
made
here
sound?
Do
we
need
to
support
any
more
algorithms
with
with
parameters?
I
think
that
could
be
done
by
just
adding
that
you
identify
it
with
a
integer
or
an
array.
C
Do
we
need
to
support,
I
think,
pss
with
short,
two
and
elliptic
curve
with
arbitrary
coordinates?
I
think
these
are
the
one
and
do
we
see
any
future
algorithms
having
parameter?
The
current
trend
seems
to
be
in
peaks
to
not
use
any
parameters
and
encode
everything
in
the.
C
C
Yeah,
if
for
this
draft,
I
have
added
that
so
there
are
for
these
new.
These
are
new
registers
for
the
seaboard
certificate
created
by
the
seaboard
certificate,
draw
of
them,
for
I
think
the
current.
What
the
suggestion
now
is
that
one
might
require
itf
action,
I
think
and
or
standard
action
or-
and
you
might
require
just
expert.
C
C
C
C
C
The
relative
distinguished
name
is
itself
encoded
as
an
array,
and
this
was
based
on
a
comment
on
that.
We
should
not
use
use
map
as
the
theoretically.
The
order
of
the
map
is
it's
unordered,
so
we
change
this
also
to
an
array,
and
if
the
array
only
contains
one
attribute,
it's
encoded
as
a
text
string
now
it
only
con
contains
a
utf
string,
encoded
common
name.
It's
the
array.
C
C
C
I
just
got
more
confused
seems
to
be
ff
f
e
or
ffff
in
the
middle.
Also,
both
wikipedia
and
I'll
typically
says
that
the
eui
64
encoding
from
a
mac
address
is
deprecated,
so
maybe
we
should
not
encourage
that
I.e.
We
should
not
have
any
special
handling
of
mac
address
and
also
a
related
issue
is
that
mac
address
is
today
very
much
in
some
cases,
some
environments
randomized.
C
So
basically
it's
not
suitable
for
having
a
certificate,
but
maybe
it's
because
of
that
this
practice
has
been
deprecated.
I
think
there's
people
in
here
that
knows
and
carsten
is
in
queue.
D
They
probably
should
have
some
some
determinate
algorithm
for
that,
but
I
don't
know
so.
Let's
check
that
and
of
course,
in
general,
whether
mac
addresses
are
a
very
useful
subjects.
We
will
have
to
decide
this
from
the
corpus
that
there
is
no
value
judgment
here.
It's
just
the
question:
do
people
use
that
or
do
they
not
use
that
and
if
they
use
we
should
support
it,
and
I
don't
think
we
have
privacy
considerations
here,
because
if
they
already
are
using
mac
addresses,
then
they
already
have
made
the
decision
not
to
be
very
privacy.
C
Aware
good,
a
very
good
comment:
I
have
not
thought
about
the
lower
upper
case.
I
guess
that
goes
back
to
if
there
is
any
format
for
how
you
encode
a
ui
64
in
a
certificate.
I.
D
Would
like
to
answer
fraser's
question
in
the
chat:
does
it
make
sense
to
have
these
special
cases?
Really?
The
question
is
who's
going
to
do
these
conversions,
I
mean
the
whole
point
is
that
the
constraint
device
never
sees
sn1,
so
the
the
conversion
is
done
on
a
less
constrained
device
and
there
we
should
have
the
the
power
to
add
a
couple
of
lines
of
code
to
do
such
a
special
case.
So
I'm
I'm
generally
in
in
favor
of
doing
encodings
of
really
expensive.
D
Text-Based
encodings,
like
like
this
three
bytes
per
byte
hex
encoding
of
mac,
addresses
that,
since
mac
addresses
already
are
not
exactly
small,
that's
probably
worth
it
if
they
are
actually
used
and
that's
something
that
I
don't
know.
Yeah.
C
C
C
For
the
explanation,
any
more
comments
on
this,
I
think
this
is
something
we
definitely
need
more
input
on
from
people
at
new
eui,
64
and
practices
in
this.
C
Field
maybe
move
on.
C
C
C
Something
we
identify
was
the
printable
string.
Only
constrained
contains
6.2
bits
of
the
information
per
character.
It
could
be
compressed,
but
I
don't
know
if
that's
a
good
id
then,
for
example
in
tls
you
could.
If
this
is
a
certificate
type,
you
could
use
compression
on
top
of
this
and
then
compressing
each
string
in
this
in
some
way
would
probably
increase
the
total
size
and
also
it
makes
it
much
harder.
Then
you
cannot
read
the
text
strings
in
in,
for
example,
cbr.me
or
any
c
board
encoder
easily.
C
C
C
So
validity
was
a
comment
from
jim
to
add
generalized
time
as
well.
We
have
done
that
in
there
zero
three,
both
you
tc
time
and
general's
time.
The
proposal
is
to
encode
them
using
a
horner's
method
with
different
bases.
As
you
can
see,
the
formula
here
on
the
slide
and
uts
utc
time
and
generalized
time
can
be
encoded.
C
And
the
coding
can
quite
easily
be
done
by
modeling
and
subtraction
operations
also
comment
from
jim.
Why
we
don't
use
you
this
unix
time,
and
there
is,
I
think
that
can
be
discussed.
There's
some
some
disadvantages.
One
is
that
unix
time
cannot
support
leap
seconds,
which
is
a
part
of
x
of
rfc
5280.
C
Also,
when
implementing
I,
my
feeling
is
that
there
is
unix
time
is
not
back
to
and
from
unix
time
is
not
really
well
supported
on
all
systems
or
platforms,
but
maybe
I'm
right
wrong,
and
also
at
least
on
ins,
c
c,
plus
plus
one
of
the.
I
don't
remember
if
it
was
two
unix
timer
from
you
next
time
made
use
of
local
time
by
default.
So
if
you
want
unix,
if
you
want
utc
time,
you
need
to
add
your
time
soon.
C
But
otherwise
the
unix
time
and
this
encoding
would
create
would
use
exactly
as
many
bytes
boot
representation.
You
can
compare
directly
with
this
formula.
You
cannot
calculate
differences
in
time,
time
periods
from
the
compressed
values
that
you
can
do
in
unix
time
as
it
just
counting
the
number
of.
C
B
You
misunderstood
my
comment.
The
the
time
is
always
in
utc,
okay,
sorry
yeah.
The
format
is
before.
C
B
And
I
don't
think
there
is
only
carries
second,
so
I
don't
know
I
can't
think
of
in
a
certificate
where
a
leap
second.
B
B
B
A
C
You
so
extensions
ex,
so
this
the
previous
suggestion
had
it
was
very
limited.
It
was
meant
to
be
very
limited,
so
this
has
been
completely
rewritten
and
now
we
can
encode,
I
think,
basically,
any
certificates
on
the
web.
But
of
course,
of
course,
unless
a
lot
of
the
extensions,
more
non-iot
extensions
are
than
just
the
integer,
followed
by
their
encoded,
byte
string,
which
is
not
very
nice,
can
go
to
the
next
slide.
C
So
here
is
the
current
ayana
registrations.
We
have
one
table
for
extensions,
one
for
extended
key
usage
and
one
for
subject:
alt
names.
I
think
these
are
not
all
the
subject.
Alternatives
was
just
the
ones
I
had
time
to
specify
right
now.
I
think
we
need
a
lot
of
input
on
which
ex
what
should
be,
what
should
the
initial
registration
for
these
tables
be?
Assuming
we
assume
we
agree
on
this
encoding.
C
C
C
I
thought
it
was
easier
to
remove
if
you
don't
need
change
the
tls
to
its
certificate
type,
instead
gesture
to
coordinate
this
with
the
tls
working
group,
and
this
maybe
when
the
cosi
has
adopted,
adopted
work
on
that
on
this.
If
cozy
do
that
next
slide,.
C
And
here
is
an
example,
encoding
of
the
tools
itf
certificate
and
you
this.
This
was
original.
Their
encoding
is
1650
bytes.
The
cbor
encoding
is
1374,
so
you
save
270
bytes,
but
that
is
only
16
compared
to
the
56
percent
in
the
very
constrained
certificate
and,
as
you
can
see,
the
gr.
What
is
marked
with
green
here
is
the
extensions
in
7925
which
we
have
defined
cbor
encoding
for
the
values
the
other
areas
take,
that
their
encoding
are
taken
just
from
the
certificate,
and
I
think
this
is
it
should
be
discussed,
which
extension
should
be.
C
We
should
hand
write
encodings
for
or
if
can
we
come
up
with
a
general
c-bor
encoding
that
just
takes
the
sequences
and
sets
of
asn
1
and
map
them
to
to
see
more,
probably
for
the
for
the
rfc
7925.
You
probably
want
some
special
handling,
but
for
the
other
you,
you
would
probably
be
best
with
a
general
thing
if
it
can
be
constructed.
C
We
would
very
much
want
more
reviews,
people
trying
to
implement
this.
I
have
implemented
a
dairy
inc
there
to
seabor,
which
supports
large
part
of
this.
I
will
the
plan
is
to
try
to
release
that
as
open
source
in
the
coming
months.
I
will
write
to
the
list
when
that
happens
and,
of
course,
more
discussion
on
the
list.