►
From YouTube: IETF110-SUIT-20210311-1430
Description
SUIT meeting session at IETF110
2021/03/11 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
B
B
C
C
C
All
right,
everyone
welcome
to
the
suit
working
group
meeting
at
iatf
110.
My
name
is
dave
waltermeier
I'm
joined
with
my
co-chairs
russ
and
russ
housely
dave
fowler,
as
you
can
see,
there's
the
notewell
you've
probably
seen
this
a
few
times
so
far
this
week.
As
always,
let
us
know
if
you
have
any
questions
about
its
contents.
C
You
also
agreed
to
it
when
you
signed
up
for
this
meeting,
if
you
could
advance
to
the
administrative
tasks
russ.
Yes,
I
grabbed
the
wrong
slide.
When
I
went.
B
C
Much
better,
let's
see
so
so
dave.
We
have
two
note
takers,
we're
still
looking
for
one.
C
A
Wait,
if
I
remember.
E
A
Do
their
last
ietf
of
the
one
before
akira
helped
out
as
one
of
our
notetakers
it's
good
to
spread
the
wealth,
but
otherwise
I'm
wondering
if
akira
could
help
me
if
nobody
else
steps.
C
A
Okay,
akira
says:
okay
sure
I
know
akira
has
done
it
once,
but
so
it'd
be
great
to
have
a
different
volunteer,
but
I
appreciate
thanks
akira,
so
I
guess
we
can
go
on
and
I
will
try
to
keep
the
english
well
if
you
can
make
sure
that
I
don't
miss
anything
so
okay,
thank
you
jessica
great.
So
we
got
jessica
as
well
great,
so
the
three
of
us
will
do
it.
C
Okay
and
you
can
follow
along
on
the
the
cody
md.
Where
we'll
be,
you
know
actively
taking
notes.
So,
if
you
have
anything
to
add
to
the
notes
are
correct
feel
free
to
do
so
next
slide.
Please.
C
Today
we
today
we
have
a
pretty
full
agenda,
we're
going
to
be
covering
status
on
a
number
of
drafts.
We
also
have
an
update
on
the
secure
reporting
you
know
which
has
been
asked.
We
have
a
call
for
adoption,
you
know
currently
underway.
We
also
I
talk
about
some
new
work
and
if
we
have
time
we'll
we'll
have
open
mic
for
any
other
business.
Any
agenda
bashing.
F
I
I
think
there
might
actually
be
one
minor
bash.
It's
just
a
point
of
order
here,
which
is
that
the
the
question
of
recharter
seems
to
be
in
the
in
section
six,
but
it
strikes
me
that
it
probably
belongs
before
we
talk
about
secure
reporting.
F
A
C
Excellent,
so
we'll
we'll
cover
the
recharger
topic,
then,
in
the
the
last
item
in
general,
we've
done
fairly
well
with
our
milestone
so
that
we're
behind
on
getting
the
yeah
the
manifest
format
sent
to
the
isg
you
know
by
about
a
year
right
now
we're
pretty
close.
So
I
would
like
to
to
make
sure
that
we're
talking
about
during
that
segment
of
the
meeting
you
know
what
what
last
bits
of
work
needs
to
be
done
to
get
it
across
the
finish
line.
C
Next
slide,
please
that's
the
last
one!
Okay,
so
I
think
up
next
we
have.
We
have
brendan
or
honest
with
the
the
architecture
and
information
model.
C
C
F
F
F
All
right,
so
the
information
model
has
been
through
iesg
review
now
and
there's
a
few
items
of
feedback.
There
were
a
number
of
minor,
relatively
minor
knits,
but
I've.
I've
brought
up
three
points
that
seem
like
they
require
a
little
bit
more
discussion,
so
the
first
one
was:
why
are
we
constraining
device
identity
matching
to
uuids?
F
And
I
I
have
a
few
reasons
that
I
made
this
recommendation
in
the
first
place
and
the
indeed
that
that
we
we
discussed
previously.
I
think
so.
The
the
first
point
here
is
that
text
tends
to
end
up
getting
parsed.
It
rarely
stays
as
string
matching.
So
one
reason
for
using
uuids
is
to
encourage
people
to
do
the
right
thing
to
use
these
for
matching
an
identity
rather
than
matching
a
complex
sequence
of
characters.
F
F
So
if
you
need
something
human
readable,
it
should
be
in
the
text
section,
but
devices
don't
really
need
human
readable
things,
so
we
should
give
them
things
that
are
easy
for
devices
to
process
and
the
vendor
and
class
id
are
really
for
testing
applicability,
not
for
asserting
properties-
and
I
think
that's
an
important
point
that
gets
lost
a
bit
in
this
in
this
format
that
the
manifest
does
not
assert
properties.
F
So
that's
that's
essentially
my
my
feedback
for
the
uuids.
I
guess
the
question
here
to
the
group
is:
do
we
need
to
document
this
more
clearly.
F
I
I
guess
I'll
just
continue
on
here
and
we'll
do
some
discussion
at
the
end.
Does
that
make
sense.
C
That's
fine
if.
A
A
You
know
constraint,
discussion
the
context
of
I
think
it
was
rats
and
there
the
discussion
was
rats
and
teeth
basically,
because
there
it's
a
little
bit
different,
because
in
the
other
context
you're
trying
to
potentially
you
have
a
reason
to
say,
take
a
you
take
an
identifier
whether
it's
uid
or
whatever,
and
look
up
some
other
information
not
on
the
device,
but
on
the
management
side
like
if
you're
going
to
look
at
an
index
or
something.
A
But
here
if
it's
embedded
in
a
suit
manifest,
you
have
all
the
rest
of
the
suit
manifest,
including
any
you
know,
human
readable
strings
in
the
text
section
as
well,
and
so
I
think
the
reasons
that
other
groups
needed
to
go
with
something
beyond
a
uid
and
have
delegation.
A
My
belief
is
those
reasons
don't
apply
to
suit.
But
since
that
is
a
common
discussion
of
their
working
groups,
it
might
be
useful
to
say
what
you
just
said
and
to
distinguish
it
so
that,
because
it
seems
like
it's
going
to
be
a
frequently
asked
question
and
if
it's
a
frequently
asked
question,
it's
useful
to
have
a
frequently
answered.
One.
F
Okay,
then,
the
next
item
was
that
the
delegation
mechanism
was
too
vague,
so
this
is
delegation
specifically
in
the
context
of
delegating
from
one
signatory
to
the
next,
so
from
a
root
of
trust
through
multiple
delegate,
firmware
assigners.
F
This
was
deliberately
left
vague
to
leave
space
for
detail
in
the
in
a
given
manifest
serialization.
F
F
Right,
there's
a
requirement
on
secure
time,
specifically
for
the
expiration
of
manifests.
There
isn't
any
reference
in
that
description
on
including
a
reference
time
source.
The
only
thing
that's
defined
is
that
the
this
so-called
secure
clock
needs
to
be
monotonically
increasing,
among
other
things,
but
that's
the
key
requirement
and
it
doesn't
mention
a
reference
time
source.
So
the
question
is
whether
we
should
define
a
reference
time
source
as
being
part
of
having
a
secure
clock
or
not.
I
think
that
it
probably
makes
sense.
F
I
guess
the
only
argument
I
can
see
against
adding
that
text
is
that
you
could
quite
easily
have
a
secure
relative
clock
as
long
as
you
express
your
expiration
times
in
relative
terms.
However,
the
manifest
as
it
stands
today
uses
absolute
time
for
expiration
times.
So
that's
probably
not
the
the
right
answer,
so
I
think,
on
that
basis,
we
probably
should
make
a
reference
to
having
a
reference
time
source.
C
I
just
jumped
in
the
queue
speaking
as
individual
contributor.
I
mean
generally
secure.
Time,
though,
is
more
than
just
providing
a
time
source.
It's
about
verifying
that
the
time
came
from
that
source.
You
know
using
a
signature.
C
C
F
Okay,
well,
that's
it
for
the
information
model,
so,
barring
any
additional
commentary.
I
think
we
can
move
on
hannes.
I
guess
is
here.
E
I
only
wanted
to
point
out
that,
in
addition
to
those
three
which
I
think
are
the
the
meat
or
the
sort
of
the
core
questions
that
haven't
been
addressed
in
the
with
the
latest
draft
update,
there
are
also
a
few
others
which
we
need
to
go
through
and
it
didn't
work
out
to
do
those
in
time
for
the
deadline.
E
So
I'm
going
to
do
the
update
next
week
on
those
or
or
this
weekend,
so
it's
only
sort
of
nits
and
things
that
need
to
be
changed
here
and
there
yeah.
E
But
it's
coming
to
an
end.
I
would
say
with
also
with
the
changes
that
or
proposed
changes
that
we
just
discussed.
B
Regarding
delegation,
I
think
we
need
a
little
more
detail,
but
not
everything
that's
in
manifest,
and
so
I'm
hoping
we
can
come
up
with
a
enough
that
makes
it
clear
what's
going
on,
but
at
the
same
time
I
don't
think
we
want
to
dilute,
what's
in
the
manifest
to
the
point
that
it
makes
it
hard
for
an
implementer
to
find
the
text.
B
F
Yeah,
I
I
mean
I
wouldn't
be
against
having
a
examples
document.
That's
separate,
I
don't
think
there's
anything
wrong
with
that
and
the
the
other
aspect
of
that
is
that
we
can
add
to
it
over
time.
If
that's,
what
is
helpful.
B
Yes,
that
that
approach
was
taken
for
s
mine,
and
so
there
was
both
good
and
bad
examples
there,
so
that
you
could
say
this
is
expected
to
fail.
This
is
expected
to
succeed.
We
can
do
that
if,
if
there's
somebody
willing
to
put
the
time
into
it,.
F
Okay,
well,
that
that
I
mean
that
is
probably
a
question
that
we
should
discuss
when
we
get
to
the
manifest,
which
I
think
is
now.
I
could
be
wrong.
G
I
just
wanted
to
pull
on
the
thread
about
the
examples
I
know:
there's
sometimes
cultures
and
working
groups
or
rumors-
that
the
isg
doesn't
support
these
add-on
documents.
These
add-on
informational
documents
relative
to
protocol
specs.
I
personally
find
them
really
helpful
for
implementers,
especially
you
know
if
you're
co-developing
it
with
the
spec
or
after
the
spec
is
made
just
to
be
very
practical
to
show
those.
So
I
you
know
on
a
from
a
personal
perspective,
I
think
we
should
do
it
as
an
ad
I'll,
happily,
support
support
such
a.
F
Okay,
so
there's
a
new
version
of
the
suit
manifest
up
there.
There
are
very
few
changes,
so
there
were
a
couple
of
examples,
changes
and
it's
just
that
there
were
errors
in
the
encoding,
and
this
had
to
do
with
the
cddl
getting
out
of
sync
from
the
example
generator,
so
that
has
been
fixed
now
and
and
in
terms
of
of
editorial
changes.
That's
it.
F
There
was
one
feature
edition
which
is
on
the
next
slide
and-
and
that
is
a
specific
request
from
teep
teep-
requested
the
ability
to
delete
a
component.
Now,
the
problem
with
deleting
a
component
as
an
imperative
is
that
it
can
end
up
causing
a
lot
of
dependency
problems.
If
you're
able
to
delete
a
specific
component
and
that's
depended
on
by
an
out
of
tree,
manifest
a
or
indeed
a
diamond
dependency,
then
you
can
end
up
with
a
broken
system
fairly
easily.
F
There's
also
questions
about
who
actually
has
the
authority
to
delete
trusted
components,
and
then
there
are
right,
two
different
tas.
Yes,
so
the
other
question
is
what
happens
when
it's
already
been
deleted
and
in
terms
of
the
atomic
nature
of
manifests
or
of
updates?
There's
the
question
of
what
happens
if
you
use
a
component
part
way
through
an
update,
then
delete
it
and
then
something
fails
afterwards.
F
You
no
longer
have
the
component
that
you
need
to
be
able
to
to
use
it
in
the
first
part
of
your
manifest
when
you
have
to
try
again
and
and
so
you
can
end
up
breaking
the
entire
manifest,
even
though
it's
supposed
to
be
atomic,
so
I
think
that
either
an
unlink
or
a
garbage
collect
type
idiom
would
make
more
sense
to
me
next
slide.
Please.
F
You
might
also
include
something
like
decrementing
a
reference
count
on
that
component
and
the
idea
here
is
that
if
it's
marked
and
its
reference
count
is
zero,
then
at
the
end
of
the
current
section
or
or
indeed
here,
where
section
is
used,
it
may
mean
the
the
whole
process
of
doing
either
a
secure
invocation
or
a
or
an
update,
and
that's,
I
think,
probably
the
most
likely
approach
when
that's
done,
then
the
manifest
processor
will
check
all
of
the
marked
components
and
any
that
have
a
reference
count
of
zero
can
safely
be
removed,
since
they've
they've
already
been
used
to
the
degree
that
they
are
likely
to,
and
there
shouldn't
be
any
dangling
atomicity
problems.
F
So
I
I
I
would
support
the
addition
of
a
garbage,
collect
or
or
an
unlink
directive,
and
I've
put
one
of
those
into
version.
12.
I'd
be
very
interested
in
the
working
group's
feedback
on
on
that
approach
to
explicitly
removing
a
component.
F
So
after
this
slide,
my
contents
done
and
we'll
hand
over
to
hanas.
So
if
there
are
any
questions
or
comments
on
this,
I
think
this
would
be
a
good
time
to
break
for
them.
A
Sure
so
I
think
I
jumped
in
cue,
so
I
think
from
the
cheap
requirements
perspective.
I
think
that
the
unlink
or
garbage
collect
would
be
perfectly
fine.
So
in
other
words,
I
would
support
that
proposal.
I
think
the
only
constraint
to
make
clear
in
the
text
or
examples
or
something
that
part
of
the
teep
requirement
comes
from
the
case
where
you
may
have
limited
capacity
and
you're
trying
to
say
remove
one
component
in
order
to
free
up
space
to
do
an
install
of
a
different
component
where
the
first
component
is
no
longer
needed.
A
F
A
A
That
in
the
teep
case,
there's
two
independent
things
that
are
happening
right.
One
is,
I
no
longer
need
component
x,
it's
just
an
app.
It's
no
longer
needed
for
anything.
In
other
words,
it's
a
trusted
app.
So
it's
not
an
app
that
the
normal
user
thinks
of
as
an
app
right.
It's
a
it's
a
binary
that
runs
in
the
tee.
A
That
is
not
directly
user
visible.
It's
a
library,
that's
consumed
by
other
applications
that
may
no
longer
exist
right,
so
you
can
clean
up
some
space
there.
That's
one
thing
separately:
the
authority
over
the
tam
wants
to
install
another
app.
Now
it
could
do
those
in
two
completely
separate
manifests
and
two
completely
separate
protocol
exchanges,
and
it's
just
trying
to
bundle
them
to
do
them
at
the
same
time,
because
there's
a
strict
ordering,
if
there's
a
resource
requirement
that
says,
I
can't.
E
A
The
second
one
in
there
it's
going
to
fail
due
to
out
of
space
unless
the
first
one
does,
and
so
is
there
a
way
to
bundle.
Those
two
suit
manifests
into
a
strict
ordering,
but
there's
no
dependency
other
than
the
ordering
right.
The
first
one
either
succeeds
or
fails.
The
second
one
can
only
succeed
if
the
first
one
succeeds
right.
That's
what's
the
right
way
to
express
that,
and
I
think
you
can
do
that
by
bundling.
The
two
suit
manifests
into
a
common
manifest
that
just
has
an
ordering
in
between
them.
F
I
I
yes,
you
can
I
I
guess
the
question
is
so
right,
so
this
shouldn't
be
such
a
big
problem,
because
the
components
that
you're
talking
about
should
already
have
before
you
start
no
references.
If
you're
deleting.
E
F
Thing
there
shouldn't
be
any
references
to
it,
which
means
that
the
moment
you
get
to
I'm
expressing-
I
don't
have
any
interest
in
this,
and
it's
already
got
a
zero
dependency.
Then
that's
should
be
a
reasonably
safe
thing
to
remove
directly.
A
I
think
the
issues
you're
worried
about
yeah.
I
think
the
issues
that
you're
worried
about
and
why.
I
think
that
this
solution,
I
think,
is
fine,
come
up
in
the
non-teep
cases,
because
huge
is
useful
for
other
cases
too.
So
you
have
to
protect
it
and
that's
why.
I
think
this
is
a
better.
The
unlink
or
garbage
collect
semantic
is
better
in
general.
A
I
just
want
to
make
sure
that
it
actually
solves
the
t
case
and
specifically
when
you
start
by
having
no
references
to
it
and
it
is
nice
and
efficient,
but
it's
also
safe
to
use
outside
of
teep,
and
I
think
this
proposal
goes
in
that
direction.
But
that
was
my
question
about
what
you
meant
by
once.
The
current
section
is
complete.
F
Yeah,
no,
I
actually
did
mean
something
different,
so
I
I
mean
when
the
update
process,
the
whole
update
process
is
fully
complete.
That's
the
time
to
actually
do
the
garbage
collection,
but
I
think
what
we
can
have
is
a
special
case
where
there
are
no
references
to
start
with
so
rather
than
starting
at
one,
which
would
be
the
standard
situation
for
a
dependency.
F
You
would
start
at
zero
and
since
you're
starting
at
zero.
You
know
that
this
is
not
required
and
that
a
failure
later
on
in
the
process
isn't
going
to
render
your
system
inoperable.
Then
it's
safe
to
do
a
direct
removal
right
away.
I
think
that
should
be
a
reasonably
safe
approach.
A
Okay,
so
I
see
david
brown
is
in
queue
after
me,
but
so
I
just
let
me
just
make
one
last
comment
and
then
I
will
see
if
david
has
a
response
to
this
discussion.
There's
hey
sorry!
I
just
lost
my
training
yeah,
there's
two
different
ways
that
teep
could
could
accomplish
this
between
teep
and
suits
right.
We
could
either
say
suit's
gonna
do
it,
in
which
case
you
do
what
you
just
summarized.
A
If
we
did
not,
if
that
caused
problems
for
something,
then
the
other
workaround
was
that
teep
would
pass.
Two
independent
suit
manifests
in
the
same
message
and
just
run
through
the
process.
Super
processing
of
those
two
manifests
sequentially
right,
and
so
that
would
be
the
workaround.
If
suit
can't
solve
it,
then
teep
could
just
more
work
for
t
right,
just
which
working
group
does
it.
So
that's
why
I
prefer
what
you
just
described
brendan
but
david.
You.
A
H
All
right
is
my
audio
working.
Yes
perfect.
I
guess
the
question
I
would
have
is
this
reference
count,
an
ephemeral
thing.
That's
part
of
the
pro
the
update
processor.
Is
this
a
persistent
piece
of
data
associated
with
each
image?
H
If
it
were
persistent,
it
would
make
sense
that
you
would
come
in
at
the
beginning
of
this
process
with
a
reference
count
already
0,
and
that
would
be
known,
whereas
you
know
say
a
previous
update
removed
what
it,
what
depended
upon
it
and
the
garbage
collect
maybe
could
be
implemented
so
that
when
it's
asked
to
remove
the
item,
if
the
reference
count
is
zero,
it
could
remove
it
then
otherwise
later,
but
that
does
require
storing
this
more
persistently
than
just
during
an
update.
F
F
If
you
don't
have
apps
that
you
can
install
inter
independently,
then
this
is
completely
irrelevant.
If
you're
dealing
with
system
images
that
have
dependencies,
this
doesn't
become
relevant
if
you,
but
when
you
have
the
ability
to
install
individual
applications
and
those
applications
may
have
dependencies,
then
this
reference
counting
thing
starts
to
become
a
question.
H
H
A
Yeah,
just
one
other
point
of
clarification
when
we
say
apps
I
I
would
generalize
that
to
the
real
case
is
really
about
like
shared
libraries
right
it
just
so
happens
that
in
teeth
and
a
trusted
app
is
basically
a
shared
library.
But
if
you
want
to
generalize
it,
the
things
with
references
are,
you
can
think
of
as
just
being
shared
libraries
anytime,
that
you
have
a
multiple
reference
counts
of
dependencies
on
it.
It's
basically
a
shared
library.
So
that's
the
case.
We're
talking.
E
E
Okay,
I
hope
you
can
hear
me
next
slide.
E
E
I
looked
at
the
mcu
booth
as
a
sort
of
as
a
real
world
example
on
what
is
done
today
and
also
spoke
to
david
brown,
who
was
on
the
on
the
microphone
previously
about
what
functionality
is
used
and
what
they
have
implemented
and
how
they
did
it
and
so
on
and
looked
at
that
code,
and
there
were
two
mechanisms,
namely
sort
of
a
symmetric
key
based
version
of
encryption
as
well
as
well.
E
I
should
say
both
of
them
use
symmetric
keys
to
encrypt
the
firmware,
because
it's
it's
larger,
but
for
the
key
exchange,
there's
the
symmetric
key
version,
which
is
the
the
aes
keywrap
and
then
there's
the
asymmetric
key
version
which
uses
elliptical,
tiffy
helmet
and
and
I'm
going
to
walk
you
through
how
that
looks
like
when
embedded
into
the
suit
manifest
as
a
reminder.
So
I
I
don't
know
if
how
many
of
you
remember
what
the
cosy
spec
says
among
the
different
options.
E
But
those
are
two
of
them,
and
so
I
picked
those
because
of
because
they
map
closer
to
what
is
being
done
already
today
in
mcu
boot,
and
I
also
looked
at
other
boot
loaders
from
nxp
and
sd
microelectronics,
which
I
use
something
very
similar.
E
Obviously,
so
the
encryption
is
typically
used
in
in
two
cases,
as
david
brown
also
confirmed
to
me,
one
is
when
you
have
a
firmware
image
stored
on
an
external
flash,
and
then
you
use
obviously
the
decryption
operation
to
put
it
on
the
internal
flash,
because,
obviously
you
can
only
operate
on
the
decrypted
image
to
actually
do
an
execute
in
place.
E
The
other
option
is
when
the
encrypted
image
gets
decrypted
and
then
put
into
into
ram
for
execution
there,
the
former
being
more
common,
so
in
the
in
the
aes
128
key
wrap
case
and
I'll.
Try
to
summarize
real,
quick
russ
is
the
delete
also
on
that
rfc.
E
So
in
essence,
there
are
two
keys
being
used.
One
is
the
content,
encryption
key
or
keck,
which
is
used
to
encrypt,
in
our
case
the
firmware
or
software
or
whatever
we
want
to
encrypt
this
suit,
and
the
other
one
is
the
key
that
is
used
to
encrypt
that
content.
Encryption
key,
which
is
also
pronounced
keck,
but
it's
the
key
encryption
key
and
the
ca
key.
The
content,
encryption
key
is,
is
randomly
generated
and
in
they
externally
provide
key
encryption.
Keys
then
used
to
to
protect
it.
E
So
that's
a
relatively
simple
technique,
as
you
will
see
later
more
complicated,
though,
is
the
the
public
key
based
variant
of
it.
Oh
it's
yeah,
so
it's
the
course
respect
calls
it
elliptic
curve
tv,
helmet,
ephemeral,
static,
plus
aes,
key
wrap,
and
the
procedure
is
roughly
as
follows.
E
E
If
you
have
an
operation
on
the
using
its
private
key
that
the
one
that
he
just
created
in
the
in
the
previous
step,
with
the
static
public
key
of
the
recipient
of
the
iot
device
and
generates
this
symmetric
key-
which
I
call
it
here-
ecdh
shared
and
then
it
needs
to
apply
an
hkdf
function
which
I
will
get
into
later,
because
I
think
it's
I'm
quite
relevant
to
the
terms
of
types
of
profiling.
We
are
doing,
and
this
produces
the
content,
encryption
key
and
the
the
key
encryption
key.
E
So
the
reason
I'm
I'm
pointing
those
out
is
because
those
are
only
two
mechanisms
out
of
the
a
range
of
different
techniques
that
are
made
available
with
cosi,
and
I
really
think
that
we
have
to
nail
it
down
to
a
few
of
them
and
describe
them
precisely
so
that
there
is
some
level
of
intro
ability
and
also
the
code.
Size
is
manageable.
Next
slide,
so
start
off
with
the
simpler
one
with
this
keywrap.
E
So
this
is
how
it
looks
like
in
a
as
an
example,
I
shortened
the
encrypted
content
encryption
key
here,
but
otherwise
it's
it's.
This
should
be
a
working
example.
If
I
got
it
right,
so
this
is
a
cozy
encrypt,
not
a
cozy
encrypt
zero.
So
I
I
suggest
only
use
the
encrypt
version,
which
includes
information
about
the
key
that
is
being
used,
which
I
think
is
quite
useful.
E
The
yellow
box
is,
is
information
used
to
encrypt
their
the
firmware
and,
and
so
the
first.
The
first
bucket
here
is
sort
of
the
protected
field
which
just
encodes
the
algorithm
being
used
here
in
our
example:
aes
gcm
128.
E
The
second
bucket
is
an
unprotected
field,
so
called
unprotected
field,
or
it's
actually
unprotected.
Well,
actually,
the
whole
thing
is
protected,
but
leaving
that
aside,
there's
the
iv
in
there
or
the
nons
that
we
use
with
the
aad
cipher,
and
then
we
use
only
a
detached
cipher
text,
so
the
firmware
image
is
not
included
in
here.
So
that's.
Why
there's
a
null
as
the
last
line
in
this
yellow
box.
E
If
we
go
to
the
blue
box,
this
is
the
information
needed
for
the
keywrap
and
it
essentially
says
here's
the
algorithm
for
keywrap.
Here's,
the
key
identifier
for
the
that
identifies
the
the
key
encryption
key
that
is
used
then
to
encrypt
this
randomly
generated
keck
the
content,
encryption
key,
which
is
the
last
line
here
this.
So
this
is
then
and
if
I
hope
it's
correct,
but
this
is
how
then
the
example
would
look
like
and
with
of
course,
alongside
with
the
encrypted
firmware
image?
E
Okay,
that's
so
there's
one
thing.
C
H
David
over
there,
okay
yeah,
the
question
one
is
is
actually
in
regards
to.
You
mentioned
the
two
use
cases
for
this.
I
just
wanted
to
point
out.
I
remember
a
third
one
that
hasn't
gotten
implemented
in
mcu
boot
and
there
are
microcontrollers
that
support
loading,
a
content,
encryption
key
into
the
hardware
and
are
able
to
execute
directly
in
place
from
an
encrypted
image.
So
I
just
wanted
to
point
out
that
that
is,
I
know
of
real
examples.
They
just
didn't
get
upstreamed
into
the
mcu
boot
code.
E
Yeah
that
that's
true,
there's
there's
some
it's
a
it's
a
rare
case
of
microcontrollers.
I
I
forgot
which
one
it
is,
but
it's
it
basically
has
the
hardware
capabilities
to
do
the
decryption
in
hardware
rather
than
doing
something
in
software
which
would
require
copy
things
around.
E
You
could
also
argue
that
another
benefit
of
encryption
is
which
I
didn't
mention
is
like.
You
would
additionally
encrypt
the
binary
all
the
way
from
the
firmware,
also
to
the
the
software
that
or
to
mcu
boot,
for
example.
E
Okay,
next
slide
yeah,
so
the
the
aes
key
wrap
needs
an
additional
data
structure,
and-
and
this
is
encoded,
as
shown
on
the
screen
which
the
cozy
spec
defines
so
there's
the
there's
a
string,
then
there's
the
protected
field
and
then
some
external
additional
data,
and
my
suggestion
is
to
have
the
external
additional
data
defined
as
null
and
and
the
my
reading
of
the
specification
is
that
the
protected
field
here
since
we
have
two
protected
fields,
refers
to
the
outer
protected
field
so
to
the
yellow
box,
not
to
the
blue
box.
E
I
had
shown
on
the
previous
slide,
but
I
I
would
need
someone
else
to
confirm
that
that
was
my
understanding
of
the
spec,
but
in
talking
to
rasa
I
have
misinterpreted
this
spec
in
other
places.
So
I
I'm
I'm
trying
to
be
a
little
bit
cautious
here.
So
there's
some
clarification
needed.
E
I
don't
think
this.
The
null
for
the
external
aad
is
controversial,
so
I
will
skip
to
the
next
slide.
E
Okay,
this
is
the
more
complicated
technique,
but
security-wise
better,
so
there's
another
as
you
can
immediately
see
it.
First
of
all,
it
didn't
fit
on
one
screen,
but
so
there's
a
second
one,
but
there's
also
another
layer
in
here.
In
addition
to
the
boxes
I
explained
previously,
which
is
a
slightly
change,
but
I
will
glance
over
those
aspects.
E
G
E
And
then
otherwise,
there's
there's
a
lot
of
similarity
here
in
in
terms
of
the
the
structure.
Okay,
next
slide,
there's
here
for
completeness,
there's
the
ephemera
structure
which
which
contains
this
bubbly
key.
It's
a
cozy
key
structure
which
also
has
a
couple
of
options
and
in
in
the
code
I've
been
working.
E
The
y
component
could
be
replaced
by
just
the
sign
bit,
but
I
include
the
the
y
component
of
the
key
because
I
couldn't
figure
out
on
how
to
get
this
to
work
with
the
embed
dls
api,
but
I'm
going
to
look
into
that
so,
but
I
would
suggest
to
have
one
specific
encoding
rather
than
the
choices
that
are
being
offered,
because
you
can
have
compressed
points
and
and
of
course,
there's
also
the
question
about
what
curves
and
what
algorithms
should
be
recommended
in
the
suit
specification,
because
there
are
obviously
also
a
lot
of
choices.
E
I
didn't
go
into
the
algorithm
recommendation
here
actually,
so
this
is
the
complicated
part
which
I
think
is
really
important
to
also
specify
the
in
the
document
is
because
here
that,
in
the
gray
box,
you
see
how
the
procedure
works
to
generate
this
con.
This
key
encryption
key,
it's
basically
using
an
hkdf
on
applied
to
the
ecdh
shared
key
with
some
context
and
the
context
is
rather
complicated.
E
It's
this
cozy
structure,
which
needs
to
be
populated
with
different
parameters,
and
there
there's
the
identities
of
the
two
parties,
and
I
assume
you
and
we
in
our
case
refer
to
you-
would
be
the
firmware
author
or
the
the
party
that
generates
the
encryption
and
v
is
the
recipient.
E
So
in
our
case
the
iot
device,
and
so
the
key
id
would
be
a
good
fit
for
the
for
the
recipient,
because
that's
something
we
already
include,
as
I
mentioned
previously,
for
selecting
the
right
key
on
on
the
iot
device
for
the
elliptic
curve,
dv
helmet.
But
for
the
sender
I
wasn't
quite
sure
what
what
identifier
to
include
here.
E
So
that's
something
that
needs
to
be
worked
out.
There
are
also
nonsense
in
all
of
those
body
infrastructures
which
I
would
suggest
to
use
nil
or
null
here,
because
I
didn't
really
know.
I
couldn't
figure
out
what
nonsense
we
could
use
here.
We
could
probably
carry
some
additional
nonces
in
in
the
payload,
but
I
I
wasn't
sure
what
added
value
those
would
provide.
E
So
maybe
someone
has
some
ideas
and
has
different
use
cases
that
would
justify
this
and
then
there's
also
the
it's
called
sub
pub
info,
which
contains
the
protected
parameter
and
the
algorithm
id
the
date
and
the
key
lens
and
again
here
that
the
challenge
is
like.
Ideally,
what
parameters
would
be
used
here?
E
Would
we
use
the
algorithms
that
are
used
to
encrypt
the
cac
or
would
be
used
so
essentially
the
information
from
the
yellow
box
or
from
the
blue
box,
which
at
least
from
my
reading
of
the
spec
of
the
cosy
spec,
at
least
wasn't
wasn't
clear
to
me
and
then
there's
some
other
and
and
some
additional
information
which
I
would
have
also
suggested
to
to
use
null
here
or
to
not
populate
unless
there's
there's
a
good
reason.
But
maybe
maybe
someone
of
you
has
an
idea:
russ
david.
B
E
Okay,
so
so
in
that
so
ideally
like
for
the
scheme,
since
the
cinders
ephemeral
keeper,
it
was
supposed
to
be
ephemeral,
as
the
name
says
they
are.
Probably
you
wouldn't
want
to
include
the
nons,
but
what
about
the
static?
The
static
key
of
the
recipient,
which
clearly,
as
the
name
suggests,
is
static?
E
So
what
would
you
recommend
in
terms
of
like
specification
because,
ideally
like
this
is,
I
would
like
to
leave
as
little
options
as
possible,
because
it
makes
this
implementation
simpler.
E
B
H
Yes,
I
just
wanted
to
add.
As
far
as
the
nonce
goes,
we
have
patches
coming
into
mcu
boot
to
implement
the
nonce,
but
within
mcu
boot,
despite
the
applic.
You
know,
all
of
our
uses
do
only
use
this
to
encrypt
one
image.
Ever
one
of
the
users
basically
decided
through
their
security
analysis
that
the
the
encryption
had
not
been
studied
without
the
use
of
a
nonce
and
they
felt
more
comfortable
having
it
in
there.
So,
within
a
few
weeks,
probably
mcu
boot
itself
will
support
announce
it.
H
C
I
actually
have
a
question
about
that.
It
seems
like
if
we
do
this
in
the
manifest
document
that
this
is
going
to
push
the
time
that
we
publish
the
document
out.
You
know
quite
a
quite
a
bit,
and
you
know
just
an
observation.
We
we
tend
to
have
a
pattern
of
you
know
getting
the
manifest
document
fairly
close
to
done
and
then
adding
features
to
it,
and
you
know
that
has
been
kind
of
extending.
C
You
know
the
time
that
we're
working
on
it.
You
know
I'm
interested
in
thoughts
on
how
we
might
be
able
to
you
know,
split
this
work
in
a
way
that
would
allow
us
to
move
forward
with
the
manifest
but
still
address.
You
know
this
this
problem
space,
any
any
ideas
on
that.
F
Is
essentially
the
same
as
what
I'm
recommending
with
the
examples
at
the
moment,
not
necessarily
that
we
take
the
examples
that
are
in
there
and
split
them
out,
but
that
any
additional
ones
could
get
adopted
into
a
new
examples
document.
I
think
here
we
might
want
to
also
consider
the
possibility
of
defining
a
set
of
profiles
and
having
those
profile
definitions
live
in
a
separate
document
as
well.
I
think
that
we
could
make
a
pretty
sound
argument
for
saying
you
know
a
we've.
F
You
know
this
is
a
minimum
device,
and
these
are
the
features
it
has,
and
this
is
the
minimum
device
with
encryption,
and
these
are
the
things
you
have
to
implement.
So
I
think
that
we
could
probably
make
an
argument
for
defining
profile
documents,
informational
ones
as
separate
from
the
the
primary.
B
B
Profiles
are
inevitable,
I
think
when
we
have
algorithm
choices,
so
I
think
it'll
be
interesting
when
we
get
to
what
are
the
mandatory
to
implements,
because
that's
what
will
get
us,
you
know
a
base
spec,
but
profiles
that
that
address
different
communities
are
gonna
happen.
So
let's
just
be
realistic
and
and
set
that
up.
But
the
features
that
are
being
discussed
here
are
already
in
the
spec,
we're
just
talking
about
how
to
use
them
right
with
the
with
the
profile
with
the
algorithms
that
hana
started.
The
presentation
with.
C
Are
dave
dave
tyler,
and
I
were
talking
briefly
about
that.
You
know,
given
that
this
is
one
of
our
like
significant
work
items.
It's
probably
worth
you
know,
spending
the
time
to
move
this
forward
it
as
far
as
I
just
had
one
question
and
we
can
move
on
the
as
far
as
the
mtis
is
that
something
that
we
want
to
do
in
a
separate
draft
to
you
know
to
be
able
to
support
algorithm
agility
without
having
to
revise
the
base.
Spec.
C
C
E
Oh
sorry,
I
I
lost
internet
connectivity.
Okay,
did
you
move
on
in
the
meanwhile.
C
No,
we
were
just
having
a
discussion
about.
You
know
how
we
maybe
split
some
of
this
work
in
a
way
that
would
allow
us
to
move
forward
with
the
base
spec.
While
you
were
gone.
B
Yeah
other
other
security
protocols
have
put
algorithms
in
a
separate
doc.
Just
so
that,
if
the
base
protocol
were
to
advance
to
internet
standard,
then
the
algorithms
could
still
be
changed
without
pulling
the
bass
back
down
the
back
right.
The
ladder
yeah
right.
E
That
makes
sense,
yeah
yeah,
and
would
you
include
algorithms,
like
the
key
exchange
algorithms
are?
Are
you
talking
mostly
about
sort
of
like
let's
say,
aes,
gcm
versus
c
ccm
or
so.
D
E
Because
I
think,
without
detailing,
like
these
parameter
configurations,
on
the
left
hand,
side
the
or
the
right
hand
side
these
bullet
list,
I
fear
that
there
would
be
like
with
no
guidance
chances
that
two
implementations
are
interoperable,
are
close
to
zero.
C
Right
and
I
guess
the
question
that
I
raised
on
this-
was
you
know
doing
this?
Work
is
gonna,
add
time
more
time
to
our
schedule.
You
know
for
getting
this
published
and
I
was
looking
for
ways
to
you
know
to
move
the
base
back
forward.
While
we
work
on
some
of
these
things.
E
Yeah,
maybe
maybe
one
possibility
is
to
just
have
the
very
basic
functionality
in
there,
like
the
aes
key
wrap
that
I
presented
at
the
beginning
and
to
have
the
sort
of
more
sophisticated
version
then
covered
separately.
E
If
you,
for
example,
if
you
advance
to
the
next
slide,
there
was
also
a
question
well
or
maybe-
maybe
even
the
one
further,
this
one.
So
I
I
I
noticed
that,
like
there
are
obviously
many
different
public
key
elliptical
public
key
encryption
schemes
and
selecting
one
of
them
is
is
like
is
tricky,
but
luckily
there's
there's
also
work.
E
So
clearly,
there
are
a
number
of
choices
given
by
the
cosy
spec,
but
then
there's
also
some
more
recent
work
done
in
the
cfrc
on
the
hbka,
which
is
this
hybrid
public
key
encryption
scheme,
and
maybe
maybe
that's
also
sort
of
right.
At
least
I
thought
it
would
be
useful
to
look
into
this,
because
this
is
currently
being
sort
of
incorporated
into
the
dls,
1.3,
client,
hello,
encryption
and
also
mls
uses
it.
E
So
maybe
maybe
there's
a
possibility
here
for
reuse
as
well,
and
then
also
the
case
of
multiple
recipients,
which
the
mechanisms
I
I
explained
earlier.
Support
are
supported
by
those
two.
That's
also
something
to
consider.
E
A
Get
to
the
end
of
this
discussion
for
today,
because
we've
only
got
about
four
minutes
left,
and
so
I
guess
what
I'm
hearing
so
far
is
proposals
to
put
the
encrypted
by
the
the
use
of
suit,
for
you
know,
encrypted
binaries
and
things
the
details
all
into
a
separate
document,
and
if
we
do
that,
then
I
guess
my
preference
would
be
to
put
as
much
of
the
discussion
about
that
as
possible
into
a
separate
document
and
just
make
sure
that
the
base
spec
includes
is
easy
to
extend
in
another
document
and
say
you
know
such
and
such
is
left
for
a
future
document
and
that's
fine
as
long
as
it
does
not
have
to
you
know,
update,
but
only
extend
the
base
spec,
then
that
seems
to
be
a
good
decoupling
rather
than
saying
putting
some
part
of
it
in
the
base
spec
and
some
part
of
it
in
a
separate
document.
A
That
includes
examples.
You
know
if
there's
any
new
commands,
I
don't
know
if
there's
any
I've
not
heard
any
yet,
but
you
know
all
the
algorithm
stuff
and
so
on,
and
if
we
do
that,
because
roman
is
asking
you
know
what
is
the
new
milestones
we
would
set,
because
I
think
that
type
of
approach
would
allow
us
to
have
a
earlier
milestone
for
the
earlier
date
for
the
base
spec,
because
it's
pushing
more
of
the
stuff
into
the
other
spec,
which
would
have
a
later
milestone.
A
C
Yeah
I
agree
I
was
gonna,
suggest
something
similar
yeah
and
we'll
have
to
factor
this
into
our
charter
update.
B
Definitely
so
with
only
two
minutes
left,
I
wonder
if,
if
brenda
you
want
to
even
start
one
of
these
other
presentations
or
we
should
just
push
that
to
the
internal.
E
F
I
I
I'm
not
sure
I
think
the
the
the
big
question
for
me
is
following
on
from
the
previous
discussion
here:
do
you
think
that
it
makes
sense
to
factor
out
all
of
the
examples
that
currently
live
in
the
manifest
document,
or
simply
say
that
additional
examples
may
show
up
as
time
permits
the
the
essentially?
F
What
I'm
saying
here
is:
does
it
make
sense
to
provide
some
examples
so
that
implementers
know
how
this
fits
together
without
necessarily
having
every
possible
example,
or
should
we
move
all
examples
out
to
a
new,
a
new
document?
B
Yeah,
I
think
we're
gonna
have
to
discuss
that
on
the
list,
but
there
there's
clearly
advantages
to
implementers
to
have
them
so
yep.
You
know.
F
C
All
right
we'll
do
that
then.
So
I
guess
with
that
we're
out
of
time.
So
sorry
brandon,
we
weren't
able
to
get
to
the
other
topics,
but
we
wanted
to
make
sure
we
were
making
progress
on.
You
know
the
the
base
spec
here
thanks
for
presenting
and
with
that
I
think
we're
gonna
wrap
things
up.
We
have
a
few
discussions
that
we're
gonna
take
to
the
list.
There's
some
rechartering
work
that
needs
to
be
done,
which
we'll
also
take
to
the
list.
C
I
guess
with
that.
Thank
you
and
we'll
we'll
talk
to
you
soon
at
the
hopefully
at
the
virtual
interim.
Thanks
again.