►
From YouTube: IETF114 SUIT 20220728 2000
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
This
meeting,
usually
rule
of
thumb,
is
working.
Group
documents
beat
documents
that
are
not
working
group
documents,
and
so
we
let
the
working
of
documents
expand
time
and
don't
call
time,
because
we
usually
have
a
bunch
of
individual
documents.
Now
that
most
of
our
documents
are
working
group
documents,
we
can't
follow
that
right
now,.
B
By
thursday,
you
probably
know
the
note
well
already,
but
this
is
the
rights,
privileges
and
responsibilities
as
participants.
Please
follow
the
code
of
conduct
and
treat
each
other
with
respect.
In
addition,
you
need
to
wear
a
mask
in
this
room
unless
you're
on
the
pink
axe
by
the
presenters
mike,
and
we
just
did
the
administrative
tasks.
So
I'm
going
to
skip
that
so
the
agenda,
we
have
a
long
agenda
today,
for
it
seemed
like
two
weeks
ago
we
were
not
gonna
have
any
presentations,
and
now
we
have
nine.
B
So
this
is
the
first
page
of
the
draft
agenda
and
here's
the
second
page
any
bashes
to
that
agenda.
It's
the
same
one,
that's
posted.
C
A
B
A
The
switch
is
on
all
right
one,
two
three:
now
it's
on
all
right,
great
all,
right,
hackathon
report:
we
had
a
combined
cose
suit
t
hackathon
table
with
a
bunch
of
participants
listed
there,
I'm
going
to
go
through
that,
go
through
this
pretty
quickly.
Until
we
get
to
the
two
issues
to
report
on
go
ahead
next
slide,
there
was
a
bunch
of
issues
that
were
filed
during
the
hackathon
the
whole
set
on
the
top.
A
I
am
not
going
to
talk
about
because
they're
trivial
grammar
stuff
and
are
pressed
for
time,
so
only
mention
the
bottom
two.
The
bottom
two
have
a
slide
on
each
of
them,
so
that
means
only
real
two
slides
of
content.
So
first
one.
So
if
you
have
issues,
go
and
read
through
those
all
right.
First
question
that
we
had
at
the
at
the
tpackathon
was:
it
came
up
as
far
as
teep
trying
to
implement
the
suit
manifest
okay,
so
the
eat
profile
previously
used
software
name
and
software
version
claims.
A
But
we
observed
that
those
were
meant
for
human
readable
strings.
Okay,
they
were
not
necessarily
machine
readable.
So,
for
example,
there
was
nothing
to
prevent
somebody
from
patching
a
binary
and
then
just
not
updating
the
human
readable
string
right.
So
it
wasn't,
you
know,
cryptographically,
you
know
bound
to
anything.
So
that's
the
wrong
thing
and
so
lauren
said
you
probably
want
to
use
the
manifest
claim.
So
that's
what
we
did
in
in
t.
Okay,
the
only
issue
with
that
is
that
currently
the
manifests
claim
requires
a
full
suit,
manifest
right.
A
So
manifest
format
allows
you
to
have
a
suit
envelope
and
we
said
we
would
like
to
be
able
to
do
that
without
having
the
entire
suit
manifest,
and
is
there
a
way
to
do
that?
That
was
the
question
raised
and
we
filed
this
issue
for
that.
For
that
it
says:
okay
for
the
manifest
format.
We've
got
a
content
type
as
long
as
you
have
something
to
fill
into
a
content
type.
That
means
it's
a
reference.
You
could
do
it
even
without
a
suit
envelope
right.
You
could
use
something
other
than
the
suit
envelope.
A
So
example,
during
the
hackathon
here
was
a
proposal
that
was
submitted
as
a
per
request
to
say:
okay,
alternate
version,
the
manifest
body
is
not
a
suit
envelope.
It's
a
suit
reference,
which
has
like
a
uri
and
a
manifest
sequence.
Number
and
brennan
was
online.
We
went
back
and
forth
and
said
this
kind
of
thing
might
make
sense,
okay
and
so
right
now.
The
proposal
is
to
maybe
add
this
to
the
update
management,
which
is
on
the
agenda
later
and
of
course
this
would
require
a
co-op
content
format,
value
to
mean
that's
the
format.
A
Second
issue
that
came
up
and
so
by
the
way,
if
we
want
to
defer
discussion
on
that
to
the
update
update
management
document,
we
could
do
that,
but
that
was
one
thing.
We
followed
one
issue
that
we
ran
into
when
implementing,
and
so
we
filed
the
issue
and
say
we
should
really
discuss
a
part
of
that
document.
A
Second
issue
that
we
ran
into
was
having
a
suit
parameter
for
the
manifest
sequence
number.
So
the
t
query
response
has
now-
and
this
is
now
in
draft
10-
has
system
property
claims,
although
in
teep
there
was
a
question
about
whether
this
is
right.
A
But
this
is
what
draft
10
says
and
so
in
the
suit
report,
and
now
in
the
deep
query
response
you
can
have
this
little
blob
of
suit
system,
property
claims
which
has
a
suit
component
identifier
and
one
or
more
suit
parameters,
and
this
parameter
is
defined
in
in
one
of
the
documents
that
covers
things
like
image,
digest
size
and
so
on,
but
there's
nothing
that
has
the
manifest
sequence
number
to
put
in
there
right.
So
the
manifest
document
allows
you
to
have
suit
manifest
suit
parameters.
A
The
I
think
it's
the
update
management,
one
that
augments
that
with
additional
suit
mana
suit
parameters-
and
this
is
just
saying-
hey,
let's
add
yet
another
suit-
parameter-
that's
possible
here
and
put
that
into
the
extensions
document.
Just
like
we've
put,
you
know,
image
digest
and
so
on
into
there,
and
so
that's
the
proposal
here.
A
A
So
that
other
protocols,
if
they
have
the
same
problem,
could
reuse
option
two,
so
my
personal
preference
is
option
two,
which
means
that
would
go
into
like
the
update
management
document.
But
the
point
is
the
hackathon
report.
Is
we
ran
into
this?
We
need
some
solution
to
it:
hey
teep!
You
should
weigh
in
or
sorry
suit.
You
should
weigh
in
so
the
deep
implementers
know
how
to
implement
the
suit
manifest.
A
D
So
the
suit
report
has
an
explicit
solution
for
this.
It
does
have
an
unambiguous,
manifest
reference
in
it.
The
problem
that
you're
encountering
comes
purely
from
taking
the
system
property
claims
out
of
the
suit
report.
So
I'm
not
sure
that
this
is
the
issue
you
think
it
is.
I
would
argue
in
fact,
that
the
answer
is
to
use
a
suit
report.
A
Yep,
so
this
isn't
the
word.
This
isn't
the
discussion
on
the
draft,
so
I
won't
respond
I'll
just
say.
My
report
is
at
the
hackathon.
The
issue
was
raised
and
we
need
to
come
up
with
something
and
in
your
presentation
brendan
and
in
the
teep
working
group.
We
discussed
this
briefly
where
you
made
the
same
comment,
and
so
you
might
be
right.
The
point
is
just
I'm
reporting
that
we
had
this
discussion
and
you
can
report
on
the
answer.
Thank
you.
B
E
If
you
go
back
one
slide
on
the
on
the
previous
issue,.
E
A
E
A
Let's
say
you
have
tf-a
version,
xyz,
okay,
and
so
you
boot
up
and
you
send
off
an
eat
that
goes
off
and
the
eat
has
multiple
layers,
maybe
one
for
the
one
for
the
trust
zone.
Hardware
right
one
for
the
chip
right,
one
for
one
little
piece
of
information
about
tf-a,
piece
of
information
about
opti
and
a
piece
of
information
about
the
the
teep
agent
ta.
Okay.
A
So
that's
what
comes
into
your
eat
and
that
that,
however,
you
encode
that
into
each
right
in
that
okay,
you
need
to
specify,
because
now
you
have
a
piece
of
hardware
and
you
have
three
components
right
in
that
chain
right.
You
have
tf2sa,
you
have
opti
and
you
have
the
the
type
agent,
and
so
each
of
those
could
have
a
suit
manifest.
A
And
so,
as
part
of
your
token,
you
want
to
say
here
was
the
you
know:
image
digest
or
the
manifest
version
number
or
whatever?
Okay
for
each
one
of
those
layers,
and
then
I
will
send
that
off
to
the
verifier
and
then
I
can
say:
oh
yeah,
all
those
things
match:
you're,
good.
Okay.
So
how
do
you
encode
that?
And
that's
what
this
is
talking
about,
because
you
want
to
put
the
entire
manifest
into
there.
You
want
a
reference
to
it.
A
That's
what
this
issue
is
is:
what's
the
easiest
most
efficient
way
to
do
that,
and
so
here
in
this
example,
it's
using
the
suit
manifest
number,
not
the
digest.
Why?
Because
you
can
look
up
one
from
the
other
and
so
the
policy
on
the
verifier
side
to
say:
is
it
good
or
not?
You
would
be
allowed
to
have
a
policy
that
says
suit.
E
A
B
Okay
brendan,
would
you
come
present
on
suit
manifest
18.
C
F
D
Okay
next
slide,
please.
D
Oh
yeah,
I
could
do
that.
Yep
got
it.
D
So
largely
this
is
editorial
changes
there.
There
hasn't
really
been
much
in
terms
of
churn
in
the
spec
really.
What
we've
done
is
just
made
a
few
of
these
editorial
changes
that
I've
got
listed
here
since,
as
you
point
out,
we
are
short
for
time.
I
won't
go
through
them,
they
are
all
in
the
github,
so
that's
relatively
easy
to
track.
D
Now
there
is
one
structural
change,
and
the
structural
change
here
is
that
I've
added
a
reference
to
an
algorithm
profile
document
and
unfortunately,
it's
the
if
time
permits
document,
I'm
I'm
hoping
that
we
can
get
past
the
the
if
time
permits
and
get
to
talk
to
it
talk
about
it,
because
I
think
it's
probably
the
most
important
thing
we'll
discuss
today.
D
There
are
there's
also
one
technical
change.
Now
this
technical
change
was
not
taken
lightly.
I
really
tried
not
to
change
the
ordering
of
the
keys
in
the
suit
manifest.
D
So
what
I
did
was
to
look
back
at
exactly
what
requirements
we
had
and
why
we
would
choose
to
order
things
in
a
particular
way,
and
so
the
rationale
for
ordering
here
is
that
recipient,
necessary
parameters
should
become
before
the
ones
that
are
not
necessary
to
the
recipient
and
unseverable
members
should
come
before
ones
that
are
severable.
D
So
noting
that
I'm
not
aware
of
any
unseverable
recipient
unnecessary
metadata,
with
the
possible
exception
of
the
canonical
uri,
which
I
have
moved
to
the
front.
The
first
element,
I
would
say
that
that
third
one
doesn't
actually
exist,
and
the
result
of
that
is
that
we
have
unseverable
before
severable
and
recipient
necessary
before
recipient
unnecessary
and
that
required
reordering
a
few
of
the
keys.
So
since
some
of
the
keys
were
being
reordered,
I
attempted
to
space
out
the
remaining
ones
to
allow
us
to
hopefully
grow
in
whichever
direction
is
needed.
D
D
So
I
really
would
appreciate
feedback
from
other
implementers
on
this
topic,
but
I
think
that
if
we're
willing
to
accept
the
breaking
ordering
change,
it
is
probably
a
better
result.
In
the
end.
B
G
D
So
those
are
the
actual
key
changes.
I
I
it's
yeah
numbers,
let's
move
on,
so
we
have
some
open
issues
and
we've
already
heard
about
one
of
them.
How
do
you
reference
a
manifest
in
eat?
We've
got
a
few
ayana
feedback
elements
and
to
do's
from
the
early
review,
so
those
are
all
relatively
straightforward.
None
of
them
are
breaking.
None
of
them
are
cause
for
concern,
they're,
just
editorial
we'll
get
those
sorted
out.
D
There
are
a
few
cddl
nits,
but
I
hope
that
that's
all
sorted
out
with
in
short
order
here
and
there
was
an
error
in
some
of
the
text.
Example.
This
is
all
stuff
that
I
think
dave
already
referenced
in
his
hackathon
report,
but
the
real
question
there
is,
of
course,
is
how
do
we
reference
a
manifest
in
eat
and
that's
not
strictly
a
manifest
question.
So
maybe
we
can
just
ignore
that
at
the
moment
and
and
that's
it-
that's
what
I've
got
for
the
manifest.
D
So
I
I
guess
the
question
I
have
is:
are
there
any
other
sort
of
working
group
last
call
type
review
elements
that
we
need
in
here
now.
A
F
A
D
A
D
Okay,
multiple
trust
domains.
This
is
only
two
slides,
so
I'm
going
to
let
you
advance
this
one.
Russ.
D
Okay,
we
have
a
few
open
issues:
yeah
there's
a
key
conflict
because
I
reordered
the
numbers
in
the
suit
manifest
it
hasn't
had
its
update.
Yet
so
that's
all
that's
going
on
there
after
the
discussion
in
the
teap
working
group
earlier
today.
I
think
that
it
is
now
clear
to
me
that
we
do
need
an
uninstall
command
sequence.
D
I
don't
think
there's
any
getting
away
from
that.
I
think
that's
what
it
has
to
be
now
because
of
what
that
is.
It
has
to
be
added
to
the
unseverable
manifest
members.
That's
all
that
can
be
done.
That's
where
it
lives,
so
that's
going
to
need
to
be
an
update.
But
again
this
is
an
update
to
the
trust
domain
document.
I
think
that's
it.
I
don't
believe
any
other
commands
are
necessary.
I
think
unlink
on
its
own
is
good
enough.
D
D
C
D
Okay,
again,
two
slides
next
slide.
Please
yeah,
there's
very
little
to
say
about
this
one.
It's
definitely
not
a
complete
list
of
update
management
actions,
I'm
fairly
confident
of
that.
I
think
this
is
something
where
we
can
expect
the
registration
list
to
grow
and
that
that
is
sort
of
the
reason
we
have
an
iana
registry
because
it
won't
be
complete
and
beyond
that,
I'm
not
sure
I
have
a
question
here
about
whether
you
should
be
able
to
use
a
manifest
sequence
number
in
a
version
comparison
within
a
manifest.
D
That
was
probably
because
I
misinterpreted
the
question
that
dave
was
asking
me
before
and
thought
that
he
wanted
a
parameter
in
the
the
suit
parameters
specifically
to
be
able
to
use
it
in
manifest
sequences.
Well,
that
appears
not
in
fact
to
be
the
case,
so
maybe
we
can
just
strike
that
one.
So
I
don't
think
there
are
any
open
issues
as
a
result.
A
Yeah
this
is
dave's
favorite.
I
think
the
two
issues
that
I
covered
at
the
end
of
the
hackathon
report.
If
there's
any
changes
to
be
made,
this
is
I
oh
sorry.
One
of
them
was
the
trust
domains
document
right.
Another
one
wasn't
here.
So
if
we
agreed
to
do
something
there,
then
this
is
the
document
that
it
would
be
done,
and
so
I
would
put
on
a
list
of
open
issues
there.
Even
if
brennan
might
be
an
open
issue,
so.
H
H
I'll
talk
anyway,
regardless
go
ahead
and
go
go
on.
Yes,
that's
it.
So
the
main
issue
with
the
firmware
encryption
draft
was
the
this
instance
of
the
practical
thing
from
mcu
boot,
where
the
flash
image
needs
to
be
updated
in
pieces
and
it
kind
of
precludes
the
use
of
aad
and
so
there's
more
explanation
in
here
about
effectively.
H
And
go
ahead:
you
can
go
ahead
and
go
on.
Oh.
H
So
that
this
is
just
a
summary
of
the
the
the
issues
behind
that,
basically,
we
use
a
aes
counter
mode.
You
can
also
use
cbc
for
this.
This
is
written
into
the.
I
believe
it's
nine
of
the
draft.
H
H
So
there
was
discussion
during
the
coz
of
work,
the
coza
meeting
to
allow
unauthenticated
encryption-
I
guess,
depending
on
how
that
actually
ends
up
getting
worded,
will
determine
what
we're
allowed
here.
Currently,
it's
worded
in
our
draft
that
these
are
only
to
be
used
for
suit
for
this,
and
that
should
be
it.
B
So
this
external
to
the
encryption
integrity
mechanism
makes
the
system
okay,
but
the
way
the
instructions
are
written
in
cosa.
It
says
the
algorithm
identifier
is
the
algorithm
identifier
of
an
aead,
so
we
gotta
say:
write
a
document
says
why
it's
okay
in
this
particular
context,
get
the
code
points
registered
for
aes,
counter
aes
cbc,
and
then,
if
cosi
adopts
it
we're
done.
We
have
an
answer.
If
they
reject
it,
then
we
have
a
different
problem.
E
B
E
B
E
Clicked
the
wrong
one,
and
so
that
the
newer
slide
only
contains
pointers
to
the
github
repository
on
three
issues
that
were
brought
up
by
marco.
I
think
marco
is
here,
yep
actually
two
by
marco
and
one
and
one
other.
I
think
he
was
again
ken
ken
proposed,
not
this
one
other
issue
in
the
during
the
hackathon.
So
to
do
just
to
to
shortly
summarize
marco
suggested
to
look
into
the
counter
signatures
for
the
wrapper
that
we
provide
outside
the
encryption.
So
we
first
do
the
encryption.
E
So
that's
something
we
should
be
looking
into
because
it's
just
the
signature
just
goes
into
another
header
parameter
rather
than
having
an
entire
cosi
sine
one
wrapper
around
it,
which
I
think
has
has
a
lot
of
benefits.
E
The
other
one
was
about
the
wording
refinement
of
the
wording
that
we
have
in
there
on
the
use
of
the
keck
verification,
which
was
the
mitigation
to
deal
and
thank
you,
which
was
the
mitigation
to
deal
with
potential
battery
exhaustion,
and
so
since
we
use
the
keck
with
oil
with
a
nons
with
oil
zeroes.
We
should
not
for
this.
For
this
verification
step,
we
should
not
then
use
a
kick
for
encrypting
anything
afterwards
with
the
same
value,
because
we
would
be
reusing
it.
E
I
think
we
need
to
be
explicit,
maybe
obvious
too
many,
but
I
think
we
should
be
crystal
clear
there
and
on
the
on
the
hackathon,
it's
safe,
yeah
and
ken.
Maybe
you
can
explain
your
last
item.
I
know
you
you
created
the
br
and
so
on.
Maybe
you
can
briefly
summarize
on
the
issue
that
you
filed
for
the
encryption
document.
G
A
G
Suit
encryption
info
was,
in
the
former
suit,
manifest
original
code
document
that
brendan
moved,
I
think
brendan
removed
from
the
core
document
of
sued
manifest,
and
now
it's
a
in
the
pharma
encryption
document,
and
I
pointed
that
it
I
think
I
I
I
think
it
should
be
a
reasonable
position
in
this
suit
directive
set
parameter.
E
Yeah
so,
and
what
is
also
missing-
and
I
think
we
are
getting
close
like
the
these
issues-
should
be
resolved
fairly
quickly.
The
first
one,
and
definitely
the
second
one,
with
a
little
bit
of
re-reading
and
and
looking
into
the
counter
signatures,
and
also
what
ken
just
said.
E
Probably
what
we'll
be
holding
up
is
the
former
issue
that
we
just
talked
about,
which
is
kind
of
unfortunate,
but
it
is
what
it
is
and
also
there's
the
since
we're
using
two
key
exchange
mechanism
in
here,
the
eas
key
wrap
and
also
hbke.
We
have
this
dependency
with
the
hbke
document
in
the
courtesy
working
group
and
while
it's
advancing
it,
there's
a
continuous
update
or
synchronization
needed
between
those
two
documents.
E
With
regarding
to
the
example
and
the
complete
example
is
currently
not
in
a
document
it,
which
is
also
something
that's
needed,
so
it
kind
of
gets
delayed
because
of
the
completion
of
the
other
work
and
the
dependency.
So
that's
yeah,
but
I
think
that
reconfirms
that
it
was
some
right
decision
to
move
that
out
of
the
in
the
main
specification
to
advance
the
main
manifest
document
faster
than
this
extension
right.
E
D
F
B
We'll
we'll
just
have
to
read
the
politics.
F
D
It's
it's.
I
I
totally
appreciate
that.
I'm
and-
and
I
also
see
where
they're
coming
from
on
that
end-
that
you
really
want
to
avoid
having
a
lot
of
people
using
this
for
non-firmware
update
use
cases.
I
do
wonder,
though,
if
cozy
is
in
general,
missing
a
streaming
decryption
capability
and
that's
something
that
they
need
to
address.
B
D
All
right,
so
there
there's
really
not
a
huge
change
to
the
document
this
time
around.
Essentially,
what
I've
done
is
I've
added
a
big
text
section
that
explains
why
and
how
you
might
choose
to
use
a
suit
report
as
attestation
evidence
now.
This
has
been
something
that
I've
talked
about
with
with
hank
a
fair
bit
actually
and
essentially,
the
idea
behind
this
is
that
a
verifier
may
well
be
equipped
to
evaluate
a
suit
report,
and
I'm
not
talking
about
the
proper.
D
It
can,
then,
to
construct
a
more
standard
suit
or
attestation
result
out
of
that
document,
and
so
this
is
the
essentially
the
idea
and
there's
a
few
justifications
for
why
you
might
want
to
do
this.
One
of
them
is
that,
then
your
device
can
have
just
an
append.
Only
log
of
what
the
manifest
processor
did
and
that
becomes
enough
for
your
attestation
evidence.
D
I
think
that's
a
really
powerful
thing
for
a
very
constrained
node.
So
so
that's
that's
sort
of
the
summary
I've
put
a
block
of
text
in
which
explains
all
of
that.
That's
the
big
change
and
in
terms
of
open
issues.
There
is
one
issue
as
far
as
I'm
concerned,
and
that
is
that
we
have
two
different
logs:
we've
got
one
for
debug
type
things
and
one
for
evidence.
D
The
idea
being
that
that
this
merged
log
that
you
get
at
the
end
is
better
for
embedded
devices,
because
they
only
have
to
append
elements
to
a
single
buffer,
and
so
that
makes
it
really
easy
for
them.
Now,
as
I
say
here,
this
is
a
simple
change,
but
it
desperately
needs
feedback,
especially
if
teeps
about
to
start
using
the
part
I
want
to
delete.
Then
we
definitely
need
to
talk
about
exactly
how
this
all
fits
together.
A
So
I'm
going
to
put
myself
in
queue
here,
there's
that
I
don't
yet
have
an
opinion
on
that
one
you
can
think
about
it
more,
but
the
other
issue
that
came
up
that
was
reported
in
the
team
working
group
was
a
question
and
the
context
is
the
question
that
was
raised.
There
is
what's
the
right
recommendation
for
how
to
encrypt
suit
reports
if
there
happened
to
be
any
sense
of
information
in
it,
and
so
I.
F
A
Observed
that
the
entire
security
consideration
section
of
this
reports
document
right
now
is
two
sentences,
and
perhaps
it
should
say
more
than
that,
the
only
reference
is
it
should
either
be
carried
over
a
secure
transport
or
assigned
or
both,
but
doesn't
say
what
secure
transport
doesn't
have
any
considerations
about.
You
know
encryption
or
whatever.
So
at
least
that's
an
editorial
issue
to
be
addressed,
if
not
an
actual
technical
issue.
A
If
it
really
is
to
say
you
must
use,
if
you
care
about
encryption,
then-
or
you
know,
sensitive
information
and
suit
report-
then
either
put
it
in
a
secure
transport
or
leave
it
out
of
the
report
right
then
at
least
that
would
be
something
if
we
want
to
have
a
mechanism
to
do
encryption
at
the
superport
layer
in
the
future.
So
you
get
that
vetting
extension.
Whatever
my
point
is
the
security
consideration.
The
section
should
actually
say
something.
F
D
D
Fair
that
that
element
of
the
draft
is
definitely
lacking.
So,
let's,
let's,
let's
see
if
we
can
get
that
fixed
for
the
next
one.
I
For
those
who
don't
know
we're
laughing
about
brendan
was
active
in
previous
meetings
this
week
about
asking
people
to
have
threat
models,
and
so.
D
C
D
Yeah,
so
this
this
is
really
just
an
update,
and
this
is
a
very
simple
extension
to
suit.
The
idea
is
that
you
have
a
mechanism
to
carry
either
a
mud
file
or
both
mud,
uris
and
mud,
signer,
public
keys.
The
idea
behind
this
is
that
it
replaces
the
conventional
approach
to
deliver
mud
information
from
a
mud
capable
device
to
a
what's
the
word:
a
mud,
a
mud
manager.
I
think
it's
a
mud
manager
and
it
replaces
that
with
the
update
pipeline.
D
So
the
idea
here
is
that
your
network
infrastructure
is
supposed
to
receive
a
copy
of
the
manifest
before
it
gets
pushed
out
to
your
device.
That
means
that,
before
the
device
ever
connects
to
the
network,
the
network
infrastructure
already
knows
what
its
new
mud
file
is
going
to
be
because
it's
either
fetched
it
remotely
or
decoded
it
out
of
the
manifest.
D
Obviously,
this
is
a
severable
element,
because
the
device
itself
does
not
need
this
information.
It
has
a
lot
of
benefits.
It's
similar
to
device
certificate
binding,
but
has
the
advantage
that
individual
device
certificates
do
not
need
anything
about
this
information.
Instead,
all
of
that
is
delivered
to
the
network
infrastructure
in
a
much
more
compact
form.
D
What
this
does
give
you
is
the
requirement
that
you
either
do
some
kind
of
device
fingerprinting
or
at
a
station
in
the
network.
Now,
of
course,
my
personal
preference
on
this
is
for
attestation.
D
D
It's
going
to
be
referenced
by
the
iot
nets
document.
That's
going
tomorrow
in
the
iot
ops
working
group.
I'm
I'm
not
aware
of
any
open
issues
on
this.
It's
a
literally
a
two
point,
a
three
point
extension
to
the
manifest
it
does
does
very
little.
It
says
very
little
and
I
don't
know
what
else
we
need
in
it.
D
All
right
this
is
this:
is
the
controversial
one
you'll
you'll
notice
that
I've
got
two
titles
here.
There's
there's
zero
because
I
filed
the
wrong
one
and
before
the
draft
deadline.
Sorry
about
that,
then
there's
zero
one!
It's
got
a
much
better
structure.
If
you're
going
to
read
them.
Please
read
the
second
one.
G
D
There
we
go
so
the
idea
behind
this
is
that
we
want
to
ensure
interoperability
between
devices
and
the
systems
that
manage
them,
and
we
want
to
do
this
with
as
little
as
little
m
cross
n
problem
as
we
can
get.
D
But
this
is
an
asymmetric
problem.
Devices
can
only
be
expected
to
implement
a
single
crypto
suite
you
might
get
lucky
and
have
to
that
being
the
case.
The
burden
really
falls
on
authors
and
management
systems
to
handle
multiple
crypto
suites
so
that
they
can
support
the
devices
they
manage.
D
Having
mandatory
to
implement,
algorithms
may
be
problematic
for
some
recipients,
so
this
is
going
to
be
a
challenge
for
us
and
I
think
that
it's
real,
oh,
I
should
mention.
We
don't
do
constrained
to
constrained
right.
You
don't
in
suit
that
you
don't
have
a
situation
where
you
have
two
constrained
nodes
that
are
talking
to
each
other.
You
always
have
a
relatively
capable
system
talking
to
a
constrained
system,
so
this
is
a
different
problem
than
most
of
the
interrupt
problems
that
we
run
into.
D
Recipients,
if
they
don't
have
the
the
the
crypto
system
they
want
available,
will
simply
not
comply
with
the
mtis.
I
think
it's
pretty
clear
that
and
and
I've
had
feedback
from
some
implementers
that
say.
Essentially,
if
you
make
an
algorithm,
I
don't
want
mandatory
to
implement.
I
might
still
use
your
standard,
but
I
won't
comply
with
the
mti.
D
D
I
suppose
that's
a
good
reason
for
separating
this
out
of
the
manifest
draft
in
itself.
At
least
then
they
can
comply
with
that
draft,
but
not
with
this
one.
D
So
then,
the
question
is:
if
we're
going
to
do
mandatory
to
implement
suites,
what
should
we
do?
Well,
if
we
do
symmetric
it's
relatively
straightforward,
we
mostly
know
what
to
do
with
that,
but
it
the
key
and
tag
distribution
is
a
real
pain.
It's
not
a
nice
way
of
doing
things.
We
really
don't
want
to
advertise
this
as
the
way
to
solve
the
problem
for
asymmetric
the
classical
implement
implementations.
At
least
the
signature
is
small.
D
A
hash
based
is
quite
large
and
has
a
stateful
private
key,
which
is
not
a
thing
to
recommend
it,
and
it
may
be
difficult
to
justify
in
some
applications,
particularly
if
you're
demanding
an
hsm,
because
I'm
not
aware
of
any
that
support
it.
Yet
there
are
other
options
that
are
coming,
but
they're
not
standardized,
yet
the
winners
are
announced,
but
the
standards
haven't
arrived.
D
So
for
key
distribution,
which
is
the
other
side-
and
this
will
play
it
more
into
the
the
firmware
encryption
side
of
the
the
work-
and
there
are
symmetric
solutions
and
most
of
them
will
involve
you
know
using
a
single
shared
secret
and
then
deriving
from
it
and
there's
classical
asymmetric,
and
this
is
well
known-
might
become
broken.
D
We
have
pqc
asymmetric
coming,
but
there
are
no
standardized
pqc,
h
or
symmetric
algorithms.
As
of
yet
there
are
winners
announced
so
obviously
that
side
of
things
we
probably
can't
do
in
an
mti
draft
today,
again
this
is
a
moving
target.
D
So
what
should
we
do?
I
have
a
proposal,
and
this
is
very
much
a
straw
man.
I
very
much
think
this
is
going
to
need
changes
and
that
I
I
would
very
much
welcome
input
on
this.
The
proposal
is
that
for
symmetric.
We
well
I
mean
that
one's
obvious.
We
don't
need
to
go
into
it
too
much.
I
note
here
just
quickly
that
I've
got
aead
written
for
each
of
the
encryption
algorithms.
That's
because
those
are
the
only
currently
standardized
options.
D
D
So
then,
the
next
stage
of
this
is
authentication
well
for
symmetric
yeah
again,
we
know
what
to
do
with
that.
So
for
classical
asymmetric.
I've
proposed
es256
for
key
exchange,
hpke,
which
I
realized
is
you
know
both
key
exchange
and
encryption,
but
never
mind
and
for
for
pqc.
What
I'm
proposing
is
a
hybrid
mode
where
the
authentication
is
is
hss
lms,
but
the
key
exchange
is
classical
hpke.
B
So
brandon
this
is
russ.
I
think,
in
light
of
what
we've
been
learning
in
jose
hpke,
led
to
some
confusion.
What
honest!
What
our
document
is
is
a
way
to
get
with
cozy
structures,
the
same
properties
that
they
can
take.
F
B
But
it
is
not
exactly
in
the
sense
that
if
you
took
an
hbke
library,
you'd
have
to
pull
it
all
apart,
though
the
ins
and
outs
all
apart
right
and.
B
Just
sorry
jose
hpke
or
something.
B
Right,
I
think
that's
what
that's
really
my
only
suggestion
for
clarity,
because
I
know
at
least
one
person
didn't
get
it.
D
Fair
enough
yeah,
so
I
mean
that's:
that's
a
good
update
for
the
draft
to
mention
that
so
there's
a
lot
of
other
favorite
algorithms.
Some
of
them
are
definitely
favorites
in
the
iot
space,
and
my
answer
to
that
is
there
are
going
to
be
an
implementers
who
demand
fips
algorithms.
D
We
should
not
deny
them
an
mti
fips
algorithm.
That
would
be
a
mistake.
So
I've
listed
three
and
they're
all
fips.
The
question
is:
do
we
need
something
else
that
isn't
fips
that
allows?
You
know
pick
your
favorite
algorithm.
I'm
have
very
mixed
feelings
about
this.
As
I
suspect
you
know,
many
people
do.
The
list
will
end
up
being
very
long.
D
If
we
keep
going
down
this
road
and
so
then
this
question
is
the
the
reasoning
for
the
ones
I've
picked
is
that
people
are
going
to
demand
fips
and
that
that's
not
an
unreasonable
demand.
A
Dave
filler,
as
with
the
t
protocol
document,
editor
hat
on,
one
of
the
use
cases
of
suit
is,
of
course,
antique
and
when
doing
both
them
in
constrained
nodes,
it
sure
would
be
nice
if
you
had
common
requirements
on
what
the
algorithms
are
for
the
same
purpose.
I
A
Type
document
says
something
right
now,
which
could
also
be
changed,
and
so
my
point
is
the
mti
is
here
and
the
mti
is
in
suit.
I
would
like
them
to
be
consistent,
but
I
don't
have
a
strong
opinion
what
they
are,
but
the
cheap
protocol
document
says
right
now
and
similar
constraints,
as
brendan
said
to
everybody
else
right.
You
have
one
side
that
is
not
constrained
and
the
side
that
is
constrained
that
happens
to
match
exactly
the
constraints
that
the
case
is
in
suit
right.
A
The
constrained
side
is
still
the
constrained
side
in
both
cases.
What
it
says
right
now
in
the
document
is
that
the
constrained
node,
which
is
the
consumer
of
information,
can
pick
either
es
256
or
eddsa,
and
the
unconstrained
side
must
do
both.
Okay,
that's
what
it
says
right
now.
What
it
should
say
is
an
interesting
question.
My
point
is:
we
should
keep
alignment
there,
but
I
bring
this
up
because
you
say
what
about
ed,
dsa
and
t.
C
Yes,
so
dave,
this
is
dave
waltermeier.
If,
if
the
goal
is
to
keep
them
in
alignment,
how
do
we
ensure
long-term
alignment
between
the
two
efforts?
C
B
B
I
A
Just
posted
draft
10,
so
the
cheap
meeting
was
earlier
today
and
we
walked
through
all
the
issues
and
t
as
well
as
a
couple
of
open
issues
right,
but
all
the
issues
that
I
said
here
in
github
are
now
posted
in
draft
10,
which
came
out
this
afternoon
right.
It
matches
exactly
the
github
copy
as
of
this
morning
and
the
end
of
the
hackathon,
and
that
one
does
take
a
dependency
on
the
firmware
encryption
document.
A
You'll
see
that
in
the
right
now
it's
an
informative
reference
just
due
to
how
it's
worded
right,
it
could
become
normative.
I
think
right
now,
it's
informative,
but
to
dave
walter
meyer's
question.
I
want
to
give
an
analogy
to
what
we
do
for
eat
in
the
eat.
In
the
rats
working
group,
the
eat
document
says
you
can
define
a
profile
and
it's
going
to
use
the
word
profile.
I'm
not
saying
how
to
use
your
profile
or
whatever
it
says
in
use
case.
A
What's
mandatory
to
implement
is
not
in
the
body
of
the
document,
it's
in
the
specific
use
case
right.
So
what
you
could
say
is
that
it's
teeps
job
to
specify
what
the
mandatory
to
implement
cases
when
using
suit
in
a
teep
case.
Now
the
disadvantage
of
that
is
that
we
would
love
suit
to
say
I
have
a
suit
manifest
signer
and
processor
that
can
be
used
for
both
teep
and
other
cases.
That's
the
reason
to
not
do
that,
and
so
I
just
want
to
throw
out
both
the
pros
and
the
cons
of
that
project.
A
Thank
you
again,
so
I
I
like
one
of
the
things
that
brendan
said
earlier,
which
does
align
with
how
teep
does
it,
which
is,
if
you
say
that
the
non-constrained
side
has
to
implement
both
of
them
in
order
to
let
the
constrained
side
pick
one,
you
can
do
the
same
thing
for
how
you
do
profiles
right.
The
non-constrained
side
can
implement
multiple
profiles
and
it
must
do
all
of
them
right
and
the
constrained
node
supports
often
just
a
single
profile.
A
That's
using
it
for
a
single
use
case
right
and
so
as
long
as
you
principal
around
the
mtis
is
to
say
each
use
case
defines
its
mtis
and
your
principle
is
that
say
the
suit
manifest
generator.
If
it's
going
to
have
a
tool
or
a
repository
for
doing
both
of
those,
it
supports
a
set
of
huge
cases,
and
it
supports
all
the
mtis
for
all
the
use
cases
it
wants
to
be
used
for.
C
But
so
so
ross
here,
you're
implying
that
shouldn't
define
any
mti
and
that
these
other
use
cases
should.
D
D
A
No
great
answer,
I
I
think
one
other
things
that
I
think
you
mentioned
on
the
previous
slide,
which
is
this
is
a
moving
target.
A
Okay,
so
I
think
that's
exactly
a
good
reason
why
we
split
out
the
mti
discussion
out
of
the
main
document
so
that,
as
the
set
of
mtis
change,
which
you
know
10
years
from
now,
the
set
of
mpis
is
probably
going
to
be
different
from
what
they
are
right
now,
because
your
point
of
view
is
about
the
you
know,
hopefully
by
then
we'll
have
pqc
standards
right,
so
you
can
actually
reference
that
have
different
apis
right,
and
so
that
means
that
the
ideal
case
is
we
don't
need
to
obsolete
or
even
update
the
suit
manifest
document
right.
A
D
So
I
I'm
going
to
say
this:
I
have
almost
definitely
made
wrong
choices
in
this
document.
This
was
explicitly
intended
to
be
a
straw.
Man.
Please
go
bash
it
it
it's.
It's
almost
certainly
wrong,
but
it
was
the
the
best
shot
at
the
minimum
set.
I
could
think
of
that
would
suit
the
use
cases
I
can
see
today.
D
I,
as
I'm
well
aware
that
riot
disagrees
with
me
and
their
default
signature
algorithm
is
eddsa
and,
as
a
result,
I
wonder
if
we're
going
to
wind
up
with
four
options
in
the
very
in
very
short
order
as
soon
as
they
start
editing
this
document
with
me,
but
that
that
was
as
far
as
I
got
today
and
the
reasoning
again
was
because
of
fips.
J
Oh
yeah,
sorry,
it's
kind
of
short
here,
so
the
the
latest
eat
has
a
definition
of
a
profile
which
includes
the
crypto
algorithms
for
eat,
but
it
is
not
mandatory
to
implement.
So
it's
just
a
definition
of
a
profile
that
you
can
so
you
can
reference
if
you
want
to
and
say,
for
you
know,
for
this
kind
of
device
use
we're
using
this
profile,
so
they're
not
mandatory
to
implement
they're.
Just
you
know
a
palette
of
of
profiles,
or
this
is
the
start
of
a
ballot.
B
A
I
just
want
to
report
out
in
case
the
camera
is
not
there.
There
was
nobody
in
the
room
that
said
that
they
had
any
issues
or
no
hands
raised.
So.
B
I
B
You
dave,
given
that
we
have
just
five
minutes
left.
We
can
either
go
back
and
talk
about
the
hackathon
things
that
they've
skipped,
because
we
didn't
think
we'd
get
done
or
we
could
then.
A
E
A
Find
a
way
forward,
given
that
the
actual
wasteboard
was
not
to
point
the
package
on
reports,
one
pack
of
dog
report
would
say
we
raise
an
issue
all
right.
So
if
you
just
go
to
the
last
two
slides
there,
the
first
one
so,
let's
see,
if
you
can
get
any
if
we
can
get
any
direction
here
right.
A
So
this
one
that
the
green
part
here
is
what
the
each
spec
says:
okay,
which
anything
that
has
its
own
content
type,
your
own
co-op
content,
format,
value
that
you
can
plug
into
here,
and
so
the
proposal
in
the
hackathon
was
to
say
we
create
another
co-op
content
format,
value
which
can
specify.
I
have
a
way
of
referencing
a
particular
suit,
manifest
and
verse
number,
and
if
that's
a
good
idea,
then,
which
draft
would
that
go
in?
That's
the
question.
D
So
I
I
think
I've
mentioned
previously
that
my
preference
for
in
these
situations
is
to
use
the
the
digest
of
the
manifest.
I
understand
that
you
like
the
ability
to
do
broad
version
comparisons
simply
so
I
I
take
that
point
that
other
than
that
I
yeah
I
mean
this
is
fine.
I
would
I
guess
my
my
question
would
be:
how
would
you
feel
about
making
the
sequence
number
either
or
with
the
digest.
A
I
personally
would
not
have
any
objections.
The
question
is:
who
gets
to
decide
to
either
or
and
because,
as
long
as
say,
an
an
author
of
a
verifier
can
say,
we
really
like
doing
manifest
sequence,
numbers
or
whatever
it
says
it
gives,
who
gets
to
decide
the
order
right?
It's
really
the
real
question.
A
There
so
I
she's
speaking
as
an
individual.
I
would
not
have
any
problem
with
that.
I
in
a
constrained
node
fewer
options
is
better,
and
so
that
was
the
disadvantage
of
say,
if
you
say,
or
as
long
as
the
implementer
gets
to
pick
and
only
implement
one
of
those
two
in
the
constrained
node,
then
that
resolves
that
concern
exactly.
C
A
D
E
E
I
have
a
question
independent
of
this
one:
more
sort
of
logistical
question
or
process
question
when
brendan
said
he's
going
to
update
the
manifest
with
the
content
he
already
had
in
which
he
talked
about
it.
That's
fantastic,
then.
The
next
step
is
with
that
triggered
in
the
working
group
last
call
of
that
document.
Or
how
would
we
proceed
specifically?
Now
we
have
the
summer
months
august.
Some
people
are
away
and
so
on.
E
So
how
do
we
make
sure
that
we
sort
of
like
get
those
document
out
there,
so
we
can
actually
use
them
also
in.
E
A
That's
right:
I
think
that
the
principle
we're
trying
to
follow
is,
if
you
raise
a
new
comment
on
something
that
hasn't
been
addressed,
then
we
would
look
to
see.
Is
that
piece
severable
out
of
the
main
document
into
an
extension
so
that
we
can
keep
doing
that
to
let
the
rest
go
forward
and
we
hope
that
the
answer
is
always.
There
exists
no
unseparable
pieces,
sorry
to
reuse,
brendan's,
several
coins
term
out
of
time,
so
I
don't
know
if
we
have
time
to
cover
the
last
slide.