►
From YouTube: IETF104-COSE-20190326-0900
Description
COSE meeting session at IETF104
2019/03/26 0900
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
So
the
blue
sheets
should
be
making
their
way
around
important
that
this
is
an
official
ITF
meeting.
So
please
note
well
IPR
and
kept
right
and
code
of
conduct
items
probably
already
seen
this
at
least
once
this
week
so
far,
but
if
not,
please
do
take
time
to
read
this.
If
you're
not
familiar
reminder
of
where
we
are
having
minutes,
do
we
have
anybody
willing
to
jabber
scribe.
A
B
A
E
E
So
the
first
item
is
when
I
was
actually
getting
my
counter
signature
code
running
I
found
that
it
was
difficult
to
actually
tell
simply
if
something
was
a
single
counter
signature
or
there
were
more
than
one,
because
in
both
cases
the
first
stated.
The
first
type
tag
that
you
looked
at
was
a
an
array,
so
you
actually
had
to
look
one
more
level
down
to
figure
out
whether
there
was
a
single
version,
a
single
counter,
signature
or
two.
E
So
the
thing
I'm
basically
proposing
is
that
we
remove
the
first
option
in
terms
of
what's
there
from
the
list.
We've
gotten
one
person
who
said
yes,
I-
think
that's
right
and
I,
don't
believe
that
there's
any
countersignature
code
out
there,
that
is
actually
standing
countersink
rushers
around
and
the
wild
which
is
going
to
be
affected
by
this.
E
E
Okay
next
item:
when
we
compute
all
of
our
authentications
structures,
we've
got
a
context
string
into
everything
and
right
now
the
context
string
that
we
use
for
the
countersignature
one
structure
is
countersignature
zero
and
it's
that
way
for
historic
reasons.
Specifically,
I
renamed
the
structure
and
I
forgot
to
rename
the
strength.
E
E
It
is,
however,
in
an
absolute
breaking
change
for
any
countersignature
or
zeros
messages
which
exists
out
in
the
real
world.
At
this
point
in
time,
the
only
implementations
I
know
of
eff,
countersignature
zero
are
mine,
and
as
long
as
we
managed
to
get
this
changed
before
the
kontiki
version,
no,
the
californian
version
is
actually
published
brocade
once
the
californium
version
is
published.
F
Custom
woman's
a
little
bit
like
looking
at
an
object
of
art
that
has
a
change
somewhere
in
it
and
I.
Think
I'll
just
differ
in
how
they
look
at
objects
of
art,
with
that
property,
I
think
a
little
bit
of
patina
increases
the
value
and
I
really
wouldn't
want
to
send
the
signal
we
are
making
gratuitous
changes
here.
I
mean
it's
from
a
technical
point
of
view.
It's
gratuitous,
it
could
have
been
fubar
and
would
be
doing
well,
and
the
only
thing
I
see
is
that
editorially.
F
G
E
G
I
Mike
Jones
Microsoft,
when
we
violate
the
principle
of
least
surprise
it's
the
developers,
the
implementers
you
have
to
build
this
stuff.
That
gets
surprised
and
may
in
fact
do
wrong
things
because
they're
making
assumptions
which
might
have
been
true
but
aren't
so
I
agree
with
the
previous
speaker.
We
should
fix
this
while
the
fixings
good.
J
Brendan
Morin
arm,
while
we
may
only
know
of
one
implementation
that
exists,
that
doesn't
mean
there
aren't
more
out
there,
and
this
potentially
could
cause
breaking
changes
within
infrastructure
of
people
who
haven't
published
publicly.
I
think
this
is
a
really
dangerous
change
and
without
significant
input
from
the
community,
I
think
it's
quite
concerning.
A
J
F
Last
moment
also,
you
actually
have
to
answer
to
ask
the
question
at
the
time
this
document
is
published,
because
there
is
this
period
of
time
when
people
still
only
find
it
1
5
2
in
the
ROC
set
and
they're.
Just
aren't
aware
that
this
is
happening
here
and
we
don't
have
the
perfect
marketing
machine
that
that
pushes
this
out
so.
K
E
My
advice,
yeah
I'm,
scared
of
making
a
change
so
I
mean
personally
other
than
then
it's
a
little
bit
of
a
jump
for
people
who
actually
are
doing.
The
implementations
I
think
that,
given
that
we
may
also
immediately
point
to
test
vectors
that
are
out
there
and
are
and
are
correct
right
now
not
doing
it
is
probably
the
correct
answer.
B
A
A
A
A
A
F
L
A
J
E
We
probably
should
move
the
counter
signatures.
There
are
stuff
out
of
the
appendix
and
put
it
in
with
the
same
countersignature
stuff.
The
question
that
I
have
is:
should
we
make
counter
signatures,
be
a
subsection
of
signing
which
is
what
they
currently
are,
or
should
they
be
a
top-level
section
of
the
of
their
own
equivalent
to
doing
signing
and
encryption
and
acting
because
it's
kind
of
a
the
zone
thing
kind
of
not
is,
and
it's
basically
for
people
who
read
the
document?
B
B
E
Group,
a
scored
document
which
is
in
the
core
group,
is
doing
counter
signatures
on
encrypted
messages
to
mean
who
actually
is
the
person
who
sent
the
message?
Because
everybody's
sharing
a
group
key
you
need
to
use,
want
to
know
who
in
the
group
did
it
and
what
we're
doing
to
do.
That
is
we're
signing
the
out
signed
on
the
outside.
Rather
than
signing
on
the
inside.
F
I
said
it's
really
principled,
but
the
actual
evidence
doesn't
have
to
be
part
of
the
data
structure.
I
mean
if
I'm
counter
signing
something
because
of
evidence
that
that
I'm
not
going
to
add
to
the
data
structure.
That's
a
very
valid
thing.
I
have
trouble
understanding
why
this
one
would
not
be
valid.
E
We
didn't
do
one
for
counter
signatures,
because
I
didn't
think
about
it
and
I'm,
not
too
sure
that
it
makes
sense
I'm,
basically
bringing
it
up
at
this
point,
just
purely
as
a
completeness
issue.
So
I
don't
know
of
any
situation
where
one
would
have
a
counter
signature
floating
around
on
its
own.
A.
E
F
Guess
moment:
I'm
very
much
against
proof
by
leg
of
imagination,
so
I
think
completeness
just
cause
for
doing
this.
It
doesn't
cost
very
much
I
mean
it
costs
one
sea
boat
egg.
Depending
on
how
long
you
make
it
that
cost
can
be
very
low
and
it
makes
it
available
for
when
it's
needed
and
you
then
you
don't
need
to
or
suddenly
start
doing,
complicated
things.
N
A
So
the
so
this
was
discussed
at
the
virtual
interim
briefly,
with
a
will
ask
for
it
when
we
need
it,
and
now
we've
gotten
at
least
one
opinion
of
we
should
just
ask
for
it
now,
and
so
nobody
else
has.
Has
anything
I'd
like
to
see
on
this
one
I
suppose
we
can
run
a
home
to
see
whether
we
should
at
whether
we
should
register
for
one
now.
A
A
E
Things
of
things
which
basically
I
don't
necessarily
know
what
we're
doing
with
or
just
to
basically
I
need
input.
I
rewrote
the
ionic
considerations
to
basically
only
have
the
things
that
I
am
is
supposed
to
do
when
this
document
shows
up,
rather
than
having
all
of
the
old
registrations
in
the
Ino
sections,
to
make
it
easier
for
I,
ana
and
also
because
I've
been
getting
pushback
on
some
other
documents,
I've
written
from
the
iesg
about.
E
E
M
F
Right,
so
the
the
syllabus
wording
does
not
use
the
word
canonicalization.
Of
course
it
points
back
through
70
49,
because
there
is
a
technical
difference
between
the
recommendation
and
70
49,
the
recommendation
that
is
in
the
right
now
in
either
case.
It's
a
recommendation,
so
you
need
to
specify-
even
if
you
just
say
do
it
like
the
recommendation
says
so.
F
K
E
L
Oh
Lawrence
Thunder
lead
the
Seaboard,
canonicalization
and
deterministic
encoding
has
always
been
a
bit
weird
to
me.
My
preference
would
be
to
just
take
the
canonicalization
needed
for
cozy
into
the
cozies
back
and
just
drop.
The
reference
just
seems
like
that
would
be
cleaner.
To
me
is
the
the
canonicalization
needed
for
cosy
is
pretty
small
and
specific,
where
the
the
general
rule
seemed
no
more
general
and,
and
it
seems
like
it
might
be
cleaner
to
do
that.
E
F
So
the
editorial
intent
is
to
improve
on
the
section
that
that
defines
this
minimal
encoding.
It's
no
longer
a
part
of
the
prefer
of
the
deterministic
encoding.
It's
called
preferred
encoding
now
and
the
the
deterministic
encoding
is
preferred
encoding,
plus
map
key
sorting,
but
in
any
case,
I
think
the
the
what
the
application,
the
Seaboard
application
protocol
cosy.
F
Does
it's
nice
if
you
follow
the
recommendations
of
Siva
Bastille,
but
see
what
this
really
doesn't
have
a
busyness
in
making
you
any
tell
you
how
to
do
it
that
that's
your
decision
and,
on
the
other
hand,
the
application
doesn't
have
any
business
telling
the
the
civilization
protocol.
What
what
the
recommendation
for
other
application
protocol
should.
E
F
Yes,
but
that
would
be
confusing,
but
because
it
would
send
the
message
that
you
have
to
have
the
old
70,
the
free
world,
70
49
canonicalization
to
do
cozy,
and
that's
not
true.
If
you
have
the
the
syllabus
deterministic
encoding,
you
have
everything
you
need
to
do
cause
you
have
more
than
you
need
to
do
cost
so
I
would
explicitly
not
refer
to
the
old
recommendation,
which
only
differ
in
the
way
they
do
math
lease
watching
anyway.
E
F
E
E
E
E
E
I've
got
three
implementations,
there's
also
an
implementation
in
JavaScript
and
an
implementation
in
Python.
They
are
not
complete
in
terms
of
then
they
don't
all
do
counter
signatures.
They
don't
all
implement
all
of
the
different
algorithms
that
you
could
do.
The
JavaScript
one
I
know
only
does
ECDSA
and
II
CVH.
E
It
doesn't
do
any
of
the
Edwards
curves,
but
from
an
inter
option
operative
from
the
point
of
doing
interoperability,
and
we
give
me
even
the
report
that
I
don't
believe
that
matters,
because
that's
underlying
cryptographic,
algorithms-
that
has
nothing
to
do
with
how
cozy
itself
is
structured.
So
you
can
you
can
look
at
the
messages
you
can
build,
signed
messages,
you
can
care
part
signed
messages
and
they
work.
It
doesn't
matter
which
signature
hugger
than
use
you
know
to
the
covers.
E
J
Brendon
Morin
I
just
wanted
to
make
a
note
about
Interop
and
some
of
the
content
in
the
RFC,
and
it's
not
spelt
out
very
clearly
exactly
what
the
contents
of
a
signature
field
are.
The
the
problem
that
this
is
caused
for
me
has
been
that
all
of
the
crypto
libraries
I
have
access
to
default
to
producing
an
ASN
one
encoded
signature,
and
so
the
two
fields
have
to
be
extracted
from
that
to
put
them
in
a
cause.
A
signature
container
and
a
naive
implementation
will
just
put
the
whole
thing
in
there
and
thus
not
interrupt.
O
E
You
go
to
the
cozy
working
group,
a
github
repository.
You
will
find
the
c-sharp
version,
the
java
version
and
the
c
versions,
or
which
is
are
the
three
of
mine,
and
I
am
going
to
be
putting
pointers
on
the
readme
page
of
the
of
this
particular
document,
which
is
also
in
the
cozy
working
group.
To
point
to
the
other
two,
the
other
two
implementations
great.
P
O
F
To
leave
the
subject
of
this
group
for
a
couple
of
seconds,
that
is
of
course,
a
question
that
comes
up
for
other
SIBO
based
formulas
like
cinnamon
and
so
on
as
well,
and
my
plan
is
to
extend
the
Seaboard
at
our
own
site
in
such
a
way
that
it
can
carry
pointers
to
fermentations
of
cozy
cinema
suits
and
so
on.
So
I
will
contact
you
you,
after
the
meeting
sometime
after
the
meeting
to
collect
that
information,
I.
G
E
E
There's
almost
no
changes
in
the
actual
contents
at
this
point
in
time,
given
the
the
what
you
had
I'm
pulled
that
in
for
the
for
the
a
CVS
a
there's.
Actually,
if
you
go
to
the
root
of
the
readme,
there's
actually
two
pointers
to
RSC
diff,
which
will
which
will
actually
compare
the
current
version
and
80
81
52.
So
you
can
actually
look
to
see
what
changed
between
everything
I
don't
know
of
any
open
issues
on
this
particular
document
or
I.
E
E
B
E
E
E
E
So,
there's
a
whole
slew
of
potential
algorithms
that
we
could
put
into
this
hash,
algorithms
that
we
don't
currently
have.
Although
some
of
those
hash
algorithms
are
in
the
hash
draft,
they
could
basic
yeah.
This
is
all
sorts
of
signature,
algorithms
that
we
could
be
adding
key
rap
algorithms,
Mac,
algorithms,
ADF
algorithms.
E
F
E
Mean
it
is
things
like
if
you
I
mean
the
question,
is
you
say
sha-3?
Yes,
so
when
you
say
sha-3,
do
you
mean
sha-3,
256
sha-3
512,
shake
128
or
shape
256,
yes,
I
mean
as
hash
algorithms,
independently
as
by
a
signature,
algorithm
you're,
starting
to
get
a
big
growth,
and
there
is
a
question
as
to
how
many
people
are
going
to
be
switching
to
Edwards
kurz,
as
opposed
to
staying
with
EC
ba.
F
E
F
I
mean
if
this
this
other
standard,
where,
where
ITU
is
squatting
on
code
points,
because
they
didn't
understand
the
IANA
thing,
I
mean
they
are
also
doing
it
wrong,
but
which
is
even
worse,
but
the
interesting
observations,
they're
squatting
on
code
points,
because
they
didn't
figure
out
how
to
get
the
IANA
registrations
and
I
would
just
like
to
take
a
little
bit
of
the
sand
out
of
the
gears
here
and
just
make
it
easy
for
other
people.
So
the
observation
VI
HF
is
going
to
do.
F
G
John
Watson,
Eriksson
I,
think
shot.
3
is
something
that
should
be
discussed
and
added
now,
I
think
the
hash
algorithm
a
good
choice
to
standardize
the
shape,
but
not
the
main
shortly
I
think
that
can
be
discussed.
Is
that
is
needed
as
well,
but
I
think
shake
should
be
added
now
having
kmac
is
also
useful.
Algorithm
should
be
added
now,
that's
a
short
read
about
the
right
algorithm.
Q
Quinn
danged
nest
I
saw
from
the
previous
slide.
If
you
and
the
whooping
group
one
day
decided
to
do
the
PDF,
which
came
back,
you
could
do
it
with
the
HT
DF
or
you
could
do
just
came
back
alone.
That
is
an
option
we
specified
and
yep.
You
could
use
it
H
PDF
or
you
just
you.
You
know
one
past
kmac
myself
and
both
options
are
affine
to
us
and.
E
E
E
Q
Q
E
Yeah
and
that's
and
that's
one
of
the
reasons
I
come
yeah
I
put
K
Mac
on
the
list
is
I
think
it's
is
interesting.
I
mean
it's
the
key
ramp
algorithms,
the
k
WF
when
I
put
on
there
I,
don't
know
that
anybody
knows
what
it
was:
I
didn't
until
the
middle
of
February,
when
I
was
trying
to
find
something
else
and
I
ran
across.
This
is
a
hash.
Only
key
rap
algorithm
and
I
haven't
torn
it
apart
to
enough
to
fit
to
figure
out
what
it
does
and
how
it
works.
E
A
One
thing
the
chairs
will
note
is
well
the
while
the
current
charter
does
say
we're
doing
doing.
Essentially
the
minimal
for
this
group
and
our
dependent
groups
or
groups
groups
have
dependencies
on
this
work.
There
is
nothing
that
necessarily
stops
us
from
retiring
to
do
additional
algorithms.
If
we
can't
come
to
agreement
relatively
quickly,
so
something
to
keep
in
mind.
E
The
sha-1
is
going
into
the
registry
marked
as
deprecated,
but
it
is
there
because
a
lot
of
people,
it's
still
perfectly
good,
to
use
sha-1
for
certain
types
of
things.
If
what
you're
doing
the
same,
I
want
to
just
filter
out
of
I've
got
a
whole
this
Louis
Lewis
or
did
because
I
want
to
get
the
ones
that
are
possible.
It's
like,
if
you
get
two
or
three
back,
doesn't
really
make
a
difference
because
you
just
check
each
of
one
of
them
until
you
find
the
one
with
the
right
public
key.
E
Q
Q
E
Q
Q
They
both
provide
256
bits
of
security,
the
SHA
the
shot
three
512
has
farter
base
of
preimage
in
second
preimage
resistance,
but
that
is
essentially
you
know,
but
collision
is
to
the
56-bit
of
collision,
resistance,
strength
and
so
256
bits
of
security
is
more
than
enough.
So
you
don't
you
know
you,
you
don't
need
or
anything
go
to
file
Topher
for
anything
and
but
by
doing
that,
you're
burning
it
double
energy.
You
know
energy
consumption
and
your
function
will
to
be
twice
slow
from
shake
512
shake
256
to
char
3,
5
12,
so
yeah.
F
F
Yeah
so
I
think
it
is
useful
to
have
these
things
that
that
cannot
really
be
used
as
a
graphic
edge
functions.
I
recovered
I
would
like
actually
like
to
edge,
which
most
definitely
are
not
cryptographic
and
I'm
wondering
whether
this
is
the
right
space
to
do
it,
because
it's
really
useful
to
have
numbers
for
those.
F
G
E
So
right
now,
as
the
recommended
value
that
I've
got
on
the
sha-256
slash,
64
is
no
because
it
doesn't
really
provide
the
the
declension
resistance
that
you
want,
but
I
think
it
makes
sense.
If,
especially,
if
we're
going
to
add
the
additional
algorithms
into
this
table
to
put
another
to
know
the
column
into
it,
which
describes
something
about
the
functions
that
they
have
the
house,
this
that
could
be
used
for
so
in
terms
of,
if
you're
looking
for
collision
resistance,
as
opposed
to
just
filtering.
So
that's
clearer
in
the
IANA
registry.
E
C
E
E
E
If
people
want
to
give
me
some
input
in
terms
of
or
the
designated
experts
of
which
I'm
one
input
in
terms
of
how
frequently
they
think
these
hash
algorithms
are
going
to
be
used
just
in
terms
of
whether
we
assigns
some
of
the
one
byte
space
as
opposed
to
assigning
two
byte
identifiers
to
them,
I.
What
I'd
like
to
hear
that
as
a
right
now
is
probably
the
that
suit
is
going
to
be
using
all
the
time.
It's
gonna
be
a
one
bite
and
everything
else
is
gonna,
be
a
few
bitin.
Your
MOT.
G
J
So
just
a
comment
from
the
suit
perspective:
the
current
version
of
the
draft
is
actually
importing
hash
identifiers
from
the
named
information
draft.
If
that
needs
to
be
adjusted,
we
can
do
that,
but
that's
currently,
where
we're
finding
the
algorithm
identifiers,
because
there
weren't
any
in
cozy
Brendan
Morin.
E
It's
I
mean
we
need
to
do
it,
define
it
for
X,
5
or
9.
So
we
have.
We
have
to
find
a
structure
which
says:
I've
got
a
hash
and
I've
got
a
value,
and
the
question
is
whether
people
in
general
would
want
to
do
that
or,
as
I
generally
recommend,
they
should
be
defining
their
own
structure.
So
I
said
you
know
suit.
You
should
define
your
own.
F
E
E
So
documents
missing
because
the
security
considerations
at
this
point
and
then
there's
just
a
couple
of
procedural
questions
if
suit
wants
to
use
this,
and
we
need
to
do
early
assignment
of
the
identify
of
at
least
some
of
the
identifiers,
the
ones
that
they
want
to
be
using
and
there's
a
procedural
question
in
terms
of
timing,
this
potentially
could
be
going
into
working
class
call
even
before
the
documents
evolve.
What
I'm
doing
this
is
writing
considering
considerations
and
that's
it.
A
A
D
A
E
E
The
defaults
in
terms
of
which
you
are
referring
to
whether
you're
referring
to
something
on
the
signers
and
on
the
originators
end
or
something
on
the
recipients
and
depends
upon
whether
you're
looking
at
signing
or
key
agreement
signing
it's
is
refers
to
the
originators
and
key
agreement.
It
refers
to
the
recipients
and
which
Manson
when
I
sat
down
to
actually
start
doing
things.
E
B
E
E
E
E
E
F
I
One
of
the
things
that
at
least
the
Jose
working
group
decided
to
do
was
say
essentially
that
the
certificate
was
always
extra
information
which
you
could
ignore.
If
you
didn't
need
it
and
the
way
they
did,
that
was
to
say
that
if
you
had
a
certificate,
the
jwk
representation
of
the
public
key.
That's.
E
E
E
E
It
also
give
us
gives
us
a
way
forward,
because
one
of
the
issues
that
was
raised
on
the
mailing
lists,
but
in
the
last
week
is
well.
What
happens
if
what
I
want
to
do
is
use
a
JWT,
so
you
could
basically
identify
a
JWT
the
same
sort
of
way
into
if
you
want
to
carry
it
in
a
key
which
makes
my
implementation
easier,
because
then
I'm
still
just
carrying
keys,
passing
keys
into
the
implementation
and
it's
up
to
the
implementation.
If
you
get
what
to
do
with
a
certificate
or
with
a
CWT.
E
We
don't
have
any
implementation
experience
playing
with
this,
but
there
is
at
least
one
standards
groups
which
wants
to
get
a
code
point
for
at
least
the
things
that
go
into
the
cosy
signature.
Cozy
encryption
document
are
objects,
so
we
can
basically
get
to
potentially
do
early
adoption
on
those
that
is
those
four
things
and
but
not
actually
process
finish
process
and
document.
Until
we
have
have
some
good
discussion
on
how
we
deal
with
fuzzy
keys.
I
Mike
again,
I
guess
thinking
about
the
jose
context.
We
put
in
x.509
certificate
representations,
because
a
lot
of
people
had
and
still
do
have
tools
that,
if
you
were
generating
a
key,
that
was
the
wrapper
that
they
got
it
in
and
they
had
things
to
consume
it.
But
we
as
an
explicit
transition
step,
wanted
to
also
make
it
possible
for
people
to
deploy
without
having
to
have
an
ASM
dot,
1
bar
sir
etc.
I
realized
the
application
context
and
motivation.
Here
is
a
little
different
and
I.
I
R
We
specified
that
the
first
one
is
the
leaf,
but
then
the
ones
after
that
just
are
a
collection
of
our
kind
of
a
bag
that
you
can
build
chains
out
of
that
the
system
has
to
kind
of
search
through
those
certificates
to
its
root,
so
think
about
whether
that's
what
you
want-
and
second
this
was
for
signed
exchanges
for
in
web
packaging,
so
mostly
desktop
and
phones
rather
than
really
constrained
spaces.
Does.
E
E
E
E
B
E
R
E
P
E
A
I
Meaning
it's
a
final
w3c
standard,
there's
for
RSI
signing
algorithms
that
are
registered,
which
weren't
already
registered
for
use
in
cozy,
as
well
as
the
SEC
P
256,
K
1
curve,
and
signing
with
that
I'll
note
that
this
draft
is
explicitly
intended
to
fulfill
a
charter
deliverable
which
is
on
the
screen
there
and
just
for
reference
if
you're
downloading
the
slides.
This
is
the
final
web
authentication
URL.
I
Thankfully,
I
received
two
really
good
sets
of
reviews
already
one
from
Jim
shod,
one
from
John
Matson,
which
I've
replied
to
you
on
West.
They
both
found
a
number
of
things
that
they
suggest
made
the
same
suggestions
for
which
tells
me
that
yeah,
we
should
probably
do
those
things,
and
you
can
see
those
on
list.
I
These
were
defined
by
yan,
comma
mesh
of
IBM
and
some
additional
people
I
think
Ralph
from
knock-knock
and
originally
done
in
a
Fido
one
UAF
text
and
web
authentic
can
do
at
a
stations
about
the
authentication
that
occurred
using
these
formats.
Now,
I
will
know
that
the
web,
authentic
considerations
section
and
proposes
just
registering
these
referencing
the
spider
draft.
I
As
the
primary
definitions,
we
could
just
decide
as
cozy
to
first
just
ask
Ayane
to
process
this
and
have
the
designated
experts
either
say
yes
or
no,
and
only
if
the
designated
experts
say
no
would
we
even
have
any
work
to
do.
There's
also
been
questions
about.
Are
these
great
algorithms
in
the
first
place,
but
now
we're
batting
out
of
my
league
Jim
shod
coming
to
the
microphone
I
suspect
us
a
designated
expert,
Jim.
E
U
U
T
I
This
draft
today
consists
of
well
known
algorithms,
with
well-known
security
properties,
and
we
could
finish
it
very
quickly
if
we
suck
this
stuff
in
will
be
a
year
plus
at
least
with
CFR
G
involvement
and
what-have-you,
but
I
did
want
to
point
out
that
as
chartered,
we
could
have
included
these
and
I
did
not.
For
some
of
these
reasons,
all
right
well.
A
You
know
Charter
says
we
things
that
are
needed
by
others.
That
doesn't
necessarily
mean
we
have
to
take
everything
so
just
pointing
that
out
there
I'm
hearing
a
lot
of
these.
This
is
really
bad.
Is
there
anybody
that
wants
to
risk
coming
to
the
mic
to
have
a
counter-argument,
yeah,
okay,
so
I
think
it's
I
think
we
I
think
we
can
continue
without
without
trying
to
add
these
okay.
I
A
I
I
There
was
a
string
which
came
from
one
implementation
that
already
exists:
I,
think
by
Vladimir
Duchenne
off
of
connect
ID,
where
he
implemented
signing
using
the
SEC
P
256
K
one
curve,
and
he
called
it.
P
256
K
and
both
my
reviewers
said
just
call
it
SEC
P
256,
K
1,
and
that
makes
sense
to
me
or
was
it
your
implementation?
No.
E
H
A
I
I
I
I
Q
B
I
I
I
A
So
so,
as
Mike
pointed
out
that
working
group
last
call,
a
working
group
call
for
adoption
does
end
today,
given
all
the
feedback
we've
gotten
on
the
list
and
lack
of
any
objections
here,
I
believe
we
will
be
adopting
it.
I
think
the
one
question
we
would
have
is
for
the
two
reviewers
that
do
happen
to
be
in
the
room.
Is
it
important
to
address
those
concerns
before
okay,
you've
gotten
headshakes
from
both
of
them?
So
we
will
send
the
announcement
on
the
list
by,
but
yes,
please
submit
submit
a
draft
IETF
Cosi
item.
A
B
A
B
B
What
are
the
characteristics
of
the
algorithm?
So
you
build
a
tree,
it's
hash
pastry,
Merkle
trees
and
the
number
of
signatures
that
you
can
use
depends
on
the
number
of
leaf
nodes
in
the
tree.
So
it
has
a
finite
number
of
signatures.
That's
one
of
the
biggest
criticisms
of
this
algorithm,
but
it
has
small
public
keys
and
a
low
computational
cost.
B
B
B
B
B
So
this
slide
can
has
the
conventions
right
out
of
the
internet
draft
I'm
not
going
to
read
through
you
know
them,
but
the
what
goes
in
each
of
the
fields
in
the
for
a
signature
is
there
have
comments
about
this?
Please
talk
about
the
list
next,
so
why?
Why
are
we
carrying
about
this?
Like
I,
said
the
small
verification
code?
Size
is
very
attractive
in
the
IOT
space,
since
it's
quantum
safe,
a
bunch
of
people
are
advocating
that
we
use
these
now
to
sign
firmware
that
way.
B
We
have
a
way
to
deploy
the
code
that
implements
the
next
generation
of
crypto
in
a
safe
way.
If
something
comes
along
that
makes
this
difficult,
such
as
a
large-scale
quantum
computer,
we
still
have
confidence
in
the
software
update
integrity
mechanism,
so
suit
has
been
looking
at.
This
suit
has
already
decided
they
are
using
cozy.
That's
a
decision.
B
We're
looking
at
this
is
one
of
the
possible
mandatory
implement
algorithms.
That
discussion
is
going
to
happen
later
this
week,
so
I'm,
hoping
that
this
discussion
doesn't
change
that
next
slide.
So
we
already
had
the
working
group
adoption
of
this.
Some
small
errors
were
found
that
basically
we're
done
to
align
the
the
document
that
is
now
in
the
RFC
editors
queue
and
and
this
Jim
shod
provided
some
comments.
They
were
dealt
with,
I
think
to
his
satisfaction,
and
Jim
also
has
done
an
implementation
now.
B
Q
B
Q
B
A
Any
other
comments
all
right,
so
it
sounds
like
four
fractions.
Then
you,
you
have
one
more
revision
to
do
with
these
updates
and
then
we
should
be
able
to
do
a
working
group.
Last
call
on
that
also
I
mean
this
is
arguably
the
most
complete
of
the
documents
that
were
that
we
initially
took
on.
So
if
there's
no
objections,
we
can
look
at
doing
that.
I
think
we've
still
got
a
number
of
things
to
deal
with
that.
The
core
drafts
that
this
shouldn't
be
too
much
of
a
distraction.
W
A
What
what
we
are
looking
to
propose
is
having
a
another
virtual
interim,
to
discuss
some
of
these
outstanding
issues
again,
targeting
sometime
in
May
again
focusing
on
on
any
152
bits
with
the
idea
that
by
IETF
105
we're
either.
If
we're
really
really
really
optimistic,
we
might
be
able
to
see
if
we
can
get
it
to
the
state.
A
We
feel
we
can
pop
wreck
but
most
likely
to
get
to
the
state
that
we're
doing
a
working
group
last
call
on
the
best
drafts,
also
for
one
at
105
talking
again
with
Jim
and
a
couple
other
people
at
the
hackathon.
Looking
at
attempting
to
do
a
in
Interop
some
form
of
interrupt
testing
at
the
Montreal
hackathon.
A
A
F
Yeah
just
one
comment
on
the
virtual
interim
stuff:
there
is
a
number
of
working
groups
that
are
doing
virtual
inference
repeatedly
and
so
on.
So
I
think
it
would
be
a
nice
idea
to
just
coordinate
this,
so
you
could
use
one
of
the
slots
of
the
Seaboard
working
group.
So
it's
not
so
much
of
a
change
for
people.
Okay,.