►
From YouTube: IETF113-SUIT-20220324-1200
Description
SUIT meeting session at IETF113
2022/03/24 1200
https://datatracker.ietf.org/meeting/113/proceedings/
B
A
D
D
Yeah,
we
really
do
need
to
start
because
there's
a
very,
very
full
agenda.
D
Oh
good,
all
right,
let's
go
ahead
and
get
started
welcome
to
suit.
We
have
a
very,
very
full
agenda
today,
and
so
we
want
to
start
on
time
with
a
hope
of
therefore
ending
on
time.
D
D
Dave-
and
I
will
watch
as
well
so
awesome
that'll
get
us
there.
Thank
you
next
slide.
D
D
E
Go
ahead
hi!
This
is
honest
just
because
of
the
hackathon
yeah
it
was.
I
was
there
at
the
hackathon
like
many
of
the
folks
in
like
who
obviously
remote
or
many
people
couldn't
come
to
this
idf
meeting,
who
are
typically
participating
at
the
hackathon,
which
was
unfortunate.
So
I've
been
working
on
the
firmware
encryption
and
I'm
I
I'm
going
to
talk
about
that
a
little
bit
later.
E
So
I
think
I
think
it
was
we
had
about,
I
would
say
100
people,
maybe
at
the
hackathon,
so
it
was
well
attended
like
relative
to
to
where
we
are
today
with
the
restart
of
the
face-to-face
meetings.
So
it's
really
good
but
different
experience
than
then
we
had
pre-copied
so
hopefully,
next
time
we'll
get
folks
to
participate
in
in
philadelphia
at
in
a
bigger
setup
again.
D
Okay,
brendan's
up
next
with
suit
manifest.
H
Okay,
so
this
is
the
suit
manifest
draft.
As
you
can
see,
it's
still
version
16.
That
means
it
hasn't
changed
since
112.
next
slide.
Please
that
doesn't
mean
we
don't
have
any
open
issues.
The
primary
open
issues
that
we
have
today
are
mti
algorithms
and
crypto
agility
next
slide.
Please.
H
So
it
really
makes
sense
to
me
that
we
should
have
some
kind
of
pqc
mandatory
to
implement
algorithm,
but
the
question
is:
what
does
that
actually
mean?
Does
that
mean
that
authors
are
required
to
support
pqc
or
bootloaders
or
update
clients,
or
all
of
them?
I
guess
at
minimum.
It
seems
that
authors
should
be
required
to
support
pqc
next
slide.
Please.
H
So
there
are
a
number
of
ways
now,
the
one
that
we've
discussed
really
is
hss
lms.
Now
we
have
a
research
paper
which
is
linked
at
the
bottom
there,
which
has
some
details
on
exactly
how
this
would
be
configured
and
what
kind
of
implications
it
has
so
comparing
ecdsa
to
hss
lms
with
the
parameters
that
were
selected
for
that
particular
research
paper.
H
We
see
two
fifths,
verification
time
and
74
times
the
signature
size
one
and
a
half
times
the
stack
size
double
the
code
size,
and
I
think
that
the
key
question
here
is
whether
a
74
times
signature
size
is
acceptable.
This
is
four
kilobytes
just
for
putting
a
concrete
number
on
it.
There's
another
parameterization,
obviously
where
we
could
do
the
w8
parameter
rather
than
the
w4
that
drops
the
signature
size
to.
H
I
think
1280
bytes,
but
I'm
expecting
a
much
higher
verification
time,
because
there's
a
lot
more
hashes
that
have
to
be
done.
So
the
question
is:
can
we
realistically
expect
this
from
bootloaders
and
I'm
not
sure,
there's
a
clear-cut
answer
on
that?
H
H
There
is
an
alternative,
falcon
512
actually
looks
pretty
good,
it
doesn't
have
the
same
kind
of
key
management
overhead.
The
signature
size
is
smaller
than
all
of
the
hss
lms
implementations,
and
it
is
incredibly
fast.
It
does
require
a
fair
bit
of
ram
around
four
kilobytes
based
on
the
aforementioned
research
paper.
The
real
issue
is
the
code
size
which
is
looking
at
about
57
kilobytes,
just
to
implement
that
one
signature
algorithm
and
it's
not
yet
accepted
by
nist,
though
it
is
in
the
final
round,
so
there's
a
possibility
there.
H
H
The
next
question
is
crypto
agility.
Now
that's
quite
plausible
for
update
clients
within
the
the
constraint
that
they
will
have
to
over
specify
hardware
or
implementers
will
have
to
over
specify
hardware
and
essentially
be
planning
for
this
from
the
get-go.
However,
it's
not
plausible
to
have
crypto
agility
in
a
non-updatable
code.
So
how
do
we
handle
stage
zero
boot
loaders?
Is
that
just
a
different
requirement?
H
We
we
need
to
essentially
say
where
our
crypto
agility
mandate
ends,
and
I
guess
the
final
question
is:
do
we
advocate
for
dual
signature?
The
idea
there
is
that
you
use
a
classical
signature
algorithm
for
the
bootloader,
but
you
use
pqc
algorithm
for
the
update
client
itself.
H
That's
it
yeah,
that's
it
so
discussion.
I
Am
I
on
yes
all
right,
so
I
guess
the
only
comment
I
would
make
about
something
like
57
kilobytes
of
code
is
like
several
times
larger
than
npu.
Boot
is
currently
and
that's
not
going
to
work.
For
I
mean
we
can
declare
something
as
mandatory,
but
realistically
they're
going
to
be
config
options
and
people
won't
select
them
if
they
aren't
going
to
fit
in
their
device.
H
Sorry,
which
code.
K
I
yeah
emmanuel
here
so
yeah,
it's
it's
it's
for
both
signing
and
and
verifying,
and
so
we
definitely
you
know
these
are
our
numbers.
We
got
with
a
an
implementation
that
we
made
as
much
as
possible,
embedded
friendly,
but
there
are
probably
ways
to
improve
that
and
we're
actually
working
on
that
right
now.
K
We
don't
have
the
results
for
that,
but
I
expect
we
can.
I
mean,
as
russ
said
we
can
do
slightly
better.
There
are
some
stuff
which
I
think
won't
get
better
like
the
signature
sides
and
things
like
that,
but
it
might
be
that
and
there
are
like
more
embedded
friendly
implementation
out
there,
how
how
much
more
friendly
that
is
gonna,
be
I
don't
know,
but
russ
is
right
that
there's
probably
like
some
some
some
level
of
improvement.
That's
possible
here.
H
Okay,
that's
that's
good
information.
My
my
understanding
from
having
looked
at
this
a
bit
before
was
that
that
that
57k
in
particular
seemed
very
large
compared
to
what
I
saw
on
the
on
the
site,
the
falcon
sign
site,
and
I
thought
that
it
was
possible
to
do
smaller
than
that.
But
I
I
took
you
at
your
word,
so
I'd
be
like
very
interested
to
hear
what
the
verify
only
sizes
look
like.
E
Hi
yeah,
I
I
wonder
whether
it's
possible
to
get
away
without
specifying
a
mandatory
to
implement
in
this
case,
because,
as
friends
said
like
there
are
different
pieces
in
this
or
software
components
in
this
whole
sort
of
picture,
you
have
obviously
the
stage
zero,
bootloader
or
the
like
the
the
one
that
is
kind
of
the
the
root
of
trust,
and
that's
one
thing.
But
then
you
have
maybe
other
stages.
You
know
in
a
more
complex
system.
E
You
also
have
the
update
client,
which,
which
also
has
some
some
code
in
there
and
and
of
course
it
will
depend
a
little
bit
on
on
the
specific
deployment
case
like
how
long
these
devices
are
supposed
to
be
out
in
the
field.
E
And
so
how
can
we
make
generic
recommendations,
given
that
the
this
competition
also
hasn't
been
completed
yet
and
so
on?
And
so
on
so
like?
Do?
We
really
need
to
sort
of
like
can't?
We
table
that
and
maybe
have
profiles
later
on,
for
example,
say
a
specific
deployment
sort
of
setup,
that
has
let's
say
a
combination
of
different
stages
of
bootloaders
and
firmware,
update,
client
and
so
on,
and
have
have
for
those
a
recommendation
versus
something
that
is
sort
of
very
simplistic,
short-lived,
etc
or
shorter.
E
Lift
a
different
sort
of
story.
B
E
Yeah,
maybe
to
do
more
or
less
describe
the
challenge
that
someone
deploying
a
firmware
update
mechanism
has
to
go
through,
like
they
have
to
sort
of
figure
out
for
themselves.
On
like
how
long
are
my
devices
going
to
be
out
in
the
field
is
post
quantum
sort
of
the
post
the
emergence
of
these
computers?
Is
that
a
problem
for
me
or
do
I
consider
it
an
important
how
how
much
space
do
I
have
for
the
device
and
so
on
and
so
on?
E
Do
I
need
encryption
for
my
firmware,
etc,
etc
like
or
how
is
my
whole
software
architecture,
sort
of
laid
out.
A
My
prediction
would
be
that
if
I
were
to
look
into
a
crystal
ball
that
it
might
not
pass
iesg
review,
if
it
didn't
actually
have
you
know
mandatory
to
implement
stuff,
because
you
would
not
have
an
interoperable
spec
per
say
if
you
required
a
profile
that
didn't
exist
in
our
fc
forum
to
actually
interoperate,
and
so
I'm
not
sure
that
it
would
actually
save
us
any
time
to
the
rfc
process
to
try
to
split
it
out.
It's
a
good
question,
you're
making
me
think
about
it,
but
that's
my
guess.
K
Yes,
so
I
think
that
this
question
was
raised
because
we
wanted
to
make
lms
mandatory
to
implement
right
where
there
are
like
some
questions
about
like
is:
is
that
like
today,
something
that
people
are
going
to
be
able
to
do,
and
so
so
the
question
is
not
like:
do
we
want
to
have
nti
or
not
it's
like
what
do
we
put
into
it
yeah
right
now.
I
think.
D
That
was
the
discussion
and
we
observed
that
we
had
this
post-quantum
hss
lms
opportunity,
which
would
allow
us
to
have
a
transition
to
other
algorithms
under
the
protection
of
a
post-quantum,
safe
algorithm.
So.
D
D
G
So
we
I
just
wanted
to
relay.
We
had
a
few
other
points
of
concern
about
the
hss
lms.
One
of
them
is
that,
since
it
is
not
part
of
any
of
the
like
big
standardized
libraries,
there
is
a
greater
risk
that
we
don't
know
when
we
use
it.
Whether
it
will
have
support
whether
security
issues
will
be
will
be
handled
and
fixed
in
the
future
and
also.
G
G
H
I
just
wanted
to
respond
to
the
comment
that
firmware
loads
are
huge,
while
that
may
be
the
case
for
a
full
image
update.
That
does
ignore
that
it's
absolutely
possible
to
do
differential
updates
that
are
small,
and
it's
also
possible
to
do
small
asset
updates
that
aren't
the
entire
firmware
image.
So
I
I
don't
think
it's
fair
to
say
that
amortizing,
a
kilobyte
or
four
kilobytes
of
signature
size
across
a
firmware
load
is
necessarily
going
to
get
lost
in
the
noise.
H
I
think
that
very
much
depends
on
the
use
case
and
on
on
exactly
what
kind
of
compression
you're
using
and
just
to
put
some
concrete
numbers
on
this.
The
energy
that
it
takes
to
transmit
a
byte
of
firmware
over
a
lora
network
is,
I
think,
on
the
order
of
80
times
the
amount
of
energy
that
it
takes
to
write
it
to
flash.
So
when
it
comes
to
saving
energy
on
low
power,
remote
nodes,
the
firmware
size
is
absolute
like
over.
The
wire
is
absolutely
crucial.
K
Yeah,
so
I
wanted
to
also
violently
agree
with
with
brandon
here
we
detail,
like
different
different
cases
in
this
paper.
K
That
brendan
was
was
citing,
where
you
see
the
impact
of
something
like
lms
in
terms
of
signature
size
on
on
the
data
you
need
to
transmit
over
the
network,
depending
on
what
you're
actually
updating,
obviously-
and
there
are
different
sizes-
indeed,
where,
where
4k
is
a
lot,
that
said
so,
we
we
are
working
on
a
improved
implementation
of
lms
with
our
colleagues
at
interior,
who
are
crypto
specialists,
and
so
we
are
we're
going
to
follow
up
on
this
on
this
paper
with
with
some
more
work,
and
hopefully
we
can
actually
bring
some
of
these
some
of
these
numbers
down,
not
the
signature
size,
but
others,
at
least
that's
that's
our
hope
and
so
stay
tuned
on
this
and
we'll
get
back
as
soon
as
we
can
on
this.
E
Yeah,
I
wonder
we
wanted
to
finalize
the
suit
specification
and
manufacture
specification
rather
soon.
So
I
wonder
like
what
are
really
realistically
the
options
besides
hssm
lms,
because
I
don't
think
it
would
be.
It
would
be
wise
to
pick
something
that
from
the
nist
competition
which
hasn't
been
finalized,
yet
let
alone
that
obviously
there's
even
less
code
available.
B
It
sounds
to
me,
like
we
have
a
timing
problem
here,
right
that
there's
desire
to
make
hhs
lms
work,
but
we
haven't
had
enough
time
for
implementation
to
kind
of
catch
up.
B
One
of
the
things
that
we
did
in
ipsec
me
you
know
was
we
had
a
separate
algorithm
draft
that
we
would
work
on
and
update
over
time,
and
we
use
things
like,
must
minus
or
should
plus
as
a
way
to
signal
a
desire
to
advance
or
or
retract
specific
algorithms
over
time
as
a
way
to
kind
of
signal
to
the
implementation
base,
the
direction
that
the
standard
was
going.
Maybe
we
could
do
something
like
that
here
as
a
way
to
you
know
to
break
the
logjam.
J
No
thoughts
on
that
sorry,
I
just
want
to
update
on
the
local
numbers.
Okay.
So
if
there's
anyone
who
wants
to
respond
to
what
we
just
said,
the
please
go
ahead.
First,.
J
So
what
I
just
did
to
get
the
numbers
was
quickly
take
the
benchmark
the
test
application.
We
have
for
falcon
comment
out
anything
that's
related
to
key
generation
and
signing
and
wrap
the
numbers
from
the
elf
file
that
take
up
the
falcon
bits
and
that's
around
10k.
So
that's
for
falcon,
probably
what
you
have
to
work
with
for
this
implementation.
J
C
D
E
Yeah
I
like
I
like
the
idea
that
david
just
raised,
but
the
problem
is.
It
sounds
like
a
little
bit
to
what
dave
taylor
was
previously
referring
to,
because
we
basically
then
have
no
mdi
in
the
manifest
specification
move
that
the
separate
algorithm
draft.
But
then,
presumably
they
would
have
to
go
together
right.
E
While
there
is
a
benefit
of
having
the
ability
to
update
that
algorithm
draft
independently,
without
sort
of
revising
the
manifest
specification
which
has
is
attractive
to
me.
But
I
think
it
will
not
sort
of
like
really
allow
us
to
get
us
off
the
hook
of
the
question
of
what
mti
is
because
even
so,
I
haven't
looked
at
that
ipsec.
But
presumably
it
also
has
an
mdi
version
in
there
right.
D
E
Now
I
I
like
that
idea,
but
even
even
then
like
would
it
make
sense
to
let's
say,
have
ecdsa
india
as,
for
example,
currently
as
the
must
and
I've
recommended,
or
should
for
hss
lms
and
then,
as
we
make
progress
and
say,
okay,
we
can
get
the
code
size
down
and
we
can
do
all
sorts
of
other
investigations.
We
be
revisit
that
that
document
and
then
maybe
make
some
other
recommendations,
is
that
sort
of
the
idea,
david.
B
D
That
could
still
be
done
as
as
dave
suggested
by
putting
it
in
a
separate
document.
That's
a
normative
reference,
that's
easier
to
change
without
ever
changing
the
base.
Spec.
H
Yeah,
fair
enough,
I
guess
what
I'm
trying
to
say
here
is
that
boot
loaders
can
end
up
being
so
application
specific
that
if
we
are
too
normative
about
what
the
boot
does,
all
that
means
is
that
this
will
not
get
used
in
a
bootloader
and
will
inflate
sizes
artificially,
because
there
are
multiple
manifests
flying
around.
D
Okay,
so
I
think
we
have
a
basic
direction
for
for
brendan
to
finish
this
up
and
it's
very
clear
that
we've
spent
half
of
the
time
on
one
document
so
that
we're
not
going
to
get
anywhere
close
to
through
this
agenda,
so
we're
just
going
to
keep
going
because
I
think
the
decisions
we're
making
are
important,
but
we're
going
to
be
scheduling
a
virtual
interim
in
a
couple
months.
So
let's
keep
going
brendan
up
next
is
the
trust
domains.
H
Okay,
so
there
is
not
a
lot
of
update
here.
This
is
just
the
resubmission
of
the
previous
individual
draft
as
a
working
group.
Draft
next
slide.
Please.
H
Just
as
a
quick
recap,
this
is
the
portion
now
that
contains
delegation
chains,
dependencies
integrated
dependencies,
multiple
suit
processors
and
the
unlinked
directive.
Now
this
is
important
specifically
for
t,
so
we
want
to
get
this
one
through
quickly
well
quickly,
after
the
manifest
primary
document,
and
it
is
specifically
because
teep
depends
on
dependencies
and
unlink
next
slide.
Please.
H
Now
I
say
that
there's
no
running
code
for
these
things,
but,
to
be
frankly
honest
I
could
well
be
very
wrong.
I
know
that
akira
has
been
working
on
running
code,
which
may
well
do
all
of
this.
So
when
I
say
there's
no
running
code,
I
mean
that
I
haven't
spotted
it
yet.
So
if
the,
if
there
is
running
code,
please
do
let
me
know
really.
The
other
thing
is
I'm
not
100
certain
that
we're
using
the
cwts
correctly.
H
So
if
there's
anyone
who
is
who
wants
to
review
the
use
of
key
claims
in
cwt,
I
would
appreciate
that
or
sorry
proof
of
possession
claims
and
I
would
very
much
appreciate
any
contributors
and
especially
if
they
come
from
teep,
I
mean
anyone
is
welcome,
but
if
they
come
from
teep
doubly
so.
F
Can
you
hear
me?
Yes,
oh
yeah
yeah,
as
I
mentioned
in
the
chat,
my
lips
suits
support,
dependency
and
also
integrated
dependency,
but
I'm
not
sure
that
there
is
support
because
there's
no
sample
binaries
in
the
document.
So
I
report
are
an
email.
F
So
please
review
my
sample
binaries
and
mr
rip
sisu
versus
behavior.
H
Thank
you
ken.
I
guess
what
that
that
really
says
to
me
is
that
I
need
to
make
sure
that
there
are
some
examples
in
that
draft.
H
H
All
right,
just
as
a
refresher,
what
this
contains
is
update
management
metadata.
So
this
provides
information
like
certain
conditions
that
you
might
care
about.
Version
number
matching
battery
levels,
expiry
dates
of
manifests,
an
explicit
check
for
if
an
image
does
not
match
something,
an
authorization
check
which
could
be
used
for
end
user
approval,
and
I
think
that's
an
important
consideration
with
rfc
8890.
H
H
So
currently
we
are
specifying
coswood,
which
is
what
was
available
when
the
original
draft
was
written,
but
it
looks
to
me
like
co-rim
would
be
a
much
better
option.
The
problem
is
that
co-rim
is
not
a
working
group
document
yet
and
so
that
that
would
essentially
put
a
blocker
on
this
particular
draft.
So
it
strikes
me
that
it
might
be
better
to
go
ahead
as
it
is
and
add
another
extension
document
later
much
as
I'd
rather
not
have
so
many
extensions.
H
It's
not
clear
that
the
update
management
document
is
anywhere
near
comprehensive
or
complete.
Once
again,
if
there
are
use
cases
that
you
care
about,
I
would
very
much
appreciate
hearing
about
them,
and
feedback
is
absolutely
welcome.
E
Okay,
next
slide
briefly
talking
a
little
bit
about
the
firmware
encryption.
So
what
what
has
changed
since
we
met
last
time.
So
there
was
this
intra
meeting
in
the
cozy
working
group
where
we
presented
the
cosy,
hp,
key
draft
and
there
the
decision
was
made
to
change
the
underlying
structure
of
the
payload.
E
Needless
to
say,
that
that
had
to
be
backboarded
so
to
speak
into
this
document
and
I've
also
fixed
references
which
apparently
got
somehow
garbled
ice
bento,
we
spent
most
of
our
time
focusing
on
progressing
the
cosy
hb
key,
which
we
extracted
from
this
document
or
from
an
earlier
version
of
this
document
and
moved
into
that
separate
document
by
the
last
idf
decision
of
this
group.
E
And
in
the
meanwhile,
I
had
added
code
to
a
code
to
hp
key
to
embed
tls,
which
you
can
find
there,
I'm
using
that
code
in
the
decocy
library,
which
you
find
there
and
updated
the
code
during
the
hackathon
which
I
was
previously
referring
to,
which
uses
this
the
crypto
adaptation
layer
that
lawrence
has
added
decoys.
He
supports
openssl
and
also
the
bsa
crypto
api,
which
is
why
I
had
used
the
bsa
crypto
api.
E
What
you
will
also
notice
when
you
look
at
that
code,
is
that
the
firmware
encryption
is
for
use
with
aes
keywrap
is
not
yet
there,
because
the
bsa
crypto
api
support
for
the
aes
keywrap
is
still
working
progress
in
the
last
link
here.
So
as
soon
as
that
is
done,
I
will
copy
that
code
in
there
as
well.
E
Okay,
so
there's
at
least
something
to
look
at,
and
that's
how
I
create
the
examples
as
well
next
slide.
So,
but
there
are
some
open
issues
still
not
only
with
this
document,
but
also
with
the
work
of
the
cozy
hb
key
document.
So
we
will
have
to
work
on
or
take
the
decisions
that
were
made
earlier
this
week
in
a
cozy
working
group
and
update
this
document
as
well.
E
The
examples
are
kind
of
rudimentary,
so
they
don't
include,
for
example,
the
whole
wrapper,
let
alone
the
the
suit
part
sort
of
like
this.
The
outside
manifest
part,
which
I
would
also
like
to
include
and
there's
also
sort
of
some
homework
to
be
done
when
it
comes
to
binding
the
context
to
the
encryption
itself,
and
I
want
to
talk
about
the
last
two
items
in
the
next
few
slides
briefly.
E
Okay,
next
slide.
So
this
is
what
I
mean
by
a
more
complete
example.
So
what
you
see
in
the
document
right
now
is
the
left-hand
side,
which
shows
this
cozy
structure
in
a
sort
of
debug
format.
With
this
new
two-layer
structure,
which
is
which
is
essentially
the
sort
of
the
the
the
first
layer,
the
first
part
on
the
top
is
just
the
regular
encrypt
function.
E
Functionality
cos
encrypt
with
algorithm
information
with
the
nouns
included
in
there
detached
ciphertext,
that's
the
first
part,
and
then
what
follows
afterwards
is
the
recipient
structure
or
the
or,
if
there
are
multiple
recipients,
multiple
recipient
structures
in
that
area,
and
that's,
for
example,
where
the
hpke
goes
or
the
aes
key
wrap.
So
this
is
now
unified
in
terms
of
look
and
feel
which
I
personally
like
a
lot
there's.
Obviously
some
of
the
things
are
abbreviated
for
better
readability,
so
obviously
the
keys,
the
public
keys
and
also
the
encrypted
care
case
would
be
larger.
E
This,
however,
needs
to
be
in
order
to
provide
proper
security,
or
at
least
the
authentication
part
it
needs
to
be
bundled
up
with
a
sign.
So,
as
I
try
to
show
here
graphically,
is
that
once
you
generate
this
cosy
encrypt
structure,
it
gets
sort
of
the
binary
gets
included
into
this
payload
structure
on
the
right-hand
side
of
the
slide,
and
then
the
the
cosy
sign
wrapper
is
sign
one
rapist
and
use
to
to
actually
sign
that
payload.
E
I
hope
that
makes
sense
so,
for
example,
if
you
have
well
not,
for
example,
but
this
this
would
be
the
way
to
be
done
for
the
for
the
use
with
the
hp
key
when
you
sign
it,
but
then
with
key
as
key
wrap
when
one.
If
you
have
a
shared
secret
in
this
case,
multiple
shared
secrets,
then
you
would
actually
use
the
mac
operation
instead.
E
So
that's
those
are
some
of
the
examples
that
are
still
missing
in
the
document.
I
will
add
them
as
well.
Based
on
on
on
the
code.
I
have
okay
next
slide,
so
if
we
actually
produce
that
example
on
the
on
the
previous
slide,
there
there
is
the
sort
of
for
the
topmost
part.
There
is
the
encrypt
operation
which,
for
which
the
cosy
specification
defines
that
you
have
to
come
up
with
a
structure
which
I
copied
on
the
screen.
E
This
underscore
structure,
which
is
then
used
as
input
to
the
additional
authenticated
data
for
this
operation
and
the
so
there's
some
context
in
there,
namely
the
operation
you
are
going
to
perform.
There's
also
information
copied
over
from
the
protected
field,
which
is
from,
for
example,
on
the
previous
slide.
E
We
used
aes
gcm
128
to
encrypt
the
firmware
image,
so
that
would
be
put
in
there
and
then
there's
in
in
our
case,
there's
no
external
aad
here,
so
this
would
be
used
and
then
that
would
be
input
to
the
regular
in
this
case,
aes
gcm
128
operation
and
that's
what
the
the
output
would
be
next
slide,
but
there's
more
than
that.
E
So
the
the
courses
back
also
talks
about
this
so-called
context
information
structure
and
refers
to
sort
of
it
as
a
way
to
bind
the
context
or
the
context
of
the
transaction
to
the
whole
sort
of
sort
of
construction.
If
you
will-
and
as
far
as
I
understand
it-
and
at
this
my
reading
of
the
the
cozy
specification
is
a
little
bit-
I'm
I'm
still
learning
in
some
sense
on
how
to
read
that
cozy
specification.
E
But
I
understand
that
it's
not
used
for
k,
aes
keywrap,
but
it
would
be
used
for
or
it's
currently
used
for
all
these
elliptic
curved
tiffy
helmet
static,
static
or
semi-static
operations,
and
so
that's
why
I
had
put
that
sort
of
a
way
to
populate
that
structure
into
an
earlier
version
of
the
document
which
is
now
found
in
the
cosy
hb
key
document.
E
E
So
I'm
going
to
reach
out
to
some
of
the
experts
here
in
the
idf
for
like
cast
and
others
to
find
out
whether
my
understanding
is
is
correct,
but
it's
it's
a
little
bit
tricky
because
there's,
I
don't
want
to
have
too
much
redundancy
here,
because
some
of
that
information
is
already
included
in
the
kdf
in
a
key
derivation
function
of
the
hb
key
itself.
Already,
what
is
not
included
is
because
we
are
using
the
base
mode
of
hp.
E
Key
is
the
identities,
so
at
least
at
the
minimum
we
would
have
to
wrap
in
the
identities
and
the
recipient
identity
itself
has.
If
actually,
we
could
go
back
to
slides,
to
show
that
to
see
the
example
here,
no
one
another
one,
this
one
yeah.
So
if
you
look
here
this
obviously
there's
the
key
id
shows
here
up
in
two
places
and
one
is
for
the
for
the
sender
and
the
other
one
is
for
the
recipient,
so
in
the
cosy
encrypt
that
contains
the
recipient,
the
key
id
for
the
recipient.
E
I
don't
know
if
you
can
scroll
over
them.
If
you
have
a
way
to
mark
things,
but
you
maybe
you
can
see
that
if
you
can
go
down
with
the
mouse
point
a
little
bit
so
as
part
of
this
recipient
structure,
there's
the
key
id
that
identifies
the
static
elliptic
curve.
If
you
have
in
public
key
and
that
would
be
the
recipient
id
that
would
be
yeah
exactly.
That
would
be
the
recipient
identity
included
into
this
structure.
E
And
what
is
a
little
bit
inconvenient
is
that
since
we
have
this
layering
of
the
payload,
the
sender's
identity
is
actually
outside.
In
this
cozy
sine
one
structure,
but
that's
how
it
is
so
if
anyone
has
an
idea
on
how
in
cosi
this
was
meant
to
be
used
being
applied
to
hbk
or
has
some
other
sort
of
like
experience
with
this,
I
would
obviously
value
that
input,
but
I
understand
it's
a
little
bit
a
very
specialized
aspect
here
and
yeah,
so
this
is
so.
D
E
D
This
is
russ.
This
goes
back
to
rfc
2631,
which
is
based
on
nancy
x942,
where
you're
trying
to
derive
a
shared
secret,
and
you
want
to
make
sure
that
both
parties
are
applying
the
same
context
to
that
secret.
That's
where
this
info
struck
stuff
is
rooted,
and
here
we're
we've
got
a
lot
less
concerns
because
of
the
it's
always
used
with
the
signature.
D
So
the
question,
to
my
mind,
really
falls
to
the
cozy
group
to
make
sure
that
when
they're
using
it
as
a
building
block
in
other
contexts,
are
there
any
concerns,
and
I
think
we
need
to
make
sure
that
questions
raised
there.
But
in
this
context,
I'm
I'm
pretty
sure,
there's
no
problems.
E
Yeah
yeah,
that
was
my
that
was
my
impression
as
well,
because
I
don't
want
to
sort
of
blow
things
up
with
some
redundant
payloads
that
are
actually
then
not
adding
any
additional
value
but
yeah.
So
currently,
what
is
currently
in
the
two
documents
is
that
we
don't
use
that
structure
and
the
cochbee
document
says
if
you
have
an
application,
specific
context:
here's
the
structure
and
you
populated
with
the
respective
fields,
but
I
wanted
to
sort
of
be
sure
that
you
guys
agree
with
that.
That's
that's
yeah!.
E
That
was
my
last
line:
yeah
yeah.
So
if,
if
anyone
is
interested
to
contribute
drop
us
an
email,
yeah
quote
there
a
lot
of
fun.
H
H
So,
just
a
a
quick
recap
of
what
this
is:
it
carries
a
record
of
decisions
made
by
the
suit
manifest
processor
that
you
use
alongside
the
manifest
tree
itself
in
order
to
reconstruct
what
a
device
did.
H
H
So
what
we
have
done,
since
the
zero
zero
draft
is
added
a
list
of
suit
parameters
and
component
ids
to
use
as
system
properties.
What
this
can
do
is
enable
attestation
of
system
properties
and
though
it
does
have
wider
applications
than
just
attestation,
and
it
ties
into
the
suit
reporting
policy
which
shows
up
in
the
manifest
draft
itself.
H
I
I
had
originally
planned
to
have
this
one
come
after
the
one
on
the
suit
and
rats
claims.
So
that's!
Hence
my
thinking
there
was
more
content
coming
there.
So
this
this,
I
guess,
sets
the
backdrop
then
for
that
particular
discussion.
H
So
I
think
it
in
it
makes
the
most
sense
to
me
to
put
these
two
together,
and
maybe
we
should
go
straight
into
the
next
one,
and
then
we
can
have
discussion
about
them
together,
because
I
think
the
the
issues
really
are
tied
together.
A
E
D
H
Okay,
so
previously
we
had
a
draft
of
suit
claims
in
rats
to
define
suit
specific
elements
that
require
attestation.
The
thing
is
that
the
suit
report
could
also
carry
these
elements.
Now
we
proposed
this
at
the
rats
interim
and
suggested
that
we
merge
the
this
document
with
the
suit
report
document.
Now
that
was
rejected
in
the
interim,
and
the
reason
for
that
was
that
some
of
the
claims
are
duplicated
by
elements
that
have
been
added
in
rats.
H
H
So
essentially,
this
is
a
debate
about
semantics
versus
structure.
Eat
contains
data
with
specific
semantics
and
specific
structure,
and
the
suit
report
contains
data
with
similar
semantics
and
a
different
structure.
The
suit
report
structure
is
designed
specifically
to
reduce
overhead
on
constrained
devices.
Now
what
that
means
is
essentially
that
you
don't
have
to
hold
in
memory
components
that
will
go
into
the
the
eat
claims
later.
H
The
idea
here
is
that
you
can
actually
just
directly
encode
on
the
fly
as
you
as
you
encounter
these
decision
points
the
this
may
seem
like
it's
a
premature
optimization
and
I
suppose
it
might
be,
but
it's
consistent
with
the
the
non-attestation
side
of
reporting
in
suit.
H
So
by
putting
those
two
things
together,
it
seems
that
they
do
make
sense
on
their
own,
like
the
the
the
the
the
joint
code,
size,
reduction
and
memory
reduction
that
you
get
by
doing
both
things,
this
way
seems
like
it
would
be
the
right
choice.
Obviously
this
is
something
that
we
don't
have
measurements
for
yet,
but
that
is
something
that
makes
sense
to
me
from
a
high-level
perspective,
it's
really
tightly
coupled
to
how
suit
parsing
is
done.
H
H
And
so
this
is
where
I
think
we
come
to
possibly
the
contentious
side
of
things.
Suit
reports
could
potentially
be
treated
as
evidence,
but
they
should
not
be
treated
as
attestation
results.
So
arguably,
a
verifier
should
translate
a
suit
report
into
generic
e-claims.
H
H
Oh,
I
just
I
just
stole
my
own
thunder,
so
that
would
be
consistent
with
using
it
as
evidence.
The
verifier
would
be
perfectly
capable
of
translating
claims
from
evidence
to
results
where
appropriate.
H
It
moves
the
trans,
the
format,
translation,
overhead
away
from
constrained
endnodes
and
puts
it
in
a
verifier
in
a
data
center
somewhere,
which
is
where
it
belongs,
and
it
would
allow
us
to
merge
the
suit
rats
claims
document
into
the
ietf
suit
report
document
and
then
only
have
one
claim
added
in
each
which
would
cover
all
of
suit,
and
that
is
my
slide
deck.
So
questions
comments.
A
Go
ahead,
dave
dave,
filler
as
an
individual
participant
and
editor
of
t
protocol.
I
think
this
is
part
of
the
right
question.
What
you
have
on
the
slide
might
actually
be
the
answer,
but
I
wanted
to
up
level
the
question
into
multiple
possibilities
and
maybe
get
your
feedback
and
the
rest
of
the
working
groups
feedback
to
see.
A
If
this
is
the
right
one,
because
I
can
see
multiple
different
ways,
one
could
go
that
I
think,
are
consistent,
maybe
with
the
original
principle,
and
this
is
one
way
to
implement
them
and
it
might
be
the
right
one.
Okay,
so
I
can
imagine
of
for
completeness.
I
can
imagine
you
could
use
the
suit
report,
as
the
evidence
format
say
instead
of
eat.
Okay,
you
could
use
the
suit
report
in
evidence
like
encapsulated,
like
you
have
here,
which
is
you're
doing
it
inside
of
a
single
claim
inside
of
an
each
right.
A
So
you
have
this
report
inside
of
a
need.
You
could
do
it
translated
where
the
information
in
the
suit
report
becomes
information
in
the
eat,
and
I
think
that's
consistent
with
what
you're
saying
maybe
about
attestation
results
or
portions
of
attestation
results
and
portions
of
zero
reports.
Maybe
you
could
also
send
the
suit
report,
in
addition
to
evidence-
and
it
gets
to
the
evidence-
is
stuff
that
is
interpreted
by
a
verifier
and
here
in
the
tea
case,
the
thing
that
needs
the
information.
A
The
student
report
is
the
relying
party,
so
you
can
say
well
how
do
I
get
the
information
from
the
a
tester
or,
or
you
know,
suit
reporter
into
the
relying
party,
and
so
you
might
be
able
to
do
that
via
inside
the
attestation
exchange,
in
which
case
the
all
the
information
that's
needed
by
the
updater.
It
has
to
be
in
the
at
the
station
report
in
some
way,
so
you
got
to
go
through
that
pipeline
or
another
way
that
you
could
do.
It
is
to
say,
okay,
independent
of
attestation.
A
You
send
the
suit
report
directly
from
the
attesture
to
the
to
the
relying
party,
which
means
it
would
be
in
in
the
teap
case.
That
would
be
in
a
query
response
message
separate
from
the
evidence
field,
okay
and
so
in
terms
of
what
we
do
in
the
t
protocol
spec.
A
We
can
add
another
field
into
into
a
query
response
that
says:
here's
how
you
could
reply,
here's
how
you
could
pass
in
you
know
the
boot
time
suit
report
or
something
like
that
separate
from
the
evidence
field,
or
you
can
put
it
inside
the
evidence
field,
but
then
you've
got
to
make
sure
it
gets
translated
into
attestation
results
just
so
that
the
team
could
get
it
rather
than
getting
it
in
parallel
to
the
evidence.
So
those
are
the
different
possibilities
that
I
see.
A
I
have
no
objection
to
doing
what
brendan
what
brendan
is
saying
here
on
the
slide.
I
just
don't
know
if
that's
the
most
efficient
way
to
do
it
in
in
teep
or
if
we
should
also
have
a
way
of
having
suit
reports
directly
in
the
query
response.
Sorry
in
the
career
response.
In
addition,
the
evidence
field
just
so
it
goes
directly
to
the
relying
party
and
it
only
pays
attention
to
it.
If
at
the
station
succeeds
so
open
and
feedback,
hey
dave,
real
quick.
B
You
you,
you
said
a
lot
and
it
was
very
difficult
to
capture
in
the
notes.
Would
you
mind
typing
some
of
that
into
the
notes
for
us.
H
E
A
To
do
with
the
t
protocol
one
is
today:
there
is
no
requirement
for
a
teep
device.
You
know
a
teep
agent
capable
device
to
actually
keep
track
of
suit
reports
at
boot.
Time
right,
you
can
argue
that
there
is
a
requirement
to
keep
track
of
suit
reports
at
update
time,
okay,
but
there's
not
currently
a
requirement
to
keep
track
of
them
at
boot
time.
A
If
we
say
that
there's
no
claims
directly
in
eat,
then
I
think
it
does
introduce
a
requirement
to
have
suit
reports
at
boot
time
and
there
would
be
a
dependency
there
requirement
for
for
for
the
tp
agent.
So.
H
Yeah,
I
think,
on
this
one,
I'm
a
little
bit
less
concerned
about
what
happens
in
teep,
because
so
far
at
least
it
appears
that
teep
devices
are
typically
larger
and
have
more
power
available,
more
code
size
available,
more
memory
available.
So
maybe
that's
not
quite
as
big
of
an
issue
and
it's
fine
to
do
things
the
way
they
are.
I'm.
I
guess
I'm
more
thinking
about
more
constrained
devices.
H
A
D
So
yes,
let's
continue
this
discussion
on
the
list.
I'm
really
surprised,
given
that
the
first
presentation
took
us
a
half
hour
that
we
got
through
this
much
of
the
agenda.
D
D
Thank
you
very
much
to
the
note
taker,
especially.