►
From YouTube: IETF104-SUIT-20190327-0900
Description
SUIT meeting session at IETF104
2019/03/27 0900
https://datatracker.ietf.org/meeting/104/proceedings/
A
C
A
C
C
We've
also
received
a
leis
on
statement
from
the
itu-t
SG
17,
which
we'll
be
talking
about
in
a
little
bit,
they're
working
on
a
document
describing
usage
scenarios
around
software
updates,
they've
shared
a
draft
document
with
us.
That's
posted
out
on
the
data
tracker
and
they're
seeking
comments
on
that
draft,
as
well
as
alignment
with
the
work
that
we're
doing
here
in
the
working
group.
Their
next
meeting
is
in
August.
C
C
It
talks
about
some
of
the
prior
work
that
has
occurred
within
the
IETF
and
elsewhere
on
this
topic.
So
basically
what
the
document
does
is.
It
defines
some
some
basic
requirements
for
some
of
the
key
architectural
roles
that
participate
in
the
software
update
process.
This
is
mostly
consistent
with
our
architecture.
Doing
a
deeper
read
of
the
document,
though
I
think
there
is
some
ambiguity
over
the
function
of
status
trackers,
especially
with
relating
to
delegation.
I'll
talk
a
little
bit
about
that.
C
More
close,
8.1
I'm
in
the
document
requires
that
an
IOT
device
has
a
status
tracker
which
is
slightly
different.
That
are
thinking
about
the
topic
next
slide,
please,
so,
generally,
the
way
they're
defining
a
software
updates
is
I'm,
starting
on
the
right
hand,
side.
You
have
an
offer,
an
author
who
creates
a
firmware
image.
They
publish
that
image
to
a
firmware
server,
starting
on
the
left
hand
side.
C
You
have
a
status
tracker
that
is
responsible
for
tracking
the
current
update
status
of
the
consumer
and
then
initiating
a
firmware
update
when
an
update
is
needed,
the
it
instructs
the
firmware
consumer
to
to
perform
that
updates.
The
consumer
then
requests
the
firmware
from
the
firmware
server,
providing
the
image
back
to
to
the
consumer,
either
embedded
or
by
downloading
the
consumer
can
then
verify
and
install
the
firmware
and
report
at
the
updated
status
to
the
status
tracker
next
slide.
Please.
C
C
The
updates
so
I
think
there's
an
opportunity
for
us
to
provide
some
feedback
just
to
seek
some
clarification
there.
Some
of
their
examples
that
next
slide.
Please
do
you
seem
to
indicate
that
there
are
devices
that
might
not
have
a
status
tracker,
but
it's
not
clear,
like
in
the
example
of
devices
B
and
C,
whether
there's
a
status
tracker
implied
in
this
diagram
or
whether
there's
actually
a
status
tracker.
C
You
know
present
on
that
device
and
I
I
talked
with
with
Aki
Takahashi,
who
is
one
of
the
the
authors
of
this
draft
and
he
would
definitely
appreciate
some
feedback
on
on
where,
where
he
can
clarify
things,
to
make
sure
that
this
is
in
sync,
with
our
work
next
slide.
Please
I'll
mention.
C
Right
so,
in
the
latest
revision
of
the
document
there's
been
a
bunch
of
minor
editorial
changes.
You
know
a
lot
of
fixing
of
case
and
abbreviations
throughout
the
document.
There
were
a
bunch
of
definitions
in
the
previous
version
that
were
kind
of
in
line
with
the
text.
There's
a
new
section,
Clause
3.2,
where
all
the
different
definitions
are
now
kept,
so
they're
a
little
bit
easier
to
find
in
the
document
and
also
they've
recently
added
in
appendix
2,
which
provides
an
example
scenario
of
IOT
software.
C
Updating
using
a
distributed
ledger
technology
next
slide,
please
that
guy
so
on
the
distributed
ledger
technology,
it
seems
like
that
approach
is
a
little
under
specified
in
the
document.
So
it's
not
really
clear
the
exact
role
that
a
distributed
ledger
is
serving
in
the
update
process,
so
I
think
there's
probably
some
more
work
to
do
for
them
on
that
front.
So
considering
this
liaison
statement,
I
have
a
few
questions.
C
F
This
one
is
yeah,
I
was
just
wondering
about
the
earlier
mentioned
status,
tracker
discussion,
because
when
I
provided
the
text
in
the
architecture
document
there,
the
status
track
had
somewhat
a
different
semantics
and
it
was
really
like
a
device
management
functionality
and,
as
that
name
indicates,
it
monitors
the
whole
firmware
update
process
and
it
wasn't
actually
on
the
device
itself.
So,
given
that
there
are
these
subtle
changes
throughout
time,
you
son
like
if
they
seem
to
still
work
on
the
document,
and
so
I
prefer,
as
I
will
later
explain.
F
C
C
H
So,
starting
from
a
statement,
my
name
was
a
little
mutt
of
kryptonite.
I
would
like
to
mark
my
presence
here,
just
as
a
possible
point
of
contact
with
a
study
group,
seventeen
being
a
vice
chairman
of
study
group.
Seventeen
I
would
like
to
point
out
in
our
point
of
contact.
You
could
maybe
have
seen
our
know
today
who
is
working
party
chairman
of
study
group
17
and
in
the
absence
of
statistic
factor
takahashi.
We
can
kind
of
provide
a
contact
and
collaboration.
Thank
you.
Thank
you.
I
This
is
Brendon
Morin
at
the
mic
and
I've
gone
through
this
document,
and
there
are
a
number
of
points
of
ambiguity
that
I
think
we
would
need
to
resolve
before
we
can
move
forward
with
more
more
alignment
between
our
two
groups.
In
particular,
the
status
tracker
needs
significantly
more
definition.
The
status
tracker
is
currently
defined
as
doing
a
great
many
things.
In
fact,
I
think
that
you
could
probably
we
construct
an
update
system
entirely
of
status.
C
I
E
So
just
observation
on
the
first
question
of:
do
we
need
to
respond?
This
isn't
the
first
time
that
we've
asked
that
question.
That's
obviously
not
the
first
time
we've
got
a
liaison
from
Citigroup
17
so
far,
the
way
that
it
has
worked
in
the
other
direction.
So
by
the
way
in
this
direction.
My
understanding
I
am
NOT
an
itu-t
study
group,
seventeen
expert,
but
my
understanding
is
the
way
the
mechanism
that
they
have
to
share.
E
The
document
with
us
is
through
a
liaison
statement,
and
so
that's
why
we
get
the
Izod
statements
from
them
so
that
we
can
review
the
document
and
the
other
direction.
We
don't
need
a
liaison
statement
for
them
to
review
our
documents,
and
so
in
the
other
direction
has
been
working
by
email
to
tack
and
discussion
on
our
public
lists,
and
so
do
we
need
to
respond
is
not
the
same
question
as
do
we
need
to
send
a
liaison.
E
It
may
be
discussed
in
the
list
to
which
tack
and
vasiliy
or
whatever
are
visible
participants
in,
and
so
that
may
be
sufficient
yeah
Brennan.
If
you
have
comments
just
posting
into
the
list
and
making
sure
that
taxi's
them
may
be
sufficient,
rather
than
going
to
the
formal
way
as
on
process,
we
can
send
early
as
I
know
if
we
feel
a
need
to,
but
so
far
we
have
not
felt
any
to.
J
J
Thanks
so
I
would
I
would
suggest
indeed
conveying
this
information
at
least
capturing
it.
It's
already
a
good
start,
I
think
the
questions
that
Brendan
asked
are
fairly
good
and
maybe,
when
asked
Takeshi,
what
would
be
the
best
way
to
communicate
back
so
that
the
message
gets
through
with
the
group,
but
that
would
be
my
suggestion.
H
Thank
you.
A
bit
of
clarification
again.
I
was
a
little
more
of
a
bit
of
clarification
on
itu-t
procedures
and
the
years
own
statements,
you'd
correctly
stated
the
role
of
Lea's
own
statements
in
the
ITU
so
which
is
where
I
would
propose.
If
someone
wants
to
walk
on
the
text
and
the
contents
of
the
document,
it's
bellow
most
efficient
way
to
contact
acacia,
takahashi,
directly
and
walk
through
here
with
him,
maybe
participate
as
a
co-editor.
Sorry,
something
like
that.
The
other
own
statements
you
will
need
in
two
situations:
first,
one
if
their
itu-t
does
something.
H
Definitely
wrong
in
your
perception
then
steadily
as
young.
The
itu-t
can
definitely
stop
the
process
and
start
rethinking
and
discussion
in
now
ever
the
way
which
I
prefer.
If
you
definitely
support
this,
you
can
send
Lea's
own
statement,
saying
that
you
support
which
document
in
its
contents-
and
it
will
speed
up
the
recommendation-
approval
I.
E
C
H
To
make
a
contribution
from
a
member
state
I
do
not
do
synthesis,
we
cook
were
quite
a
way
to
do
that.
No
restrictions
to
the
participations
is
imposed
on
them.
Maybe
if
we'll,
if
one
like
to
he
his
name
as
a
co-author
of
the
document,
he
could,
he
should
represent
even
member
state
or
sector
member
which
are
a
lot
of
large
companies
are
so
that
depends
on
the
position
of
the
person
and
it's
vicious
that
doesn't
present
any
meaningful
walk.
The
document
sliver
editors
of
the
document,
okay,.
C
Okay,
so
on
another
point,
I
was
talking
with
Takeshi
earlier
in
the
week
and
he
expressed
a
desire
to
have
someone
else
help
with
editing
this
document.
So
if
there's
a
member
of
this
group
that
would
be
willing
to
contribute
some
time,
he
would
welcome
that
that
contribution
pending
what
we
were
just
talking
about
I
think
that
the
person
that
would
would
be
helping
would
would
probably
have
to
be
a
representative
than
of
a
member
state
in
order
to
ask
for
a
sec
remember
in
order
to
contribute.
D
Hello,
I'm,
just
gonna,
give
a
small
status
report
on
what
we
did
it
a
hackathon
next
slide.
Please
excite
so
here's
the
team
where
12
people,
one
remote,
yeah,
really
nice
next
slide,
please.
So,
as
you
know
here,
we're
working
on
suffer
updates
for
IT,
so
we
are
working
on
architecture
and
metadata
for
software
updates.
It's
actually
firmware
updates
now
for
IOT
devices,
including
small
microcontrollers,
not
to
forget
them
at
a
hackathon.
We
work
on
hands
on
implementation
of
the
latest
metadata
format
draft.
D
So
what
happened
at
hackathon
at
the
hackathon
we
had
available
new,
manifest
generators,
two
of
them
one
from
arm
and
one
from
renesis.
We
had
new,
manifest
parsers
three
and
implemented
three
independent
limitations,
and
one
from
in
Ariya
are
I,
went
from
on
one
former
NSS,
and
two
of
these
implementations
were
actually
running
on
actual
Hardware
on
actually
small
microcontrollers,
so
one
with
32
kilobytes
of
RAM
and
the
other
with
64
kilobytes
of
RAM.
D
So
we're
we're
pretty
in
a
let's
say
the
low
end
here
and
we're
happy
to
see
that
we
could
demonstrate
interoperability
between
the
manifest
generator
from
arm
and
the
partials
from
INRIA
and
finally
Bassett
it
on
one
hand
and
the
parser
from
renesis.
So
that's
good
and-
and
we
also
had
a
full
workflow
demo.
D
Firmer
building
manifests
building
and
transporting
that
to
a
riot
device
and
actually
doing
a
firm
Arabic
with
that
I
think
yeah
excite.
So
what
did
we
learn?
There
were
a
couple
of
aspects
in
the
spec
where
there
were
several
ways
to
do
things
and
cost
contributions.
It's
not
the
first
time
it
happens
in
the
IDF,
but
you
know
so.
This
similar
conclusion
is
that
we
should
just
define
one
thing.
D
One
way
to
do
things,
maybe
Brendan
will
talk
about
a
little
bit
later
and
first
foremost,
ITF
hackathon
is
fun
and
really
nice
venue
to
make
some
progress
so
for
those
who
weren't
there.
Please
consider
coming
next
time.
Yeah
next
slide,
yeah.
So
for
more
information
we
have.
We
had
an
inter
pad
where
we
noted
bunch
of
things
and
links
useful
links
for
the
what
happened
at
the
hackathon
concerning
suit
yeah
and
then
the
usual
links
to
the
spec
work
in
progress
and
working.
A
F
It's
quite
short,
so
I
didn't
put
some
slides
together,
so
I
submitted.
Do
drafts
update
since
the
light
last
IDF
meeting
the
first
one
was
early
this
year
to
do
it,
the
Molalla
alignment
that
was
discussed
at
the
last
IDF
meeting
in
context
of
what
we
discussed
earlier
with
the
I
do
tea
liaison
and
that
document,
so
it
seems
to
there
may
be
some
additional
work
and
for
the
second
update,
I
added
some
text
on
boot.
F
Loaders,
specifically
following
the
discussion
that
we
saw
on
the
list
where
the
focus
of
the
firmware
update
didn't
just
include
sort
of
the
transfer
of
the
firmware,
plus
the
manifest
from
some
devices
from
the
firm
walls
all
the
way
to
the
IOT
device,
but
also
then
concerned
the
question
of
what
happens
then
afterwards
at
the
device,
and
specifically
the
interaction
with
secure
boot,
and
so
we've
seen
that
some
people
want
to
use
the
same,
manifest
or
at
least
a
stripped-down
version
for
the
secure
boot
mechanism.
Afterwards
and
I.
F
Try
to
capture
that
discussion
a
little
bit.
India
I
try
to
keep
it
as
short
as
possible
because
there
are
obviously
a
number
of
ways
to
design
a
boot
loader
with
different
stages,
and
we
talked
about
this
and
in
previous
meetings
before
when
I
spoke
about
the
hackathons.
So
there
are
different
design
choices
and
I
didn't
want
to
preclude
or
favor
one
specific
approach,
but
there
will
obviously
be
implications
in
terms
of
code,
reuse
and
the
security
property
of
the
device
itself,
depending
on
what
you
are
doing.
F
F
So
that's
something
I
included,
they've,
send
a
message
earlier
this
week,
actual
Monday
with
a
small
with
a
note
from
Dave
wheeler,
which
wants
to
have
additional
clarification
regarding
the
trust
anchor
which
currently
only
talks
about
these,
be
its
it
being
a
public
key,
but
also
wanted
to
highlight
that
there
are
some
requirements
regarding
the
protection
of
those
keys
are
clearly.
You
can't
just
store
it
on
the
in
flash
and
let
everyone
modified.
So
there
are
some
requirements
to
protect
it
against
modification
against
sort
of
stripping
it
out,
deleting
it,
etc,
etc.
F
So
I'm
going
to
add
that
I
think
that's
a
minor
clarification,
but
still
quite
useful.
A
useful
addition
and
otherwise
I
would
suggest
I
would
have
suggested
to
start
a
working
group
last
call,
but
now
I'm
not
quite
sure
anymore.
But
if
the
discussion
is
about
the
status
tracker
and
some
of
the
other
idea,
T
work
so
I'm
not
entirely
sure,
but.
C
A
C
F
C
That's
perfect
so
so,
maybe
later
today
we
can,
we
can
actually
start
the
the
working
group
last
call.
Thank
you.
E
I
Over
the
trapdoor,
okay,
good
yeah,
kick
it
set
on
the
eggs
okay.
So
following
ietf
103,
there
were
a
number
of
updates
requested
to
the
information
model.
Specifically
these
had
to
do
with
a
couple
of
new
threats
and
not
one
new
threat
and
a
couple
of
new
use
cases
next
slide.
Please
so
what's
happened
mostly
in
this
update.
Is
that
we've
rearranged
elements
mostly
to
place
the
manifest
elements
at
the
beginning.
That
was
on
request
of
the
chairs
at
the
previous
IETF
and
then,
as
I
said,
new
threats
and
new
use
cases
next
slide.
I
Please
so
HP
HR
PC
requested
that
we
address
the
possibility
of
exposing
information
about
an
individual
by
exposing
what
devices
they
have,
and
so
that
requires
obfuscating
the
contents
of
a
manifest,
because,
even
though
it
doesn't
contain
any
IP,
it
could
contain
device
identifying
information
and
that
could
reveal
information
about
a
person
or
the
things
they
own
so
to
resolve
that
we've
added
a
new
security
requirement
for
the
option
of
having
encrypted
manifests
next
slide.
Please
there
were
several
new
use.
Cases
discussed
specifically
as
Hanna's
mentioned,
secure
boot
and
once
secure
boot
was
an
option.
I
The
next
thing
to
to
add
in
was
the
ability
to
transform
a
firmware
image
during
the
loading
process,
so
decompress
on
load
was
the
use
case
that
was
given
to
me,
but
I'm,
quite
certain
that
decrypt
on
load
is
also
a
requirement.
So
that's
been
added
in
as
well,
and
there
was
significant
discussion
on
the
mailing
list
about
simple
parsing.
So
we've
added
that
as
a
required
use
case
in
the
information
model.
Next
slide,
please
and
from
that
we
derived
for
almost
identical
usability
requirements
and
that's
about
it
for
updates
to
the
information
model.
E
A
K
Dave
wheeler,
so
I
haven't
read
all
of
the
the
documents
in
detail,
but
I
did
spend
a
couple
hours
yesterday
reading
through
the
information
model
and
things
specifically
with
the
purpose
of
trying
to
reuse
the
manifests
for
teeth
and
I
think
there
may
be
some
some
things
that
we
might
want
to
add
to
this.
But
I
don't
have
anything
right
now
solid
to
give
you
as
input,
but
I
should
should
do
that
within
the
next
couple
of
weeks.
I
E
Brendon,
you
said
there
were
some
editorial
comments.
Do
you
have
any
timeline
on
when
you
are
planning
to
address
the
editorial
comments?
Hopefully
this
week?
Okay,
so
if
they
can
be
addressed
by
Friday,
they
we
can
say
we're
just
going
to
start
to
work.
We're
gonna
send
out
the
working
your
class
call
as
soon
as
that
appears.
If
it's
going
to
be
longer
than
that,
then
we
should
go
ahead
and
start
it.
But
if
you're
going
to
potentially
do
it
before
a
Friday,
then
we'll
send
out
the
working
request
call
announcements
initiation
on
Friday.
E
I
All
right,
so
this
has
been
a
major
revision
from
the
previous
draft
next
slide.
Please
so
I
really
want
to
thank
everyone.
Who's
contributed
I've,
gotten
a
lot
of
feedback,
not
all
of
it
positive
on
the
previous
draft,
and
that
made
me
that
encouraged
me
to
do
a
major
rethink
of
the
mechanism
that
we
were
using
to
handle
the
the
serialization
of
the
information
model
and
the
rethink
I
think
it
produces
a
much
simpler
result.
The
the
format
ends
up
being.
I
The
format
is
constructed
specifically
to
make
the
parser
simple.
That
doesn't
mean
in
all
cases
that
it
makes
the
format
smaller,
but
it
doesn't
increase
it
significantly.
I
don't
think
I'll
have
to
I've
had
some
discussions
about
every
byte
counts,
but
it's
still
I
think
that
the
trade-offs
are
in
the
right
in
the
right
vein.
Next
slide,
please
so
I.
This
is
just
an
overview
of
what
we're
going
to
or
what
I'm
going
to
talk
to
you
about.
I
Let's
get
into
the
reasoning
behind
the
changes,
so
the
previous
draft
was
very
complex
and
and
every
time
I
added
a
new
use
case.
It
got
more
complex
and
that
means
complex
parsers,
and
that
means
complex
code,
and
that
means
more
space
on
constrained
devices.
I
didn't
like
where
this
was
going.
So
the
new
use
cases
were
introducing
new
optional
fields
in
places
that
already
had
significant
numbers
of
optional
fields.
This
also
made
capability
reporting,
really
complicated,
and
the
irregular
structure
of
the
data
made
it
very
difficult
to
parse
efficiently
next
slide,
please.
I
So
there
are
a
few
different
things
that
are
turning
up
in
this
in
this
draft
and
the
important
ones
to
recognize
our
commands,
which
are
either
the
the
struction
for
to
a
device
to
test
something
or
the
instruction
to
a
device
to
do
something.
There
are
parameters
which
the
devices
use
in
order
to
perform
those
two
options
and
the
components
are
the
things
that
devices
operate
on
those.
Are
you
typically
firmware
images
or
other
resources
that
a
data
that
a
device
uses
next
slide?
I
Please
so
at
the
high
level,
the
only
real
change
is
that
I've
moved
the
authentication
container,
typically
cozy,
into
a
B
string.
I
guess
we're
saying
it
is
cozy,
so
the
cosy
container
goes
into
a
paste
ring
now
that
is
specifically
to
ensure
that
the
top-level
parser
doesn't
require
a
understanding
of
cosy
this.
This
is
to
partition
the
responsibility
for
understanding
different
formats
into
the
individual
software
modules
that
implement
them.
I've
also
expanded
the
CD
DL
that
describes
the
the
authentication
container
to
allow
an
array
of
authentication
methods.
I
This
was
because
it
allowed
us
to
handle
both
a
cozy
Mac
and
a
cozy
signature
within
the
same
block,
which
would
otherwise
not
be
possible,
and
the
manifest
itself
has
substantial
changes
which
we'll
get
into
in
a
moment
here.
Next,
please,
all
right,
so
the
new
manifest
is
divided
into
two
major
sections.
There's
the
common
data
area.
Now
the
first
two
elements
in
that
are
different
from
the
rest.
Those
two
elements
are
specifically
intended
for
an
external
system
or
external
software
to
be
able
to
read
it's
not
really
part
of
what
the
manifest
processor
handles.
I
This
is
because
the
structure
version
informs
a
device
whether
or
not
it's
manifest
processor
can
handle
the
data,
and
the
second
allows
it
to
decide
which
manifest
it
should
be
looking
at.
So
both
of
these
things
have
to
happen
before
a
device
is
able
to
actually
start
processing
its
manifest
this.
This
is
again
a
secure
boot
question,
rather
than
a
update
question.
You
need
to
know
the
sequence
number
before
you
can
pick
which
partition
to
boot.
Then
there
are
dependencies
and
affected
components,
so
those
are
components
that
are
affected
by
the
manifest
or
its
dependencies.
I
The
dependencies
are
other
manifests
that
are
required
by
the
one
that's
being
processed.
Behavior.
Definitions
are
used
to
explain
to
a
device
exactly
what
it's
supposed
to
be
doing
in
the
course
of
an
update
or
a
secure
boot
process,
and
as
Carsten
has
pointed
out,
they
are
effectively
scripts,
but
I
didn't
want
to
use
the
term
scripts
because
I,
don't
scripts,
have
a
lot
of
baggage,
and
one
thing
you
don't
want
in
a
secure
boot
process
is
a
lot
of
baggage.
I
So
so
this
is
the
reason
I'm
saying
behavior
definitions,
rather
than
something
else
is
because
we've
lived,
we've
removed
the
possibility
to
do
some
of
the
things
that
scripts
do
that,
make
them
problematic
in
this
kind
of
space,
specifically
the
ability
to
perform
branches
and
loops.
There
is
no
halting
problem
here
there.
The
complexity
is
sort
of
enforced
to
be
low,
so
they
the
individual,
the
two
steps
they're
laid
out
here,
the
install
and
the
run-
are
broken
down
into
three
pieces.
I
I
Next
slide,
please,
so
all
commands
must
target
a
component.
This
is
because
components
are
essentially
what
we're
operating
on.
If
it's
not
targeting
a
component,
then
it
really
doesn't
do
anything
on
a
device.
Some
commands
may
target
all
components.
This
is
an
optimization
to
allow
you
to
say,
go
and
fetch
all
of
the
components
that
are
about
to
be
installed
or
in
do
an
image.
Verification
on
everything
most
parameters
are
scoped
by
component.
There
are
two
specific
parameters
that
are
not
scoped
by
component,
but
I'll
talk
about
those
a
bit
later.
I
I
I
So
the
parameters
that
don't
require
a
component
to
act
on
are
the
strict
order
and
soft
failure
parameters.
So
the
soft
failure
parameter
is
the
one
that
enables
conditionals
that
as
I
as
I
just
described,
strict
order
is
a
parameter.
You
will
only
ever
see
on
a
device
with
many
components
and
lots
of
RAM.
This
is
a
mechanism
to
allow
it
to
do
things
out
of
order
where
they
do
not
have
dependencies.
I
So
these
are
things
like
decompression,
decryption
and
unpacking,
and
image
identifiers
are
typically
cryptographic
so
digests
of
a
an
image,
but
I
also
allow
for
the
possibility,
due
to
previous
requests
from
this
group,
that
they
could
be
version
numbers.
There
may
be
an
interface
version,
that's
required
and
verifying
that
an
interface
version
is
available
and
is
the
domain
of
the
manifest
in
this
particular
type
of
parameter
and
finally
device
identity,
which
we've
defined
under
the
under
the
UUID
scheme.
I
So
here's
a
the
information
that
will
encode
into
a
manifest
in
the
current
format.
It's
about
96
bytes
of
information,
but
what's
not
obvious
here,
is
that
there
are
also
instructions
to
a
device
on
how
to
use
that
information.
So
this
is
just
the
raw
information.
If
you
were
doing
this
bespoke
the
minimum
that
you
could
use
to
encode.
This
information
is
96
bytes.
Since
that's
exactly
what
the
data
size
is,
we
could
encode
it
in
169
bytes,
but
that
does
give
the
device
some
flexibility
on
how
to
use
it
next
slide.
Please.
I
So
the
outer
wrapper
is
the
same
as
it
always
was.
It's
not
terribly
exciting.
Next
slide,
please
I.
The
inner
part
of
the
manifest
shows
the
version
number
of
the
sequence
number
it's
got.
One
payload
and
I
will
talk
a
little
bit
more
at
the
end
on
the
open
issues
about
how
the
component
is
listed,
there
I
think
we
can
do
better.
I
Then
we've
got
the
common
section,
a
common
is
executed
before
every
other
command
list
and
then
validate.
So
this
is
just
doing
a
secure,
boot
no
apply
and
then
validate
there.
We
are
apply,
validate
and
run
so
our
common
is
executed
before
every
each
of
these
others
and
that's
to
enable
essentially
size
reduction
because
it
contains
the
digest,
as
I'll
show
you
in
a
moment
it
reduces
the
amount
of
space
that's
consumed,
because
the
digest
doesn't
have
to
be
repeated
in
each
segment.
Next,
please
so
in
here.
I
It
sets
the
component
index
to
zero
checks,
the
IDs
and
sets
up
the
digest
that
will
be
expected
later
and
the
size
that
will
be
expected
later
next,
please
well.
My
highlighting
is
all
gone,
can't
see
which
section
you're
in
okay,
so
this
section
is
apply
and
in
apply.
What
is
happening
is
that
it's
doing
a
simultaneous
fetch
and
install.
I
I
I
Think
it's
another
area
where
we
can
have
some
improvement.
There
were
some
comments
during
the
hackathon
as
well
that
this
is
not
the
or
this
particular
format.
This
encoding
is
difficult
to
parse
and
I
think
that
we
should
try
and
find
a
better
solution
for
that
and
I've
got
some
more
information
on
that
in
the
open
issues
section
at
the
last
element.
There
20
is
a
fetch
all
elements
directive,
but
it's
definitely
not
in
the
description.
Ok,
next
slide,
please
I
hear
it's
very
simple.
This
is
apply
or
this
is
validate.
I
So
this
is
a
very
simple
section.
It
just
sets
the
component
index
and
validates
the
now
downloaded
image
against
the
component
that
it's
got
specified
by
the
component
index.
Next,
please
and
here's
run
the
same
thing
again
component
index
and
run
the
selected
component.
Now
this
I
I
hope
that
it's
obvious
that
we're
setting
the
component
index
a
lot
and
possibly
too
much,
and
so
one
of
the
other
open
issues
is,
should
we
have
a
default
for
that?
I
I
I
So
you
can
add
those
numbers
for
authentication
depending
on
what
your
use
case
is
next,
please
so
a
pure,
secure
boot
manifest
encodes
47
bytes
of
information
and
consumes
91
bytes
encoded
I,
again
dependent
on
exactly
what
your
component
ID
is
next
slide.
Please
for
a
minimal
update
without
secure
boot
again,
depending
on
your
component
ID
and
your
URI
74
bytes
of
information
encoded
in
130
bytes
of
manifest
next,
please
adding
boot
to
that
cost
to
9
bytes.
Next,
please.
I
So
now
adding
compatibility
or
applicability
rather
verification
to
this
caught.
It's
an
additional
32
bytes
worth
of
uu
IDs,
and
it
ends
up
being
encoded
in
177
bytes
next,
please
so.
The
parser
that
I've
put
together
to
to
verify
this
took
me
about
600
lines
of
C
for
the
the
part
that
executes
the
manifest
and
about
200
lines
of
C
for
simple
C
bore
information
and
extraction
that
isn't
compiled
sizes,
obviously,
and
the
C
is
pretty
vanilla
and
probably
has
too
many
prints
in
it.
I
So
that's
just
just
a
ballpark
figure
for
how
complex
it
is
to
implement
and
I'd
love
to
get
feedback
from
anyone
else
who's
how
to
go
at
implementing
it.
If,
if
that's
available
or
if
someone's
on
the
line,
perhaps
who
could
mention
that
when
we're
done
here
next
please,
so
there
are
a
few
open
issues,
as
has
been
pointed
out
already.
There
are
a
few
places
where
there's
more
than
one
way
to
do
things,
and
that
makes
parsers
more
complex,
so
we
should
get
rid
of
them.
I
The
digest
incise
hair
was
done
as
a
mechanism
to
trade
off
between
parser
complexity
and
data
size,
so
encoding
it.
The
way
they
in
one
way
would
produce
a
smaller
manifest,
but
a
more
complex,
parser
and
encoding
it.
The
other
way
would
produce
a
less
complex
parser,
but
a
larger,
manifest
I
think
that
the
since
one
of
the
mechanisms
is
required
for
a
few
use
cases
and
the
other
is
not
explicitly
required
for
any
other
than
the
size.
Optimization
I
think
that
we
should
stick
with
the
slightly
larger
but
less
complex
method.
I
The
URI
list
is
complex,
I,
don't
like
how
much
parsing
it
takes
to
handle
it
and
I'm,
not
convinced
that
there
are
a
lot
of
use
cases
that
require
the
URI
list
that
we
have
at
the
moment.
I
think
there
are
three
different
ways
that
we
could
deal
with
it,
so
we've
got
the
existing
one,
which
is
effectively
a
multi
map,
just
not
listed
that
way.
I
think
that
we
could
I,
don't
think
it's
necessary.
I
So
the
second
option
is
just
a
plain
list
of
your
eyes
where
priority
comes
out
of
the
order
in
the
map
or
in
the
list,
rather
than
coming
out
of
an
explicit
priority
number
listed
with
the
URI.
The
second
possibility
is
a
map
of
your
eyes,
keyed
by
priority
that
prevents
duplicate
priorities.
That's
the
only
and
that's
the
only
problem
that
it
has
I
think
so
these
what
these
options
don't
enable,
because
that
apparently
has
cut
off.
It's
like
I
forgot
to
save
it
at
some
point.
I
So
the
what
these
don't
enable
is
that
the
is
the
ability
to
have
multiple.
You
are
eyes
at
the
same
priority
that
was
raised
as
a
possible
optimization
at
one
point
where
devices
need
to
choose
among
multiple
your
eyes
of
the
same
priority
for
geographic
region
selection,
for
example,
I
think
that
this
is
a
fairly
complex
use
case
and
in
situations
like
that,
I
think
devices
should
probably
work
out
their
own
priorities
based
on
order
and
based
on
geographic
region
and
I.
I
Think
that
having
an
explicit
prior
in
there
is
probably
not
something
that's
beneficial
to
most
devices,
so
I
think
either
a
list
or
a
map
is
probably
the
right
answer.
I'm
commanding
coding.
It
also
has
a
bit
of
an
open
issue
right
now.
It's
an
array
of
maps,
an
array
of
maps
is
fine
and
it's
equivalent
to
an
array
of
arrays
with
two
elements.
Each
so
there's
there's
no
semantic
difference
there,
I
I,
think
the
array
of
maps
is
probably
okay.
A
multi
map
would
be
a
more
efficient
encoding,
but
I
I
gathered
that
see.
I
Bor
has
considered
this
and
rejected
at
numerous
times,
so
the
other
option
that's
been
brought
up
is
a
pseudo
multi
map.
I
I
call
it
that,
because
that's
the
best
explanation
I
can
have
for
it
where
we
alternate
keys
and
values
in
each
successive
element.
I
think
that
the
array
of
maps
is
probably
fine,
it
adds
a
few
bytes,
but
it
makes
the
semantics
a
lot
easier
to
follow,
and
so
we
also
have
the
issue
I
raised
a
few
minutes
ago
about
the
default
component
and
dependency
index.
I
This
would
be
fine,
except
that
if
we
remove
the
ability
to
layout
the
digest
and
size
of
a
payload
in
its
component
description
and
move
that
explicitly
into
the
command
sequence,
we
won't
be
able
to
do
that.
So
there's
a
trade-off
here
where
you
could
use
this
manifest
in
a
completely
script
--less
way.
I
L
K
K
All
of
the
options
are
equally
valid,
but
a
device
may
choose
one
based
upon
their
trust
anchor
list,
and
so
the
URI
has
to
include
both
where
to
go,
get
it
and
the
key,
and
one
of
the
things
that
we've
been
talking
about
is
that
particular
URI
might
need
to
be
signed
to
prove
that
it's
valid.
So
I
want
to
maybe
explore
that
with
you,
some
more
via
the
email,
if
we're
thinking
about
this
in
the
right
way,
but
it
creates
a
rather
complex
case,
I
think
for
the
URI
LS.
K
I
I
L
D
D
It's
quite
substantial
but
like,
depending
on
like
how
much
flash
it's
flash
you
have
on
the
device.
It's
so
like
relatively
to
the
flash
like
you
have
to
relate
that
to
the
number
of
mouths
of
we
have.
So
when
I
hear
that
we
may
want
to
run
this
stuff
in
the
T
where
we
might
have
like
I,
don't
know
like
reduce
num,
reduce
amount
of
flash.
This
might
become
like
a
something
we
want
to
characterize.
D
K
D
Triple
bet,
but
okay,
so
if,
if
you're
thinking
about
like
you
know,
device
with
128
kilobytes
of
flash,
that's
thick
bearable
if
you're
thinking
about
like
64
or
kilobytes
of
flash
or
in
a
pretty
small,
and
maybe
you
take
it-
becomes
like
a
something
significant
to
take
into
account.
But
again
like
this.
This
is
a
very
preliminary
results.
I
just
got
now
so
to
be
confirmed.
D
N
M
C
N
C
C
I
Agree
and
I
think
if
you
look
through
the
mailing
list
archive
there
was
a
point
I
raised
some
time
ago
about
not
using
see,
bore,
parsers
to
parse,
see,
bore
and
there's
a
way
of
just
doing
exact
matching.
You
know
with
mem
compare
that
you
can
or
you
can
take
as
an
approach
to
really
cut
down
size
if
you're
in
a
very
fixed
function
case
like
that.
E
I
So
this
is
a
quick
overview
of
the
work
that
went
into
the
the
creation
of
manifest
zero
4.
It's
essentially
the
information
model,
if
you
will
behind
the
serialization
of
the
command
sequences
and
goes
a
little
bit
into
the
ideas
that
we
used
to
to
to
generate
that
serialization
and
the
the
reasons
behind
them.
So
what
does
the
recipient
do
when
it
needs
to
do
an
update,
probably
check
for
authenticity
assuming
it's
not
guaranteed
by
some
other
means,
and
then
it
needs
to
install
a
payload.
I
But
there
are
a
number
of
questions
around
that
as
well.
Next,
please,
so
descriptive
updates,
binary
formats
provide
a
recipient
with
explicit
information
I'm
in
a
number
of
different
ways
and
then
expect
the
recipient
to
act
on
that
information
via
some
pre-agreed
methodology.
Next,
please,
it's
got
a
few
pros.
I
Is
it's
a
completely
separate
definition
and
it's
a
separate
problem
next,
please,
the
other
option
is
to
specify
things
in
a
behavioral
way
to
specify
exactly
what
a
device
do
instructing
it
on
how
to
perform
each
step
in
a
normal
update
process
and
in
a
secure
root
process.
As
the
recent
use
cases
have
pointed
out,
the
same
information
is
all
there,
but
the
organization
is
different
next,
please
so
it's
unambiguous
as
to
what
a
device
should
do
it,
because
it's
constructed
of
directions
to
a
device.
The
data
encoding
is
very
simple.
I
The
parsing
should
be
very
simple,
although
those
numbers
that
a
manual
has
been
giving
me
are
concerning
the
behavior
is
explicit,
not
implied,
which
is
beneficial
from
a
security
perspective
and
there's
a
high
degree
of
flexibility.
The
codes
are
the
the
size
of
the
manifest
itself
may
be
larger,
but
that's
a
encoding
question
rather
than
a
informational
question
and
there's
more
tooling
required.
Definitely
because
it
effectively
turns
your
manifest
generation
infrastructure
into
what
is
effectively
a
compiler.
It
also
means
that
presenting
the
information
in
a
manifest
to
a
user
requires
tooling
as
well.
I
Next,
please,
the
outer
structure
is
the
same
as
I've
shown
in
the
previous,
the
previous
set
of
slides.
You
have
the
authentication
wrapper
and
then
a
set
of
externally
accessible
data
which
is
used
by
other
parts
of
the
system.
Then
common
data,
that's
shared
between
all
of
the
operations
performed
on
the
device
and
then
finally,
the
command
lists
that
the
device
uses
to
process
through
the
manifest
next
please
so
we
constructed
six
command
lists
and
one
common
command
list
that
gets
executed
before
each
of
the
others.
I
This
was
done
to
ensure
that
each
of
the
phases
that
a
device
typically
goes
through
in
an
update
would
be
catered
for.
Next,
please,
dependency
handling
is
something
that
needs
special
tension
in
this
model.
It's
explicit
as
all
of
the
other
operations
on
the
device
are,
but
because
dependencies
have
to
be
resolved,
all
of
them
before
any
one
dependency
is
processed
in
any
other
way.
I
The
command
lists
have
to
be
handled
in
lockstep,
so
dependency
resolution
of
the
first
manifest
has
to
complete,
or
at
least
partially
complete
before
now.
The
dependency
resolution
has
to
complete
before
the
image
acquisition
starts.
Now
that's
important
because
you
want
to
have
early
failure
in
devices.
You
want
to
know
that
an
update
will
be
able
to
acquire
all
of
its
dependencies
before
you
start
applying
the
update.
Likewise,
you
want
to
know
that
a
device
will
be
able
to
acquire
all
of
its
images
before
it
starts
to
install
any
one
image.
I
So
that's
the
reasoning
between
dividing
out
these
command
lists
into
their
component
parts.
When
dependencies
are
involved,
we
need
to
be
able
to
divide
down
into
the
individual
sub
steps
of
the
update
process
and
dependencies
are
explicitly
processed,
so
the
there's
a
command
in
the
manifest
to
say,
go
and
process
a
dependency,
and
that
means
that
it
processes
the
current
command
list
in
the
next
dependency.
So
dependency
resolution
means
dependency
resolution.
The
image
acquisition
means
image,
acquisition
and
so
on.
I
Next,
please
I've
gone
through
the
lists
of
commands,
there's
one
here
that
wasn't
listed
in
the
other
one,
which
is
the
third-party
authorization
and
on
the
other
side
directive,
which
is
wait
for
an
event.
Those
are
two
cases
that
we
have
found
will
probably
be
needed
in
a
lot
of
devices.
Next,
please
I've
talked
about
the
different
parameters
already
I.
Don't
think
that
I
need
to
go
through
that
again
next,
please,
oh,
that's
it!
Okay,
there
we
are.
So
that's
that's
just
an
overview
of
the
process
that
we
went
to
get
here.
I
N
I
You
depend
on
a
specific
manifest.
If
that's
not
going
to
be
the
case,
then
there
are
going
to
it's
going
to
be
much
more
difficult
to
construct
a
secure
dependency
chain,
and
the
other
mechanism
for
handling
this
is
to
verify
are
sorry
to
check
for
availability
of
a
particular
version,
and
we
already
do
have
that.
But
it's
not
constructed
as
a
dependency.
I
I
L
Cross
Housley
two
meetings
ago,
I
advocated
that
we
take
a
look
at
hash
based
signatures
and
I
just
wanted
to
provide
a
update
on
where
the
work
in
the
cosy
working
group
is
gone
to
allow
us
to
do
that,
since
we
were
aligned
with
seal
or
we
needed
signatures
there.
The
hash
based
signature
specification
out
of
the
CFR
G
is
in
the
RFC
atatürk.
You
there
in
auth
48.
So
we
actually
know
what
the
RFC
number
is
now
it'll
appear
very
shortly,
then
the
cosy
spec
was
his
progressing.
E
So
I'll
mention
and
manual
didn't
put
it
into
the
hackathon
report,
but
at
the
hackathon
there
was
actually
a
question
that
was
raised
at
the
soup
table,
which
is
so.
What
is
the
status
of
quantum
resistant
stuff
we've
talked
about
that
before,
but
we
didn't
hear
about
that
and
that's
actually
what
russ
was
just
answering
was
the
question
that
came
up
with
hackathon
manual.
You
want
to
say
anything
else.
D
Mineola
chilly
yeah
here
I,
was
at
Cosi,
so
I
reversed
some
of
your
slides,
and
you
were
talking
about
the
the
signature
sizes
depending
on
you
know
how
many
times
you
can
sign
and
etc,
and
you
know
like
lasting
a
long
time,
obviously
is
means
longer
signatures.
The
thing
I
remember
like
that
you
had
like
the
very
minimum
30,000
signatures,
or
something
like
that
with
like
rather
small
slides,
is-
is
that
the
type
of
thing
that
we
will
recommend
to
use
for
software
updates
on,
like
really
small
devices.
L
Yes,
that
is
depending
on
how
you
actually
manage
your
software
development
process,
because
the
thing
with
hash-based
signatures-
that's
different
than
others,
is
when
you
create
the
tree.
The
number
of
leaf
nodes
defines
the
number
of
signatures
that
you
can
produce.
So
if
you
are
going
to
do
multiple
builds
a
day,
then
that's
probably
not
enough,
but
if
you
expect
you
know
a
release
once
a
month,
that's
plenty,
so
that
that's
a
trade-off
that
I
think
each
software
developer
needs
to
to
do
themselves.