►
From YouTube: IETF115-SUIT-20221109-1300
Description
SUIT meeting session at IETF115
2022/11/09 1300
https://datatracker.ietf.org/meeting/115/proceedings/
B
C
D
A
E
A
A
A
Remind
you
of
the
note
well,
please,
if
you're
going
to
contribute,
know
your
rights,
Privileges
and
responsibilities
and
please
treat
each
other
with
respect
and
we'll
we'll
make
better
technical
decisions.
That
way
we
just
did
the
administrative
tasks.
A
And
here
is
the
first
part
of
the
agenda
and
the
second
part
of
the
agenda.
Are
there
any
agenda
bashes.
D
Day,
favor
I
have
to
present
in
the
room
next
door
for
10
minutes
about
45
minutes
in
and
since
our
usual
rule
of
thumb,
you
don't
see
times
up
here
and
that's
because
the
things
that
are
the
most
well
Advanced
documents
we
let
them
run
until
we
actually
get
them
done,
because
we
want
to
ship
them
or
whatever.
D
So
that's
why
you
don't
see
times
on
here,
so
that
means
we
reserve
the
right
to
do
Dynamic
swapping
towards
the
end,
so
that
the
things
that
teep
does
not
directly
reference
are
the
ones
that
might
be
done
during
the
10
to
15
minutes
here.
So,
for
example,
I
have
to
be
in
the
room
for
the
firmware
updates,
because
Russ
is
an
author,
whereas
things
like
mud
and
MTI
to
might
actually
move
up
depending
on
where
we
are
after
45
minutes
or
so
so
that
we'll
do
that
real
time.
D
Yeah
I
think
for
an
interested
time
any
of
the
hackathon
stuff
can
be
done
in
tip
and
any
of
the
actual
outcomes
I've
already
think
been
rolled
into
these
slides
on
the
various
documents
and
stuff.
So
we
did
have
several
people
working
on
suit
there,
but
there's
a
hackathon
report
in
teap
which
a
cure
is
going
to
cover
in
teeth,
which
kind
of
covers
the
relationship
between
deep
and
suit
and
so
on.
D
F
G
F
Hear
me
right
so
they're,
mostly
editorial
changes
in
this
version.
There's
not
a
lot
of
technical
churn.
Primarily
these
are
coming
from
feedback
from
the
the
well
I
I.
Guess
it
was
the
list
from
feedback
from
the
list.
There
were
some
things
on
naming
Clarity.
F
So
what
we've
gone
for
here
is
to
rename
run
to
invoke,
because
there
was
already
a
run
sequence,
and
the
idea
here
is
that
we
want
to
make
it
clear
what's
happening,
so
that
was
just
a
minor
editorial
naming
convention
there
the
same
thing
in
common
sequence
versus
shared
sequence.
The
idea
was
that
common
and
command
get
a
little
bit
too
close
together.
So
by
separating
that
out,
it
becomes
a
little
bit
clearer
that
we're
saying
comments
or
shared
Suite
sequence
versus
Command
sequence.
F
I've
added
some
clarifying
text
in
a
number
of
places
and
the
those
are
around
run
sequence
when
strict
order
is
false,
which
is
more
applicable
on
large
systems
than
small
systems.
So
this
is
not
a
microcontroller
consideration
in
general,
this
is
more
of
an
A-Class
system
kind
of
consideration.
F
The
entry
for
suit
invoke
there,
it
wasn't
clear
that
it
contained,
could
contain
image
verification,
so
there's
some
text
to
explain
that
that's
possible
and
the
try
each,
which
is
used
for
some
decision
making
purposes,
doesn't
didn't,
have
a
clear
explanation
of
what
its
stop
conditions
were.
So
the
stop
condition
explanation
has
been
added.
There
was
a
minor
technical
change.
F
I
even
actually
asked
for
a
way
to
write
a
small
payload
directly
without
needing
to
have
a
separate
payload
argument,
and
the
idea
behind
this
is:
if
you've
got
something
that
requires
I,
don't
know
32
bytes,
you
don't
necessarily
want
to
have
an
entire
separate
hash
and
everything
to
make
that
work.
You
probably
just
want
to
be
able
to
put
that
small
payload
directly
into
flash
now
that
required.
F
F
So
we
had
an
Ayanna
early
review
and
obviously,
we've
had
a
previous
Ayanna
early
review.
This
one
is
pretty
minimal.
There
was
one
comment,
and
that
was
since
we
have
standards
track
ranges.
F
Do
those
also
require
expert
review,
as
is
the
norm
in
the
cozy
style,
hybrid
approach,
and
for
that
I
will
take
that
to
the
working
group.
How
do
you
think
we
should
handle
this.
F
Okay,
so
I.
If
that's
the
consensus
of
the
working
group,
then
we
need
to
put
some
text
in
there
to
give
Ayanna
that
guidance.
H
Customer
the
problem
is
that
over
the
life
of
this
document,
the
people
who
will
do
standard
strike
the
documents
that
are
based
on
this
will
not
be
limited
to
the
people
who
know
what
they
are
doing
and
I
say
that
as
a
designated
expert
with
several
registers,
so
I
actually
prefer
the
expert
to
be
involved.
Okay
I
mean
the
the
response
of
the
expert
can
be
very
short.
E
Sorry
I
didn't
put
myself
in
the
queue
Roman
denilio
as
the
kind
of
AD
to
share
similar
field
experience
with
Diana
on
other
documents.
They
have
previously
in
collaboratively
identified
some
issues
where
it
was
just
in
the
standards
track
range
and
there
was
no
de
and
it
would
have
been
really
helpful
to
have
remembered
and
had
some
of
that
knowledge.
F
F
That
being
the
case,
should
we
adopt
the
cozy
style?
Hybrid
standards
plus
expert
review
model
sounds
like.
E
B
Well,
will
we
have
to
recommend
you
know
some
individuals
to
to
be
those
experts.
E
Roman
denili
again
kind
of
by
process.
It
would
be
the
isg
that
would
choose
those
designated
experts,
but
I
would
certainly
welcome
recommendations.
Be
great.
F
I
think
someone
just
pointed
at
me
seems
plausible,
okay,.
A
F
And
this
this
is
the
last
one
I
have
for
this
draft.
So
unless
there's
any
more
questions
or
comments,
I
think
we
can
continue.
F
Right
so
this
is
suit,
must
multiple
trust
domains.
This
is
primarily
in
support
of
tip
at
the
moment.
There
are
a
couple
of
other
use
cases
that
are
important,
but
they
haven't
gotten
quite
as
much
exercise
as
the
team.
Specific
ones
have
next
slide,
please.
F
So,
just
in
summary,
what
we've
got
in
here
is
three
key.
Parts
we've
got
or
three
key
needed
features,
rather
key
delegation
being
the
first
one.
We
want
to
support
explicitly
and
then
there's
the
use
case
for
mutually
distrustful
signers.
This
is
where
two
different
parties
own
two
different
pieces
of
the
system
image
and
they
don't
trust
each
other
to
see
to
authorize
their
code
and
we
need
a
way
to
deliver
those
packages,
while
still
expressing
software
dependencies
between
them
next
slide.
Please.
F
So
summary
of
features
we
have,
we
have
cwts
for
key
delegation
that
part
is,
is
defined
currently,
but
I'm
not
sure
how
accurate
it
is
so
cwt
experts,
please
have
a
look
if
you're
a
cwt
expert.
Please
check
that
out
for
me
in
we
have
the
unlink
command,
which
is
a
specific
requirement
of
teep,
as
well
as
the
uninstall
sequence,
and
then
we
have
dependencies
which
are
a
way
of
expressing
these
multiple
signature
scenarios
next
slide.
Please.
F
So
there's
been
a
number
of
updates,
so
we're
no
longer
indexing
dependencies
separately
from
components
the
Indus
index
lists
have
been
merged.
This
is
intended
to
make
the
whole
thing
simpler
to
handle.
It
does
have
some
significant
implications,
so
digest
of
manifests
are
over
the
Manifest
content
itself,
not
the
envelope,
but
this
treats
the
Manifest
Envelope
as
a
component,
which
means
that
doing
an
image
check
will
digest
the
wrong
thing.
F
So
the
current
implementation,
or
the
current
definition
in
the
spec
rather
just
says
that
the
way
that
this
works
is
that
there
is
a
test
done
in
the
image
check
command.
The
feedback
from
the
hackathon
was
that
perhaps
it
would
be
better
to
implement
a
separate
command
for
this
I
see
Ira
in
the
queue.
C
C
F
So
right
as
a
better
solution
to
the
the
approach
that
we've
had
so
far
with
with
joining
the
two
lists
of
components
and
dependencies
is
to
have
a
separate
command
for
verifying
the
the
digest
of
the
Manifest,
and
we
also
needed
a
test
to
determine
whether
or
not
the
the
currently
processing
component
was
a
manifest
or
whether
it
was
a
dependency
or
a
a
an
image
and
the
the
idea
behind
this
is
for
handling
batch
processing.
F
So
this
is
where
you
have
a
you're
using
the
true
variant
of
the
index,
and
this
is
so
that
you
can
go
through
everything
at
once,
giving
it
the
same
commands
the
problem
is
we
used
to
have
a
way
to
say,
handle
all
the
dependencies
handle
all
the
components,
but
now
components
are
depend.
Our
dependencies
are
components
so
now
we
need
a
way
to
split
them
apart
and
so
that's
what
this
this
test
is
for
then.
F
F
If
it's
not
it's
possible
that
we
could
just
not
do
that
and
have
it
just
fail
on
a
parse
error,
I'm
I'm,
not
sure
I,
like
that
I
think
I'd
prefer
it
checks,
but
I
will
be
happy
to
take
feedback
if
anyone
has
a
specific
preference,
the
uninstall
command
sequence
is
the
mechanism
that
tip
is
going
to
use
from
what
I
understand
to
say
that
it
is
time
to
remove
all
of
the
things
that
were
installed
by
this
manifest,
and
so
that
has
been
added
in
here
in
support
of
team
next
slide.
F
D
I
can
comment
on
that
one
Dave
Taylor,
so
not
only
is
it
usable
by
teep,
but
the
other
scenario-
and
this
is
much
less
for
constrained
devices
than
it
is
for
say
devices
that
a
a
human
can.
You
know,
type
things
into,
for
example,
the
other
scenario
is
we're
a
local
administrator
wants
to
physically
on
the
box,
go
on
and
uninstall
something,
and
so
you
can
do
that
if
you've
already
have
the
stuff
that's
in
there
and
just
follow
the
uninstall
command
sequence.
D
F
Okay,
so
for
open
issues,
what
we've
got
other
than
what's
already
been
talked
about,
and
the
security
consideration
section
is
not
particularly
specific
to
this
document.
It's
the
one
that
was
originally
in
the
suit
manifest
draft,
so
that
definitely
needs
to
be
updated.
So
there's
a
bit
of
work
left
to
do
there.
F
The
component
another
issue
raised
in
the
hackathon
was
the
component
ID
for
the
root
manifest.
Now.
This
is
an
interesting
problem,
because
in
a
constrained
system,
this
is
irrelevant.
If
you
receive
a
manifest,
you
know
where
to
put
it,
you
have
one
space
to
put
it
in,
you
put
it
there
in
a
dependency,
enabled
constrained
device.
This
is
still
the
case
there.
F
If
you
receive
an
unsolicited
manifest,
there
is
one
place
for
it
to
go,
however,
once
you're
starting
to
deal
with
devices
that
have
multiple
independent,
manifest
trees
that
Define
individual
applications-
probably
this
is
most
common
when
they
involve
trusted
applications
that
are
signed
by
someone
else.
But
when
we
have
that
scenario,
then
there
needs
to
be
a
defined
place.
F
To
put
it,
and
that's
where
the
question
of
a
component
ID
for
the
root
manifest
comes
in,
because
that
tells
a
device
that's
receiving
it
where
it
goes,
there's
a
slight
challenge
with
that,
which
is
that
if
we
have
that,
there's
going
to
be
an
interaction
between
it
and
the
component,
ID
that's
specified
for
that
for
a
dependency.
So
if
you
have
a
a
root
manifest,
but
it
doesn't
matter
what's
in
it
for
the
current
moment,
but
it
defines
component
IDs
for
its
components.
F
Now,
if
one
of
those
components
is
a
dependency
manifest
which
contains
a
component
ID,
there's
a
contention
between
these
two,
the
the
best
idea
for
the
the
thing
that
I've
come
to
for
the
moment,
which
may
or
may
not
be.
The
right
answer
is
that
anything
defined
in
a
dependency
component
list
should
override
whatever's
in
the
Manifest,
and
that's
just
not
going
to
happen,
and
there
are
other
arguments
we
could
make,
but
I
think
that's
so
far,
I!
That's
the
one
I
found
the
least
arguments
against.
D
F
Okay,
then
I'll,
wait
then
right
so
I
believe
I
put
those
on
a
following
slide.
We'll
come
back
to
it.
Oh
there,
okay,
yes!
So
there
we
are:
where
should
a
dependent,
manifest,
be
stored?
Okay,
and
so
there
there
are
in
single
image
devices.
As
I
said,
this
is
clear:
in
single
system
configuration
devices
still
clear,
but
when
you
have
a
system
with
multiple
independent
independent
manifests,
not
clear.
F
So
if
we
give
dependent
manifests
a
component
ID
that
solves
one
of
our
problems,
but
the
question
is:
do
dependencies
also
get
to
declare
their
own
component?
Id
I?
Think
I
just
ran
through
these
choices.
The
three
the
third
one
was
actually
a
hybrid
of
two
of
the
others,
so
I
left
it
out,
so
the
dependent
component
list
would
this
is
the
what
I'm
saying
I
think
is
probably
the
right
answer.
F
The
dependence
component
list
overrides
any
declared
component
IDs,
and
the
other
option,
of
course,
is
that
the
designated
element
of
the
dependence
component
list
is
concatenated
with
any
dependency
self-declared
component
ID
I'm
a
little
bit
worried
about
some
of
the
security
considerations
around
that
one,
whereas
the
other
seems
clear
to
me.
D
So
to
this
day,
favor,
so
to
make
it
clear
the
thing
that
is
the
in
the
override
case
right,
the
outer
one
gets
to
override
where
the
inner
one
goes
correct.
And
so
the
scenario
is,
you
can
have
one
inner
one
and
it
couldn't
talk
about
some
of
the
things
that
Fran
and
I
talked
about
at
hackathon.
D
The
the
same
dependency
could
actually
need
to
be
installed
in
multiple
places
on
the
same
overall
device,
okay
and
so,
for
example,
if
a
device
has
say
multiple
tees
in
it
right,
then
it
would
be
exactly
the
same
suit
digest
exactly
the
same
dependency
or
whatever,
but
you
may
need
to
install
it
separately
in
two
different
tees,
and
so
where
would
you
say
that
you'd
say
that
in
the
outer
one,
with
different
component
IDs
with
one
prefix
going
to
one
te,
one
prefix
going
to
their
tee
right?
D
D
It
goes
over
in
that
one,
okay,
and
so
the
concatenation
aspect
could
have
done
that,
but
it
means
you
have
less
control
over
the
full
path
right
and
so
the
override
means
you
have
full
control
over
exactly
where
you
want
it,
and
so
it
can
be
installed
multiple
times
in
more
complex
devices.
And
so
that's
why
you
know
I
agree
with
that
as
the
as
the
proposal
and
but
I
just
want
to
explain
why.
F
F
A
Does
anyone.
H
A
Does
anyone
disagree
with
the
conclusion
that
was
just
made
here
between
Brunson
and
Dave,
just
so
that
if
there's
any
disagreement,
it's
it's
aired
now.
A
D
Before
you
go
on
to
the
next
one,
Brandon
did
ask
for
somebody
that
is
a
cwt
expert
to
be
a
reviewer
of
this
one.
So
I
just
asked:
is
there
anybody
who
considers
themselves
to
be
proficient
in
cwts?
It
would
be
willing
to
do
a
review
for
for
that
aspect
of
the
document.
D
Was
multiple
trust
domains
and
everybody
pointed
at
Kirsten
after
Hank
raised
his
hand
first
in
case
you're,
taking
notes.
Thank
you.
F
So
now
we're
into
update
management,
so
it
just
as
a
summary.
There
are
several
extensions
to
suit
in
this
document.
The
first
is:
it
currently
contains
a
coast.
Wood
I
would
prefer
it
to
contain
a
co-rim.
F
It
has
mechanisms
for
version
comparison
for
Loosely
coupled
dependencies,
rather
than
ones
that
are
coupled
by
Digest.
It's
got
some
things
on
deployment
constraints
like
timing,
priority
and
authorization,
and
a
couple
of
commands
to
enable
more
compact
encoding
for
setting
parameters
next
slide.
Please.
F
So
the
primary
changes
since
v0
are
adding
the
override
multiple
command.
The
point
of
this
is
that,
if
you've
got
a
lot
of
components,
this
saves
you
two
bytes
each
then
there's
the
copy
parameters
command,
which,
when
more
than
one
component,
uses
the
same
value
for
a
parameter
cuts
down
on
the
encoding.
F
This
is
primarily
important
for
hashes,
because
if
you
copy
a
hash
in
the
in
the
current
version
of
the
suit
manifest
draft,
if
you
copy
a
component
from
one
place
to
another,
you
have
to
declare
the
hash
for
it
more
than
once,
and
that
is
not
great
for
something
that's
supposed
to
be
encoded
small.
So
this
is
to
resolve
that
problem
and
it
allows
copying
from
one
component
to
another
with
a
relatively
minimal
encoding.
F
Just
waiting
for
it
to
advance
okay,
so
there's
this
is
definitely
not
a
full
list
of
update
management
actions.
If
there's
something
missing
that
you
need
for
a
use
case,
please
let
us
know,
let
me
know
let
someone
know
if
they're
for
sorry
version
comparisons.
F
There
was
an
open
question
from
the
previous
meeting
about
whether
it
should
be
possible
to
use
a
manifest
sequence
number
as
a
version
comparison
in
a
manifest.
My
instinct
is
no
because
we
already
have
a
way
to
check.
However,
I
have
had
the
request
for
that
and
then
that
request
Dave
went
strangely
silent,
so
I'm
not
sure
where
we
go
from
there.
F
Okay,
sorry,
then,
are
there
any
other
open
issues
that
anyone's
aware
of.
F
In
that
case,
I
think
that
is
it
we
we
do
have
I'd
be
interested
if
anyone
has
review
or
is
interested
in
reviewing
the
this
document.
I'd
appreciate
reviews
in
general,
but
also
specifically
on
those
two
introduced
new
commands.
F
D
So,
are
you
able
to
are
you
able
to
say
more
about
what
the
actual
issue
was,
or
should
we
just
take
that
offline.
F
J
Okay,
Kentucky
of
this
document,
the
next
slide,
please
yeah.
We
are
still
improving
our
document,
yeah
and
David
Brown
joined,
of
course,
as
and
we
have
some
dependency
on
other
documents.
We
are
still
discussing
in
quasi
working
group
like
causing
hpk
and
also
called
the
AES
and
ASC
CBC
mode,
and,
as
you
can
notice,
the
title
is
changed.
J
The
software
encryption
with
suit
manifest
into
encrypted
payloads
in
suit
manifest,
and
we
are
still
improving
the
text
in
the
document,
and
we
have
new
example
approach
to
delivery.
The
integrated
firmware
into
to
device
next
slide.
Please
simple:
this
is
old
approach
and
I.
Don't
want
to
explain
it
so
next
slide.
Please
yeah!
This
is
new
idea.
The.
J
The
Manifest
is
signed
by
the
Manifest
Creator,
you
know
so
the
and
now
the
encryption
aim
for
is
inside
the
Manifest,
so
it
is
signed
by
someone
and
it
requires
if
they
also
create
the
Manifest.
J
Nobody
can
not
change
the
Manifest,
so
it
requires
distribution
system
to
create
a
second
manifest
with
a
dependency
resolution
mechanism,
and
so
this
is
another
story,
but
so
I
I
explained
it
later
and.
J
Yeah
in
this
draft,
we
do
not
exemplify
the
dependency
solution,
so
just
simple
one:
the
author
creates
encrypted
firmware
and
its
manifest
and
deliver
it
to
the
device.
So
next
price,
please.
This
is
the
example.
J
That
helps
perfect
yeah
next
right,
please,
okay
at
next
slide,
please,
okay,
hello,
yeah
with
this
case,
as
you
notice,
the
the
oh,
it's
so
so
tiny,
oh
yeah,
so
the
as
I
said
the
encryption
info
is
inside
install
command,
so
this
is
signed
by
author,
so
the
device
can
decrypt
it
with
this
parameter
next
side.
Please,
and
now
we
are
trying
to
export
in
this
example
to
multiple
trust
domains
draft.
J
So
this
is
a
little
bit
complicated
that
they
also
create
a
go
firmware
and
it's
manifest
and
then
deliver
it
to
the
distribution
system.
The
distribution
system
creates
encrypted
firmware
and
it's
manifest
so
there
there
are
two
manifests
and
encrypted
firmware
to
be
sent
to
the
device.
J
J
Maybe
that's
all
right.
We
are
still
tackling
to
create
it
and
also
improve
our
example
manifest
because,
with
this
scenario,
the
the
author
have
to
Trust
on
the
distribution
system,
because
the
they
also
have
to
disclose
the
raw
firmware
to
this
to
the
distribution
system
and
also
the
device
must
trust
the
distribution
system
because
to
process
the
the
Manifest
which
is
created
by
this
distribution
system.
It
requires
to
depend
trust
the
the
Distribution
Systems
public
key.
J
So
it
is,
it
introduces
more
new
security
considerations,
so
maybe
we
we
have
to
improve
these
Solutions
yeah.
That's
all
and
any
comments
and
advices.
D
D
Is
that
teep
uses
this
not
just
for
code,
but
also
for
what
type
calls
personalization
data
so
in
other
words
the
code
itself
isn't
necessarily
secret,
but
the
config
file
or
the
config
data
around
that
may
need
to
be
encrypted,
and
so
this
abstracts
it
because
it's
just
a
payload,
it's
a
file
that
could
be
placed
or
something
that
could
be
stored
in
storage,
whether
it's
code
or
data
doesn't
matter
for.
The
purpose
of
this
is
that
was
why
the
rename,
because
T
needs
it
for
both
code
and
for
data.
A
A
F
At
the
mic,
I
guess,
the
the
only
thing
I'd
note
is
that
we
probably
could
revisit
a
more
distributable
version.
If
that's
something
that's
that's
demanded
from
the
working
group
I'm
not
saying
that
we
would
change
this
draft
I'm,
saying,
there's
the
possibility
that
we
could
look
at
a
compatible
or
the
one
that
doesn't
use
dependencies
but
uses
a
key
distribution
mechanism
instead.
A
We're
going
to
change
the
order
now
because
Dave
just
got
his
five
minute
warning
to
go
next
door,
so
we're
gonna
do
mud
and
then
we're
going
to
do
MTI
while
Dave's
gone.
A
G
H
G
Forgot-
and
there
was
this
comment
about
when
you
have
close
with
that
you
wanted
program
instead,
that
would
be
perfect.
That
would
be
a
blocker
because
it
would
take
way
longer
yes
accommodating,
for
that
is
fine,
but
don't
expect,
as
of
course,
what
is
basically
done.
So
maybe,
if
you
want
this
done
and
if
we
want
this
done,
maybe
not
wait
for
Quorum,
but
you
know.
A
Okay,
wait
a
minute:
how
does
that
affect
the
working
group?
Last
call
this.
F
Was
for
the
update
management
so.
F
F
C
F
To
the
integration
between
suit
and
mud
next
slide,
please
so
the
just
to
give
a
summary
of
what
this
is
for.
Anyone
who
hasn't
looked
at
it
before
the
idea
is
essentially
this
mud
files
are
a
mechanism
that
allows
devices
to
point
to
a
URL
which
contains
a
document
that
tells
Network
infrastructure
what
they
should
and
shouldn't
access
over
their
intranet
and
possibly
over
the
internet.
F
What
this
does
is
provides
a
new
reporting
mechanism
for
those
URLs.
The
argument
here
is
that
it
would
be
nice
if
your
network
infrastructure
knew
what
this
was
and
had
those
files
available
before
it
ever
sees
that
device
and,
if
you're,
receiving
firmware
updates
those
access
requirements
can
change
so
having
those
two
things
coupled
together
again
makes
sense
further
to
that.
Some
of
the
reporting
mechanisms
that
were
defined
for
mud
originally
are
unsecured
and
leaving
an
unsecured
way
of
reporting
security.
F
Information
doesn't
make
a
lot
of
sense
to
me
at
least
there
was
one
mechanism
defined
that
was
secured,
but
that
mechanism
was
done
through
device
certificates
and
while
that
is
a
one
way
to
get
the
job
done,
there
are
other
ways
to
do
it
as
well,
and
particularly
the
interesting
thing
about
this
approach
is
that
it
allows
us
to
link
it
in
with
attestation
as
well.
So
you
can
attest
the
software
that
a
device
is
running
and
using
that
information
about
the
software.
F
F
So
so
this
is
the
the
idea
behind
it.
I
I
can
talk,
probably
off
of
part
of
that
first
slide
from
memory.
So
I'll
do
my
best.
The
the
what
we've
defined
in
this
draft
is
mostly
just
a
mechanism
to
report
either
a
URI
and
a
signer
key
or
a
full
copy
of
the
mud
file,
and
that's
it
this.
That
is
the
draft.
In
summary,
there
is
precious
little
else,
that's
there.
So
it's
got
similar
benefits
to
certificate
bindings,
but
it
doesn't
mean
you
need
device
specific
certificates.
F
It
does
require
device
fingerprinting
or
attestation
in
your
network.
So
it's
just
different
ways
to
solve
the
same
problem
I
with
different
trade-offs.
Next
slide,
please
last
slide
and
also
last
slide.
There's
been
very
little
activity
on
this
I
don't
know
if
just
no
one
is
interested
in
it,
in
which
case,
maybe
we
don't
need
it.
F
There
is
an
open
issue
about
how
we
handle
updating
mud
files.
Specifically,
if
you
deliver
the
full
text
of
a
mud
file,
does
that
imply
it
never
changes
or
is
there
a
way
to
override
it?
So
that's.
That's
essentially
the
one
open
issue
around
this
foreign.
I
Richardson
I
I
did
read
the
document,
some
ihfs
to
go,
so
you
just
I
was
going
to
say
something
positive
and
then
you
just
said
well,
you
just
said
we're
delivering
the
full
text
of
the
mud
file.
I
didn't
don't
remember
that
ever
being
the
case,
I
thought
it
was
only
the
URL.
There
was
an
option
to
do
it
that
way.
Well,
I
think
that's
probably
a
silly
thing.
Okay,
so
that
probably
solves
your
problem.
I
Don't
do
that,
but
so
there's
a
document
in
opto
AWG
which
which
I
think
will
finally
get
to.
Where
can
we
last
call
this
morning
on
once
you
have
one
securely?
How
do
you
update
and
what
are
our
reasonable
update
path
and
you
can
do
it
relatively
securely,
so
I
think
that
actually
solves
most
of
the
problem,
but
I
think
that
you
can
deliver
a
unique
URL
per
firmware.
I
I
think
that's
the
right
way
to
do
it,
even
if
the
I
would
say
it's
the
right
way
to
do
it,
even
if
there's
no
functional
changes
in
the
firmware.
Okay,
just
you
just
say
this
is
the
new
version,
and
this
also
lets
you
do
because,
as
you
may
know,
you
can
also
now
Point
there's
multiple
ways
of
doing
this.
Now
you
can
point
to
an
s-bomb
from
the
mud
file,
and
so,
while
that
might
not
be
like,
we
could
do
that
through
suit
as
well.
I
G
Hi
this
is
Hank
I
was
just
I.
Was
writing
modifieds
for
rats
back
in
the
day,
so
mighty
rats
there
will
be
Paul
postponed
them
because
the
implementations
were
not
there
a
year
ago,
were
there
now
so
that
we're
returning
to
that.
So
you
are
not
explicitly
fire
defining
a
mod
file
here,
no
yeah!
So
isn't
there
a
need
for
that?
Why
is
that?
A
no
just
as
a
nutshell,.
F
Not
what
this
is
for
this
is
for
giving.
A
C
B
Was
just
gonna
say
on
the
last
Point?
If,
if
the
timing
is
right,
we
could
submit
them
as
a
bundle.
I
F
Okay,
so
the
point
of
this
draft
is
to
ensure
on
interoperability
with
a
minimal
crypto
Suite
now
I
want
to
prefix.
This
I
think
I'm
going
to
say
this
again
multiple
times,
but
the
important
thing
here
is
that
this
is
specifically
for
constrained.
Node
firmware,
update,
I'm,
not
saying
anything
about
mandatory
to
implement
algorithms
for
tape.
I'm
sure
Dave
has
ephemerally
heard
me
somewhere.
F
So
that's
that's
an
important
consideration
in
this
discussion
that
this
is
specifically
for
constrained.
Node
update
that
we're
talking
about
these
crypto
Suites.
So
it's
an
asymmetric
problem.
Unlike
many
of
the
interop
algorithm
discussions
we
have
mandatory
to
implement
means
something
different
for
the
author
than
it
does
for
the
constraint
node.
The
important
thing
here
is
that
your
manifest
author
should
be
able
to
make
a
manifest
for
any
device.
F
Sorry,
the
Manifest
author
should
be
able
to
make
a
manifest
for
any
device,
an
intermediary
that
processes
a
manifest
should
be
able
to
process
a
manifest
for
any
device,
but
a
device
does
not
need
to
be
able
to
process
any
manifest.
It
only
needs
to
be
able
to
process
the
Manifest,
that's
aimed
at
it
and
if
the
Manifest
author
can't
work
out
which
crypto
algorithm
to
use
for
that,
there
are
bigger
problems,
problems
that
we
can
solve
with
suit
report.
F
So
the
that's
the
the
fundamental
consideration
here
in
that
this
is
an
asymmetric
MTI.
It
means
something
different
for
the
author
than
it
does
for
the
recipient
and
if
we
don't
have
appropriate
choices
for
constrained
nodes,
they're
just
going
to
ignore
this
document,
that's
one
reason
that
it's
been
separated
out
of
the
suit
manifest.
The
other
reason
is
that
it's
likely
to
change
over
time
and
be
obsolete
a
bunch
of
times
next
slide
please.
F
So
the
current
status
is
we're
defining
four
MTI
algorithms
they're
all
mandatory
to
implement
for
manifest
authors
and
intermediaries,
but
manifest
processors
are
simply
required
to
implement
at
least
one
it's
scoped,
specifically,
as
I
said
to
iot
Firmware
deployment,
use
cases
and
constrained
nodes
at
that.
One
of
the
questions
I
have
for
the
working
group
is
whether
we
should
require
all
authors
and
intermediaries
to
implement
the
symmetric,
algorithm.
Suite,
that's
defined
I'm,
not
sure.
F
A
F
F
C
F
I'm
misunderstanding
something
here:
okay,
ask
your
question:.
A
F
A
Then
there'll
be
another
document
that
comes
and
replaces
it
or
it
just
you
pick
something
else
from
the
Cozy
libraries,
the
algorithm
registry
and
as
long
as
the
code
points
are
there,
it
just
works,
but.
D
A
See?
Okay,
so
where
we've
had
to
define
a
new
mode,
you're
still
gonna
expect
the
new
say:
block
Cipher
with
the
same
mode
as
a
future
yeah,
that's
the
idea.
Okay,
I!
Don't
have
a
problem
with
that.
F
I
Welcome
back
so
you've
defined
four
profiles.
Yes,.
I
One
of
them
is,
has
HSS
LSM,
yes
right,
which
I'm
very
enthusiastic
up,
Russ
and
I
had
a
back
and
forth
about.
C
I
If
I
could
have
you
know
simple
syllables,
instead
of
lots
of
letters
to
say,
I'll,
remember
it
Lucy
in
the
Sky
with
Diamonds,
whatever
something
like
that
right,
so
Russ
and
I
said
so,
who
actually
implements
hsms
with
LS
HSS.
F
I
You
told
me
to
open
source.
Okay,
you
told
me
to
one
of
them
is
defunct.
I
had
a
long
conversation
with
Randy
and
and
Rob.
Okay,
it's
really
defunct.
You.
I
Okay,
well,
okay,
so
let
me
tell
you
what
I
I
know:
okay,
all
right!
The
cryptek
one
is
at
this
point
sadly
defunct:
yep.
Okay,
the
hardware
is
unobtainable
the
the
revision
to
it
got
killed
by
pandemic
and
now
Russian
sanctions,
yep.
Okay,
because
the
guy
who
did
the
work
is
there
so
and
they're
not
likely
to
ever
get
new
hardware
out
is
what
I
got
if
their
spares
you
could
use
it
there.
Another
company
was
one
in
Ottawa
correct,
who
surprisingly,
has
an
office
Three
Doors
Down
from
mine.
I
I
But
actually
I
suspect
no
one's
been
to
that
office.
Ever
that
was
a
a
tax
office,
registration
for
r
d
credits,
so
I
don't
know
any
of
the
people
involved
right.
Maybe
you
do
so.
You
know
that's
interesting.
Okay,
they
exist
and
you
say:
there's
a
third
one:
a
Cisco
implementation
I
think
that
that
I
think
that
just
the
community
needs
Assurance,
a
feeling
of
of
safety
that
there's
stuff
that
we
can
go
and
get
that
are
going
to
be
useful.
I
C
I
Happy
to
to
rev
it
in
whatever
that
period
is
18
months,
two
years
six
years,
whatever
okay
yeah.
Of
course,
we
should
do
that
right
and,
and
if
and
if
we
obsolete
one
of
our
profiles,
that's
okay
too,
because
we,
the
purpose,
was
to
get
an
upgrade
path.
That
was
the
whole
point
was
to
get
the
upgrade
path
and
I'm
very
very
concerned
that
people
are
not
going
to
implement
the
the
PQ
safely
one
if
they
feel
at
all
anxious
about.
You
know
what
they're
gonna
do
they're,
just
like.
F
So
these
are
the
algorithms
that
are
defined.
We've
got
one
symmetric,
one
post
Quantum
asymmetric,
that's
only
kind
of
post
Quantum,
it's
post,
Quantum
hybrid,
because
there
are
no
standardized
key
exchange
algorithms.
Yet
the
classical
asymmetric
we've
got
es-256
and
eddsa,
both
of
them
with
hpke,
because
that
seems
to
be
where
things
are
headed.
I
think
they're
currently
listing
aesgcm,
but
it
sounds
like
AES,
CTR
or
AES.
Cbc
should
be
coming
so.
F
Okay,
so
there
you
are
so
those
are
what
we
have
on
the
plate
at
the
moment.
Next
slide,
please.
F
There
were
two
that
were
obviously
missing:
those
there
might
be
a
need
for
a
specialized
version
of
eddsa.
There
I,
don't
think,
there's
a
Code
point
for
ed25519
and
cozy,
but
that's
kind
of
an
important
consideration
because
on
a
constrained
node
you
can
handle
it
differently.
D
Day
Fair
can
we
go
back?
One
slide.
I
have
a
question,
not
a
request,
but
it's
a
question.
Yeah
all
of
the
MTI
ones
actually
require
encryption.
D
D
F
F
Better,
so
here's
you
know
there
are
a
couple
obvious
things
that
get
used
a
lot
in
iot
that
are
missing
from
that.
Maybe
they
shouldn't
be
I
I've
seen
at
least
one
argument
that,
if
we're
going
to
have
eddsa,
we
might
as
well
put
Chacha
poly
with
it
and
that's
an
option.
Those
that
set
seems
to
get
used
together
quite
a
lot,
which
is
the
argument
for
that.
F
So
maybe
that
would
be
a
good
change.
I,
don't
know!
Oh
I've
got
a
thumbs
up
from
at
least
one
person,
okay,
so
that
that
might
be
one
change
to
make
and
that's
it
if
you
have
any
feedback,
please
let
me
know
I'd
be
welcome
co-authors
as
well.
If
someone
wants
to
do
some
of
this
write
security
considerations,
Maybe.
D
So
should
we
do
a
Poll
for
adoption?
How
do
you
want
to
do
that
because.
A
I
think
he
needs
to
do
and
an
update
to
address
that
point
you
made
before
we
adopted
it's
adopted
before
we
last
call
it.
D
F
D
I
think
you're
right,
I
think
that's
right.
It
is,
and
so
I
think
we
have
the
action
item
to
call
adoption
so
I'm
asking.
Can
we
do
that
right
now
and
say?
Can
this
it's
not
done
right?
Can
we
at
least
rename
it
from
individual
to
working
the.
D
Current
form,
I've
heard
several
people
saying
just
just
adopt-
is
the
next
step
right,
just
making
sure
okay,
so
technically,
it's
within
our
race
to
just
adopt
it
without
asking
the
list,
but
we
like
to
ask
the
list
so
or
ask
the
people,
so
the
assumption
is,
it
will
be
adopted
and
the
next
version
of
it
will
actually
be
a
draft
ietf
suit.
F
Okay,
I
think
this
is
the
one
Dave
wanted
to
be
back
for
so
this
is
a
suit
report.
Next
slide,
please
so
a
summary
of
what
it
is.
The
idea
behind
this
is
that
you
want
to
know
what
your
device
did
when
you
attempted
to
install
something
or
try
to
secure
boot.
So
what
it
contains
is
a
reference
to
the
root
manifest
so
that
you
know
exactly
what
it
was
working
on.
Then
you've
got
a
record
of
each
decision.
It
takes.
F
There
are
relatively
few
decisions
in
a
suit
manifest,
so
this
is
a
small
list.
There
is
also
a
record
of
any
critical
information.
That's
identified
in
that
process.
This
is
done
through
the
the
reporting
mode
hint
that
goes
with
each
suit
command.
That
feeds
into
the
construction
of
the
suit
report,
but
it
is
a
hint
suit
manifest
processors
are
welcome
to
override
that
behavior,
however,
they
see
fit.
The
result
of
this
is
this,
so
what
it
gives
you
is
the
result
of
an
a
procedure.
F
There
are
were
two
procedures,
but
since
the
changes
to
the
suit
multiple
trust
domains,
there
is
now
a
third
procedure
which
is
uninstall
invoke
in
case.
It's
not
clear,
is
equivalent
to
either
secure
boot
or
running
the
code.
That's
in
your
tee
next
slide,
please.
F
So
this
has
a
relationship
to
rats
and
we
didn't
quite
have
time
to
talk
about
it
at
rats.
But
the
idea
here
is
that
a
verifier
in
rats
could
take
all
of
this
information
and
construct
your
device
State
out
of
it,
and
by
using
that
they're
able
to
discern
information,
they
might
need
to
determine
the
the
trustworthiness
of
the
device.
F
They
can
also
extract
the
system
property
claims
and
by
extracting
the
system
property
claims,
they
can
construct
the
information
that
would
normally
have
gone
into
an
attestation
report,
so
this
can
be
used
in
appraisal
and
the
the
one
important
consideration
here
is
that
this
is
not
the
kind
of
information
that
a
relying
party
wants
to
get.
So
there
is
an
onus
that
gets
placed
on
the
verifier
to
translate
this
information
into
more
conventional
eat
values.
F
F
So
there
were
a
couple
of
changes.
I
noted
in
the
original
version
of
this
draft
that
it's
very
convenient
on
a
constrained
device
to
do
reporting
through
a
single
append-only
log,
and
if
you
have
multiple
places
that
you
have
to
put
data
mistakes,
get
made.
Serialization
is
hard.
What
this
does
is
it
allows
you
to
just
keep
a
pending
and
serializing
to
a
log
all
in
one
go,
so
you
don't
have
to
do
a
post-processing
step
before
you
can
cons
before
you
can
send
or
store
your
report.
F
What
I
have
done
in
this
one
is
merged
the
system,
property
claims
and
the
suit
manifest
records
to
try
and
join
that
together
to
go
from
two
logs
down
to
one
and
the
mechanism
for
this,
which
is
not
entirely
clear
here,
but
the
idea
behind
it
is
that
one
of
these
elements
is
a
list
or
an
array
element
and
the
other
is
a
map
element
and
by
doing
this,
a
verifier
that
wants
to
extract
only
system.
F
Property
claims
just
takes
all
of
the
maps
out
of
that
list,
and
it
has
the
system
property
claims
without
having
to
worry
about
parsing
anything
else.
Next
slide,
please
I've
added
suit
capability
reports.
We
talked
about
capability
reports
a
number
of
times
in
this
working
group,
and
we
never
quite
got
to
doing
it.
But
I
thought
that
a
report
draft
might
be
the
place
to
put
a
report.
F
So
I've
added
a
suit
capability
reports
in
here,
and
it
essentially
breaks
it
down
to
the
things
that
a
an
author
needs
to
know
about
a
suit,
manifest
processor
and
it's
just
a
list
of
lists
of
integers.
It's
fairly
simple
in
that
respect.
So,
oh
and
component
identifiers,
which
are
not
integers,
so
so
that's
that's
the
overall
structure
on
the
rough
idea
of
what's
in
there
between
these
things,
you
know
what
a
suit
manifest
processor
can
do,
modulo
any
ACLS
that
are
applied
by
it,
which
you
won't
know
from
this
next
slide.
F
Please
your
last
one!
Oh
that's
my
last
one!
Okay!
Well,
then,
that's
it
so
that
if
there's
any
feedback
on
that
I'd
appreciate
it.
If
you
want
to
do
a
review,
I'd
appreciate
it
go
ahead,
any
questions.
I
D
You
want
me
to
go.
First,
yeah
go
first,
okay,
so
two
what
one
question
one
comment:
I'll
give
the
comment:
one
first,
that
I
think
some
place.
We
need
to
write
down
how
you
might
carry
a
suit
report
in
an
eat.
D
That
that
would
be
my
preference
as
well
and
Russ
is
also
nodding
as
part
of
where
that,
wherever
that
gets
written
down,
whether
it's
in
this
document,
which
would
probably
be
my
preference,
but
it
doesn't
have
to
be-
should
also
consider
answering
the
question
of
okay-
assume
that
your
suit
report
has
sensitive
information.
D
Do
you
encrypt
the
suit
report,
or
do
you
put
it
in
and
eat
and
encrypt
to
eat?
I
suspect,
it's
easier
to
say
the
latter,
because
the
eat
may
contain
other
sensitive
information
from
that
device.
Besides,
the
suit
report,
in
which
case
not
having
a
mechanism
to
say
encrypt
the
suit
report
for
use
and
eat,
is
probably
not
necessary,
but
that's
what
the
security
consideration
should
actually
discuss
that
so
I.
G
D
D
D
On
the
eat,
one,
if
you
imagine
that
there
are
five
different
claims
of
which
you
preferred
as
one
and
all
of
them
have
sensitive
information,
do
you
encrypt
five
things
separately
and
then
put
them
in
an
eat,
or
do
you
put
them
all
in
and
eat
to
encrypt?
This
whole
thing
that
I'm
saying
that's
the
discussion
that
should
be
put
into
the
security
considerations
right.
D
And
possibly
yes!
Okay!
So
if
you
didn't
hear
that
remotely
Russ
said
that's
a
discussion,
I
should
go
in
the
eat
document.
I
Or
yeah
so
Michael
Richardson
here
so
I'm
really
happy
to
let
you
go
first,
because
because
now
I
can
ask
my
my
question
in
a
much
more
interesting
way.
So
up
to
this
point,
we
are
the
whole
status.
Tracker
has
been
sort
of
out
of
scope
for
the
working
group.
I
So
my
question
is:
how
do
we
get
suit
reports
back
in
the
first
place,
given
that
we
haven't
even
told
people
how
to
get
you
know,
manifests
and
stuff
to
the
device?
That's
of
all
a
device
specific
thing.
So
how
do
we
get
any
of
this
back
and
it
actually
answers
part
of
the
question
and
that's
the
same
way
the
same
magic
way?
But
but
you
see
at
that
point,
if
you
say
it's
the
same
magic
way,
then
the
the
privacy
considerations
for
that
thing
are
also
the
same
magic
way.
I
I
C
I
Think
that
that
well
there's
some
places
some
verticals
like
teep,
where
they
have
the
problem
solved
I
think
there's
a
whole
bunch
of
other
places
where
people
are
just
okay
and
they're,
going
to
wind
up
in
some
very
proprietary
vertical.
At
that
point,.
F
So
but
I'll
sorry
I'm
just
joking
the
what
we've
realized
that
this
is
that
there
really
isn't
anything
in
tape
that
restricts
it
to
Tes,
there's
nothing
in
the
T
protocol
draft
that
would
prevent
you
from
using
it
outside
of
a
te
and
when
you
squint
at
it
just
hard
enough.
It
looks
an
awful
lot
like
that
status.
Tracker,
so
I.
I
Think
that's
really
cool
and
I
think
that,
for
a
bunch
of
things
that
are
of
the
you
know,
Raspberry
Pi
and
larger
devices
I
think
that's
probably
the
right
answer,
and
then
the
question
is
whether
that's
usable
below
that,
and
that
may
be
the
case
that
it
is
right
and
the
reason
I
I
think
that
tees
don't
have.
That
problem
is
that
they
also
have
a
typically
a
rich
execution
environment
that
can
do
all
of
the
heavy
networking
stuff.
I
F
D
Okay,
if
it's
a
follow-up,
let
karaoke
first
okay,.
K
Well,
just
to
Russ's
Point,
about
where
encryption
discussion
should
go,
I
think
it
should
go
on
and
eat
profile
which.
A
D
Okay,
so
Dave
Taylor.
Now
my
other
question
on
the
slide
here
it
says:
they're
broken
down
into
supported
component
identifiers
and-
and
you
pointed
out
that
you
know
they're,
not
integers
and
stuff.
So
what
does
supported
component
identifiers
mean
for
a
non-constrained
device?
Is
my
question
so.
D
A
No,
we
didn't,
we
need
to
talk
around
okay.
D
I,
don't
remember
what
the
charter
question
was:
oh
yeah,
yeah,
you're
right
on
so
Brendan's
answer
here
about
an
hour.
I
was
referring
to
like
the
tape
meeting
and
I
will
observe
that
earlier
in
the
suit
working
group
right,
we
had
a
discussion
of.
Can
you
use
suit,
for
so
I
can
use
a
suit
manifest
for
things
that
are
not
iot
devices?
D
Okay,
because
you
know
software
update
for
internet
of
things,
and
we
said
yes
for
a
chartered
to
make
sure
that
it
works
for
iot,
but
we
actually
put
language
in
this
manifest.
That
said,
it
is
not
restricted
for
that
purpose.
Okay,
you
can
imagine
a
similar
discussion.
Go
that
might
happen
in
deep,
fair
enough.
A
J
I
K
D
D
Door,
my
part
of
it
did
since
I'm
just
advertising
a
side
meeting,
so
apologize.
K
A
G
Definitions
document
I'm
pretty
sure
that
actually
means
busaker,
and
so
they
want
to
manage
that
for
validation,
procedures,
of
course,
and
and
the
I
will
propagate
the
TA
profile
for
Quorum
Edo
platform,
because
I
have
a
relationships
that.
H
They
have,
they
have
a
common
size,
yeah.