►
From YouTube: IETF109-TEEP-20201118-0730
Description
TEEP meeting session at IETF109
2020/11/18 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
Can
you
hear
me
yes
now
I
can
hear
you
great
okay,
so
we've
got
both
chairs
here
and
we've
got
a
full
agenda
for
today,
since
we
only
have
one
hour.
This
is
in
my
normal
ietf
session,
so
the
note
will
apply.
Most
of
you
are
familiar
with
it
for
the
agenda
and
again
I
want
to
thank
alessandro,
akira
and.
A
Sukasa
for
being
the
note
takers-
and
I
encourage
the
rest
of
you
to
also
look
at
the
code
emd,
which
is
where
the
notes
are
being
taken.
So
this
is
the
agenda
that
we
have
today.
A
This
is
only
a
one
hour
session,
so
hopefully
we
have
enough
time
to
get
through
all
of
this
and
dave.
I
didn't
have
time
and
I
forgot
to
to
send
out
the
rats
session
cancellation,
but
if
we
need
to,
we
can
set
up
another
interim,
perhaps
not
this
week,
but
in
a
few
weeks
we
can
do
a
doodle
poll
to
further
the
work.
A
B
B
All
right,
so
the
architecture
document
has
been
through
last
call
as
a
reminder.
At
108
we
said
there
was
two
action
items,
moving
some
text
and
adding
an
unneeded
tas,
and
then
we
talked
about
in
the
minutes
right.
You
know
what
was
an
appropriate
milestone.
So
next
slide.
B
So,
since
itf
108,
we
did
those
two
action
items
except
for
one
thing:
the
second
action
item,
which
was
adding
the
unneeded
tas
text.
We
revisited
so
a
little
over
a
month
ago,
october
16th,
I
posted
the
list,
the
question
that
was
raised
that
had
to
do
with
do
we
really
want
to
add
unneeded
tas
to
the
list
of
things
that
are
requested
for
rats
claims.
So
this
is
the
diagram
that
appears
in
the
architecture
document
and
has
for
a
really
long
time.
B
You
can
see
there's
stuff
that
goes
from
the
te
or
the
t
agent
off
to
the
tam
and
then
potentially,
the
tam
on
the
back
end
uses
a
verifier
to
process
the
evidence
and
tam
is
just
passing
that
through
and
so
the
observation
is
that
the
claims,
meaning
the
things
that
you
ask
for
from
rats,
are
things
that
go
all
the
way
to
the
verifier
and
are
important
to
the
verifier.
B
Whereas
you
know
what
goes
in
say,
the
t
protocol
messages
that
carry
the
evidence
well
things
that
the
tam
is
about
that
the
verifier
doesn't
really,
and
so
the
question
is-
or
the
point
was
well,
this
notion
of
requested
tas
and
unneeded
tas
they're
not
really
needed
by
the
verifier
they're
for
use
by
the
tam,
and
so
the
point
was
raised.
It
says
actually
put
him
in
the
rat's.
Claims
is
probably
the
wrong
place,
because
the
verifier
doesn't
care
that
tam
does,
and
so
the
proposal
was
just
put
them
in
the
teat
protocol.
B
Messages
not
put
them
in
the
evidence,
because
the
verifier
doesn't
care.
There
was
no
objections
raised,
and
so
that
was
done
and
you'll
see
that
that
affects
the
transport
spec
too,
and
so
now
this
principle
that
claims
are
used
for
things
that
are
important
to
the
verifier
protocol
fields
are
used
for
things,
that's
important
just
to
the
tab,
that's
the
principle
that
we
try
to
use
throughout
now,
and
so
that
one
was
done
since
ietf
108,
but
wasn't
discussed
before
other
than
on
the
list.
B
So
next
slide
again,
unless
people
have
objections
or
questions,
I'm
going
to
keep
going
in
the
interest
of
time
all
right.
So
there
was
this
open
question
about
that.
Thiru
had
asked
about
clarifying
the
use
of
symmetric
keys
to
erase
it
the
changes
shown
on
the
screen,
don't
need
to
discuss
unless
somebody
wants
to
because
tyro
who
allow
the
issue
said.
It
looks
good
and
closed
the
issues
so
next
slide
unless
somebody
has
something
they
want
to
discuss.
A
B
Similarly,
we
had
a
solicitor
review
from
russ
housley
most
of
his
comments,
or
I
should
say
you
know,
maybe
half
of
a
little
bit
more
of
his
comments
were
addressed
prior
to
108.
Some
were
not,
and
so
this
is
the
leftover
ones.
The
remaining
comments
from
ross.
You
can
see
the
paragraphs
that
we
did.
The
chairs
verified
and
closed
the
issue,
so
we
believe
that
this
one
is
also
done,
but
you
can
see
the
text
there
in
case
somebody
wants
to
discuss
it.
I
think
we
can
just
go
on.
B
All
right,
this
one
was
another
one
that
was
another
list
post
from
last
month
and
the
issue
here
again
was
raised
since
ihf-108,
and
the
issue
was
as
follows:
the
term
ta
in
the
document
was
defined
as
an
app.
That
quote
runs
in
a
tee
where
runs
means
to
humans
that
there's
code
there
and
it's
not
just
a
piece
of
data.
Okay.
B
So
you
use
the
deep
protocol
to
install
the
code
and
separately
use
the
tek
protocol
to
install
you
know
the
data
configuration
blob
that
it
needs,
but
other
text
in
the
document
only
ever
talked
about
installing
quote
tas
right,
which
implied
that
it
could
not
be
used
to
install
things
that
are
just
the
data
blobs
and
so
hence
the
contradiction
that
was
purely
editorial
now
to
resolve
this.
There
was
already
a
sentence
in
the
document
that
used
lowercase
trusted
components
in
a
way
that
could
clearly
be
read
to
mean
either
a
ta
or
personalization
data.
B
So
the
resolution
was
we
just
capitalized
that
stuck
in
the
terminology
section
to
say
whenever
we
mean
either
code
or
you
know,
data,
only
we
just
use
trusted
components,
and
so
this
proposal
was
raised
on
the
list
a
month
ago.
There
was
no
objection
so
right
before
the
draft
deadline.
We
just
did
it
and
it's
same
in
the
other
specs
too.
B
Next,
I'm
keeping
an
eye
on
the
queue,
so
I
don't
see
anybody
so
just
keep
going
all
right.
So
last
week
we
had
the
hackathon
which
akira
is
going
to
talk
about
later,
but
one
of
the
issues
that
we
found
during
hackathon
was
this
one
that
affects
the
architecture
document.
Okay,
if
you
remember
at
ietf108,
we
had
this
discussion
about
a
way
to
tell
the
tam
that
you
don't
need
a
ta
anymore,
so
that
the
tam
can
then
choose
to
delete
it.
B
B
How
does
it
find
the
requested
tas
and
the
answer
was
we
had
this
conceptual
abstract
api
called
request
ta,
but
there
was
no
symmetric,
unrequest
ta,
and
so
you
had
half
of
the
story
and
the
abstract
api,
but
not
the
other
half,
and
there
was
this
gap
that
we
found
during
trying
to
implement
it,
and
so
the
fix
was
to
add
unrequest
ta
next
to
request
ta
using
almost
identical
language,
except
for
saying,
uninstalled,
okay
and
again
that
issue
again
affects
all
three
documents.
B
But
again
this
was
not
in
the
posted
document
yet
because
it
was
only
found
during
the
hackathon
last
week.
Okay,
but
there's
already,
you
can
see,
there's
a
per
request
there.
So
there's
already
proposed
text
which
is
on
the
screen,
and
so
the
belief
is,
unless
there's
objections,
that
we
would
merge
the
pr
right.
There's
no
text
to
be
written
in
case
unless
you
don't
like
the
text.
So
next
slide.
B
Unless
there's
questions,
we've
got
lots
of
issues
in
the
tea
protocol
to
discuss,
and
so
I
I'm
trying
to
go
through
the
things,
because
most
of
these
are
editorial.
Only
if
you
remember,
we
had
a
discussion
before
about
removing
text
that
talked
about
security
domains
out
of
the
architecture
document
right,
not
that
it's
disallowed,
because
you
might
be
able
to
use
a
suit
manifest
to
do
things
with
security
domains
but
removed
it
from
the
architecture
document.
B
However,
when
we
remove
that
text,
the
following
paragraph,
that's
in
red
was
left
in
there
which
we
missed
because
it
doesn't
use
the
word
security
domain,
but
it's
talking
about
a
problem
that
security
domains
solve
and
it's
under
the
heading.
The
t
protocol
addresses
it.
Well,
that's
not
addressed
by
the
t
protocol,
it's
addressed
by
the
suit
manifest,
and
so
the
editorial
fix
is
delete.
B
C
That's
the
teep
protocol
does
actually
address
this
by
its
inclusion
of
the
suit
manifest,
and
I
realize
that's
a
small
niggle,
but
it
it
strikes
me
that
it
still
does.
C
B
All
right
trying
to
figure
out
if
you
have
an
objection
to
removing
it,
I
would
say
maybe
moving
this
paragraph
to
a
different
document
which
we
don't
have
a
document
that
talks
about
security
domains
in
the
suit
manifest
yet,
but
that's
where
it
would
go
in
my
opinion.
So
all
right,
your
still
list
is
being
shown
in
cube
brennan.
So
I
don't
know
if
I'm
gonna
keep
going.
I.
B
Okay,
great
all
right,
so
I'm
going
to
try
to
finish
this
one
up
here,
so
the
last
one
is
a
something
that
has
not
been
discussed
in
the
list
yet,
and
so
you
can
see,
there's
a
question
mark
in
the
issue
label
here,
and
so
let
me
summarize
this
one
by
saying
this
is
a
question
I
raised
and
filed
an
issue
on,
so
the
working
group
can
decide
whether
we
want
to
do
anything
right.
B
We
could
choose
to
do
nothing,
okay,
and
so
the
observation
is
that
the
t
protocol
won't
be
used
for
everything.
Okay,
three
reasons
for
that
number,
one
for
sim
chips
which
have
you
know,
a
a
t-e-e
and
an
e-uicc
sim
chip
is
already
in
wide
used
by
mobile
operators
and
they're,
not
using
the
t
protocol
they're
using
the
gsma
protocol.
And
if
you
look
at
their
architecture
document,
it
has
diagrams
look
just
like
petite
ones,
just
with
different
labels.
B
Number
two
global
platform
already
standardized
otrp,
which
we
didn't
they
are
now
under
the
second
version
of
it,
meaning
the
second
you
know
1.1
instead
of
v,
1.0
and
so
for
secure
elements.
Gold
platforms
are
using
otrp
third
point.
If
we
go
back
a
couple
like
at
least
two
years
ago,
david
wheeler
gave
a
presentation
about
you
know
in
when
we
were
doing
otrp
about
why
a
bunch
of
stuff
doesn't
make
sense
for
sgx,
because
there's
no
such
thing
as
enumerating
tas
in
sgx.
B
What
does
really
install
mean
and
so
on
and
so
classic
use,
and
by
classic
I
mean
the
uses
that
david
wheeler
had
in
his
presentation.
B
One
might
assume
that
you
don't
need
to
use
the
t
protocol,
because
what
would
it
do-
and
this
came
up
also,
we
were
trying
to
implement
it
and
so
there's
a
proposal
that
says
we
could
explain
what
teep
is
applicable
for
and
it
could
be
applicable
to
things
in
sgx.
B
There
was
a
presentation
I
gave
on
behalf
of
mike
purcell
about
the
anarchs
project
about
a
year
ago,
when
we
were
talking
about
which
direction
the
transport
protocol
does,
and
so
we
said,
the
heat
protocol
is
actually
a
use
for
that
one,
but
transports
in
the
direction
so
last
slide
going
to
the
next
one,
which
is
just
showing
some
proposed
text
in
the
per
request.
Should
we
choose
to
do
something?
B
This
is
what
we
might
say
if
we
were
to
say
something,
and
so
in
the
introduction
section
you
know
it's
applicable
to
tees
that
can
install
and
enumerate
tees
in
a
tee
secured
location
where
another
domain
specific
protocol
standard
that
meets
the
needs
is
not
already
unused.
That's
an
example
of
something
we
might
say:
okay,
the
sgx
section
and
the
trustzone
section.
B
We
have
sections
on
both
of
those
which
kind
of
imply
when
you
read
them
that
protocol
is
applicable,
and
so
all
that
text
there
is
fine,
but
we
might
augment
it
with
a
paragraph
like
these.
That
say,
in
which
cases
it
might
actually
be
applicable
to
sgx,
and
this
is
using
the
nrx
model
without
ever
using
the
word
anarchs
here
and
similarly
for
trust
zone
where
there's
multiple
ta
stores,
such
as
an
opti
than
anything
where
you
can
install
stuff
in
a
trusted
location,
it's
applicable.
For
so
that's
an
example
of
what
we
might
say.
B
D
So
what
I
was
trying
to
ask
is,
you
said,
applicability.
I
think.
That's
that's
a
good
point.
So
I've
I've
been
a
little
bit
absent
last
time
in
the
wg
meetings,
and
now
I'm
wondering
what's
the
key
difference
between
gsms
and
gp's
cheap
flavors.
That
already
are
there
what's
what's
this
solution,
bringing
to
the
table
is
that
a
applicability
content
that
should
also
be
highlighted
somewhere.
B
My
I've
looked
at
the
gsma
spec.
I've
looked
at
the
otrp
spec.
My
belief
is
that
they
are
roughly
accomplishing
the
same
goals,
but
gsma
and
otrp
respectively,
are
for
very
domain
specific
purposes
like
otrp.
Has
lots
of
security
main
stuff
built
in
and
gsma
stuff
has
stuff?
That's
very
specific
to
you
know
mobile
operators
and
sims
and
stuff,
but
at
a
high
level
they
do
the
same
thing,
and
so
my
belief
is
gsma
already
has
a
deployed
protocol,
there's
no
incentive
for
them
to
switch
at
least
right
now.
B
There's
not
similarly
global
platform
has
a
protocol
there's
no
incentive
for
them
to
switch
right,
but
if
you're
designing
something
for
sgx
or
trust
zone
and
you're
in
these
other
use
cases,
there's
incentives,
and
so
I
I
don't
know
of
a
reason
to
switch,
but
they
are
a
lot
alike
in
terms
of
like
I
said,
if
you
look
at
the
protocol,
the
the
architecture
diagram,
you
can
just
change
the
labels,
it's
the
same
as
our
diagram.
B
D
B
The
other
protocols,
okay,
that
one
I
do
know
because
I
was
a
chair
at
the
time
and
part
of
the
stuff,
the
other
ones
are
not
applicable
outside
their
domain
right
and
so
otrp.
You
can't.
B
D
Okay,
excellent,
so
it's
like
the
the
abstracted
generalized
version
of
flavors
that
exist.
Okay,
thanks
exactly
so
that
is
probably
captured
somewhere
prominently
at
the
beginning,
yeah.
E
Thanks
harness,
isn't
you
yeah
yeah?
I
just
wanted
to
add
this
is
honest
here
like
there's,
obviously
a
a
long
history
with
otrb
and
why
we
have
chosen
to
design
deep
in
the
way
it
is
currently
designed,
and
I
don't
think
that
history
needs
to
go
into
the
document,
because
it's
obviously
like
the
dirty
laundry
of
standards,
work
between
different
organizations
and
how
things
can
go
sideways
in
some
sense
yeah.
E
One
of
the
reasons
why
otrb
and
deep
now
look
different
this,
and
I
think
this
is
quite
important-
is
that
we
made
use
of
eat
and
and
the
rats
work,
as
well
as
the
suit
work,
which
I
believe
and
that's
what.
If
you
look
at
the
the
content
of
the
otrb
protocol,
that's
what
most
of
it
talks
about,
and
so
we
we
managed
to
sort
of
generalize
this
and
put
it
into
separate
buckets.
And
I
think
that
solution
is
like
technically
much
better.
E
It
would
be
worthwhile
to
to
describe
those
differences,
but
that
would
obviously
be
be
much
longer.
B
B
Okay,
I
can
do
the
next
one
in
two
minutes,
which
is
the
transport
spec
you're
on
okay,.
B
Next
yep
minutes
say
from
iutf108
said
we're
going
to
publish
as
soon
as
two
things
are
done,
moving
text
and
doing
redirects
next
slide.
Both
of
those
were
done
as
well
as
during
the
meeting
ben
cadec
raised
some
questions
about
text
referring
to
2818.
B
We
just
copied
a
sentence
from
an
existing
rfc
that
doesn't
reference
2018,
so
we
match
kind
of
what's
already
gone
through
iesg.
There
was
a
discussion
at
108
around
headers,
so
we
removed
cash
control,
as
hannah
said
proposed,
and
there
was
one
fix
that
when
I
followed
up
with
mark
nottingham,
he
said
unsupported.
Media
type
should
be
415,
not
406..
So
we
corrected
that
in
the
text
next
slide.
B
I
only
got
one
more
slide,
so
please
go
to
slide
four
okay.
There
we
go
only
one
new
issue
was
raised,
which
is
that
issue
that
we've
already
discussed
in
the
architecture
document,
and
so
we
made
similar
changes
here
and
there's
the
open
pull
request
on
the
unneeded
ta.
That
would
affect
this
stock
too
again.
Similarly,
if
we
accept
it
on
the
architecture,
we
accept
it
here.
So
that's
it.
Nothing
new
to
discuss
here
that
we
didn't
discuss
during
architecture
or
already
at
108,
so
done
cool.
A
A
E
F
F
People
who
are
engaged
to
be
sending
audio
will
have
like
a
greenish
background
and
the
microphone
logo
will
be
blue.
Oh.
G
F
Participant
list,
and
so
at
the
time
akira
was
in
that
state
with
the
blue
microphone
icon,
and
now
I
see
him
there
in
that.
F
E
A
B
B
B
B
Okay,
all
right
so
there's
a
number
of
issues,
there's
three
collectively
that
I'll
talk
about
here
that
are
introduced
on
the
curious
slides
and
so
today,
every
teat
message
has
a
token.
The
token
is
an
unsigned
integer
that
the
tam
sends
that
agent
echoes
back
in
the
response,
so
this
does
require
the
tam
to
create
state
to
store
the
token,
even
for
a
query
request
now,
a
courier
quest
other
than
the
token
is
identical
to
when
it's
sent
to
every
client.
B
The
only
thing
that
differs
in
query
requests
is
the
token
field.
Okay.
So
that
means
that
you
have
to
keep
state
and
there's
no
other
reason
in
the
query
request
to
keep
state
the
query
response
at
least
allows
you
to
or
requires
you
to,
depending
on
who
you
implement.
It
includes
the
attestation
evidence
the
attestation
evidence
already
has
a
separate
challenge
field.
That's
in
the
query
request.
That's
echoed
back
in
the
attestation
evidence!
Okay,
so
if
you
think
about
well,
how
do
I
do
replay
protection?
B
I
need
tokens
for
that
to
ensure
you
know,
freshness
and
so
on.
Well,
you've
already
got
the
challenge
field
for
that.
There's
multiple
layers
of
stuff
going
on
right,
there's
the
tls
layer
which
might
terminate
outside
the
tees.
You
can't
trust
that
there's
the
cose
header
there's
fields
in
the
teep
message
like
token
and
then
there's
things
inside
the
evidence,
and
so
since
replay
protection
with
evidence
is
already
done
by
the
challenge.
B
As
long
as
you
already
have
as
long
as
you're
using
the
challenge
and
the
eat
or
evidence,
then
you
don't
need
the
nonce
for
purposes
of
matching
or
replay
protection,
because
you
can
already
get
that
out
of
the
challenge.
Okay.
So
if
you
do
do
a
token,
then
this
introduces
this
complex
question
I
ran
into
with
the
implementation
says.
So
when
do
you
clean
up
state
right?
So
let's
say
you
send
the
query
request
and
you
never
get
a
query
response
right.
B
You
actually
have
to
clean
up
state
according
to
some
implementation,
to
find
things
so
there's
some
complexity
to
deal
with
that.
Okay,
but
does
it
actually
buy
you
anything
in
the
query
requesting
response?
So
the
first
question
is:
could
we
just
get
rid
of
the
token
and
the
query
request
and
the
query
response?
B
Okay
now
hold
on
that
question
for
a
second
here,
let's
go
on
to
the
next
slide,
it
says:
does
the
token
actually
buy
you
anything
because
out
of
the
hackathon
implementers,
none
of
us
could
come
up
with
an
idea
of
why
you
needed
a
token
in
their
career
request
during
response,
given
that
you
had
the
challenge
and
that's
echoed
back
in
the
in
the
rats
evidence,
so
then
you
say
well
is
the
token
needed
for
install
and
delete
right,
because
you
got
to
know
which
install
you're
sending
the
success
to
or
which
delete
you're,
sending
the
error
to
well-
and
this
is
where
I
wanted
brendan
to
be
part
of
this
discussion
here,
because
again,
there's
multiple
layers
of
stuff
here
and
today.
B
This
in
the
latest
drafts
that
we
have
the
success
and
error
message
can
include
suit
reports.
The
suit
reports
have
the
results
of
the
install
and
the
delete
okay
and
so
in
a
suit
report,
and
this
is
echoing
stuff
out
of
brendan's
suit
report
draft
there's
a
manifest
digest
that
one
is
what
identifies
which
suit
manifest
was
being
installed
or
uninstalled.
That
might
have
the
success
of
errors
and
the
suit
record
has
you
know
a
a
an
array
of
zero,
more
suit
records
that
have
you
know
success
or
failure,
results
or
status
points
or
whatever?
B
So
my
claim
is,
I
don't
know
that
you
actually
need
a
token
for
matching
purposes
in
the
installer
delete
either,
because
we
have
the
suit
manifest
digest
and
things.
So
you
can
ask
well
what
about
replay
protection?
Well,
how
do
you
know
that
the
suit
reports
that
you're
getting
aren't
replayed
by
you
know
the
re
or
something
from
things
that
were
suit
reports
from
you
know,
last
week
five
months
ago,
or
something
like
that?
How
do
you
know
the
student
reports
are
fresh?
Okay
and
so
again,
maybe
you
saw
that
at
the
cose
layer.
B
Maybe
you
saw
it
in
the
suit
report
itself,
but
I
don't
know
that
you
need
to
solve
it
in
the
teep
message,
and
so
the
proposal
too
is:
could
we
use
either
the
cose
header
or
the
suit
reports
and
not
use
the
token
and
installer
delete
either?
And
so
let
me
open
it
up
here
because
I
see
conus
is
already
in
queue.
E
So
the
the
token
which
is
announced
that
it's
initially
sent
by
the
dam
and
then
relate
back
in
the
response
you
said
like
you-
could
also
use
the
nuns
for
that
purpose.
But
it's
not
it's
not
necessarily
the
case
that
the
nonce
is
always
used.
When
this
the
ban
doesn't
need
attestation
information,
then
it
wouldn't
use
the
nons.
E
B
So
I
think
two
things
we
talked
about
during
the
hackathon
one
is:
is
there
any
such
case
where
you
would
not
want
to
include
the
evidence
and
number
two?
If
there
is,
could
you
just
have
the
token
be
optional
and
only
used
in
such
a
case
and
number
three?
Are
you
actually
buying
anything
given
that
the
suit
that
they,
sorry,
that
the
query
requests
are
identical?
B
E
Yeah,
so
for
me,
like
the
reason
why
there
was
the
need
to
associate
the
response
to
request,
was
we
said
in
the
architecture
document
that
we
may
have
actually
multiple
des
on
a
single
device,
and
this
is
request.
It
needs
to
know
how
to
match
one
request
to
the
other.
I
think
that's
where
it
came
from
initially.
C
So
that
when
I
wrote
this,
I
had
assumed
that
there
was
going
to
be
a
replay
protection
layer
underneath
the
suit
report.
But
I
don't
see
a
problem
with
including
it
and
I
think
pretty
much
anywhere
that
it's
used.
Replay
protection
is
probably
going
to
be
a
question,
so
it
probably
needs
some
kind
of
counter
in
there,
but
I
suspect
it
needs
to
be
very
loosely
defined
because
the
the
content
of
whatever
token,
if
you
will
the
suit
report
contains,
is
probably
highly
application.
Dependent.
B
Yeah,
you
can
see
my
bullet.
There
probably
applies
to
suit
reports
in
general,
so
when
we
have
this
discussion,
the
suit
working
group
later
this
week,
we
might
want
to
have
this
issue
in
suit,
because
this
is
probably
not
teach
specific
right
suit.
Reports
in
general.
C
D
So
hi
this
is
hank,
so
I
I
heard
the
term
evidence
so
then
I
my
attention
was
packed,
of
course,
so
my
assumption
is
that
the
request
does
not
include
a
heat,
but
the
reply
will
substitute
the
nuns
for
the
eat
or
I
expected
the
time
to
issue
a
eat
on
the
on
the
request.
Also,
I
I
didn't
see
the
request.
B
The
request
can
include
a
challenge
which
you
can
interpret
as
being
nonce,
but
it
could
be
something
more
than
a
knowledge
just
depends
on
what
the
what
the
mechanism
is.
So
when
I
say
challenge
you
can
re,
you
can
hear
that
as
saying.
Oh,
he
said
nahs
right,
so
the
request
has
a
challenge.
The
response
includes
the
evidence
as
long
as
the
tam
requested
it,
and
so
the
challenge
is
used
in
computing,
the
evidence
so
and
the
evidence
is
it
by
default
and
eat.
Yes,.
D
Okay,
so
you
basically
would
not
return
the
challenge
content,
but
the
challenge
content
is
then
nested
in
the
evidence,
and
that
would
be
yeah
so
not
to
say
that
yeah.
B
Model
right,
you
have
a
nonce
generated
by
the
verifier,
and
so
that's
the
challenge
and
then
the
nonce
is
then
included
inside
the
eat
to
give
freshness
and
that's
what
is
done
here.
D
Okay,
but
that
that
that
by
extension,
also
adds
as
the
included
nones
for
the
streets
for
the
term,
sorry
for
the
response
to
the
jam,
so
that
is
like
the
double
layout
announcement
to
speak.
Okay,
that
is
fine.
D
I
think
it's
a
good
idea
and
the-
and
I
just
want
to
have
a
small
comment
here-
clarifying
comment
on
the
reports,
so
the
suit
report
was
created
with
evidence
and
attestation
results
in
mind,
so
it's
ease
of
computability,
so
it's
relatively
high,
highly
refined
evidence
claims
here
that
could
be
used,
probably
even
in
metrics
for
attestation
results.
It's
relatively
easy
without
a
complicated
policy.
B
Okay,
so
I
think
so
far
what
I'm
hearing
just
to
summarize,
the
last
three
speakers
put
together,
is
just
that
there
might
still
be
a
case
for
a
token,
but
maybe
it's
not
required.
Maybe
it's
optional
and
I
think
akira
has
in
his
deck
a
slide
that
shows
the
different
uints
and
things
that
was
one
of
the
proposals
and
so
I'll.
Let
akira
cover
that
option
in
his
slides
and
but
otherwise.
I
think
we
actually
depend
on
the
resolution
to
the
suit
discussion
to
resolve
this
one
for
sure.
E
Yeah,
I
I'm
okay
with
having
it
optional
in
the
in
the
response,
but
I
believe
we
need
to
have
a
replay
protection
mechanism
in
there
I
sort
of
not
the
replay
but
the
liveness
guarantee,
because
when
we
create
the
signature
over
the
message
of
a
response
message,
there
has
to
be
something
that
proves
that
it
has
been
created
recently.
E
Be
undangled
from
the
eat
likeness
check,
which
you
talked
about.
I'm
happy
to
do
a
formal
analysis
to
make
sure
that
the
brotherhood
is
fine.
B
C
Yeah,
so
there
was
a
comment
that
you
made
about
the
about
using
it
for
attestation
hank.
Specifically,
you
made
that
comment.
I
I
did
look
through
that
and
I
discussed
that
with
with
dave,
and
I
think
the
conclusion
that
we
came
to
was
that
using
it
for
attestation
might
be
possible,
but
that
it's
probably
more
complex
than
is
necessarily
useful
for
attestation
purposes.
As
a
general
case.
B
Okay,
so
I
would
propose
that
we
have
that
follow-up
discussion
in
the
suit
working
group
rather
than
here,
because
we
have
other
issues
to
talk
about
so.
A
Yeah
so
time
tech
tell.
G
A
B
13.,
okay,
thank
you
just
cut
me
off
because
I
I
I
believe
that
we
have
more
slides
and
we'll
get
through
so
we'll
get
through
as
many
as
we
can
and
then
we'll
stop.
So
all
right.
So
this
one
again
there's
two
issues
that
have
to
do
with
cipher
suites,
okay.
So
what
the
draft
does
right
now
is
it
defines
two
cipher
suite
values.
You
can
see
there
kind
of
defines
like
an
iona
registry
and
there's
two
values
out
of
there
defined
right
now
and
the
messages
you
can
see.
B
The
supported,
cypher
suites
is
an
array
of
sweet
values,
and
so
that's
what
the
tam
sends
and
then
the
agent
sends
back
a
selected
one
which
is
a
single
one
and
then
the
combined
cdl.
You
see
this
cypher
sweets
as
bitmaps.
Okay,
well,
you've
got
this
array
of
sweet
values
that
looks
like
a
typo.
So
that's
what
72
is
is
why
does
that
say
as
bitmaps?
We
think
that
you
just
say:
cipher
sweets
and
bleep.
Those
two
words.
So
that's
issue
72
73,
which
I
think
is
just
trivial
editorial.
B
So
73,
on
the
other
hand,
is
you've,
got
two
different
values
defined
right.
If
your
tam
only
supports
value
one,
your
agent
only
supports
value
two
or
vice
versa.
You
don't
have
interoperability,
so
the
question
is
what
cipher,
suite
or
suites
are
mandatory
to
implement
on
each
end?
That's
what
73
is.
I
don't
know
what
the
recommendation
is
there,
but
I
would
defer
to
any
crypto
people
here
if
they
have
a
recommendation,
sure
what
should
be
mandatory
to
implement.
B
F
So,
jumping
in
this
is
ben
k
duck.
We
tend
to
prefer
the
x25509
and
dsa
of
de
novo
deployments,
where
you
don't
have
any
legacy
considerations
to
to
work
with,
but
we
tend
to
have
to
fall
back
to
p256
and
es256
for
cases
where
you
have
like
a
tpm
or
a
smart
card
that
can
only
do
the
older
algorithms.
B
F
B
B
Right
so
you
can,
I
mean,
there's
multiple
ways
to
get
interoperability
right.
You
can
either
pick
one
and
say
both
ends
have
to
do
that
one
and
could
choose
to
negotiate
something
else
or
you
can
say
that
one
end
has
to
do
all
of
the
set
and
the
other
end
can
choose
which
one
it
wants,
and
so,
if
you
think
about
tp
agents
that
are
in
constrained
devices,
then
maybe
mandating
too
or
you
want
the
one
that's
best
for
a
small
iot
device
or
something
like
that.
B
A
A
B
Okay,
right
ning.
H
Oh
yeah,
I
can
speak
okay.
So
just
what
comment
on
what
you
said
there
was
in
our
old
protocol.
We
already
have
say
time
supported
mandatory
support
both
and
agents
support
one
for
them,
so
I
will
support
that
position.
So
that
has
to
be
the
case.
B
Okay
sounds
like
we
actually
have.
I
don't
hear
anybody
arguing
for
something
else.
So
as
an
author,
I
will
accept
that
as
being
direction
of
the
authors.
So
next
slide.
B
Yeah,
okay,
so
here
there
is
this
thread
that
was
joint
rats
and
teeth
with
the
title.
Each
claims
needed
by
t
right.
This
one
is
still
open.
Where
the
architecture
document
says,
here's
some
things
you
have
to
be
able
to
express
in
claims
somehow
and
doesn't
say
how
that
leaves
it
to.
You
know
something:
it's
a
normative
spec.
B
Already
there
and
lauren
said,
respondents
saying
yep:
we
need
a
new
claim,
yep
we
need
to
claim
and
in
rats
yesterday
or
whatever
lawrence
mentioned,
that
they're
still
working
on,
they
have
pull
requests
and
stuff
in
progress,
and
so
because
of
that,
my
summary
is
that
we
that
the
proposal-
at
least
I
think
from
lawrence
and
myself-
is
that
we
should
not
define
yet
and
let
tell
proven
otherwise
any
type.
Specific
claims
right.
B
Lawrence's
belief-
and
I
agree-
is
that
everything
in
this
list
is
things
that
would
be
applicable
outside
of
teep
and
so
would
go
into
the
eat
spec
or
something
in
the
rats
working
group,
and
we
can
just
refer
to
it,
and
so
some
of
them
are
there.
Now
some
of
them
are
not,
but
and
in
rats
lawrence
mentioned
that
for
firmware
and
software
identifiers
right.
B
He
says
the
intent
for
software
claims
to
use
coswood,
and
this
is
on
a
slide
in
the
rats,
you're
working
group
and
but
there's
nothing
in
the
eat
document
about
coswoods,
yet
okay,
so
I
think
I'll
mention
that
in
the
next
slide
or
two
slides,
if
I
get
to
it,
so
we'll
come
back
to
that.
But
here
I
think
there's
nothing
for
us
to
do
yet
right
now,
I'm
just
reporting
out
that's
what
I
saw
on
the
thread
so
next
slide.
A
B
A
glue
on
your
okay,
so
yeah
coming
now
drilling
down
to
this
causewood
stuff.
Okay,
so
what
we
need
in
teep
is
we
need
a
version
independent
id
and
by
version
independent,
I
mean
you
know
as
you
rev
your
suit
manifest
with
you
know,
patches
and
so
on.
You
increase
your
manifest
sequence,
number
you're,
going
to
increase
your
component
id
sequence
and
your
version
number,
and
so
on,
but
version
independent
identifier
that
we
can
use
in
messages
and
abstract
apis,
like
request
ta.
B
B
The
coswood
spec
has
this
tag
id
that
says
it's
a
16
byte,
uniquely
identif,
uniquely
referencing,
a
software
component,
so
to
my
unknowledgeable
eyes
that
tag
id
looks
like
it
would
meet
the
requirement,
but
it's
optional
in
suit,
and
so
one
thing
we
could
do
is
to
say
suit.
Manifest
carried
in
teep,
for
this
purposes
need
to
use
the
coswood.
But
this
is
the
other
one
that
I
needed
brendan
here
and
so
brendan.
Please
correct
what
I'm
what
any
misunderstandings
I
have.
B
If
you
have
something
that's
great,
I
think
when
I
had
asked
about
a
component
identifier
in
some
message-
maybe
you
I
don't
remember
which
message
it
was.
I
didn't
see
anything
in
the
suit
manifest
document
right
now
that
was
directly
usable
other
than
causewiz.
So
please
correct
me:
if
there
is
something
that's
version,
independent
id,
so.
C
What
you
have
in
in
suit
for
purposes
like
this
is
the
component
identifier
and
the
way
that
it
works
is
it's
an
array
of
byte
strings
so
that
you
can
represent
a
notional
path.
So
when
we
talked
about
trusted
domains
previously,
the
idea
was
that
we
were
going
to
have
a
te
identifier,
followed
by
a
trusted
domain.
Identifier,
followed
by
a
vendor
identifier,
or
maybe
I've
got
those
two
in
the
wrong
order,
not
important
and
then
followed
by
some
kind
of
ta
identifier.
B
Okay,
so
if
you
think
that
that's
what
we
should
be
using,
then
I
am
happy
to
you
know,
generate
a
pull
request
that
points
to
things
as
long
as
you
tell
me
what
the
right
term
to
use
is,
and
we
can
do
that
offline
then.
C
That
sounds
like
that
would
be
my
inclination
if
there's
a
good
reason
not
to
take
that
approach.
We
talked
about
using
uuids
for
tas
as
well,
so
I'm
not
entirely
sure
whether
you're
looking
for
a
uuid
here
or
not
just
has
to
be.
B
E
This
total
makes
sense
to
me.
I
was
just
wondering:
maybe
you
can
explain
what
the
idea
of
the
cost
suite
would
be
here.
I'm
not
not
too
familiar
with
or
not
enough
familiar
with
coursework
to
say
like
whether
this
would
how
this
actually
relates.
B
It's
just
something
that
can
uniquely
identify
a
software
component
right
I
mean
the
tag.
Id
is
something
that's
just
16
by
that's
already
an
existing
thing.
That's
neither
rats
nor
suit,
nor
teep
specific
right.
It's
from
saccum,
it's
not
an
rfc.
Yet
it's
an
active
draft
right.
E
Okay,
but
if
we,
for
example,
as
brenton
said,
if
we
put
use
the
component
id
from
the
suit
manifest
and
put
use
that-
and
maybe
that
contains
a
uid
in
in
our
case-
that
we
can
mandate
that
that
should
be
fine
yeah
yeah.
B
I
agree,
then
we
should
be
fine.
Okay,
I
think
I
may
have
time
for
one
more
slide.
B
If
I
got
two
minutes
we'll
see,
so
let's
go
one
more
slide
and
cut
me
off
in
two
minutes:
okay,
okay,
so
this
one
was
an
issue:
that's
been
going
back
and
forth
between
hanus
and
me,
and
I
forget
who
else
might
have
commented
on
that
thing,
but
it's
been
on
the
issue
not
on
the
list,
so
this
is
to
raise
visibility
here
and
to
get
more
inputs
here,
not
necessarily
in
the
next
few
minutes,
but
at
least
to
tell
you
to
things,
and
so
here
we
have
suit
manifest.
B
That
can
depend
on
other
suit
manifests
the
things
it
depends
on
might
be
even
having
to
come
from
a
different
tam
right,
there's
a
case
that
we
talked
about
in
the
context
of
the
architecture
document
where
you
have
personalization
data
that
might
need
to
come
from
a
different
tam
than
the
ta
binary.
That's
one
of
the
use
cases
we
talked
about.
You
know
last
year
sometime,
and
so
let's
assume
that
you
have
a
dependency
from
suit,
manifest
a
on
to
suit
manifest
b.
B
B
You
know
a
depends
on
b,
so
there's
at
least
four
options
here,
and
maybe
different
people
have
different
preferences
here
and
it's
also
possible
they're
gonna
be
multiple,
correct
answers
and
so
option
number
one
is
to
say
well,
the
tam
has
to
resolve
all
the
dependencies
and
then
pushes
down
the
blob
of
all
the
suit
manifest
down
to
the
agent
in
one
install
message.
Well,
that's
problematic.
B
B
Well,
you
could
just
not
respond
to
the
first
install
message
until
all
the
dependencies
are
resolved
and
suit
processing
completes,
but
maybe
that'll
take
a
bunch
of
time.
So
what
does
the
tame
do
in
the
meantime
and
option?
Number
four:
is
the
agent
resolves
those
dependencies
but
sends
back
some
progress?
Notification
of
the
tab?
Maybe
there's
other
options,
but
those
the
four-
and
I
think
I
am
out
of
time
now,
and
so
my.
B
G
A
A
G
Yes,
yes,
next
slide,
please.
G
Yes,
I'm
going
to
talk
something
first,
which
is
not
written
in
this
slide.
So
what
really
happened
during
the
hackathon
week?
G
Initially
my
plan
was:
there
was
many
update
for
the
xero4
draft
in
the
deep
protocol,
so
up
catch
up
with
the
latest
draft
with
on
monday
and
tuesday
and
then
announcing
about
wednesday
when
we
all
get
together
with
do
the
connecting
individual
time
and
time
server,
tama
time
server
and
deep
device.
But
what
really
happened
was
we
were
busy
in
internal
updating
in
implementation
of
deep
device
to
adopt
the
therefore
draft
until
thursday,
night
or
something?
G
So,
what
really
happened
was
having
a
discussion
meeting
on
friday
and
that's
the
photo
during
the
hackathon
agenda
in
this
slide.
So
that's
the
reality,
but
we
got
many
things
raised.
I
mean
not
raised
but
to
find
improve
the
draft.
So
yeah
that's
wait
and
that's
the
from
the
next
slide.
Next,
please.
G
Oh
yes,
that
was
this
is
the
picture
from
the
on
friday.
Yes,
next,
please
and
yes,
these
are
the
implementation
we
at
the
moment
we
know
on
on
friday,
so
I
I
know
that
harness
and
and
ming
we
might
also
have
the
implementation,
but
yes
and
next
slide.
G
Please-
and
these
are
the
details,
but
most
of
the
details
listed
here
is
overlap.
What
about
what
dave
have
presented
before
and
it's
related
with
the
most
of
it
is
token
and
and
another
another
two
topics
of
how
to
consider
a
consideration
of
the
token
and
the
second
is
the
detail,
t
protocol
message,
compatibility
and
detail
compatibility
is
we
could
something
we
could
improve
with
with
a
github
issue
and
pull
requests
and
merging
it.
G
However,
the
discussion
of
the
token
it
was
a
bit
more
serious
and
from
the
hackathon
implementing
perspective
of
the
token
discussion
is
oneness
we
need
is
that
token
need
to
be
mandatory
or
option,
and
and
but
most
importantly,
from
the
implementing
on
the
tip
device
and
time
is
how
to
generate
the
token
which
will
not
likely
to
collide
between
the
different
time.
G
So
everything
I
think
we
need
some
guidance
in
the
the
draft,
how
to
generate
the
token
and
then
another
thing
is
in
the
implementation
of
the
tipped
install,
which
is
just
sending
the
binary
from
tam
server
to
the
device.
G
We
need
some
kind
of
id
and
so
right
now
the
ta
name
change
the
tc,
so
tc
unique
id,
and
if
we
not
explicitly
written
in
this
draft,
we
might
end
up
somebody
in
the
implement
implementer
using
token
in
for
the
tc
id
unique
id,
which
is
not
a
good
practice.
So
I
think
we
we
we
have,
we
we
did
have.
We
were
discussing
what
what
is
the
unique
id
really
going
to
be
used
and
and
on
the
fridays
dcid?
G
What
going
to
be
a
tc
unique
id
is
something
we
need
it's
not
we
don't
we
not
really
don't
have
it
right
now,
but
probably
it's
going
to
be
a
tc
list
or
in
this
suit
manifest.
G
So
and
another
discussion
was
right:
now
we
were
all
busy
just
supporting
seaboard
and
the
keep
seaboard
present
a
representation
for
the
binary
was
keep
the
updating
where
we
were
just
following
the
update.
Was
it
end
up
our
work,
but
in
the
next
next
step
will
be
supporting
coset
and
then
we
really
need
which
cypher
suit
should
we
need
to
implement
for
the
at
least
for
the
hackathon,
or
interpret
the
test
between
the
time
server
and
deep
device?
And
that's
something
I
saw
the
discussion
in
the
dave's
slot.
G
Yes,
yeah:
these
are
almost
related
to
the
token
or
tip
tip
message,
details
of
the
binary
format
or
not
notation
representation,
and
one
thing
improvement
is
we
have
we
didn't
have
a
time,
but
we
we
now
have
the
unneeded
ta
list.
So
we
could
use
that
for
the
removing
the
ins,
the
binary
inside
the
chip
device.
C
G
G
And
these
are
the
some
of
the
changes
we
were
able
to
close
during
the
the
week
at
the
hackathon.
It's
most
of
them
are
just
binary
format-
compatibility,
yes,
okay
and
next
page.
Please.
B
Yeah
dave's
in
the
queue
so
accurate.
There
was
one
thing
and
I
don't
remember
which
issue.
If
you
can
point
people
to
it,
it
was
the
one
where
we
had
the
discussion
about
the
the
integer
field
at
the
end
and
being
able
to
combine
stuff
into
the
star
ant
and
stuff
which
which
issue
number
was
that
remember.
B
Token,
if
we
make
the
token
optional
for
that
discussion,
see
issue
number
78.
It
sounds
like
okay,
thanks.
G
So
we
might,
we
have
to
change
the
tip
message
framework
from
the
beginning
to
making
which
which
which
member
entry
going
to
the
option
and
it
and
enter,
is
going
to
be
up
mandatory
and
up
soon.
G
A
B
B
Like
use
the
cancelled
rat
slot
for
a
side
meeting
or
a
schedule
of
virtual
interim
afterwards,
anything
like
that
so
yeah,
please,
whatever
we
can
do.
A
A
F
I
mean,
I
think,
if
we
wanted
to
have
a
bunch
of
people
get
together
and
and
have
a
side
meeting
in
that
slot.
That
would
be
great.
I
don't
really
expect
us
to
be
able
to
sort
of
turn
it
into
an
official
2
second
session,
or
something
like
that.
A
I
don't
know
that
we
need
to,
I
mean,
and
I
don't
want
to
lose.
The
momentum
so
will
are
folks,
okay
having
a
I
should
we
call
it
a
side
meeting.
Then.
F
Yeah
a
side
meeting
or
a
working
session
or
something
yeah.
I
think
we
would
have
to
use
webex
to
answer
dave's
question.
A
Okay,
well,
I
can
set
one
up
russ.
You
were
saying
something.
A
I
guess
I
will
try
and
do
a
quick
show
of
hands
if
there's
enough
interest
in
participating.
Let
me
post
a
question:
will
you
be
able
to
participate.
A
A
A
B
That
sounds
good
webex
side
meeting
with
nine
people
is
a
good
set.
So
thanks.