►
From YouTube: IETF-SUIT-20230911-1500
Description
SUIT interim meeting session
2023/09/11 1500
D
B
B
It'll
help
reduce
Echo
and
other
problems
during
the
meeting
so
for
today
we're
automatically
logging
who's
participating
using
medecco.
But
we
do
need
some
volunteers.
Can
we
get
a
couple
of
people
to
help
us
with
with
note
taking
I,
didn't
have
the
ether
pad
link,
but
you
can
access
that
and
meet
Echo
and
I'll
drop
that
into
into
chat
as
well.
B
F
G
B
B
B
Pursuit
manifests
we've
also
completed
a
working
group.
Last
call.
We
haven't
received
any
feedback
on
that,
so
unless
we
hear
otherwise
we're
probably
going
to
want
to
ship
that
document,
we
have
firmware
encryption
with
suit,
manifests
we're
completing
the
working
group,
Last
Call
on
that
today,
I'm
shepherding
that
one
I'm
working
on
a
shepard
review,
which
I
hope
to
get
in
maybe
later
today,
worst
case
tomorrow.
B
B
C
A
Just
I
know
Nancy
wanted
this
to
be
during
the
first
hour
instead
of
during
the
last
half
hour.
This
is
the
agenda
Basher.
We
want
to
rearrange
stuff
and
Brendan
I.
Think
the
thing
that
I
commented
on
was
the
T
protocols.
You
come
after
the
MTI
right,
the
one
the
top
one
on
the
slide
should
come
after
that,
just
because
that's
how
the
slide
was
constructed
and
I
see
Brendan
when
you
submitted
the
slides
in
your
title,
I
didn't
open
them
up
your
totally
put
MTI
first
in
the
title.
A
A
A
Think
MTI
and
T
protocol
should
move
up
on
the
agenda,
I
think
based
on
Nancy
and
Brendan's
things,
and
so
whether
they
go
immediately
before
or
after
manifest.
If
we
don't
have
the
slides
for
manifest
open,
then
we
should
start
with
seven
and
eight
I.
Don't
know
we
just
want
to
make
sure
we
get
to
seven
and
eight
within
the
first
hour
right.
It
doesn't
have
to
be
first
so.
D
C
B
C
C
D
D
D
D
I'm
sure,
then
they,
the
suit
pqc
future
profile,
has
been
changed
to
use
AES
256
in
in
both
of
its
well,
both
in
key
wrap
and
in
encryption,
and
the
point
of
this
was
that
HSS
LMS
signatures
are
so
big
already
that
the
the
larger
key
is
basically
irrelevant,
and
there
wasn't
a
256
bit
AES
profile
to
start
with.
This
seemed
like
the
appropriate
place
to
put
it
so
that
that
was
a
request
by
Russ
I
think
originally
I
may
have
that
wrong.
D
I
think
it
was
Russ,
so
that
I've
put
that
in
now
and
I.
I
also
noticed
that
all
of
the
profiles
we
were
using
thus
far
stayed
away
from
ed25519
and
Chacha
poly,
which
seems
to
be
a
popular
combination
for
iot
devices.
So
I've
added
that
as
an
additional
current
profile,
so
as
not
to
alienate
existing
iot
users.
D
I
believe
that
all
of
the
known
issues
with
suit
MTI
are
now
resolved
bar
one,
and
that
is
purely
cddl
editorial
and
and
what
that
is
is
that
there
should
probably
be
a
single
unifying
suit.
Cozy
profiles,
structure
in
the
cdvl
and
you'll
see
that
come
up
later
when
we
talk
about
suit
report
and,
and
that
is
it
for
suit.
Mti
I
I
think
that
now
you
know,
if
I
tack,
that
one
bit
of
cddl
in
I
think
we're
done.
H
Yeah
I
have
posted
a
mail
to
the
list
about
this
related
to
the
CTR
aspect,
because
it
came
up
in
a
in
a
private
message
sent
around
by
Akira
on
about
the
the
Deep
usage
and
I.
Think
for
for
deep
GCM
is
definitely
better
for
these
trusted
applications
as
a
way
to
protect
them
rather
than
CPR,
so
I
believe
we,
we
would
really
need
one
version
with
GCM
and
the
other
one
version
with,
for
example,
a
CTI
and
the
MTI
algorithms.
D
Friend,
I
think
that's
fine
as
long
as
we
limit
it,
because
I
don't
want
to
get
an
I,
don't
want
the
combinatorial
explosion
that
we
are
likely
to
head
towards
if
we
don't
limit
how
many
options
we
take
on.
So
if
there's
one
particular
profile
that
looks
like
it's
the
the
right
one
for
teep,
then
let's
get
it
in
there.
Otherwise
yeah
I
don't
want
to
to
to
do
it
that
way
and
and
have
it
all
explode,
because
that
kind
of
defeats,
the
purpose
of
an
MTI
document.
H
Yeah
yeah
I
I
see
it
more
as
a
MTI
for
sort
of
a
classical
iot
devices
versus
sort
of
like
the
Deep
use
case,
which
is
focusing
on
on
a
higher
end
devices.
So
that
sense,
it
I
think
it
would
be.
It
would
be
fine,
but
I.
Let
Akira
also
who's,
also
going
to
speak
about
that,
because
he
he
brought
this
issue
up.
I
I
D
I
D
A
So
I
don't
have
a
strong
enough
knowledge
of
the
the
two
to
have
an
opinion
as
to
which
one
is
right,
and
so,
if
you
recommend
the
the
CTR
instead
of
the
GCM,
then
no
objection
but
I
did
want
to
share
that.
There
are
two
things
that
the
T
protocol
uses
this
this
for
and,
of
course,
you
know,
I
agree
with
the
point
that
we
want
to
have
like
for
iot
devices
as
few
as
possible.
A
Okay.
This
is
not
about
what
goes
in
the
Manifest,
which
is
the
third
one
right
right
about
what
would
use
manifest.
So
those
are
the
three
different
things
two
on
the
sending
in
one
on
the
receiving
end
right
and
to
say
what
is
the
right
one
for
all
three
purposes,
because
teep
would
probably
defer
to
Suits
recommendations.
As
long
as
the
understanding
is.
This
applies
to
suit
reports,
potentially
manifests
and
eat.
D
D
H
H
H
C
I
D
C
G
D
C
D
B
A
Yeah,
so
just
as
a
reminder,
this
has
already
gone
through
working
group.
Last
call
we
have
a
document
Shepard
right
up.
We
raised
two
issues
at
hackathon,
117
and
posted
a
draft
that
referenced
those
two
and
so
we're
basically
dealing
with
any
other
issues
that
get
filed
as
they
get
filed,
while
we're
waiting
for
the
dependencies
to
to
progress,
because
you
see
quite
a
number
of
the
ones
that
I
think
four
of
the
documents
that
from
suit
are,
are
normative
dependencies.
A
So
next
I
think
that
goes
a
lot
of
that,
and
here
they
are
so
here's
the
list
of
normative
dependencies
and
they're
all
farther
along
or
as
far
along
as
the
tea
protocol.
The
last
two
being
the
the
tail
end
right
so
NPI,
which
we
just
talked
about
and
suit
report
which
we'll
talk
about
shortly.
The
hope
is
that
they're
all
getting
to
the
iesg
before
November,
so
that
we
can
discuss
any
AD
review
and
ietf
last
call
stuff
would
be
great
if
we
can
discuss
those
November
meetings.
A
All
right
so
I'm
going
to
talk
about
what
changed
since
the
last
time
that
we
met
in
San
Francisco
next
okay.
So
there
are
two
things
that
we've
presented
at
ietf
117
that
came
up
at
the
hackathon,
the
boy.
We
had
an
implementary
agreement
there
and
we
had.
We
believe
working
group
consensus
that
didn't
change
after
the
meeting,
and
so
everything
that
was
done
for
those
two
was
presented
in
the
meeting
and
made
it
into
the
draft
and
so
I
don't
need
to
talk
about
further.
A
A
Okay,
then
honest
raised
a
point
that
says
this
is
an
editorial
one.
That
says
you
know
how
is
replay
protection
prevented
and
we
should
have
a
discussion
that
just
explains
that
right,
and
so
we
added
the
paragraph,
that's
on
the
screen
and
it's
security
consideration
section
right,
there's
nothing
normative
in
it.
A
Main
point
is,
there
is
nothing
normative
in
here.
It's
all
things
that
should
be
should
be
obvious
from
somebody
that
understands
the
rest
of
the
spec,
but
if
somebody
is
looking
for
replay
protection,
it's
just
a
summary
in
the
threat
model.
That's
in
there
covers
a
whole
bunch
of
different
threats
in
the
security
consideration
section.
So
this
one
is
new
right.
If
I
don't
see
any
hands
up,
then
go
on
to
the
next
okay,
so
new
issues
raised
since
then
that
were
just
raised
in
the
last.
A
What
two
weeks
this
is
Ken's
ones,
I,
know
Ken
you're
on
here
and
so
feel
free
to
get
into
the
queue.
If
you
want
to
discuss
anything
more
than
what's
on
the
slide,
so
all
right,
so
the
first
one
is
that
that
we
talked
about
eats
and
suit
reports
that
are
created
by
the
TP
agent
and
they're
processed
by
The,
Tam
and
so
on,
and
then
the
in
one
of
the
ones
that
we
discussed
at
117
and
made
it
into
Dr
F16.
A
We
added
the
notion
that
you
could
require
the
Tam
to
a
test.
Before
you
give,
you
know,
say
secret
data
off
to
The
Tam
and
that's
you
know
an
option
that
people
support,
and
so
we
put
that
into
there
about
attestation.
But
what
it
neglected
as
Ken
pointed
out,
is,
it
doesn't
mention,
say,
Suit
reports,
because
if
you
were
to
use
suit
reports
in
attestation,
like
Brennan
said
that
you
know
you
don't
have
to
use
your
reports
attestation.
A
D
A
And
so
it
does
not
mention
those
that
there's
a
particular
section
that
talks
about
sending
them
and-
and
it's
that
that
whole
section,
including
eats,
implies
that
it
is
only
keep
agent
to
Tam
Direction.
And
so,
while
we
fix
the
wording
of
some
other
sections,
we
didn't
make
the
wording
of
this
one
sort
of
a
agnostic
wording.
As
as
a
reminder
to
those
in
t.
A
We
change
things
like
you
know:
Tam
and
tape
agent
to
keep
implementation
just
for
any
paragraphs
that
could
be
in
either
direction,
and
so
Ken
pointed
out
a
section
that
needs
to
happen
here,
and
so
that
makes
perfect
sense
to
me
and
I
think
we
should
just
do
that
because
it
doesn't
break
anything.
It
just
makes
it
be
more
more
applicable
if
you
want
to
do
that
in
the
other
direction
too.
A
C
A
Okay,
there's
no
question:
no
questions
no
hands
up,
then,
let's
go
on
to
the
next
slide,
all
right.
So
the
next
question
is
remember
that
list
of
all
the
normative
references
Ken
asks.
Do
we
need
the
suit
report
document
to
actually
be
normative,
and
so
can
the
the
top
two
thirds
of
this
is
actually
Ken's.
A
Liberal
quote
in
the
issue
right,
so
you
could
put
a
suit
report
into
the
mesres
claim
of
eat,
and
so
does
that
mean
that
we
need
to
put
anything
or
can
we
remove
it
from
you
can
see
option
one
option
to
an
option.
Three
removes
your
reports
option
from
all
messages,
which
means
the
only
place
you
can
put.
It
is
inside
of
an
eat
inside
of
a
team
message.
You
can't
put
it
in
parallel
to
that
option.
A
Two
would
be
to
remove
the
reports
option
from
the
query,
request
and
query
response,
but
maybe
leave
it
in
some
other
messages
and
number
three
is
leave
things
the
way
they
are,
and
so
I
wanted
to
repeat
my
response
in
there,
which
sorry
I
wanted
to
repeat
the
working
groups
discussion
we
had
before,
at
least
for
my
recollection.
The
rationale
for
the
current
state
is
The
Following.
When
the
attestation
payload
contains
evidence,
the
attestation
payload
is
okay,
you
can
go
to
the
verifier,
in
other
words,
if
you're,
using
the
background
check
model
right.
A
If
you're
using
the
background
check
model,
then
the
attestation
payload
never
goes
to
The
Tam
right.
It's
completely
opaque
right
just
goes
off
the
verifier
and
if
you
were
to
say,
the
only
way
to
get
suit
report
is
through
the
evidence
and
the
background
check
model,
and
that
means
you're
introducing
a
requirement
that
the
verifier
which
you
might
not
have
control
over
has
to
copy
the
stuff
from
the
evidence
in
the
attestation
report
and
the
next.
A
That
is
an
extra
dependency
that
we
didn't
want,
and
so
that
is
why
it's
it's
in
parallel,
because
the
destination
of
the
suit
report
is
the
Tam
or
as
the
destination
of
the
evidence
is
the
verifier.
And
so
that's
the
rationale
for
option
three
but
Ken.
If
you
want
to
bring
up
anything
because
I'm
saying
I
think
we
had
consensus
on
this
before.
But
if
you
have
new
implementation
experience
or
something
like
that,
then
you
know
we
can
discuss.
Is
it
worth
changing
based
on
new
layering,
so.
I
Oh
I
still
have
this.
Yes,
this
was
not
only
about
the
having
suit
report
redundant
in
the
peak
message
and
also
inside
e.
It
was
about
when
we
making
a
draft
I
ran
and
can
always
run
the
cdto
syntax
test,
and
a
suit
report
is
still
having
a
syntax
syntax
era.
So
yeah
it
didn't
Ken
thought
moving
the
suit
report
into
the
eat.
I
A
C
A
B
A
A
I
think
we
did
have
a
discussion,
I'm
thinking
it
was
like
a
year
ago
about
if
we
have
a
teep
specific
suit
example,
then,
which
document
should
a
teach
specific
suit
example
go
in?
Should
it
go
in
a
cheap
document
or
in
a
suit
document
and
I?
Think
at
the
time
like
a
year
ago,
I
think
we
said,
put
it
in
the
teeth
document,
because
it
could
have
gone
either
way
and
I
think
that
was
the
choice
they
made.
So
that's
why
it's
it's
in
here
now.
A
D
D
B
A
C
A
A
Okay,
so
this
one
is
Ken
filed
the
fact
that
GCM
changed
the
CTR
and
T
needs
to
reflect
that,
and
so
Ken
is
proposing
that
we
just
replace
all
uses
of
GCM
with
CTR,
and
so
this
is
why
this
presentation
needed
to
be
after
the
previous
one,
because
now
that
you've
had
the
other
discussion,
the
proposal
from
the
TP
implementers
is
to
replace
GCM
with
CTR.
Are
there
any
objections.
C
A
A
A
J
C
H
The
other
thing
is
I,
so
in
general,
the
attitude
towards
his
confidentiality,
only
ciphers
is,
as
some
of
us
or
some
of
you
have
seen
on.
Amelicus
is
not
great,
so
I
think
we
should.
It
would
raise
some
eyebrows
if
we,
if
we
use
that
sort
of
as
a
preferred
over
GCM,
even
though
we
include
the
signature
on
top
of
the
whole
thing,
it's
it's
so
it's
it's
definitely
worthwhite
to
think
about
it
twice.
In
my
opinion,
even
though
I
can't
see
it
an
attack
and
attack
either.
A
A
Sure
yeah
I
think
we
should
push
to
have
it
be
implemented
before
or
at
the
hackathon
or
whatever.
So
we
can
get
some
implementation
experience
but,
like
I
said,
I,
don't
consider
that
to
be
a
blocker,
but
that's
my
opinion,
but
I
am
an
influenter
and
I
and
I
do
have
the
same.
You
know
dependency
that
you
can
mention
so.
B
D
C
B
C
E
Said
about
CCM
and
GCM
is
you're
not
supposed
to
return
any
plain
text
if
the
Integrity
check
fails,
and
so
the
libraries
that
do
all
that
are
are
structured
so
as
to
comply
with
that
part
of
the
spec.
And
so
the
ability
to
break
a
image
up
into
chunks
is
an
important
aspect
here
and
it
doesn't
fit
with
a
GCM
and
CCM.
A
I
A
Okay,
so
what
I
haven't
heard
is
I
haven't
heard
objections
unless
I
missed
them
to
the
authors
or
the
editors
at
the
T
protocol,
spec,
making
the
change
that
Ken
proposes
here.
So
we
can
ask
again
on
the
list,
but
here
I've
heard
of
a
implementation
questions
and
can
get
stuff
done
and
and
so
on.
But
I've
only
heard
technical
reasons
why
to
make
the
change
and
so
I
think
we
can
go
ahead
and
do
this
in
the
next
one
unless
people
object
so.
B
A
All
right
so
then
there
was
a
question
about.
Is
there
anything
else
to
be
to
be
done
because
our
goal
was
to
be,
you
know
done
by
iagf
118
meaning,
so
we
can
discuss
any
less
things
in
that
meeting
and
so
I
guess
here:
I
wanted
to
open
up
to
Hana.
Since
honest
you
filed
a
couple
of
issues
here.
Is
there
anything
else
you
think
needs
to
be
discussed
in
the
meeting
now
or
is
just
doing
stuff
over
the
list
sufficient
for
the
ones
you
just
found
yesterday
since.
H
A
I
didn't
know
if
there's
anything
that
needed
to
be
discussed
in
a
meeting
in
order
to
make
rapid
progress,
because
if
it's,
if
everything
is
just
editorial,
then
we
can
probably
do
that
on
the
list.
But
if
there's
things
we
want
to
verify
consensus
if
there's
open
questions
how
to
deal
with,
but
since
they
were
opened.
What
you
know
24
hours
ago
or
less
or
whatever
I
haven't
had.
H
One
is
the
the
Manifest
payload
specifically,
and
that
was
the
prime
example
and
that's
already
covered
in
the
suit
firmware
encryption
document,
but
then
there's
encryption
of
the
suit
report,
potentially
and
also
of
the
Eid
and
there
we
can't
directly
use
the
the
the
work
that
we've
done
in
the
suit
firmware
encryption
document,
because
that
relies
on
on
the
on
the
Manifest
and
so
but
the
text
is
what
some
text
India
is
also
applicable.
So
I
created
a
br
to
add
that
text.
H
What
changes
is
is
the
context
information
structure,
because
we
are
encrypting
different
things,
so
I
believe
I've
covered
the
respective
text
for
the
eat
in
the
Deep
document,
but
the
for
the
suit
report.
That
text
would
have
to
be
copied
and
adjusted
in
the
suit
report
document.
Ideally,
that's
my
understanding,
because
I
think
the
it
itself
doesn't
explain
how
the
encryption
really
works.
A
It's
the
last
link,
I
just
pasted
in
I.
Don't
know
if
you
want
to
project
it
on
the
screen.
Just
briefly,
I,
don't
know
how
much
time
we
want
to
spend
on
this
compared
to
the
other
suit
ones.
But
since
this
is
a
joint
interim
and
this
is
we
thought
that
all
technical
issues
were
closed
and
we're
just
doing
editorial
passes
here,
but
if
there's
any
technical
ones,
then
this
is
the
T
part
of
the
meeting
before
Nancy
drops.
B
C
H
C
H
I
I
so
I'm
happy
to
like
to
adjust
the
deck
stores
to
cover
suit
report,
but
since
we're
working
on
in
the
group
on
suit
report,
I
think
it
best
fits
there
and
they
are
in
this
text.
I
for
eat
and
I.
Think
the
same
is
applicable
to
suit
reports
as
well
is
is
just
to
focus
on
a
key
exchange
that
uses
public
key
encryption
and
we
have
EST
for
that.
So
why
not
reuse
that?
D
So
I
I
have
added
more
text
regarding
encryption
in
the
suit
report
and
some
cddl
to
back
it
up.
I'm,
not
sure
if
this
is
going
to
to
cover
the
situation
that
honest
has
encountered
or
not.
Essentially,
what
I've
done
is
reused.
The
suit
MTI
profiles
to
to
construct
a
suit
report-
that's
Integrity,
protected
and
confidentiality
protected
are
all
optionally
confidentiality
protected,
I'm,
hoping
that
that
will
help
for
this
situation,
but
it
might
not
so
I'm
sure
we'll
get
to
that
in
a
few
minutes.
A
But
anybody
else
is
welcome,
but
that
unless
there's
any
other
comments,
then
maybe
you
want
to
go
back
to
the
suit
part
of
the
agenda
to
go
through
the
slides.
If
we
finally
get
to
the
end
and
there's
bills
still
spare
time
which
I'm
guessing
there
won't
be.
But
if
there
is
then
we
can
always
come
back
and
look
at
some
of
the
editorial
prayer
requests
from
honest.
So
is.
A
B
B
H
H
H
H
So
that's
definitely
after
addressing
all
of
those
I
think
we'll
have
a
much
more
readable
document
in
the
end,
they
are
also
what
I
noticed,
and
we
also
have
a
few
old
comments
and
if
there's
time
in
the
meeting,
we
should
have
a
quick
look
at
them,
or
or
at
least
Dave
and
Ken,
just
double
check
whether
you
still
find
these
older
comments,
they
were
from
last
year
whether
they
are
still
relevant
and
if
not,
we
should
sort
of
clean
up
the
GitHub
issued
list.
Essentially,
okay,
next
slide.
F
H
All
right,
thank
you,
yeah,
so
I
think
what
what
is
still
needed
is
to
address
the
other
open
issues.
Brightness
on
the
call
had
spoken
to
him,
Hank
and
and
in
the
orbit
is
not
they
are
not
on.
The
call
unfortunately
haven't
been.
They
haven't
been
active
for
a
little
while
now
didn't
respond
to
my
emails
on
this
issue.
So
I,
don't
know
so
we'll
have
to,
among
the
authors,
make
sure
that
we
get
those
issues
resolved
and
and
make
the
document
more
readable.
H
Okay,
next
one
so
I
was
trying
to
find
out
whether
there's
anything
specifically
I
could
present
and
discuss
during
this
meeting,
but
there
wasn't
really
anything
besides
wording
improvements,
okay,
but
that
doesn't
mean
it
takes.
No
time
like
you
can
easily
work
a
day
on
on
improving
the
the
wording
of
the
document.
B
H
Yeah,
so
we
had
last
at
the
last
IDF
meeting,
we
talked
about
this
document
and
we
decided
that
we
want
to
change
the
context.
Information
structure
and
Lawrence
and
Ken
have
worked
on
on
the
implementation
path,
learns
on
the
update
in
the
D
cozy
library
and
and
Ken
on
the
Lipsy
suit
Library.
So
we
actually
can
update
the
examples.
I
had
email
exchanges
with
Ken
and
he
provided
they
were
posted
the
description
of
what
he
has
been
doing
on
the
mailing
list.
H
Let
him
speak
in
a
in
a
second
in
the
meanwhile,
with
the
JSF
issued.
The
working
group
last
calls
and
we
reached
out
to
reviewers,
because
if
such
a
document
is
always
complicated
to
get
reviewers,
it's
a
very
specialized
field,
and
so
luckily
we
got
a
few
people
to
volunteer.
Marco
is
on
the
call,
for
example,
Michael
as
well:
Who
provided
excellent
feedback
and
I
included.
H
The
links
here,
I
believe
I
have
addressed
those
comments,
at
least
to
to
a
large
extent
that
Michael
is
really
the
only
came
in
today.
I
just
submitted
the
draft
update
and
and
I
I
hope
it
made
it
to
the
list.
That's
why
and
I
need
to
think
a
little
bit
more
about
how
to
better
summarize
some
of
the
key
points
that
he
raised,
but
I
think
with
version
15
I
think
there's
a
much
better
readable
version
based
on
those
leave
your
comments,
so
it
was
really
good.
H
H
H
J
Okay
and
not
so
much
but
I,
want
to
provide
a
YouTube
verify
the
example
manifest
so
because
my
my
code
is
so
complicated
because
it
includes
a
lot
of
features,
so
I
want
to
focus
on
so
anyone
can
verify
the
example
so
give
me
a
time
to
implement
it.
Yeah
I
want
to
create
simple
code
to
verify
the
Manifest
yeah.
H
H
We
had
the
as
key
wrap,
but
it
was
protected,
Integrity
protected
using
a
digital
signature
which
is
kind
of
maybe
a
little
bit
odd,
because
the
MTI
algorithm
is
as
key
wrapped
with
with
a
Mac
I'm
protecting
it,
so
that
that
was
the
next
update,
the
other
one
on
the
esch,
of
course,
the
based
on
the
changes
in
the
context,
information
structure
we
and
the
updated
code
in
decode,
so
that
those
examples
had
to
be
regenerated
as
well.
So.
C
H
C
H
Yeah,
just
as
a
reminder,
what
we
came
up
with
from
is
with
the
context
information
structure
was
essentially
we
had
this.
If
you,
if
you
can
see
the
string
suit,
payload
encryption,
that's
the
part
that
is
tailored
according
to
the
usage
protocol,
so
for
for
the
payload
encryption
using
for
suit
manifest.
This
is
the
the
problem
or
the
string
you
are
using,
but
for
it,
for
example,
or
for
a
suit
report.
H
This
would
be
different
so
to
have
some
distinguishability
and
we
asked
the
identities
from
the
partisan
info
sender
and
the
recipient
as
we
discussed
already
last
time.
So
that
should
be
all
all
great
implementation,
wise
and
also
description,
wise
and
I.
Don't
think
I
messed
it
up,
and
there
was
no
comment
on
on
that.
So,
okay,
next
one.
H
Yeah
address
remaining
working
group
plus
call
feedback.
So
as
as
mentioned
earlier,
that's
on
track.
It
just
got
a
private
review
from
from
synopsis
who
have
been
working
with
in
the
in
Embassy
in
the
in
this
micro
process
of
benchmarking
organization,
and
he
provided
some
further
feedback
which
I
just
received
right
before
the
call
so
I'll
I
will
forward
it
to
the
to
the
mailing
list
and
will
addresses
it
while
I
haven't
read
through
it.
Yet
there
was
no
time
and
so
yeah.
C
H
B
B
B
B
F
F
F
So
I
I
there's
one
piece
where
I'm
not
sure
if
you're
describing
a
profile
or
not
but
anyway,
there's
there's
between
five
and
six
of
of
kind
of
methods,
and
what
I'm
really
saying
is
that
I
really
think
that
it
would
be
worth
naming
them
clearly,
so
that
people
can
pick
one
I'm,
picking
the
red
one,
the
orange
one
whatever
and
I
think
that
will
help
a
lot
for
the
eventual.
You
know
Security
reviews
who
will
be
you'll,
be
able
to
say
also.
F
H
Yeah,
that
was
that
was
a
good
idea.
It
didn't
on
names,
didn't
jump
to
my
mind
instantly,
so
I
I
think
I
have
to
think
about
that
a
little
bit
more.
Also,
the
the
comparison
that
you
were
asking
for
in
a
kind
of
a
comparison
table
for
the
security
consideration
section.
That's
also
something
I
need
to
think
about
a
little
bit
more
I.
H
F
F
So
we're
not
gonna
like
we
know,
there's
been
problems
with
certain
vendors
at
one
point
where
you
know
you,
you
basically
took
apart
one
firmware
and
you
got
the
signing
key
for
the
firmware
and
you
could
spread
it
through
their
entire
mesh
Network
right.
So
we're
not
talking
about
that
kind
of
thing.
It's
just
the
Privacy
that
we're
dealing
with
and
there
so
I
think
that
anyway,
that's
what
my
suggestion
is.
H
B
H
A
A
H
So
so
the
examples
I
it's
a
question
to
Ken
I
think
Ken
should
answer
that
and
on
the
on
on
the
feedback,
it
depends
a
little
bit
on
what
further
feedback
will
arrive.
So
Roots
feedback
is,
is
the
next
one,
but
then
there
may
be,
like
other
people
may
have
additional
feedback
which
I
still
need
to
address.
So
if,
if
it's
only
put
feedback,
I
think
I
can
wrap
that
up
this
week,
but
yeah.
J
B
C
D
C
D
D
I
think
that,
depending
how
you
look
at
it,
trust
domains
can
mean
more
than
one
thing
and
I
was
trying
to
to
group
the
various
extensions
to
the
suit
manifest
around
common
cases
and
and
that
the
the
contents
of
this
document
were
mostly
around
trust
domains
being
whether
those
are
trust,
domains
on
device
or
trust
domains
of
authors.
I,
guess
that's
essentially
the
difference.
D
If
there's
a
possibility
for
a
clearer
title,
I'm
happy
to
change
it,
but
I'm
not
really
sure
what
that
would
be.
Be
hannes
pointed
out
that
the
the
information
around
use
cases
was
really
important
and
needed
to
be
up
at
the
beginning
in
the
introduction,
so
that
people
could
understand
what
this
draft
was
for.
D
H
B
E
D
That
sounds
good
to
me
all
right.
So
again,
Hannah's
had
a
a
comment
on
this,
which
was
that
there's
not
enough
information
in
there
to
ensure
interoperability.
If
the
report
containers
so
I've
added
a
cozy
profile
for
containing
reports,
what
I
mean
by
a
cozy
profile
is
essentially
this
thing
where
you
and
two
cozy
structures
together
and
I,
think
this
is
where
I
I
mentioned,
that
suit
MTI
is
probably
missing
a
unifying
declaration
for
all
the
profiles.
D
Oh
wow,
that's
incredibly
small
I
thought
it
would
be
bigger
so
that
that's
just
the
the
definition
there
that
I
had
mentioned,
but
essentially
all
that
it
says,
is
that
the
there's
a
cozy
sign,
one
I,
I
I'm,
not
sure
I
couldn't
come
up
with
an
a
reason
for
having
more
than
one
recipient
available
for
a
a
cozy
signature
or
a
oracosem
Mac.
It
only
made
sense
to
me
to
to
to
sign
up
for
the
verifier
if
that
makes
sense.
D
D
A
H
Yeah,
hey
Frank,
that's
definitely
better,
but
I
still
think
you
need
to
copy
that
text
in
the
happy
to
create
a
pull
request
to
your
repository.
To
specifically
like
it's
it's
not.
This
is
not
a
huge
amount
of
text
like
we're
talking
about
maybe
two
paragraphs
here
to
just
add
the
necessary
text,
to
get
the
to
sing
out
the
the
use
of
esdh
and
to
change
the
context,
information
structure
and
then
I
think
you
are
done
because
yeah.
D
D
Answers
my
question:
brilliant
that'll,
be
it
perfect?
Now
we
have
to
find
where
it
starts.
Let's
see
there,
it
is
okay,
good,
so
yeah.
This
is
a
really
short
one.
There
were
a
couple
of
missing
keys
for
override
multiple
and
copy
params
I'm,
hoping
that
this
will
resolve
the
remaining
outstanding
issues.
I'm,
not
aware
of
any
further
ones.
So
I'm
happy
to
have
this
progress
to
working
group
last
call
if
no
one
has
anything
else
to
add.
A
A
So
maybe
we
should
ask:
have
people
read
this
draft
because
you
know
we
we
could
be
done,
but
we
did
the
working
group
last
call
house.
We
get
people
to
read
or
to
say
yes,
I,
think
it's
ready,
so,
okay,
if
we
can
get
a
a
person
or
two
to
just
say
yes,
I,
think
it's
ready
nothing
to
discuss.
Somebody
well.
D
How
about
I
turn
that
around
instead
and
say
Dave?
You
already
reviewed
this
and
we
made
changes
based
on
your
review
to
add
additional
file
permissions
in
addition
to
that
Akira
I.
No,
it
was
The
Cure.
No,
it
was
Ken.
Ken
reviewed
this
one
as
well,
and
Ken
looked
at
it
and
said
spotted
the
missing,
override,
multiple
and
copy
params
keys
and
I
think
he
spotted
a
couple
of
other
things
and
I
fixed
those
in
response
to
his.
Oh,
no.
He
made
pull
requests
which
I've
merged
as
a
result
of
that
review.
A
So
I'm
the
document
Shepard
on
this
one,
which
is
why
I'm
kind
of
poking
here,
because
I'm
going
to
do
a
document,
Shepard
write
up
I,
don't
think
I've
done
that
one.
Yet
on
this
one
I,
don't
think
I've
done
the
document,
Shepard
right
up
yeah
so
that
yeah
yeah
I've
not
done
the
write-up
yet
so
that
is
my
next
step.
Is
I'm
going
to
do
the
document
Shepard
right
up
so
I
have
the
action
on
this
one.
A
If
there's
anybody
else
that
can
comment
that
says
yes
I've
addressed
that,
and
that
will
help
me
in
doing
the
document
Shepard
right
up
because
I
don't
want
to
say
there
was
working
class
called
and
it
was
complete.
Silence
right,
I
want
to
say
something
better
than
that
when
I
did
the
document
Shepard.
That's
why
I'm
poking
on
this?
So.
A
A
A
B
A
A
B
A
J
D
I
I
guess
I
should
clarify
on
this
one
I,
don't
think
it
can
be
complete
at
this
stage.
I
I
strongly
suspect
that
there
will
be
things
it's
missing
discovered
in
the
future
and
and
if
that
does
indeed
happen,
that's
actually
a
good
thing.
It's
a
sign.
People
are
using
suit
quite
a
lot,
because
you're
not
going
to
find
things
that
are
missing
from
it.