►
From YouTube: IETF111-SUIT-20210730-1900
Description
SUIT meeting session at IETF111
2021/07/30 1900
https://datatracker.ietf.org/meeting/111/proceedings/
B
Add
some
notes:
okay,
so
yeah
when
you're
not
presenting
okay
yeah,
so
that
would
be
great
and
if
anybody
else
can
help
christian
well,
hannes
is
presenting
during
the
firmware
encryption
part.
That
would
be
great,
but
all
right
do
I
have
my
coaches.
I
saw
dave
waltermeier
on
briefly
a
minute
ago,
he's
having
connection
problems.
B
Sorry,
I
don't
know
how
to
use
the
advanced
to
next
slide
when
it's
all
in
pdf
here
and
here-
and
I
don't
want
to
spend
time
to
figure
it
out.
So
I'm
just
going
to
scroll
here.
This
meeting
is
covered
by
the
note
weld,
presumably
at
this
point
in
the
week
you've
seen
this
many
times.
B
If
you
haven't,
please
read
through
this:
it's
in
the
slides
link
to
this
session
that
you
can
find
in
the
meeting
materials
tab
on
the
top
right
is
the
folder
icon
to
get
the
meeting
materials
and
you
can
find
all
the
slide
decks
from
today
under
the
folder
icon
on
your
screen
all
right.
We
just
talked
about
note
takers.
We
have
christian
and
hannes
as
our
note
takers
and
we
do
not
need
a
jabber
room
watcher
based
on
the
latest
discussion,
unless
somebody
tells
me
otherwise,
I'm
going
to
skip
that.
B
This
is
our
agenda
for
today
split
into
two
slides,
so
logistics
from
the
chairs,
we'll
talk
about
hackathon
things
suit,
manifest
format
the
firmware
encryption.
B
B
Let
me
know
if
that's
incorrect,
but
that's
what
I
understood
from
the
email
threads
that
we
had,
and
we
do
want
time
to
talk
about
the
reach
harder
discussion
which
I
think
are
currently
in
the
chair,
slides,
and
so
we
could
put
that
under
logistics.
B
Although
I'm
thinking
we
might
want
to
do
that
at
the
end
after
we've
had
discussion
about
these
drafts,
but
I
can
go
either
way
and
since
I
don't
see
any
of
my
co-chairs
here,
I'm
thinking
that
I
would
rather
wait
till
the
end,
because
that's
when
the
co-chairs
will
be
here,
I
do
see
roman
is
here
that's
great.
As
long
as
roman
you
can
be
here
for
the
full
session,
then
I'm
going
to
move
the
charter
discussion
stuff
to
the
end
at
0.7.
C
In
the
hopes
that
worries,
what's
that,
I
will
be
here
for
the
full
session,
so
no
worries
if
we
want
up
or
do
whatever
we
want.
B
Okay,
great,
then,
I
will
hold
that
until
the
end,
in
the
hopes
that
russ
and
or
dave
can
be
here
along
with
me
for
the
recharter
text
discussion.
So
all
right,
so
our
current
milestones,
we
have
one
remaining
milestone
on
the
current
charter.
B
Hence
our
discussion
about
what
should
be
in
the
updated
charter,
which
was
originally
march
2020
when
covet
happened,
and
so
we're
still
trying
to
finish
up
the
manifest
format,
and
so
we
believe
we're
really
close,
and
so
that's
the
main
item
for
today,
if
we
can
get
through
the
manifest
discussion
get
through
the
fact
that
we
believe
that
it
is
ready
for
the
next
step.
That
would
be
great,
and
so
that's
everything
else
is-
is
a
secondary
to
that
particular
work
item
today.
B
At
this
point,
these
are
the
slides
for
later
on,
and
so
I'm
going
to
stop
here
from
the
chair,
slides
and
we're
going
to
move
directly
to
the
hackathon,
slides,
and
so
let's
see
who's
presenting
the
hackathon
is
that
hannes
yeah
do.
D
D
Yeah,
let.
B
B
Let
me
try
okay,
just
because
I
I'm
in
the
scrolling
mode
and
if
you
can
get
into
the
like
next
slide
mode,
then
yeah.
What
are
you
drawing.
B
To
do
that,
and
I
do
see
russ
just
joined
us
russ.
I
was
just
saying,
since
neither
you
nor
dave
walter
meyer
were
here
right
when
I
was
saying
this
we're
going
to
do
the
charter
discussion
at
the
end,
because
I
did
see
dave,
waltermeier
pop
in
and
then
disappear,
and
so
I
stopped
advancing
the
chair
slides
when
we
got
to
the
charter
stuff
saying:
let's
do
that
after
the
other
presentations
is
that,
okay,
with
your
ass.
E
A
B
Honesty's
hackathon
report
and
then
when
we
get
past
the
firmware
encryption,
then
we'll
come
back
to
the
charter.
Discussion.
Okay
and
we'll
remember
as
disc
firmware.
Encryption
goes
too
long
we're
going
to
call
time,
because
we
do
want
a
couple
minutes
at
the
end
to
talk
about
the
recharge
discussion.
So.
D
Yeah
is:
can
you
see
my
slides.
D
A
B
B
E
Also
were,
can
you
full
screen,
it.
D
I
thought
I
did.
Oh
man.
F
D
You
may
have
seen
that
I
sent
around
an
email
before
the
ids
meeting
to
talk
about
having
a
hackathon
and
then
kind
of
a
bigger
project
picture
in
some
sense,
not
just
focusing
purely
on
the
work
of
the
group,
but
instead
also
looking
at.
How
does
the
firmware
get
there
and,
like
the
whole,
the
whole
chain?
Essentially,
and
so
we
based
on
the
participants
who
who
said
that
they
want
to
join,
which
I
was
surprised
given
like
the
online
experience
of
a
hackathon,
is
kind
of
clumsy.
D
So
we
had
one
group
working
on
on
the
actual
transport
and
they
used
lightweight
m2m
and
in
with
their
focus,
they
wanted
to
do
some
oscore,
because
that
was
not
available
at
that
time.
In
the
deep
group
there
was
a
presentation
already,
which
is
I'm
going
to
skip
now
and
then
there's
that
the
the
work
on
the
manifest
itself
and
then
to
actually
use
that
new
software
as
part
of
the
secure
boot
mechanism.
D
So
a
couple
of
things
got
done.
I
skipped
the
first
few
and
focus
on
the
last
one
which
are
relevant
to
this
group,
and
there
are
a
couple
of
pointers
to
repositories,
ongoing
work,
of
course,
and
big
thanks
to
david
brown,
who
helped
me
to
with
the
integration
of
suit
into
the
mcu
boot,
which
you
know
like
when
you
initially
create
the
plan
to
do
something,
it
always
looks
easier
than
it
actually
is.
D
So
it
was
amazing
to
see
that
there
is
actually
a
separate
simulator
in
mcu
boot
to
simulate
updates
and
particularly
failures
to
updates
like
what
happens
if
the
update
gets
interrupted,
if
the
mistakes
with
flash
writing
and
flash
access,
and
so
on
so
really
cool
stuff
in
terms
of
testing,
maybe
something
to
look
at
for
other
people
in
other
projects.
D
D
On
explaining
a
little
bit
on
on
the
details
of
one
specific
aspect,
which
I
thought
could
be
interested
interesting
to
the
group
as
a
sort
of
a
background
in
mcu
boot,
open
source
bootloader,
which
many
of
you
know
and
which
is
used
in
other
embedded
operating
systems,
there
are
different
slots
and
each
slot
has.
These
has
a
firmware
image
in
there
or
potentially
has
a
firmware
image
in
there.
But
there's
also
some
some
additional
data
there,
particularly
header,
which
describes
somewhat,
follows
afterwards.
So
you
can
actually
see
like
lens
information.
D
Oh
man
really
yeah,
maybe
maybe
you
guys-
maybe
you
guys,
can
present
because
because
that'll
look
it's
a
little
bit
painful.
D
More
so
now
now
I'm
slide
four
yep:
okay,
okay,
okay,
so
that's
good
as
I'm.
I
would
like
to
show
slide
four
and
ignore
the
details
of
how
this
looks
like,
but
the
general
idea,
I
think,
is
important.
So
then
there's
a
firmware
image
and
the
firmware
image
is
today
is
followed
by
a
couple
of
dlvs
and
that's
the
way
how
these
descriptives,
descriptive,
firmware
images
or
firmware
updates.
D
D
What
the
encryption
keys
are
to
actually
then
subsequently
decrypt
it
etc,
etc,
and
the
features-
and
you
see
that
in
that
box
here
with
the
dlvs
each
new
dlv
adds
a
feature
like
different
encryption,
different
algorithms
and
so
on,
and
that's
sort
of
like
the
the
whole
flow
of
processing
sort
of
follows
by
going
through
the
dlvs
and
then
looking
like
what
feature
it
was
implemented
and
then
actually
executing
that
and,
as
you
can
imagine,
as
we
are
sort
of
incorporating
the
suit
function,
that
changes
quite
a
bit
because
we
have
this
behavioral
manifest.
D
And
so
what
we
then
discussed
and
decided
to
do
is
we
we
still
use
the
same
header
format.
Add
a
new
matching
number
repurpose,
one
other
field
to
know
the
size
of
the
manifest
and
then
just
attach
the
manifest
at
the
end
of
the
firmware
image
on
in
this,
in
the
specific
slot
and
and
still
stick
with
the
trailer,
because
that's
obviously
needed
and
then
used
a
bunch
of
different
software
libraries
to
accomplish
this
task,
and
some
of
it
is
not
yet
published.
D
I
need
to
find
a
good
home
for
it,
but
other
things
are
available,
as
the
links
previously
indicated,
I'm
also
going
to
brenton
released
his
his
father,
which
is
quite
minimalistic,
so
I'm
trying
to
compare
the
size
of
those
and
and
to
come
up
with
some
performance
numbers
as
well.
Just
for
your
your
interest
and
depending
on
which
features
you
like
this
one.
The
current
code
that
I've
been
working
on
was
using
the
embed,
dls
and
and
sort
of
some
of
those
features
and
lawrence's
queue,
cbo
and
ecosd
library.
D
So
that's
about
the
the
bootloader
and
I
will
post
a
link
to
the
list
when
the
when
the
boot
is
once
I
figure
out
where
to
put
the
code,
we
had
a
few
challenges
as
well,
but
overall,
I
think
the
the
key
message
I
want
to
get
away
with
is
like,
although,
like
this
virtual
environment,
is
pretty
much
discouraging
for
hackathon
participation,
I
thought
it
was
still
a
great
experience
because
there's
always
some
people
around
that
you
can
ask,
and-
and
I
have
talked
to
you
obviously
to
the
other
team
members,
but
also
to
to
others
who
hang
around
in
the
hackathon
and
there's
always
something
that
you
get
away
with
something
you
haven't
known
before
so
so.
D
For
me,
this
was
a
a
plus,
despite
all
the
minuses,
with
time
zone,
differences
etc
and
a
big
thanks
to
the
people
who
who
participated
and
helped
out.
Okay,
that's
all
I
wanted
to
to
say
about
the
hackathon
and
just
drop
me
an
email.
If
you
are
interested
in
specific
details.
B
If
not,
then
we
will
move
on
to
the
suit
manifest
and
I
have
those
slides
or
brendan.
You
can
share
if
you
prefer,
but
otherwise
I'm
ready
to
project
whichever
you
like.
H
Let's
give
it
a
go
and
and
see
what
the
experience
is
like
and
we
can
always
revert
if
it's
not
it's
not
working
for
us.
H
All
right,
so
here's
roughly
the
topics
I
want
to
cover
today,
so
there's
a
few
minor
issues
that
we
probably
need
to
discuss,
and
then
there
is
the
major
issue
of
document
structure
which
I
will
of
course
come
back
to.
But
I
thought
we
should
clear
out
the
minor
ones
first,
since
I
think
they
should
be
reasonably
easy
to
get
through.
H
H
There
we
are
yes,
so
it
uri
fragment
only
references
are
already
referenced
in
the
document,
so
I
think
it
is
just
an
oversight
that
we
aren't
saying
that
the
uri
is
a
uri
reference.
So,
in
my
opinion,
what
we
should
do
is
we
should
switch
to.
We
should
make
the
the
formal
definition
of
what's
actually
in
the
uri
parameter
a
uri
reference.
I
don't
think
this
is
a
big
change.
It
does
produce
one
interesting
question,
which
is:
if
you
have
a
relative
uri
placed
there.
H
Then,
if
both
of
those
conditions
are
met,
then
the
relative
uri
should
be
relative
to
the
reference
uri.
Otherwise
I
think
it
should
be
undefined
beyond
that.
I'm
I'm
not
sure.
So
if
anyone
has
any
strong
opinions,
please
let
me
know.
H
I
think
implementation
defined
is
probably
the
right
answer
here,
because
I
can
imagine
there
being
situations
where
that
kind
of
thing
is
well
known
in
a
particular
deployment.
The
the
idea
of
having
a
local
cache
server,
for
example,
comes
to
mind
and
if
devices
happen
to
know
about
their
local
cache
server,
then
that's
probably
fine,
but
there's
no
way
to
specify
that
without
having
a
you
know,
devices
know
the
mdns
name
of
the
local
cache
server
and
the
local
cache
server,
conforming
to
that
mdns
name
for
example.
H
So
I
I
think
it's
better
to
have
devices
know
what
to
do
themselves
and,
and
then
it
just
becomes
implementation
defined.
If
there's
no
reference,
uri
present.
I
Hi,
thank
you
yeah.
I
I
think
it's
really.
I
I.
I
think
it's
really
important
that
that
relative
references
work,
because
I
think
that's
that
the
the
I
think
that's
the
best
way
to
refer
to
other
dependencies
and
make
sure
that
they
can
get
there,
regardless
of
how
how
the
initial
parts
are
delivered
via
you
know,
and
I'm
thinking
specifically
about
air
gaps
and
usb
keys
and.
I
Servers-
and
so
I
really
think
it
I
I
think
it
needs
to-
I-
I
don't
like
the
what
I
heard
you
saying
implementation
specific.
I
I
think
I'm
going
the
wrong
direction,
or
maybe
I'm
misunderstanding,
but
I
I'm
thinking
that,
maybe
you
mean
it's
specific
to
how
you
got
the
manifest.
H
I
I
was
trying
to
avoid
enumerating
all
the
possible
ways
that
this
could
work.
That's
what
I
was
trying
to
do.
I'm
saying.
G
H
I
agree
with
you
completely
okay,
so
the
then
the
only
question
I
have
is:
do
you
think
it's
a
good
idea
to
overload
the
reference
uri
and
make
that
an
option
as
that
a
device
may
choose
for
producing
that
offset.
So
you
know
if
it
if
it
knows
something,
local
and
and
that's
maybe
where
it
got
its
first
manifest,
for
example,
then
it
starts
there
and
if
it
can't
find
what
it's
looking
for
there,
then
it
can
use
the
reference
uri
as
a
second
step.
G
I
Then
you
can
go
get
it
here.
I
think
that
a
certain
amount
of
nominal
determinism,
but
I
think
that
may
be
an
acceptable
amount.
Okay.
What
what
I'm
worried
about
is?
Oh
and
then
it
it
went
to
this
ran
site
that
no
one
really
was
expecting
and
and
thinking
mud
files
here,
specifically
yeah,
and
it
failed
because
it
wasn't
allowed
to
get
there,
because
no
one
knew.
I
H
H
So,
just
just
a
thought
there.
Maybe
we
should
think
about
that
some
more
so
I
think
we
have
like.
Is
there
anyone
else
in
the
queue.
J
So
I
think
that
that
this
is
a
place
where
examples
are
a
good
middle
ground
by
not
specifying
the
doubt,
they
would
provide
exactly
the
non-intuitive
guidance
that
we
need,
for
example.
The
second
example
here
was
mud,
but
also
the
if
there
is
no
reference
uri.
It
is
probably
still
very
known
to
the
context.
J
So
so
you,
if
it's
it's
not
there,
you
assume
there
will
be
something
there
and
then
these
two
examples
spelled
out
in
the
I
don't
know:
user
story,
probably
with
the
mitigate
the
uncertainty
here
or
engineers
to
implement
that.
H
G
So
if,
if,
if
it's
possible,
I
think
it's
more
straightforward
to
say
that
if
there
is
a
if
if
an
explicit
base
is
indicated,
then
that
is
the
base
and
if
no
explicit
one
is
indicated,
then
the
context
may
have
one
failing
that
relative
references
just
don't
work
but
yeah.
I
try.
H
So
so
I
would
actually
argue
for
the
opposite
order.
If
there
is
a
locally
known
context,
it's
probably
correct
and
the
reference
uri
should
be
used
as
the
as
the
reference
of
last
resort,
and
that's
because
we
don't
know:
what's
happened
in
the
chain
of
custody,
on
the
manifest
to
to
get
it
to
where
it
is
and
and
and
so
that
uri
might
be
old
or
hard
to
access.
G
H
Hearing,
oh,
I
have
skipped
ahead
by
accident.
Hurry
there
there
okay,
so
the
next
point
is
that
there's
been
a
request
for
future
manifest
uris
and
the
idea
behind
this
is
essentially
to
advertise
in
a
manifest.
What
the
place
the
update
client
should
look.
H
What
the
place
is
that
the
update
client
should
look
for
the
next
manifest
I
this
could
be
used
for
update
service
migration,
for
example.
This
is
an
interesting
idea,
but
my
my
question
is:
does
this
belong
in
the
core
specification?
I
I
think
it
might
not.
I
think
this
might
be
an
extension.
H
Should
it
be
component
specific,
should
it
be
overrideable
and
then
finally,
is
it
an
artifact
of
secure
invocation?
You
know
secure
boot,
or
is
it
an
artifact
of
installation?
It
can
make
an
argument
that
it
should
be
an
artifact
of
secure
boot,
especially
in
the
situation
where
there
are
severed
sections,
because
that
information
will
be
lost.
H
Alternatively,
you
can
make
an
argument
that
it
should
be.
It
should
be
part
of
the
the
update
section,
because
that's
the
application,
that's
going
to
be
doing
the
work,
so
I'm
I
think
I
probably
come
on
the
side
of
this
should
be
part
of
secure
invocation,
but
I'd
be
interested
in
feedback
and
further.
I
think
the
most
important
feedback
on
this
is.
Should
this
be
part
of
the
course
specification,
or
should
this
be
moved
to
an.
B
I
think
the
default
answer
is
put
an
extension
because
we're
trying
to
get
the
manifest
to
be
published
as
soon
as
possible
and
move
everything
else
to
extensions
right,
move
some
things
out
like
firmware
encryption
so
on,
and
so
unless
I
mean
it's
a
compelling
reason
why
it
cannot
be
left
to
an
extension.
I
think
that's
the
default
answer.
H
Agreed
extension,
it
is
all
right,
moving
on
integrated
payloads
there's
a
question
of
whether
you
should
be
able
to
compute
a
digest
directly
on
an
integrated
payload.
Now
this
is
a
problem,
because
the
existing
condition
for
evaluating
an
image
digest
only
refers
to
a
component
id,
which
means
that
you
can't
refer
directly
to
an
integrated
payload.
H
My
inclination
is
that
this
should
be
referenced
by
using
a
a
new
condition.
Integers
are
cheap
and
if
you've
got
an
integrated
payload,
then
you
clearly
are
not
worried
about
having
minimum
size
of
your
manifest,
so
adding
a
a
new
commit,
a
new
condition
specifically
for
doing
this
seems
like
it's
probably
the
right.
The
right
answer,
the
one
question
here
that
I
would
have
if
we
were
to
do
it.
That
way
is
what
should
the
component
id
be?
H
H
And
I
again,
I
think
this
might
be
a
candidate
for
a
an
extension
and
unless
someone
has
a
burning
need
to
have
it
in
the
in
the
core
specification.
That
is
what
I
would
aim
for.
H
Okay
know
what.
E
H
I
I
think
it's
probably
an
important
feature
where
integrated
payloads
are
used
extensively.
If
they're
not
being
used
extensively,
then
maybe
not.
H
Question,
okay:
well
again,
I
think
maybe
the
step
here
is
to
to
propose
some
text
and
take
it
back
to
the
list,
and
then
we
can
work
out
whether
this
goes
in
the
base,
spec
or
not.
H
Okay,
next
so
there's
a
question
about
whether
we
should
use
integer
references
for
integrated,
payloads
and
indeed
integrated
dependencies.
The
the
issue
that
I'm
dealing
with
here
is
that
right
now
we're
using
integers
to
reference
integrated
payloads.
Now
what
this
does
is.
It
means
that
the
manifest
itself
has
to
execute
a
integer
to
string
conversion
or
sorry,
a
string
to
integer
conversion
in
order
to
look
up
the
correct
key
for
its
integrated
payload,
because
this
is
referenced
as
a
fragment
only
uri
reference.
H
This
see
it
doesn't
seem
to
me
like
it's
necessarily
the
right
approach.
It
also
actually
increases
the
size
more
than
you
would
expect.
The
reason
for
this
is
that
you
can
use
a
shorter
string
if
you
are
or
like
a
shorter
uri
reference
fragment
only
reference
if
you
are
using
a
string
one
rather
than
an
integer,
and
that's
simply
a
a
a
factor
of
the
size
that
it
takes
to
represent
a
number
large
enough
to
fit
in
so
size
is
sizes
shouldn't
be
an
issue.
H
If
we
were
to
switch
to
using
strings
the
the
big
issue
would
be
having
two
possible
keys
in
the
envelope,
either
integer
or
string.
That
would
be
the
only
real
substantial
change
here.
It
does
have
some.
So
the
the
thing,
one
thing
that
I
I
do
think
is
a
big
benefit
to
switching
to
using
a
string
rather
than
a
an
integer
reference
is
the
that
we
can
avoid
any
possible
collisions
with
future
extensions.
H
You,
you
can't
collide
a
string
with
an
integer
so
that
solves
that
problem
pretty
solidly
and,
of
course
we
remove
the
string
to
integer
conversion
in
the
manifest
processor,
which
is
good
too.
H
So
if
there
are
no
objections
to
it,
I
would
like
to
change
the
the
integrated
payloads
and
integrated
dependencies
to
be
strings.
That
point
our
strings,
that
key
a
white.
B
H
Yeah,
and
it
looks
like
michael,
is
supportive
as
well.
I
think.
H
They
do
not
currently
have
github
issue
numbers.
I
should
fix
that
all
right
next
topic,
then,
oh
right,
I
went
through
it
without
actually
without
actually
looking
at
the
the
slide
that
had
it.
Okay.
So
one
of
the
interesting
options
that
that
you
would
have,
if
you
were
to
to
follow
this
proposal,
is
that
you
could
take
a
an
optimization
option
where,
if
you
as
a
distributor,
wanted
to
make
sure
that
a
device
checked
for
an
integrated
payload
before
it
before
it
went
and
did
a
fetch.
H
What
you
could
do
is
take
the
uri
that
you
were
going
to
use
or
that
the
device
was
going
to
use.
You
can
see
it
plainly
in
the
manifest
and
put
that
in
the
envelope
reference
and
put
the
payload
with
it,
and
then
your
device
will
go
and
pull
that
out
of
its
own
manifest
because
it
checks
for
that
string
in
the
manifest
before
doing
a
remote
fetch.
So
there's
an
interesting
option
that
you
have
there
as
a
distributor
to
essentially
change
the
fetching
policy
without
changing
anything
to
do
with
a
manifest
at
all.
H
You
simply
put
the
payload
in
the
envelope
at
the
right
uri
or
with
a
string
key
that
is
a
uri
and
that's
where
fetch
hits
first.
So
that's
an
interesting
option.
I'm
not
saying
that!
That's
something
that
needs
to
be
mandated,
but
that's
something
that
maybe
we
should
think
about
you
know.
Do
you
always
check
there
first
or
not
and
again,
I
think
the
right
answer
here
is
to
put
some
text
on
the
list,
given
that
there
is
some
support
for
this
approach
and
go
from
there.
H
So
what
this
would
look
like,
I
just
I
put
together
an
example
of
the
encoding
sizes,
and
you
can
see,
as
I
mentioned
before,
that
the
sizing
turns
out
to
be
pretty
similar.
The
reason
24
is
picked.
There
is
because
the
the
code
or
the
cddl
explicitly
states
that
the
integrated
payload
key
must
be
24
or
larger.
So
that
is
the
minimum
number
of
bytes
that
you
can
use
as
a
uri
fragment
only
reference,
all
right
and
and
now
hopefully
I'm
on
to
the
next
topic
and
nope-
that's
the
cdl
for
it.
H
Let's
keep
going
okay,
now,
there's
we
currently
have
a
mandatory
to
implement,
digest
algorithm.
H
So
there's
a
question
of
whether
we
should
implement
a
mandatory
to
implement
signature
algorithm
and
then
the
question
is:
which
ones
should
it
be?
Based
on
the
the
concerns
about
a
possible
future
break
in
existing
public
key
infrastructure?
H
It
seems
that
making
hss
lms
mandatory
to
implement
is
probably
the
the
thing
to
do,
because
that
it
allows
us
to
be
sure
that
devices
can
migrate
away
from
compromised
signature
algorithms,
if
and
when
a
quantum
break
occurs,
and
but
that
does
put
an
additional
burden
on
implementers
to
move
to
hss
lms
or
at
least
support
hss
lms
right
now,
and
I'm
not
sure
what
that
would
do.
For
this
specification.
K
And
I
make
about
this-
is,
I
know
at
least
with
nmcu
boot.
We
generally
build
a
given
configuration
with
only
one
signature
algorithm
chosen
as
supported,
and
that's
has
to
do
with
binary
size
and
constrained
devices,
and
I'm
not
sure
what
the
implication
would
be
of
a
mandatory
to
implement
signature
algorithm.
If
most
many
people
are
going
to
be
building
the
system
with
a
different
signature
algorithm
and
will
not
want
the
code
spent
implementing
another
one.
H
Yep,
that
is
exactly
the
concern
now.
The
one
comment
I
will
make
on
that
is
that
the
code
size
for
hss
lms
should
actually
be
quite
small.
The
reason
for
this
is
because
it's
based
entirely
on
hashes
and
since
you've
already
got
a
hash
algorithm
for
your
other
signature,
algorithm,
there's
no
additional
crypto
added
to
get
this
job
done.
It's
just
a
question
of
how
much
code
it
takes
to
implement
the
the
processing
of
that
signature.
I
Go
ahead,
michael,
so
I
I
take
your
point
that
the
most
of
the
crypto's
already
there
and
there's
some
other
stuff
to
validate,
which
is
some,
has
some
code
side
implications,
but
I
actually
think
the
bigger
issue
is
the
trust
anchor
maintenance
on
that
on
that
lms,
hss,
lms
and
possibly
another
one.
I
So
if
you
now
have
two
trust
anchors
to
deal
to
maintain
that's
a
big
deal
and
the
argument
I
think
becomes
if
you're
gonna,
if
you're
gonna
have
the
hash
based
signatures
at
all,
unless
the
signature
size
impact
is
you
know,
monstrously
horrible,
then
the
argument
becomes
well.
That's
just
that's
the
one
that
we're
going
to
that's
the
one
we're
going
to
maintain
anyway.
H
I
Well,
so,
okay,
so
that's
so!
Okay,
so
it's
not
megabytes
is
what
I
I
I
knew.
That
was
probably
the
case,
but
some
people
may
have
been
worried
about
some
of
the
other
post
quantum
signatures
which
were
huge.
I
But
then
you
know
compare
that
extra
kill,
k
and
a
half
to
the
size
of
the
firmware
that
you're
going
to
apply,
and
maybe
that's
not
so
important,
and
I
believe,
if
I'm
not
mistaken,
that
you
could
then
get
away
with
not
having
any
dsa
or
or
edd
essay
in
your
boot
path,
because
you'd
only
have
hashes
and
that.
H
H
Otherwise
you
might
sign
two
different
things
with
the
same
branch
on
your
merkle
tree
or
the
same
leaf
on
your
merkle
tree,
and
if
you
do
that,
then
your
private
key
becomes
useless
you
you
have
effectively
exposed
it
by
signing
two
different
things
and-
and
there
is
a
finite
number
of
signatures
as
well,
so
that
produces
a
new,
a
new
and
different,
exciting
burden
for
signers
to
to
hold
on
to,
and
so
the
I
guess
what
this
is
about
is
whether
this
should
be
placed
in
as
a
algorithm
of
last
resort.
I
If
I
had
an
asymmetric
key,
all
I
need
to
do
is
read
the
private
key
from
my
secure
storage,
use
it
and
then
delete
it,
yep
right,
whereas
with
a
hash
based
signature,
I
need
to
read
it
use
it
and
then
update
the
state
on
the
the
secure
storage
that
way
and
that's
correct,
that's
a
a
different
ceremony
and
it's
a
ceremony
that
people
will
get
wrong
if
they
aren't
using
it
every
week.
B
E
Okay,
so
I'm
the
one
who's
originally
advocated
for
hash
based
signatures,
and
the
reasoning
is
if
we
don't
exactly
know
when
a
quantum
computer
is
going
to
come,
but
the
path
for
distributing
any
new
crypto
is
software
update.
So
it
would
be
really
nice
if
the
software
update
was
resistant
to
that
attack.
E
The
statefulness
that
you
talked
about
is
definitely
true.
That's
unique
to
this
kind
of
signature.
That
is,
is
something
that
you
know
the
firmware
signer
will
have
to
be
aware
of,
and
I'm
aware
of
at
least
one
hsm
implementer
who
has
already
taken
care
of
all
of
that
stuff
for
the
signer.
H
B
See
anything
but
he
said,
should
we
list
mandatory
implement
in
the
base
spec
versus
a
crypto
spec
and
should
we
be
concerned
about
longer
term
agility
and
he
said
he
was
gonna,
ask
it
at
the
mic.
So.
H
H
I
I
take
david
brown's
point
if,
if
this
adds
any
space
at
all,
it
might
be
a
hard
reject
from
you
know,
and
if
that's
mandatory
to
implement,
then
we
either
fragment
the
implementation
space
with
non-compliant
implementations
or
the
standard
doesn't
get
picked
up,
and
I
don't
think
either
of
those
is
a
good
answer.
So
this
this
presents
a
bit
of
a
problem.
H
I
think,
if
we're
going
to
make
it
mandatory
to
implement,
then
we're
going
to
have
to
provide
a
we're
going
to
have
to
provide
real
measurements
of
exactly
how
much
code
size
this
costs
and
be
able
to
to
demonstrate.
This
is
a
worthwhile
venture
for
that.
So
I
I
mean
if,
if
anyone
here
is
able
to
produce
really
reduced
size,
implementations
of
hss
lms,
that
would
be
really
helpful.
H
E
Be
so
responding
to
that,
I
do
think
that
we
should
see
what
the
code
size
for
either
of
these
elliptic
curves
versus
hss
lms
is.
I
would
argue
that
the
hash
is
the
same,
and
so
the
question
is
the
merkle
tree
versus
the
elliptic
curve
stuff,
and
we
I
mean
I
have
a
python
implementation
of
hs
lms
and
I've
open
sourced
it.
So
I'm
pleased
to
work
with
anybody
on
that,
and
I
will
point
out
that
the
vast
bulk
of
the
code
is
on
the
signer
side.
F
C
Seems
like
a
really
big
decision
for
us,
and
so
I
wanted
just
to
repeat
what
we've
been
talking
about
here.
I
I
don't
think
we
should
make
this
decision
on
assumptions
and
we
should
get
real
numbers
and
talk
through
what
the
trade
is
and
then
be
very
explicit
with
you
know,
with
real
kind
of
data
that
we're
making
this
trade,
because
potentially
this
could
lock
us
in
in
a
bad
way
yeah
and
you
should
just
be
very
deliberate.
H
Thanks
yeah,
I
agree,
and
I'd
add
to
that
that
I
would
also
really
like
to
get
feedback
from
potential
implementers
on
exactly
whether
this
would
be
a
stumbling
block
for
them
or
not.
H
Okay,
well
it
I
I'll
take
the
the
argument
from
that
that
we
probably
aren't
going
to
have
a
decision
on
this
today
and
that
what
this
is
is
we
need
further
research.
So
I
think
that
that's
probably
where
we
have
to
go
from
here.
I
So
I
I
just
want
to
reiterate
that
I
think
that
when
you
said
implementers,
I
think
that
you
were
thinking
probably
of
people
like
mcu
boot,
and
I
know
that
just
mentioned
his
python
program
on
that
side,
but
I
think
there's
a
and
he
said,
there's
an
hsm
vendor
that
had
some
things,
but
I
think
that
we're
lacking
a
process-
or
maybe
you
know
people
call
it
a
ceremony
on
the
management
on
the
signing
side
of
things.
I
understand
how
that
is.
I
I
think
we
understand
for
this
some
asymmetric
algorithms.
We
know
how
to
do
that
and
we
also
can
build
trees
of
pki,
specifically
trees
of
keys,
and
it's
unclear
how
we
do
that
from
a
management
point
of
view
at
the
layer,
eight
kind
of
point
of
view-
and
I
think
that's
where
actually
the
biggest
risk
for
this
comes
from
is
figuring
that
out,
and
so
I
think
we
actually
need
someone
to
go
and
and
do
some
kind
of
a
trial.
I
don't
know,
maybe
nist
something
like
that.
You
know
so
that.
H
Maybe
I
guess
the
other
point
to
to
to
make
on
this
is
that
nist
has
only
just
within
the
last
year,
actually
declared
winners
for
their
hash
based
signature
contest,
so
these
have
only
just
become
nist
approved,
and
that
is
a
risk
in
and
of
itself,
not
not
that
there's
anything
wrong
with
the
technology
you
understand,
I
know
hash
based
signatures
are
very
old.
That's
not
the
argument,
I'm
making.
What
I'm
saying
instead
is
that
there's
a
lack
of
tooling,
not
saying
anything,
bad
about
your
about
your
python
library,
russ.
H
What
I'm
saying
is
that
it's
it's
not
quite
the
same
as
the
infrastructure
that's
available
for
rsa
and
ecdsa
and
eddsa.
So
it's
a
really
limited
selection
of
tools
available.
I
would
be
surprised
if
you
found
a
lot
of
hsms
that
implemented
it.
I
am
glad
to
hear
there's
at
least
one.
That
was
a
surprise.
To
be
honest,
so
you
know
this.
H
This
is
actually
the
the
availability
of
tooling
is
a
real
concern,
and
I
wonder
if
the
right
answer
isn't
to
make
one
of
now
one
of
the
existing
asymmetric
algorithms,
the
mandatory
to
implement
for
now
and
then
issue
abyss
in
a
while
to
deprecate
it
and
make
make
hss
lms
mandatory.
Instead,
you
know,
we
can
put
you
know
a
warning
right
in
there
that
says
look.
H
This
is
coming
as
soon
as
you
know,
as
soon
as
the
tooling's
ready,
but
I
worry
that
we're
we're
limiting
the
audience
if
we
make
hash
bay
signatures
mandatory.
At
this
point.
H
E
And
that
way,
we're
signaling
that
this
is
a
thing
that
we're
thinking
about
going
forward.
We
can
even
put
an
extra
sentence
in
there,
but
the
should
should
get
someone's
attention
yeah.
I
would
be
fine
with
that
way
forward.
H
B
Forward
to
the
chat
for
michael,
are
you
disagreeing
with
that.
I
Well,
I
I
heard
I
heard
that
I
heard
russ
say
that
it's
going
to
be
a
must,
plus
a
should
a
must
on
hash
based
signature
and
a
should
on
some
algorithm.
The.
I
So
I
I
yeah
so
but
now
you're
making
people
meant
two
things
and
higher
code
size.
So
that's
why
I'm
arguing
that
you
know
you're
we're
gonna
wind
up
with
with
an
asymmetric
as
a
should
anyway,
and
we're
going
to
have
a
may
right,
so
you
have
three
options
there
right
and
so
you're
going
to
wind
up
with
with
some
kind
of
a
anyway.
The
point
is,
I
don't
think
we'll
ever
get
to
having
hash
based
signatures
as
a
must.
I
If
we
start
off
with
it
as
I
should,
the
pushback,
I
think,
will
be
too
big
in
the
and
it's
a
voluntary
standard
and
I'm
just
worried
it
will
be
exactly
the
situation.
Russ
worries
about
yep.
H
H
B
B
Ross,
you
seem
to
be
the
most
up
to
be
on
this
one.
Do
you
want
to
figure
out
how
to
ask
the
question
any
suggestions.
E
So
why
don't
we
just
ask
a
poll?
Do
you
prefer
and
then
ask
for
those
three
choices?
I
don't
know
how
to
do
a
three-way
poll.
That
only
does
yes,
no
right
so,
but
that's
the
question
I
really
would
like
to
ask,
but
let's
start
with,
do
you
prefer
hash,
based
or
elliptic
curve
and
then,
if
elliptic
curve
wins
will
last
between
those
two?
How
does
that
work.
E
B
Well,
I
guess
the
only
thing
that
we
should
just
verify
is
that
those
who
preferred
elliptic
curve
is
there
a
strong
technical
argument
that
you
have
that
you
think
would
be
convincing
to
anybody
else
that
has
not
already
been
discussed.
If
you
have
new
technical
input,
please
come
to
the
mic.
Otherwise,
if
it
is
just
a
preference
or
for
reasons
we've
already
discussed
in
the
meeting,
then
I
think
we're
done
with
that.
One
with
that
question,
rich
cells.
L
E
So
rich
I'll
just
point
out
that
everything
in
there
is
more
than
20
years
old,
so
there's
no
submarine
patents.
If
that's
what
you
were
thinking,
no.
L
I'm
not
worried
about
the
submarine
patents
and
okay,
I
know
there's
those
are
two
very
different
issues.
Right,
yes
and-
and
I
I
yeah
I
know
the
stuff's
gone
since
layton
went
off
to
found
a
company
I
work
for,
but
yeah,
it's
all,
that's!
Okay.
I
understand
I'm
not
concerned
about
the
security
implications
of
the
technology.
I'm
just
concerned
about
adding
too
much
burden
that
becomes
a
barrier
to
acceptance
is
yes.
H
The
the
argument
I
would
make
on
this
is
that
one
of
the
ways
that
we
can
reduce
the
burden
is
that
we
can.
We
can
actually
put
in
the
the
signature
calculations
for
hss
lms,
not
not
the
hashes,
the
hash
algorithms.
You
know
you
have
to
be
supplied
separately,
but
if
that
becomes
part
of
the
of
the
the
suit
parsing
process,
then
the
argument
becomes
that
the
suit
parser
always
has
to
supply
that
and
and
that
sort
of
solves
the
problem.
You
know
it's
part
and
parcel.
It
comes
with
it.
H
If
it's
mandatory
to
implement
you
can
make
an
argument
for
doing
that,
and
that's
that's
convenient,
so
maybe
there's
maybe
there's
an
option
there.
I
don't
know
this
is
something
that
obviously
needs
some
more
thinking
about,
but
you
know
we
have.
We
have
options
for
making
it
less
of
a
burden
for
implementers.
H
All
right:
well,
let's,
let's
get
this
thing
moving
on!
Oh
and
I've
gotten
back
to
the
start
again,
somehow
sorry
about
that.
Yes,
document,
structure,
okay,
so
I've
had
a
number
of
reviews
from
outside
the
working
group
that
suggest
that
the
manifest
specification
is
too
complex
or
even
too
complex
to
implement
it.
It's
a
shame
that
I
I
updated
to
version
14,
because
version
13
was
111
pages
long,
which
I
thought
would
have
been
ideal
for
this
particular
ietf.
H
But
that's
the
only
thing
it
would
be
ideal
for
a
111
page
or
113.
Now
page
document
is
a
bit
long
for
what
is
hopefully
a
fairly
simple
concept.
So
I'm
concerned
that
people
are
worried
that
it's
complicated
because
the
the
actual
core
of
the
the
idea
behind
it
is
quite
simple.
H
So
I've
been
trying
to
think
about
how
we
could
get
it
down
to
something.
That's
a
little
bit
more
reasonable
one
of
the
ways
we
could
do,
that
is
by
reducing
the
core
specification
to
just
a
small
number
of
use
cases,
and
I
have
a
proposal
here
for
exactly
which
q
use
cases
those
would
be
so
this
would
mean
that
exactly
what
gets
covered
in
a
given
in
the
the
core
draft
is
substantially
reduced.
H
So
I'm
curious
whether
we
have
we
have
a
support
for
taking
the
simplification
action
and
essentially
what
it
would
mean
is
that
we
would
break
the
current
manifest
specification
out
into
several
documents.
So
what
the
core
specification
would
contain
is
a
shorter
list
of
commands
and
parameters.
H
The
ones
listed
here
and
I'm
not
sure
that
it
makes
sense
to
you,
know,
walk
through
that
right
now,
but
just
it's
a
reduced
set,
and
only
the
ones
that
are
necessary
to
get
the
core
use
cases
to
work,
and
then
there
would
be
a
an
extension,
a
set
of
extension
drafts,
four
of
them,
I
think
which
would
provide
encryption.
So
that's
the
that's
the
one
that
has
already
working
on.
H
H
We'd
put
the
commands
that
have
been
put
together
to
support
t
along
with
delegation
chains
and
dependencies
in
there,
and
I
I
thought
multiple
trust
domains
was
probably
the
best
way
to
explain
the
connection
between
those
things
and
then
update
management
as
another
draft,
and
that
would
give
you
directives
like
weight
and
additional
conditions
like
image,
not
match
and
used
before
and
batteries
battery
levels,
and
things
like
that.
H
So
I'm
wondering
if
the
working
group
would
support
this
kind
of
restructuring.
I
think
it
would
make
the
document
a
lot
simpler
and
hopefully
it
would
move.
It
would
allow
us
to
move
things
forward
a
little
bit
more
quickly.
This
document
has
been
not
quite
at
working
group
last
call
for
over
a
year
now,
so
I'd
really
like
to
see
what
we
can
do
to
move
it
forward
and
simplifying
it
seems
like.
Maybe
that
would
be
a
step
in
the
right
direction.
H
So
any
questions
comments,
criticism
just.
B
A
question
on
on
the
things
that
are
on
the
slide
right
now,
so
encryption
is
already
in
separate
one.
So
the
other
three
is
there
anything
that
are
that
you
know
of
that
has
been
open
issues
raised.
That
would
be
any
other
reason
to
split,
or
is
it
just
the
size?
That's
the
deterrent
for
people
to
read.
Is
there
anything
that
you
could
say
that
they
recruit
that
the
document
could
go
to
last
call
faster
by
splitting
out
those
three?
B
So,
for
example,
early
in
the
session
we
had
that
come
up
when
we
said
by
default.
The
answer
is
going
to
be
extension,
because
there
were
those
questions
we
didn't
answer
right
and
the
same
thing
with
encryption.
We
were
split
that
off
so
that
their
action,
all
the
time
was
so
that
the
main
document
could
go
to
working
group
last
call
right
and
take
longer.
So
does
that
argument
apply
to
any
of
the
three
bullets
there,
because
we
do
have
things
like
teep?
B
H
Oh
speed
things
up
in
teep
is
another
question.
Hopefully
not
to
not
not
a
lot
of
slowdown
in
tape
would
be
would
be
my
answer
there,
because
the
the
content
of
the
multiple
trust
domains
document
is
essentially
everything.
That's
already
in
suit
and
hasn't
had
issues
raised.
The
one
place
where
I
think
there
probably
are
going
to
be
issues
raised
is
actually
in
compression
and
differential
update.
I
think
that
those
are
not
well
specified
enough
that
they
should
really
be
dealt
with
at
this
time.
K
I
I
think
you
said
my
name,
I
guess
one
question
I
would
have
about
this:
are
we
putting
too
much
in
the
base
of
this
proposal?
K
Would
we
be
better
off
with
the
core
specification
being
even
more
simple
of
just
some
kind
of
streamlined
load
this
something
like
that
and
then
those
kind
of
profiles
and
use
cases
that
we
had
that
you
spelled
out
in
the
previous
slide
would
be
another
doc,
just
a
wondering
about
that.
The
use
cases
here
we
are
yeah
or
without
that
yeah.
H
Maybe
maybe
I
worry
that
if
we
strip
it
down
too
much,
then
it
will
simply
look
like
this
specification
doesn't
meet
my
use
case.
You
know
and
that'll
be
the
default
answer
as
I
look
at
it,
and
this
doesn't
do
what
I
need.
H
A
thought
no
fair
enough.
I
I
was
you
know,
I'd
like
to
pare
it
down
more
as
well,
but
after
a
certain
point,
we're
going
to
hit
diminishing
returns
and
that's
simply
a
a
question
of
exactly
what
is
the
incremental
cost
in
adding
one
of
these
use
cases,
and
when
we
start
with
the
first
one
there,
the
incremental
cost
of
adding
the
additional
ones
after
looks
to
me
to
be
fairly
small.
H
I
don't
think
it's
a
big
incremental
cost
to
add
the
additional
ones,
at
least
between
the
the
first
four
in
the
section
when,
when
you
get
to
two
images,
oh
no,
that
one's
actually
pretty
simple
as
well,
so
so
the
the
reason
I
say
that
is
because
that
one
is
just
about
the
ability
to
set
a
component
index.
That's
literally
the
only
thing
it
adds.
D
Yep,
okay,
honest
yeah.
I
just
wanted
to
point
out
that
when
we
started
working
on
the
firmware
encryption,
there
was
also
the
impression
at
least
I
had
that
impression
with
that
it
would
be
totally
straightforward
and
we
just
provided
an
example
in
there
not
a
big
deal,
and
then
I
stumbled
over
one
issue
after
the
other,
and
my
worry
is
that
we
may
actually
see
that
with
other
things,
as
well
as
an
example.
D
The
cost
with
stuff
trying
to
do
an
example
there.
The
delegation
chains
may
fall
into
that
bucket
as
well.
So
it
the
fact
that
questions
have
haven't
been
raised
or
issues
haven't
been
pointed
out
is
maybe
not
enough.
So
that's
why.
I
think
this
is
a
good
idea
to
separate
this
out
and
then
have
more
possibility
to
work
on
these
more
advanced
cases
and
to
get
them
right
have
proper
examples
in
there
not
worry
about.
Oh,
am
I
adding
another
20
pages
or
so
just.
G
D
D
B
So
I
think
I'm
next
in
queue,
so
you
didn't
explain
the
rationale
for
what
was
core
and
what
was
the
extension.
So
I'm
going
to
give
you
a
proposed
rationale
that
I
think
matches
your
split
and
have
you
confirmed
whether
the
split
is
the
correct
split?
B
Okay,
if
you
think
about
the
there
are
some
parts
of
the
suit
manifest
document
right
now
that
are
mandatory
to
implement
and
there
are
some
parts
that
are
optional,
okay,
and
so
my
hope
is
that
there
is
nothing
that
you
would
split
out
that
is
already
mandatory
to
implement,
because
that
would.
G
B
Breakage
or
whatever,
but
you
could
argue
that
everything
that's
optional
could
be
split
out
because
you're
not
going
to
break
anything
by
splitting
it
out
right,
and
so
hopefully
my
point
is
that
perhaps
the
rule
of
thumb
is
that
anything
that
is
optional
goes
into
a
separate
spec.
B
That
was
clearly
optional
and
now,
if
you
last,
if
you
think
about
the
way
people
often
specify
compliance
in
your
checkbox
and
stuff,
they
often
do
it
on
rfc
number
basis,
which
we
all
know
is
bad,
but
people
do
it
anyway
right
and
so
at
least
there's
an
advantage
that
says
if
you
split
off
the
optional
stuff
and
people
who
follow
the
bad
practice
are
at
least
not
causing
us
problems.
So.
H
Yeah,
so
that's
exactly
what's
done
here:
all
of
the
mandatory
to
implement
are
in
the
base.
Spec
a
few
of
the
optional
to
implement
are
are
also
in
the
base
spec,
but
only
the
ones
that
are
necessary
to
meet
a
set
of
reasonably
simple
use.
Cases
that
that
was
the
idea
behind
the
split.
B
Yeah
and
for
everybody
else
brendan-
and
I
and
others
were
talking
about
in
another
context,
related
to
deep
and
rats
about
the
need
to
do
like
what
commands
do
you
support
in
suit
right
and
so
as
long
as
all
the
optional
ones
are
out.
It
does
not
change
that
discussion
in
any
way
right,
because
we
already
have
to
do
stuff
to
be
able
to
enumerate
that
which
we're
not
solving
yet
right,
and
none
of
it
affects
that
discussion.
So
yeah.
I
Thanks,
so
I
guess
I'm
supportive
of
this,
I
I
I
think
that
one
of
the
things
I
heard
from
hannes-
and
I
don't
know
there
was
a
plus
or
a
minus
that
as
he
split
off
the
encryption,
he
found
that
the
scope
of
content
that
he
needed
to
cover
was
larger
and
I
think
that's
because,
as
you
split
the
documents
out,
you
basically
wind
up
painting
a
crosshair
on
more
of
the
document
to
be
looked
at
yeah.
So
so
that's
an
a
negative
from
the
point
of
view
of
getting
the
thing
done.
I
H
On
the
encryption
document
was
actually
key
distribution,
we
didn't
have
any
tests.
I
I
But
so
I
guess
I
would
say
that
that
the
the
key
thing
in
my
mind
and
and
I'm
going
to
say
that
that
when
I've
read
the
sp
suit
spec
and
I
haven't
read
the
current
rev,
but
you
know
maybe
six
months
ago
as
I
get
to
all
these
commands
and
I'm
going
to
admit
that
in
most
cases
I
just
hit
page
down
page
down
when
I
actually
write
code
I'll
come
back
and
figure
out
what.
G
I
All
mean,
but
fundamentally
what
I'm
actually
saying
is
that
you
lost
my
attention
because
I
needed
the
high
level
view,
and
so,
as
long
as
the
core
components
are
within
people's
attention
span
who
are
reading
it,
then
I
think
that's
it's
a
good
thing
and
they
have
a
view.
I
think
the
that
in
the
introduction
and
the
other
things
and
some
of
these
core
use
cases,
I
think
you
act.
We
actually
need
to
cover
them
in
the
base
document.
That
says,
we
support
blah
blah
blah,
but
you
need
to
go
see
these
other
documents.
I
However,
those
need
to
be
informative
references
so
that
we're
not
actually
creating
a
cluster
as
michael
jenkins
suggested.
So
we
need
to
say
that
we
also
support
the
blah
blah
blah,
but
it's
through
the
additional
of
work,
which
is
not
a
normative
reference
so
that
we
can
actually
get
through,
but
we
need
to
still
tell
them
that
it's
that
that
their
their
use
case
is
supported,
and
I
think
that
where
you're
going-
and
so
I'm
supportive
of
that-
that.
A
B
H
Think
that
one's
I
don't.
B
H
That
one's
okay,
we.
B
H
I
don't
think
so.
The
only
the
only
element
I
can
think
of
on
on
that
list
would
be
the
the
digest
of
an
integrated,
payload
and
and
that
one
is
reasonably
straightforward
and
I
don't
think
there's
a
lot
of
corner
cases
in
it.
So
if
that's
the
case,
then
maybe
the
right
answer
for
that
one
is
to
just
put
it
in.
B
Yeah,
I
mean
it
if
you
think,
if
you
make
something
that
you
think
is
not
out
of
line
with
what
you've
heard
today,
then
in
my
opinion
and
it's
there,
then
that
would
not
stop
us
from
beginning
working
with
last
call,
because
the
working
glass
call
will
solicit
the
feedback
on
that
see.
If
we
got
it.
B
H
Okay,
well,
I
think
that's
the
end
of
of
that
of
my
slides,
so
I
guess
I
don't
see
anyone
in
the
queue
and
the
chat
has
gone
quiet,
so
I
think
I've
done
this.
C
B
E
B
D
Yeah
I
start
and
then
hand
over
to
brent
and
maybe
maybe
you
can
show
the
slide,
so
we
don't
have
the
same
disaster.
A
So,
just
a
minute
here,
while
I
swap
which
screen
is
being
presented.
Okay
here
we
go.
Hopefully
I
got
it
right
this
time.
D
That
that
looks
good,
perfect
thanks,
okay,
yep
next
time.
D
Can
you
see
me
okay,
yeah?
We
we
added
the
architectural
description.
I
have
a
figure
later
on.
There's
example:
examples
in
there
for
the
aes
keywrap,
which
is,
I
think,
pretty
solid.
I've
started
the
the
work
on
hbk.
D
Initially,
I
thought
that
I
could
reuse
an
existing
implementation,
but
then
the
whole
sort
of
that
was
more
complicated.
I
used
stephen
ferris
implementation,
which
used
openssl,
but
because
I
need
to
obviously
have
some
code
to
create
the
examples,
but
that
wasn't
straightforward,
but
I
completed
that
one
and
need
to
release
the
code
somewhere
as
well,
so
there
are
still
a
few
missing
items
there.
The
examples
that
are
currently
in
there
are
focused
on
the
cozy
encrypt,
rather
than
an
entire
manifest.
D
I
think
that's
important,
there's
also
currently
only
a
description
of
the
firmware
encryption
itself
rather
than
the
encryption
of
the
manifest,
which
is
also
a
feature
that
we
wanted
to
have
based
on
early
discussions
in
the
group.
Why
not
substantially
different
in
the
sense
of
like
the
encryption?
Algorithms?
Don't
care
about
the
encrypt,
but
I
think
it
would
still
be
be
useful
to
explain
that
how
this
would
look
like,
and
that
needs
to
be
done.
D
There's
also
a
question
mark
about
whether
we
should
cover
or
include
a
discussion
about
how
to
maintain
the
confidentiality
of
the
firmware
image
once
it's
on
the
device
itself,
because
it's
a
related
issue
once
you
do
the
update
and
then
potentially,
if
something
fails,
you
swap
it
out,
for
example,
to
external
flash,
if
done
incorrectly,
that
could
easily
lead
to
a
compromise
and
make
the
whole
process
of
encrypting
the
firmware
image
like
mood
so
that
at
least
from
a
security
consideration
section,
maybe
that's
a
point
on
an
aspect
that
we
should
talk
about
this.
D
This
happens
next
slide.
D
One
question
that
came
up
and
I
think
russ
you
brought
it
up-
is.
D
B
D
K
Statement
about
your
last
point
there,
with
the
interact
the
on
device
management
of
encrypted
images.
We
did
end
up
having
to
deal
with
a
lot
of
complexity
with
the
interaction
of
the
swap
command,
where
you
have
a
an
image
that
is
encrypted
when
in
the
upgrade
slot
and
is
decrypted
in
the
other
slot,
and
then
the
image
that's
unencrypted
has
to
be
encrypted
when
placed
back
in
the
swap
slot.
So
yeah
there's
some
complexity,
and
maybe
we
should
have
an
offline
discussion
about
the
details
of
that
yeah.
D
Yeah,
I
think,
there's
some
operational
guidance
that
one
could
provide
and
some
of
that
operational
guidance
is
has
been
made
in
the
mcu
boot
project.
So
I
think
we
should
leverage
that
and
make
it
aware
of
the
potential
bitfoils
in
making
that
implementation.
D
So
there's
also
some
more
advanced
hardware
that
actually
so
normally
that's.
What
david
has
just
been
talking
about
is
the
issue
of
you
need
to
decrypt
the
image
before
you
can
execute
it,
but
there's
also
in
the
meanwhile
some
hardware
that
literally
operates
on
encrypted
image,
because
the
decryption
is
done
by
the
hardware.
So
you
don't
need
to
sort
of
decrypt
and
copy
around.
So
that
may
be
also
something
to
describe
in
the
security
consideration
section
something
that
hasn't
been
done
yet.
D
Coming
back
to
the
document
management
question
and
and
the
point
that
russ
brought
up
in
an
offline
conversation
was
for
for
the
aes
key
wrap,
we
essentially
reuse
something
that
is
already
in
the
cosy
spec,
so
that
was
quite
convenient
and
we
profile
it
for
our
use
case
for
the
hpke
case.
Hybrid
public
key
encryption
case-
that's
not
the
case,
so
there's
the
the
cfr
chief
specification,
but
of
course
it's
very
generic
and
it's
obviously
not
sort
of
written
for
use
with
cosi.
D
D
H
Just
the
one
thing
about
that
is
that
there
is
already
something
in
cozy.
That's
similar
to
hpke
the
ecdh
ephemeral
static
with
aes
keywrap
gets
you
most
of
the
way
there.
D
Yeah,
that's
true,
but
and
that's
actually
what
I
implemented
initially
before
I
stumbled
over
hbt
the
problem.
There
is
there
and
a
bunch
of
similar
specifications
and
they
all
look
like
from
a
high-level
concept
very
similar,
but
they
are
not
not
the
same
so
just
being
halfway.
There
is
still
not
there,
so
you
would
yeah
the
hp
key
stuff.
Is
it's
just
incompatible
with?
What's
in
the
in
the
course
aspect,.
H
Right
now,
of
course,
I
I
guess
my
question
is:
what
would
we
gain
in
like?
What's
the
the
difference
for
suit
between
hpke
and
the
the
ecdh
ephemeral
static.
D
The
the
benefit
and
why
we
we
picked
that
one.
I
think
that
was
one
of
the
discussions
we
had,
that
the
last
idf,
and
also
the
virtual
intro
meeting
was
the
hbke
variant
seems
to
be
the
one
sort
of
candidate
that,
at
least
in
the
idea
people
want
to
go
forward
with
because
it
provides
the
formal
analysis.
It
provides
test,
vectors
and
there's
more
and
more
code
available,
because
it
seems
that
the
whole
hybrid
public
key
encryption
has
become
a
popular
building
block
in
many
of
the
protocols.
D
D
D
So
a
brief
recap
on
what
was
added
to
the
document,
because
it
will
help
to
understand
the
discussion
that
brent
is
going
to
go
into
in
a
second.
D
So
what
we
added
there
is
is
a
sort
of
a
description
of
the
differences
between
the
the
classical
signing
case,
where
the
also
signs
the
firmware
image
and
then,
of
course,
the
device
needs
to
have
a
trust
anchor
in
there
to
verify
the
signature
and
that
maybe
may
require
some
public
key
infrastructure.
D
Maybe
it's
in
some
cases
very
simple,
but
when
we
switch
over
to
encryption
of
the
firmware
images,
we
run
into
an
additional
challenge
because
the
author,
who
produced
the
software
and
the
library
and
so
on,
may
at
the
time
when
he
does
so
not
necessarily
know
what
all
the
devices
will
be
to
which
this
firmware
image
is
going
to
be
sent
to,
which
is
typically
the
role
of
the
distribution
system
like
an
iot
device
management
solution,
and
so
that
list
may
be
more
dynamic
and
the
author
may
not
be
burdened
with
knowing
the,
for
example.
D
D
So
in
any
case,
what
we
concluded
on
the
mailing
list
is
as
a
reminder
is
that
we
said
that
the
recipient
list
must
be
mutable
simply
because
by
the
it
must
be
mutable,
because
the
author
still
signs
or
protects
the
manifest,
and
so
the
distribution
system
cannot
change
it
anymore.
D
So
if,
if
because
the
cosy
encrypt
structure
has
to
be
put
into
the
manifest
or
the
envelope,
and
so
the
conclusion
was
from
the
mailing
list,
discussion
was,
we
need
to
put
it
into
envelope
so
that
someone
else
the
distribution
system
can
change
it
and
the
author
doesn't
need
to
know
what
the
devices
are
that
this
encrypted
firmware
image
will
be
sent
to.
D
But
having
that
said,
there
are
obviously
a
couple
of
sort
of
side
effects
of
that
decision
and
that's
why
I
hand
over
to
brenton
which,
where
he
discusses
the
threats
and
then
potential
mitigation
techniques,
brenton.
H
So
there's
there's
two
threats
that
come
up
here.
First
is
device
suppression
in
distribution.
This
is
different
from
a
conventional
dos,
because
a
specific
device
can
be
targeted
by
an
attacker
that
has
no
access
to
the
network
on
which
that
device
is
in
a
conventional
dos
attack.
The
the
attacker
would
only
be
able
to
suppress
all
devices
or
no
devices.
H
This
allows
them
to
suppress
a
specific
device
and
prevent
it
from
being
updated
so
that
that's
a
little
bit
different
than
a
conventional
attack,
and
and
that's
why
I
think
it
deserves
extra
attention
here.
So
what
they
would
need
to
do
in
order
to
get
this
attack
is
to
simply
prune
one
element
from
the
recipient
list.
H
So
in
order
to
do
that,
an
attacker
would
either
have
to
be
on
path
and
modify
the
recipient
list
in
transit
now,
and
that
is
between
a
between
the
author
and
the
distributor
and
that's
the
the
end,
node
distributor.
So
the
one
that
distributes
directly
to
devices
anywhere
between
that
and
that
attacker,
that
has
the
ability
to
to
modify
traffic,
would
be
able
to
do
this.
H
Alternatively,
if
the
manifest
is
hosted
on
a
cdn,
any
attacker
that
can
compromise
the
cdn
can
then
prune
the
recipient
list,
and
they
can
do
it
transparently
and
it's
the
transparency
here.
That's
really
important
because
it's
impossible
to
determine
whether
the
device
was
deauthorized
by
the
manufacturer
or
the
author
and,
oh
sorry,
yeah,
it's
impossible
to
tell
the
difference
between
it
being
deauthorized
and
it
being
under
attack,
and
I
think
that
that
is
a
really
important
distinction,
because
it's
a
repudiation
threat
as
well
as
well.
H
The
second
threat
that
we
have
to
consider
is
device
energy
and
flash
exhaustion
and
the
way
that
this
one
works
is,
it
is
a
denial
of
service
attack
on
a
specific
device
and
what
an
attacker
does
in
this
case
is
they
alter
the
cryptographic
material
in
presumably
in
the
cosi
recipients
list,
but
possibly
also
in
the
cosi
encrypt
and
by
altering
that
cryptographic
material.
H
They
make
it
so
that
the
device
spends
the
flash
cycles
and
the
energy
to
fetch
a
payload
decrypt
it
and
write
it
to
flash
before
it
gets
the
whole
payload
and
is
able
to
determine
that
it
has
a
digest
mismatch.
H
So
by
doing
this,
you
burn
a
whole
lot
of
extra
power
and
a
whole
lot
of
extra
flash
cycles.
So
we
want
to
avoid
both
of
these
yeah,
the
the
yes.
I
think
I've
described
that
all
yes,
so
again,
the
the
attacker
capabilities
in
this
case
would
be
either
compromising
a
cdn
or
modifying
the
recipient
list
in
transit
and
the
in
the
last
case.
This
can
be
on
the
same
network
rather
than
as
a
separate
network.
H
Please
so
to
deal
with
the
the
with
the
device
suppression
threat.
H
The
idea
is
essentially
that
the
recipient
list
needs
to
be
signed
now,
each
entity
that
modifies
it
needs
to
sign
it
and
discard
the
old
list
and
the
old
signature,
and
that
way
each
distributor
is
able
to
validate
the
list
of
recipients
on
receipt
and
because
they
they
presumably
can
validate
that
signature
against
a
list
of
known
trust,
anchors
or
entities
that
are
authorized
to
make
those
modifications.
H
H
So
what
I'm
suggesting
there
is
that,
assuming
that
we
accept
the
proposal
to
use
strings
as
as
keys
for
payload
for
integrated
payloads,
and
what
we
would
do
here
is
we
would
have
a
map
of
cozy
sign
objects
and
that
would
give
us
the
ability
to
authenticate
individual
cozy
encrypts
within
the
the
payload
sorry
within
the
envelope.
H
So
you
have
an
envelope
that
contains
a
cozy
encrypt,
that
cozy
encrypt
is
sitting
at
a
string
key
reference
in
the
envelope
and
then
there's
a
a
cosy
sign
which
signs
the
cozy
encrypt
object
and,
as
a
reminder,
the
cozy
encrypt
contains
the
recipient
list.
So
this
allows
there
to
be
more
than
one
signature,
since
there
might
be
more
than
one
cozy
encrypt
and
because
it
lives
at
a
separate
location
in
the
suit
envelope.
This
allows
it
to
be
pruned
in
into
its
entirety
before
it's
delivered
to
a
recipient.
H
Okay
right
so
here
the
the
problem
is:
this
is
the
the
other
side
of
it.
We
want
to
make
sure
that
the
device
doesn't
have
a
doesn't
use
a
invalid
content,
encryption
key,
so
one
option
we
have
is
to
put
the
ephemeral
public
key
into
the
manifest
now.
The
issue
with
that
is
that
that
forces
the
same
use
of
the
same
ephemeral
key
for
all
recipients,
and
the
other
option
is
that
we
could
use
channel
security
between
the
distribution
system
and
the
device
both
of
these
are
have
their
challenges.
H
So
next
slide.
Please.
H
Yes,
oh,
I
think
I
I
got
myself
confused
there.
I
think
I
was
talking
about
the
wrong
thing,
never
mind.
I.
I
still
think
that
we
we
have
the
the
I
can.
I
can
talk
about.
D
Really
quick
one
pack
hpk
yeah,
so
just
just
to
summarize
again,
I
like,
as
we
said,
we
want
to
put
the
cozy
sign
at
the
cosy
encrypt
into
the
envelope.
D
Before
that
we
had
it
in
the
manifest,
and
so
the
digital
signature
covering
the
manifest,
also
authenticated
the
cozy
encrypt,
because
hp
key
provides
also
different
modes,
where
you
can
also
provide
in
authentication
for
sort
of
the
hyper
public
key
encryption.
D
But
in
this
case,
when
we
move
it
out
and
there's
no
signature
covering
the
envelope
itself
for
the
previously
explained
reasons,
and
so
the
issues
is
essentially
unauthenticated,
so
yeah.
So
as
the
challenge,
then,
is
a
distribution
system
or
any
entity
along
the
path.
If
you
don't
use
channel
security,
in
addition
to
it,
can
replace
the
ephemeral
key
and-
and
of
course
can
then
he
like
can
replace
the
entire
cozy
encrypt
structure
all
along.
D
So
that
may
be
maybe
a
problem
there's
a
certain
trust
required
in
the
coming
communication
fabric.
If
you
will-
and
there
are
two
solutions
to
that
like
that
s-
brenton
alluded
to
and
a
they
both
have
sort
of
the
advantages
and
and
disadvantages
of
course,
solution.
D
One
is
sort
of
literally
take
this
ephemeral
public
key
and
place
it
into
the
manifest
where
it
would
be
signed
and
the
other
one
is,
as
as
mentioned,
is
to
use
channel
security
and-
and
of
course,
there
are-
maybe
other
ones
like
authenticating
digital,
for
example-
digitally
signing
the
the
use
of
hp
key
with
the
yeah
already
provided
mechanism.
But
in
any
case,
regardless
of
what
the
solution
is,
there
is
some
a
certain
overhead,
so
that
comes
along
with
it
and
we
should
or
restrict
the
use
a
little
bit.
D
So
we
should
probably
think
a
little
bit
about
how
we
do
that
and
I'm.
I
haven't
myself
settled
on
a
specific
solution.
Myself.
H
Yeah
I've
struggled
with
that
a
bit
and
that's
that's
where
I
came
with
the
the
previous
suggestion
on
the
previous
slide
to
this
one,
where
we
include
a
cozy
sign
for
each
of
the
cozy
encrypts,
but
we
do
it
separately
from
the
cozy
encrypt
so
that
it
can
be
removed
for
final
distribution
to
the
end
device,
so
that
yeah,
I
think,
that's
option.
Three.
B
Since
hanus
was
presenting
and
christian
was
having
connectivity
troubles
and
those
are
our
two
notetakers,
so
we
need
somebody
else
to
step
up
until
christian's
connectivity
gets
back.
D
H
H
The
issue
here
is
that
if
a
an
attacker
were
to
replace
the
ephemeral
key,
then
the
attacker
would
be
able
to
replace
all
of
the
content
encryption
keys
with
ones
that
they
made
up,
provided
that
they
have
access
to
device,
public
keys
and
then
aes
keywrap
would
unwrap
the
content
encryption
key
and
it
would
validate,
and
then
only
when
it
was
used
to
decrypt
the
firmware.
H
H
The
disadvantage
is,
it
does
increase
the
manifest
size
by
one
suit
digest,
and
I
think
that
we
probably
do
need
some
security
analysis
on
exactly
how
dangerous
it
is
to
include
a
how
dangerous
it
is
to
include
a
digest
of
a
content
encryption
key
on
a
or
in
a
signed
container,
since
that
would
possibly
allow
some
kind
of
correlation
attack
that
I'm
not
aware
of,
I
think,
there's
possibly
some
security
analysis
or
cryptographic
analysis
required
there.
H
A
E
I'm
not
sure
I
buy
your
argument,
okay,
but
if
this
is
the
case,
maybe
this
is
the
reason
to
back
up
and
do
the
building
blocks
that
cozy's
already
giving
us,
because
if
we
were
to
do
that,
we'd
be
doing
a
wrap
of
the
cek
and
giving
us
the
integrity
protection
of
it
right
there,
which
would
stop
this
attack
way
earlier
in
the
chain.
H
I'm
not
convinced
the
issue
here
is
that
someone
who
has
access
to
modify
the
ephemeral
public
key
would
be
able
to
modify
the
content
encryption
key.
E
E
H
What
I
would
do
as
an
attacker
is,
I
would
replace
both
the
key
wrapped
key
and
the,
and
I
would
replace
the
ephemeral
public
key,
because
I
replaced
the
ephemeral
public
key.
I
now
control
the
I
now
control
the
shared
secret,
and
thus
I
control.
H
C
H
And
a
new
ephemeral
private
key,
I
use
those
to
create
a
shared
secret
with
the
static
public
key
of
the
target
device.
This
creates
a
new
shared
secret.
I
use
that
shared
secret
to
encrypt
random
data
in
aes
keywrap.
I
replace
the
aes
keywrap
key
with
my
encrypted
random
data,
and
I
replace
the
ephemeral
public
key
with
my
brand
new
ephemeral
public
key
aes
keywrap.
When
you
perform
the
public
key
operations
will
validate
you'll
end
up
with
a
valid
key
according
to
aes
key
wrap.
It
will
just
be
the
wrong
key
right.
E
H
H
G
H
Power
that
costs
me
cycles,
so
I
don't
want
to
do
that,
and-
and
this
puts
us
into
this
corner
case-
that
most
of
your
cryptographers
won't
look
at,
and
that's
that's
where
we
come
up
with
the
these
strange
things
like
what,
if
I
just
put
a
digest
of
my
key
in
then
I've
got
authentication
and
everything's
fine.
E
Yeah
the
problem
is
at
least
in
hsms.
You
can't
digest
that
key.
I
see
fair
enough,
that's
what
that's
what
I'm
struggling
with,
because
the
an
opera,
an
operation
that
says
you
know,
computer
digest
over
the
the
key
register
is
like
okay,
fair.
E
H
So
so
then
the
other
option
that
I've
suggested
down
there,
which
is
encrypt
a
standard,
dummy
value
or
indeed
even
the
unit
vector.
I
don't
know
that
that
would
work
yeah.
So
so
that's
one
of
the
options
that
we
have.
You
know
you,
you
get
an
init
vector
and
a
dummy
value,
and
you
encrypt
that
and
off
you
go.
E
Okay,
I
know
we're
running
out
of
time,
so
if
we're
going
to
have
any
time
for
the
charter
discussion,
we
need
to.
H
B
This
was
the
last
slide.
So,
oh,
it
was
oh
perfect
yeah,
so
we
can
call
it
now
and
move
on
to
the
charter
discussion.
Since
I
think
we've
gotten
through
all
of
this
one
and
I
think,
sounds
like
between
the
three
of
you.
You
know
who's
got
the
act
items
to
do
the
next
steps
on
this
one.
So.
B
All
right,
so
I'm
gonna
stop
sharing.
So
now
we
have
the
charter
text
discussion,
that's
in
the
chairs,
slides
and
I
think
russ.
Do
you
want
me
to
share
the
chair
slides
again
or
do
you
have
it?
I.
E
So
the
only
thing
that
I
think
we
know
going
into
this
already
is
that
if
we're
gonna
break
manifest
into
a
core
document
and
a
bunch
of
extension
documents
which
we
just
talked
about
today-
that's
not
reflected
here
other
than
that
I
don't
know
of
changes.
E
B
B
B
The
the
the
goal
of
this
to
say
is
to
say
by
the
end
of
this
discussion,
we
would
like
to
make
any
updates
based
on
working
of
discussion
and
send
that
to
roman
to
be
approved
or
whatever
for
the
recharter,
which
is
the
process
we
want
to
make
sure
we
can.
We
take
in
any
working
group
input
now,
since
this
has
already
been,
I
think,
on
the
list.
So.
H
E
Gone
so
this
is
pretty
new
and
I
see
a
slide.
H
So
brenda
sorry
yeah
if
we
could
back
up
to
the
previous
slide
sorry,
the
security
threats
and
are
are
primarily
detailed
in
the
information
model
should
that
be
updated.
B
H
Security
threats,
use
cases
or
user
stories
and
and
security
requirements.
E
B
E
This
part
about,
what's
out
of
scope,
is
unchanged.
B
H
So
the
only
things
that
I'm
aware
of
that
we're
looking
at
at
the
moment
are
the
suit
report,
which
is
definitely
a
format
right
and
there's
that
that
would
be
relevant.
To
this
I
mean
the
other
question
on
this.
One
is
whether
we
would
want
to
include
the
discovery
or
sorry
capability
discovery
side
of
the
of
suit
and
whether
that's
a
protocol
or
just
a
format.
I
suspect
it's
just
a
format,
but
that
was
the
only
other
thing
that
sort
of
springs
to
mind.
B
I
I
agree
that
some
could
classify
that
as
a
protocol
and
that
by
itself
might
be
a
sufficient
reason
for
leaving
the
text
in
as
it
stands,
which,
as
russ
pointed
out.
That
text
was
in
there
before
so,
because,
if
you
consider
capability
discovery
a
a
protocol,
then
we
don't
want
anybody
to
say
that
that
is
out
of
scope
so
because
it
wasn't
before
so.
B
Okay,
so
I
I
meant
my
my
suggestion
that
leaving
it
unchanged
is
okay
with
me.
B
I
guess
we
could
say
is
also
defining
formats
and
capability
discovery
mechanism
that
enables
brennan.
What
do
you
think.
H
Yeah,
so
so
the
to
to
be
clear,
the
the
capability
discovery
that
I'm
talking
about
is
maybe
discoveries.
The
wrong
word,
maybe
capability
reporting,
would
be
the
right
way.
To
put
it
essentially,
what
is
needed
is
that
a
manifest
creator,
a
manifest
author
needs
to
know
exactly
what
commands
and
parameters
and
algorithms
are
supported
by
a
given
device,
and
so
in
order
to
do
that,
they
need
to
get
a
document
from
that
device
that
gives
them
a
list,
so
it
I
don't
know
if
that's
a
protocol.
H
I
know
it's
definitely
a
document
so
whether
there's
a
protocol
in
there
as
well
as
to
me,
it's
an
open
question.
B
So
as
long
as,
for
example,
if
you're
only
doing
the
equivalent
of
here's,
how
to
express
the
set
of
what
you
support
in
a
suit
report
right,
whether
you
put
it
in
record
or
something
else,
I'm
saying,
for
example,
if
it's
in
the
suit
report,
then
I
think
it's
just
a
format,
because
you
don't
have
any
way
to
actually
query
it
right,
you're,
leaving
that
to
some
other
mechanism
right.
So
we
talked
about
in.
B
B
All
right,
so
the
first
paragraph
here
we
had
a
discussion
in
the
rats
working
group
yesterday
that
I
led
that
was
about
the
title
was
cheap
requirements
for
eat,
and
the
discussion
is
about
the
how
to
dispatch
the
draft
perk
holes
suit,
dash
rats,
dash
claims
document
right.
The
suit
dash
rats
dot
claims
document
has
some
claims
in
it
that
are
system
properties
that
are
not
really
suit
specific,
and
it
has
a
bunch
of
claims
in
that
document,
which
is
an
individual
submission
right
now,
not
in
any
working
group.
B
It
says
here's
the
number
of
claims
for
eat
that
are
specific
to
suit
purposes
and
and
the
discussion
was
how
to
dispatch
that
document.
Where
should
that
document
go
okay,
because
this
text
here
was
written?
This
first
paragraph
here
was
written
to
say
that
it
would
be
acceptable
if
the,
if
that
was
presented
to
suit,
then
suit
would
be
allowed
to
accept
it.
Okay,
now
the
result
of
that
discussion
on
rats
is
that
I
I
I
don't
know
if
it
was.
B
Consensus
has
not
been
confirmed
on
the
list,
but
I
would
say
the
opinions
of
those
in
the
room
was
that
they
might
want
to
do
those
in
the
rats
working
group
themselves
itself.
Okay,
now
the
rats
working
group
itself
is
not
required
to
have
every
e-claim
be
done
in
the
rats
working
group.
Okay,
just
like
the
dhc
working
group,
doesn't
have
to
have
every
possible
dhcp
option
in
the
dhc
working
group.
B
It
just
has
to
be
able
to
review
stuff,
and
so
whether
you
use
a
decentralized
model
of
development
and
review
by
the
centralized
working
group
or
whether
you
do
stuff
in
the
core
working
group,
it
kind
of
depends,
and
so
here,
if
rats
takes
it,
then
there
might
be
no
document
in
the
suit
working
group
that
we
need
to
do
here.
Other
than
review,
and
so
the
word
specify
here,
no,
the
suit
working
group
will
specify
implies
that
we're
going
to
have
a
milestone
here
right
now.
That
could
go
either
way.
B
H
B
Okay,
I
I
agree
that
that
is
an
option.
I'm
gonna
argue
for
the
option
that
I
gave
why
I
like
that
one
slightly
better.
The
option
that
I
gave
is
we'll
work
with
the
rats
working
group
to
specify
and
the
difference
is
that
one
says
that
is
our
charter
to
make
sure
it
gets
specified,
as
opposed
to
may
means
we
could
choose
to
do
nothing
and
still
be
okay.
B
And
I
think
we
actually
do
depend
on
there
being
things
that
get
done,
and
so
that's
why
I
would
prefer
the
will
work
with
the
rats
working
group
to
specify
and
that
kind
of
leaves
it
ambiguous
as
to
where
the
document
is.
And
then
we
would
leave
that
off
of
the
milestones
in
this
particular
point
of
rechartering,
because
we
can
always
get
roman
to
approve,
adding
a
milestone
once
it
gets
worked
out
to
which
working
group
was
going
to
add
the
milestone.
B
Okay,
roman,
any
comments
on
that.
C
Yeah
I
mean
I
just
put
it
in
chat,
I
mean,
since
I'm
idea
of
both
of
them,
I'm
watching
both
of
it.
I'm
actually
not
so
concerned,
because
it's
clear
that
the
working
groups
are
talking
amongst
themselves
and
we
can
wait.
Let's
just
make
sure
we
have
enough
ground,
so
we
don't
have
to
recharge
her
again.
If
we
choose
a
path,
you
know
that's,
you
know.
That's.
B
G
E
And
then
here's
the
deliverables
that
we
have
that
brandon.
Maybe
you
could
reply
to
the
thread
on
the
on
the
mail
list
and
say
what
what
extension
documents
you
think
we
should
commit
to
besides
the
firmware
encryption,
one
which
is
here
already.
H
Yeah,
so
I
think
really
what
we
need
to
do
is
just
go
through
that
that
separation
work
for
the
for
the
manifest
document
and
what
I
I
don't
want
to
commit
to
exactly
what
that
output's
going
to
be
because
it
might
just
shift
in
the
next
little
while
right
so
milestones.
As
you
said,
we
can
add
them
if
we
need
to
so
the
the
initial
ones
that
I
I
would
suggest
are
the
ones
that
we
had
in
the
previous
discussion
right.
We
have
encryption,
which
I
think
is
already
listed
here.
E
H
We
we
don't
have
the
multiple
trust
domains
document
so
how
to
handle.
When
you
have
more
than
one
trust
domain
for
your
device
and
we
don't
have
an
update
management
document.
So
that's
that's
again,
just
all
those
ancillary
things
you
might
want
to
know
about
if
you're
managing
updates
in
a
slightly
more
complex
way.
H
So
I
think
those
are
those
are
the
ones
now
compression
and
differential
update.
I
still
think
that
one.
I
don't
think
we
have
enough
information
on
exactly
how
it
needs
to
work.
I
I
think
that's
that's
the
problem,
so
do
we
put
it
in
or
not?
Well,
so
maybe
at
this
level.
E
B
C
It's
a
good
idea
to
have
some
marker
in
the
deliverables
or
milestones
if
you
added
new
scope,
but
if
it's
a
case
which
I
feel
like
we
are
right
now,
we
don't
exactly
know
how
it's
going
to
pop
out.
We
can
cluster
cluster
markers
for
future
deliverables
relative
to
that
scope
and
work
it
out,
and
so,
when
we
have
a
better
idea,
we
can
decide
to
kind
of
split
it
and
make
it
a
first
order
milestone
as
needed.
E
B
My
comment
is
going
to
be
on
the
wording
of
the
fourth
bullet
there.
We
need
the
equivalent
wording
to
say,
maybe
just
add
another
sentence
under
the
end.
That
says
this
may
be
done
in
the
suit
or
rats
working
group,
or
something
like
that
just
because
we
have
a
deliverable
to
make
sure
it
gets
done,
whether
we
review
it
or
whether
we
author
it
as
open
so
right.
But
yes,
we
are
at
times
so.
B
All
right
enjoy
the
rest
of
your
ietf
public
service
announcement
for
those
of
you
in
suit
the
teep
working
group.
One
of
the
things
that's
a
presentation.
There
is
suit
examples
for
teep.
If
you
want
to
see
the
examples
of
suit
manifest
and
deep
context
come
to
deep
working
group
in
about,
I
don't
know
two
hours.
I.