►
From YouTube: IETF113-COSE-20220321-1200
Description
COSE meeting session at IETF113
2022/03/21 1200
https://datatracker.ietf.org/meeting/113/proceedings/
B
B
So
going
through
the
chair,
slides
and
I'm
starting
on
time,
because
we
are
so
tight,
I
wonder
if
the
clicker
works.
A
And
the
same
computer
that
you've
started
them
from.
There
should
be
like
arrows
near
the
bottom
of
the
screen,
and
I
think
that
the
arrow
keys
on
your
keyboard
will
work
as
well.
B
A
B
C
C
Like
if
you
I
can
try
to
share
this
likes
and
see
if
I
managed
to
figure
it
out,
let
me
have
to
tell
you
next
night.
C
Oh
yeah,
I
can
try
to
take
control
of
the
slides,
not
sure
if
that
will
be
helpful.
B
B
D
Let's
say
which
one
did
status
by
the
chairs:
okay
yeah.
I
think.
B
View
now
there
are
arrows.
Thank
you,
hannes,
honest
joe
fenninger,
our
our
hero.
B
There's
a
set
of
meeting
tips,
the
most
important
one,
I
believe,
is
that
all
of
you
in
the
room
are
to
join
using
the
lite
version
of
meat
echo,
which
is
the
one
that
looks
like
a
mobile
telephone
and
you
use
that
user
interface
in
order
to
cue
yourselves,
so
that
we
are
being
fair
to
people
not
only
in
the
room
but
in
the
virtual
room.
So
please
do
so
also
you're
all
requested
to
scan
the
qr
code
or
use
the
tools
to
fill
in
the
virtual
blue
sheet
to
indicate
attendance.
B
There's
a
set
of
resources
that
I'm
going
to
skip
in
the
interest
of
time.
Most
of
you've
probably
already
found
them
per
every
itf
working
group
meeting.
I
need
two
volunteers
or
more
than
two.
I
need
people
that
are
willing
to
contribute
to
the
note
taking
there
is
a
shared
note
space
can
someone
in
the
room
raise
their
hand
or
in
the
virtual
room,
send
me
a
chat,
saying
you're
going
to
be
taking
notes.
B
B
B
Thank
you
very
much
ben
our
esteemed
area
director.
We
have
a
very
tight
meeting
agenda.
We
only
have
an
hour.
We
have
a
lot
of
good
presentations
cued
up.
I
am
now
over
by
a
minute,
so
I'm
going
to
turn
it
over
at
this
point
to
my
co-chair
evo,
the
second
agenda
item,
who
is
going
to
talk
about
the
status
of
current
drafts,
including
the
bist
drafts
eva,
do
you
want
me
to
try
to
present
that
I
should
probably
figure
out
how
to
do
that
again.
C
C
Perfect,
okay,
okay,
thank
you!
So,
yes,
I
will
be
presenting
the
slides,
I'm
here
by
the
patrol.
C
Yes,
I
will
start
with
the
beast
documents:
name,
the
1952
rfc
to
be
and
a
1953
subjective,
rfc2b
know
you.
C
I
am
sure
so,
basically,
there
and
ben
caduck
has
been
spearheading
the
discussion
with
the
rfc
editor.
There
has
been
a
number
of
exchanges
and
most
of
them
are
already
closed.
The
important
part
is
for
me
a
question
about
how
whether
we
need
to
require
private
key
in
key
operation
values.
This
is
table
5
in
section
7.1,
and
maybe
it
will
be
best
first
to
present
all
the
slides
and
then
come
back
to
this
question.
C
If
there
are
any
comments
in
in
from
the
participants,
so
this
is
the
most
important
question
for
me
that
we
could
discuss
today,
because
this
is
not
exactly
consistent
with
the
rc7517.
C
And
with
nw3c's
web
crypto-
and
we
are
claiming
to
be
consistent
with
those
and
then
there
is
a
reason
formulation
of
this
sentence
where
ben
has
indicated
we
might
want
to
check
if
this
still
makes
sense
to
everyone,
whether
the
formulation
is
still
good.
My
personal
individual
opinion
is
that
it
seems
fine.
But
yes,
if
anyone
has
other
opinions,
we
can
discuss
that
further
and.
C
Going
forward
so
then
there
is,
there
were
some
comments
from
carsten
and
the
first
one
has
already
been
addressed
and
there
were
some
texts
that
didn't
make
sense
in
its
state,
but
yeah
now
it's
fixed
and
then
there
is
an
update
that
I
was
done
in
1952
and
not
in
1953
documents.
So
we
would
need
to
make
them
consistent
and
the
last
point
is
suggestions
to
not
call
cdl
a
grammar
but
rather
standard
definition,
language
or
symbolic
data
structure.
C
Makes
sense
to
me
individually,
but
we
can
discuss
if
there
are
other
opinions
and
yes
calling
then
to
the
next
discussion
item.
Carsten
was
suggesting
to
be
more
precise
when
we
talk
about
deterministic
encoding
requirements
and
specify
which
section
we
are
aiming
for
and
yes,
this
is
the
text
that
he
has
suggested.
C
So
next
the
x509
draft,
we
are
going
to
publish
a
new
version
of
the
draft
and
that
was
discussed
some
time
ago
and
there
is
an
issue
31
that
I
believe
we
should
get
some
more
discussion
on.
I
saw
that
today,
like
maybe
an
hour
ago,
there
was
also
some
and
discussion
for
a
new
issue.
I
have
not
yet
dig
deep
into
how
it
might
affect
the
draft
so
and
then
the
counter
same
document.
As
far
as
I
saw
itself
with
roman.
E
C
Awaiting
kd
review
it's
in
a
publication
requested
status
and
going
then
to
see
burn
coded
certificates.
My
understanding
is
that
there
are
more
reviews
that
are
needed
and
there
are
some
small
to-do's
that
are
still
pending
there.
So
that's
all
the
traps
and
that
I
wanted
to
present
the
status
of
now.
We
can
go
back
mainly
to
see
if
there
is
any
quick
opinion
on
this
required
private
key
fields,
text
or
maybe
we
can
start
mainly
please,
discussion
and
device.
B
D
Yeah
thanks
thanks
a
lot
so
briefly
talk
about
the
cozy
hpke
document.
Next
slide.
Probably
evo
needs
to
do
that.
So
we
had
a
fruitful
discussion
at
the
virtual
intro
meeting
in
january
and
I
published
a
zero
one
version
in
response
to
those
discussions,
and
I
will
show
the
the
most
important
change
with
zero
one.
I
also
created,
as
I
promised,
an
implementation,
a
reference
implementation
of
this,
which
you
can
find
at
this
link
below
it's
the
decocy
library
and
here's
also
the
link
for
the
draft
repository
next
slide.
D
So
this
is
next
slide.
This
is
the
new
structure
if
you
haven't
been
following
the
discussions
last
time,
so
this
is
a
two-layer
structure
at
the
top,
you
see
the
sort
of
classical
encryption
sort
of
headers.
In
this
case
the
ciphertext
is
not
included.
It's
detached,
there's
the
algorithm
information
in
there
and
the
topmost,
the
part,
and
also
the
nonce,
and
then
the
recipient
structure.
D
That's
where
the
hb
key
content
goes
in
there
with
obviously
the
ephemeral
public
key
and
then
finally,
with
in
this
case,
with
the
encrypted
keck,
which
is
the
keck,
is
used
to
encrypt
the
the
outermost
plain
text.
D
Okay,
so
that's
what's
currently
in
the
document.
It's
a
big
change
compared
to
the
previous
version.
Next
slide:
okay,
open
issues,
so
we
talked
about
the
algorithm
registry
and
the
the
group
wanted
to
have
an
efficient
way
to
reuse,
the
hbke
defined
algorithms
and
obviously,
for
the
currently
defined
algorithms.
There
isn't
really
a
problem
because
they
are
listed
in
the
now
rfc
and
we
can
just
they
will
be
put
into
the
document
and
registered.
But
the
question
is
what
happens
going
forward
with
new
algorithms,
and
we
had.
D
We
discussed
primarily
the
first
approach,
which
was
to
add
a
rule
in
quotes
to
the
hbke
specification
to
then
automatically
populate
values
in
the
cosy
registry.
Unfortunately,
shortly
after
the
virtual
intro
meeting
and
the
discussion,
the
hb
key
document
was
published
as
an
rfc.
So
no
changes
were
possible
anymore,
which
leaves
us
with
two
other
choices,
either
to
have
a
rule
with
ayanna
to
sort
of
automatically
populate
values
in
the
registry
which,
in
my
opinion,
requires
some
discussions
with
ayanna
to
make
sure
that
this
actually
works.
D
Some
folks
in
the
group
were
hopeful
that
this
is
simple
to
do,
but
I
don't
know,
and
if
that
doesn't
work,
and
the
last
approach
is
obviously
this
approach
is
is
is
sensible
to
require
that
whenever
someone
defines
a
new
hpke,
algorithm
or
cypher
suite,
then
they
need
to
also
populate
the
registry
for
the
for
the
corresponding
cozy
registry.
D
So
that's
kind
of
like
nothing
really
earth
shaking,
but
but
at
least
there
was
a
lot
of
discussion
on
this
topic
on
on
the
list.
A
Yeah,
so
I
think
there
are
definitely
some
cases
where
ayanna
will
be
able
to
say
when
there
is
a
change
to
one
registry
go
and
reflect
that
in
another
registry,
but
you're
right.
You
should
definitely
talk
to
them
about
this
particular
case
because
they
really
want
it
to
be
a
very
deterministic
algorithm
that
they
follow.
They
don't
want
to
have
to
use
any
judgment
and
I
believe
they
have
office
hours
this
week,
but
it's
probably
only
in
gather
town.
It
may
not
be
in
person.
D
Yeah
yeah
we'll
definitely
use
the
idf
meeting
here.
In
some
sense,
it's
a
pretty
simple
task.
The
cosy
or
the
hp
key
registry
consists
of
three
separate
registry
aadid,
key
fld
and
camera
id.
As
I
wrote
on
the
slide
and
in
cosi,
it's
just
mapped
to
one
number
that
combines
the
three.
Well,
it's
it's!
Well,
you
could
call
it
simple
or
not.
I
don't
know,
but
but
in
any
case,
there's
some
something
that
needs
to
happen.
D
It's
almost
like
a
ci
in
in
case
you
you
make
some
changes,
then
automatically
does
something
else,
but
yeah
so
yeah.
I
don't
know
if
someone
has
some
better
ideas
what
to
do,
but
it
the
first
option
that
we
discussed
and
preferred
that
the
intro
meeting
is
kind
of
gone.
Unfortunately,.
A
I
think
the
second
one
will
work
pretty
well
and
I
would
suggest
that
we
just
keep
going
in
the
slide
deck.
D
So
that
was
another
point
that
hillary
raised.
That
was
briefly
touched
on
at
the
virtual
intro
meeting,
but
there
was
no
conclusion
or
no
feedback,
and
hopefully
I
get
some
feedback
from
you
and
russ
was
kind
enough
to
reach
out
to
some
guys
in
the
industry
to
get
an
understanding
of
where
we
are
in
terms
of
state
of
the
art.
So
this
is
about
point
compression
and
currently
the
the
previously
shown
example
with
the
ephemeral
public
key
that
was
included
in
the
in
the
structure
in
the
in
the
recipient
layer.
D
That's
an
uncompressed
point
and
point
compression
would
obviously
help
to
transmit
fewer
bytes
on
the
wire,
and
it
turns
out
that
this
is
a
20
plus
year
old
technology
and
the
idea
is
to-
and
that
was
illary
was
suggesting-
to
add
that
capability
to
the
document
as
another
point
format
being
optional,
because
it's
not
necessarily
widely
supported
everywhere,
for
mostly
patent
reasons.
D
And
so
yeah,
I
think
to
me
that
makes
sense
what
hillary
was
proposing
on
the
list.
I
don't
know
if
anyone
has
some
opinion
here
about
this
topic
or
has
some
experience
with
point
compression,
and
this
and
the
like.
G
D
Thanks
russ
yeah
russ
checked
out
with
paper,
so.
H
Malicious,
so
just
the
data
point
for
the
data
compression,
I
was
just
working
with
the
with
the
point
compression
for
the
past
two
weeks
in
the
context
of
the
ad
hoc
and
lake
implementation,
and
it
is
true
that
it
is
poorly
supported
in
the
existing
libraries.
But
there
is
the
rfc
6090
algorithm
that
doesn't
that
doesn't
require
the
implementation
of
square
root
that
can
be
implemented
with
the
pure
module
operation,
and
that
is
fairly
simple
to
implement
from
my
experience.
H
So
this
is-
and
this
is
well
needed
in
the
context
of
constrained
technologies
in
in
the
context
of
bites
over
the
wire
savings.
D
Warning:
okay,
thank
you.
Next
slide,.
D
I
will
skip
that
one
next
slide
in
interest
of
time,
so
this
is
a
change
I'm
proposing,
so
the
cosy
specification
has
for
all
the
different
operations.
It
constructs
additional
data
or
additional
information
to
be
included
in
in
in
the
whole
processing,
and
so,
regardless
of
whether
you
use
a
sign
operation
or
in
this
case
an
encrypt
operation
and
and
that's
a
that's.
D
This
information
is
also
structured
as
a
cosi,
sort
of
data
element
and
currently
what's
in
there
in
the
document,
is
also
an
infrastructure
to
be
used
with
hbke
and
initially
when
it
it's
a
leftover
from
the
early
days
of
the
document
in
the
suit
group
and
hbke
itself
has
its
own
way
to
pass
information
into
hp
key
for
inclusion
into
the
key
derivation,
and
so,
in
my
opinion,
that
infrastructure
is
not
needed
in
addition
to
that.
D
So,
since
hb
key
already
provides
uses
its
own
mechanism
and
provides
addition
for,
someone
who
wants
to
pass
in
additional
information
can
do
so
for
certain
usage
environments,
but
so
I'm
proposing
to
remove
that
infrastructure
from
the
document.
B
B
So
the
next
pair
of
presentations-
I
am
not
the
chair
evo,
is
the
chair.
I
am
an
individual
contributor
to
two
documents
that
my
colleague,
tobias
looker,
in
new
zealand
is
the
primary
author
of,
but
it
is
exactly
12
hours,
time
difference,
and
so
this
was
not
a
convenient
time
for
him
to
present
next.
B
So
there's
a
set
of
elliptic
curves
called
bls
that
belong
to
the
realm
of
pairing
friendly,
cryptography
and
there's
related
work
underway
at
the
cfrg.
There's
been
some
discussion
of
this
on
the
mailing
list
already
from
russ
housley
and
the
like,
and
I'd
like
russ,
to
comment
at
the
end,
if
possible,.
B
B
So
there's
numerous
applications
of
pairing-based
cryptography,
there's
one
called
bls
signatures.
There's
the
bbs
bbs
plus
signatures
work
that
some
of
you
who
are
aware
of
some
of
the
current
decentralized
zero
knowledge
proof
work
may
have
been
following
again.
This
is
supporting
other
work
in
other
standards
organizations,
but
jose
and
kosei
have
become
the
gold
standard
for,
respectively,
based
and
seabore
based
cryptographic
operations,
which
is
why
tobias
is
bringing
this
draft
to
this
working
group.
B
B
So
the
only
next
steps
that
the
authors
are
requesting
today
is
for
people
to
read
the
draft
and
to
comment
on
the
mailing
list
following
a
discussion
on
the
mailing
list,
depending
upon
how
that
goes,
we
may
ask
for
working
group
adoption,
but
we
are
not
doing
that
today.
B
B
And
the
chairs
can
take
that
up
with
the
area,
directors,
etc
and
eva,
and
I
will
take
that
action
item
with
me
wearing
my
chair
hat
and
not
as
a
draft
author
hat.
B
B
B
The
jot
spec,
which
came
before
has
an
interesting
feature
which
dick
hart
had
requested
and
some
others
based
on
practical
experience,
which
was
dick,
was
looking
at.
If
you
have
an
encrypted
token
with
jwe,
you
obviously
can't
see
the
claims.
That's
generally
a
good
thing,
but
sometimes
when
you're
processing
a
token
like
routing
it
trying
to
decide
where
it
goes.
B
That's
worked
out,
okay
for
jots,
it
does
not.
That
feature
is
not
present
in
cwt's
and,
furthermore,
you
couldn't
just
port
the
feature
directly
into
cwt's,
because
john
excuse
me
cwt,
claim
names
and
cos
a
header
parameter.
Names
are
both
small
integers
with
an
overlapping
space,
so
you
couldn't
just
mix
and
match
next
slide.
B
So
the
proposed
solution
in
this
draft
is
to
define
one
new
cozy
header
parameter,
the
value
for
which
is
a
set
of
cwt
claims
that
can
be
disclosed
in
the
integrity
protected,
but
non-encrypted
header.
This
parallels,
the
chat
functionality,
that's
already
been
shown
to
have
at
least
been
good
enough
to
solve
the
problem
at
hand.
B
I
think
that
should
be
fairly
clear.
Let's
go
to
the
next
slide.
It
is
exactly
the
same
as
the
last
slide
in
the
previous
presentation,
where
we
are
requesting
that
working
group
members
read
the
draft
comment
on
list
and
depending
upon
how
that
discussion
goes.
The
authors
may
ask
the
chairs
for
working
group
adoption
where
I
will
obviously
stay
out
of
that
as
a
conflict
of
interest,
any
comments.
Or
can
we
move
on
to
the
next
presentation
because
I
think
we're
even
a
minute
or
two
ahead.
B
The
next
presentation
is
by
mike
prorock,
whose
remote
evo,
could
you
queue
up
mike
prorock's
presentation
on
post
quantum
signatures
and
mike
are
you
with
us.
I
J
I
authored
an
individual
draft
and
then
got
some
great
feedback
and
support
from
a
number
of
folks,
as
well
as
contributions
so
and
some
folks
also,
obviously
working
across
other
aspects
of
cryptography,
so
we've
got
basically
the
problem
statement
is
this:
we
know
post
quantum
algorithms
will
come
out.
J
Be
able
to
interoperably
sign
things
with
post
quantum
methods
and
make
sure
that
the
other
side
was
interpreting
that
correctly
and
that's
with
both
jose
and
jose.
So
we
wrote
up
the
draft
initially
focused
on
kind
of
two
aspects
of
post
quantum
signatures,
so
hash
based
and
lattice
based
schemes.
J
The
main
reason
for
that
is
that
we
want
to
make
sure
we
have
a
good
trade-off
and
good
options
in
case
we
find
problems
either
with
size
on
signatures
that
just
make
them
impractical
or
key
sizes,
or
if
we
find
a
weakness
in
one
approach,
be
it
a
lattice-based
approach
that
has
some
fundamental
weakness
that
we're
not
aware
of.
We
want
the
ability
to
fail
over
to
hash,
based
or
otherwise
right,
so
it's
really
about
providing
crypto
agility.
J
The
main
concern
I
see
is
that
the
nist
standardization
process
is
obviously
still
ongoing
for
this,
but
but
these
algorithms
are
out
they've
been
around
for
a
while
they're.
You
know,
I
guess
in
what
round
three
and
are
you
know
moving
forward
there?
J
So
I
think,
even
if
nist
does
not
standardize
one
of
the
algorithms
that
we
define
here,
we
would
still
want
to
go
ahead
and
go
ahead
and
get
it
defined
if
for
no
other
reason
than
to
be
able
to
make
sure
that
it
is
defined
and
we
can
flag
it
as
hey.
Please
do
not
actually
use
this
from
like
an
iona
registry
standpoint
next
slide,
please.
J
So
you
know
once
again
kind
of
going
back
to
the
main
goals.
We
want
to
really
enable
agility
to
be
able
to
jump
up
to
these
post-quantum
algorithms
when
they're
appropriate.
We
want
to
be
able
to
test
ahead
of
time,
and
then
we
do
want
to
go
ahead
and
make
sure
that
we
can
get
in
our
registrations
done
for
these
post
quantum
signature
schemes,
otherwise
one
of
the
things
especially
due
to
the
high
level
of
parameterization
and
the
fact
that
most
of
these
algorithms
get
their
security
properties
from
specific
combinations
of
parameters.
J
We
want
to
make
sure
very
explicit
parameters
are
registered
for
each
algorithm.
So
we
know
what's
good,
what's
bad
etcetera
right
and
can
put
that
out
next
slide.
Please,
the
you
know
some
complexity
in
getting
at
the
really
kind
of
getting
at
the
parameterization
side
of
things
right.
We
really
need
to
be
able
to
use
alg
or
some
other
identifier
right
within
there,
just
to
make
sure
that
we
can
clearly
identify
what
set
of
parameters
is
in
use,
for
instance,
with
dilithium
or
falcon,
or
especially
a
special
sphinx
plus,
etc.
J
So
we
we
do
want
to
make
sure
that
that's
very
explicitly
stated
otherwise
it'd
be
very
possible
to
either
misidentify
a
key
or
to
run
a
you
know,
run
a
method
or
a
signature
method
with
the
wrong
set
of
parameters,
and
that's
obviously
not
good
next
slide.
Please.
J
I
J
Looking
at
as
a
group
that
are
working
on
some
different
ways
of
just
talking
about,
you
know
like
the
sign
verify
operations,
we're
not
defining
any
new
cryptography
here,
like
no
desire
to
do
that.
This
is
just
pointing
back
at
the
well-defined
stuff
we
may
for
right
now,
we're
just
pointing
back
to
the
papers
and
that
they
just
stay
that
way.
J
We
are
based
on
feedback
on
the
list,
looking
a
little
broader
at
some
other
hash
based
signature
approaches,
especially
some
more
stateful
ones,
and
then
we're
getting
ready
to
start
into
a
whole
bunch
of
test
factor
generation
and
getting
into
some
better
serialization
examples
with
both
jwk
and
with
jws.
J
So
really,
the
big
ask
little
group
is
go
ahead
and
read
the
draft.
I
know
quite
a
few
of
you
that
I
see
here
have
already
done
so
provide
feedback
and
then,
if
appropriate,
and
if
in
line
for
the
charter
we'd
like
to
be
able
to
get
this
adopted
as
a
working
group
item
and
move
it
forward
when
the
time
is
right,
assuming
that
it
matches
the
group's
needs.
So
thanks
so
much.
K
L
M
Yeah,
I
I
just
want
to
point
out
what
what
I
pointed
in
chat
that
the
algorithms,
according
to
the
cozy
charter,
have
to
be
evaluated
by
cfrd
or
completed
public
review
and
violation
by
a
process
that
is
the
nist
process.
So
if
these
algorithms,
that
you're
defining
here
are
not
collected
by
nist,
I
believe
they
would
have
to
go
through
pfrg
evaluation.
B
All
right,
if
not,
I
will
speak.
Oh
there
we
go
now.
E
You
sure
I
just
want
to
note
that
the
lms
and
xms
are
actually
all
approved,
missed
algorithms,
post
quantum,
you
read:
miss
800,
sp
208,
we'll
see
their
proof.
There.
E
A
Yeah,
sorry,
I
guess
I
jumped
a
little
bit
too
early
with
sending
my
video,
but
I
mainly
wanted
to
just
say
thank
you
to
my
for
the
yeah
to
michael
for
the
bit
about
reducing
optionality
and
really
nailing
down
the
parameters
for
the
post.
Quantum
stuff
and
it'd
be
really
useful
to
have
these
sort
of
just
use
this
and
not
have
people
worry
about
exactly
what
they
have
to
choose.
N
Yeah
thanks
a
lot,
a
very
interesting
wrap.
I
I
think
it's
it's
might
become
like,
in
my
mind,
like
two
drafts,
in
a
sense
that
what
we
do
with
jose
but
with
causes
might
be
slightly
different.
This
is
like
they're
targeting
different
use
cases,
at
least
in
the
very
constrained
case.
Some
of
these
signatures
might
be
less
appropriate
than
others
due
to
their
size,
and
things
like
that
maybe
clearly
separating
this.
N
This
use
case
of
very
constrained
devices
might
makes
it
make
sense.
There
are
some
things
that
are
really
can
be
set
as
less
interesting
in
this.
In
this
context
of
very
constrained
devices,
I
I
I
talk
on
behalf
of
the
committee
working
on
on
on
the
riot
operating
system,
where
we
have
like
very
constrained
devices
and
microcontrollers,
and
things
like
that.
I
know
some
of
people
in
the
room
are
very
sensitive
to
these
types
of
constraints,
but
yeah,
so
so
that
would
be
great.
N
Actually,
we
we
have
a
recently
previous
paper
on
this
that
is
analyzing
some
of
these
signatures
in
this
context,
using
cozy
for
for
a
suit
secured
security
for
updates
on
on
riot
devices.
I
can
share
the
link,
if
that's
interesting
also
here.
B
J
Gonna
note
there's
a
related
draft
and
actually
can
we
pop
to
the
next
slide.
I
think
I
put
a
link
reference
in
there
and
I'm
gonna
dig
up
the
link
and
put
it
in
chat,
but
this
is
actually
also
highly
referenced
and
has
a
number
of
the
folks
that
are
also
working
on
the
key
information
spec
as
well.
I'm
linking
that
now,
the
so
there's
quite
a
bit
of
overlap
there.
Just
in
terms
of
yep.
We
already
know
that
these
things
are
getting
well
defined.
B
Okay,
I'll
make
one
closing
remark,
which
is
kozai
as
a
working
group
is
chartered,
among
other
things,
to
do
registration
of
algorithm
identifiers
for
algorithms
with
a
certain
level
of
maturity,
we
are
explicitly
not
chartered
to
describe
new
kinds
of
cryptographic
operations
and
there's
a
fairly
bright
line
between
the
two,
I
will
say
just
wearing
a
hat
as
an
individual
right
now,
when
I
read
the
draft
at
first,
I
know
that
there
was
a
lot
of
explanatory
text
trying
to
say
how
these
algorithms
work
and
how
they
might
be
used.
B
B
All
right,
thank
you
mike
for
writing
that
and
thank
you
for
all
the
feedback.
That's
already
come
on
the
mailing
list.
Please
keep
it
up.
O
Okay,
so
hello,
everyone,
I'm
joran,
salander,
I'm
going
to
talk
about
this
really
short
draft
who's
been
updated
today
on
standing
here,
the
entire
integers
next
slide.
Please.
O
So
the
cosec
parameter
kid.
The
identifier
is
currently
restricted
to
byte
strings
and
c
board
by
strings
are
typically
two
bytes
or
more,
except
for
the
empty
byte
string,
which
is
a
very
special
identifier,
and
in
order
to
allow
more
one-byte
identifiers,
we
propose
to
extend
the
kid
value
type
to
int,
seaborg
hints,
which
have
the
order
of
50
and
one
byte
identifiers.
O
So
that's
that's
the
proposal,
it's
a
short
draft
they're,
essentially
updating
three
registries
and
that's
a
little
shoppie.
Can
you
hear
me
now?
O
Thank
you.
Okay
ben
had
some
problems
with
the
audio,
so
I
I
think
the
I
mean
this
is
the
last
slide.
I
think
the
proposal
is
fairly
clear
on
on
the
slide.
Ask
questions.
Otherwise
it's
basically
extending
the
value
type
for
for
kid.
For
the
currencies
of
kid,
we
had
a
discussion
about
pros
and
cons
for
making
this
a
separate
parameter
and
whether
this
was
really
needed,
and
I
think
the
conclusion
was
that
this
was
how
we
should
do
it
and
I'm
happy
to
have
any
comments
or
or
questions.
O
Okay,
there's
a
couple
of
people
who
have
choppy
audio
here.
I
don't
know
if
there's
anything
that
needs
to
be
repeat
still
possible
to
understand.
Okay,
good.
A
A
I
just
want
to
make
sure
that
the
draft
talks
about
like
the
deployment
considerations
for
when
it
is
actually
safe
to
use
the
integer
form
of
it,
because
if
you
just
have
an
updated
sender
that
starts
sending
it
without
indication
that
the
recipient
will
be
able
to
do
something
useful
with
it.
You
will
get
a
lock
loss
of
interoperability.
O
Yeah,
that's
I
mean
that
that
type
of
consideration
isn't
currently
in
the
draft,
but
we
had
the
discussion
at
the
time
and
the
general
feeling.
If
I
understand,
if
I
remember
right,
but
that
since
this
is
c
boar
and
if
you
have
implemented
c
or
byte
string,
you
typically
have
implemented
zebra
in
as
well,
and
these
are
typed-
I
mean
zebra
has
a
built-in
type
typing,
so
you
would
typically,
of
course
you
would
notice
that
there
there
is
an
error
here.
O
If
you
expect
the
byte
string
and
you
get
an
in
but
but
you
wouldn't
sort
of
it
wouldn't
result
in
any
that
you
would
get
sort
of
the
wrong
type
of
value.
You
would
get
the
wrong.
You
expect
a
certain
string
and
you
get
some
get
an
integer.
Instead.
O
A
Okay,
yeah,
I
mean,
I
think
that
having
some
text
in
the
document
will
be
good.
Eventually,
you
know
by
the
time
we
get
later
on
into
the
process.
B
I
I've
been
waiting
to
the
end
I'll,
I'm
not
speaking
as
a
chair.
B
B
All
right
is
there
anything
else,
you'd
like
to
say
karen.
B
Thank
you,
okay.
Thank
you.
We
unexpectedly
have
five
minutes
of
time,
which
I
will
now
have
open
mic
time
on
any
koze
related
topic
join
the
queue
ben.
You
were
in
the
queue.
A
Yeah
I
had
taken
some
notes
locally
about
the
point
compression
presentation,
but
I
didn't
get
to
say
them
earlier,
so
I'll
go
back
to
that
now
about
the
optionality
of
it.
I
think
that
this
is
very
likely
to
be
something
we
would
want
to
only
be
optional.
I
think
the
arguments
about
making
it
required
being
potentially
problematic
carry
a
lot
of
weight
to
me.
The
other
topic
that
comes
up
is
about,
like
the
relationship
of
the
point
format
to
the
curve,
and
so
like.
A
Currently,
we've
got
the
octet
key
pair,
which
is
used
by
like
the
x25509
and
whatnot,
the
cfrg
curves,
and
we've
got
the
ec2
point
format,
which
is
the
traditional
uncompressed
point
format,
that's
used
by
like
the
nist
curves,
and
so,
if
we
start
trying
to
bring
in
new
point
formats
that
are
using
compressed
points,
we
would
want
to
think
about
how
we're
gonna
signal
that
and
if
it's,
if
the
intention
is
to
be
able
to
use
both
ec2
and
this
new
compressed
point
format
on
the
same
existing
curves,
we
might
have
some
situations
where
it's
hard
to
get
interoperability
or
it's
very
complicated.
A
And
I
guess
I
will
yield
to
john
and
get
back
into
the
queue.
For
my
other
topic.
P
I
I'm
very
can
see
me
but
yeah.
I
hope
you
can
hear
me.
I
I
think
it
should
be
optional.
I
don't
know
exactly
what
was
discussed,
but
I
think
it
makes
sense
as
daniel
bentley
has
to
register
a
new
ayanna
code
point
or
compressed
format.
P
P
A
B
B
Seeing
it
that
the
queue
is
empty,
I'm
going
to
make
a
personal
statement
thanking
ben
for
serving
as
a
security
area
director
for
us
and
many
other
working
groups.
And
it's
been
a
pleasure
working
with
you
and
if
people
agree
with
me.
Maybe
congratulate
him
in
the
chat
and
thank
him.