►
From YouTube: IETF111-TEEP-20210730-2300
Description
TEEP meeting session at IETF111
2021/07/30 2300
https://datatracker.ietf.org/meeting/111/proceedings/
B
B
B
Provisioning
working
group-
I'm
just
gonna-
try
and
go
through
this
quickly
by
now,
hopefully
you're
all
familiar
with
the
note.
Well,
so
I
don't
think
I
need
to
go
through
this
one
either.
Similarly,
with
the
meeting
tips,
I'm
just
gonna
bypass
that
and
get
to
our
agenda
bashing.
So
first
off,
I
wanna
have
a
huge
thanks
and
shout
out
to
hannes
and
to
ming
for
signing
up
to
help.
Take
notes.
That'll
make
my
life
a
lot
easier.
B
B
D
D
D
Yep
in
case
you
were
missed
the
session
yesterday.
I
will
reintroduce
this
slide
here
and
we
continue
the
discussion
that
we
were
in
the
middle
of
when
we
ran
out
of
time
yesterday
and
so
as
a
reminder
section
4.2
of
the
t
protocol
spec
says
that
the
tam
can
query
the
teep
agent.
That's
what
runs
on
the
device
to
see
if
it
supports
ocsp
via
the
complete
capability
discovery
exchanges
described
above,
but
then
it
does
not
actually
describe
any
capability.
Discovery
exchange.
There's
no
way
to
query.
It.
D
There's
no
way
to
report
it,
and
so
the
question
is:
what
should
we
do
about
that?
And
so,
during
the
session
yesterday
there
was
some
discussion.
I
think
russ
had
an
argument
that
you
know
there
might
be
things
that
you'd
want
to
use
other
than
ocsp
in
some
cases,
and
so
maybe
we
do
need
a
negotiation
mechanism.
D
So
my
reading
of
the
discussion
so
far
is
that
I
heard
arguments
I
heard
originally
one
or
two
people
argued
for
option
one,
but
then
we
had
people
that
got
in
line
that
argued
for
option
two,
and
I
did
not
hear
any
responses
to
that,
and
so
I
think
the
consensus
is
leading
towards
option
number
two,
but
I'm
not
sure
yet.
So,
let's
restart
that.
D
I
think
russ
mentioned
cms
or
something
like
that,
and
so
at
this
point
I'd
like
to
open
this
up
for
our
discussion
to
say:
should
we
deal
with
option
number
two
and
if
we
go
with
option
number
two,
what
should
be
in
the
initial
list
of
possibilities
and
is
there
anything
that
is
mandatory
to
implement
or
is
there
nothing
that
is
mandatory
to
implement?
So
that's
the
set
of
questions
that
we
like
to
restart
discussion
on
here.
E
D
So
the
I
mean
feel
free
to
propose
a
different
meaning
of
option
two,
but
the
meaning
of
option
two.
That
would
be
the
most
consistent
with
the
negotiation
of
cipher,
suites
and
negotiation
of
freshness
mechanisms
is
that
there
is
some
implied
default
which
gets
you
the
mandatory
implement
question.
The
implied
default
might
be
nothing
or
might
be
ocsp,
depending
on
what
we
would
decide,
but
there's
some
default
that
that,
if
you
want
to
know
specifically,
then
what
the
tam
does
is
it
sets
the
data
item
requested
field
to
set
the
bit.
D
That
says,
please
tell
me
what
you
support
as
far
as
you
know:
ocsp,
or
equivalence,
okay
and
then
in
the
query
response
there
would
be
an
array
of
zero
or
more
entries,
the
the
device
being
the
type
agent
would
say,
and
here's
the
set
of
things
that
I
support.
So
there
would
be
a
value
for
ocsp
and
if
cms
or
whatever
else
was
an
alternative,
there
would
be
a
value
for
that
and
the
device
could
say
which,
which
of
those
zero
or
more
of
those
possibilities.
That
is
in
this
registry.
E
D
The
next
slide
there's
a
separate
issue.
That's
what
do
you
do
with
ocsp?
That
is
the
next
slide,
which
is
right
now,
we've
factored
them
two
issues.
Can
you
discover
a
thing?
Can
you
discover
the
capability
and
then
what
does
the
capability
used
for
both
of
those
are
problems
in
the
document
right
now,
okay,
separate
issue,
okay,
hold
that
question
to
the
next
slide,
because
I
see
others.
Thank
you.
C
But
I
came
to
the
mic
line
just
to
say
that
sort
of
in
the
the
general
from
a
high
level
perspective.
If
you
have
a
pki
system
going
on,
you
pretty
much
need
some
sort
of
mechanism
for
conveying
revocation
information
unless
your
credentials
are
so
short-lived
that
you
can
get
essentially,
revocation
just
by
not
renewing
the
credentials
and
letting
it
expire.
A
This
is
a
protocol.
We
actually
start
we
just
by
default.
We
is
sending
asp
stapling
right
so
request
it
to
send
a
list
of
statements.
Data
is
put
in
there.
We
do
not
negotiate
the
cypher
suite
or
what
you
should
sign
in,
but
we
send
over
or
assume
the
device
tp
agent
process.
If
you
cannot,
then
response
may
say
I
don't
support
it.
So
now
this
one,
this
slides
more,
is
it
proposing
new
requirements
about
the
negotiation
piece
or
the
discovery
piece
complete
discovery?
I
think
this
is
new
right.
A
I
just
would
go
back
to
whether
we
could
just
fall
back.
It
says
time
is
always
can
get
the
whole
system
stabling
right,
I
think
that's
a
basic
functionality.
It
can
always
send
the
data
over
say
I'm
not
revoked
right,
so
get
out
of
proof
and
leave
that
to
tip
agent
to
process
right.
These
have
a
policy.
It
says.
Okay,
this
is
term
server,
trust
based
on
the
cell
speed,
stapling
data,
so.
D
I
don't
see
russ
here,
but
the
argument,
as
I
recall
that
russ
was
making
yesterday.
If
I
understood
it
right
is,
if
you
have
a
constrained
device,
if
ocsp
stapling
is
not
mandatory
to
implement
on
the
tam
and
the
chief
agent
side,
then
sending
it
large
amounts
of
data
might
be
difficult
for
constrained
nodes
as
far
as
power
and
bandwidth
goes,
and
so
I
thought
he
was
arguing
that
there
might
be
more
constrained
friendly
solutions
than
ocsp
stapling,
but
I'm
not
sure
I
got
his
argument
right,
but
that's
how
I
interpret
it.
D
Okay,
so
I'm
expecting
you
three
to
stay
in
queue
or
whatever
come
back
in
the
queue
your
preference,
this
one
didn't
fit
on
one
slide,
so
it's
actually
split
into
two
slides,
so
issue.
148
is
what
would
you
do
with
ocsp?
Okay,
so
in
section
4.2
it
actually
mentions
ocsp
data.
Okay,
you
can
see
section
4
with
the
query
request.
D
The
tam
provides
ocsp
data,
so
the
teep
agent
can
validate
the
status
the
search
chain
without
making
its
own
external
ocsp
service
call
right
and
then,
similarly,
in
security
considerations,
the
tp
agent
should
meaning
it's
already
optional,
but
it
should
use
the
ocsp
information
to
verify
the
validity
of
the
certificate
as
well
as
intermediate
certificates.
Okay,
so
that's
what
those
two
sections
talk
about
it
being
a
should
to
implement
and
and
that
the
tam
should
be
providing
it
right.
That's
what
the
document
says
right
now.
D
Okay,
however
section
4.1.2,
which
is
a
section
on
what
you
do
to
validate
a
team
message,
does
not
mention
anything
about
ocsp,
so
it
doesn't
say
how
you
do
it
there's
a
set
of
steps.
That's
there,
it
does
say,
follow
the
steps
in
8152
for
validating
a
cosy
sign
object,
but
of
course
the
8152
does
not
contain
any
mention
of
ocsp
itself.
Okay,
so
that's
half
of
it.
So,
let's
advance
to
the
next
part
in
the
next
slide,
still
on
the
same
issue
here
all
right.
D
D
This
is
a
quote
from
the
old
otrp
spec
that
we
had
validates
that
the
request
stamp
certificate
is
chained
to
a
trusted
ca
that
the
te
meds
is
a
trust
anchor
cache
the
stapling
data
and
certificate
replication
check
status
for
other
subsequent
requests
and
can
use
its
own
clock
time
for
the
ocsp
stapling
data
validation
right.
So
it
had
explicit
steps
in
here
when
receiving
a
message
of
how
you
validate
the
teep
message
by
checking
for
a
certificate
revocation,
the
current
document
never
says
the
check
for
certificate
reputation
right.
D
He
says
the
team
should
send
it
to
the
t
page
and
could
and
the
t
patient
is.
It
should
implement
ocsp,
but
it
doesn't
say
how
so
this
is
an
equivalent
tax
that
otrp
had
so
the
question
in
issue
148
is:
should
we
add
some
similar
text
like
what's
on
the
screen
here
into
the
t
protocol
spec
or
is
there
some
other
document?
That
already
does,
because
8152
doesn't
that
you
could
reference
or
should
we
say
something
else
or
say
nothing
right?
D
E
All
right
harness
yeah.
Well,
if
we
assume
that
ocsp
stapling
or
ocsb
in
general
is
a
good
solution,
then
I'm
a
little
bit
worried
about
the
sort
of
the
interplay
with
cosy
because,
as
you
correctly
said,
on
a
previous
slide,
it
actually
doesn't
talk
about
how
that
works,
and
the
encoding
is
also
different.
That
maybe
cr
make
add
a
lot
more
code
defeating
a
little
bit
the
point
of
the
cozy
encode
or
the
c-boy
encoding.
E
E
D
E
E
In
fact,
mptls
doesn't
even
implement
ocsb
because
there
was
never
the
demand
for
this
on
on
any
constraint
device,
and
the
reason
is
also
why
it's
not
used
in
in
many
places
is
because
you
can
bypass
the
whole
story
by
an
update
software
update
mechanism.
That's
what
the
browsers
do
as
well.
They
update
certificates
and
because,
ultimately,
if
you
find
out
that
important
certificates
have
been
revoked
or
otherwise
compromised,
you
need
to
do
something
about
it.
So
I'm
curious
on
what
the
story
here
is.
D
A
I
think
yeah,
I
think
honestly,
is
a
good
point,
but
I
would
say
still
a
lot
of
cases
we
use
certificate
and
with
certificate
is
a
relatively
long.
Lift
right
is
a
revocation,
so
if
it
is
revoked,
shouldn't
decline
to
check.
So
if
we
just
ignored
that
broken
the
ecosystem
right,
I
think
once
I
have
certified
case,
it
should
have
some
revocation
check
if
a
publicly
used
will
imply
implicitly
that
a
key
is
a
violate
right.
A
You
have
nowhere
to
revoke
and
check
whether
it's
revoked
you
just
trust
it
right,
but
even
certificate
wise
used
it
for
that
purpose.
Right
notification
now
come
back
and
say
who
says
they're
playing
with
ossp.
I
think,
as
I
would
go
back
and
say,
do
we
support
this
revocation
check
right.
You
can
use
those
statements
one
way
if
you
know
where,
because
for
devices
it's
not.
If
you
want
to
go
out
to
us,
it's
required
directly
and
as
an
analogy
whatever
brother,
yes
and
a
chromosome,
they
have
as
a
function
update.
A
You
could
load
ci,
or
this
is
a
intricate
right,
a
subset
to
the
brothers
to
shorter
cut
that,
but
they
still
do.
Listen
appear
as
to
my
understanding.
They
do
try
to
do
ssp,
but
it
doesn't
fail
open
with
a
very
close
and
they
use
that
cio
delta.
So
the
data
as
a
stop
gap
right
stop
gap
to
enhance
that
revocation
check.
So
the
purpose
is
still.
Does
we've
clearly
checked
it's
a
how
part,
so
I
think,
as
a
requirement
here,
a
compiler
said
we
should
write
to
verification
check
by
client.
A
A
C
Okay
ben
right,
so
I
think
han
has
covered
a
lot
of
the
key
points.
You
know
you
need
that
we
switch
to
using
cozy
and
cozy
by
default,
assumes
you're,
not
using
certificates,
and
so
even
dave
you
had
asked
the
question
here:
would
ocsp
make
sense
with
non
x519
certificates,
and
the
answer
is
probably
not
really
so
I
guess
the
answer
here
is
that,
since
we're
using
cozy,
we
probably
don't
need
to
talk
about
ocsp
quite
so
directly.
C
D
So
we
actually
had
an
issue
in
the
get
in
the
architecture
document
that
resulted
in
text
changes
that
are
in
there.
Now
that
the
the
issue
was
filed
when
the
question
was
asked
because
could
you
use
the
teat
protocol
for
managing
your
trust
anchor
store?
And
the
answer
is
yes,
and
so
there's
discussion
in
the
architecture
document
about
that
right
now
right,
you
can
treat
your
trust
anchor
store
as
just
another
component
that
could
be
updated
via
the
t
protocol.
D
If
you
wanted
to
do
it
that
way,
and
so
there's
nothing
special
that
you
have
to
do
with
the
protocol.
It's
just
another
set
of
content
that
you're
installing
across
you
know
the
security
protocol.
So
one
approach
is
what
I'm
hearing
is.
We
could
remove
all
mention
of
ocsp
and
stapling
data
from
this
document.
D
D
If
I
understood
your
suggestion
correctly
and
the
document
should
not
mention
ocsp
anywhere
in
it,
and
if
you
did
that,
then
to
just
respond
to
ming's
point,
then
maybe
we
don't
put
any
negotiation
mechanism
into
here
and
we
just
leave
it
out
of
scope
and
say
well,
you
can
use
the
teat
product
called
update,
your
trust
anchor
store.
And
if
you
want
to
revoke
something,
that's
what
you
do.
D
Because
I
think
that
would
then
resolve
both
of
the
past
two
issues
was
because
there
would
be
no
negotiation
mechanism.
We
would
remove
all
mention
of
ocsp
and
it
sounds
like
ming.
You
would
want
us
to
add
a
sentence
very
similar.
Well,
we
should
like
the
first
bullets
first
sub
bullet,
that
one
still
applies,
because
that
one
still
doesn't
mention
ocsp
the
second
bullet.
D
Sure
I
think
we
have
some
text
someplace
that
is
not
specific
to
certificate
and
that
in
like
in
the
architecture
document
that
we
could
steal
and
use
the
same
wording.
That
sounds
good
because,
if
you're,
just
using
straight,
you
know
public
keys,
you
know
public
key
cryptography
and
note
with
no
certificates.
Then
you
can
just
say
you
know,
validate
that
the
request
tam
public
key
is
in
the
trust
that
you
know
it
is
a
trusted
is
in
the
trust,
anchor
store
right
which
matched
the
little
table
we
had.
So
we
could.
D
D
But
if
you
flip
back
and
forth,
you
can
probably
conclude
that
four
one
one
and
four
one
two
are
actually
referring
to
10.4,
but
the
use
is
unclear
to
implementers
right.
There's
no
cross
references,
there's
no
use
in
the
example
or
cdal
a
document,
and
so
the
reader
wonders.
How
does
this
relate
to
the
cose
sign?
One
tagged
thing,
and
so
we
need
to
see
for
expert
to
say
what
the
document
should
actually
say
here
and
what
the
example
should
actually
show
so
harness.
E
Yeah
I
wanted
to
I
I
only
now
saw
the
chat.
I
wanted
to
come
back
to
the
previous
issue
and
respond
to
one
comment
from
david
brown.
Okay,
if
that's
okay,
he
was
saying
that
the
issue
is
that
the
mcu
boot
is
generally
mutable
and,
of
course
like
that.
That
would
obviously
be
a
show
stopper
for
the
update.
E
On
the
other
hand,
if
you
I
think
there
are,
there
are
also
ways
to
deal
with
this
like
having
a
second
stage
bootloader
and
but
clearly,
and
that's
probably
something
that
we
need
to
write
up
or
describe
better.
The
issue
is
that
at
some
point
in
time,
the
rule
of
thrust
there
is
various
different
parts
of
the
root
of
trust,
hardware,
software
and
also
configuration
data.
E
You
can't
change
it
so
so
like
in
our
case,
what
we
do
is
we
have
a
second
stage,
bootloader,
even
or
even
a
third
stage,
bootloader,
depending
on
what
system
it
is,
so
you
can
still
update
everything,
except
for
the
first
one,
which
is,
which
is
part
of
the
root
of
trust.
So
I
think
we
can
get
around
this
to
a
certain
extent
by
by
appropriate
wording,
but
it's
obviously
an
important
point
and
that's
why
I
copied
it
into
the
meeting
minute
so
that
we
don't
forget
it.
D
Yeah,
I
saw
the
chat
that
there's
two
ways
of
doing
it,
depending
on
your
implementation.
David's
point
was
even
if
it's
immutable,
you
might
be
able
to
pass
a
crl
as
the
mutable
configuration
and
just
and
just
be
able
to
use
teep
to
update
the
crl.
I
think
that
was
david's
point,
and
then
your
point
is
yeah.
You
could
do
is
two
stage
boot
loaders
and
the
second
one
is
mutable
and
you
could
do
stuff
there
so
yeah.
It
depends
on
your
computation
right.
D
C
147
ben
you're,
in
the
queue
I
was
up
for
147
the
absence
of
some
other
cozy
expert,
so
in
general,
or
co,
seabor
expert.
Really
so
in
general.
For
seabor,
you
can
have
a
bunch
of
the
different
data
structures
like
the
integer
map,
string
text
string
whatever,
and
sometimes
you
might
want
to
preface
them
with.
C
And
so
the
reason
I'm
thinking.
That
is
that
in
four
one
two,
we
say
that
the
validation
step
is
going
to
remove
the
t
message
tag
and
then
verify
that
there's
a
cozy
seaport
tag
after
it,
and
so
that's
sort
of
implicitly
putting
a
requirement
that
there
is
the
cozy
secret
tag
following
it
and
that's
what
directly
maps
up
to
the
cozy
side.
One
tagged
at
the
bottom
that
you
have
so
the
octathorp6.18,
because
he
sent
one,
is
the
diagnostic
notation
for
the
tag
that
corresponds
to
the
the
cozy
sibor
tag.
D
Help,
maybe
the
but
you'll
notice
that
you
know
411
and
412
is
still
saying
all
of
that
goes
inside
of
a
teep
session,
so
you've
got
a
context
that
says
that
it
is
t
already.
I
think,
and
so
is
there
any
value-add
that
a
cheap
seabor
tag
actually
provides
by
putting
it
into
the
cheap
protocol,
because
normally
you're
not
trying
to
de-multiplex
and
say
this
one
is
t
versus
something
else
right.
We
have
other
mechanisms.
C
C
D
I
saw
that
yeah
yeah,
okay,
so
that's
my
conclusion
as
well
as
it
does
not
add
value.
Unless
somebody
comes
in
and
says
no,
no,
you
need
it
for
the
following
reason:
right
and
it's
easier
to
just
remove
these
sentences
from
four
one
one
and
four
one
two
and
all
of
10.4
rather
than
trying
to
add
examples
or
whatever
is
to
that
actually
start
to
show
it.
D
D
D
F
The
only
reason
you
would
use
a
tag
on
the
cosy
sign,
one
is
if
it
were
acceptable
to
use
a
cozy
sign
as
well,
and
you
needed
a
way
to
disambiguate
that.
Likewise,
if
you
wanted
a
variant
where
you
had
cozy
mac
or
cozy
mac
0,
you
would
also
need
to
have
a
tag
so
that
you
could
identify
exactly
which
authentication
object.
You
are
using.
D
Okay,
that
makes
sense,
I
think,
the
four
one
one
and
four
one
two
text
originally
came
from
hanas,
who
did
the
first
rev
of
the
heap
one?
Did
you
have
anything
else
in
mind?
I
think
currently
it
only
supports
sign
one.
Is
there
any
reason,
honest
that
you
know
of
to
support
any
other
alternatives
that
brandon
mentioned.
E
F
So
the
the
clarification
that
you
would
probably
want
here
is
that
cozy
sign
is
what
you
need
if
you're
ever
going
to
have
multiple
signers.
So
if
you
ever
need
threshold
signatures-
or
you
know
two
sign-offs
to
to
be
able
to
do
something-
then
you're
not
going
to
get
all
the
way
there
with
cozy
sign.
D
One
okay,
so
I
can
see
three
different
ways
that
we
could
go.
We
could
say
we
just
embed
because
they
assign
one
directly
the
next
one
is.
We
could
create
a
a
teep
tag,
which
is
basically
what
10.4
is
doing
right
now.
That
gives
us
that
flexibility.
If
we
need
to
do
something
else
in
the
future,
and
then
I
guess
the
third
possibility
is
we
could
just
embed
cosec
sign
one
tagged
in
there
and
use
the
6.18
as
the
way
to
disambiguate.
Those
would
be
three
possible
approaches
we
could
take
so
far.
D
I
heard
people
are
arguing
for
the
just,
remove
it
and
don't
provide
that
flexibility,
but
that
was
before
you
jumped
in
to
ask
about
that.
So
I
think
it's
worth
reasking.
The
question
now
is:
do
people
think
we
should
have
a
tag,
whether
it's
a
teep
specific
one
or
the
generic
cozy
sign
one
tagged
value
to
do
to
as
a
discriminator
in
the.
D
D
E
D
Okay,
so
unless
somebody
argues
that
we
need
that
flexibility,
thank
you
brandon
for
the
explanation,
and
so
I
take
it
as
that
has
not
changed.
The
proposed
resolution,
which
is
to
remove
the
tag
and
just
use
cozy
sign
one
directly
as
the
so
unless
somebody
has
a
compelling
reason,
then
we'll
do
that
in
the
next
rev
of
the
document
and
we'll
see
if
people
like
that.
So,
okay,
I
don't
see
anybody
in
queue
and
so
yeah.
Okay.
D
Next,
I
enter
a
registration
policy,
so
the
spec
currently
has
two
inter
registries
in
there,
the
cipher
suite
registry
and
the
fractious
mechanism
registry,
and
so
in
the
iona
considerations.
It
says:
hey
we'd,
like
these
two
new
registries,
but
it
doesn't
actually
see
what
the
registration
policy
is
8126,
which
is
the
rfc
that
says
what
you're
supposed
to
put
in
it.
D
Considerations
says
that
whenever
you
create
a
registry,
you
have
to
say
what
the
registration
policy
is,
and
it
gives
you
us
a
menu
to
pick
from
okay,
and
so
we
have
to
pick
one
of
those
for
each
of
those
two
registries
and
actually
say
what
what
the
expectations
for
iona
is.
Okay,
so,
for
example,
for
cypher
suites
and
precious
mechanisms,
is
there
any
reason
to
allow
private
or
experimental
use,
or
is
it
just
straight?
You
know
you
get
a
red
value
in
the
registry,
and
the
registry
is
simple
within
the
registry.
D
Finally,
what
information
should
I
request
or
if
I
want
to
add
a
new
cypher
suite,
what
do
they
need
to
supply
in
a
form
or
free
form,
email
or
whatever,
to
require
to
say
I
have
a
new
cypher
suite
request.
What
do
I
need
to
provide
to
ask
for
it?
Okay,
soon
to
fill
that
in
into
our
honest
consideration
section
before
we're
done
so
any
thoughts
on
policies
or
any
of
the
bottom?
Three
questions.
D
E
D
No
opinion
the
least
workers
did
not
mention
anything
about
use
for
private
or
experimental
use
that
you
got
to
get
an
allocated
value
now,
whether
that
would
cause
problems
for
implementers,
for
I
have
no
idea,
but
that's
kind
of
my
question,
but
if
nobody
asked
for
it,
then
we'll
naturally
leave
that
out.
But
since
most
registries
don't,
but
some
do
so.
D
D
Okay,
no
opinions,
okay,
good
to
know
it
means
nobody
has
a
strong
opinion.
Just
about
anything
is
okay!
There's
a
house
like
there's
a
suggestion
for
specification
required
and
nobody
arguing
for
anything
else.
So,
let's
go
on
to
the
next.
Oh
anything
else
in
chat
here
seems
reasonable,
looks
good.
D
Okay,
thanks
guys,
daniel
subway
sounds
great
all
right,
and
so
with
that,
so
I've
gone
through
most
of
the
issues
that
were
filed
during
the
hackathon
and
then
there's
one
github
issue
that
we
discussed
last
time
and
where
we
said
there
was
a
github
issue
filed
that
had
to
do
with.
What's
the
t
profile
for
suit
and
last
ietf
we
talked
about
a
desire
for
four
things
being
added
into
the
document,
and
so
I'm
just
looking
at
the
minutes.
D
The
the
bullets
from
the
minutes
from
last
ietf,
which
was
there
was
suggestions
for
two
sample
suit,
manifests
for
specific
cases
and
two
sample
suit
reports
for
the
success
and
failure
cases
and
so
brendan,
took
on
the
task
of
working
on
that
particular
issue.
And
so
I'm
now
going
to
hand
it
over
brennan
to
talk
about
the
suit
manifest
examples
and
the
suit
report.
Examples
that
are
proposed
for
adding
into
the
t
protocol
document.
So.
F
F
The
ta
is
going
to
be
saved
to
a
file
which
is
the
unpronounceable
uuid
there
in
rpmb,
and
the
ta
developer
doesn't
want
to
use
a
second
tam
they're,
just
going
to
use
an
https
server
to
supply
the
personalization
data.
Now
the
tam
will
deliver
unique
personalization
data,
manifest
to
each
ta
instance,
and
each
personalization
data
manifest
will
have
a
dependency
on
the
ta
manifest
the
personalization
data
manifest
and
the
ta
binary
manifest
are
going
to
be
delivered
in
a
teep
update
message
and
the
personalization
data
will
be
delivered
via
an
https
uri.
F
F
F
Next,
we
get
to
the
components
that
are
defined,
so
one
component
is
defined
in
this
manifest
and
that
component
is
a
path.
Essentially
now
the
first
element
is
opti.
The
second
one
was
supposed
to
be
rpmb,
not
exactly
sure
what
happened
there.
There
may
be
a
bug
in
the
suit
tool.
I'll
have
to
take
a
look
at
that
and
then
the
third
element
in
the
path
is
config.json
and
that's
the
name
of
the
file.
F
F
F
Then
an
image
digest.
So
that's
the
digest
of
config.json
in
this
case,
and
there
should
be
a
size
in
there
and
I'm
not
sure
why
there
isn't
then
there's
a
condition
vendor
identifier
and
condition
class
identifier.
I
think
I
must
have
missed
copying
something
into
the
slides.
There
really
isn't
normally
an
image
size.
F
F
F
Now,
yes,
dave!
I
see,
I
see
the
the
chat.
I
will
talk
about
that
when
I
actually
get
to
the
ta
manifest.
That's
that's
coming
up,
but
for
this
part
it's
fetching
the
config.json
or
it's
declaring
the
config.json.
So
you'll
note
that
it
says
it
does
a
process
dependency
before
it
does
any
fetching.
So
that
would
be
an
opportunity
to
do
an
attestation
following
that
process
dependency.
F
Now
there
isn't
currently
a
command
in
suit
for
doing
an
attestation
for
instructing
the
the
tee
when
the
right
time
to
a
test
is,
and
that
is
an
interesting
question
whether
that
would
be
appropriate
in
this
case.
I'm
not
sure.
I
I
think
that
I
need
feedback
from
the
deep
working
group
on
whether
having
a
way
to
instruct
the
system
when
to
do
an
attestation
is
important
or
not,
but
continuing
on
once
the
dependency
has
been
processed
and
we'll
come
to
what
that
means
in
a
moment.
F
The
next
thing
to
do
will
be
to
fetch
the
component
that's
identified
here,
which
is
the
config.json
and
then
check
its
digest.
So
what
process
dependency
does
in
this
case
is.
It
goes
and
runs
the
install
section
for
the
for
the
dependency
manifest,
so
we'll
come
to
the
dependency,
which
is
the
ta
in
just
a
moment,
once
we've
finished
running
through
the
personalization.
F
Just
runs
the
ta.
Well
I
mean
it
runs
the
process,
dependency
and
the
ta
manifest
presumably
runs
the
the
ta
and
we'll
see
that
in
a
moment
as
well.
Now
this
is,
you
can
think
of
the
the
manifest
is
divided
into
two
sort
of
notional
sections.
There's
the
part
that
you
use
to
install
software
and
then
there's
the
part
that
you
use
to
securely
invoke
software
now,
whether
a
teep
manifest
would
include
these
two
sections
is
entirely
up
to
an
implementer.
They
might
have
their
own
way
of
doing
secure
invocation.
F
F
Next,
I'm
into
the
ta
manifest,
so
the
the
actual
authentication
version
would
look
like
this
sorry.
The
actual
signed
version
would
look
like
this,
so
the
first
element
in
the
authentication
list
is
a
suit
digest,
followed
by
any
number
of
cosy,
sign,
cozy,
sign
one
cozy
mac
or
cosy
max
zero
objects.
F
F
And
next
again,
there's
this
common
section,
which
declares
the
components
and
there's
only
one
component.
This
in
this
case
and
again
there
seems
to
be
some
kind
of
encoding
error.
Rpmb
didn't
come
out
as
as
rpmb.
It
came
out
of
something
else,
and
then
we
have
a
uuid,
but
that's
been
re-encoded
into
binary
and
followed
by
ta.
F
F
Output
then,
there's
again
this
common
sequence,
the
common
sequence
defines
the
parameters
that
are
used
for
this
particular
part
of
the
well,
the
ta,
in
fact,
so
there's
the
vendor
id
and
the
class
id
and
again
the
image
digest
and
the
algorithm
I
id
sorry,
the
image
digest
and
the
image
size
in
this
case
use
that
the
size
is
actually
there.
I
think
I
know
why
the
size
disappeared.
I
think
it's
because
I
didn't
have
a
config.json
to
to
to
hand
it,
and
so
it
just
didn't
get
a
size.
F
D
Before
you
honestly,
I
jumped
in
queue
so
so
my
comment
earlier
was
different
from
this
one.
I
agree
with
everything
you
said,
but
my
comment
earlier
about
was
the
case
where
you
have
one
ta
one
manifest
in
which
case
is
the
personalization
data,
manifest
that
depends
on
another
manifest
the
ta
manifest
my
comment
earlier
was
you
don't
have
to
go
off
and
fetch
the
ta
manifest
from
some
place,
because
you've
already
got
that,
so
they
obviously.
D
D
F
Yeah,
the
one
of
the
overriding
design
principles
behind
the
the
suit
manifest
is
that
many
of
these
operations
are
actually
just
copies
of
each
other,
but
with
different
parameters,
so
it
parameterizes
all
of
the
common
operations
so
that
you
don't
have
to
have
special
cases
for
fetching
a
manifest
versus
fetching
a
payload
they're.
The
same
thing
so
they're
done
the
same
way.
E
Brenton
I
was
wondering-
and
there
was
the
there
was
requirement
that
you-
that
the
personalization
data
is
unique
for
the
instance,
that's
something
you
said
on
the
first
slide
and
the
the
da
binary
that
you
have
on
this
slide,
obviously,
is
the
it's
the
same
for
all
the
devices
on
or
for
the
entire
class
of
devices.
But
how
do
you?
How
do
you
make
sure
that
the
personalization
data
is
unique
for
each
instance?
That's
something
I
missed
somehow.
F
F
No
intentionally,
because
that
there
there's
only
so
much
I
can
fit
in
these
slides,
and
I
promised
you
that
I'd
get
it
in
under
an
hour.
So
so
the
the
point
here
is
that
the
the
way
that
you
ensure
in
this
case
that
only
the
correct
recipient
receives
a
given
set
of
personalization
data
is
through
tls,
client,
authentication
and,
and
that
is
something
that
would
come
up
in
it.
Won't.
Let
me
go
back
far
enough
here.
F
We
go
in
our
initial
assumptions
right
that
the
personalization
data
is
delivered
via
an
https
uri
and
that
the
it's
not
using
a
second
tam,
just
an
https
server.
So
if
you
want
to
ensure
that
there
is
authentication
of
your
clients
and
that
only
the
correctly
authenticated
client
receives
the
correct
data,
then
https
client
authentication
is
probably
the
answer
we
did
want
to
do.
Another
example
where
the
the
ta
developer
used
encryption
to
secure
the
personalization
data.
F
The
issue
that
we
had
with
that
is
that
it
depends
on
the
development
of
the
suit
firmware
encryption
draft,
which
is
still
in
draft.
We
haven't
moved
it
along
far
enough
that
we
are
at
anywhere
near
consensus,
so
that
I
think,
is
why
we
decided
that
we
would
stay
away
from
that
particular
part
of
the
discussion
just
yet
so
when
you
flippantly
asked
intentionally.
The
answer
is
in
fact
yes.
F
Right
so
validate
and
run
are
quite
trivial.
You
check
that
the
image
matches,
and
then
you
run
it
and
we've
got
a
little
bit
of
text
in
this
one
as
well
similar
idea.
It's
got
the
vendor
domain
and
the
model
name
and
those
are
indexed
by
the
component
id,
and
that
is
all
there
is
to
the
example.
Is
there
any
other
questions
happy
to
take
them.
D
Dave
yeah,
so
for
anybody
who
wasn't
in
the
suit
session
a
couple
hours
ago,
there
was
this
discussion
for
everybody
else
that
we
had
about
taking
the
suit
manifest
document
and
moving
a
couple
of
parts
of
it
outside
of
the
core
document
into
extensions.
And
so
my
question
is
this
particular
example.
D
Out
of
the
things
we
talked
about,
moving
to
examples,
because
you
used
to
explain
that
the
firmware
encryption,
which
is
already
a
separate
document,
we
tried
to
pick
an
example
that
does
not
depend
on
that
document.
Only
on
the
course
back,
but
now
that
we're
moving
some
other
stuff
which
of
those
things
that
would
be
moved
into
extensions.
Does
this
depend
on
because
my
first
glance
here
is,
I
think,
there's
only
one
and
it's
the
one
that
covers
dependencies.
It's
going
to
move
out
to
extension,
and
I
think
that's
the
only
one.
F
D
E
G
B
G
It's
this
definitely
the
common
section
will
help
and-
and
I
think
the
difficulty
we
had
was
how
to
yeah,
write
the
order
inside
the
comment
section
and
how
to
express
integrated
dependency
inside
the
command.
So
yeah
yeah-
that's
yeah,
that's
that's,
I
think
yeah.
Definitely
this
is.
This
slide
is
going
to
help
for
the
implementation.
G
F
F
F
So
if
success,
if
it's
been
completely
successful,
if
no
conditions
have
failed,
then
you
get
something
really
pretty
simple.
So
the
first
part
is
a
manifest
digest
and
that's
just
to
reference
exactly
which
manifest
it's
talking
about.
That's
the
root
manifest
the
one
at
the
very
the
root
of
the
tree.
F
So
in
our
example,
that
would
have
been
the
suit
personalization
data
or
sorry
the
personalization
data
manifest,
and
then
it
will
provide
a
uri
if
the
suit
reference
uri
has
been
populated
and
the
idea
behind
the
suit
reference
uri
is
to
provide
a
canonical
location
to
find
that,
even
if
your
distribution
infrastructure
is
different,
that
it
will
always
come
back
to
that
same
place.
This
is
so
that
you,
as
a
you
know,
as
a
network
operator,
can
identify
exactly
what
this
is.
F
Even
if
you
have
a
munged
version,
that's
been
provided
by
a
distribution
network
or
something
like
that
now.
In
this
example,
there's
an
empty
list
of
suit
report
records
and
that's
because
every
condition
in
the
manifest
has
executed
successfully,
and
none
of
them
have
failed.
So
there's
nothing
to
report
receiving
this
report
would
mean
that
everything
is
fine
and
that
there's
no
concerns,
and
I
should
be
clear
that
this
is
separate
from
an
attestation
report,
that
this
is
not
the
kind.
F
F
F
So
what's
happened
here
well,
the
first
element
shows
the
manifest
id
it's
an
empty
list.
That
means
that
it's
the
root
manifest
where
something's
happened
to.
If
there's
a
list
of
integers
here,
then
that
tells
you
how
to
navigate
the
tree
of
manifests
according
to
their
order
in
each
manifest
to
find
which
one
it
was
processing
when
it
encountered
this
error.
F
So
what's
happened.
Well,
it
was
in
the
dependency
resolution
section
now.
This
refers
back
to
the
previous
manifest
example
that
we
looked
at.
So
you
see
in
the
dependency
resolution
section.
The
7
here
is
actually
the
7
that
is
referred
to
by
defendancy
resolution
in
suit
and
then
what's
happened.
Well,
it
was
in
offset
66
offset
66
into
this
particular
section
takes
us
to
the
highlighted
directive
fetch.
F
F
F
So
this
was-
and
I
realized
this
is
slightly
broken
compared
to
the
the
assumptions
we
laid
out
in
the
previous
one
that
both
were
developed
delivered
via
a
tip
update
message.
Well,
in
this
case,
it
wasn't
delivered
via
the
teep
update
message
or
it
was
corrupted
or
something
was
wrong
with
it,
because
when
it
went
looking
for
it,
it
couldn't
find
it.
It's
done.
A
fetch
fetch
has
tried
to
find
it
and
hasn't
located
it,
and
in
this
case
it
is.
D
Okay,
so
for
the
example
that
we
would
want
to
put
into
the
document,
I
think
we
wanted
to
match.
We'd
probably
want
to
show
the
case
where
the
dependency
resolution
of
the
actual
https
uri
to
grab
the
config.data
was
what
failed
say.
It
was
unreachable
or
something
like
that,
and
you
got
a
404
from
that
url
or
whatever
it
was
so.
D
D
D
Yeah
and
then
you
said,
like
the
the
image
size
was
missing
from
the
slide,
and
so
the
example
shows
that
and
then
the
one
that
shows
the
dependency
resolution
of
a
different
url,
but
otherwise
I
think
the
manifests
are
directly
usable,
as
is,
and
the
suit
reports
will
need
those
particular
tweaks
so
but
other
than
that.
I
think
these
are
great
examples
again,
thanks
brennan,
for
putting
these
together
for
us.