►
From YouTube: IETF114 COSE 20220726 1730
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
So
welcome
to
jose
we'll
give
people
just
a
couple
minutes,
but
for
instance,
maybe
we
can
look
at
the
notewell
slide
while
we're
waiting.
B
A
B
B
B
B
B
B
It
changed
a
bit
since
the
original
upload
on
data
tracker,
so
I
made
that
visible
here.
Is
there
any
bashing
of
our
agenda.
B
I'll
take
that
as
a
no,
then
we
can
start
with
the
document
status
so
and
we
have
the
following
documents
that
are
passed
working
group
last
call
the
first
one
is
the
hash
algorithms.
As
far
as
I'm
aware,
there
are
no
pending
changes
or
no
pending
action
items.
It's
just
waiting
for
the
other
documents
in
the
cluster
to
be
ready
before
getting
published
and
then
for
the
auth
48
documents.
B
We
have
a
few
iterations
done
recently.
I
believe
all
the
comments
that
were
raised
were
handled.
I
know
some
participants
wanted
to
do
one
final
pass
through
the
documents,
but
other
than
that
they
should
be
good
to
go.
B
B
C
Paul
voters
80-
I
just
wanted
to
let
you
know
that
I
I'm
I'm
new
at
the
ad
role.
This
is
my
first
full-time
itaf
at
the
sd.
That's
the
ad
and
about
half
the
people.
Who've
approached
me
so
far
are
approaching
me
about
this
cluster
of
four
documents
that
are
waiting
for
a
very,
very
long
time
and
sort
of
ping-ponging
between
karsten,
ben
and
and
the
rfc
editor.
C
We
really
need
to
get
this
out
so
so
so
I
don't
know
what
I
can
do
anymore,
because
I
already
sort
of
tried
to
give
you
deadlines
to
get
this
cluster
out,
because
there's
really
a
lot
of
people
both
inside
the
idf
and
outside
the
iitf
waiting
on
these
documents
to
get
our
synonyms
to
god.
So
I'm
thinking
of
in
about
two
weeks
to
just
push
the
button
to
the
rc
editor
to
say,
publish
this.
I
don't
care
anymore.
D
Yes,
sorry,
I
was
a
couple
minutes
late
late
joining,
but
I
wanted
to
be
here
to
be
able
to
speak
to
this
topic,
and
so
I
did
send
some
updates
to
the
rc
editor
based
on
essentially
a
full
review
of
the
text,
and
I
looked
over
the
resulting
diffs
and
they're
they're.
Basically
good
karsten
spotted
a
duplicate
word.
D
D
So
I
think
the
only
other
point
I
want
to
add
is
for
paul
and
just
to
check
basically
that
some
of
the
changes
that
were
made
in
auth48
were
of
this
heart.
That
would
require
ad
approval
as
potential
content
changes.
Basically,
and
so,
if
you
could
also
take
those
two
weeks
to
confirm
that
you've
looked
those
over
and
you
don't
have
any
concerns
that
you
want
to
push
back
on.
That
would
be
helpful
to
make
sure
we
can
actually
publish
at
the
end
of
the
two
weeks.
D
And
I'll
thank
kirsten
again
for
his
help
and
looking
over
many
aspects
of
it.
A
Yeah,
thank
you
ben
and
karsten
for
your
diligence
as
well
as
evo.
In
moving
this
forward.
I
see
marco
in
the
queue.
E
Yeah
hi,
this
is
marco.
Just
a
comment
on
the
counter
sign
document.
Please
just
a
comment
on
the
counter
sign
document.
I
noticed
the
latest
revision
in
section.
Three
refers
a
course
document
and
the
specific
reference
got
changed
compared
to
the
previous
version
yeah.
I
believe
the
previously
referred
document
is
more
appropriate
because
that's
where
the
actual
counter
signing
happens,
I
was
just
double
checking
this
morning
with
the
security.
Ids
looks
like
the
case
I'll
send
out
the
mail
to
the
last
call
thread.
Also.
F
This
test,
okay,
cool,
so
russ,
and
I
will
briefly
talk
about
two
issues
in
the
cozy
hb
key
document.
F
As
you
know,
and
there's
the
hp
key
document
was
was
published
as
an
rfc
coming
out
of
the
irdf,
and
this
document
describes
on
how
to
accomplish
the
functionality
of
hbke
with
the
cosy
structures
next
slide.
So
we
are
version
two
of
the
document
if
you've
been
following
the
mailing
list,
you've
seen
a
lot
of
exchanges
back
and
forth
between
hillary
and
myself.
Thank
you,
larry
for
all
the
the
reviews.
F
I
there
are
two
aspects
that
are
worthwhile
your
time
here.
This
is
the
first
one
which
I
would
like
to
cover
is
we
need
to
have
an
agreement
on
the
format
of
the
public
key
encoding,
the
ephemera
public,
key
encoding
that
is
sort
of
included
in
the
encryption.
F
F
I
think
discussion
wise.
We
got
a
little
bit
stuck
between
hillary
and
myself
on
what
the
right
format
would
be
and
that's
why
we
are
seeking
out
to
get
feedback
from
you
on
the
on
your
right
hand,
side.
So
the
public
key,
the
nist
b256
r1
curve
in
cosi,
is
described
in
the
following
way.
So
you
see
the
key
type
which
is
set
to
this
value.
Ec2,
obviously
there's
a
key
id
in
there
or
not.
F
Obviously,
but
there
is
a
key
id
in
there
there
or
potentially
then
there's
a
curve
indication,
because
obviously
there
are
different
curves
and
then
there's
the
encoding
of
the
x
y
value,
and
there
may
be
a
compressed
encoding
of
the
point
depending
on
how
you
set
the
y
coordinate.
Okay,
that's
also,
basically
taking
from
the
cosy
rfc.
That's
not
my
invention.
F
Hillary
proposes
a
slightly
different
format,
so
he
would
like
to
use
a
different
key
and
key
format,
and
this
is
the
octet
key
pair.
If
we
remember
that
correctly,
key
id
is
the
same
so
uncontroversial.
F
He
wants
to
use
a
new
value
for
the
hp
key,
so
it's
just
temporarily
assigned
to
that
specific
number,
and
then
he
basically
takes
the
output
of
the
hp
key
algorithm
that
produces
this
ephemera
public
key
and
dumps
it
into
this.
A
F
Yeah-
and
I
think
that's
where
hillary
and
myself
sort
of
divert
in
in
the
views.
F
His
opinion
is,
if
I
correctly
reflect
it,
and
maybe
he's
online-
is
that
he
wants
to
basically
use
hp,
an
hb
key
library
to
export
what
comes
out
of
it
and
then
dump
it
straight
into
this
field
in
the
last
field
shown
on
the
screen
without
further
sort
of
post-processing.
So
to
speak.
I
think
that's
that's
one
argument,
but
maybe
some
of
you
guys
have
some
additional
input
or
different
perspective.
G
Yes,
thanks
mike
perrock
here,
one
of
the
things
that
concerns
me
in
looking
at
the
kty
discussion,
both
on
jose
and
kosay,
is
potentially
overloading
octet
key
pair
and
especially
crv,
to
apply
to
things
for
which
crv
either
doesn't
apply
or
isn't
fully
described
by
a
single
parameter.
G
I
am
strongly
in
favor
of
the
proposal
on
the
right
from
the
screen
size,
which
I
believe
is
yours,
honest
as
far
as
kty
ec2
in
this
case
with
xy
coordinates
because
it
completely
describes
what
the
actual
key
type
by
family
right
as
defined
in
the
rfc,
is
as
well
as
how
do
you
actually
reference
that
from
a
curve
perspective?
In
this
case,
we've
run
into
similar
issues
from
a
post
standpoint
where
we're
getting
into
families
of
algorithms,
also
that
don't
have
curves
or
other
things
like
that
right.
G
That
are
novel
constructions,
for
which
we
need
an
answer
to
this,
and
so
I
think,
by
going
in
ec2
kty
type
here
we're
setting
that
direction
as
a
group
as
to
a
good
path
forward,
so
that
we're
not
overloading
and
encouraging
implementers
to
make
mistakes
as
far
as
selection
of
algorithms.
So
that's
all.
Thank
you.
A
I'll
make
a
meta
point:
those
of
you
who
want
to
join
the
queue
should
actually
join
it
online
I'll,
nonetheless
recognize
tobias,
but
the
next
time
please
join
the
queue
so
that
we're
fair
to
the
online
participants.
H
Okay,
thanks
yeah
I'd
much
the
same
as
the
sentiment
express
before
I.
I
think
we
already
have
a
key
representation
format
for
p
256
keys.
This
is
really
just
embedding
it
in
a
high
level
application,
so
the
p256
public,
key
representation
with
ec2
makes
more
sense,
because
the
the
octet
key
peer
representation
here
as
well
tends
to
sort
of
stretch
the
notion
of
the
curve
field
with
a
custom
tag
too,
to
kind
of
layer
on
a
higher
level,
algorithmic
sort
of
representation
which
is
hpke
and
kind
of
conflate
the
application.
A
I
F
I
think
well,
I
was
like
huge
dutch
consensus.
A
C
So
sorry
balance
80.,
whether
or
not
you
do
a
hum.
I
don't
think
really
changes
march
anymore
right
because
you
still
have
to
go
to
the
list
to
confirm
it
anyway,
and
I
think
sure
you
know
the
humming
here
is
already
pretty
much
in
favor
of
the
proposal
on
the
right
from
what
I
can
see.
So
I
mean
you're
free
to
hum,
but
you
would
still
have
to
go
to
the
mailing
list
anyway.
So
I
don't
think
it
matters
in
this
case.
D
J
D
Guess
this
is
maybe
a
clarifying
question,
but
larry's
proposal
had
the
he
did
as
a
65
byte
string,
which,
in
my
understanding,
has
a
clear
decomposition
into
x
and
y
coordinate,
and
so
that
would
tend
to
if
that's
correct,
that
would
tend
to
lead
me
to
also
prefer
the
the
right-hand
side
proposal
using
ec2
keys,
and
the
only
reason
I
can
think
of
that
would
strongly
make
me
prefer.
Lr's
proposal
would
be
if
there
was
some
ambiguity
or
difficulty
in
actually
converting
the
representation
away
from
from
that
proposed
representation.
K
So
ben
this
is
russ.
My
understanding
is
he's
just
using
the
exact
hpke
algorithm,
that's
in
the
rfc
and
taking
the
dump
of
that
straight
from
the
library.
A
Okay
to
close
this
out
eva,
do
you
agree
with
me
that
the
chairs
should
send
a
note
to
the
list
saying
the
consensus
in
the
room
appeared
to
be
to
use
the
standard
representation
and
asking,
if
there's
any
discussion
on
that
yeah
just.
K
A
K
So
one
of
the
places
that
the
this
draft
is
being
used
is
in
the
suit
working
group,
where
we
have
encryption
of
firmware,
that's
being
loaded
onto
iot
devices,
and
so
the
encryption
has
to
be
done
in
conjunction
with
the
bootloader
and
the
the
thing
that
is
going
on
is
the
firmware
signed
and
encrypted.
K
So
we
don't
really
need
an
aead,
because
the
signature
provides
the
integrity
and
the
way
that
some
small
devices
manage
their
memory,
such
as
flash
blocks.
They
want
to
be
able
to
encrypt
chunks
of
it
that
match
the
size
of
the
flash
blocks
so
that
the
bootstrap
loader
and
the
encryption
can
be
easily
tied
together.
K
So
in
those
cases,
counter
mode
or
cbc
are
much
better
aligned
with
that,
but
cos
a
encrypt
demands
an
aead,
and
so
we
think
we
should
register
some
non-aedi
algorithms
with
big
notes
in
the
registry.
K
That
says,
you
know
only
use
this
if
the
data
is
already
integrity
protected
in
some
other
way
or
the
approach
we
do
not
recommend
is
we
define
some
cosa
encrypt
light
and
that
seems
like
way
more
work
to
not
be
an
aed,
as
opposed
to
a
note
in
the
registry,
so
we're
advocating
hanus
and
I
are
advocating
the
register
of
the
non-aed
aead
algorithms
with
appropriate
notes
and
we're
willing
to
write.
They
are
the
internet
draft.
If
the
group
agrees
that
that's
a
reasonable
way
forward,
we'd
like
to
hear
from
you.
L
I
thanks
I'm
wondering
if
you
could
reinforce
the
settlement
by
saying
that
integrity
protection
should
be
guaranteed
before.
Can
you
get?
Thank
you
sorry.
Yes,
can
we
ask
for
that?
The
integrity
protection
be
guaranteed
before
decryption,
rather
than
separately
from
encryption
to
prevent
attacks
on
unauthenticated
decryptions
that
are
still
possible
in
principle,.
L
So
you
could
authenticate
after
decryption
or
by
your
signature
independently.
I
think
asking
for
the
signature
to
be
checked
before
the
description
occurs.
It
will
be
structurally
more
secure,
and
so,
if
you
can
renounce
the
text
right
where
you're
authentication
by
signature
default
description,
that
would
be
stronger
than
separate.
L
J
Hi
jonathan
hamill
canadian
security
chain
center
for
cyber
security,
just
a
clarifying
question
you
mentioned
about
notes,
guidance
on
use
of
these
additional
registry
items.
Where
would
that
be
put
in
the
registry
itself?
I'm
not
aware
of
a
there's
a
description
column,
but
where
would
that
appear.
K
Yeah
we'd
we'd
have
to
in
the
iana
considerations,
ask
guyana
to
add
a
place
to
put
it.
Thank
you.
M
John
matson,
I
I
support,
registering
encryption
without
integrity.
This
has
popped
up
in
other
places
as
well,
for
example,
group
or
scoring.
I
think
there
was
some
web
discussion
here
where
it
was
needed.
I
think
in
general
the
default
recommendation
is
strongly
to
use
aad
unless
you
know
what
you're
doing
and
yeah.
So
I
strongly
support
you.
K
A
I
A
N
Great,
it
is
not
practical
to
require
a
integrity,
verification
prior
to
decryption
in
a
firmware
update
scenario.
The
reason
for
this
is
that
a
device
that
is
fetching
an
encrypted
firmware
may
require
that
it
fetches
a
block
decrypts
it
in
place
and
then
writes
it
to
flash.
Otherwise,
if
you
don't
follow
this
procedure,
you're
doubling
the
flash
cycles
and
you're
risking
the
survival
of
the
device
when
you
have
to
do
an
in-place
decryption
later,
because
that
requires
additional
journaling
on
top
of
what
you
already
might
be
doing.
K
So
brandon,
I
think,
you're
talking
about
the
potential
for
burning
out
the
flash
cells
with
too
many
rights.
Is
that
your
point.
N
It's
not
just
when
you
said
damage
device;
it
is
that
that's
that's
only
part
of
the
story,
though
it's
also
the
energy
required
to
write
to
the
flash.
So
so,
there's
multiple
aspects
here.
D
So
I
was
doing
a
quick
read
through
the
8152
is
struck
and
while
we
do
only
talk
about
authenticated
encryption
modes,
I
didn't
find
anything
that
specifically
says
you
must
have
authenticated
encryption.
So
I
think
that
would
tend
to
support
registering
the
algorithms.
But
I
would
add
to
that
that
you
really
ought
to
include
a
section
in
the
document.
That's
like
how
to
encrypt
for
non-authenticated
encryption
modes
or
whatnot.
K
D
D
Data
just
to
solidify
my
point
to
russ:
we've
got
a
section
heading,
that's
like
how
to
encrypt
and
decrypt
for
aead
algorithms,
that's
currently
in
in
the
struct,
and
just
do
the
analogous
thing
for
that.
When
you
do
this
right,
okay,.
O
As
as
I
recall,
when
we
were
doing
jose,
we
made
the
explicit
decision
not
to
have
non-aead
encryption
to
event
attempt
to
prevent
people
from
shooting
themselves
in
the
foot.
That's
correct,
so
it
would
be
possible
to
have
a
define,
a
composite
algorithm
that
did
as
was
originally
suggested
encrypted
and
then
signed.
That
would
be
one
possibility,
I'm
I
am
sensitive
to
the
constraints
for
software
updates.
I
don't
know
that.
O
There's
a
perfect
solution
for
this,
but
it
that
is
a
pretty
special
purpose
use
case
and
we
have
to
balance
the
the
overall
good
for
of
you
know,
making
this
exception
for
cos
a
versus.
You
know
how
many
people
are
going
to
use
it
inappropriately
because
they
they're
not
reading
the
registry
versus
the
utility
of
of
having
it
as
part
of
jose.
So
I
don't
know
I
wouldn't
rush
necessarily
rush
into
making
a
general
exception
for
jose
to
have
non-aead
bulk
encryption.
K
A
So
it
would
be
my
suggestion,
russ
to
write
the
draft
and,
as
I
told
you
previously,
there
is
a
precedent
for
registering
cose
algorithms
as
deprecated
from
the
get-go
we
registered
rsa
sha-1.
I
personally
did
because
it's
in
tpm
1
and
is
used
as
deprecated,
because
we're
trying
to
get
rid
of
show
one.
But
it's
there
in
practice,
and
I
view
this
as
somewhat
analogous
I'm
not
promising.
The
working
group
will
adopt
the
draft,
but
I
think
the
next
step
is
to
write
the
draft
and
make
the
case
all.
K
M
M
M
There's
also
been
a
lot.
Several
people
expressing
interest,
derek
atkins
and
manisha
malik
has
requested
c
code
implementations
on
either
the
mailing
list
or
on
github.
M
Armando
garcia
from
franhofer
has
announced
that
he's
soon
ready
with
his
c
implementation,
and
this
is
great
news
it
has
been
requested.
I
think
also
more
implementations
of
the
c5
serum
9
is
a
good
step
to
move.
This
forward
also
comments
from
kerry
bonnell
from
ddesert
that
suggested
a
change
in
the
general
subtree
thing
and
also
suggested
some
improvements
to
the
document
structure
to
place
things
in
subsection
to
align
with
rfc
52
80
seems
also
very
good
suggestions.
M
M
A
H
Okay,
thanks
next
slide,
so
so
just
a
bit
of
context.
This
was
recently
adopted
by
the
working
group
and
this
draft
registers
the
required
parameters
for
both
the
jwk
and
cosa
key
cryptographic,
key
representations
for
the
what's
known
as
the
beretta
lynn,
scott
bls,
family
of
curves,
both
the
12
381
and
4
48
581
variations.
H
Just
a
quick
note
about
the
the
bls
curves
they're
said
to
be
pairing
friendly,
which
enables
some
novel
algorithms
beyond,
namely
digital
signature,
algorithms,
beyond
standard
or
conventional
digital
signatures,
and
the
bls
family
are
the
most
popular
in
use.
Today,
the
only
others
that
are
notable
the
bearing
nedo
curves,
however,
bls
are
favored
in
most
applications
and
there
is
a
formal
definition
of
the
bls
curves
as
a
work
item
at
cfrg
as
well
for
context
next
slide.
H
So
just
a
quick
note
on
a
couple
of
different
algorithms
that
this
uses,
one
is
an
aggregate
signature
scheme
which
enables
aggregating
signatures
of
the
same
payload
together
whether
it's
same
result
can
be
checked
against
the
individual
sinus
keys.
This
is
useful
in
multiple
applications,
most
notably
in
blockchain
applications.
It's
already
in
use
and
and
networks
like
ethereum
and
file
coin,
and
the
signature
scheme
itself
is
also
a
item
of
the
cfrg.
H
Another
scheme
example
for
these
key
representations
is
a
scheme
known
as
bbs
signatures,
which
have
we
proposed
to
the
cfrg
this
week
as
a
work
item
and
most
notably,
that
scheme
supports
several
different
novel
properties,
such
as
selective
disclosure,
proof
of
possession
and
unlinkable
proofs,
so
yep
next
slide,
and
that
that's
this
is
really
just
informational
context
for
the
algorithmic
usages
and
of
this
scheme.
H
So
I
actually
think
that
the
last
couple
of
slides
were
just
really
inform
informational,
so
we
can
probably
skip
let's
get
past
this
really
the
the
updates
for
for
this
draft
at
this
stage
with
bls
key
representation,
we
can
probably
just
flick
through
these
things-
is
that
the
the
key
key
parameters
have
essentially
been
defined
in
the
draft.
H
The
only
outstanding
item
that
that
I
have
on
my
list
is
to
produce
some
samples
for
these
key
representations
in
both
kosaki
and
jw
key
as
informational,
so
yeah.
Any
comments
on
that
draft.
H
Okay,
this
is
a
this.
Is
another
draft,
so
next
slide.
Thank
you
so
so
the
rationale
for
this
is
that
jason
webb
tokens,
which
is
obviously
a
related
predecessor
to
cebu
webb
tokens,
included
normative
texts
that
permitted
you
being
able
to
put
jwt
claims
in
the
protected
heater.
H
However,
when
cwt
was
standardized
it,
it
didn't
really
define
the
equivalent
behavior
and
and
this
draft
sort
of
rectifies
or
creates
a
mechanism
to
do
the
equivalent
in
cwt
and
in
general,
being
able
to
put
cwt
claims
in
the
header
of
kosovo.
Structures
has
a
has
a
couple
of
possible
useful
applications
next
slide.
Please.
H
So
one
of
them
is
encrypted
cwts
in
some
scenarios,
when,
when
you're
encrypting,
say
cwt,
there's
a
desire
to
have
some
of
the
claims
that
are
also
going
to
be
present
in
the
payload
replicated
into
the
unencrypted
header.
You
know
this
includes
things
like
the
iss
claim
or
token
validity
information
they
might
facilitate
in
the
decryption
process.
H
Next
another
use
case
we've
found
as
well
is
is
when
you're
using
a
kose
sign
structure,
that's
featuring
a
detached
payload,
so
the
payload
may
not
in
fact
be
a
cwt
and
it
may
not
actually
be
in
this
in
the
structure
being
able
to
use
standard.
Cwt
claims
in
the
cose
header
of
the
of
the
structure
just
means
that
you're
not
re-redefining
claims
that
are
equivalent
to
cwt
claims
for
bespoke
purposes.
H
So
again,
we've
found
applications
where
we
are
producing
content,
signing
signing
a
signature
over
a
detached
piece
of
content,
and
we
want
to
be
able
to
describe
who
the
signer
is,
and
maybe
some
validity
information
over
that
signature
over
that
payload,
which
isn't
a
cwt
itself
like
a
cwt
structure,
so
being
able
to
put
information
like
who
the
signer
is
and
typing
validity.
Information
in
the
header
again
is
beneficial
there
and
last
one.
Thank
you,
and
so
just
one
key
design
consideration
to
sort
of
call
out
here.
H
The
cwt
claims,
namespace
and
cosa
heater
parameters
are
distinct
registries.
They
have
distinct
numeric
allocations
for
their
claims.
That
pre-exist,
therefore,
we
can't
merge
them
like,
as,
as
is
the
case
in
jwt,
where
you
can
simply
put
iss
directly
in
the
header,
so
this
draft
essentially
intends
it
as,
as
is
registering
a
new
header
parameter,
whose
value
essentially
is
a
map
or
structure
that
contains
the
cwt
claims
inside
it.
H
So
with
that,
that's
it's
main
only
the
description,
any
any
questions
on
that.
H
Yeah,
so
the
the
only
outstanding
question
that
I
think
we
had,
we
had
some
feedback
on
on
the
list
briefly
about
whether
or
not
to
include
a
sample
cddl
within
the
draft
to
make
it
clearer
exactly
how
it's
essentially,
how
it
is
represented
within
a
coza
header.
B
Ken
then
michael.
G
Yeah
just
wanted
to
say
thank
you
for
the
work
on
this
tobias.
This
is
extremely
useful,
especially
downstream
and
other
work
items
as
a
co-chair
at
community
credentials.
Group,
for
instance.
I
know
there
are
multiple
drafts
kind
of
in
process
that
will
leverage
these
kinds
of
techniques
to
kind
of
provide,
a
pathway
into
more
binary
representations
of
some
of
these
items
and
that's
critical
for
high
volume
traffic,
especially
in
cyber
physical
supply
chains,
where
data
still
needs
to
be
verified,
so
very
supportive
of
the
work
very
much.
P
Yeah,
I
think
it's
a
good
idea
to
be
able
to
to
transport
cwt
claims
with
any
cosy
structure.
The
the
one
thing
I'm
not
too
sure
about
is
that
I
understand
what
that
specifically
means.
P
So
if,
if
you
have
a
cwt
in
there
and
are
putting
a
few
more
claims
on
the
outside,
then
it's
pretty
clear
to
me
what
what
the
the
the
combination
of
those
claims
would
mean,
at
least
if
they
don't
conflict
with
each
other.
But
if
you
just
take
a
random
cozy
design
data
structure
and
and
slap
a
few
cwd
headers
on
top
of
that,
that
may
not
have
a
very
well-defined
meaning.
P
P
So
that's
maybe
a
direction
that
we
should
look
at,
come
up
with
a
few
examples
and
and
explain
what
putting
the
the
data
actually
means.
The
other
question
you
had
is:
should
you
put
cddl
there,
and
the
answer
of
course
is
yes,.
H
So
sorry,
just
so,
I
can
clarify
carsten
so
so
in
particular,
your
question
is
around
the
usage
of
of
the
parameter
in
say
the
detached
payload
case,
where
the
the
overall
structure
itself
is
is
perhaps
not
it's
not
actually
a
cwt,
but
using
that
heater
you're
saying
would
be
misleading.
H
P
H
Right
I
just
just
to
clarify,
though
my
observation
is,
is
if
you
register
this
as
a
general
purpose
claim
where
cwt
claims
can
go,
applications
would
be
free
to
use
that
and
even
structures
that
are
using
detached
payloads
right.
P
A
Q
Yes,
yes,
please,
okay,
yeah!
So
we
we
know.
Cwt
is
cwt.
If
it's
a
c,
if
it's
a
cwt,
officially
it's
used
for
authentication
and
it
has
the
authentication
semantics
like
shaking
his
head.
No,
so
we
we
there
so
there's
a
draft
for
content
types
for
eat
and
you
know,
as
we
know,
eat
uses
cwt.
Q
So
there's
you
know
we're
trying
to
work
through
that
there.
So
I
guess
you
know,
I'm
not
saying
I
have
a
the
exact
answer
here,
but
it
seems
like
it
is
related
to
the
content
type.
That
might
be.
You
know
in
the
the
cose
header
or
in
the
surrounding
mime
identifier
or
in
the
tag
identifying
some
tags
around
it.
So
it
seems
like
it
might
be
related
to
that.
H
R
Hello,
can
you
hear
me:
is
it
good
all
right,
so
it's
my
first
time
presenting
at
ietf,
so
apologies
for
any
missteps,
as
we
get
through
this
so
today,
I'll
be
talking
about
some
work
that
we've
done
to
attempt
to
represent
some
of
the
key
and
signature
proposals
that
are
coming
out
that
are
post
quantum
resistant.
R
So
what's
the
deal
with
post
quantum
cryptography,
hopefully
you've
been
reading
the
news.
Lately,
there's
been
some
announcements
about
it.
Why
do
we?
Why
do
we
need
post
quantum
resistance
in
in
some
of
these
cryptographic
constructions
for
digital
signatures
or
key
agreement,
and
there's
a
long
answer
to
that
which
I
encourage
you
to
to
read
on
your
own,
but
essentially
shores?
Algorithms
is
involved
in
a
number
of
the
the
answers
to
specific
questions
on
that
front.
R
So
why
are
we
here
at
the
at
cozy
to
talk
about
this?
Essentially,
what
we
would
like
to
do
is
to
support
an
upgrade
path
for
folks
who've
been
using
cozy
and
hosey
representations
with
you
know:
pre-quantum
algorithms,
for
these
post-quantum
algorithms.
So
we
want
to
give
developers
a
sort
of
familiar
path
to
upgrade
where
things
kind
of
look
the
same.
But
now
they've
got
some
coverage
for
some
of
these
post-quantum
attacks.
R
So
what
algorithms?
And
why,
as
I
mentioned
before,
this
is
mostly
focused
on
key
and
signature
algorithms
right,
so
key
representations
for
post-quantum
schemes
and
signature
representations
for
post-quantum
schemes,
and
I
want
to
be
very
clear,
like
we're
here,
to
propose
the
envelope
formats,
the
serializations,
for
these,
not
the
fundamental
cryptography
that
would
be
more
appropriate
at
the
cfrg
and
the
works
already
underway.
R
So
specific
constructs
that
we're
looking
at
this
there's.
Basically,
your
two
two
main
families,
the
lattice
approaches
with
all
of
the
wonderful
drama
that
comes
along
with
them
and
the
hash
systems,
and
so
we're
hoping
to
register
representations
for
both
of
these,
so
that
we
don't
just
register
one
family
that
might
all
of
a
sudden
suffer
from
a
particular
attack.
You
know
say
on
lattices
if
we
only
looked
at
registering
lattices
and
there
was
a
you
know-
critical
break,
you
know
and
attacking
lattices-
that
wouldn't
be
great.
R
So
if
we
let
register
lattices
and
hashes
together,
we
get
a
little
bit
of
a
better
defense
and
at
the
bottom
you
know
like,
as
I
said
at
the
beginning,
the
biggest
announcement
is
nist
has
finally
announced
the
candidates
for
standardization
and
there's
been
a
call
for
additional
algorithms,
additional
signature,
algorithms
as
well,
so
keep
your
eye
on
on
those
announcements
from
nist
and
that's
a
major
reason.
Why
we're
here
to
talk
about
it
today
next
slide,
please.
B
N
Just
a
clarifying
question
you've
said
here
that
it's
key
representations
that
you're
looking
at
signature
and
key
representations.
Do
you
mean
signatures
and
key
exchange
algorithms,
or
are
you
looking
at
encapsulating
keys
so
we're.
R
G
Yeah
this
is
mike
perrock,
I'm
one
of
the
authors
on
the
spec,
so
brenden
yeah,
just
clarification,
we're
avoiding
any
of
the
key
encapsulation
stuff
right
now
we
have
focused
100
on
the
three
signature:
algorithms,
based
on
three
different
classes
of
problems,
so
we
have
dilithium
representing
learning
with
errors,
type
problems.
G
You
know
falcon
coming
more
out
of
the
entrue
side
of
the
world
and
then
coming
in
also
with
us
thanks
for
the
hash
side,
but
we've
avoided
it
for
a
variety
of
reasons,
any
of
the
actual
key
encapsulation
exchange
stuff
for
the
time
being.
That
is
a
topic
that
will
come
up
later,
but
we'll
have
to
wait
on
cfrg
actions
and
some
other
items
that
we're
involved
in
so
okay.
D
And
kate
here,
so
I
think
I
just
want
to
solidify
the
previous
questions
so
like
you're
looking
at
the
key
representation,
so
you
can
like
publish
the
public
key
that
was
used
to
make
the
signature.
M
Yeah
john
erickson,
I
think
cozy,
should
definitely
standardize
everything.
I
think
we
should
limit
us
to
what
in
this
standardize
it,
but
I
don't
think
we
should
make
sure
that
this
it's
not
published
before
nist
has
published
the
final
standards
they
might
change.
We,
I
don't
think
we
want
the
situation
where
somebody
starts
implementing
and
then
we
are
there.
M
There
are
discussions
right
now
under
this
email
list
on
exactly
what
what
kind
of
algorith
symmetric
algorithm
to
use,
at
least
in
the
key
exchange
waiting
with
key
exchange,
seems
good
because
it
might
rely
on
hpk
for
that.
G
G
One
of
the
important
things,
though,
to
get
the
draft
out
early
and
you
know
being
refined,
is
the
fact
that
there
are
federal
executive
orders
here
in
the
us
that
are
forcing
us
to
identify
a
path
for
interoperability
and
crypto
agility.
So
if
we're
not
doing
that
in
a
standardized
way,
we
will
wind
up
in
trouble
where
one
agency
is
attempting
to
do
something
one
way:
private
sector,
another
another
vendor
in
private
sector.
G
Another
way,
and
so
we
won't
be
able
to
actually
see
how
this
stuff
works
in
practice
when
we're
working
on
a
hard
timeline.
So
it's
a
little
bit
of
a
nuanced
situation
compared
to
normal,
but
fully
agree
until
we
actually
hit
final
standardization
and
can
lock
in
the
parameter
sets
for
each
of
these
algorithms.
We
should
not
attempt
to
finalize
and
publish.
A
I'll
make
a
clarifying
point
about
itf
process,
which
is
pertinent
to
this,
which
is
it's
possible
and
often
normal
to
get
a
draft
to
essentially
final
status,
even
to
the
point
of
it
being
in
the
rfc,
editor
queue,
but
it
to
be
held
there
until
the
normative
dependencies
that
it
takes,
such
as
the
algorithm
definitions
themselves
are
final,
so
I
mean
our
area.
Director
could
also
confirm
this,
but
I
would
encourage
you
to
work
in
parallel
with
nist
and
the
cfrg
so
that
we
can
all
land
at
the
same
time,.
C
Pop
out
is
80.
so
yeah.
I
I
encourage
you
to
to
join
the
the
the
pqc
list
that
we
just
created,
because
this
is
coming
up
in
multiple
different
working
groups
and
so
on
one
hand
we
want
to
avoid,
like
everybody
doing
their
own
thing
and
coming
up
with
something
different.
We
want
like
people
to
learn
from
each
other
and
and
move
forward
in
a
somewhat
more
structured
way
and
see.
If
we
can,
we
can
like
de-duplicate
some
of
the
work.
G
Yes-
and
we
are
already
on
that
list
and
actually
are
making
sure
that
we
have
co-editors
on
this-
for
instance,
michael
osborne
and
christine,
who
are
working
on
some
of
the
kind
of
lower
level
representations
of
some
of
these
keys,
so
that
we
have
good
overlap
between
the
authors
and
editors,
etcetera
that
are
working
on
this.
A
R
I
think
this
is
my
last
one
yep,
so
I
think
we've
gotten
into
a
bunch
of
the
specifics
already,
but
just
to
sort
of
highlight
the
nist
announcements,
a
sphinx
plus
that's
the
hash,
based
system
falcon
and
dilithium,
two
lattice-based
systems
that
are
included
in
that
announcement.
R
As
I
mentioned
before,
you
know,
we
want
to
see
an
intuitive
upgrade
path
for
these
post-quantum
schemes.
In
some
cases
there
might
be
folks
who
are
jumping.
You
know
from
staying
in
rsa
for
a
very
long
time
to
some
of
these
newer
systems.
If
we
have
an
encoding
representation
that
can
support
them.
R
R
Another
sort
of
key
goal
here
is,
as
we
mentioned
these
envelope
formats-
and
we
were
talking
about-
you-
know
kty
and
crv,
and
these
other
key
representation
components
registering
you
know
two
new
families
of
cryptosystem.
R
At
the
same
time,
really
forces
us
to
re-evaluate
or
clarify
how
the
existing
term
definitions
for
kty-
and
you
know,
crv
these
other
key
represent
key
representation
terms
are
to
be
used,
and
so
this
is
a
great
time
for
us
to
provide
better
guidance
on
clarity
on
some
of
the
the
questions
that
were
raised
before
in
the
hpk
talk
and
again,
you
know
in
the
draft
we're
going
to
be
calling
for
reservations
for
some
of
these
key
and
signature.
M
John,
what
about
hybrid
systems
or
whatever
the
idf
choose
to
call
them
yeah?
I
think
nsa,
said
they
will
go
with
pqc
only
in
cnsa
2
does
here.
At
least
I
think
that
was
what
france
has
said,
that
they
will
enforce
hybrid
solutions
for
the
next
years.
Will
you
standardize?
I
didn't
see
that
in
the
draft
is
the
will.
You
is
the
solution
to
nestle
things,
or
will
you
suggest
some?
It
should
be
discussed
at
some
point.
Yeah.
R
Excellent
question:
there's
there's
been
some
discussion
about
that
already
and,
and
my
my
position
on
it
is.
We
should
be
clear
about
representations
for
post
quantum
schemes
before
we
talk
about
hybrid
schemes
combining
them.
So
I
I
see
this
as
a
necessary
step
towards
that
objective,
but
certainly
they
can
that
work
can
start
happening
in
parallel
as
well,
and
I
I
think
both
of
those
are
good
ideas
to
sort
of
proceed
with
just
specific
to
this
draft.
We're
only
focused
on
the
post,
quantum
key
representations
and
not
registering
approaches
for
hybrid
schemes.
G
Or
he's
going
to
put
me
on
the
spot,
but
I
would
say,
let's
just
being
time
conscious
since
we've
had
good
engagement
here,
can
we
flip
to
the
next
slide
here
really
for
us?
This
is
about
next
steps.
We've
gotten
things
up
to
101
draft
had
great
feedback
in
especially
from
some
of
the
authors
and
great
support
from
folks
who
are
working
on
the
core
signature.
G
G
Since
standardization
path
has
been
announced,
we
are
adding
in
good
detailed
examples
for
falcon
and
sphinx,
so
we
have
those
in
for
dilithium
already
we'll
now
be
doing
the
same
for
falcon
and
sphinx
and
that
moves
us
into
piles
and
piles
of
test
vectors,
which
I'm
of
course
going
to
try
to
hand
to
ori,
but
always
love
help
on
key
thing
for
us
is.
We
would
love
to
get
this
adopted
by
the
working
group.
There
are
a
lot
of
details
here.
G
There
are
a
lot
of
smart
people
in
the
working
group
and
in
the
room.
We
want
feedback
in,
because
this
is
going
to
impact
all
of
us.
So
that's
kind
of
the
next
key
step
that
we're
after
is
kind
of
moving
it.
You
know,
hopefully
from
a
place
where
we
can
begin
to
really
work
on
this
seriously
into
broader
work
with
the
working
group
itself.