►
From YouTube: IETF105-SUIT-20190724-1000
Description
SUIT meeting session at IETF105
2019/07/24 1000
https://datatracker.ietf.org/meeting/105/proceedings/
A
B
B
B
B
B
The
the
information
model
was
updated
after
IETF
104
that
we
believe
that
the
draft
is
progressing
fairly
well.
We'd
like
to
have
some
conversation
later
about
the
next
steps
there
and
we've
been
running
a
call
for
working
group.
Adoption
of
the
C
bore
manifest
serialization
formats,
which
we
also
have
to
resolve
at
this
meeting.
B
Okay,
so
I'm,
so
at
ITF
104,
we
we
pulled
the
room
and
we
there
was
a
lot
of
support
for
adopting
that
draft
and
no
concerns.
We
also
took
that
to
the
list.
There
was
some
additional
support
there
and
no
concerns
so
I'm.
At
this
point,
we
feel
that
there's
consensus
for
adopting
that
draft.
So
we'll
ask
the
author's
suppose
the
next
revision
as
a
draft
IETF
suit,
manifests.
So
thank
you,
I
think.
That's
everything
on
our
status
report.
Any
questions.
B
So
we've
done
well
on
some
of
our
milestones,
but
we
have
a
few
that
are
lagging
at
that.
The
fact
that
we
just
adopted
the
civilization
format
will
allow
us
to
close
that
one
milestone,
and
we
believe
that
the
other
drafts
will
probably
progress
fairly
quickly,
so
we're
a
little
behind,
but
we
should
be
able
to
catch
up
I.
Think
in
the
next
next
meeting
or
two.
E
B
All
right,
so
so,
let's,
let's
start
through
our
drafts
Honus,
would
you
like
to
come
up
and
talk
about
the
architecture.
F
F
So
we
received
different
versions,
but
the
most
recent
one
made
some
other
changes
specifically
to
the
status
tracker,
which
I
would
like
to
point
out
and
would
like
to
walk
away
with
a
decision
on
what
I
should
be
doing
there
to
change
the
terminology
to
make
everyone
happy
and
I
tried
to,
but
there's
a
long,
an
email
from
Brenton
on
the
list,
which
goes
into
essentially
a
review
of
the
document
which
I
don't
think
I
would
want
to
go
into
here
because
many
of
the
things
he
points
out
actually
unrelated
to
what
we
do
here.
F
But
it's
more
consistency
check
on
what
they
wrote
themselves.
So
it's
hopefully
something
that
they
would
take
into
account
when
updating
the
document.
But
this
one
is
worthwhile
to
discuss.
So
we
had
this
notion
of
a
status,
tracker
and
and
I
copied,
or
must
sort
of
summarized
the
definition
from
the
IETF
draft
and
also
from
the
ID
document
and
for
the
IETF
draft.
F
So
that's
why
the
terminology
for
the
status
track
in
the
ITF
trough
currently
only
talks
about
monitoring
the
firmware
update
process,
and
so
it
says,
for
example,
is
it's
a
server
side
component
in
these
in
these
drawings,
in
the
diagrams,
which
basically
retrieves
information
from
the
device,
and
then
CSUN
like?
Where
is
the
update?
So,
for
example,
is
the
device
still
downloading
the
new
firmware
image,
or
is
it
updating
it
already
or
what?
But
is
it
actually
doing?
F
That's
what
the
document
currently
says
and
it
may
be
insufficient,
because
if
you
look,
on
the
other
hand,
at
the
idea
of
the
definition,
it
talks
about.
First
of
all,
monitoring
some
of
the
properties
of
the
device
like
what
what
device
version
is
there
like
certain
attributes?
What
are
the
some
of
the
software
versions
running
there?
Then
it
also
gets
the
update
because
they
are
the
different
starts
already,
because
the
status
track
has
not
just
a
component
in
the
cloud.
It's
actually
and
I
have
a
few
diagrams
here
to
illustrate
this.
F
It's
actually
also
a
component
in
the
device
itself.
Oh,
it
may
be
cascaded
throughout
the
architecture.
So
it's
you
can
see
this
easily
here
so
and
there's
another
diagram
in
the
following
slide.
So
you
have
the
status
tracker
that
runs
here
on
the
device
itself,
but
then
it
talks
to
a
network,
local
status,
tracker
and
that
may
be
sort
of
instructed
by
a
status
tracker
that
is
in
the
cloud
so
and
it
there
may
be
another
one
it
cooperates
with
and
so
on.
F
So
it's
it's
a
slightly
different
sort
of
architectural
model
if
you
will
and
that
that
also
explains
why
it
talks
about
these
additional
components
like
it.
Riess
receives
the
requests
and
then
checks
the
need
for
the
update,
assuming
when
it's
local,
for
example,
it
has
information
about
what
the
devices
software
version
is
is
it
running
on
then
it
can
obviously
do
that
initiates.
The
updates
and
yeah
and
I
mentioned
this
already
the
issue
of
the
concerned.
F
G
F
Yeah
that
I
think
that's
a
typo.
So
it's
it's
really
in
the
device
like
shown
here
yeah.
So,
for
example,
you
have
this
IOT
device
that
comes
with
a
Status
track
has
a
separate
component
and
then
there
may
be
actually
multiple
firmware
consumers
on
a
single
device,
and
so,
for
example,
this
could
be
a
device
with
multiple
MCU.
So
each
one
would
have
those
type
of
things
and
in
this,
but
Brendon
may
have
a
different
view
on
this
and
then
the
status
tracker.
H
H
G
F
Hopefully,
Brendon
can
fix
this
issue,
so
I've
been
wondering
what
what
should
be
done
to
the
document,
to
make
some
alignment
and
and
and
to
make
sure
that
there's
some
meaningful
content
in
in
the
device.
So
what
often
happens
is
and
I
believe
the
status
tracker
is
essentially
a
different
way
of
saying
that
there's
a
device
management
functionality
and
what
that
typically
does
is
you
have
a
normally.
You
have
a
component
somewhere
a
server
side
component
that
the
devices
talk
to
because
normally
like
you
in
in
many
deployments,
it's
do
you
have.
F
The
device
is
sitting
out
there,
but
of
course
the
server
needs
to
know
about
those
devices
upfront.
So
he
can't
just
send
firmware
updates
there
when
it
doesn't
even
know
that
the
devices
are
awake,
they
they
are
waiting
for
software
updates.
It
needs
to
know
and
like
what
is
this
device
running
on
is
specifically
if
it
wants
to
target
a
specific
software.
It-
and
you
know
so.
I
G,
if
more
in
my
target
are
anticipated
by
the
ITU
is
poor
one
as
it
does
not
adequately
cover
a
variety
of
scenarios
required
by
different
IOT
devices
based
on
differences
in
I
device.
Functional
connectivity
available
poverty
et
Cie
ITA
should
not
try
to
do
too
hard
to
align
with
it
other
than
avoid
conflicting
and
confusing
terminal,
and
then
there's
a
Brendon
was
saying
that
there
is.
This
sort
of
tracker
may
reside
inside
the
status
tracker,
which
was.
F
So
so
continuing
what.
K
K
Attack
you
see
from
a
knight
city.
Thank
you
very
much
for
the
discussion
for
the
scissors
tracker
I,
just
write,
email
from
branding
and
also
discussion
today.
Sorry
for
that
and
I
think
the
discussion
in
the
email,
it's
very
correct,
I
agree
with
the
point,
and
the
point
you
said
today
is
I
ETH
not
be
putting
too
much,
but
I
also
agree
on
that.
So
we
ITT
will
be
doing
our
effort
to
follow
the
program
you
raised.
K
L
M
K
F
F
It
knows
what
devices
need
to
be
updated
and,
of
course
it
also
knows
their
communication
behavior,
because
it
may
not
not
all
of
that
it
as
devices
will
be
always
reachable,
so
it
it
deals
with
this,
and
so
this
is
a
purely
communication,
specific
issue,
but
still
quite
important,
because
after
all,
the
updates
have
to
go
there
and
then
it
the
way
how
the
updates
are
triggered
also
varies.
It
may
be
purely
like
triggered
by
the
server
once
the
software.
F
The
new
software
is
there,
the
server
could
trigger
it,
the
update,
and
that
would
happen
or
it
could
be
a
policy
base
depending
on
like,
if
you
think
about
cars,
you
don't
just
do
the
updates
whenever
the
software
is
there,
but
obviously
have
to
take
certain
other
aspects
into
account
and
so
on,
and
there
may
be
some
user
consent
that
takes
place
etc.
F
Because
it's
not
core
to
what
we
actually
do,
I
think
it's
useful
information
to
know
how
these
systems
work
today,
but
we
don't
actually,
they
standardize
and
define
the
status
tracker
sort
of
like
the
IOT
device
management
protocol
in
this
in
this
group
they
are
already
those
protocols.
So
so,
how
much
should
we
accommodate
for
that?
F
To
give
to
read
enough
and
you,
and
and
whoever
wants
to
look
at
that
document
to
give
enough
information
without
going
off
into
the
weeds
on
explaining
things
that
are
only
sort
of
what
really
or
less
frequently
relevant
for
what
we're
actually
doing
in
a
group
itself?
And
so
my
my
what
I'm
I'm
proposing
is
we
describe
some
of
the
stuff
that
I
have
on
this
slide
nicer
boarding
and
in
the
terminology
section,
so
it's
more
than
what
we
had
previously.
We
take
some
of
that
into
account.
F
This
specifically
is
kind
of
nested
aspect,
because
that's
also
how
things
are
deployed
today,
not
so
much
the
status
tracker
on
the
device,
but
for
examples
that,
if
you
you
have
device
management
functionality.
Also
in
gateways
today
like
there
are
lots
of
edge
computing
devices,
and
so
you
have
this
sort
of
device
talks
to
gateway
gateway
talks
to
to
some
server
and
I.
Think
that's
also
good
to
capture
what
is
actually
being
done
today,
but
I
wouldn't
go
further
than
that
and
specifically
having
the
status
tracker
on
a
device
itself.
F
Specifically,
if
we
talked
some
really
constrained
devices,
that's
rather
unlikely,
and
maybe,
if
that's
important,
there
should
be
a
different
term
for
that
to
avoid
are
creating
the
confusion.
So
that's
that's
my
proposal.
That
would
be
an
update
and
I
could
spin
that
fairly
fairly
quickly
and
have
a
few.
You
review
that
if
you,
if
you're
familiar
with
this
type
of
work
yourself,
I,
think
that
would
I
would
appreciate
your
feedback.
F
M
H
M
H
M
F
Sounds
perfect
yeah,
so
I'm,
not
I'm,
not
aware
of
any
other
requests
for
changes
is
anything
that
comes
to
your
mind,
something
that
I
have
to
have
to
do.
N
C
B
B
L
H
That
I
did
add
two
more
significant
edits.
Those
are
the
result
of
a
review
by
a
security
engineer
in
arm.
The
result
of
that
was
a
new
threat
that
I
hadn't
considered
before,
which
is
extra
code
following
the
code
covered
by
a
digest.
So
this
is
what
happens
when
the
payload
that's
delivered
to
a
device
is
larger
than
is
specified
in
the
manifest
when
the
digest
doesn't
cover
the
whole
thing
and
for
whatever
reason
that
still
gets
written
into
the
device.
H
So
the
solution
to
this
is
to
digest
past
the
end
of
the
firmware
cover
the
whole
available
space
and
use
that
as
the
firmware
digest
so
I've
added
this
as
a
recommended
security
requirement,
not
a
required
one,
and
then
there
was
a
new
use
case.
The
addition
of
delegation
of
authority
and
a
usability
requirement
associated
with
it,
which
was
the
ability
to
deliver
a
delegated
signing
key
with
the
manifest,
and
that
is
all
for
edits.
B
E
C
B
H
B
H
H
L
F
Yeah
that
these
audio
problems
sometimes
happen
so
as
you've
seen
also
from
like
we
had
written
some
of
those
scenarios
in
the
architecture
document
notes
elaborated
on
it.
In
the
information
model
document
you
have
the
wide
range
of
different
IOT
devices
and,
while
sort
of
the
basic
scenario
is
very
simple,
where
you
have
a
single
MCU,
you
have
a
single
firmware
image
and
that
gets
installed
and
everything
is,
is
cool.
That's
not
necessarily
all
the
cases
that
we
have
to
deal
with.
F
If
you
open
up
one
of
the
IOT
devices
that
you
find
around
like
this
camera,
or
you
pick
any
of
those,
you
will
see
that
there
are
many
different
hardware
architectures
that
chip
manufacturers
came
up
with
that
require
different
treatment.
You
may
have
multiple
ends,
use
and
so
print
listed
a
couple
of
those
here
where
you
have,
for
example,
in
in
more
modern
architectures.
F
You
have
a
split
between
the
secure
word
and
a
normal
word,
and
you
have
different
codes,
so
you
have,
you
may
have
a
different
stack
offered
by
the
OS
and
the
underlying
sort
of
the
middleware.
So
if
the
kernel
and
the
middleware
that
is
provided
by
one
manufacturer,
including,
for
example,
the
radio
stack
and
then
the
application
provided
by
someone
else-
and
you
may
actually
want
to
update
those
independently,
this
execute
in
place
is
also
a
very
common
technique.
In
some
other
devices,
specifically
wireless
LAN
device.
F
You
often
have
the
case
that
very
much
like
in
in
more
powerful
processor
architectures.
You
actually
need
to
cop
the
code
first
into
RAM
before
you
execute
it.
This
is
not
necessarily
true
in
many
other
devices
where
you
execute
it
straight
from
flash.
So
it's
a
very,
very
different
models
and
you
need
to
take
those
into
account
during
their
during
the
update
the
update
model.
There
are
also
different
practices
on
how
you
actually
do
the
procedure.
Where
do
you
copy?
F
Is
it
just
telling
out
okay,
it's
somewhere
else,
or
do
you
actually
have
to
swap
the
code
as
a
consequence
of
that
and
that's
what
print
and
try
to
elute
here?
So
you
have
to
cover
different
cases
and
depending
on
who
you
talk
to,
they
have
different
models
and
you've.
Seen
that
discussion,
when
we,
when
we
talked
to
the
MCU
folks
who
joined
the
list
and
also
Co,
also
the
the
architecture
document
who
are
working
on
on
different
hardware
systems,
then
then,
for
example,
we
do
so
they
tried
to
cover
a
wider
system.
F
So
we
have
a
couple
of
OS
vendors
who
target
a
larger
set
of
hardware,
architectures
and
so
taking
those
different
architectures
into
account
was
obviously
part
of
the
the
work.
As
you
know,
as
you
know,
if
you
have
followed
along,
we
also
spent
specifically
information.
While
we
spend
a
lot
of
time
on
talking
about
the
different
roles
and
the
different
players
in
that
ecosystem
and
as
as
the
firmware
updates,
gets
propagated
and
gets
sent
to
the
device,
there
are
many
different
actors
that
may
influence
the
decision
on
what
gets
installed.
F
We
had
these
cases
of
medical
devices
where
you
can't,
just
as
a
device
manufacturer,
push
the
update
to
the
device,
but
you
have
to
take
into
account
that
there's
certification
processes
in
and
regulatory
regimes
that
are
big
date
on
what
you
can
and
cannot
update
and
who
needs
to
approve
the
updates,
and
so
we
had
many
of
those
actors
listed
in
the
information
model
document
and
that
also
influenced.
That
is
sign.
F
Of
course,
if
you
ignore
all
of
this,
if
this
solution
would
be
much
simpler,
you
just
take
a
subset,
and
so
we
try
to
indur
in
the
specification
and
manifest
specification.
We
try
to
accommodate
for
a
different
use
cases,
even
though
you
may
not
use
some
of
the
features
in
your
in
your
specific
deployment,
or
at
least
not
that
at
the
given
point
in
time.
F
Right,
I
load
it
to
that
already
earlier.
So
many
of
the
devices
today,
even
though
they
are
very
simple,
so
some
of
you
so
who
has
been
playing
around
with
arduino
like
the
8-bit
microcontrollers,
who
has
yeah
a
couple
of
you
guys
so
like
those
are
really
basic,
microcontrollers
and
very
simplistic.
F
It's
very
nice
to
work
with
and
and
the
pin
layout
is
Soak
they're
sold
huge
pins
that
you
can
even
sort
them
so
they're
very
simplistic,
but
in
many
iid
devices,
even
even
we
talked
about
constrained
devices,
obviously
not
the
way
how
they
look
like.
So
if
you,
if
you
open
up
one
of
those
boxes
or
your
SmartWatch,
you
will
notice
that
there
are
lots
of
different
components
that
need
to
interact.
F
And
specifically
since
we
thought
Internet
of
Things,
they
are
there's
a
common
practice
in
industry
that,
if
you
have
radio
modules,
a
radio
component
like
Bluetooth,
Low
Energy
or
you
have
15.4
or
cellular
that
they
actually
reside
on
separate
microcontrollers,
because
the
company
offering
that
support,
they
branch
it
out
to
different
components.
And
so
you
have
different
microcontrollers.
You
have
to
manage
the
updates
for
so
that's.
Why
we
had
this
these
requirements
to
have
a
Singh,
have
the
manifest
to
carry
multiple,
different
firmware
updates
and
to
describe
what
goes
where
yeah.
G
F
Is
now
now
this
was
more
like
more
generic
sort
of
interaction.
Well,
why
did
we
end
up
with
all
these
different
sort
of
what
as
an
outside?
If
you,
if
you
come
into
the
group
and
look
at
the
document
for
the
first
time
you
want
to
like
or
we
talk
about
constrained,
IOT
devices?
Why
is
this
so
complicated
and
the
reason
that's
the
reason
where
we
ended
up.
We
initially
thought
it
would
be
simple
as
well,
but
yeah
that's
and
that's.
B
F
B
F
So
we
in
in
the
discussions
around
December,
when
Dave's
colleague
from
Microsoft,
jumped
in
and
suggested
a
different
alternative
format,
because
he
had
a
very
specific
architecture,
mind
we
had
this
debate
about
like
could
we
have
different
formats?
Could
we
come
up
with
different
ways
to
make
it
really
optimize
for
specific
environments
like
the
whole
debate
we
had
about?
Could
we
just
encode?
F
We
want
to
have
one
format
we
don't
want
to
have
different
formats
for
the
different
architectures
and
we,
but
obviously,
at
the
same
time
we
want
to
have
a
very
simple
pasa
we
want
to
make,
because
why
do
we
want
to
have
the
simple
possible
under
on
and
that
actually
relates
to
the
track?
I
talked
about
before,
okay.
H
H
B
F
Yeah
I
will
continue
so
so
previously
what
I
mentioned
with
the
status
tracker.
So
when
that
the
phone
wept
it
gets
sent
to
the
device
it's
running
in
like
the
regular
application
and
it
gets
to
gets
the
update.
But
then
it
needs
to
do
some
passing
there
and
so
and
that
level
of
functionality
there.
You
have
typically
more
sophisticated
code
to
do
the
passing
and-
and
we
have
maybe
see
what
code,
of
course
on
cozy
code.
F
For
other
reasons
or
very
at
that
part
of
the
application
firmware
and-
and
that's
great
that
that
needs
to
happen,
because
you
don't
want
to
want
someone
to
send
your
garbage
and
then
you
switch
off
the
device
and
then
go
into
a
put-on
state.
But
you
wouldn't
trigger
the
device
to
go
into
this
other
state
where
the
bootloader
has
to
decide
what
firmware
it
starts
and
that
sort
of
is
a
needs
to
be
a
somewhat
simpler
format,
because
you
don't
want
to
have
a
huge
amount
of
code
in
that
bootloader
as
well.
F
You
want
to
keep
the
bootloader
as
simple
as
possible,
but
you
still
need
to
for
having
some
security
a
lot
of
security.
You
want
to
go
sort
of
like
through
this
secure
boot
sequence,
so
you're
essentially
reusing
the
same
format,
but
is
that's
what,
for
example,
aims
you
guys
are
looking
into
digital
strip
off
some
part
of
what
was
received
over
the
wire
previously
and
verified
you
repurpose
that
for
the
use
of
secure
boot,
because,
ultimately
the
bootloader
comes
up.
F
It
has
a
key
provision
and
it
needs
to
verify,
for
example,
the
digital
signature
of
the
image.
It's
going
to
start
and
that's
what
it
does
everywhere.
Every
time
it
stands.
So
that's
that
has
to
be
better,
be
a
very
simplistic
code.
That's
sort
of
like
you
want
to
have
those
simple
parsers,
specifically
at
the
bootloader
side,.
E
H
J
H
So
yeah
from
what
he
was
saying,
I
agree
the
simple
part
to
construct
a
simple
parser.
You
need
to
have
few
unique
structures
and
load
nesting
levels
and
and
as
Hannes
was
saying,
simple
parsers
are
very
much
needed
in
IOT
devices
that
have
very
constrained
sizes
and
in
boot,
loaders.
H
The
next
thing
is
that
most
update
use
cases
use
similar
operations.
These
are
things
such
as
copying,
a
bit
of
firmware
from
one
place
to
another,
whether
that's
remote
or
local,
checking,
digests,
checking,
statuses
of
or
properties
of
different
elements
of
the
device
and
other
things
such
as
telling
other
parts
of
the
device
to
suspend
or
resume
function,
and
that
most
use
cases
use
these
same
fundamental
operations,
just
in
varying
orders
and
with
varying
endpoints.
And
finally,
the
possibly
controversial
point
is
that
an
update
consumer
doesn't
actually
care
what
their
update
is.
H
They
care
what
they
should
do
with
it.
So
your
IOT
device
cares
nothing
about
what
the
update
is.
It
just
needs
to
know
how
to
install
it,
so
that
makes
the
suggestion
that
perhaps
we
should
look
at
a
sequence
of
update,
relevant
commands.
Now
this
is
a
bit
of
a
rehash
of
the
the
arguments
that
I
made
for
behavioral
updates
with
the
version
for
manifest
next
slide.
Please.
H
So
the
currents
structure
lays
out
several
parts:
we've
got
external
information
now.
This
is
information,
that's
used
by
code
outside
of
the
manifest
itself,
so
that
in
our
sorry,
outside
of
the
manifest
processor,
so
that
involves
the
structure
version
so
that
the
parser
is
able
to
determine
whether
or
not
it
can
use
the
manifest
followed
by
the
sequence
number
now
that's
used
by
other
parts
of
the
code
to
determine
which
manifest
it
should
process.
H
Next
we
have
common
information
which
includes
dependencies
component
identifiers
and
something
called
the
common
sequence.
If
you've
read
through
the
draft
or
if
you
remember,
IETF
104,
where
I
talked
about
this,
you
may
be
familiar
already
with
what
the
common
sequence
does,
but
essentially
it
runs
before
any
other
sequence
and
what
it
does
is
sets
up
the
environment
so
that
common
decisions
can
be
made
in
one
place
which
reduces
encoding
size
and
a
common
common
variables
such
as
component
digests,
can
be
initialized
in
the
same
place
which
again
reduces
encoding
size.
H
Next
we
have
the
command
sequences.
Those
are
the
six
following
sequences,
the
dependency
resolution,
payload
fetching
installation
and
then
validation
loading
and
run
those
happen
in
two
different
use
cases.
The
first
three
happen
during
installation.
The
second
three
happened
during
secure
boot
type
operations
and
finally,
we
have
either
text
or
a
text
reference
section.
This
goes
back
to
the
severable
section
concept
that
we've
discussed
previously
next
slide.
Please.
H
So,
in
terms
of
a
summary
of
changes,
oh
good
I
forgot
to
fill
in
the
numbers.
Summary
changes
from
zero.
Four
I've
moved
the
common
elements
into
a
nested
B
string.
This
is
effort,
used
parsing
complexity
and
improved
consistency
in
the
format.
Now,
what
I
mean
by
consistency
in
the
format
is
that
everything
else
in
the
manifest
structure
is
wrapped
in
an
e
string,
with
the
exception
of
the
structure
version
and
the
sequence
number
so
wrapping
the
common
section
in
a
B
string
also
makes
the
parser
more
consistent
for
reducing
parsing
complexity.
H
This
is
because
the
common
section
is
referred
to
back
to
by
all
of
the
other
sequences,
so
having
a
single
common
mechanism
to
point
back
to
it
makes
it
simpler
to
implement
the
parser,
since
it
only
needs
to
hold
one
reference,
and
it
has
a
fixed
size
in
which
to
parse,
which
makes
the
MM
parser
a
bit
cleaner
to
implement
so
I've
also
changed
the
encoding
of
command
sequences.
Previously
command
sequences
consisted
of
a
list
of
maps.
H
Each
map
contained
only
one
key
value
pair
after
discussion
with
Karsten
and
Hank
I
have
concluded
that
the
most
sensible
way
to
implement
this
is
by
a
sequence
of
keys
on
even
numbers
and
values
on
odd
numbers,
but
I.
Don't
think
it
has
to
be
that
restrictive
I
think
it
just
has
to
be
a
key,
followed
by
a
fixed
number
of
arguments
and,
and
those
can
be
encoded
in
a
flat
way.
They
don't
have
to
be
in
maps
next
slide.
Please.
H
And
I've
changed
handling
of
optional
sequences.
This
was
a
very
late
addition,
so
I
haven't
had
a
chance
to
work
out
the
examples,
and,
after
some
discussion
with
experts
on
language
design,
I
have
been
convinced
that
we
were
missing
an
else
previously.
It
was
possible
to
live,
set
ace
a
number
of
sequences
together
that
that
each
tested
on,
if
tight
case,
but
there
was
no
way
to
define
that
it
wasn't
that
there
was
an
else
type
case
either.
H
What
they
suggested
was
that
we
pack
together
any
number
of
conditional
sequences,
but
have
them
wrapped
in
one
list
and
have
the
stipulation
that
at
least
one
of
these
sequences
must
pass.
This
allows
us
to
have
a
a
try
else.
Try
else
try
else
type
structure,
I've
added
support
for
encrypted
manifests
the
mechanism
to
do
this
was
to
put
in
new
values
and
define
them
as
mutually
exclusive.
Sorry,
not
new
values,
new
keys
in
the
outer
wrapper
and
defined
them
as
mutually
exclusive,
with
the
existing
key
for
the
manifest.
H
I've
also
moved
to
defining
suit
specific
digest
identifiers
in
response
to
some
discussions
that
I
had
following
IETF
104,
and
there
was
some
mailing
list
discussion
about
the
named
identifiers,
straf
t',
including
some
digests-
that
absolutely
should
not
be
supported,
such
as
ones,
truncated
to
32
bits,
but
not
supporting
some
digests.
That
probably
should
be
supported,
such
as
the
shot
to
2
to
4
family.
And
finally,
there
were
a
fair
number
of
editorial
changes.
Next
slide.
Please
I
think
that's
it.
N
H
F
The
tip
meeting
I
I,
suggested
to
do
our
very
upfront
preparation
for
the
next
hackathons
and
because
this
this
meeting
was
a
little
ankle
inconvenient
for
some
of
the
folks,
unlike
neither
manually
into
their
guys
and
Brennan,
is
not
here
and
so
on.
But
for
the
next
one
I
was.
We
were
wondering
indeed
whether
there
would
be
interest
to
actually
do
a
sort
of
a
tutorial
hands-on
tutorial
before
the
hackathon,
because
it
would
allow
some
of
the
newcomers
to
actually
get
up
to
speed
on
the
hands-on
part.
F
So
they
can
actually
didn't
benefit
in
the
hackathon,
because
otherwise
it
gets
a
little
tricky.
But
if
I
have
to
bring
hardware
along
I
need
to
know
up
front
I
can't
just
fill
up
my
luggage
with
stuff.
So
it
would
be
nice
to
know
if
there
is
interest
in
in
doing
that
and
then
I
bring
the
piggy
along.
N
B
And
really
that's
a
separate
issue
from
what
you
you
just
mentioned:
I
mean
we
can
we
can
do
the
trip,
the
training
as
well?
If
it's
not
convenient
to
do
it
before
the
hackathon,
we
might
be
able
to
take
care.
Take
some
side
meeting
time
or
you
know
for
an
interim
even
right
to
do
that
training
ahead
of
the
next
night
yeah.
That's
something
else
that
we
should
consider
and
I
think
we're
interested
in
thoughts
on.
You
know
what
what
folks
would
prefer.
I
B
D
Roman,
nearly
back
on
the
3rd
of
a
half
papania
I
would
strongly
encourage
some
prep,
where
I've
seen
kind
of
groups
to
get
together
and
come
up
with
a
plan
coming
into
the
actual
kind
of
Saturday
kind
of
Sunday
activity.
There's
been
phenomenal
results
so
strongly
encourage
virtual
interim
or
whatever
might
help.
M
Dave
Taylor
slightly
different
topic,
but
related
Honus
triggered
so
I'm,
actually
at
the
mic
as
a
teep
chair
and
wanted
to
give
a
short
report
out
on
the
relationship
between
teeth
and
the
manifest
format.
So
teep
had
an
interim
meeting
in
between
104
and
105,
and
Brendon
gave
the
presentation
presenting
the
suit
manifest
format
to
the
teeth
working
group,
so
the
teeth
working
group
could
make
a
decision
as
to
whether
they
wanted
to
take
a
dependency
on
suit.
Okay,
the
outcome
of
that
is
the
teeth.
M
Working
Beck
got
consensus
that
says
the
teeth
working
group
and
the
OTP
protocol
will
take
a
dependency
on
the
suit
manifest
okay
and
so
part
of
the
discussion
had
to
do
with
suit
is
primarily
chartered
with
having
and
a
manifest
format
for
firmware
updates
and
teeps
use
case
is
not
necessarily
updating
firmware
right.
It's
updating
stuff
that
goes
into
at
EEE,
which
includes
firmware
and
none
firmware,
ok
and
so
way
back
even
in
the
BOK
we
talked
about.
M
Is
this
for
software
update
or
firmware
update,
or
what
and,
and
so
Brendan
explained
that
the
manifest
format
was
generic
enough
to
not
be
constrained
firmware.
Only
ok,
even
though
that's
the
primary
outcome
of
the
primary
goal
of
suit.
Ok,
so
that
was
the
basis
of
discussion,
and
so
the
consensus
was
that
the
belief
is
the
cert
manifest
format.
Even
though
it's
designed
for
a
firmware,
it's
designed
for
all
the
constrained
requirements
that
we
have
in
suit.
It
is
not
limited
to
that.
M
Ok,
and
so
the
consensus
was
that
t
p--
was
planning
to
use
the
suit
manifest
as
long
as
it
stayed
generic
right
as
long
as
it
stayed
such
that
it
was
not
limited
to
use
for
firmware,
which
is
the
current
case
and
Brendan.
As
the
author
was
explaining.
Yes,
you
could
use
it
for
many
different
purposes
right
at
your
generic
format.
It
happens
to
meet
all
the
requirements
for
IOT
and
firmware
and
so
on,
because
who
does?
M
But
it
also
happens
to
meet
the
requirements
that
keep
head
to
you,
and
so
the
outcome
is
that
currently
cheapest.
Choosing
in
the
OTR
PV
to
document
that
Hannes
authored
and
presented
in
the
teeth
working
group
ago
this
week
that
it
would
have
a
normative
reference
to
the
suit
manifest
format,
even
for
purposes
not
just
firmware
per
se.
Okay,
that
is
the
current
status
and
so
from
the
t,
p--
working
group.
M
We
hope
that
the
suit
working
group
continues
to
along
the
same
lines
as
it
is
doing
and
the
teeth
would
be
happy
to
use
it,
and
so
that
was
me
just
summarizing
us
chair.
What
I
think
the
consensus
from
the
interim
meeting
and
the
meeting
earlier
this
week,
which
we
had
yesterday,
where
Hannes
presented,
how
we
might
be
encapsulate
this
you
manifest
in
the
ojp
protocol,
so
Dave
this.
N
M
Progress,
the
chairs
had
that
discussion
and
right
now
our
belief
is
that
the
suit
manifest
will
naturally
precede
the
auteur
IP
spec
in
the
progress
meaning.
We
think
that
the
suit
manifest
is
more
nailed
down
than
the
OTP
discussion.
So
the
answer
is
yes,
but
it's
not
something
that
we
have
any
concerns
about
at
this
point.
So,
okay,
thank
you.
A
Empire
I
also
look
on
Latif,
so
I,
just
personal
on
that
conquer.
What
they've
said
singing
as
the
comments
on
the
importance
of
a
generic
format,
idiotic
terminology,
it's
40,
we
decided
and
want
to
leverage
a
suit,
but
for
our
terminology,
wise
will
have
say,
will
have
a
rich
world.
I
said
no
more
application,
application
and
dependent
trust
application.
As
a
suitor
animation
might
perform
aware
on
limited
form
of
HTTP
general
software
and
they
will
have
software.
We
have
a
trusted
application
in
tipo
world.
That's
one!
Second
awareness
about
dependency.
A
We
also
want
to
leverage
the
suit
to
address
the
case
where
I
install
application,
one,
it
depended
t81,
tma-22,
ts3
and
and
go
further
and
further
that's
a
complex
problem
and
every
piece
Ida
said:
ok,
what
collaborate
suit.
Maybe
it's
a
wedding
suit
scope?
How
much
that
will
handle
that
in
a
simple
way
outside,
but
maybe
able
to
stretch
it
but
I.
Think
it's
a
complete
problem
overall,
no
matter
it's
a
firm
way
or
software
or
trust
application.
It
is
I.
H
So
suit
definitely
responds
to
the
dependency
question
and
suit
addresses
it
in
a
way
that
doesn't
require
the
same
signer
on
each
of
the
components
that
you
install.
It
explicitly
allows
different
signers
for
different
components.
What
it
also
does
in
order
to
forcibly
break
the
possibility
of
circular
dependencies
is
that
it
relies
on
cryptographic
digests
of
dependencies,
which
prevents
you
from
ever
constructing
a
circular
dependency.
M
M
Is
explaining
that
because
you
were
breaking
up
there?
Yes,
the
suit
manifest
does
have
a
way
of
addressing
the
circular
dependencies
question
and
Brendan
was
attempting
to
give
some
details
that
were
started
breaking
up
as
to
exactly
how,
but
the
teep
working
group
is
saying
the
teeth
working
group
will
just
rely
on
the
suit
working
group.
Solving
that
problem
and
the
teeth
will
working
group
will
not
try
to
solve
the
problem
themselves.
It's
just
taking
a
dependency
on
suit.
To
do
that.
That's.
A
M
M
The
binary,
your
can
be
R
per
visioning,
say
configuration
of
the
binary
right,
and
so
we
call
that
we
antique
call
that
personalization
data
because
it
may
be
encrypted
by
the
device
specific
key
right,
so
that
no
other
device
can
I'm
trying
to
configure
this
device,
and
only
this
device
right,
and
so
the
suit
manifest
is
capable
of
passing
yo
files
and
things.
And
so
that
could
be
considered
to
be
part
of
this.
M
You
manifest
the
open
issue
is
has
to
do
with
trust,
anchor
update,
and
so,
if
you're
going
to
update,
say
the
keys
in
a
device
whatever
you're
using
for
your
trust,
ank
you're,
going
to
update
the
the
contents
of
your
trust.
Anchor
store
is
that
personalization
data
that
you
might
manage
with
a
Spile
and
a
suit
manifest,
or
is
that
something
you'd
use
a
different
protocol
or
mechanism,
for
that
is
something
the
teep
working
group
is
not
heavy
proposal.
A
Mean
playing
games,
I
judge
I,
have
to
say
the
trust.
Anchor
comes
it'll,
look
different
from
complication
data
become
with
it
as
a
less
sensitive
than
trust.
Anchor
we'll
talk
about
that
Ruta,
at
least
of
a
rule
to
say,
certificates,
just
like
brother
right,
the
browser,
vendors
control
that
it
or
take
it
very
seriously.
Who
do
you
trust
now?
How
much
is
that,
in
a
suit
as
a
format,
I
can
say
the
more
a
dependent,
a
format
our
manifest
and
file
versus
deliver
a
trust
list
at
a
different
problem.
F
This
one
is
yes
in
Stephen
Ming
product,
the
deep
topic,
I'm
curious,
whether
we
should
add
another
use
case
to
the
architecture
document
in
sort
of
pointing
to
the
deep
work
to
the
deep
architecture
document
and
talking
a
little
bit
about
the
sort
of
software.
The
trusted
application
and
also
the
personalization
data,
along
with
it.
So
I.
A
Mean
yes,
I
think
I
concur
Highness!
Well,
let
a
few
subtle
way
to
honor
that
depreciation
right.
These
are
different
entities.
They
work
I,
clearly
explicit.
This
part
reliance
on
a
suit.
This
part
may
need
a
different
approach
so
and
if
a
suicidal
always
see
with
our
particular
trust
anchor
as
a
general
treat
as
a
different,
a
problem
to
not
put
in
scope
this,
whether
you
say
this
will
realize
a
suitor
soffit,
it's
a
it's
a
template
in
your
use
case
of
scope.
O
Randy
Turner
would
lend
us
a
year
I
had
it
would
be
nice
at
some
point
to
get
a
definition
of
the
word
simple,
because
I
was
just
doing
a
rough
back
of
the
envelope
calculation
on
what
I
needed
to
implement
this.
So
there's
a
simple,
simple
parser
looks
like
I
need
a
cosy
implementation,
a
seaborne
implementation,
some
hashing
post
post,
any
hackathon.
It
would
be
nice
to
have
somebody.
Maybe
let
us
know
what
the
size
of
what
they
did
was
or
if
they
were
doing
a
sufficient
or
a
substantial
implementation,
or
what
this
might.
O
O
H
I
fully
agree
with
you.
Getting
the
sizes
down
is
one
of
the
top
priorities.
I've
had
I'm
even
going
back
to
IETF
103.
If
you,
what,
if
you
were
part
of
that,
you
may
have
seen,
Emanuel
I
asked
that
specifically
I'm
so
I
think
working
as
hard
as
I
can
to
get
those
sizes
down.
Now,
when
you
say
a
stibor
implementation,
you
should
note
that
it
doesn't
have
to
be
one
of
the
existing
keyboard.
H
That's
really
difficult
to
get
away
without
I'm,
guessing
that
in
sensors,
that
small
and
don't
have
signatures
so
you're,
probably
using
something
like
H
Mac
for
signature,
verification
that
doesn't
add
much
code,
so
you're
you're
in
a
really
tough
spot
to
get
firmware
update
in
a
device
that
size,
but
it
might
be
able
to
I,
would
question
whether
you
need
something.
That's
completely
application
specific
in
an
8k
range
that
falls
below
the
class
1
device.
P
F
This
one
is
an
app
that
was
part
of
the
exercise,
as
we
worked
on
the
on
at
the
hackathons
and
then
the
work
we
did
in
between
specifically
like
the
Seaboard
question.
Brendon
address
that,
but
also
the
cosy
part,
because
it's
may
be
worthwhile
to
note
that,
for
the
cosy
implementation
you
don't
need
the
entire
specificity
or
implementation
of
the
specification.
You
pick
only
those
features
that
you
really
need
in
because
there's
a
lot
of
stuff
in
the
course
implementation.
F
F
Even
though
the
cozy
workhorses
supports
a
symmetric
crypto,
but
if
you
use,
let's
say
state-of-the-art,
be
256
are
one
type
of
elliptic
curve
cryptography.
Then
you
pay
a
certain
price
and
we
used
in
our
case
empathy,
LS
implementation
and
looked
at
various
other
stacks,
and
you
can
see
how
the
size
differs,
how
the
speed
varies
so
they're
they're
various
trade
off
with
the
different
implementations,
and
you
may
want
to
take
a
look
at
that
depending
on
what
exactly
your
requirements
are,
how
much
time
you
have
for
the
boot
process
and
for
the
verification,
etcetera,
etc.
P
Either
there
my
phone
again
I
I,
would
caution
against
viewing
the
crypto
libraries
themselves
as
being
bigger
than
the
processing
code,
because
the
assumption
is
that
the
crypto
is
all
being
provided
in
software
and
therefore
part
of
the
codebase,
but
we're
seeing
more
often
we're
just
building
the
crypto
at
the
hardware.
So
the
the
SHA
primitive
is
provided
in
the
hardware.
The
EC
primitive
may
be
provided
in
the
hardware:
okay,
so
you're
paying
you're
shifting
the
price
from
software
to
hardware.
But
for
us
that's
we're
willing
to
do
that
now.
P
F
And
then
Brendon,
yes,
and
it's
great,
if
you
have
these
things
in
hardware
and
of
course
that
will
reduce
your
other
code
size.
But
of
course
it
just
means
shuffling
things
around
because
in
reality,
if
it's,
for
example,
if
it's
just
a
separate,
microcontroller
or
a
different
feature,
so
you
will.
You
could
as
well
have
a
larger
microcontroller
and
pay
the
same
price
and
just
have
any
software,
so
you're
moving
stuff
around.
But
ultimately
the
functionality
has
to
be
somewhere.
I
Channeling
Keith
Moore
one
concern
I
have
is
how
many
different
things
does
the
implementer
have
to
know
and
understand
in
order
to
build
an
implementation,
that's
appropriate
for
their
product.
Some
things
like
hashes
and
signatures
are
none
available,
but
encoding
really
needs
to
be
as
simple
as
possible.
The
manifest
world
needs
to
be
as
simple
as
possible.
I
H
Brendan
go
ahead:
hi,
Keith,
I
completely
agree
with
you.
It
does
need
to
be
simple.
I
think
that
the
behavior
encoding
will
turn
out
to
be
simpler
than
you
expect.
The
only
way
to
prove
that
to
you,
of
course,
is
to
show
you
an
implementation.
So
that's
what
I
am
working
on
now.
I
think
that
we
need
to
do
is
to
provide
a
few
example
sets
that
show
what
you
would
need
to
implement
on
a
few
classes
of
device.
B
B
I
I
I
F
And
that
that
also
leads
to
the
hackathon
our
questions
we
different
people
come
along
with
that
yeah
favorite
devices
I
think
it
gives
us
a
better
way
to
sort
of
get
their
size
measurements
down,
and
we
had
some
of
those
guys
they
already
with
different
devices
but
having
more
people
come
along
and
participate
so
that
we
may
be
at
the
end,
even
have
a
reference.
Implementation
of
people
can
use
to
avoid
mistakes.
Our
basic
mistakes
would
be
really
useful,
so
you
guys
have
a
chance
to
participate.
That
would
be
good.
E
F
So
I
can
post
them.
I
can
boast.
F
D
Was
just
added
so
Roman,
generally
Academy
we're
talking
about
kind
of
implementations,
we're
talking
about
things
are
in
slides
things.
A
result
of
a
hackathon
I
might
strongly
encourage
the
creation
of
a
wiki
page
that
just
enumerate
set
implementation,
so
we
have
running
list
folks
can
see
it
folks
can
add
to
it
in
it
transparent
way.
The
track
wiki,
github
wiki,
whatever
makes
sense,
I.
D
Room
engine
again
that
would
be
fabulous.
You
know
when
I
read
the
Shepherd
reports
and
I
want
to
bring
documents
forward.
One
of
the
first
things
I
check
for
is:
do
you
have
running
code,
or
are
you
just
saying
the
working
group
kind
of
talked
about
it
and
I
have
a
tendency
to
want
to
have
a
conversation
about
drafts
that
don't
have
a
piece
of
running
code
that
you
can
point
to,
and
typically
I
like
to
see
URL
as
well.
So
all
this
would
help,
and
so
I
do
appreciate
that.
M
So,
thank
you
great
suggestion.
We
do
have
a
suit
wiki
page
created
right
now
put
on
your
task
like
one
main
link
in
it
and
I.
Think
it's
a
great
suggestion.
No,
it
doesn't
have
implementations
on
it
yet
right,
and
so
thank
you
that
suggestion
let's
go
ahead
and
do
that
as
chairs.
If
people
have
implementation
links,
send
them
to
us,
I
don't
know
if
other
people
have
the
option
to
edit
the
wiki
themselves
or
if
it's
just
the
chairs.
If
you.
M
D
And
one
particular
practice
I've
seen
very
helpful
as
we
kind
of
talk
about
this,
whether
you're
watching
TLS,
dots
and
East.
This
may
not
be
the
case
in
this
working
group,
but
as
more
documents
get
published,
it's
not
a
matter
of
just
saying.
I
have
an
implementation
for
this
working
group.
I
have
an
implementation
relative
to
a
particular
set
of
drafts
and
a
particular
set
of
versions
of
the
draft.
So
if
implementers
can
talk
about
a
relative
to
draft
and
specific
version
numbers
that
would
be
a
great
help.
B
So
we
have
so
I
believe
that
I'll
start
then
my
co-chairs
can
can
add
to
this.
We
talked
today
about
updating.
Our
milestones
will
will
propose
some
new
dates
that
are
more
reasonable
to
our
ap.
B
N
D
Room
into
new,
you
know,
I'll,
repeat
my
point
about
kind
of
milestones.
I
know:
we've
had
broad
ITF.
Why
conversations
about
how
real
they
are
our
and
how
they
not
I,
think
the
most
important
thing
for
the
publishing
the
milestones
is
about
getting
other
people
involved
in
the
work.
It's
so
folks
from
the
outside,
who
aren't
perhaps
not
in
the
room,
can
actually
get
a
better
sense
of
the
timeline
and
when
things
might
be
ready
yeah,
so
it's
actually
I.
Do
it
as
as
important
as
a
project
management
thing
lightly,
but
as
a
marketing
tool.
B
So
we
can
do
maybe
three
or
four
week.
You
know
last
call
on
the
information
model
to
allow
for
time
for
vacations
and
whatnot
and
then
the
other,
the
other
action
I
think
was
since
we've
adopted
or
since
we've
we've
completed
the
last
call
on
the
architecture
we
in
order
to
complete
the
last
call
in
the
architecture.
We
need
to
do
one
more
Rev
to
adjust
the
text
around
status.
Trackers.