►
From YouTube: IETF112-TEEP-20211112-1200
Description
TEEP meeting session at IETF112
2021/11/12 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
A
A
A
A
A
We've
got
akira
providing
us
the
hackathon.
We
still
have.
Our
architecture
and
protocol
drafts
have
been
submitted
to
publication.
For
today,
we've
just
got
the
hackathon
report.
Akira
I've
got
you
and
I
think,
you've
embedded
them
in
your
slides
to
talk
about
the
the
suit
and
teap.
I
think
that
was
also
part
of
your
hackathon,
but
there's
a
github
request
for
this
and
then
the
rest
of
the
time
we'll
spend
talking
about
the
protocol,
see
I'm
like
not
awake.
A
B
G
B
F
D
A
D
D
B
B
Yes,
yes
received
very
early
email
on
tuesday
from
hannes
and
yes,
we
we
jumped
in
and
also
we
had
we
on
the
in
japan
side
in
in
japanese
time,
we
were
working
on
going
through
our
implementation
and
file
filing
issues
on
the
github
and
creating
put
plo
requests
and
the
so
for
the
first.
This
is
for
explaining
what
what
is
steep
first
so
t
honestly,
it's
not
only
about
deep
from
the
beginning
from
the
when
the
protocol
draft
and
architecture
draft.
B
It
was
obvious
that
its
suit
and
rats
was
going
to
be
used
in
the
deep
and
and
the
in
the
format
was
changed
from
otr
p
to
t
was,
then
it
was
from
json.
Then
it
was
obvious.
It's
going
to
be
using
coset,
so
well,
there's
many
things
have
to
be
done
in
making
the
deep
draft
finishing,
which
is
which,
which
is
tough
but
which
is
also
challenging
and
good
good
thing
to
do.
Work,
try
it
so
from
last.
B
I
gifted
this
idea.
We
focused
on,
I
mean
me
and
the
other
people
in
japan
was
yes.
I
would
like
to
call
their
name
name.
Yeah
from
asd
is
suzakson
from
second
takayama
and
tragedy,
and
also
from
yes,
we
joined
on
the
arm
suit
work,
suit,
working
group
hackathon
too,
so
random,
harness
and
and
dave
was
working
on
in
on
his
time
zone
too.
B
And
coming
back
so
we
were,
the
main
focus
was
adding
suit
format
in
the
tip
draft,
yes,
and-
and
we
would
like
to-
we
would
like
to
finish
suit
manifest
example
in
the
tip,
so
everybody
who
is
going
to
use
teep
would
also
understand
how
to
construct
the
suit
manifest
inside.
The
t
protocol
then,
and
then
it
will
in
then
will
be
much
easier
to
have.
The
concrete
cdl
example,
with
the
diagnostic
notation
example
and
the
binary
representation
with
the
commented.
B
B
It's
meant
to
be
a
library
to
support,
to
make
it
easier
who
wants
to
implement
it
cheap
device
or
tam,
and
it's
it's,
and
so
that's
was
adding
this
having
suit
manifest
inside
a
leap,
c
suit
and
also
deep
device.
We
have
an
open
source
yet,
but
we
we
trying
to
working
hard
to
finish
the
implementation,
taking
very
long
time
by
the
way
I'm
after
this
ietf119112,
I
would
like
to
focus
on
finishing
tip
device
implementation.
B
Let's
keep
updating
so
finished,
supporting
draft
zero,
six
of
the
tip
message
portion
and
then
adding
this
exam
example
suit
manifest
format
and
which
is-
and
also
it
says,
integrated
payload
here,
but
it
means
in
the
same
same
with
the
on
the
top
line,
is
adding
tc
binary
inside
the
soup.
Manifest
super
manifest
could
have
only
manifest
and
could
have
binary
and
separately,
but
right
now
we
wanted
to
have
try
having
a
binary
inside
the
suit
manifest
and
make
it
workable
between
the
deep
device
and
time
so.
B
B
Was
it
was
r
or
takayamas
in
our
understanding,
so
we
made
a
issue
listing
pull
request
and,
and
the
the
fourth
is
the
yes.
This
is
something
with
we've
been
doing
from
these
three
months
was
keep
updating
finalizing
the
three
way
of
the
example
in
the
deep
message
of
the
suit
manifest,
and
the
last
is
yes
yeah.
So
this
is
was
my
quick
one-line
pull
request
is,
since
it
was
the
suit
example
and
the
suit
manifest
was
using
es-2556
for
the
corsair.
B
B
Yes,
honestly,
I
did
suffer
a
lot
when
trying
to
implement
the
seaboard.
So
since
I
suffered
a
lot,
I
thought
I
would
put
my
knowledge
into
the
deep
protocol
draft,
so
everybody
else
could
don't
have
to
go
through
entire,
how
to
implement
and
how
to
debug
it
when
the
when,
when
the
negotiation
not
or
point
message
going
back
and
forth
between
the
time
and
deep
device,
probably
whoever
going
to
implement
the
seaboard
problem.
Yes,
I
want
just
wanted
to
make
it
easier
for
them.
B
So
this
is
the
left.
Side
is
c
board.
Diagonal,
stick
not
notation,
which
is
derived
from
reading
the
cdl
and
in
the
right
side.
It's
in
the
in
the
draft
have
a
binary
example,
but
with
the
comment
in
on
it,
so
if
anything
doesn't
work
in
with
the
talking
with
the
other
tier
of
the
on
the
internet,
for
example,
deep
device
and
tam,
then
you
just
go.
You
could
see
the
example
and
which
line
might
be
different
in
the
binary.
B
If
it's
a
json,
it
will
be
much
easier
to
develop
because
it's
text
format
and
if
you
do
the
ether
real,
I
mean
like
it's
not
ethereal
right.
Now,
it's
a
wireshark
and
if
you
see
the
packet
dump,
then
they're
pretty
much
easy
for
them.
If
you
do
the
top
packet
dump
on
the
seaboard
keyboard
binary,
it's
all
hex
decimal.
B
D
B
B
B
B
Now
we
still
using
dot
ta
for
the
convenience,
for
the
understanding
and
and
inside
the
tc
iphone
you
id
dot
t
is
it
doesn't
have
to
be
this
file
name,
you
could
choose
any
kind
of
the
file
name
and
since
since
it's
in
the
arm,
implementation
for
the
opti
was
using
uid
and
the
file
name
of
the
ta.
I
I
added
the
easier
to
parse
it
in
the
mine.
B
You
could
use
the
uid.ta
and
for
the
example
on
the
into
sgx
and
it's
any,
you
could
use
any
kind
of
the
file
name.
So
it's
dc
hyphen
uid.ta,
which
it's
going
to
be.
It
doesn't
have
to
be
using
your
id
or
any
file
name
pointing
to
the
binary
and
then
the
binary
it
has
any
of
the
yeah
hexismo
or
any
binary
inside.
B
The
developer,
who
is
who
create
made
the
binary
of
the
trusted
component,
is,
could
going
to
be
download
from
their
website
or
https
link.
So
you
could
you?
Could
you
will
notice?
The
tip
device
have
downloaded
the
binaries
and
and
and
the
and
the
time
does
do
not
have
to
host
their
the
dc
binary
on
the
temp
side.
So
you
just
you,
just
provide
a
certain
manifest
to
the
deep
device
and
then
the
team,
the
tip
device,
will
get
the
bioneer
binary
from
a
trusted
component
developer.
B
B
H
B
Instead
of
that,
you
are
pointing
to
other
website,
you
have
the
dc
binary
embedded
inside
the
suit
manifest,
as
as
this
very
simplified
written
here
detail
is,
is
in
the
draft,
but-
and
this
is
the
simplified
way
of
the
x
description
so
good,
so
this
one
is
the
more
intuitive.
So
if
the
tip
deep
device
requests
the
dc
binary
to
the
time
server,
then
the
time
server
tip,
update
message
will
contain
the
suit
manifest
with
the
tc
binary.
B
So
you
could
receive
it
in
one
message
and,
and
yes,
it's
just
pretty
much
the
same.
What
opposite?
From
the?
What
I
discussed
with
example,
one
is
the
trusted
component
developer:
do
not
have
to
host
the
binary.
Yes,
it's
and
also
it's
pretty
much
the
same.
What
opposite
of
what
I
I
I
have
just
this
said.
B
The
trusted
component
binary
is
going
to
be
this
by
time.
So
if
yeah
you
just
don't,
have
one
can't,
you
need
to
trust
the
temp
and
you
can't.
You
can't
count
the
trusted
binary,
download
number
or
something
if
you
wish,
but
oh
yeah
yeah,
but
the
good
thing
is
you
don't
have
to
worry
about
it
and,
and
also
it's
the
time
message
from
the
update
message
from
the
tam
to
deep
device
will
contain
the
binary.
So
it
stands.
Probably
it's
going
to
be
tend
to
be
message
will
be.
B
The
size
will
be
larger
than
just
having
a
manifest,
but
I
really
don't
think
it's
a
big
big.
I
mean
big
negative
point.
I
think
it's
it's
that
that's
that's
the
even
even
downloading
a
trusted
company
binary
separate
from
team
device
from
trusted
component
developer
hosted
web
website.
It's
it's
going
to
use
the
same
bandwidth.
B
And
example,
three
is
the
adding
the
example
of
the
what
brandon
have
talked
at.
I
dif
one
last
iedif
when,
when
having
the
personal
data
for
the
particul
for
the
dc
binary
already
inside
the
dc
deep
device,
then
you
could
how
you
could
this
rate?
The
in
this
example
is
the
personal
data
is
the
example
is
having
a
config.json
file,
the
providing
to
the.
B
Depended
tc
binary
is
in
this
example,
is
the
one
already
have
in
the
deep
devices
dc
uid.suit?
So
if
the
dc
device
already
have
the
tcu
id
exactly
the
same
tc
already
installed,
and
these
deep
device
then
could
receive
the
personal
data
with
the
suit
manifest
inside
the
deep
update
message
and
yes,
okay,
yeah.
I
think
I
pretty
much
finished
my
slide
so.
B
Consider
how
to
support
the
corsair
and
the
suit
I
mean
that
I'm
a
tip,
and
yes,
we
we
now
we,
I
don't
know
this
suit,
manifest
for
three
format.
It
should
be
inside
the
deep
draft
or
it
should
be
in
the
suit
manifest
ma'am,
second
draft
or
external
draft,
not
sure,
probably
it's
going
to
be
discussion
with
the
brandon
later,
with
the
dave's
talk
and-
and
yes,
I
just
wanted
to
explain
how
the
seaboard
looks
in
the
tip
yes
and
after
what
I
define
one
line.
B
A
A
B
A
B
If
the,
if
it's
okay,
to
have
the
three
formats
in
the
deep
draft,
it
will
be
yeah,
could
anybody
could
remember,
dave
or
ming
could
merge
it
or
if,
if
it's
more
appropriate,
to
put
put
it
in
the
suit
manifest
external
draft,
which
brandon
have
split
it
last
week,
yeah
we
could
move
that
to
the
to
suit
manifest
draft.
I
really
don't
mind
which,
which
is
going,
which
should
go
into
it,
because
it's
anyway
we're
going
to
use
the
same
format.
H
H
One
question
that
plays
into
that
is
how
much
of
these
examples
suit
generic
versus
teep
specific
right.
So,
for
example,
if
there
was
a
suit
spec
that
had
the
thousand
examples
that
just
didn't
have
teep
stuff
in
it.
Is
that
close
enough
or
does
steep?
I
think
right
now.
Tp
has
one
example
in
there
for
each
message:
type
where
it's
like
the
personalization
date
examples.
I
think
it's
the
closest
to
get
curious
third
example
right,
not
the
first
to
the
second
one.
B
B
B
J
Yeah,
sorry,
I
it
was
hard
for
me
to
press
the
buttons.
I
don't
know
why
this
is
hank
so
yeah
there
is
so
in
principle.
That
is
not
a
problem
to
pull
that
into
the
manifest
draft
or
the
if
it's,
if
it's
just
the
reintegration,
there's
also
merits
to
have
that
in
a
separate
draft.
I
think
we
are
happy
to
help
here
if
it
is
uncomfortable
for
the
cheap
id
to
to
somehow
build
their
around
the
content.
That's
not
a
problem
we
can.
B
J
J
J
J
D
K
K
B
J
H
K
So
I'm
happy
to
put
examples
in
suit
where
they're
appropriate,
but
the
question
is,
if
there
isn't
an
appropriate
document
in
suit
for
a
teep
example
to
land
in,
I
think
it's
just
a
little
bit
incongruous
to
to
shoehorn
one
into
a
document
where
it's
not
appropriate,
so
it
makes
sense
to
me
to
put
you
know:
if
teep
is
a
profile
of
suit,
then
it
should
have
its
own
examples
for
suit.
Does
that
make
sense.
J
A
A
H
E
I
think
my
my
note
in
the
jabber
may
have
been
based
on
a
flawed
assumption.
So
I
think
dave
is
clarifying
that
you
know
the
idea
is
to
have
a
single
document.
That
is
just
examples,
and
the
question
is
whether
to
do
that
in
the
teep
or
the
working
groups
and
I
think
either.
Those
are
fine,
and
I
agree
with
you
that
we're
probably
not
going
to
get
a
clear
resolution
in
the
meeting
right
now.
E
A
H
H
And
we
don't
have
to
answer
it
right
now,
but
I
want
brendan
to
fully
understand
the
question.
So
if
this
is
moved
to
the
list,
then
he
can
appropriately
weigh
in
the
examples
that
akira
walked
through
the
part
of
the
question
that
we
would
love
you
to
weigh
in
on
not
necessarily
the
mic
here,
but
at
some
point
right
is
the
examples
of
things
like
what
does
it
look
like
when
you
take
the
actual
binary
embedded
into
the
suit
manifest?
H
What
does
it
look
like
when
you
have
a
uri
that
points
to
it
hosted
off
off?
The
thing
are
those
things
that
are
inherently
teep
specific
concepts
or
are
those
things
that
are
generic,
and
so
that's
the
examples
he's
going
through
is
those
different
variations,
and
so
that's
why
the
question
is:
is
it
really
something
in
a
tea
profile,
or
are
these
just
examples
of
generic
suit
things
that
should,
or
maybe
already
are
in
in
a
document
in
the
suit
working
group?
H
H
All
right
so
since
111
there
was
a
long
backlog
of
old
issues
that
we've
been
slowly
working
through
in
deep
working
group
meetings
and
we've
now
got
to
the
point
that
almost
all
the
old
issues
have
now
been
resolved
and
we're
only
talking
about
new
issues.
And
so
I'm
going
to
clear
the
backlog
today
in
the
discussions
here
and
then
go
on
to
the
new
ones
file.
But
there
really
aren't
any
old
ones.
H
Previously,
we
kind
of
picked
the
most
important
ones
to
talk
about
in
the
working
group
meeting
and
we've
now
kind
of
cleared
that
backlog
and
so
and
most
of
the
spec
right
has
now
been
implemented
by
at
least
one
implementation
right.
You
heard
akira
mentioned
the
last
pieces
that
were
kind
of
still
in
progress
right,
integration
of
other
things,
but
we
think
we've
fleshed
out
all
of
the
areas
of
the
spec
that
there
might
be
an
issue
until
we
actually
implement
things.
H
All
right,
so
here
are
some
of
the
ones
that
we
previously
discussed
at
ietf
111
and
I'm
not
going
to
go
through
each
of
these
on
slides.
This
is
just
a
list
of
things
that
we
covered
last
ietf
meeting
and
we
had
proposed
resolutions
and
those
have
now
been
incorporated
into
draft
seven,
and
so
we
added
the
error
code
for
no
freshness
mechanism
in
common.
H
H
We
said
you
just
have
to
have
a
update
mechanism
to
update
your
trust
anchors
and
that's
how
you
do
replication
and
so
all
the
different
points
that
were
raised
during
the
meeting.
We
believe
we've
incorporated
those
back
into
the
spec,
and
so
I'm
not
going
to
show
you
the
text,
because
my
belief
is
it
just
matches
what
we
said
and
we
would
invite
you
to
inspect
the
text
yourself.
Just
to
verify
that
if
you
had
an
appointment
point,
you.
H
Make
sure
it's
in
there,
but
we
believe
we've
collected
everything
from
last
ietf
meeting,
so
I
want
to
go
on
and
discuss
new
issues,
and
so,
unless
there's
a
question
on
those,
then
I'd
like
to
go
on.
Let
me
pause
for
a
second
there's:
nobody
in
the
queue
right,
okay,
let's
go
ahead
and
go
on
unless
there's
questions
on
any
of
those.
H
So
all
right,
so
I'm
going
to
walk
through
other
ones
that
were
kind
of
in
the
in
the
backlog,
and
so
this
is
one
that
was
one
of
the
one
of
the
older
ones.
It's
finally
been
merged,
and
so
this
one,
I
think,
was
originally
one
of
the
hackathon
filed
issues
from
maybe
two
or
three
ietfs
ago,
and
the
text
finally
got
merged.
H
So
after
various
edits
and
rebases
and
merge
conflict
resolutions-
and
so
remember
tokens
here
is
the
name
for
the
nonce-like
thing
that
appears
in
a
that
can
appear
in
a
deep
request.
That's
echoed
back
in
the
deep
response
if
the
tam
needs
to
match
requests
and
responses,
and
so
depending
on
the
freshness
mechanism
and
use,
and
so
on
the
token
is
optional,
depending
on
use
case
it's
up
to
tam,
and
so
when
you
are
using
a
token,
sometimes
known
as
announce
right,
it
now
has
actual
requirements
around.
H
You
can't
use
it
for
other
purposes
other
than
this
particular
purpose
in
teep,
and
when
you
issue
a
nonsenate
request,
there
should
be
some
expiration
such
that
you
can't
come
back
three
months
later
or
something
right.
Just
the
expectation
is
you
don't
keep
state
around
forever
right?
So
that's
the
kind
of
the
guidance
that's
in
there
right
now,
so
that
one
is
now
merged
next.
H
H
H
You
send
back
when
processing
an
update
message
does
say
that
you
have
to
echo
back
the
token
if
it's
present
in
the
update
and
the
update
can
include
a
suit
report
and
if
the
suit
report
has
announced,
then
I
should
say
if
the
update
has
a
token,
then
the
suit
report,
if
present,
must
have
the
suit
report
nuds
in
it,
okay
and
so
the
br,
and
I
see
russia
on
the
cube.
But
let
me
finish
the
slide
here
and
then
I'll
go
to
urs.
H
The
proposal
that
I
have
is
just
to
clarify
the
ambiguity
is
to
explicitly
say
that
it's
up
to
the
tam
implementation,
so
in
other
words,
you
are
allowed
to
have
a
token
in
a
delete
message
or
an
update
message
or
a
query
request
message:
it's
not
a
requirement
that
you
use.
You
know
all
three
or
none
of
the
three
you
can
pick
and
choose.
H
Besides
explicitly
saying
that
to
say
that
the
teap
agent
must
ensure
that
the
suit
report
nonsense
present
if
the
update
contains
a
nonce-
and
so
that's
already
implied
okay,
but
it's
not
explicitly
stated
so
we
could
make
that
any
more
explicit
so
ross.
Do
you
have
an
opinion
on
this?
One
go
ahead.
L
L
H
It,
I
think,
the
intent,
and
so
I
think
the
actual
wording
was
authored
by
one
of
our
japanese
colleagues,
but
I
believe
that
the
intent
is
that
it
must
be
different
per
outstanding
request
and
so
and
there's
different
ways
of
doing
that.
And
so
I
there
are
ways
to
not
have
to
retain
state.
So
you
could
have
a
pseudo-random
sequence.
L
H
L
H
H
So
if
we
were
to
run
out
of
time,
I
would
rather
make
sure
we
cover
all
the
eat
stuff
and
not
cover
all
the
other
stuff
that
I
have
or
cover
less
the
other
stuff
that
I
have
so
I've
got
eat
and
suit.
Then
optimizations
in
that
order.
So
here's
the
eat
stuff,
so
there's
been
a
bunch
of
threads
about
this
one
started
off
as
the
rats
meeting
on
monday,
and
so
let
me
just
summarize
the
discussion
I've
seen
so
far.
H
If
there
was
anything
overnight,
I
am
not
up
to
speed,
but
I
I
I'm
up
to
speed
as
of
yesterday
so
yesterday
afternoon,
all
right,
so
there
were
two
issues
related
to
referencing
of
each
one
of
those
is
already
merged.
One
of
those
is
open
to
track
the
remaining
things
and
so
on.
The
left
is
the
sets
of
requirements
and
I'll
go
through
the
the
ones
for
the
second
row
there
and
more
details
in
the
later
slides,
but
this
is
the
one
that
summarizes
all
the
other
ones.
H
H
As
we'll
see,
the
middle
column
is
what
draft
07
says
right
now:
okay,
and
so
there
are
one
two
three
of
those
requirements-
that
draft
07
points
to
the
core,
each
spec
as
meeting
those
requirements,
and
there
are
five
of
those
that
points
to
an
individual
submission,
hank's
document
as
meeting
the
other
five
in
the
hopes
that
those
would
be
merged
into
the
spec
right.
That
was
the
status
as
when
draft
07
was
posted.
Okay
on
the
far
right
side
is
the
current
proposal
for
the
next
draft
other
than
the
yellow.
H
One
is
subject
to
discussion
here
and
so
we'll
talk
about
that
another
another.
There's
a
couple
of
variations
of
how
that
might
be
done
or
not
done
or
whatever,
so
the
other
ones
that
are
currently
point
to
bar
calls.
The
proposal
is
to
point
those
to
the
latest
eat
spec,
because
there's
been
some
rewordings
of
some
existing
things
in
some
cases
and
there's
been
some
new
claims
added
in
other
cases.
H
Okay,
so
the
belief
now
is
that
the
vendor
of
the
device
can
be
specified
using
an
oem
id
claim
and
remember
that
each
has
different
claim
sets.
You
can
have
a
claim
set
for
each
component
right.
Your
overall
evidence
can
have
multiple
claim
sets
one
for
each
layer
or
one
for
each
component
or
whatever,
and
so
oem
id
can
appear
multiple
times,
one
for
each
component
right,
so
the
vendor
of
the
device.
If
you're
talking
about
a
device
claim
set,
then
oem
id
would
be
the
vendor
of
the
device.
H
Similarly,
the
device,
unique
identifier
euit,
could
be
used
as
the
unique
identifier
in
a
claim
set
about
properties
of
the
device.
Okay,
as
opposed
to
the
properties
of
you,
know
the
firmware
or
the
t,
the
tpa
or
whatever
else
so
eoid,
we
believe
could
be
used
for
that
one
and
then
new
in
the
latest,
each
spec
they
added
the
software
identifier.
H
As
you
know
previously,
it
talked
about
coswoods,
but
it
didn't
actually
have
any
formal
text
in
there
that
was
implementable,
and
now
it
does
right,
and
so
now,
in
the
coswood
section,
the
software
name,
the
software
version
can
be
used
to
meet
the.
What
what
the
architecture
document
uses
words
for
firmware
type
and
firmware
version
right.
It
uniquely
identifies
what's
the
firmware,
that's
actually
on
there,
and
so
the
belief
is
that
the
11
spec
draft
11
of
eat
actually
meets
all.
H
But
one
of
the
requirements
of
the
that's
talked
about
in
the
teep
spec
right
now,
the
deep
architecture
document
right
now
and
that's
classic
device,
and
so
that's
what
all
the
remaining
discussions
about
is
that
one
remaining
thing-
and
I
see
brendan
in
queue
so
is
if
you're
gonna
anything
other
than
class
of
the
device
is
in
scope,
for
this
slide
so
feel
free
to
ask
questions
anything
else.
So.
K
This
is
this
is
a
moment
where
we
need
to
be
really
careful
about
how
we
sync
up
between
a
bunch
of
drafts
that
are
in
flight
at
the
moment,
I'm
concerned
and
and
to
to
be
honest
with
you.
I
I
have
not
looked
through
this
to
to
the
extent
where
I
can
tell
whether
oem
id
euid
and
the
current
uuids
specified
in
the
suit
draft
are
compatible
or
not.
K
H
Okay,
all
right,
but
yeah
those
would
be
feedback.
I
think
for
the
rats
working
group,
which
I
would
invite
you
to
the
working
group
session
following
this
one.
So
all
right
unless
there's
any
other
comments
on
any
of
the
other
ones,
then
all
the
rest
of
these
things
are
about
the
classic
device
discussion,
which
has
been
a
active
discussion
this
week.
Thank
you
to
all
of
those
who
have
weighed
in
on
it
and
thank
you
for
coming
to
this
session,
if
you
wouldn't
normally
be
in
teeps.
So
next
slide,
please,
okay!
H
It
does
have
this
notion
of
type
of
firmware
right,
which
I
mentioned
the
previous
slide,
that
the
coswood
can
cover
that
one
and
the
type
of
tee
included
in
a
device
right,
and
so
that's
one
example.
Wording
and
otrp
does
this
so
next
slide,
but
that's
not
our
spec
anymore.
So
it's
just
that
was
a
predecessor
to
what
deep
architecture
has
okay,
so
a
couple
places
in
the
deep
architecture
document
that
actually
specified
the
requirement
that
we're
talking
about
now.
H
Okay,
one
is
here
talking
about
device,
identifying
information,
okay,
attestation
information,
maybe
may
need
you,
you
can
identify
a
device
to
the
tam
right,
that's
more
like
the
the
euid
case
right,
you
need.
It
allows
this
hand
provides
services,
a
device
such
as
managing
installed,
tas,
providing
subscriptions
to
services,
locating
device,
specific
keying
material
to
communicate
with
and
authenticate
the
device
or
authenticate
device.
H
In
some
cases
it
may
be
sufficient
to
identify
only
the
class
of
device
right
if
you're
managing
you
know,
10
000
things,
you
have
the
same
policy
for
all
10,
000
of
them,
not
on
the
device
by
device
basis
for
scalability
right
and
so
what's
the
class
of
the
device
right,
not
the
serial
number,
but
what's
the
what's,
the
model
number
or
some
other
class
or
category
that
applies
to
the
whole
set
of
things
not
on
a
per
serial
number
basis,
where
eoid
is
like
a
serial
number.
Okay
next
slide.
H
The
other
part
of
the
requirement
just
to
verify
is
in
the
tee
identifying
information,
and
this
is
the
type
of
tee
that
generated
this
attestation
might
be,
must
be
identified
right
and
includes.
You
know,
version
information
for
hardware,
firmware
software
and
so
on.
Those
those
other
bullets
are
the
other
rows
in
that
table.
H
Right,
t,
manufacturer
information
for
the
te
right,
that's
like
oem
id
for
the
tee
claim
set
right
is
required
in
order
to
disambiguate
the
same
te
created
by
different
manufacturers
and
so
as
an
example
right
in
the
arm
ecosystem.
Right,
you
have
a
say,
a
trust
zone
dee,
but
the
actual
chip
manufacturer
is
a
very
it's
anybody
that
licenses
the
arm
design
right.
H
So
you
can
imagine
a
trust
zone
with
multiple
oem
ids,
but
it's
the
same
te
type,
which
is
trust
zone
right
so
again,
there's
a
there's,
a
classic
device
there.
In
this
example,
I
think
if
I'm
interpreting,
if
I
understand
the
arm
ecosystem
right,
this
is
an
example
where
there
might
be
a
te
type
that
would
be.
That
would
span
multiple
oem
ids
and
that's
an
important
concept
to
keep
track
of.
When
I
get
to
that
question
in
another
slide
here,
so
all
right.
H
So
hopefully
somebody
will
correct
me
if
I
have
something
wrong,
but
this
is
the
text
that
was
that's
already
passed
working
group
last
call
and
has
passed
on
the
isg,
so
we
already
have
consensus
on
this
text
and
now,
let's
just
we
have
to
talk
about
how
we
can
effectively
meet
these
requirements,
so
go
ahead
and
go
on
to
the
next
slide.
Nancy.
H
H
As
meeting
that
claim-
and
so
this
is
what
we
want
to
replace
with
a
a
a
working
group
document,
whether
this
document
gets
adopted
is
working
or
joking,
but
this
is
really
the
only
thing
left
that
depends
on.
Is
this
one
section
here
if
we
make
those
other
changes
that
I
mentioned,
because
the
eat
spec
has
now
incorporated
other
things,
so
there's
a
cloud.
C
H
H
H
It
was
just
delayed,
it
came
up
for
me
all
right,
so
lawrence
opened
a
pull
request
on
monday
or
tuesday
against
the
eat.
Specs
saying
would
this
meet
the
requirement?
Okay
and
that's
what
has
been
generated?
Lots
of
discussions
so
in
this
example
right?
It's
a
byte,
blob,
okay,
as
opposed
to
a
uid,
okay,
and
you
can
see
the
various
descriptions
and
stuff
there
right
set
by
the
hardware
oem
vendor
again
wording
is
flexible.
This
is
just
a
pull
request
right.
H
H
So
we
know
whether
this
is
going
to
be
a
t
profile
thing
or
an
general
thing:
okay,
so
the
first
one-
and
these
are
all
interrelated
questions
here-
so
feel
free
to
get
in
the
mic
in
any
one
of
these
four
questions
here,
because
there
are
inner
relationships
between
these
okay.
I
know
a
number
of
people
have
posted
their
comments
to
the
list,
but
not
everybody
here
has
read.
Everybody
is
probably
up
on
that
thread
and
we
want
to
get
some
consensus
direction
out
of
the
working
group
here,
if
possible.
H
H
H
K
So
this
this
might
actually
back
up
slightly
to
oem
id
as
well
just
as
a
warning,
but
I
I
think
it's
important
to
consider
in
this
that
class
identifiers
are
not
unique
for
a
device.
One
device
could
have
many
class
identifiers
and
the
the
reason
this
is
really
important
is
because
it
allows
someone
to
distinguish
between
the
various
different
kinds
of
configuration
that
they
care
about.
K
If
you
happen
to
be
building
drm
or
maybe
you
care
about
access
to
a
specific
kind
of
crypto
accelerator,
in
which
case
you
definitely
need
a
class
identifier
for
that,
and
that's
probably
actually
going
to
have
a
different
oem
id
and
a
different
class
id
than
the
tee
itself.
So
what
you
actually
care
about
in
these
situations
is
aggregations
of
multiple
oem
and
class
id
pairs.
K
And
so
I
I
mean
there's
a
couple
of
different
ways
that
you
can
handle
this.
You
can
have
a
structured
class
identifier
in
some
kind
of
enormous
tree
or
you
can
have
a
list
of
pairs
which
is
possibly
easier
to
parse
and
handle
there's
a
lot
of
different
options
here
and-
and
I
think
it's
important-
that
we
consider
that
there
are
a
lot
of
different
use
cases
here
for
different
kinds
of
ways
of
identifying
exactly
what
a
class
means
to
you
and
your
ta.
H
So
you
have
just
like
you
could
have
multiple
claim
sets
one
for
each
layer.
You
could
have
one
more.
You
have
multiple
claim
sets
one
for
each
component
and
a
composite
device.
You
could
have
multiple
claim
sets
for
other
purposes.
So
if
you
need
to
have
different,
you
said
you
know,
lists
of
you
know
pairs
of
them.
You
could
put
those
in
different
claim,
sets
and
use
the
sub
mod
relationship
to
indicate
the
relationship.
H
That's
probably
the
one,
that's
the
most
natural
way,
because
then
it's
not
just
this
pair,
you
could
have
any
set
of
claims
that
could
be
varied
together
right.
You
could
have
you
know
whether
it's
a
time
stamp
or
anything
else
that
kind
of
goes
along
with
that.
So
multiple
claim
sets
is
the
most
natural
way
to
do
that,
but
I
see
other
people
in
queue,
so
I.
K
H
H
So,
what's
interesting,
I
I
guess
I
didn't
give
you
the
background
here,
but
for
anybody,
that's
not
familiar
with
the
t
format.
There's
when
I
say
up
to
the
profile
here
in
the
second
bullet,
there's
a
separate
claim,
that's
the
profile,
okay
and
so
there's
a
with
the
value
of
being
what
that
profile
would
be,
and
so
you
could
imagine
you
know
profile
value
equals,
teep
right
and
so
the
same
component
in
theory
could
also
have
multiple
profiles,
which
would
be
multiple
claim
sets
for
the
same
for
the
same
component.
H
J
Yeah
hi
hi
dave,
so
so
my
next
words
I
have
to
phrase
very
carefully.
I
have
to
tweet
very
carefully
because
none
of
my
co-authors
are
here
and
they
are
all
the
hardware,
vendors
and
the
te
builders
and
the
at
the
station
environment
creators.
So-
and
this
is
already
hinting
this
is
coming
from
rats
and
in
reds.
They
think
I
like
brent's
comment
on.
J
You
can
have
multiple
ways
to
express
these:
let's
call
them
multi-oem
multi-parts
things
that
you
have
multiple
classes
combined,
and
that
is
especially
true
in
composite
devices
and
composite
device
attestation
rats
where
you
also
have
the
layered
attestation,
maybe
on
top
of
that.
So
you
have
also
the
dependencies
which
environment
reports
on
which
requirements
and
so
on
and
so
on.
So
we
are
very
careful
and
very
complex
in
describing
that
from
the
supply
chain
side
and
we
decided
on
maps
that
have
classes
instances
and
groups
which
are
arbitrary.
J
J
I
think,
looking
at
that
corresponding
work
in
rats
tentatively,
that
is
a
korean,
might
yield
a
lot
of
interesting
choices
here
and
also,
I
think,
represents
the
complexity
of
how
to
represent
hierarchies
of
composite
class.
Things
to
have
the
which
again
would
be
can
be,
could
be
classed
by
their
own.
Then
how
complex
that
is
so
so
yeah
oid,
all
that
is
possible
actually
and-
and-
and
I
don't
know
if
this
complexity
is
required
for
etf.
So
that's
that's
my
my
take-home
idea.
H
So
again,
for
other
people
in
the
queue
here.
The
thing
that
is
the
most
useful
is
any
comments
on
the
top
two
comments
on
the
bottom.
One
is
probably
the
least
important,
because
that's
important
only
once
you've
agreed
on
the
answers
to
the
top
ones,
and
so
is
it
team
specific
or
general?
Is
it
profile,
specific,
vendor,
specific
or
globally
unique?
H
And
I
understand
brendan's
point
is
maybe
the
answer
is
multiple.
If
you
have
multiple
purposes
who
knows,
but
that's
the
one
I
would
most
likely
to
get
a
consensus
on,
so
we
can
get
direction
to
eat
versus
rats,
sorry
eat
versus
teep
versus
rats.
I
think
a
number
of
the
rats
community
have
argued
that
it
should
be
prof
up
to
the
profile
and
could
be
done
in
teep.
H
I
Sure
hi
eric
voigt
coming
over
from
rats.
I
definitely
think
it
should
be
global.
I
do
think
there
are
parallels
with
profile.
Certainly
things
like
tpm,
1.2
and
2.0
are
things
that
are
useful
to
standardize
the
behavior
of
effectively
what
an
api
your
behavior
is.
So
the
idea
of
having
a
union
of
behaviors
sort
of
supportable
here
is
something
that
is
interesting
on
the
text
discussion
as
it
should
be
a
string.
G
I
I'm
trying
to
write
the
meeting
minutes
and
it
was
difficult
to
sort
of
associate
the
responses
of
the
commenters
to
the
questions.
Maybe
maybe
you
could?
Maybe
you
could
summarize
like
what
did
you
hear
like?
What
did
you
get
out
of
the
the
comments
so
far,
so
I
can
capture
it
in
the
meeting
minutes
for
the
for
the
benefit
of
others
who
are
not
on
a
call.
H
I'm
with
you,
so
that's
why
I
was
going
to
ask
some
more
specific
questions,
but
I
I
had
a
hard
time
associating
comments
with
specific
questions
too
other
than
I
think
brendan's.
I
I
could
where
brendan's
point
was,
there
might
be
multiple
types
of
class
class
identifiers
so
that
one
was
pretty
clear.
The
hink
is
back
in
queue,
so
I
think
he's
going
to
clarify
his
comments.
The
mic
so
go
ahead.
Hank
yeah.
J
H
H
Yeah,
okay,
so
yeah
eric's
comments
specifically
on
the
second
one,
okay
to
support
both,
which
I
gather
as
something
there's
many
address
space.
There's
many
numbering
spaces
in
iana
that
do
that
right
that
have
a
vendor
extensible
section
reserved
whether
we're
talking
about
numbers
or
strings
or
any
other
format.
There's
ways
to
do
that
so
so
examples
that
have
come
up
on
the
on
the
list
is
things
that
are
vendor-specific
and
I
think
lawrence
gave
an
example
where
his
example
was
a
generic
example.
H
That
says
you
know
tesla,
and
so
his
was
in
the
argument
as
to
why
a
byte
string
is
better
than
uuid,
because
it's
more
compact
and
accessible
for
constrained
devices,
because
your
class
identifiers
could
be
very
short,
much
less
than
say.
16
bytes
such
as
you
know,
tesla
model
s,
3,
x
or
y
would
be
an
examples
of
say
one
byte
things
that
are
what
vendor
specific
right,
just
translate
that
into
te
type
or
device
type
or
whatever,
instead
of
tesla.
But
your
point
is,
you
could
have
say
one
byte
identifiers.
H
H
H
And
so,
if
you
think
about
do,
we
need
a
registry
of
things
that
are
well
known,
okay
or
not,
because
if
it's
up
to
the
vendor,
you
don't
need
a
registry
right.
If
you
have
up
to
the
profile,
you
need
a
registry
right,
whether
so
we
would
need
in
the
t
profile
if,
if
we
have
the
class
identifier
values
that
are
specific
to
t
right,
if
keep
says,
here's
the
weight
gives
us
space.
You
could
register
you
want
trust
zone.
H
Okay
rats
would
be
fine
with
that
right,
that's
something
something
we've
talked
about
in
teep,
hence
this
discussion
or
if
we
say
no,
no,
there's
really
nothing.
That's
type
specific
here.
This
is
all
generalizable
and
it
should
really
be
in
the
right
in
the
eat,
spec
or
at
least
in
the
rats
working
group,
and
so
that's
the
most
important.
That's
the
top
bullet
here,
that's
the
most
important
one,
because
in
the
next
meeting
right
rats
is
going
to
try
to
decide.
H
Should
we
start
working
group
last
call
on
eat
and
kind
of
ignore
this
or
have
the
discussion
going
on
parallel
or
just
leave
it
to
t
right.
That's
the
what
we
want
the
feedback
to
rats
to
be
for
the
next
meeting.
So
now
that
I've
clarified
that
and
given
some
examples,
anybody
else
have
opinions
on
this,
because
otherwise,
I'm
going
to
summarize
maybe
a
straw
man
from
what
I've
heard
so
far.
H
Just
to
help
honest
okay,
I
think,
if
I
were
to
put
out
a
straw
man
so
far
based
on
list
discussion
so
far,
the
path
of
least
resistance
might
be
to
say
that
at
least
for
now,
it's
specific
to
type
and
a
t
profile,
but
with
a
vendor
extensible
space.
So
to
eric's
point
okay,
in
which
case
we
keep
would
have
to
define
a
new
claim.
We
would
have
to
define
a
new
say.
H
I
enter
registry
for
the
values
and
a
way
for
vendors
to
extend
them
and
then
the
bottom
bullet
becomes
a
teat
question
and
not
a
rat's
question
okay,
but
that
seems
to
be
the
path
of
least
resistance
based
on
the
thread
so
far.
But
since
this
is
a
different
direction
from
what
type
has
said
so
far,
this
is
our
chance
to
either
change
our
minds
or
to
stick
the
course
or
whatever
so.
H
But
I
think
that's
what
I
that
when
I
saw
the
last
responses
from
geary
and
lawrence,
I
think
that
was
their
conclusion,
that
they
did
not
see
any
consensus
that
there
was
some
generally
applicable
thing.
But
if
you
think
that
there
is,
please
come
to
the
mic
and
say
so
because
that's
probably
the
default
path
that
rash,
where
the
rats
would
advise
us
on.
H
A
H
Okay,
if
I
don't
hear
everybody
come
to
mike,
then
I'm
going
to
say
that
we
don't
have
any
other
more
strict
guidance
to
rats
other
than
sure
we'll
deal
with
it
in
a
teep.
If
somebody
else
wants
to
argue
that
is
general
feel
free,
but
otherwise,
because
kind
of
the
the
worst
case
danger
would
just
be.
We
define
something,
that's
keep
specific.
It
turns
out
to
be.
J
H
K
K
K
H
H
That's
I
think
debatable
is
the
last
one,
but
I
tend
to
agree
with
you
on
it,
and
so
I
think
the
proposal
is
that
the
claim
id
right,
meaning
the
the
seabor
integer
number
or
label
or
whatever
is
actually
general
and
the
values
of
it,
are
either
vendor
specific
or
up
to
the
profile.
So
in
other
words,
the
eat,
spec
could
say
here
is
the
well-known
claim,
but
the
values
of
it
need
to
be
specified.
H
One
of
the
requirements
for
a
profile
is
to
you
know,
cover
how
the
values
are
done,
but
there's
still
a
way
to
do
it
for
vendors
and
a
way
for
the
profile
to
find
well-known
values.
I'm
repeating
back
what
I
think
your
proposal
is
right
and
then
out
of
the
values
right,
regardless
of
whether
it's
done
by
the
vendor
the
profile,
then
it
must
be
opaque.
H
Okay
and
you
like
uuid,
specifically
because
it
guarantees
that
it's
opaque
well
and
the
other
reasons
too,
even
if
it's
a
little
bit
longer,
if
you're,
trying
to
bite
string
or
whatever
the
danger
is,
somebody
would
try
to
put
structure
in
there
and
you
wouldn't
like
that,
and
so
uib
actually
enforces
the
annual
peakness
requirement.
Did
I
get
all
that
right
sounds
good
to
me?
H
H
Okay,
anyone
else
have
an
opinion,
because
otherwise
I'm
gonna-
I
since
I
like
brendan's,
summary
there
I'd
like
to
see
other
any
objections
to
that
as
the
teep
recommendation.
As
we
go
into
the
rats
working
group
next,
that
the
request
for
rats
would
be
hey,
can
you
define
a
claim
but
leave
it
up
to
the
vendor
and
the
profile
to
define
the
values
to
go
with
the
claim.
H
H
Remember
if
it's
your
your
one
of
the
other
id
numbering
spaces
already
exist,
but
the
point
is
that
each
spec
doesn't
enumerate
the
values
right
says:
here's
how
to
put
stuff
in
there-
and
this
is
this
case
where
it
could
say
the
profile
needs
to
do
that.
Ayanna
needs
to
do
that
whatever
so
all
right,
hank.
J
So
yeah,
I
think
that
t
requires
this,
this
opaqueness
and
everything
they
can
transform
to
a
type
five
uuid
on
the
evidence
side
or
at
the
station
result
side
of
things,
which
is
fine,
and
I
think
brandon
said
the
critical
words
because
you
know
that.
So,
on
the
other
hand,
you
have
to
know
that,
so
that
is
something
you
that
there,
where
a
uu
id
might
not
be
sufficient,
but
that's
not
a
cheap
problem.
I
think
so.
I
would
agree
with.
H
Okay,
is
there
any
objections
to
saying
that
the
the
my
summary
of
what
brendan
said
is
the
consensus
of
those
in
the
room?
I'm
not
saying
it
is
yet
I'm
saying:
okay,
would
that
be
the
consensus
of
the
room?
If
you
don't
think
that
that
is
the
consensus,
you
have
a
technical
argument
against
that.
Then
please
come
to
the
mic,
we're
trying
to
form
a
consensus,
so
that
is
a
proposed
consensus.
Do
people
like
that
or
not?
H
H
L
H
H
C
H
H
It's
a
it's
a
rat's
thing
on
the
bottom
bullet
here,
the
only
thing
that
might
be
worth
doing
it
is:
do
we
agree
that
the
value
needs
to
be
opaque
right,
as
opposed
to
the
value
needs
to
be
a
uid
or
whatever,
which
that
should
be
up
to
how
they
meet
the
requirement?
That's
just
our
preferences
right
now
and
that's
a
rat's
working
group
discussion,
but
does
the
value
need
to
be
opaque
would
be
a
fair
way
to
ask
the
question.
C
A
H
G
H
H
Okay,
so
trying
to
finish
out
the
eat
stuff,
the
eat
document
section
seven
covers
requirements
for
an
eat
profile.
There's
this
long
list
of
requirements
there.
Some
of
those
requirements
are
covered
in
the
t
document
right
now
like
use
of
json
sieber
or
both
where
we
say
it's
only
seabor
like
the
second
one
from
the
bottom
seaboard
tags.
We
previously
last.
I
have
a
discussion
and
we're
not
going
to
use
the
seaport
tag.
H
It's
just
raw
because
you
always
know
that
it's
a
they
always
know
that
it's
a
an
eat
and
so
on,
but
not
all
of
them.
So
next
slide,
please,
you
can
see
that
I
said
long
list
of
requirements
says
if
you're
going
to
find
a
neat
profile,
you
got
to
cover
all
those.
That's
what
the
new
document
says.
Okay,
so
today,
not
all
of
those
are
covered
in
the
tea
protocol,
spec.
How
many
of
those
are
right?
H
So
there's
two
ways
to
resolve
this
issue:
one
is
we
just
cover
the
missing
ones
by
putting
those
in
the
t,
protocol
spec,
another
possibility
is
to
say
we
could
separate
all
the
eprofile
stuff
and
put
it
into
the
same
spec?
Okay,
because
it's
already
in
the
t
protocol
the
pieces
of
it
that
are
answered
right
now.
The
default
answer
is
the
same
spec,
but
I
just
wanted
to
verify.
H
It
would
be
a
separate
spec.
If
say,
there
was
a
reason
to
implement
the
eprotocol
without
the
e
protocol
without
the
without
the
eat
profile.
That's
not
the
case
or
if
there
is
a
reason
to
say
we
need
the
tea
protocol
spec
to
go
to
rfc,
while
we're
still
working
on
it,
because
it's
optional,
that's
also
not
the
case.
So
all
the
reasons
I
can
think
of
for
b
don't
apply
and
so
right
now
the
proposal
is
we're
going
to
address
this
by
putting
all
the
other
requirements
there
into
the
actual
heat
protocol
spec.
H
H
All
right,
thank
you.
Next,
okay,
now
we're
out
of
the
eat
section.
Now
we
are
into
so
thanks
to
those
who
oh
interesting,
this
one
is
actually
out
of
order.
I
meant
to
go
to
the
suit
ones
next,
but
that's
okay,
I'll
still
cover
this.
I
meant
to
cover.
Let's
see
we
got
half
hour
left,
let's
skip
this
one
we'll
come
back
to
it.
I
want
to
get
to
the
suit
discussions.
H
C
A
A
H
A
H
Okay,
yeah
there's
two
there's
two
ones
that
are
purely
optimizations
and
that
last
slide
was
one
of
them.
If
we
have
time
I'll
come
back
to
it,
but
but
the
other
category
is
since
we
got
suit
people
here,
let's
go
over
the
suit
discussions.
Okay
other
than
akira
already
covered
one
of
those,
so
draft
07
includes
brennan's,
manifest
examples.
H
He
went
through
that
last
ietf
and
so
that's
sufficient
to
answer
issue
41,
but
last
iatf
brandon
also
provided
suit
reports
and
we
walked
through
those
last
meeting
and
the
suit
reports
have
not
been
added
into
the
t.
Protocol
spec
right
now,
so
that's
issue.
Number
170
is
to
take
brennan's
examples
that
we
used
in
the
ietf
111
meeting
and
put
those
in
the
appendix
of
the
t
protocol
spec
2,
which
is
where
the
manifest
examples
already
appear.
H
So
that's
issue
number
170
not
going
to
talk
about
that,
because
brendan
gave
that
presentation
last
time,
then
there
are
two
other
issues.
One
is
the
one
that
actually,
I
think
that's
the
wrong
number
on
there.
Oh
that's
the
issue
number.
He
had
the
pull
request
number,
but
it's
the
same
thing.
That
was
a
curious
presentation
about
the
three
types
of
suit
manifests.
H
H
Okay,
so
there's
two
interrelated
questions
here
in
this
issue,
as
I
read
it:
okay,
this
has
to
do
with
removing
or
in
the
suit
working
group.
We
call
that
unlinking
right
because
it's
actually
removed
when
the
last
link
goes
away
right,
you're,
dropping
a
ref
count
right.
The
issue
in
the
t
github
says
removing,
but
we
mean
unlinking.
Okay,
two
related
questions
here.
First,
one
for
a
suit
is:
should
a
suit
parser
unlink,
all
the
dependent
manifests
when
you
all
of
all
the
dependencies
when
you
unlink
the
dependent
manifest
right.
H
So
if
a
references
b-
and
you
say
unlink
a
does
that
automatically
unlink
b
or
presumably
I'm
guessing,
the
answer
is
only
when
the
ref
count
on
a
goes
to
zero.
Would
you
unlink
b
right,
but
that's
the
question?
That's
in
the
issue
here
and
then
the
second
question
is
well:
keep
is
a
protocol
for
doing
things,
but
what
happens
if
you
try
to
run
some
alternate
thing
like
running.
As
you
know,
some
admin
or
whatever
outside
of
t
protocol,
is
there
a
way
to
unlink
stuff
and
what
happens
if
you
do
that?
H
Okay,
because
if
you
do
that,
you
may
be
doing
it
without
having
a
brand
new
suit,
manifest
that
says
to
delete
it.
Is
it
possible
to
delete
a
component
that
was
added
through
suit
at
suit
manifest
without
having
a
suit
manifest
that
updates
it
okay,
or
do
you
have
to
do
it
through
a
suit
manifest?
That's
what
q2
is
okay
and
so
option
number
one?
Okay?
Is
you
actually
require
having
a
new,
manifest?
H
Okay,
even
if
you're
doing
it
locally,
you
have
to
construct
a
suit,
manifest
that
bumps
the
manifest
sequence
number
and
that's
what
actually
the
suit
processor
is.
What
drops
the
ref
count
right,
so
the
only
way
to
drop
the
ref
count
taken
by
suit
is
to
have
a
new
suit,
manifest
higher
verge
sequence
number
or
manifest
sequence.
Number
that
drops
the
ref
count
right.
That
would
be
option.
H
One
option
number
two
point:
one
has
mentioned
the
issue,
but
I
don't
think
anybody
likes
this
one,
which
is
you
could
try
to
have
some
suit
parser
that
tries
to
undo
a
bait.
So
if
you
have
a
local
undo,
then
it
tries
to
look
at
the
suit
manifest
and
figure
out
how
to
how
to
unlink
and
uninstall
it
according
to
all
the
correct
stuff
in
general,
this
one
just
doesn't
work
with
all
soup
manifest
and
that's
why
it's
there
for
completeness
but
yeah
exactly
please,
no
screams
exactly
yeah,
so
that
one
is
really.
H
H
Should
you
need
to
uninstall
this
later
without
having
to
manifest
here's,
what
you
would
do,
and
so,
if
you
tried
to
do
something
locally
and
you
didn't
have
to
create
a
new
suit
manifest,
so
it's
really
between
option
1
and
option
2.2,
and
this
is
really
a
question
for
the
suit
working
group
to
weigh
in
on
other
than
the
tpu's
case.
Is
you
can
see
the
the
the
analogy
that
the
filer
had
is
the
equivalent
of
like
apt,
remove
dash
y
foo
kind
of
equivalent
for
like
an
admin
on
the
machine?
H
Does
he
have
to
do
that
by
generating
a
new
suit
manifest,
or
can
you
do
that
by
by
some
other
means,
with
the
actual
uninstall
commands
were
embedded
in
the
last
in
the
actual
install
manifest?
And
so
that's
what
issue
168
was
filed
against
by
our
japanese
colleagues
or
at
least
one
of
them
so
feedback
on
this
one,
especially
from
suit
folks
like
brendan.
K
H
C
K
The
the
issue
that
bothers
me
with
all
of
this
is
a
question
of
privilege.
Well,
actually,
there's
two
there's
two
issues.
The
first
is
exactly:
how
do
you
obtain
the
privileges
to
invoke
and
unlink
when
you
are
not
the
signing
author
and
that's
out
of
protocol?
That's
out
of
document
it's
out
of
manifest.
The
question
is:
how
do
you
manage
that
when
everything's
done
with
manifests?
H
K
H
Comment
on
that
and
by
the
way
the
default
answer
is
option
one,
and
so
the
actual
pull
request
tries
to
put
in
some
text
that
just
clarifies
using
option
one.
But
it's
interesting
to
talk
about
whether
option
2.2
is
an
option
or
not.
So
to
answer
your
question
brandon.
My
view
is
that
option.
2.2
is
not
completely
out
of
the
question
whether
it's
a
good
idea
or
a
bad
ideas
thing,
but
and
that's
because
in
the
teep
architecture
document
okay,
there
is
a
trust,
anchor
store.
H
Okay,
so
the
trust
anchor
store
can
have
one
or
more
keys
in
it.
That's
the
keys
that
are
used
to
like
by
the
manifest
signer,
for
example,
right
so
things
that
are
used
to
run
against
the
actual
tas.
Okay,
as
opposed
to
they
say
you
know
the
the
signing
of
teap
commands
themselves,
the
sign
of
the
suit
manifests,
and
so
there's
one
or
more
trust
anchors
in
the
trust,
anchor
store.
Okay,
and
so
the
question
here
in
2.2
that
you
might
be
worried
about
is.
H
Is
it
really
the
case
that
you
have
to
have
the
same
trust
anchor
signing
the
uninstall
as
sign
the
install?
Do
you
have
to
remember
which
trust
anchor
did
it
or
is
it
just
any
trust?
Anchor
in
your
store
is
the
one
that
can
do
that
and,
if
you
think
about
like
key
rollover
and
so
on,
is
that
really
a
trust
anchor
id
of
the
actual
trust
anchor?
But
if
you,
if
you
took
a
choice
that
says
any
trust
anchor
in
the
trust
anchor
store,
was
equally
trusted.
H
K
Yeah,
so
I
think
the
the
take
that
I
have
on
that
is
that
any
equally
privileged
trust
anchor
should
be
able
to
to
unlink
a
manifest.
I
just
on
that
topic.
I
thought
we
were
originally
doing.
Unlink
for
components,
but
we
now
appear
to
be
unlinking
manifests
that
that
was
a
somewhat
unintended
consequence,
but
I
I
think
it
works.
So
I
mean
that's
all
right,
but
we
did
originally
discuss
this
as
unlinking
components
rather
than
unlinking
manifests.
H
K
The
the
other
factor
here
is
that
provide
that
the
question
is:
where
do
the
links
come
from
in
the
first
place?
If
you
have
installed
this
thing
manually,
then
I
guess
there's
a
link
that
you
can
unlink
if
it
hasn't
been
installed
manually.
If
it's
been
installed
by
another
manifest.
How
do
you
unlink
it?
Is
that
something
you're
even
permitted
to
do
so?
There's
a
question
about
link
tracking
and
where
these
links
come
from,
you
can't
simply
decrement
a
reference
counter.
K
K
In
that
case,
you
probably
want
a
suit
uninstall
section,
not
command
section
or
command
sequence
rather,
because
otherwise,
that
I
don't
see
how
you
would
do
the
unlink
it
I'm
not
sure
how
that
would
make
sense.
I
I
think
you
probably
need
to
have
an
uninstall
command
sequence.
It's
I
don't
see
another
way.
H
K
K
Would
have
to
go
into
the
trust
domains
id
because
I
think
it's
highly
relevant
to
just
almost
entirely
a
situation
where
you
have
multiple
trust
domains
where
just
to
be
clear,
teep
is
exclusively
a
multiple
trust
domain
kind
of
domain
yeah.
I
think
it
might
need
to
go
there
and-
and
I
mentioned
in
the
suit
working
group
and
I'll
mention
it
again.
If
anyone
else
would
like
to
come
on
and
edit
that
document
they
are
welcome.
H
So
I
guess
what
I'm
hearing
is
that
for
now,
teep
should
continue
to
go
forward
with
option
one,
but
that
the
2.2
suit
will
consider
that
and
discuss
it.
And
I
see
there's
we
got
a
couple
of
us
suit
co-chairs
here
and
so
that
would
then
be
a
new
discussion.
We
would
start
on
the
t
on
the
suit
mailing
list.
K
H
Yeah
and
thank
you
for
correcting
the
language
here,
as
I
was
constructing
the
slide.
It
was
jet
lag
this
week
and
so
yeah
that
really
should
say
suit,
uninstall
section,
even
if
the
text
and
the
issue
number
says
command
right
now,
but
this
section
yeah
say
here's
the
directives
to
do
an
uninstall.
Should
you
need
to
do
an
uninstall
without
having
any
other
information
other
than
the
suit
manifest
again.
I
H
Okay,
so
I
guess
we
will
push
that
option,
2.2
discussion
to
the
suit
list
and
currently
there's
an
open
pull
request
that
puts
in
some
clarifying
text.
Assuming
that
option
number
one
is
the
way
that
you
have
to
do
it,
and
so
the
clarifying
text
just
says:
here's
here's!
What
happens
when
you
have
the
largest
to
do
this?
You
do
you
do
it
via
new
suit
manifest,
and
so
it
wouldn't
actually
reference
the
option,
2.2
stuff
and
unless
and
until
suit,
actually
put
something
in
a
document.
That's
referenceable.
H
C
A
H
H
First
scenario
for
personalization
data
is
where
the
developer
provides
both
the
binary
and
the
personalization
data
right,
they're
packaged
separately
in
some
way,
because
the
binary
is
exact
is
identical.
That
goes
to
all
the
different
devices.
The
personalization
data
is
different.
That
goes
to
different
devices
right,
but
since
that's
why
they're
packaged
separately,
but
the
same
entity
in
this
case
is
the
developer
and
a
signs
both
of
them
case
b.
Is
where
doesn't
matter
what
the
developer
did
right.
H
The
one
that
actually
manages
the
device
is
the
one
that's
the
actual
science
of
trusted
signer
right,
so
the
device
doesn't
trust
arbitrary
developers,
it
trusts
its
own
operator
and
owner,
depending
on
the
use
case,
whether
it's
an
operator
an
owner
and
so
that
one
provides
the
binary,
maybe
gets
it
from
a
developer
vets
it
signs,
it
itself,
generates
personalization
data
and
puts
it
on
there.
As
far
as
the
protocol
is
concerned,
this
is
basically
equivalent
to
case
a
right.
H
It's
a
it's,
a
different
organization,
maybe
a
different
human
flow,
but
as
far
as
the
code
goes,
a
and
b
are
basically
equivalent
right.
It's
the
same
thing:
okay,
they're
indistinguishable
to
code
basically
option
c
is
where
they're
different
entities,
so
the
developer
might
provide
the
binary
and
the
operator
owner
provides
the
personalization
data.
H
So
the
the
operator
says
you
need
to
install
this
personalization
data,
the
personalization
data
says
well
in
order
to
solve
this,
I'm
going
to
also
install
the
tc
binary
right
and
that's
so
you
can
have
many
manifests
that
point
to
one
you
couldn't
do
in
the
other
direction,
because
you'd
have
one
manifest
that
points
to
many
it'd
be
very,
very
difficult
by
comparison,
and
so
this
is
what's
in
the
appendix
e.1
example.
Today.
H
H
Okay,
next
one
is
the
cypher
suites
question
this
was
filed
during
the
hackathon
by
I
don't
remember
who,
let's
see
so
today,
the
cipher
suites
in
the
document.
Right
now
it
defines
a
new
registry
that
has
two
values
in
it,
and
it
says
the
tam
has
to
support
both
of
them
and
the
teep
agent
gets
to
pick
its
choice
of
either
of
those
okay
next
slide.
H
Okay,
okay,
it
was
a
sobe
son
that
filed
this
okay,
so
during
implementation
it
was
pointed
out
that
there's
this
one
registry
in
deep
in
a
different
registry
in
in
slash
cose
and
can't
we
just
use
the
same
one
so
that
we
don't
have
to
have
two
different
spaces
and
so
could
t
just
say
to
use
the
actual
numbering
space
and
values
out
of
cose,
and
then
that
would
simplify
the
code.
And
so
this
is
an
example
of
what
the
document
might
say.
H
This
is
copied
out
of
sobazon's
proposal,
which
is
you
know
the
typecozy
algorithms
is
the
cozy
algorithm
es256,
so
those
the
two
that
were
on
the
previous
slide
and
there's
various
other
ones
that
are
optional,
but
you
can
see
the
way
that
it
specified
it.
It
does
not
create
a
new
registry,
and
so
we
would
delete
the
registry
if
we
went
with
this
proposal,
and
the
point
is
this:
would
simplify
implementations
and
so
any
comments
on
this.
H
C
H
Next
next
slide,
then,
because
if
there's
no
objections,
then
I
think
it's
probably
a
good
idea
to
simplify
so
all
right,
so
suit
cipher,
suites.
Okay,
now
we're
into
the
manifest
right.
The
proposal
from
the
suit
meeting
just
fyi,
if
you
weren't
in
the
suit
meeting,
was
the
suit
decided
that
hss
lms
is
actually
the
must
ecdsa
is
a
should
and
you
may
implement
others.
Okay
and
those
are
just
examples
of
others
that
there
might
be,
but
there's
the
the
boston
they
should.
H
All
right,
so
the
next
issue,
from
a
hackathon
that's
still
related
to
suit,
is
issue
104.
Okay,
so
here
the
the
developer
creates
a
suit
manifest
that
points
to
the
tc
binary
that
the
developer
created
right.
So
he
hosts
it
on
his
own
share
or
wherever
he
has
it
right.
So
the
developer
creates
his
own
suit,
manifest
okay.
So
now
you
have
a
case
where
the
tam-
or
you
know
the
owner
or
the
operator-
wants
to
override
that
uri
okay
example:
okay,
it
wants
to
host
the
binary
itself
right.
H
Maybe
the
tam
is
a
tan
for
devices
that
are
not
on
the
public
internet
right,
and
so
it
has
a
location,
that's
accessible
to
the
devices
where
the
public
internet
that
original
uri
might
not
actually
be
reachable
in
that
location.
Right
think,
you
know
cruise
ship
space,
whatever
it
is
you're
in
some
disconnected
network
or
some
connect
network,
where
you
don't
have
reliable
connectivity
to
the
outside
world.
Okay,
so
you
want
to
host
that
uri.
So
how
do
you
override
that?
H
Okay-
and
so
one
way
to
do
this-
is
the
tam
just
creates
a
brand
new,
manifest?
Okay
with
the
tam
is
the
signer
okay,
and
so
it
just
reconstructs
that,
because
the
trust
anchor
is
the
tams
trust
anchor
that
the
device
trusts,
you
could
create
a
brand
new,
manifest
that
the
team
can
construct
using
taking
the
original
manifest
doing
a
new
version
copying
most
of
the
fields
replacing
the
uri
and
saying
brand
new
one.
The
developer
is
actually
not
in
the
loop.
Never
even
identified
doesn't
have
to
be
anyway,
and
so
off
you
go.
H
So
this
is
a
case
that
I
think
no
document
changes
would
be
needed.
If
I
understand
that
scenario
correctly,
issue
105
is
a
way
to
say.
Okay,
is
there
a
way
to
reduce
the
effort
to
say
somehow
reference
the
original,
manifest
and
just
override
the
one
field
and
say
everything
else,
I'm
incorporating
by
reference?
Okay,
it's
this
other
stuff,
except
for
I
want
to
override
this
one
field.
Okay,
and
so
here
the
binary
is
still
signed
by
the
original
signer
right,
not
by
the
tam.
The
tam
is
signing
the
manifest.
K
So
I
think
you
may
be
missing
a
couple
of
other
options
that
are
available,
which
might
be
more
appropriate,
I'm
not
sure
so.
The
first
one
is
plain
old
caching.
So
as
long
as
you
don't
use
an
https
uri,
there's
nothing
to
stop
you
from
just
caching
the
binary
on
some
local
system.
Then
you
just
override
it
in
your
transparent
cache
and
away.
You
go
no
problem.
H
K
No,
no,
not
that
I
mean
that's
an
option
as
well
that
wasn't
what
I
was
aiming
for.
What
I
meant
is
that
in
your
own
network
infrastructure,
if
you
have
a
transparent
cache
sitting
around,
which
I'm
sure
a
lot
of
network
infrastructures,
do
you
can
use
that
instead
and
then
you
just
override
the
http
request
and
serve
it
locally.
I
I
know
you
can't
do
that
with
https,
but
there's
already
at
rest
security
on
your
if
you're
using
suit
encryption,
so
you
might
as
well
just
use
a
cache.
K
K
K
Yeah
there's
another
one,
so
one
of
the
changes
to
the
the
suit
manifest
that
came
cropped
up
over
this
one
was
the
use
of
integrated
payloads
referenced
by
a
string,
and
that
was
specifically
so
that
you
wouldn't
have
to
do
conversions
from
the
uri
to
the
the
key
in
the
integrated
payload.
But
the
offshoot
of
that
is
that
you
can
use
that
as
a
precaching
mechanism.
K
You
can
then
take
your
your
your
target,
binary,
download
it
in
advance,
as
your
distribution
system
move
it
into
the
envelope
of
your
manifest
and
make
its
its
key
in
the
envelope
the
uri
that's
already
in
the
manifest
and
then
when
the
device
goes
to
look
for
it.
It
first
checks.
If
there
are
any
string
keys
and
if
one
of
them
matches
it
takes
it
there
and
if
not,
then
it
then
it
goes
out
and
attempts
to
do
a
fetch.
So
you
can
do
transparent,
pre-caching.
H
H
H
H
B
H
All
right,
then
we
can,
we
can
go
on
and
it's
the
same
for
can,
if
you
needed
to
say
something,
feel
free
to
come
to
the
mic.
Otherwise,
we'll
go
on
all
right,
so
yeah.
So
now
we've
got
to
the
last
two.
Let's
go
back
to
the
one
slide
that
I
skipped
before.
That
was
out
of
order
that
was
supposed
to
be
after
this
one.
So
go
back
to
right
before
the
use
of
suit
slide.
There's
the
first
of
the
optimization,
slides
and
feel
free.
A
H
Yep
I
got
it,
I
I
I
see
the
clock
but
call
time
if
you
want
so
all
right.
This
one
says
you
know
today
in
order
to
get
a
query
response
you
reach
out
to
the
tam
with
an
empty
payload.
The
tam
responds
to
the
query
response,
and
then
you
can
finally
with
a
query
request
and
then
you
can
send
your
query
response.
H
You
have
this
extra
round
trip,
and
so
this
question
is
this
is
purely
an
optimization,
but
if
you
already
know
the
tam
key
or
cert
right,
whatever
you're
using
to
authenticate
the
tam,
could
you
send
an
unsolicited
query
response
to
avoid
the
extra
round
trip?
Okay?
Well,
obviously,
you
can't
do
this
if
there's
information
that
varies
in
the
response,
the
in
the
request
that
you
actually
need
to
put
in
your
response
so
like
if
you
have
a
token
like
you're
having
a
not
stuff,
your
freshness
mechanism
is
nonce.
H
Then
of
course
you
cannot
do
this
okay,
but
given
that
we
have
possibilities
of
having
other
freshness
mechanisms
right,
you
can
use
the
epic
ide.
You
can
use
time
stamp
freshness
mechanism,
and
so,
if
you
had
that,
then
there's
nothing
that
actually
appears
in
the
query
request.
That's
different
from
any
other
query
request
that
you've
gotten
from
it.
Okay,
and
so
is
it
possible
to
send
an
unsolicited
query
response
if
the
query
request
would
contain
no
information
that
you
didn't
already
have
okay
and
so
here's
the
proposal
to
address
this.
H
Okay,
that
the
teap
agent
may
send
an
unsolicited
query
response
to
a
tam
if
all
three
of
the
following
conditions
are
true:
okay,
because
if
any
one
of
these
is
false,
then
there's
a
potential
problem.
So
here's
the
three
conditions
number
one
you've
gotten
a
query
request
already
from
that
tam
and
it
contained
no
token
or
challenge,
in
other
words,
there's
no
fields
that
actually
vary
by
things,
because
those
are
the
only
standard
fields
that
vary
right,
there's
nothing
in
it.
That
would
be
different
from
the
one
that
you
got
before
that
right.
H
So
there's,
no,
no
fields
that
vary
number
two.
Is
that
it
didn't
send
you
a
process
error,
since
you
got
that
query
request,
because
in
other
words
you,
if
you
this
one,
is
to
cover
the
case
where
you
sent
an
unsolicited
one
and
something
had
changed.
The
tam
said
up.
You
know,
there's
some
error
and
of
course
the
tam
just
drops
it.
There's
no
bad
response
and
so
process
error
is
the
notification
from
the
local
broker.
H
The
http
returned
that
the
transport
returned
an
error
so
like
for
return,
error,
400
or
500
http.
Then
the
broker
sends
process
error
up
to
10
broker
up
to
10
agents
right,
and
so
this
says
you
do
not
get
an
error
from
trying
to
do
this
before
that's
number
two
number
three
is
that
the
tam
search
or
key
or
whatever,
is
cached
and
still
valid
right,
so
you
can
only
do
it
if
you
actually
have
all
the
information
you
need
to
authenticate
to
tam
okay.
H
Okay,
any
objections,
because
the
proposal
is
to
put
that
into
the
next
version
of
the
spec.
So
and
of
course
we
try
to
implement
that
in
in
the
implementations
before
next
ietf,
so
at
least
one
of
them
so
all
right
hearing.
Unless
there's
any
comments,
then
I
think
we're
out
of
time.
We've
got
like
one
minute
left,
but
I
don't
think
we
have
time
to
go
to
the
last
to
the
last
one:
there's
only
one
more
stop.
H
A
A
H
If
the,
if
you
can
go
to
the
very
very
last
lie,
which
is
basically
asking
that
style
of
questions
so
skip
any
other
content,
slides
just
go
to
the
very
last
one
as
you're
asking
that
the
I
think
your
question
is,
is
it
useful
to
have
an
earlier
review
say
even
before
a
working
request
call
right-
and
I
think
you
know
that
might
be
perfectly
fine
right.
My
hope
was.
We
could
get
to
a
working
group,
less
called
capable
state
around
iutf
113.
H
H
H
A
H
A
Okay,
honest
so
we're
out
of
time,
but
hannes
is
saying
we
should
maybe
do
a
hackathon
in
december
johannes.
I
encourage
you
to
put
that
on
the
mail
list
and
we
can
figure
out
how
we
can
move
forward
and
making
progress.
So
you
guys
have
have
done
a
great
job
in
ironing
out
some
of
these
issues.
So
thank
you
for
that.