►
From YouTube: IETF112-SUIT-20211108-1430
Description
SUIT meeting session at IETF112
2021/11/08 1430
https://datatracker.ietf.org/meeting/112/proceedings/
B
I'll
back
you
up
as
when
I'm
not
talking.
B
Okay,
welcome
to
the
suit
working
group.
We
are
the
second
session
of
this
virtual
itf
welcome
and
want
to
remind
everyone
about.
The
note.
Well,
basically
make
sure
you're
aware
of
your
rights
and
responsibilities
here
before
you
contribute
either
in
writing
or
verbally
next
slide.
Please
I
want
to
remind
everybody
about
the
itf
code
of
conduct,
that's
available
in
rfc
7154.
B
Basically,
please
be
respectful
and
courteous
at
all
times.
Remember
we're
participating
in
personally.
That
means
no
personal
attacks
and
such
and
remember
that
we're
here
to
devise
solutions
that
work
in
the
global
internet,
which
means
that
we
need
to
consider
the
diversity
and
the
operational
environments
that
are
available
and
not
just
one
one
way
that
one
person
uses
the
internet
and
also
be
prepared
to
contribute
in
the
ongoing
discussions.
B
Or
at
least
the
first
slide
of
the
agenda,
put
the
second
one
up
and
then
ask:
are
there
any
bashes?
We
just
heard
from
brendan
that
his
time
went
to
the
documents
on
the
first
slide,
so
we're
basically
have
very
little
to
say
on
items.
Five
and
six.
B
B
Basically,
that's
correct.
The
earlier
item
got
divided
up
into
multiple
documents
and
we'll
talk
about
why?
But
let's
talk
about
the
status
of
the
working
group
recharter,
we
had
a
long
pause.
Sorry,
the
chairs
probably
should
have
nudged
that
sooner
after
coming
to
some
text,
then
we
put
together
some
milestones
and
sent
those
to
roman
roman
has
in
turn
updated
that
to
the
data
tracker
and
had
some
minor
discussions
about
some
word.
Changes
go
ahead,
roman.
D
Hi
everyone
yeah,
I
just
wanted
to
check
it.
I
think
we
are
quite
quite
at
the
cusp
of
being
done
here,
thanks
for
kind
of
the
the
new
milestones
everything's
dropped
in
my
only
remaining
question
before
I
would
hit
the
send
button
is
what
about
a
milestone
on
the
order
of
what
I
just
put
in
chat,
which
says:
let's
put
a
marker
for
when
we
coordinate
with
rats
on
where
the
document
goes.
B
Well,
I
I
think
I
said
in
email.
I
don't
think
that's
going
to
get
away
with
us
in
the
sense
that
right
now
it
looks
like
rats
is
going
to
drive
that
document,
and
so
as
long
as
we
coordinate
with
them,
we
should
leave
the
milestone
to
them.
Was
my
thought
dave?
Do
you
have
any
thoughts.
E
I
I'm
okay
either
way.
I
think
this
is
what's
on
here
right
now
that
roman
was
referring
to
you
can
see
this
bill
is.
A
E
Next
month,
out
for
one
year
with
other
things
there,
so
I
just
wanted
to
call
that
up
on
the
screen
there
and
I
think
roman
you're,
proposing
that
we
have
one
that
is
a
milestone
for
deciding
where
things
go.
Is
that
did
I
get
that
right?.
D
B
A
E
Maybe
I
know
there's
a
couple
other
rats
people
on
here
between
michael
and
folks,
but
if
there's
any
objections
to
that
speak
up.
E
Well,
last
ietf:
we
had
a
discussion
about
a
particular
document
and
we
said:
where
should
that
go
and
we
had
a
discussion
in
both
suit
and
in
rats
about
where
that
should
go,
and
as
at
the
end
of
last
iatf,
the
there
were
two
parts
of
the
discussion.
One
was
some
general
stuff
and
one
that
were
suit.
Specific
claims
and
the
real
discussion
we're
having
here
is
about
the
suit
specific
claims.
Okay
and
so
our
suit
specific
claims
is
that's
the
the
rat's
profile
for
suit.
E
Does
that
go
in
this
in
the
rats
working
group
with
a
cert
working
group?
That's
the
decision,
we're
talking
about
right.
G
So
so
he
either
from
my
management.
Chaos
is
to
do
that
in
rats
of
course,
but
if
there
is
a
feasible
reason
that
we
can,
we
should
split
it.
G
I'm
I'm
willing
to
listen,
but
but
for
for
my
personal
convenience,
I
think
keeping
it
in
one
place
would
be
nice
if
that
rats
are
not
not
against
that.
B
No,
I
I
think
that
the
rats
is
the
right
home
personally,
that's
just
my
thoughts
and
could
be
convinced
otherwise,
but
that
we
want
to
make
sure
this
group
reviews
it,
I
think,
is
where
we're
landing
michael.
H
So
I'm
just
concerned
that
we
think
we
feel
like
we
had
a
conversation
last
time
and
like
that.
What
we
actually
just
need
to
have
is
a
a
20-minute
virtual
interim
between
now
and
march,
probably
before
christmas,
where
we
just
make
sure
that
all
the
people
are
doing
and
have
a
longer
conversation.
H
B
Good
suggestion
we'll
coordinate
with
the
rats
chairs
and
figure
out
how
to
make
that
happen.
I
see
brandon's.
B
I
This
seems
to
me
like
a
bit
of
a
bellwether,
for
what
rats
is
going
to
look
like
going
forwards.
Does
rats
want
to
deal
with
every
single
other
thing
specific
set
of
claims,
or
does
rats
want
that
to
land
in
the
individual
working
groups?
This,
ultimately,
as
near
as
I
can
tell,
is
more
of
an
iana
decision
than
anything
else
we
have
to
register
claim
sets.
So
I'm
a
little
bit
confused
as
to
why
we're
having
this
discussion
at
all.
I
I
thought
it
was
reasonably
clear
that
rats
set
up
the
base,
you
know
draft
and
the
rest
of
its
iana
registrations.
I
don't
understand
what
we're
doing
here.
E
There's
a
suit
profile
and
a
individual
submission
right
now,
that's
a
candidate
for
that
type
of
work
is
a
draft
burkholz
suit
claims
and
the
suit
clean
the
suit
specific
stuff
is
basically
section.
3.2
is
an
example
of
something
that
could
be
used
to
meet
this,
given
that
this
is
individual
summation,
we
can't
say
this
is
ietf
and
stuff,
but
we're
talking
about
the
part
that's
highlighted
here
on
the
screen
is
a
candidate
for
that
and
the
question
is
whether
this
type
of
information
would
be
in
suit
or
unrest.
E
Answer
your
question
brendan
when
the
rats
working
group
was
first
chartered,
there
was
this
discussion
and
an
analogy
was
given
to
things
like
how
the
dhcp
or
jc
working
group
works
where
they
form
the
base,
but
profiles
are
done
on
other
working
groups
with
dhc
being
the
reviewer
of
them,
but
they
don't
do
all
the
options
right
and
so
rats
could
be
the
same
thing
and
that's
the
argument
for
why
this
might
be
done
in
the
seat
working
group
and
why
there
would
be
a
charter
milestone.
E
That's
at
least
a
placeholder
for
the
decision,
if
not
the
actual
work
as
to
whether
a
suit
profile
and
it's
any
claims
specific
to
the
use
of
suit
and
the
applicability
and
security
considerations
around
them
would
be
in
a
document
right,
and
so
this
is
an
example
of
a
document
just
for
everybody
else.
Here
a
lot
of
people
have
looked
at
this,
but
if
you
haven't,
then
this
is
a
placeholder
for
something
that
could
meet
that
work
and
in
this
example,
you
can
see
its
use
of
say
suit.
E
Records
is
one
type
of
thing
that
could
be
in
claims.
There
could
be
claims
about
suit
records
and
not
the
suit
records
themselves.
But
the
point
is:
that's
the
actual
work
that
we're
not
trying
to
have
here.
The
question
is:
which
charter
does
it
belong
in
and
to
your
point,
brenda
there's
a
valid
argument
that
says
that
it
could
belong
in
suit
with
rat's
review,
okay,
and
so
that's
the
discussion
so.
G
Yeah
there
are,
I
have
to
admit,
there
are
less
a
small
amount,
but
but
then
very
universal
claims
here
and
I
think
just
sorting
that
out
is
the
problem
here.
It's
not
it's
not
about
the
registry,
it's
not
about
the
actual,
maybe
not
even
about
the
actual
working
group.
But
it's
it's
about
understanding
what
these
claims
claims
mean
and
and
and
what
scope
they
have
and
and
then
I
think
the
rest
is
just
as
easy,
easy.
E
Yeah
there
was
a
discussion
for
those
who
were
in
the
rats
working
group
earlier.
I
raised
this
at
the
mic
because
there's
some
of
the
parts
of
this
top
part
in
a
hank's
document
that
has
now
been
obsoleted
by
recent
additions
to
the
eat
document,
and
so
an
example
that
I
called
out
in
the
meeting.
Is
this
one
right
here?
There's
now
a
this
is
pulled
into
the
document
itself.
E
Other
things
that
are
in
here
are
things
that
might
be
in
rats
because
they're
generic
not
specific
to
suit,
and
then
other
ones
are
specific
to
suit.
And
so
the
point
is
this
document
right
here
has
a
mix
of
some
things
that
are
suite-specific
and
some
that
are
not,
and
it
could
be
that
the
non-suit
specific
ones
go
into
rats
and
suit
specific
ones
go
into
suit,
but
that's
kind
of
the
ongoing
discussion
so.
E
Although
I
think
the
the
the
topic
of
the
interim
was
about
specifically
about
the
suit
specific
things,
because
my
hope
is
that
the
non-suit
specific
stuff
could
be
worked
out
long
before
an
interim,
if
not
some
of
those
would
be
worked
out
by
friday,
based
on
the
rest
meeting
discussion
of
this
week,
meaning
by
the
end
of
the
ietf
week
here,
but
the
suit
specific
ones,
I
think
having
an
interim
would
be
helpful
for
because,
regardless
of
which
one
it's
in,
we
want
review
from
both
groups
and
having
that
be
a
topic.
E
F
F
To
get
the
the
philosophical
discussion
about
where
these
extensions
should
be
worked,
is
there
any
chance
that
that
will
get
resolved
in
the
rats
meeting
later
this
week?.
E
No,
I
don't
think
so.
Well,
that's
my
opinion
than
all
those
other
rats
people
on
here,
but
that's
because
here
the
question
is
about
the
suit
profile.
My
belief
is,
is
this
my
personal
belief
is
aligned
with.
I
think
what
brennan
said,
which
is
the
rats
working
group
would
probably
prefer
that
profiles
be
done
in
the
working
group.
The
profile
is
for,
in
other
words,
they
would
probably
kick
the
suit
specific
stuff
over
a
suit,
but
that's
me
trying
to
predict
what
they
would
say.
E
F
E
D
Awesome
so
I
will
put
that
in
as
a
milestone
and
then
I
will
submit
it
for
the
isg
for
for
kind
of
for
initial
review,
so
we
can
keep
things
moving
thanks
for
everyone's
help.
Here.
B
Finished
the
working
group-
recharter
summary:
I
don't,
we
don't
have
slides
for
the
hackathon,
but
is
there
somebody
who
wants
to
say
something
about
that?
How
that
went
and
what
we
learned.
A
Hi,
this
is
honest
again
yeah
we
had.
I
gave
a
presentation
at
the
end
of
the
hackathon
week,
which
can
be
looked
up
and
I
will
share
the
link
in
the
chat
window.
Don't
have
that
ready,
don't
want
to
go
through
that
slide
deck,
but
in
a
nutshell,
we
had
a
number
of
folks
showing
up.
We
emmanuel
organized
several
presentations
which
look
at
the
identity
list,
but
some
of
you
attended
for
sure
those
were
good
presentations.
A
They
have
been
recorded
per
request,
so
they
are
up
there
but
also
share
the
link.
Slides
are
available.
A
The
purpose
of
the
presentations
was
to
give
people
a
quick
introduction
into
some
of
the
tools
and
the
code
on
riot
and
the
extensions
made
for
suit
and
point
us
to
the
code
that
brenton
had
been
working
on
et
cetera,
et
cetera,
so
that
was
that
was
pretty
good.
We
had
some
hacking
events
as
well
on
different
fronts,
so
it
was
a
little
kept
all
over
the
place
with
regards
to
activities.
The
links
to
the
code
are
also
in
the
slide
deck.
A
A
A
So
you
have
to
be
extremely
disciplined
to
actually
follow
things
through
and
but
I'm
still
hoping
either
that
we
switch
over
to
face-to-face
hackathons
again
or
that
we
sort
of
sort
of
become
very
creative
in
organizing
those
given
the
time
zone,
differences
and
all
the
other
problems
so
yeah,
but
in
if
any
one
of
you
has
interest
to
look
at
the
code
and
or
have
some
questions
on
on
the
presentations
or
anything
else,
just
drop
me
an
email
or
or
emmanuel
in
this
case
as
well.
A
He,
since
he
has
been
helping
to
organize
the
this
hackathon
event
on
suit
and
deep
and
etc.
I
I'm
I'm
sure
we
can
help
hey
honestly.
A
Yes,
give
me
a
second
to
look.
It
up
sure
thanks.
B
Seeing
any
questions
so,
let's
go
to
brandon.
I
Hi,
so
I
guess
next
slide.
Please
you're
also
invited
to.
I
Oh
yeah,
I
can
do
that
can't
I
I
have
terrible
wi-fi
at
my
house,
so
this
is
a
a
strange
and
and
new
experience
that
I
can
actually
use
video
again.
Okay,
so
the
key
changes
for
for
suit
manifest
16
are
essentially
what
we
discussed
last
time
in
ietf
111.
I
The
the
most
important
thing
that's
changed
is
that
we
have
broken
the
manifest
document
apart
into
four
or
theoretically
five
different
drafts,
the
fifth
draft
I'll
mention
briefly
later
on
what
it
would
be
if
it
existed,
but
it
doesn't
exist.
I
So
that's
that's
the
primary
bit
of
the
work
there's
also
two
minor
changes
that
were
added
in
the
integrated
element
keys,
so
that
would
apply
to
integrated,
payloads
and
integrated
dependencies.
I
Those
are
both
have
minor
changes
I'll
get
to
that
in
a
minute,
and
then
there's
the
uri
definition
and
that's
had
a
minor
change
as
well.
Next
slide,
please.
I
So
what
is
covered
in
the
core
document
now
is
the
authentication
basic
flow
control,
so
the
try,
each
and
multiple
components,
mechanisms
parameter
setting,
but
only
override
parameters,
and
the
reason
for
that
is
that
set
parameters
should
not
be
necessary
unless
you
have
multiple
manifests,
and
this
doesn't
cover
multiple
manifests,
severable
members,
so
that's
the
elements
being
taken
out
of
the
manifest
and
placed
in
the
manifest
envelope
and,
finally,
the
text
description.
I
I
Similarly,
dependency
manifests
are
covered
in
trust,
domains
and
multiple
suit
processors
are
covered
in
trust
domains,
the
the
multiple
suit
processors.
Just
as
a
reminder,
oh
no,
that
that'll
come
up
in
a
later
presentation.
I'll
leave
that
for
now
payload
transforms
are
the
one
thing
that
doesn't
have
a
a
dedicated
document.
We
do
have
one
for
encrypted
firmware,
but
we
don't
have
one
for
any
form
of
compression.
I
We
do
the
the
conditions
for
managing
updates
and
directives
and
metadata
for
managing
updates
are
in
the
separate
update
management
specification
or
individual
draft.
I
mean
so
that's
that
those
are
up
and
coming,
but
they
are
not
covered
in
the
core
specification
anymore.
So
those
things
are
no
longer
right
in
the
core
which
will
hopefully
simplify
it
substantially.
I
The
integrated
element
keys,
so
I
mentioned
I
alluded
to
this
earlier,
but
the
the
idea
here
was
that
the
original
specification
had
a
somewhat
cumbersome
mechanism
for
referring
to
integrated
elements.
So
if
you
had
an
integrated
payload,
you
had
to
use
a
fragment
only
reference
uri
and
that
fragment
only
reference
had
to
be
a
number
and
that
number
had
to
convert
to
a
specific
range
of
integer
and
that
on
doing
it
that
on
constrained
devices
seemed
like
it
was
more
cumbersome
than
necessary.
I
So
this
change
says
that,
instead
of
doing
that,
it
will
be
direct
text
string
matching.
So
you
have
a
text
string
key
for
your
integrated
element,
which
guarantees
that
it
won't
collide
with
any
future
extensions
and
that
text
string
will
be
identical
to
the
text.
String
reference
that's
placed
in
the
uri
field,
so
the
the
one
additional
thing
that
this
enables,
which
is
hopefully
useful,
is
that
a
an
intermediary
can
pre-fetch
a
payload
and
embed
it
in
the
manifest
envelope.
I
And
then,
as
long
as
a
device
knows
to
start
by
checking
the
the
manifest
envelope
for
the
appropriate
text
string
and
then
perform
a
remote
fetch.
Then
precaching
can
be
done
in
a
relatively
straightforward
way.
I
I
So
we
have
a
few
open
issues
at
ietf
111.
We
discussed
the
need
for
more
more
information
on
implementation,
overhead
for
hierarchical
hash,
based
signatures.
I
One
of
the
pieces
of
information
was
verification
time
and
thanks
to
the
work
done
by
emmanuel's
group,
we
know
that
the
verification
time
is
roughly
on
the
order
of
one
third
of
an
ecdsi
verification
and
it's
slightly
longer
than
an
ed
dsa
verification,
and
we
don't
really
know
why
this
is
yet.
As
far
as
I
know,
but
I
would
one
of
the
possibilities
is
that
libraries
are
frequently
optimized
for
performing
one
long
hash
rather
than
many
small
hashes.
I
The
pro
the
single
biggest
problem
with
ecdsa
is
that
it's
not
quantum
resistant,
the
benefits
it
has
are
mature
or
well,
primarily
the
maturity
of
the
tooling,
the
long
verification
time,
obviously
not
a
benefit
for
hss
lms.
The
the
biggest
detractors
it
has
are
probably
that
it's
got
relatively
immature
tooling.
It
itself
is
not
immature.
I
Just
the
tooling
the
private
keys
require
ongoing
maintenance,
which,
which
essentially
means
that
after
each
signature,
the
private
key
needs
to
be
updated
and
there's
only
a
fixed
number
of
signatures
possible
and
signature
sizes
are
at
least
a
kilobyte.
That's,
in
fact,
this
thing
is
1280.
Bytes
is
the
bare
minimum.
I
I
So
we
need
to
also
discuss
what
we're
going
to
do
for
optional
to
implement.
Algorithms
rsa
has
been
requested,
but
I
think
that
we
should
be
very
careful
about
permitting
that,
given
some
of
the
research
that's
going
on
in
that
area,
there's
also
a
question
as
to
whether
we
should
have
failover
options
for
digest
algorithms,
particularly
where
boot
loaders
are
concerned.
This
becomes
a
really
big
question
about
whether
we
can
actually
afford
to
have
any
crypto
agility.
I
So
I'm
looking
for
advice
or
or
input
or
recommendations
on
the
topic
of
crypto
agility
and
constrained
devices.
So
that's
that's
a
an
open
question.
If
that's
anything
that
we
can,
if
there's
any
advice.
A
I
B
So
a
good
bit
of
our
crypto
agility
comes
from
just
using
the
cose
constructs.
The
registries
already
exist,
but
we
do
need
to
have
mandatory
implements.
I
think
the
may
implements
are
anything
else.
That's
registered.
I
But
when
we
look
at
the
constrained
environment
where
there
are
certain
parts
of
the
of
the
device
that
simply
can't
be
updated,
like
you
know,
wrong
boot,
loaders
or
or
early
stage
processes,
we
really
need
to
be
careful
about
what
gets
mandated
and
I
think.
I
With
with,
on
the
subject
of
that,
with
mcu
boot
in
the
past,
as
well,.
E
Well,
I
have
a
question
and
I
don't
know
whether
the
question
will
help
or
not,
and
it's
not
a
preference.
It's
actually
a
question
because
there's
a
couple
things
that
we
could
do,
but
when
we're
talking
about
mandatory
to
implement,
let's
just
go
back
a
slide,
because
this
is
the
mandatory
to
implement
question
on
this
one,
because
the
ones
are
talking
about
optional
implements.
E
So
one
way
there's
a
couple
different
approaches
you
can
take
with
doing
mti
because
you
have
to
say
it's
metroid
implement
for
whom,
right,
because
in
the
suit
there's
at
least
two
at
least
two
roles,
arguably
more
right,
there's
the
manifest
author
and
there's
the
manifest
consumer
and
maybe
there's
a
manifest
intermediary,
depending
on
whether
you
count
that
you
count
that
as
opaque
is
that
is
that
suit
enlightened
in
any
way,
whether
there's
a
third
role
or
not,
maybe
depends
okay
and
so
mandatory
to
implement,
for
whom
right
so
for
some
classes
of
protocol.
E
You
say
you
can
say
that
the
same
thing
is
mandatory
to
implement
on
both
ends
right
and
for
other
examples
is
where
you
have
multiple
possibilities
on
one
end,
sorry
notice
pick
one
on
one
end
and
multiple
that
are
collectively
mandatory
to
implement
on
the
other
end,
and
so,
for
example,
and
again
this
is
not
a
recommendation.
This
is
part
of
the
question
you
could
say
that
both
of
these
are
mandatory
to
implement
on
authoring
sides
and
the
consuming
side
gets
to
pick
one
or
some
other
variation
right.
E
I'm
saying,
as
long
as
you
can
guarantee
that
that
author
and
a
a
parser
can
talk
to
each
other,
there's
multiple
ways
to
accomplish
that
right
and
so
the
question
the
working
group
is:
do
we
want
to
pick
one
for
all
roles,
or
do
we
want
to
allow
different
roles
to
have
different
ways
of
phrasing?
The
question,
in
other
words,
multiple
possibilities
versus
multiple
required
mandatory
implement,
and
so,
which
way
do
we
want
to
frame?
The
question
is
the
question
that
I
have
to
the
working
group
so.
E
I
bring
that
up
only
because
of
brennan's
last
point
about
constrained
devices
right,
if
you
said
well,
some
constrained
devices
could
only
do
you
know
ecdsa,
because
they're
immediate,
they
need
mature,
tooling.
Other
constrained
devices
might
only
be
able
to
do
the
other
one,
because
the
verification
time
is
lighter
or
whatever
is
that
a
blocker
to
make
them
be
mandatory
to
implement
on
a
per
use
case
basis
and
say,
authors
have
to
be
capable
of
doing
either
of
them.
There's
just
different
ways
to
skin
it
right
which
way
do
we
want
to
craft?
E
Strange
implementations-
I
don't
know
if,
like
david
brown
or
anybody,
has
a
particular
opinion
on
this
one.
I
J
F
I
I
think
that
the
idea
here
is
that
we
we're
trying
to
set
the
target
for
interoperability.
I
mean
it
seems
like
on.
You
know
david
based
on
your
your
comment
that
we're
either
going
to
end
up
with
non-compliant
solutions
or
non-interoperable
solutions,
or
both
you
know,
based
on
some
of
the
resource
constraints.
I
think
what
we're
trying
to
accomplish
through
this
is
at
least
trying
to
define
a
baseline
for
interoperability,
which
I
think
is
the
best
that
we
can
do.
H
H
Assuming
this
was
the
manufacturer,
not
someone
who
operates
the
network.
They're
gonna
put
the
algorithm
that
trust
anchors
into
the
right
for
because
you
can
also
keep
it.
So
you
can
argue
a
lot
about
what
is
the
mandatory
to
implement
from
what
we
would
like
to
see
out
there.
What
we'd
like
to
recommend
but
trust
banker,
is
not
there,
then
it
doesn't
matter
and
that
that's
within
the
ability
of
the
organization
who
built
the
device
to
defy
and
coordinate
without
our
health,
our
health.
H
So
I
think
strongly
that
we
should
say
pathway
signatures
should
be
the
mandatory
implement
in
our
document
and
there,
where
very
well
may
be
non-compliant
implementations
out
there
for
a
while
and
that
perhaps
what
will
push
this
you
know
commit
for
tooling
forward,
and
I
don't
see
another
way
and
I
don't
really
see
any.
I
don't
think
you're
doing
any
other.
E
K
Yeah,
I
just
it's
for
the
mandatory
or
requirement
anything
goes
into
suit,
it's
going
to
be
mandatory
automatically
for
the
tip
and
if
it
is
going
to
have
any
mandatory
required
algorithm,
it's
it's
automatically
going
to
be
in
the
requirement
for
the
tip.
So
I
prefer
suit
keep
eat
not
selecting
different
mandatory
orgasm
yeah
that
that's
all.
C
I
Question
we
we
had
a
discussion
previously
about
how
we
specify
capability
reporting,
and
I
forgive
me
I
don't
actually
recall
no.
I
have
not
submitted
a
draft
on
capability
reporting,
but
that
is
something
that
I
think
we
should
probably
do.
Does
this
discussion
of
mandatory
to
implement
become
irrelevant
if
we
specify
a
capability
reporting
system,
can
we
just
get
away
from
worrying
about
it
at
all.
K
E
If
the
type
of
system
that
could
run
the
binary
that
you're
referencing
is
the
one
that
has
the
algorithm
that
you
know
of,
and
you
and
you
can,
and
as
the
author,
you
can
correlate
that
information,
then
you're
crafting
an
internally
consistent
suit,
manifest
and
so
whether
it
becomes
irrelevant.
I
don't
know.
I
think
the
real
requirement
is
that
you
can
craft
a
suit,
manifest
it's
consistent
with
the
type
of
entity
that
could
actually
run
the
thing
being
expressed
by
the
suit
manifest.
E
Consumer
okay,
so,
while
I'm
at
the
mic,
let
me
just
finish
what
I
was
going
to
say
and
then
I'll
pass
it
to
david
brown.
I
think
the
the
only
case
that
I
can
think
of
where
my
previous
statement
doesn't
hold
is,
if
you
do
have
say,
an
intermediary
that
does
things
with
suit,
manifest
without
being
able
to
without
being
able
to
do
the
the
binary
itself
right.
It's
just
the
forwarder,
but
it
may
do
things
like.
E
J
We
have
a
some
consist
configurations,
we're
considering
where
the
device
that
is
being
updated
may
not
be
network
connected,
and
there
is
a
you
might
call
it
a
helper
device,
an
intermediary.
It
may
be
something
on
us:
the
same
board,
that's
a
more
powerful
processor
that
it
needs
to
be
able
to
take
this
firmware
blob
in
this
manifest
and
kind
of
pass
it
through,
and
it
would
be
nice
if
it
was
able
to
verify
the
signature,
and
you
know
not
do
operations
that
are
unnecessary.
J
Does
that
mean
now?
Do
we
just
have
three
parties
and
we
need
to
make
sure
they
all
agree
on
what
algorithm
is
done
there
that
you
know
when
it
really
comes
down
to
it?
It
is
up
to
just
the
parties
participating
the
people,
making
the
firmware
and
the
device
needing
to
agree
on
this,
and
I
mean
that's
practically:
that's
how
we're
doing
it
now
you
when
you
build
mcu
boot,
you
pick
the
signature
algorithm,
that's
used
and
you
better
sign
it
with
that
same
one
or
it's
not
valid.
F
So
I
just
want
to
just
as
chair.
I
want
to
understand
what
we're
actually
saying
here.
So
I
think,
I
think,
what's
being
said,
is
that
there
there
are
multiple
parties
that
may
be
working
together
in
an
ecosystem,
and
I
think
what
we're
suggesting
is
that
the
signature,
algorithm
or
algorithms
that
get
implemented
within
a
given
ecosystem
will
effectively
be
sorted
out
by
those
parties,
and
because
of
that,
we
don't
need
an
mti.
Is
that
is
that,
what's
being
said,.
E
I
think
what
I
was
concluding
is
that,
because
you
can
have
these
the
middle
entities
such
as
a
cosigner
type
of
a
role
right,
which
is
not
you,
know
the
destination,
that's
not
running
the
suit
manifest,
but
I
may
have
to
parse
the
suit
manifest
construct,
one
that
references
it
or
construct
a
derivative
that
replaces
it
whatever
it
is
right
and
so
for
that
I
think
having
mti
is
important.
So
I
guess
my
straw
man
from
what
I've
heard
so
far.
E
Not
strong
is
that
constrained
devices
can
pick
either
ecdsa
or
hss
lms,
but
must
pick
one
of
those
two
to
be
to
claim
compliance
and
that
authors
and
cosigners
and
things
must
implement
both
so
both
the
branditory
implement
on
the
other
roles,
that's
kind
of
where
I'm
arguing
and
I
think
that's
what
would
give
interoperability
for
scenarios
like
co-signing
and
so
on,
and
you
know
referencing
dependency
manifests
and
so
on,
but
still
leave
the
freedom
to
constrain
devices.
F
E
Case
you're
asking
me
my
proposal,
and
so
I
will
answer
my
opinion.
What
the
rest
of
the
working
group
says,
I
can't
say,
but
my
opinion
is,
if
you're
a
manifest
author,
that's
authoring
something
for
a
particular
device.
You
might
think
you
know
what
that
device
has
okay,
but
if
the
actual
device
is
not
going
to
process
your
manifest,
the
actual
one
is
going
to
process
because
you
may
not
know
the
actual
device
you're
doing
it
for
a
class
of
devices.
The
actual
device
might
do.
One
that's
done
by
a
counter
signer.
Instead.
A
E
You're,
the
manufacturer
of
the
software
or
something
so
you
construct
one,
but
the
administrator
of
the
device
says
I'm
actually
going
to
parse
that
myself
and
I'm
going
to
replace
it
with
my
own.
That's
the
counter
sign,
because
I've
got
the
signature,
he's
actually
going
to
trust
right
and
so
the
only
entity
that
parses
it
might
not
actually
be
the
device.
And
so
that's
my
argument
for
why
mtis
are
important,
even
if
you
think
you
know
the
device
so,
but
I
see
michael
is
in
queue.
So
maybe
you
have
a
better
idea.
H
I'm
just
going
to
say
that
you,
I
hope
my
audio
is
better
my
that
I
think
you
captured
what
I
was
strongly
agreeing
with,
but
the
the
the
the
subset
issue
is
that
the
author
knows
what
the
manufacturing
author
knows:
what's
available,
they're
not
going
to
go
outside
of
that
list
period!
Okay,
it's
not
even
about
guessing.
They
constructed
the
device
to
know
what's
available
period.
H
H
Finally,
I
would
say
that
I'm
not
sure
I
would
say
eastbay
and
a
test
and
and
hash
based
signatures.
It's
too
hard
to
pronounce,
but
are
a
must.
I
actually
would
say:
east
pds
day
is
a
should
and
the
case
where
you
shouldn't
use.
It
is
when
it's
been
defeated
or
you
don't
have
code
space
for
it
right.
F
I
think
we're
on
on
that
topic,
though
I
think
we're
rehashing
a
little
bit
about
about
what
we
talked
about
on
in
at
iatf
111.
You
know
we
did
a
a
poll
and
we
talked
about
you
know
the
two
and
there
was
strong
consensus
towards
if
we
had
a
single
one,
a
single
mti
to
to
to
make
the
hash
based.
You
know
the
the
mti.
I
think
that
was
largely
driven
by
the
discussion
around
quantum
resistance,
so
we
wanted
something
that
would
last.
E
I
guess
as
chairs,
are
we
ready
to
say
that
we
have
between
this
discussion
and
the
discussion
we
had
at
there
that
you
were
just
summarizing
david?
Are
we
saying
that
that
is
the
proposed
consensus?
Let
us
know
if
we've
misread
consensus.
E
Ira
asks
a
question
in
the
chat
about.
Why
would
why
ecdsa
being
issued
rather
than
e-d-d-s-a
is
the
question.
I
Right,
well,
I
I
mean
from
that
perspective,
perhaps
we
need
to
have
a
few
more
options
available
in
the
optional
to
implement.
E
Yep,
so
I'm
just
doing
time
check
we're
at
15
minutes
after
the
hour
now.
Do
you
want
to
go
on
to
the
next
presentation?
Now
I
think.
Maybe
this
is
one
for
the
list.
B
A
Okay,
cool
yeah,
so
this
is
a
short
update
on
the
firmware
encryption.
We
had
a
good
discussion
at
the
last
iedf
meeting
and
there
were
two
main
aspects
there.
One
was
to
take
the
hp
key,
the
hybrid
public
key
encryption
and
make
that
a
standalone,
cozy
method,
which
we
did
there's
a
separate
document
available
and
that
would
be
discussed
in
the
cosi
working
group.
A
I'm
not
going
into
the
details
so
essentially
was
extracted
content
from
the
suit
working
group
document
that
was
brought
into
this
one
and
the
other
thing
was.
We
had
two
attacks
listed
and
in
the
presentation
from
the
last
itf
meeting
and
those
or
the
the
mitigations
of
those
have
been
incorporated
into
this
version,
and
I
have
two
slides
that
talk
about
those
just
as
a
summary
on
what
the
solution
is.
A
The
first
one
was
an
issue
with
sort
of
had
to
put
the
sort
of
the
the
content
of
the
encryption
information
because
it
had
to
be
in
the
envelope,
and
so
it
couldn't
be
the
manifest.
So
that's
what
we
what
we
did.
This
is
essentially
something
that
was
carried
over
from
brenton's
presentation
about
the
document.
Split
so
conceptually
this
was
in
the
the
suit
manifest
are
just
in
a
different
language.
I
would
say
so.
A
This
is
just
essentially
the
suit
encryption
input
tag
in
the
envelope.
The
envelope
as
a
reminder
is
not
protected
by
the
digital
signature
itself,
but
it
manifest
this
okay
next
slide.
A
And
the
other
one
was
about
a
verification,
I'm
sort
of
mechanism
to
allow
the
prevention
of
battery
exhaustion.
So
when
the
device
receives
the
firmware
update,
it
wants
to
perform
as
little
operations
as
possible
to
determine
whether
the
payload
it
receives
is
actually
correct,
or
it
has
been
properly
signed
and
properly
encrypted.
A
In
this
specific
case
actually,
and
so
what
we
did
here
isn't
and
there's
still
a
dupe
down
here,
but
there
in
a
nutshell,
the
idea
is
that
there's
a
this,
a
byte
sequence
in
the
manifest
that
is
where
we
apply
the
content,
encryption
key
on
a
string
of
eight
bytes
with
a
specific
character
like
this.
In
this
case
hex
a5.
A
It
doesn't
really
matter
what
it
is,
but
that
allows
the
consumer
to
check
with
the
keck
that
it
got
whether
this
this
string
actually
decrypts
properly.
So
the
only
open
issue
here
is
what
I
need
to
use
and
that's
in
the
document,
that's
something
we
still
have
to
hash
out,
but
yeah,
okay,.
A
Good,
so
so
this
was
sort
of
the
current
sort
of
updates
and
the
approaches
for
addressing
the
threats
that
we
talked
about
last
time
and-
and
we
also
talked
about
different
solutions-
and
this
is
one
of
them.
So
please
have
a
look
at
this
there's
also
a
code
for
the
hb
key
which
I
created,
and
I've
also
been
working
on
a
cozy,
the
corresponding
cozy
code,
which
I
need
to
clean
up
and
and
will
be
published
out
soon.
A
What
we
are
still
lacking
is
interrupt
testing
on
this
functionality,
unlike
for
some
of
the
other
features
in
the
main
specification
which
which
we
have
tested
already-
and
I
I
just
talked
about
this
open
issue
a
second
ago
and
yeah-
that's
that's
all
there
is
so
I
I
hope
the
discussion
in
the
cozy
meeting
goes
well,
so
that
we
can
then
reference
this.
Of
course
there
will
be
changes.
A
E
Okay,
so
those
are
two
current
working
group
documents,
the
other
two,
although
they
came
split
out
of
a
working
group
document,
their
current
individual
submissions,
do
we
have
a
preference
between
the
other
two
which
one
to
cover
given
that
we've
got
eight
minutes
left
here
between
trust
domains
and
update
management.
I
B
I
I
I
observe
that
you
told
us
the
the
thinking
behind
the
split
out
in
your
previous
presentation,
so
I
think
we
leave
it
to
brendan
to
tell
us
where,
where
the
open
issues
might
lead
to
more
group
participation.
I
Yes,
please:
okay,
go
ahead!
All
right
next
slide,
please!
I
Oh
right
video!
So
essentially,
this
is
simply
just
an
export.
It
contains
the
delegation
chains,
dependencies
and
multiple
suit
processors
and
unlinked
directive.
Next
elise.
I
There
is
a
dependency
from
t
on
this
particular
draft,
although
I
don't
know
if
that's
been
declared
yet
it's
just
the
things
that
I
know
t
depends
on
got
moved
to
this
draft
next,
please
so.
Delegation
chains
are
essentially
just
a
list
of
lists
of
sibor
web
tokens.
The
idea
behind
this
is
that
in
each
list
the
first
element
is
a
cwt
that
can
be
verified
against
a
trust
anchor
and
the
last
element
is
contains
the
key
that
you
can
use
to
verify
a
manifest.
I
I
Dependencies,
so
these
are
a
fundamental
component
of
suit
or
word
and
they've
heavily
influenced
the
design
of
suit.
This
is
why
suit
has
multiple
sections
rather
than
one
single
list
of
elements
it
should
or
one
single
list
of
things.
It
should
do
this.
Essentially,
it
was
for
dependency,
lock,
step
processing
that
was
the
the
the
suit
command
sequences
were.
I
Like
that
and
there's
all
the
the
requirements
of
dependencies
that
come
with
that
and
it's
also
necessary
to
support
encrypted
manifests,
I
think
that's
an
important
thing
to
recognize
next
slide.
Please
so
integrated
dependencies
are
when
a
dependency
is
placed
in
the
suit
envelope,
and
that
will
be
probably
how
encrypted
manifests
are
typically
delivered
and
those
are
covered
in
this
document
as
well,
and
they
have
the
same
reference
semantics,
as
I
described
for
integrated
elements
in
the
previous
presentation.
Thanks.
Please.
I
Multiple
suit
processors
are
also
covered,
and
that's
when
you
have
multiple
mutually
distrustful
man
processing
environments
in
a
single
device
in
in
the
classic
iot
case.
The
most
likely
thing
I've
encountered
is
a
radio
module
that
has
a
signature
of
its
own
firmware
and
that
is
signed
by
a
different
trust
anchor
than
the
the
app
the
the
firmware
for
the
application
which
is
running
on
a
separate
processor.
So
the
idea
behind.
I
The
unlinked
directive
was
specifically
requested
by
by
t
I'm
not
sure
if
it's
quite
in
the
right
form
and.
I
Have
a
debate
about
that
within
the
discussion
this
week,
but
that's
also
covered
in
this
document
next
slide.
Please.
E
Yeah,
I
just
want
to
give
a
quick
ad
here
that
the
teep
session
is
the
first
session
on
friday
morning
and
so
that
one,
the
teep
session
will
be
discussion
of
the
use
of
suit
in
teep,
akira
and
ken
are
both
here
in
this
meeting
and
they
both
filed
issues
relating
to
suit,
manifests
and
teep,
and
so
I'd
like
to
encourage
everybody
that
wants
to
follow
this
topic.
E
Also,
please
come
to
that
meeting,
because
we're
not
gonna
have
time
to
discuss
it
here,
but
there
may
be
time
in
the
tea
meeting
on
friday.
So.
I
So
then
there
is
just
the
question
of
the
open
issues.
We
don't
have
any
running
code
for
most
of
it.
I'm
concerned
that
we're
using
about
whether
or
not
we're
using
the
seaboard
web
tokens
correctly
and
yeah
any
contribution
would
be
massively
welcome.
E
E
Both
of
these
have,
I
think,
content
that
was
originally
pulled
out
of
the
original
suit,
manifest
document
so
that
we
could
take
the
original
one
as
the
minimum
one
and
go
to
rfc
as
soon
as
possible,
and
I
think
none
of
the
content
was
pulled
out
of
there,
because
people
objected
it
to
having
it
be
in
suit,
and
so
I
guess
the
proposal
that
I
would
have
would
be.
E
Are
there
any
objections
to
taking
both
of
these
documents
and
adopting
them
as
draft
ietf
rats
documents
to
put
them
back
as
official
working
group
documents
which
they
were
before
right?
That's
the
that
should
be,
I
believe,
the
next
step.
I
just
want
to
verify
that.
There's
no
objections
to
that
yeah
draft
ietf
rats.
Thank
you,
michael.
E
K
E
Yeah,
we
don't
need
an
adoption
call
just
asking
for
objections,
because
it
was
our
content
was
already
adopted,
yeah,
okay,
so
I
think
we're
now
out
of
time
and
so
any
further
discussion
on
this
one
in
particular,
since
this
is
stuff
that's
used
by
teap.
Some
of
this
will
be
in
scope
for
discussion
on
friday.
So
again,
please
come
to
the
discussion
on
friday,
first
agenda
slot
or
first
meeting
slot
on
friday.
So
thank
you.
B
Just
brendan
post
the
the
documents
and
we'll
approve
them,
yeah.
I
So
I
should
I
should
repost
them
as
draft.etf,
then.