►
From YouTube: IETF115-COSE-20221108-1500
Description
COSE meeting session at IETF115
2022/11/08 1500
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
Okay,
we
have
a
full
agenda,
we
are
going
to
start
on
time,
I'm
Mike
Jones,
my
co-chair
is
Evo
and
we
will
be
having
a
lot
of
good
because
I
had
discussions
today.
A
A
A
A
Wear
masks
unless
you're
speaking
at
a
microphone
and
if
you're
remote
make
sure
you're
microphone
is
off
unless
you're
actively
presenting.
Thank
you.
A
A
A
A
A
The
good
news
is
that
we
finished
a
bunch
of
rfcs
and
there's
two
more
about
to
be
finished
thanks
to
Paul
for
encouraging
us
and
for
those
who
did
the
work
for
getting
us
there.
It's
been
a
journey,
but
we
now
have
an
internet
standard
for
because
they
and
with
that
I,
am
going
to
switch
to
Russ.
B
B
So
the
the
topic
is
whether
we
should
support
a
couple
of
non-authenticated
encryption
algorithms.
We
proposed
this
at
the
last
ietf
put
together
a
draft.
B
The
suit
working
group
for
their
firmware
encryption
draft
is
using
it
and
just
last
month
the
this
working
group
adopted
the
draft
to
assign
to
code
points
next
slide,
basically,
code
points
for
counter
mode,
with
three
key
sizes
and
CBC
mode,
with
three
key
sizes,
all
marked
as
deprecated
in
the
Ayana
registry,
just
to
make
sure
that
people
don't
accidentally
use
this
them
when
they
think
they
are
getting
an
authenticated
mode.
The
document
tells
them
it
has
to
be
used
with
some
mechanism,
such
as
a
digital
signature,
in
order
to
provide
that
integrity.
B
Next
slide,
please,
last
week
or
the
week
before,
we
got
a
bunch
of
comments
about
the
things
that
can
go
wrong
when
you
don't
have
Authentication.
We
knew
these,
of
course,
but
we
did
address
these
specific
things.
Ian
proposed
security,
consideration
text
next
slide,
so
there's
basically
three
possible
ways
forward.
One
is
we
adopt
that
security
considerations
text
and
assign
those
code
points
it
was
observed
in
the
concerns
that
the
padding
attack
does
have
some
concerns,
above
and
beyond
counter
mode,
the
padding
associated
with
CBC.
B
So
those
are
our
three
choices
and
the
consequences
thereof
and
I'd
like
to
know
what
the
working
group
wants
to
do.
That's
the
question.
C
I
I'm
not
making
any
comments,
I'm,
just
relaying
a
couple
things
from
the
list.
In
case
people
haven't
seen
it
please.
C
C
E
Thank
you,
Michael
Pro,
Rock,
here
I
believe
for
sure
option.
One
should
be
done.
Let's
add,
even
though
there's
a
concern,
you
know
the
security
considerations
is
getting
along
here,
it's
longer
than
the
rest
of
them.
Oh
no,
it's
there
are
some
similar
things
in
some
of
the
other
things
that
I'm
working
on
right
with
very
long
hashes
so
but
I
do
think,
there's
a
high
degree
of
value
in
registering,
even
if
it's
marked
deprecated
or
do
not
use
or
some
other
stronger
language.
E
If
for
no
other
reason
is
that,
then
that
will
encourage
someone
who
thinks
oh
I
found
this
neat
thing.
Let
me
go
look
up
what's
going
on
with
this,
and
then
they
see
mountains
of
security
considerations
and
realize
why
this
might
be
a
bad
thing
unless
they
really
really
know
what
they're
doing
and
have
a
very
specific
use
case.
So
that
is
not
to
say
that
there
aren't
highly
specific
use
cases
for
this.
E
Personal
feelings
are,
and
having
talked
a
bit
with
some
of
the
Sioux
folks,
and
things
like
that-
is
that
there
might
be
a
better
way
out
at
the
very
least
if
we
register
this.
This
might
provide
a
stopgap
mechanism
just
to
continue
proofing
things
out
as
long
as
we're
very
clear,
we're
not
trying
to
advocate
for
the
use
of
this
broadly
right.
F
F
Of
riffing
on
Brendan's
suggestion
about
something
stronger
than
than
deprecated
I
wonder
if
it
would
be
possible
to
do
something
like
Mark
these
as
reserved
these
code
points
as
allocates
and
code
points
in
the
diameter
industry,
but
mark
them
as
reserved
and
then
in
some
suit
documents,
Define
their
usage,
any
a
special
suit
way.
F
F
It
means
like
no
one's
going
to
come
across
the
registry,
be
scanning
for
things
and
say:
oh
there's
a
CBC
thing
here:
I
can
use
this
and
then
you'll
never
even
get
to
the
security
I'm
good
entertained
by
Michael's
assistant
people
are
going
to
pull
up
the
document
and
see
if
the
security
is
considering
would
prevent
that
sort
of
risk.
F
You
could
do
something
I
think
maybe
like
list.
The
suit
document
that
defines
the
acknowledge
should
be
mostly
safe
usage
as
a
reference
in
the
registry
for
why
it's
reserved.
G
I'm
not
sure
I
understood
Richard's
proposal
there,
but
they're
all
legitimate
uses
of
I
mean
there
are
multiple
legitimate
uses
of
of
country
mode,
for
example,
so
we
have
in
the
sigma
protocol.
The
second
message
only
needs
indistinguishability
against
chosen
plain
text
attack
so
as
CTR
would
be
a
good
fit
there.
G
A
So
far,
I
hear
people
speaking
for
option.
One
and
two.
A
Is
I'm
encouraged
by
not
three
and
not
wearing
my
chair,
hat
I
would
encourage
us
to
follow
normal
registration
processes
unless
there's
a
strong
reason
not
to
I
did
hear
you're
come
to
the
mic
say
there
may
be
multiple
uses
for
these,
which
I
think
argues
against
making
them
special
purpose
with
that.
Thank
you
for
your
time.
We
can
continue
this
on
the
list.
Honest!
It's
your
turn.
Thank.
B
H
Okay,
HP
key
next
slide.
H
It
looked
like
a
very
easy
document
at
the
beginning,
and
we
had
a
discussion
at
the
last
ITF
meeting,
which
also
was
uncontroversial
about
the
encoding
of
the
encrypt
or
the
output
of
the
HB
key.
Then,
following
the
confirmation
call
on
the
mailing
list,
it
turned
out
that
that
was
not
quite
true
and
with
the
Alternatives
were
proposed,
but
those
couldn't
reach
or
we
couldn't
reach
a
conclusion
either,
which
is
why
the
the
chairs,
specifically
Mike
posted
a
mail
to
the
list
mentioning
that
outcome
of
that
call.
H
So
I
put
a
few
slides
in
here
and
for
you
to
look
at
what
the
current
proposals
are
in
addition
to
what's
in
the
working
group
document
which
I
hadn't
updated,
because
obviously
we
need
to
First
have
a
conclusion
on
what
we
updated
with
next
slide.
H
So
Daisuke
proposed
made
a
very
specific
proposal
and
I
color
coded
the
important
information
here.
H
So
there
is
so
this
is
the
this
is
sort
of
like
encrypt
zero
payload,
where
the
use
of
HP
Keyes
oops
one
pack.
H
What
okay
is
indicated
using
this
HP
key
algorithm,
which
we
would
have
to
register
and
then
the
essence
or
the
core
of
the
information
that
is
being
passed
around
in,
is
in
this
newly
introduced,
hbke
sender,
information
structure,
which
contains
which
is
a
map
containing
of
a
few
Fields,
namely
the
chem,
the
kdf
and
the
aad,
which
is
which
is
populated
with
values
from
the
hpke
established
Registries.
The
ink
field
is
the
output
of
the
hpkey
algorithm
and
it's
obviously
abbreviated
here.
H
So
that's
his
proposal.
The
next
slide
Hillary's
proposal
layers
on
top
of
this,
and
instead
of
he
makes
a
few
changes.
Maybe
actually
we
go
to
the
next
slide.
This
is
sort
of
the
textual
description
of
what
you
see
here
is
is
to
use
an
array
instead
of
a
map,
thereby
and
making
it
non-extensible
and
omitting
the
chem,
and
he
believes
that
one
can
come
up
with
processing
rules
for
sort
of
guessing
what
the
chemdan
is.
H
Otherwise,
it's
it's
conceptual
is
similar,
I
I
would
say,
except
for
those
those
changes,
although
he
did
raise
a
few
new
points
on
the
mailing
list,
a
new
new
issues
that
we
may
or
may
not
introduce,
which
I
I
were
kind
of
completely
new
weren't
raised
previously
so
I
I
omitted
them
here,
but
in
in
essence
those
are
the
two
proposals
and
that
what
the
actually
three
proposals
there's
the
original
one,
neither
Richard
nor
no
Hillary,
no
I'm
or
none
of
the
the
booklet
proponents
like
that
idea,
but
this
is
kind
of
what
we
are.
H
These
two
proposals
are,
but
we
share
it
in
and
if
you
have
any
preference
on
what
you
would
like
to
do,
that
would
be
highly
welcome.
That's
what
I'm
essentially
saying
with
the
last
slide
so
I
we
don't
it's
like.
Besides
small
number
of
people
who
have
strong
opinions,
we
haven't
come
up
with
something
yet
yeah.
G
You
know
so
I
apologize,
I
haven't
really
looked
at
all
the
details
here,
but
you're
proposing
the
in
it's
a
cozy
key.
That's
what
remains
in
the
draft
in
these
are
the
two
counter
proposals
against
that,
and
basically
they
are
indexed
by
the
algorithm
algorithm,
which
then
creates
this
new,
this
new
entire
format.
So
you
basically
read
off
from
the
camera
the
the
minus
one,
but
this
is
a
cam
and
then
you,
oh
sorry,
this
is
an
hpk
and
then
your
all
the
rest
of
the
fields
are
defined.
Is
that
understanding
the
proposals.
H
Yeah,
like
that,
that's
correct.
In
some
sense,
we
are
really
talking
about
how
to
encode
the
different
fields
that
are
communicated
and
they're,
not
that
many
fields
right,
there's
the
chem,
the
aadid,
the
kdf
and
and,
of
course,
the
encryption
field,
and
that
needs
to
go
somewhere.
And
the
question
is:
where
should
that?
Go
it
like
on
a
very
high
level,
it
doesn't
sound
like
rocket
science
learned.
I
Yeah
Lawrence
dunblade,
so
so
in
this
Pro.
In
all
the
proposals,
the
the
algorithm
top
level
algorithm
is
just
hpk
hpke,
and
this
seems
like
a
Divergence
from
what
everything
else
is
in
cozy,
where
you
kind
of
have
us
the
the
top
level
algorithm
is
more
of
a
cipher
Suite
that
specifies
all
the
things
now.
I
know
the
fan
out
here
can
be
quite
large,
but
one
of
the
advantages,
I
thought
of
with
of
the
cipher
suite
at
the
top
level
are
two
advantages.
I
I
see
at
The,
Cypher
speed
at
the
top
level.
Is
you
just
have
to
look
at
the
algorithm
ID
to
know
whether
you
can
support
it
or
not?
You
don't
have
to
decode
a
lot
more
deep,
a
lot
deeper
into
it,
and
it
allows
us
to
register
only
sensible,
Cipher
Suites
and
avoid
some
of
the
fan
out.
So
my
gut
reaction
is
that's.
I
I
would
prefer
that
and
not
to
diverge.
What
code
from
Jose
has
done
in
the
past
and
I
think
there's
some
good
reasons
for
that.
Yeah.
H
Yeah,
that's
that
mirrors
what
is
currently
described
in
a
working
group
document,
but
that
approach
didn't
find
a
lot
of
sympathy,
because
the
the
Vision
was
that
the
hpkey
guys
would
register
new
algorithms
and
then
they
would
become
instantly
available
in
in
cozy
HP
key
by
reusing
existing
registry.
That's
why
the
the
way
how
these
field
three
fields
are
structured,
it's
kind
of
populated
with
the
values
from
the
existing
registry,
whether
that's
a
gigantic
benefit
or
not.
That's
in
the
eye
of
the
beholder
but
yeah.
H
That's
at
least
that's
the
rationale.
E
Yeah
I'm
gonna
Echo
similar
support
for
the
way
the
document's
written
now
I'm,
not
saying
a
huge
benefit
to
diverging
massively
from
the
existing
methods
that
are
being
taken
with
kose
registry.
It
seems
to
make
sense
right
same
reason
like
point
at
the
owl.
Go
after
this
right
follow
a
common
sense
approach.
There
I
have
a
little
bit
of
concern
pointing
out
to
a
secondary
registry,
and
then
just
we.
B
J
E
F
So,
just
one
quick
clarification
on
what
Mike
said:
I
I'm
ambivalent.
On
the
question
of
how
we
indicate
algorithms
for
what
it's
worth,
MLS
and
other
hpke
user
did
choose
to
define
specific
code
points
that
are
combinations
of
hbke
sub
algorithms.
So
it
wouldn't
be
totally
interesting
to
do
that
here,
but
you
would
have
the
the
lack
of
agility,
as
you
must
pointed
out,
I
I
do
think
that
it
is
not
an
option
to
go
with
the
document
exactly
as
it
is
right
now,
because
we
need
to
update
to
fix
this
code.
F
H
A
All
right
next,
we'll
have
the
seabor
encoded
cert.
Yes,.
K
Excellent,
oh
hi,
all!
Yes,
it's
you
will
heard
Leon
speaking
and
we
wanted
to
give
you
a
update
on
the
status
and
ongoing
work
on
the
seabor,
encoded
x509
certificates,
and
also
to
remind
everybody
to
come
with
input
on
those
issues
where
yeah
input
is
valuable.
Next
slide,
please.
K
Oh,
that's
what
I've
already
covered
one
more
please
and
as
a
quick
reminder
of
the
overall
trade-offs.
So
this
is
all
about
finding
the
good
trade-off
between
compactness
and
convenience
to
parse
and
process
for
iot
devices,
while
still
being
General
enough
to
encode
as
many
relevant
x509
certificates
as
possible.
K
So
a
recurring
topic
is
whether
the
the
minor
optimizations
that
was
proposed
in
the
beginning
should
be
kept
because
they
make
the
the
processing
a
bit
more
complex,
but
they
are
needed
to
actually
reach
the
very
most
compact
cases
for
iot
profiling.
So
we
are
basically
inclined
to
keep
them
unless
there
is
a
big
outcry
for
making
it
simpler
and
more
streamlined.
K
We
need
to
handle
these
types
of
of
signatory
encodings
and
there
has
been
some
discussion
of
whether
they
should
be
punished
in
terms
of
being
a
longer
having
longer
encodings,
but
we
think
that
as
long
as
they
are
used
for
many
CA
certificates,
it
doesn't
really
make
sense
to
actively
punish
them
that,
rather
we
should
keep
it
in
the
same
range
as
other
signature
algorithms.
K
So.
This
is
also
more
on
the
info
stage
that
there
has
been
already
observed.
It's
been
observed
that
what
we're
proposing
here
should
also
benefit
in
terms
of
revocation
lists
and
OCS
ocsp
messaging
and
the
rice
and
Ericsson
together
have
been
having
a
multitis
which
has
been
looking
into
this.
So
this
is
something
we
hope
to
be
feeding
back
into
the
existing
proposals.
K
And
this
is
also
just
to
to
make
sure
that
it
is
self-contained
the
the
draft
in
in
terms
of
actual
usability
for
iot,
because
right
now
we
we
list
a
big
number
of
algorithms,
and
not
all
of
them
are
of
course
suitable
for
iot.
So
this
is
just
a
sanity
check
to
make
sure
that
we
keep
the
knowledge
on
what
are
actually
good
algorithms
for
iot
cases
that
we
try
to
promote
next,
please
so.
This
is.
This
is
a
bullet
where
input
from
a
larger
audience
would
be
valuable.
K
Even
though,
from
our
perspective,
there
has
been
discussions
on
whether
we
should
make
propose
more
complex
structure
where
broccoli
well
back
up
one
step,
so
basically
that
that
there
could
be
certificate
chain,
optimizations
done
if
we
would
allow
to
pass
parsing
of
certificate
chains.
K
But
from
our
perspective
we
see
that
this
would
add
to
Max
much
complexity
to
the
the
parching
ending
and
make
it
less
suitable
for
the
iot
device.
The
scenarios
that
we
at
least
I
care
deeply
about
and
that
rather
it
could
be
handled
through
additional
cozy,
headers
and
external,
broadly
compression,
but
this
is
somewhere
if,
if
the
audience
has
strong
opinions,
we
are
very
interested
in
hearing
them,
but
now
we
step
on
and
take
eventual
discussions
at
the
end
next,
please.
K
K
And
this
is
an
again
an
important,
highlighting
that
currently,
the
IP
range
encoding
could
theoretically
break
the
seaboor
int
encoding
if
you
would
have
since
we
encode
differences.
So
if
you
would
have
a
crazy
subnet
where
you
would
care
to
cover
too
much
of
the
IP
Subspace,
you
could,
in
theory
break
it
and
instead
of
of
trying
to
address
this,
as
we
see
very
much
Corner
case,
we,
we
should
make
it
clear
that
this
is
a
limitation
of
the
existing
proposal.
K
Oh,
this
is
yet
the
the
last
issue,
where
also
input
from
audience
could
be
really
useful.
K
That
Hillary
made
the
real
life
observation
about
the
authority
key
identifier,
that
the
in
in
real
life
actual
certificates
lack
one
of
the
the
sub
parameters,
and
this
can
be
fixed
by
allowing
null
encoding
to
to
cover
these
cases.
But
that
leaves
two
of
the
other
subparameters
which
we
in
our
investigations
have
not
found
to
need
null
encoding
as
well,
but
we
haven't
done
extensive
studies.
So
if
this
is,
if
this
is
a
real
life
problem,
we
should
allow
also
these
submar
meters
to
be
encoded
as
null
and
this
we
are
open
for
adjusting.
K
If,
if
we
think
that
it's
a
problem
that
needs
addressing,
otherwise
it's
all
about
clarifying
the
the
assumptions
that
we
have
made-
and
that
was
the
last
issue
that
I
wanted
to
present
to
you
and
I'm,
of
course,
we're
very
happy
for
comments
now
or
on
the
mailing
list,
as
we
are
progressing
with
this
work.
Thank
you.
A
All
right,
thank
you,
Joel
at
this
point,
we'll
turn
it
to
Tobias
for
the
BLS
key
representation
draft.
H
L
So
this
is
just
a
quick
update
and
we're
Fisher
on
this
draft,
so
it
defines
and
registers
the
required
parameters
Diana
for
the
graphic
key
representation
for
the
Beretta
Lynn
Scott
elliptic
curve
family,
so
BLS
curves
for
representation
in
both
koseki
and
jwk
next
slide.
L
So
so,
why
do
it
well?
Beretta
Lynn's
got
elliptic
curves
have
a
a
couple
of
special
properties
to
them,
known
as
they
are
known
as
peering
friendly,
which
allows
different
signature
style.
Primitives.
L
L
There
is
also
a
appearing
friendly,
curves
draft
that
was
recently
updated,
which
formally
defines
the
curves
and
then
lastly,
there
is
also
another
signature
scheme
draft
that
I'm
also
a
co-author
of
that
was
newly
adopted
at
the
cfrg
since
the
last
iatf
meeting
and
both
of
these
make
use
of
the
VLS
curve,
which
is
as
as
as
per
industry,
adoption
the
most
popular
of
the
peering
curve
family
right
now
next
slide,
and
so
just
a
very
basic
status.
L
Update
as
as
spoken
about
it's
a
simple
draft,
primarily
registering
these
perimeters
and
the
draft
was
adopted
since
atf-114,
we
published
recently
an
update
which
added
jwk
based
examples
and
I'm
close
to
filing
a
a
PR
and
making
a
publication
for
adding
the
koze
key
examples.
M
L
L
No,
no
explicitations
Beyond
just
helping
to
review
the
draft,
because
the
key
examples
should
be
and
fairly
soon
in
the
next
couple
of
days,
so
reviewing
it
with
I
guess
with
an
item
next
steps
as
per
the
processes
as
yeah
as
as
probably
the
next
steps.
Thanks.
A
All
right,
thank
you.
Tobios
now
I'm
going
to
switch
roles
and
be
an
individual
participant
for
presenting
another
draft
that
Tobias
and
I
had
written
together.
This
is
the
claims
in
cozy
headers
draft.
A
So
what
does
it
do?
It
enables
us
to
represent
a
set
of
sieber
web
token
claims
in
a
special
cozy
header,
they're,
put
into
a
header
parameter
and
a
object
in
a
structure,
because
otherwise
there
would
be
name,
collisions
or
number
collisions
between
the
header
parameter
namespace
and
the
claims
namespace.
A
A
For
instance,
you
might
want
to
know
what
the
issuer
is
before
you
even
try
to
decrypt
it
Jose
and
jots
had
that
we
did
not.
We
adopted
this
draft
to
be
able
to
do
that.
A
A
Draft
that
does
one
thing
it
was
adopted
in
July.
Thank
you.
We
just
published
01.
It
is
a
one-line
change
from
zero
zero
that
changes.
The
motivating
example
to
issuer
I
will
say
you
know,
having
reread
it
again
fresh
with
fresh
eyes
in
the
last
few
days.
I
think
it
would
be
beneficial
to
add
an
example
and
I
know
Kirsten
had
asked
about
well,
should
we
have
ADD
cddl,
as
Kirsten
has
want
to
do?
I
don't
see
Kirsten
here
there
must
be
conflict,
but
I
intend
to
ask
Karsten
about
that
offline.
A
H
G
Thank
you
so
I'd
like
I,
actually
didn't
understand
the
example
you
mentioned
here
with
the
unprotected
yeah.
Why
sorry?
Why
not
use
unprotected
header
and
put
information
in
that
so
so
I
think
I.
Think
an
example
would
be
great.
That's
that's
that's
true,
and
maybe
maybe
that's
good
to
have
before
we
have
working
group
classical.
A
I
Yeah
I
was
just
going
to
answer.
That
question
is
that
you
know
if
you're,
if
you're
decoding
you
know
mime
headers
or
content
type
headers,
you
have
access
to
that
parameter
and
then
you
can
switch
on
that
before
you.
You
know,
bring
up
the
seaboor
encoder
or
whatever.
A
In
a
because
I
signed
zero,
there
is
no
unprotected
header
if
you're
using
because
they
signed
one
structure.
A
J
So
maybe
we
can
see
in
the
room
if
there
are
people
that
are
for
or
against
the
working
group,
classical
I
think
in
either
case
we
will
confirm
it
on
the
main
link
list.
If
there
is
enough
support.
J
So
those
that
are
in
favor,
of
starting
the
working
groups
last
call
please
and
raise
your
hands
and
see
if
there
are
people
that
are
against
it.
Please
also.
J
J
If
the
people
have,
if
people
want
to
clarify
why
they
think
it's
are
still
not
ready.
Please
pick
up
on
the
mic
now.
H
We
we
just
raised
two
open
issues
and
the
need
to
add
an
example
and
to
find
out
whether
these
fields
also
applied
to
unprotected
the
unprotected
header.
It
sounds
like
it
would
be
good
to
at
least
update
the
document
briefly
and
add
that
example
to
think
that
could
happen
quickly.
Actually,
there
was
a
third
issue
as
well
with
the
cddl
like
having
three
open
issues
appears
to
be
premature,
to
call
it
working
for
bus
call
right.
J
Yes,
okay,
but
with
those
issues
resolved
I,
guess
then
we'll
be
able
to
go
for
working
group,
let's
go
and
that
this
migrating
character
results.
J
A
So,
let's
move
on
to
Mike
Pro
Rock
talking
about
post
Quantum
signatures.
Thank
you
all.
E
Thank
you,
Mr
Jones,
wait
for
that
deck
to
pop
up
Mike
perock,
here
kind
of
continuing
on
this
is
the
second
update
since
the
working
group
gratefully
gracefully
accepted
this
draft
to
help
us
move.
E
It
forward
next
slide,
just
a
quick
recap
on
post
Quantum
and
why
we're
dealing
with
this-
and
it
largely
is
because
we're
seeing
interesting
changes
to
the
potentially
threatened
the
way
we've
been
handling,
especially
public,
key
cryptography
and
certain
signature
methods
based
on
use
of
quantum
entanglement
and
all
sorts
of
other
fun
things
with
qubits
that
help
us
unpack,
keys
and
relationships
within
data
sooner
we
have
selected
to
go
after
three
algorithms
here
and
we'll
come
back
to
some
implications
from
that
from
signature
scheme
standpoint,
but
the
ones
we
have
gone
after
are
two
lattice
based
ones,
as
well
as
a
hash
based
approach
based
on
feedback
from
nist
and
where
things
are
at
as
far
as
the
candidates
for
standardization.
E
Next
up
so
once
again,
as
mentioned,
we've
gone
after
three:
that's
Sphinx,
Falcon
and
I
lithium,
and
the
key
thing
here
is
to
get
us
a
leapfrog
past
and
be
able
to
start
testing
effectively
for
interoperability
with
things
that
do
require
signatures,
whether
that's
cwts,
jwts,
verifiable
credentials
over
in
the
World
Wide
Web,
Consortium
side
of
the
world,
and
things
like
that.
E
So
it's
really
setting
ourselves
up
for
cryptographic,
agility
and
to
be
able
to
set
a
path
for
registration
to
Future,
post,
Quantum,
algorithms
and
Signature
suites,
as
required,
possibly
by
kose
and
or
Jose
usage,
and
also
to
get
these
Iona
registrations
in
and
because
of
the
parameterization,
especially
with
some
of
these
algorithms.
That
can
be
quite
tricky.
Let's
make
sure
we've
very
clearly
defined
that
and
how
we
would
use
those
here
pointing
back
to
cfrg
and
this
next
slide.
E
So
big
downsides,
large
key
sizes,
large
signatures,
typically
larger
signing
times
verification
times
are
very
nice
next
slide.
E
A
couple
of
key
draft
updates
here:
we've
gone
ahead
and
completed
out
the
sections
on
Falcon
and
sphinx,
plus
we've
gone
through
and
detailed
out.
The
likely
parameter
sets
that
we'll
see
usage,
though
these
are
obviously
subject
to
change
up
until
these
algorithms
are
fully
standardized
at
nist
and
elsewhere.
E
We
are
using
a
combination
because
of
some
of
the
unique
parameters
based
on
the
way,
especially
the
Jose
spec,
is
originally
written
around
kty
and
ALG,
so
that
we
have
the
family
of
algorithms
specified
by
the
kty.
Alga
is
specifying
the
actual
algorithm
itself,
as
well
as
the
parameter
set
in
use
next
slide
next
steps.
This
is
really
the
big
question
for
the
working
group
gut
feel
at
this
point,
especially
seeing
possible
lags
pot
with
one
versus
another
is.
E
Should
we
split
this
into
three
drafts
now
that
the
bulk
of
the
work
has
been
done?
We
can
pretty
easily
do
that
and
instead
of
having
one
post,
Quantum
signature
scheme
draft
that
covers
the
three
initial
ones,
we
could
split
those
up
so
that
they
can
be
actually
moved
forward,
should
that
occur
sooner
with
one
versus
another
or
so
that
we
can
let
one
die
if
we
need
to,
for
whatever
reason
the
proposed
names
at
this
point
would
be
draft
ietf
cause
a
dilithium
falcon
and
sphinx
plus
we
are
awaiting.
E
Obviously
finalizational
parameter
sets
love
any
feedback
from
that
if
anyone's
heard
anything
that
we
haven't
and
generalized
guidance
from
the
group,
since
this
is
kind
of
the
first
draft
I
started
on
with
iatf
on
anything,
I
might
be
messing
up
on
or
could
do
better.
So
thanks
so
much
and
do
want
to
make
sure
there's
a
good
shout
out
to
Ori
all
the
others
who
have
been
helping
us
out,
especially
Christine,
and
actually
some
of
the
authors
of
things
like
Sphinx
and
Falcon
Etc.
D
Okay,
I'm
Quinta,
goodness
just
one
comments
because
three
of
them
they
they
might
come
out
at
different
times
so
I
think
it's
a
better
idea
to
have
separate
documents
for
all
of
them,
because
yeah
they're
a
good
chance
that
there
will
be
finalized
by
this
at
different
times.
And
you
don't
want
one
to
tie
down
the
you
know
the
unfinished
Hideout
the
finished
one.
A
F
Yeah
thanks.
So
thanks
for
interesting
on
the
Mike
I
think
this
is
an
obvious
no-brainer
to
get
these
algorithm
identifier
specified,
basically
as
soon
as
the
algorithms
are
done
so
I
think
my
main
concern
here
is
not
getting
too
far
ahead
of
the
actual
algorithm
standardization,
but
it's
like
as
soon
as
those
come
out
of
nist
like
let's
roll.
As
far
as
the
document
number
I
think
Quinn's
point
is
probably
good.
F
A
A
N
Hi
yeah
I'm,
just
we
had
a
hackathon
on
the
weekend
for
the
x509
side
of
things,
doing
exactly
this
with
the
PQ
keys
and
signatures.
So
I'm
wondering
there's,
obviously
overlap
here,
so
we
should
probably
talk,
and
you
know
make
sure,
because
the
object
ID
is
the
same
things
that
you
are
bringing
up
are
the
exact
same
things
that
we're
dealing
with
plus
we're
also
doing
the
composite.
So
that
would
be
something
to
also
maybe
considered
for
this.
E
Yeah
ABS
absolutely
and
also
appreciate
all
your
inputs
on
the
entry
stuff,
we're
working
on
and
I'm
very
thankful
that
we're
having
conversations
and
have
like
a
mailing
list
for
this
stuff,
because
it's
new
and
we
need
to
cross,
communicate
on
this.
So
thanks
again
for
your
support
on
this.
What.
N
It's
mainly
people
from
the
lamps
working
group
because
it's
dealing
with
the
pki
artifacts.
That
was
where
we
started
from,
but
obviously
PQ
goes
beyond
just
the
pki
artifacts
right.
It
goes
everywhere
so,
and
so
there
was
actually
a
side
meeting
yesterday
too
about
talking
about
a
PQ
side
working
group
and
putting
together
a
charter
for
all
that
so
yeah
I
guess
we'll
see
how
that
that
continues.
So.
E
Yeah
and
in
a
quick
context
for
those
who
might
not
know
Michael,
Osborne
and
Christine
Klosterman
are
co-authors
on
this,
who
authored
kind
of
the
root
level
stuff
over
at
the
lamps
side
of
things,
so
we're
in
very
close
communication
with
both
of
them
on
pretty
much
a
weekly
basis.
Okay,.
N
But
yeah
yeah
in
terms
of
our
hackathon,
like
we're,
going
to
have
we're
going
to
continue
to
work,
so
we
can
invite
we're
happy
to
if
we
people
want
to
test
Koji,
artifacts
or
whatever
with
us,
we're
having
monthly
meetings.
I
sent
that
to
the
labs
mailing
list.
I
could
send
it
to
this
mailing
list
and
invite
people
to
if
they
want
to
participate
because
I'm
trying
to
come
up
with
a
framework
for
automated
testing
and
to
make
sure
all
these
these
new
things
work
together.
So
so
I'll
do
that
then
awesome.
E
E
Just
really
appreciate
all
the
time,
and
especially
the
support
is
a
comparatively
new
author
compared
to
some
of
the
people
that
actually
know
what
they're
doing
in
this
room.
So
thank
you
all.
E
O
He
can
explain
why
that
happened,
but
anyways
so
I'm,
Mike,
sorry,
hello,
oops,
yes,
I'm,
Mike,
I'm,
part
of
this
git
working
group.
That's
been
very
newly
formed.
Some
of
you
probably
don't
even
know
it.
It's
it's
supply
chain,
Integrity,
transparency,
interest
working
group.
We
have
our
first
real
session
on
Thursdays
we're
happy
to
to
join.
O
We
wanted
to
discuss
one
specific
Topic
in
this
group
here
and
that's
around
the
transparency
aspect
of
it.
So
if
you
know
transparency
logs,
you
know
for
certificate
transparency,
for
example,
they
all
have
specific
formats
on
how
to
represent.
O
You
know
sign
tree
heads,
inclusion,
proofs
and
all
of
that,
and
this
again
now
becomes
a
topic
for
more
General,
Supply,
Chain
transparency
and
so
as
part
of
the
skid
working
group,
we
defined
well
an
early
definition
of
what
we
call
a
receipt
and
that's
basically,
a
bundle
of
assigned
tree
head
and
an
inclusion
proof
for
counter
signature
leaves.
So
what
does
it
mean?
It
means
you
have
a
a
cozy
sign.
O
One
message:
that's
your
supply
chain
in
a
way
artifact
and
then
or
statement
I
should
say,
and
then
that
becomes
part
of
a
transparency
log,
and
so
you
bind
those
two
together
with
a
counter-sense
structure.
For
example,
that's
defined
and
cozy,
so
I'm,
not
I,
don't
want
to
say
too
much
about
the
details,
so
I
I
think
the
main
point
that
I
want
to
say
here
is
we
defined
this
new
thing?
That's
called
receipt
and
it
doesn't
neatly
fit
into
any
existing
cozy
structures.
O
O
So
we
had
an
early
attempt
on
trying
to
shoehorn
receipts
and
all
the
transparency
bits
into
a
signature,
algorithm
and
essentially
reusing
cozy
as
it
is.
That
was
not
well
received
in
the
community,
because
it
was
essentially
a
bit
of
an
abuse
of
what
the
signature
algorithm
means,
and
it
was
just
too
much.
O
Does
this
make
sense
in
principle
and
then
I
guess,
there's
a
question
of
the
the
Registries
that
cozy
has
so
where
would
that
fit
in
exactly?
Would
there
have
to
be
maybe
a
new
registry
for
things
that
are
maybe
parametrized
in
our
case?
So
one
example
is
that
there's
not
just
a
single
type
of
you
know
Ledger
or
transparency
log.
They
have
slightly
different,
you
know,
let's
say
Mercury
algorithms,
and
so
there
has
to
be
some
some
way
to
to
express
that
and
yeah.
O
So
there
must
be
some
kind
of
algorithm
or
Ledger
type
and
I
think
that
goes
a
bit
back
to
the
to
the
remark
earlier.
That
was
on
ciphos
tweets.
You
know
shouldn't
be
a
single
long
thing,
or
should
it
be
a
bit
split
up,
but
anyway
these
are
kind
of
details
and
I
guess
yeah
I
have
just
one
minute.
So
that's
so
think
about
that.
I.
Don't
think
we
want
an
answer
now,
but
also
join
us
at
skit
and
maybe
yeah
and.
A
Yes,
we
have
five
minutes
of
all
other
business
with
no
claimants
yet.
A
P
So,
what's
up,
this
is
Hank
just
quickly
on
the
receipt,
so
that
definitely
is
a
core
element
in
the
the
base
work
we
are
doing
in
skit
and
and
we
we
really
need
this
in
cozy.
So
we
will
do
this
as
individual
document
here
very
transparently.
We
hope
for
our
comment,
we'll
be
talking
to
Russ
a
lot
so
so
you
warned
us
for
the
biggest
caveat.
P
So
that's
why
we
are
where
we
are
and
we
will
create
a
stable
proposal,
how
this
looks
like
and
then
I
hope
if
everybody
is
satisfied
enough,
that
we
can
actually
ask
for
adoption.
But
this
is
it's
not
this.
This
is
not
yet,
but
but
Sooners
actually
I.
Think
so.
That's
just
my
comment
that
we
want
to
proceed
with
this,
not
in
a
in
a
slow
pace,
but
actually
want
to
have
a
first
stable
thing
that
is
adoptable
very
soon.
O
Okay,
so
now
clear
everything
you
had
on
your
mind,
a
very
separate
thing,
probably
most
of
you
know
about
timestamp
tokens
than
the
whole
thing.
They're
mostly
used
to
you
know
in
things
like
signed,
a
software
packages
used
in
Microsoft
authenticode,
but
also
for
signing
documents
PDFs.
So
it's
just
to
make
good
use
cases
to
make
the
verification
of
a
signed
document
be
valid
for
longer
than
the
original
certificate
was
valid.
O
For
so
the
idea
here
is
cozy
doesn't
have
a
header
parameter
that
allows
to
embed
timestamp
tokens
in
the
unprotected
header.
So
this
is
simply
a
proposal
to
say:
let's
define
the
code
point
and
including
you
know
how
to
actually
what
to
do
with
that,
how
to
embed
it
and
then
applications
can
use
that
to
timestamp
Cozy
messages.
So
it's
very
simple
so.
P
So
this
is
Hank
again
and-
and
this
is
a
comment-
not
actual
feedback.
So
this
is
a
migration
path
solution.
We
don't
want
to
use
a
tsts
forever,
but
we
accept
the
fact
that
they
are
the
most
common
and
established
thing
to
use
today.
And
so,
if
we
want
to
move
to
something
cooler
like
say
an
Epoch
marker,
that's
fine
or
assigned
to
see
what
time
check
that's
cool.
P
But
for
now
this
is
I
think
a
necessary
solution
when
you
want
to
use
infrastructure
that
is
in
place
and
that's
why
this
could
be
perceived
as
a
mid
term
migration
path
solution,
but
if
we
don't
standardize
it.
Oh
just
random.