►
From YouTube: IETF106-TEEP-20191119-1000
Description
TEEP meeting session at IETF106
2019/11/19 1000
https://datatracker.ietf.org/meeting/106/proceedings/
A
All
right
good
morning,
everyone
you
are
in
the
trusted,
execution,
environment
and
provisioning
working
group.
If
this
is
not
the
group
that
you
want
to
be
in
you're
in
the
wrong
room,
I
want
to
welcome
you
to
the
IETF
106.
We
will
be
going
through
a
lot
of
items
here,
but
the
first
thing
I
wanted
to
do
was
make
the
announcement.
The
reason
why
I'm
sitting
here
by
myself
is
because
Dave
will
be
taking
a
bigger
contributing
role,
but
I
wanted
to
thank
Dave
for
all
of
his
contributions
and
allow
Ben
to
make
an
announcement.
B
Thanks
Dave
we're
all
looking
forward
to
seeing
more
from
you
in
the
future,
you're
not
going
anywhere,
but
I
also
wanted
to
say
thank
you
to
Tirek
on
you.
Come
duh
right
contribution,
sing
it
right
for
agreeing
to
take
over
from
Dave
as
a
co-chair.
So
everybody
please
welcome
to
and
we're
looking
forward
to
working
with
you
in
the
future.
Welcome.
A
B
A
Thanks
alright,
so
with
that,
let's
get
to
the
orders
of
business
I,
don't
think
I'm
gonna
read
through
the
note.
Well,
everybody
is
aware:
do
we
have
any
new
attendees
here,
Johanns
good?
So
you
are
all
well
aware
of
the
note.
Well,
so
we
can
move
on
with
respect
to
the
administrative
tasks.
I
believe
I
have
a
couple
of
folks
that
voluntary
volunteer,
zero
being
one
Oh
Frank
escaped.
A
A
A
Got
a
love
curl.
You
know,
okay,
so
with
that
we
had
a
very
productive
hackathon
this
week
and
so
Akira
will
be
providing
that
report
and
then
Dave
will
spend
the
rest
of
the
time
going
through
the
architecture.
So
now
that
dave
has
stepped
down
this
chair,
you
might
have
seen
the
announcement
that
to
help
expedite
things,
Dave
is
now
also
going
to
be
a
contributing
editor
for
the
architecture
draft.
So
any
objections
or
items
to
add
to
the
agenda.
A
C
A
C
What
would
plan
it's
in
the
slide,
so
we
make
me
think
main.
Actually,
we
did
in
a
hackathon,
this
testing
implementation
of
our
TRP
over
HTTP
and
and
they,
when
you
so
Bassam
brought
the
time
and
and
David
also
and
I
brought
the
teeth
device
didn't
know
what
to
say
for
the
tip
device.
So
probably
it's
going
to
be
cheap
device
from
now
on
and
yeah
little
bit
of
a
misspelling
but
yeah
all
the
participants
at
the
hackathon
and
yes.
C
So
this
is
the
table
and
that
you
are
uploading
able
to
uploading
PA
the
present
application
on
the
Tam,
and
this
is
the
arm
64
bit.
Actually,
it's
cortex
a53
a
core
device
with
connecting
with
PC
to
reboot,
in
able
to
flash
the
bootloader
and
Wireshark
the
back
printf,
debugging,
messaging,
etc
and
yeah.
C
Yes,
my
my
knowledge
of
the
IETF
in
2001
around
2001
is,
if
any
anything
is
have
UDP
working
was
okay
to
do
something
like
RTP
on
top
of
it,
and
there
was
no
operating
system,
doesn't
speak
UDP
that
time,
but
now
for
the
water
IP
hackathon
yeah
here
is
the
filter.
Consider
what
we
need,
but
so
many
things
underneath
must
be
already
working
to
make
the
or
TRP
t
working.
C
So
that's
something
we
learned
at
the
hackathon
and
something
went
well
is
preparation
from
the
beginning
of
a
Saturday
without
harming
or
disturbing
or
making
the
RET.
If
Network
down,
we
were
able
to
send
so
many
a
misspelling
or
non
know,
terminated
packets
on
the
network
and
nothing
went
wrong.
Only
was
able
to
debug
it
and
able
to
cross
check
with
the
other
implementation
of
a
time
from
the
ISOBUS
onsen
tape.
C
C
I
only
have
five
minutes,
so
we
need
to
have
at
least
what
kind
of
the
hardware
we
use
for
the
implementing
and
this
starting
to
or
TRP
and
keep
on
top
of
the
existing
stack
for
we
need
Jason's
back
HTTP
stack
encrypted
stack
for
tears
and
jw8
data.
Where
is
working
and
we
need
to
see
board
to
and
why
I'm
writing
here
is
because
the
on
Saturday,
almost
at
the
end
of
the
Saturday
I
was
I
was
finished.
I
was
to
debug
the
OTR
P
packet
on
HTTP
I
end
up
debugging.
C
C
So
this
is
my
now
I
have
no
I,
have
no
preference
I
just
list
it
up
what
what
my
mean
need
to
be
considered
and
keep
working
group
so
refreshed
time
machine?
What
is
it?
Okay,
just
you
use
a
PC
in
your
harder
hardware.
We
would
like
to
have
other
than
the
time
I
really
don't
know,
and
the
reference
steep
device
deep
device
in
in
the
many
different
area.
It's
called
IOT
device
for
each
device
or
whatever
it
is
from
your
background
and
sin
and
for
the
arm
property
of
the
usable
devices
properties.
C
The
easiest
but
I,
don't
know
it.
Raspberry
Pi
is
the
right
one
or
anything
and
Intel
device
SDX
usable
device.
Yes,
and
it
would
be
nice
if
it's
there's
something
other
than
laptop
PC
and
risk
v
is
there's
only
one
board
exists
at
the
moment
and
that's
already
have
a
PNP
X
station,
which
is
kind
of
similar
to
on
process
zone,
but
different
way
of
implementing
and
and.
D
Unless
they
have
a
question,
yeah
I
I
think
that's
a
good
question.
Also
in
light
of
the
hackathon
in
in
February,
I
looked
at
some
of
their
devices,
and
maybe
they
will
have
some
photo
recommendations,
but
a
device
that
I
recently
looked
at,
which
I
thought
was
really
cool
that
we
could
make
use
of
for
future
for
future
events
and
people
who
want
to
play
around
with
this
stuff
is
it's
a
device
recently
released
by
STMicroelectronics
called
stm32.
D
E
Take
ever
since
harness
basically
asked
me
to
make
some
recommendation
the
other
device
that
we
use
for
testing,
that
I
would
recommend,
as
probably
more
security
features
in
the
raspberry
pi
3
is
also
a
cortex
a53
and
so
NXP
there's
a
board
from
scaleless.
It's
called
the
great
board.
That
is
what
is
used
in
a
commercial
product
called
the
trust
box
from
scaleless,
and
that's
the
one
that
got
like
the
CES
cybersecurity
Innovation
Award
this
last
year,
and
so
that's
another
one
that
actually
has
a
box.
E
C
C
Otherwise,
putting
on
the
HTTP
taxation
stack
and
crypto
stack
will
be
depend
on
the
root
of
s
and
there's
so
many
selection
on
the
crypto
library,
open,
SSL,
the
bare
SSL
organizational
and
bacterias
offices
and
s2
in
and
open
SSL
variant.
It
tends
to
be
very
large
for
the
cheap
device.
So
probably
we
need
something
think
about
something
smaller
stack
and
we
also
need
a
seaport
parser.
We
need
somebody
to
do
the
C
or
parser
here
and
I'm.
C
Not
sure
this
is
the
scope
of
the
tip
working
good,
but
something
came
up
during
the
hackathon.
Is
yes,
if
having
a
test
fit
on
the
Internet,
so
I
have
a
time
and
everybody
able
to
talk
on
the
time
with
a
deep
device.
Then
you
could
do
the
hacker,
a
hackathon
preparation
before
you
coming
at
the
table
and
the
IE
development.
C
So
the
te
program
and
the
T
and
the
previous
site
I
was
using
printf
so
think
of
debugging
is
at
the
moment,
is
the
most
used
way
on
the
trusted
application
devoting,
which
is
not
that
productive
and
so
yes,
opening
clave
is
IDE
development,
environment
and
yes,
I
haven't
tried
it
on
the
my
opti
device
so
and
in
the
future.
So
we
get
have
a
github
for
the
hosting
input
reference
implementation.
C
Then
the
person
who
doesn't
have
a
just
try
out
or
once
the
type
deep
dive
the
rscd
draft,
then
able
to
see
the
implementation
and
what
kind
also
the
DT
requires
the
hardware
support
so
tan,
sorry,
what
kind
of
hardware
we
might
might
good
to
have
or
antique
device
side?
What?
What?
Yes?
What
else
we
might
good
to
have
is
something.
A
F
A
C
A
E
Okay,
so
when
I
spend
some
time
going
through
the
issues
filed
against
the
architecture
documents,
I'm
I
go
through
almost
everything.
There's
a
couple
issues
that
I
think
are
just
editorial:
that
don't
need
discussion,
but
almost
everything
I'm
going
to
cover
three
I'm
gonna
cover
here
all
right,
so
I've
got
a
slide
or
two
on
every
issue
that
is
worth
discussing,
and
so
my
actually
back
up
for
a
second.
The
goal
is
to
try
to
have
the
editors,
have
an
idea
of
what
the
working
group
wants.
E
The
resolution
to
an
issue
to
be
such
that
if
the
text
isn't
there,
we
at
least
know
what
the
intent
is
and
we
can
go
and
author
that
in
the
next
Rev
such
that
the
next
Rev
of
the
document
should
ideally
cover
some
answer
to
every
issue
which
hopefully
reflects
working
consensus,
so
that
we
can
then
verify
whether
we
got
it
right.
Okay,
so
I
want
to
actually
have
enough
information
for
the
editors
to
know
what
to
do
with
each
issue.
Some
things
we
actually
have
proposed
text
for
a
lot
of
them.
E
We
don't
and
so
I'll
ask
the
questions
and
get
the
opinion
of
the
working
group
so
that
we
know
what
to
do
there
Thanks
all
right.
The
first
one
was
I
think
you
can
see
for
each
of
these.
They
have
the
github
issue
number
you
can
see
this
one
is
issue
number
69
separately.
It
was
also
part
of
issue
number
70,
Jurgen
Center,
a
review
to
the
list
that
included
a
bunch
of
things
from
editorial
knits
all
the
way
up
to
questions,
and
so
some
of
those
are
covering
other
slides.
E
You
see
number
70
number
of
times
in
these
okay,
so
69
is
the
one
that
pulls
out
specifically
this
question:
should
the
architecture
document
use
normative
language
current
status
is
that
the
draft
by
the
way
is
intended
says
of
informational,
but
it
does
use
terms
and
from
RFC
21
19.
Okay,
so
we
can
first
confirm.
Should
it
be
informational
or
stay
no
track
right?
My
understanding
from
what
the
chairs
believed
that
it
should
be
informational,
correct,
I,
think
our
Charter
milestone
actually
says
that
it's.
E
In
other
words,
those
are
conformance
things
that
an
implementer
writes
code
that
conforms
to
a
particular
must
should
or
may
or
is
it
for
our
spec
writers,
like
the
authors
of
the
tea
protocol,
spec,
okay
or
you
know,
if
spec
routers,
which
specs
and
so
a
proposal
for
your
feedback,
is
that
it
stays
informational
and
we
could
remove
the
2119
terms,
whether
you
like
that
proposal
or
not.
So
let's
look
at
some
examples.
E
This
is
not
the
complete
list,
but
the
point
is
the
spec
right
now
includes
some
uses
of
language
that
is
directed
at
spec
writers,
and
so
you
can
see
three
examples
there
I'm
talking
about
what
goes
in
and
it
says
ot
RP
protocol
right,
you'd.
Imagine
the
T
protocol,
here's
what
the
other
protocol
document
shall
do.
Okay.
E
These
are
examples
of
normative
language,
and
so
we
could
either
keep
this
language
or
we
could
just
not
use
2119
language,
since
you
could
say
the
same
thing
in
english
text
and
there's
also
other
statements
that
are
directed
at
implementers
like
the
examples
on
the
bottom.
Okay,
so,
for
example,
the
tam
should
use
a
crl
or
whatever
to
validate
certificates.
That
type
of
statement,
okay,
is
in
the
architecture
document
right
now.
Okay,
such
statements
could
be
moved
to
the
protocol
document.
E
If
we
think
there
needs
to
be
normative
text,
that's
there
and
those
in
theory
could
move
to
say
the
tea
protocol
spec,
okay.
So
the
question
here
is:
what
do
we
want
the
architecture
document
to
be?
You
should
have
any
of
these
uses
or
should
all
of
these
be
removed
in
terms
of
2119
language
and
just
have
informative
text?
Okay,
you
can
see
right
now,
as
an
editor.
E
E
D
Yeah
I
agree
with
you,
I
think
those
I
don't
know.
I,
don't
know
how
about
the
history
is
why
we
got
that
India,
but
it
feels
a
little
bit
of
a
for
an
architecture
document,
in
my
opinion,
so
I
think
there's
no
harm
in
in
change,
Cheney
to
lowercase
and
then
actually
revisiting
some
of
the
details
because
they
may
as
well
better
fit
into
the
protocol
document.
To
be
honest,
some.
E
Of
the
statements,
as
you
will
see,
actually
are
in
sections
that
might
be
removed
due
to
a
leader
issue,
because
the
architecture
document
was
written
prior
to
the
time
where
the
t
p--
working
group
decided
to
take
a
dependency
on
suit
for
manifest
stuff
and
on
rats
for
attestation
stuff.
You
can
see
some
of
these
normative
statements
or
an
attestation
stuff
that
might
actually
not
belong
in
the
document
anymore
or
depending.
So
that's
a
later
issue.
I'll
get
to
you,
okay,
so
don't
pay
too
much
attention.
E
The
actual
literal
examples
on
here,
but
there's
a
lot
more
than
just
these
five
on
the
screen
right
now,
all
right,
so
hearing
no
objections
to
that
proposed
I'm
going
to
go
on
and
well
again,
send
the
lists
and
stuff
to
the
list
in
case
those
objections
in
the
list.
Okay,
now
we
get
into
some
terminology
ones
and
most
the
terminology
ones
I
left
on
the
editorial
stuff,
but
the
first
two
I
think
are
really
about
scoping
and
so
I
call
these
out.
This
is
a
slightly
easier
one.
E
There's
three
issues
about
terminology
about
the
stuff:
that's
outside
the
t,
ee
and
the
problem
was
as
a
number
of
issues
got
filed.
Is
that
the
same
thing
it
had
multiple
terms
for
it
in
different
places.
In
the
document
things
like
some
places,
it
was
called
an
untrusted
application.
In
other
places
it
was
a
client
application,
but
they
both
meant
the
same
thing
or
what
you
call
the
richer:
the
operating
system
and
the
rich
execution
environment,
a
bunch
of
different
terms
that
all
meant
the
same
thing.
E
Okay,
and
so
here
you
can
see
in
there's
a
plural
quest
that
I
didn't
merge
because
I
wasn't
a
chair
before,
but
I
submitted
the
pull
request.
Sorry,
because
I
was
a
not
a
document
editor
before
now
that
I'm
a
document
editor
I,
am
free
to
merge
them,
but
the
tea
process
is
that
editors
merge
and
chairs
closed
the
github
issues.
Okay,
and
so
now
that
I
am
an
editor
and
not
a
chair.
That
means
I
can
now
merge,
but
not
close.
The
issues
where,
before
I
could
close
the
issues
when
that
merge.
E
Okay,
so
that's
how
it
works
in
tea,
okay,
so
the
term
between
client
application
and
untrusted
application
in
the
pull
request.
I
chose
untrusted
application,
which
avoids
confusion
with
cases
where
you
have
server.
Applications
like
I
have
an
HTTP
server
or
something
else
as
a
server
for
pick.
Your
favorite
protocol
and
the
term
client
could
be
confusing
because
it's
the
server
side
of
some
protocol
right
so
untrusted
application
was
unambiguous,
and
so
there
you
can
see
depending
on
the
context.
E
In
some
cases,
rich
execution
environment
makes
sense
and
in
other
cases,
the
file
where
I
don't
know
who
filed
this
one
suggested
commodity
operating
system,
and
so
I
took
that
in
one
of
the
case
in
one
of
the
cases
because
we're
it
was
talking
about
that
alright
I'm
gonna
go
on
since
that
one.
That
one
is
the
this
is
the
one
that's
actually
closer
to
a
scoping
question.
What's
the
definition
of
a
t'ee?
Okay,
that's
where
we
provision
t
e's
in
this
working
group
right.
This
is
the
te
provisioning
working
group
we
provision
te.
E
So
what's
it
te
so
previously,
what
do
you
have
in
the
document?
Is
that
quote
an
execution
environment
that
runs
alongside
but
as
isolated
from
an
ree?
The
filer
picked
on
the
word
isolated,
because
the
filer
I
don't
ever
follow.
That
said
well,
maybe
I
admit
to
them
that
they
couldn't
communicate
between
each
other,
but
here
they
can
so
they
suggest
that
maybe
separated
and
then
there's
a
bunch
of
other
discussions
in
issue
number
68
and
so
an
example
is.
E
Can
you
have
tes
that
don't
have
any
rich
execution
environment
on
the
same
device
right
Hannes
mention
an
ST
micro,
for
example,
an
MCU
class
thing?
Can
you
have
the
entire
thing
via
te
and
still
call
it
a
te?
Ok.
So
that's
what
I
have
on
the
next
slide
here
so
feel
free
to
get
up
to
the
mic,
but
wait
till
I
get
to
the
next
slide.
E
So
that's
one
definition,
that's
different
from
the
definition
up
there,
so
we
could
adopt
this
okay,
and
so
the
scoping
questions
are:
does
a
te
necessarily
have
to
have
an
ree
on
the
same
device
or
not
hey?
If
it's
not,
you
call
that
not
a
te
I
would
be
inclined
to
say.
Yes,
you
could
have
a
te
that
does
not
have
an
hour
EE
on
the
same
device.
E
There
was
some
discussion
in
the
issue
about
referencing
a
trusted,
OS
and
I.
Think
honest.
You
had
a
comment
or
something
about
that.
An
issue,
and
so
some
T's
have
a
trusted.
Os
like
trust
zone,
would
like
opti
as
an
example.
A
trusted
OS,
some
like
SGX,
do
not
have
a
trusted
OS.
So
as
long
as
you
believe
that
SGX
is
at
te,
then
it
does
not
have
to
have
a
trusted
OS.
Well,
even
in
my
definition
on
the
previous
one,
you
saw
hardware
enforcement.
E
So
the
scoping
question
is
well
what,
if
you
don't
have
hardware
enforcement?
What,
if
you
just
have
enforcement
by
say
a
hypervisor?
Do
you
call
that
a
te?
Can
you
use
the
t,
p--
protocol
to
provision
something
which
isn't
Hardware
back,
that
suddenly
say
hypervisor
pact?
What's
the
scope
of
the
architecture
right?
E
So
this
is
actually
a
more
a
more
central
question
right
and
so
I
went
back
to
the
teach
charter
to
say
how
does
the
T
charter
define
it
right
and
so
I
quoted
the
key
parts
of
the
cheap
charter
for
your
information
here
it
calls
a
te,
a
secure
area
of
a
processor
which,
while
that
definition
kind
of
implies
hardware,
but
is
that
what
we
want
talks
about
isolated
execution
in
integrity
and
confidentiality,
kind
of
overlap?
So
the
definition
of
the
previous
slide
and
then
talks
about
in
general
terms,
an
execution
space.
E
It
provides
a
higher
level
of
security
than
a
rich
operating
system
and
more
functionality
than
secure
list.
Those
are
kind
of
definitional
thoughts
and
there's
some
examples,
and
none
of
those
actually
specifically
answer
the
question
of
whether
hardware
based
stuff
inherent
to
the
definition
of
a
tae
other
than
maybe
the
secured
area
the
processor
could.
And
so
the
real
view
of
the
question
is,
and
we
want
the
architecture
document.
E
D
I
I
think
I
erased
the
issue
because,
obviously
we
want
to
be
inclusive
in
the
definition
and
people
don't
want
to
be.
We
can
have
examples
in
there
for
some
of
the
popular
things,
but
I
thought
it
would
be
important
specifically
for
the
types
of
attacks
we
want
to
make
the
reader
way
off
and
specifically
like
the
definition.
D
The
main
definition
already
includes
sort
of
the
distinction
between
this
one,
an
execution
environment
that
the
runs
alongside,
but
it's
isolated
from
the
re.
So
did
you
at
least
have
a
distinction
between
sort
of
the
the
normal
world
where
a
regular
operating
system
runs
and
and
the
de
part.
So
you
have
that
so
that
the
normal
word
callously
can't
access
the
de
site
memory.
D
Of
course,
their
difference
is
that
because
some
of
the
brick
and
some
of
the
DES
don't
provide
or
extend
the
protection
or
the
way
to
peripherals,
but
only
focus
on
memory,
that's
a
would
be
a
distinction
between
I'm,
Trustin
and
and
Intel
SGX.
However,
I
also
think
it's
important
to
highlight
that
we
specifically
with
the
dynamic
uploading
installation
and
management
of
trusted
applications.
D
We
also
want
to
make
sure
that
the
das
themself
are
isolated
from
each
other,
and
the
das
are
not
able
to
access
sort
of
memory
data
that
is
essentially
running
at
a
higher
privilege
level
like
if,
in
trust
zone
case,
it
can't
access
the
operator
operating
system
underneath
so
there's
additional
protection
capabilities
there
and
I
think
the
only
way
to
get
those
protection
capability
is
true.
Some
hardware
enforcement
that
I
consider
hypervisor
hypervisor
also
Hardware
enforcement
technique
because
they
are
ultimately
they
are
we're
mechanisms,
but-
and
that's
where
I
think
the
chart.
D
The
definition
for
is
a
little
bit
short.
He
talks
about
the
processor
in
specifically
in
a
te
con
and
I'm
trusts
on
context.
It's
it's
not
enough
to
just
look
at
the
single
processor.
You
actually
have
to
think
of
it
as
a
system
concept.
A
cooperation
between
software
and
hardware
extends
to
the
whole
thing
because,
as
you
make
memory
access,
you
need
to
be
aware
that
there's
a
bus-
and
there
are
different
peripherals
on
that
bus
and
I
thought.
D
The
peripherals
like
DMA
controller,
can
access
that
the
memory
regions
they
made
shows
PI
pass
all
these
things.
If
you're
not
super
careful
so
I,
maybe
that
goes
a
little
bit
too
far
for
this
type
of
document,
but
I
think
there's
also
for
the
readers
who
may
not
be
so
familiar
before
the
different,
fine
nuances
of
the
different
DS
they
they
probably
should
be
aware
of.
What's
going
on
terrifying.
E
Question
so,
first
of
all
wait
for
anybody
that
comes
to
the
mic.
If
you
can
say
whether
you
like
any
of
these
definitions
that
I've
shown
or
if
you
like,
none
of
the
above
or
something
else
but
you've
made
a
specific
point
about
isolation
between
TAS.
Do
you
believe
that
that
is
part
of
the
definition
of
at
EEE
such
that
something
that
doesn't
do?
E
F
E
D
I
just
want
to
sort
of
a
maybe
we
need
to
talk
about
this
aspect
a
little
bit
more
in
the
security
consideration
section
is
by
the
fact
that
we
provide
some
add
some
dynamic
nature
with
the
work
we
are
doing
with
this
dynamic
provisioning.
We
are
suddenly
also,
to
a
certain
extent,
creating
new
attack
possibilities
that
didn't
exist
previously,
where
everything
was
sort
of
nailed
down
and
static
in
terms
of
what
code
run
is
running
on
the
secure
and
so
I
think
we
have
to
take
that
into
account.
E
H
E
H
E
E
H
So
I
mean
I,
don't
think
I
like
any
of
your
definitions,
because
they're
starting
to
try
to
you,
know
they're,
saying
there's
something:
magic
are
special
about
the
security
of
what
you're
doing
and
I.
Don't
think
that
that
this
protocol
really
depends
on
any
of
that
I
would
I,
would
imagine
so
I.
Don't
think
it
matters
that
from
I
would
it
does
depend
on
the.
E
H
E
E
H
B
E
D
I
think
to
me
it
makes
a
lot
of
sense
to
provide
more
background
information
and
more
context
in
an
architecture
document
and
to
explain
a
little
bit
what
the
anticipated
deployment
environment
is
but
agree,
of
course,
at
the
protocol
level
itself,
you
know
like
you
could
run
it
locally
like
two
scripts
talking
to
each
other
and
using
the
protocol
a
day.
The
protocol
doesn't
wouldn't
care
much
but
I.
D
It's
not
just
fall
out
of
thin
air,
it's
the
same
as
with
at
the
station,
like
think
of
you,
could
think
of
the
at
the
station
working
as
a
JSON
document,
and
you
can
use
JSON
documents
in
all
sorts
of
contexts,
but
then
that
there's
this
whole
architecture
around
how
people
use
attestation
and
sort
of
like
what
systems
you
want
to
utilize.
If
it
is,
it's
obviously
more
complex.
H
Like
in
the
attestation,
I
mean
I've
been
arguing
all
along
in
attestation,
that
attestation
should
be
able
to
run
in
an
unsecured,
android
app
or
it
should
be
running
in
the
secure
element
and-
and
we
don't
we
all
of
those
are
in
scope
and
we
in
attestation
we
don't
care,
we
were
just
defining
a
protocol.
That's
you
do
what
you
want
right
so
so
to
me
it
would
be
the
t.
P--
Chartres
is
narrower.
H
So
I'm
gonna
end
there
with
one
more
comment
and
that
is
in
in
phyto,
we
defined
what
it
was
called:
an
ro,
a
restricted
operating
environment
as
a
sort
of
a
broader
thing
that
covers
tes
and
sgx
and
VBS,
and
somebody
that
just
saw
there's
a
really
nice
CPU
somewhere
on
the
board.
That's
got
its
isolated
or
something
like
that.
So
we
used,
we
just
use
the
term
ROA
instead
of
thought,
EE,
sure,
yeah,
there's
a
nice
document
and
all
that
normative.
E
Ben
will
you
in
line
okay,
so
one
of
the
things
that
I've
heard
so
far
is
that
there's
some
discussion
that
belongs
in
the
security
consideration
section
and
I,
don't
know
if
it's
in
there
or
not,
that
Hannes
was
summarizing
right,
some
expectations
around
tes
and
discussion
of
isolation
and
things
like
that.
That
would
make
sense
to
have
some
place.
If
that's
not
part
of
the
definition,
then
we
still
need
to
cover
the
definition
and,
as
I
mentioned,
there
are
two
problems
that
people
race
with
the
original
definition
in
the
document
and
so
I
guess.
E
My
question
is:
if
there's
appropriate
text
that
gets
put
in
security
considerations
and
elsewhere,
then
are
there
any
objections
to
the
definition
on
the
bottom
of
the
slide,
with
appropriate
other
text
that
goes
elsewhere
about
the
different
constraints
and
different
variations
of
tes?
Are
there
any
objections
to
having
the
text
on
the
bottom,
be
the
definition
of
a
te
that
this
working
group
uses
as
the
definition
of
all
te
es
or
all
things
that
we're
talking
about
is
te
would
fit
this
and
there's
various
variations
among
them?
E
E
I
I'm,
sorry
to
interject
here,
Dave
Gary
Monday
I'm,
Qualcomm
I'm,
when
I
was
looking
through
this
document,
while
revising
the
security
consideration.
Section
I
had
a
lot
of
trouble
here
from
trying
to
figure
out
what
how
ta,
ta
isolation
is
handled
in
this
document.
Nice
in
this
definition,
really
muddy
muddy.
Is
it
for
me
because
it
does
it
I
mean
because
you're
you're,
basically
saying
that
only
authorized
Q
can
execute
within
the
te
day
used
by
that
code
can
be
read
or
tampered
with
my
coat
outside
of
the
TE.
I
E
I
E
I
I
realized
I
phrased
my
question
wrong
because
it
if
it
only
has
one
security
domain,
it
probably
is
not
a
te
a
better
way
to
phrase.
The
question
is
the
concept
of
a
security
domain
which
has
covered
a
different
issue.
I'll
have
a
later
slide
on.
Okay
is
where
you
have
multiple
TAS
in
a
secure
domain.
You
can
have
multiple
security
domains.
You
know
zero
on
device
right,
there's,
isolation
between
security
domains,
but
within
a
security
domain,
there's
not
isolation
between
TAS
and
so
just
saying.
Every
TA
is
isolated
from
every
other.
E
I
I
E
E
Remember.
The
architecture
document
was
previously
written
before
the
or
the
text.
That's
in
there
was
written
before
the
work
group
decided
to
take
a
dependency
on
the
suit
manifest.
So
there's
some
text
in
there
that's
obsolete
or
perhaps
needs
to
change
in
some
other
way,
and
so
here
are
three
related
issues:
13
34
or
35.
E
That
are
all
kind
of
about
how
you
deal
with
dependencies
either
on
TAS
say
you
know,
a
untrusted
application
depends
on
a
TA
or
a
TA
depends
on
something
like
this.
Ta
depends
on
that
TA
or
this
TA
depends
on
this
version
of
a
trusted
OS
or
this
version.
This
TA
depends
on
this
version
of
trusted
firmware
or
whatever
expressing
dependencies
in
general.
That's
what
these
three
issues
are
right.
The
bottom
one
is
dependencies
on
a
TA.
Other
ones
are
dependencies
from
a
TA.
E
Actually,
the
bottom
two
are
dependencies
on
TAS
and
the
top
one
is
dependencies
from
a
TA.
So
we
had
working
group
consensus
in
teep
to
use
the
suit
manifest
for
dependencies
from
TAS,
okay
suit.
Manifest
describes
all
the
TA
particular
TA
and
everything
it
depends
on.
Okay,
that's
separate
from
a
normal
client
or
sorry,
an
untrusted
application
manifest
it's
the
manifest
from
it
that
comes
from
or
maybe
is
used
with
your
favorite
app
store
or
whatever.
E
That's
not
the
suit
manifest,
that's
just
whatever
you're
already
using
in
your
app
store,
and
so
the
text
already
has.
The
draft
already
has
some
text
talking
about
the
untrusted
apps
manifest,
which
is
not
a
suit
manifest
rights,
whatever
manifest
is
they're
using
now
that
can
express
dependencies
on
TAS,
but
all
the
other
issues
are
about
expressing
dependencies
from
TAS.
E
Okay,
so
I
generated
a
pull
request
with
a
strawman,
and
the
summary
of
that
is
to
add
a
reference
to
the
suit
manifest
as
it's
now
a
in
the
references
section
and
explain
that
the
suit
manifest
is
what
expresses
dependencies
from
TA.
So
everything
at
EA
depends
on
whether
it's
other
TA,
whether
it's
in
a
trusted
LS
inversion,
whether
its
firmware
inversion
whatever
it
is.
That's
the
job
of
the
suit
manifest
to
say
what
the
dependencies
from
this
ta
is.
E
Okay,
now
some
of
those
issues
up
top
I
think
at
least
two
people
eric
nerd
mark
was
one
of
them
either
one
was
that
talked
about.
Well,
what
happens
if
I
Rev
something
the
that
wear?
Something
else
depends
on
it,
then
that
could
be
at
competish
use
right.
So
if
I
Rev
a
TA,
you
could
maybe
break
an
untrusted
application.
E
If
I
Rev
trusted
firmware,
it
could
break
a
ta.
If
I
rev
one
ta,
it
may
break
another
ta
that
depends
on
it,
okay,
and
so
we
would
add
a
discussion
that
says:
there's
compatibility
issues
and
in
your
implantation
need
to
be
aware
of
that,
doesn't
say
exactly
how
to
just
says
there
is
a
section
here
you
could
do
that
by
just
allowing
changes
or
whatever
it
is
right.
Okay,
so
here
is
actual
text
from
the
per
request.
That
I
will
let
you
stare
at
for
a
second
in
case.
E
Somebody
wants
to
pick
on
a
particular
wording
now,
but
the
intent
was
the
bullets
on
the
bottom
to
the
two
bullets
on
the
bottom
of
the
previous
slide.
This
is
my
intent
or
my
text
that
would
potentially
capture
that
the
dot-dot-dot
in
the
middle
means
later
slide
inserts
text
in
the
middle
of
those
two
paragraphs
for
a
different
issue.
E
Leave
that
up
there
for
a
second,
so
you
can
all
stare
at
it.
It's
been
up
there
on
github,
but
I'm
not
going
to
assume
that
anybody
here
has
read
the
github
for
requests.
So
this
is
your
chance
to
pick
on
stuff
a
lot
of
the
text
previously
that
talked
about
dependencies.
He
is
then
replaced
by
this
text
because
we're
basically
saying
the
teep
is
not
going
to
solve
this
problem
that
suits
job
and
so
there's
less
than
we
have
to
say.
We
incorporate
by
reference
using
the
suit
manifest.
Okay,
there's
no
objections.
E
E
Although
some
of
the
discussion
in
the
issue
was
that
maybe
we
didn't
mean
full
after
all,
but
still
we
had
working
group
consensus
to
remove
security
domain
as
a
formal
concept,
but
we
still
realize
that
some
tea
we'll
have
security
domains
in
them
like
secure
elements
or
things
our
global
platform
compliant.
But
it's
not
a
formal
concept
in
here.
It
may
be
a
side
effect
or
things
you
deal
with
an
implementation,
but
it
wasn't
something
you
explicitly
called
out
as
an
element
in
the
protocol
per
se.
E
So
here
is
the
hole
request
that
would
propose
to
do
what
issue
number
62
s
discussion
was
from
previous
IES.
This
is
my
greeting
of
what
we
discussed
and
how
I
might
attempt
to
accomplish
that
as
an
editor.
So
there's
two
different
pull
requests,
number
72
and
then
part
of
75.
Okay,
there's
discussions
in
API
names
like
create
security
domain
was
a
specific
API
name.
We
said
well
we're
gonna,
remove
that
remove
the
OTR
P
message
name,
especially
since
we're
moving
from
the
ot
out
here.
E
Ip
protocol
to
the
T
protocol
so
and
I've
talked
about
the
auto
key
message.
Names
like
create
security
domain,
remove
the
explicit
entry
of
security
domains
from
the
terminology
section,
which
makes
it
sound
like
there's.
A
formal
concept
depend
on
these.
This
is
the
main
point
how
it's
related
to
suit,
which
is,
if
there's
a
dependency
on
something
as
part
of
the
install
steps
in
order
to
install
this
ta
I
have
to
create
a
security
domain
and
then
I
can
install
the
ta
okay.
E
You
can
express
that
in
the
suit
manifest
in
the
suit
manifest
you
say:
here's
a
set
of
install
steps.
You
can
have
an
install
step
in
the
manifest
that
says,
create
security
domain
or
something
has
that
is
in
effect
right.
This
is
a
way
of
saying
we
can
accomplish
the
create
security
domain
inside
the
suit
manifest.
E
As
long
as
the
suit
working
group
accepts
this
as
a
requirement
and
has
a
way
to
solve
it,
okay,
which
we
will
potentially
talk
about
in
the
suit
working
group
meeting,
which
is
just
after
lunch,
but
les
point
here
still
include
the
security
domain
informatively
in
example,
text,
and
so
the
so
like
Ning,
for
example,
felt
strongly
about
this
one,
which
is,
we
still
need
to
explain
what
it
means
in
a
global
platform
environment
for
a
te
that
has
this
concept
of
security
domains.
What
does
it
mean
right
so
at
least
use
an
example?
E
Okay,
so
here
is
an
example,
and
this
was
that
dot
dot
dot.
That
was
on
my
previous
slide.
So
the
first
paragraph
is
the
one
that
you
saw
on
the
previous
one,
and
the
bold
is
the
new
one.
It's
inserted
in
that
dot,
and
so
you
can
see,
for
example,
this
is
clearly
informative
texts
and
it
talks
about
t's
compliant
with
global
platform
may
have
a
notion
of
a
security
to
me,
and
here
you
can
see
not
in
the
terminology
section.
E
E
Does
but
it's
not
the
same
one
as
global
platform,
but
yes,
that
is
a
good
point
which
is
potentially
another
reason
to
define
it
in
line
down
here
in
the
context
of
Google
platform,
and
that
is
some
formal
concepts.
Ok,
so
I
believe
that
this
paragraph
here
would
address.
If
Ming
was
here,
I
don't
know,
if
he's
actually
a
remote.
J
Ok
I.
Thank
you
for
anything
there.
Yes,
it
is
to
have
a
long
Easter
discussion
of
them
secured
to
me
whether
we
officially
remove
it
as
of
formal
concept
or
don't
support
it,
but
it
is
still
large
section
of
devices
there
which
will
your
mob
stick
it
to
me.
It's
a
reality
and
obviously
gives
us.
The
informal
text
to
you
for
those
of
the
users
will
give
us
some
of
this
class
here.
So
they
have
way
to
support
it.
That
was
a
wild
mustangs
right.
J
E
E
You
all
right,
because,
assuming
we
agree
with
these
principles,
then
I
have
something
like
10
minutes
or
whatever
in
the
suit
working
group.
Today
this
afternoon,
to
report
out
on
whatever
the
teep
working
group
decides
is
requirements
for
suit
I
have
a
spot
to
report
that
out
to
the
rest
of
the
to
suit
working
group.
I
know
some
of
you
are
in
this
room
right
now,
but
we
did
Dave
and
I
talked
about
that
on
the
agenda
today
so
or
yeah.
Okay.
E
E
Great
okay,
then
there
was
just
this
discussion
of
this
use
case.
That
says,
I
want
to
keep
secrets
from
the
Tam.
In
other
words,
I
am
a
SP
or
was
a
security
provider
that
has
applications
that
I
want
to
distribute,
but
I
don't
want
and
I
want
to
keep
them
in
secret.
You
know
the
code
for
them
could
be
encrypted
than
they
or
the
data
for
them
could
be
encrypted.
I,
don't
want
the
Tam
to
have
that
that
the
key
to
decrypt
it
okay,
so
I
just
want
to
use
the
Tam
as
intermediary.
E
This
is
a
discussion
we
had
previously,
that
being
how
I
see
is
that
the
Mike
again
was
leading
this
discussion
before,
and
so
this
is
summarizing.
What's
in
the
issue,
we
said
the
encrypted
binary
could
be
delivered
just
like
an
unencrypted
binary,
which
means
that
the
Tam
doesn't
have
the
key,
because
it
doesn't
really
know
where
it's
encrypted
or
not
just
a
file,
which
just
means
the
decryption
key
would
have
to
be
delivered
separately,
not
through
the
team,
because
the
Tam
doesn't
have
the
decryption
key.
E
And
so
then,
how
would
you
deliver
the
decryption
key
and
the
discussion
that
is
long
back
and
forth
from
different
people,
mostly
David
and
myself
and
Ming,
and
maybe
Hannes
in
this
issue?
You
could
get
it
through
teep
by
a
different
Tam
such
as
this
SP
running
their
own
Tam.
That's
just
for
purpose
of
handing
out
the
key.
That
was
one
proposal.
E
The
current
text
and
the
document
says
the
following,
though,
which
is
the
problem.
The
current
text
in
a
document
says
for
any
client
app.
This
is
the
untrusted
app
right.
There
should
only
be
a
single
Tam
to
contact
okay
and
then
the
SP
should
provide
the
Tam
with
all
the
t's,
the
D,
a
pre-chorus.
No,
as
the
the
the
implication
is
that
in
your
client
app
your
your
untrusted
app
manifest
you
say,
and
here's
the
here's,
the
TAS
and
here's
the
TAM
and
you're
going
to
get
all
the
th
from
the
same
time.
E
So
if
you
get
all
the
TAS
all
the
dependencies,
everything
in
that
it
depends
on
from
the
same
cam.
Well
now,
what
does
it
mean
when
you
have
when
I
get
the
binary
from
one
Tam
but
get
the
decryption
key
from
a
different
ham,
that
kind
of
contradicts,
and
so
the
current
text
rules
out
the
ability
to
do
that
particular
proposal?
So
what
do
we
do?
E
That's
what
this
issue
is:
okay,
there's
at
least
two
different
options
that
we
could
go
here
and
I'm
going
to
ask
me
to
jump
in
after
I
get
down
to
the
bottom
of
the
slide
here.
Option
number
one
is
what
is
closer
to
what
the
text
currently
says
in
the
document,
at
least
that
text
that
I
showed,
which
is
there's
a
single
Tam
for
the
TA
in
all
the
dependencies.
Okay,
what
that
really
means
is
that
the
Tam
for
every
dependency
is
assumed
to
be
the
same
as
the
depending
t8.
E
So
what
this
means
is
that
the
service
rudder,
then
by
it,
has
no
choice.
It
says
I
now
have
to
host
all
the
T's
that
depend
on
me
right,
because
I'm
only
going
to
give
out
the
decryption
key
from
me,
then
everything
depends
on
me
has
to
use
me
as
well.
Okay,
so
B
option
number
one
option.
Number
two
is
to
change.
E
That
text
say
that
to
imply
that
there
can
be
a
separate
tab
for
each
dependency,
and
so
the
information
about
each
Tam
comes
out
of
a
manifest
file,
which
is
how
you
the
dependency
information,
so
you'd
have
to
have
for
every
dependency.
What
the
potential
Tam
URI
is,
if
it's
different
from
the
main
one.
Okay
and
of
course,
if
a
TA
depends
on
another
ta,
the
other
ta
could
have
its
own
suit
manifest
file
for
that
matter.
E
A
E
J
You
know
you
to
room
meeting
right
into
a
meeting
without
quite
somebody
better.
They
saw
yes,
we
came
away
with
option
to
initialize
activity.
We
learn
some
most
on
option
ones
upon
them
together
later,
okay,
if
you
have
a
intrinsic
a
DSPs
yacht,
you
up
to
close
that
I,
don't
delegate
to
not
only
do
not
trust.
J
That
patient
we
came
with
that
is
that
you
know
I
was
said,
not
religious
at
a
single
warning.
Is
it
most
time
you
don't
have
too
many
TS
right?
It
depends
on
if
a
sacred
one-
and
you
can't
have
a
public
here-
you
download
from
some
public
one
more
shared
time
and
the
first
time
are
more
sensitive,
ta
UK,
the
from
a
speak.
I
know.
E
We
had
a
discussion
prior
to
the
discussion
of
having
encrypted
stuff.
We
just
said
what
do
we
do
with
dependencies
and
for
that?
That's
where
some
of
the
text
and
document
came
from
it
says
when
you
just
have
dependencies.
We
said
it
would
be
a
lot
simpler
if
you
just
get
from
the
same
one
right.
This
notion
of
how
do
I
get
a
decryption
key
came
after
that
and
said
well
that
causes
problems
with
the
previous
assumption
and
that's
where
we
got
to
the
current
state.
That's
right
because
that's.
J
E
J
E
D
And
it's
honest:
I
tried
to
put
some
text
in
in
the
issue
and
I
hope.
I
ultimately
did
based
on
a
discussion
there.
The
problem
was
a
little
bit
that,
on
one
hand,
you
have
the
Pam,
you
rely
on
it
for
distributing
the
trusted
application,
but
then
you
actually
don't
trust
it
entirely,
and
so
you
have
some
other
party
behind
it.
D
Who
provides
the
trusted
application,
the
service
provider
and
the
question
was
like:
what's
the
interaction
because
there
has
to
be
a
key,
as
you
said,
like
distribution
there,
when
you
send
the
encrypted
trusted
application
and
and
associated
metadata
through
that
them,
and
how
does
that
work?
And
how
does
that
fit
into
the
architecture?
Because
that
entity
is
actually
the
entity,
then
behind
the
dam,
the
service
provider
is
not
really
there's
no
protocol
interaction
and
so
the
conclusion
there
at
least
from
what
I
recall
was
like
okay.
D
And,
of
course,
from
a
communication
protocol
point
of
view,
there
is
to
me,
which
is
not
yet
covered
in
in
sort
of
the
solution.
Work
is
like:
how
does
the
message
interaction
really
work?
Do
you
talk
to
it
to
one
time
and
then
relay
it
the
messages?
What
do
you
actually
talk
to
different
dams?
Then
item
Utley,
which
of
course
would
be
simpler.
I
would.
E
Say
the
latter,
although
you're
correct
that
there's
no
text
yeah,
so
what
I've
heard
so
far
seems
to
imply
that
as
a
working
group,
we
want
to
go
with
option
two.
If
we
can
find
the
right
text,
there's
no
quest
on
this
right
now,
that's
just
an
open
issue.
Right,
I
think
option
number
one
came
from
the
discussion
that
we
had
with
David
wheeler
who's,
not
here
right
now,
but
is
there
anybody
that
is
here
virtually
remotely
or
present?
That
would
have
any
other
issues
with
going
in
direction
number
two.
E
E
E
E
Okay,
Ming
had
proposed
that
a
particular
ta
could
be
carried
by
multiple
tabs
and
an
example
is
if
I
have
a
particular
TA
and
I
distribute
it
in
and
I
distributed
along
with
all
right,
I
have
an
untrusted
application,
I
distribute
through
the
Google
Playstore
and
an
untrusted
application
I,
distributed
to
the
Apple
Store
and
an
untrusted
application
I
distributed
Microsoft
Store
and
they
can
all
run
on
the
same
hardware
whatever
and
so
I'm
going
to
use
the
same
ta.
But
all
three
DS
applications
depend
on
them.
E
If
the
primary
fails
to
respond,
that's
basically
means
okay,
and
so
that
seems
reasonable
to
me.
This
is
in
the
suit
section,
because
this
means
that
when
you
have,
if
you
have
a
TA
that
depends
on
another
TA,
then
you
need
says:
there's
a
manifest
requirement
for
expressing
multiple
URIs
for
where
or
where
that
particular
binary
could
be
found.
Not
just
a
single
you're
right
seems
reasonable
to
me
any
objections.
Otherwise
this
will
go
this.
E
A
E
A
E
Multiple
components
that
need
to
be
installed,
it
could
be
multiple
TAS
or
to
put
on
some
suit
terminology
here,
a
suit
manifest
can
express
dependencies
on
files.
Your
files
may
or
may
not
actually
need
binaries.
They
could
be
anything
okay.
So,
for
example,
you
could
have
a
binary
and
the
configuration
be
separate
IDs
in
a
suit
manifest.
E
They
could
also
be
bundled
together
and
say
those
are
in
the
same
file
or
whatever,
but
if
you
have
them
as
being
separate,
you
could
say
this
binary
depends
on
this
configuration
file
and
you
have
to
get
them
from
different
locations.
Okay,
and
so
this
is
extending,
says,
is
the
thing
that
you're,
depending
on
it's,
not
a
TA
per
se,
but
it
is
an
element
in
the
suit
manifest,
and
so,
if
the
way
that
you
got
the
key,
the
decryption
key
here
right,
those
decryption
key
is
is
deliberate
separately,
but
by
a
different
Tam.
E
E
E
You
are
eyes,
okay,
and
so
the
relationship
is,
if
you
have
one
thing
that
depends
on
another
thing
and
I'll
use
two
t8
here:
I
could
have
used
a
TA
and
say
opti
I
could
have
use
a
TA
and
trusted
firmware
if
I
have
two
things,
one
that
depends
on
the
other
and
let's
say
the
thing,
that's
being
dependent
on.
Let's
say
I'm
going
to
depend
on
a
particular
version
of
opti
okay
that
can
be
distributed
through
ATM.
Okay,
let's
say
that
version
of
op
T
is
accessible
via
three
tabs.
E
The
particular
ta
that
depends
on
that
I'm
trying
to
use
is
only
accessible
at
one
of
those
which
opti
Tim
am
I,
going
to
use.
Probably
the
one
I'm
already
talking
to
is
going
to
be
the
most
efficient
right,
and
so
that's
the
relationship
is
this
flexibility
of
having
multiple
says
if
I'm
already
picking
one
for
a
depending
thing
and
I
have
multiple
choices
for
the
thing
that
it's
depending
on,
then
it
gives
me
more
freedom
to
be
more
efficient
by
picking
the
one
I'm
already
talking
to
you.
E
A
E
Right
all
right,
so
next
topic
trust
anchor
storage.
The
original
issue
had
a
label
is
kind
of
a
misnomer
right.
It
was
originally
labeled,
as
should
the
trust,
I
care
format
be
specified
in
separate
draft.
If
you
read
the
issue
that
ought
now,
that's
not
what
it's
about
anymore,
it's
actually
about
specifying
the
requirements
for
how
you
protect
trust,
anchors,
okay,
section
five
point:
eight
of
the
t,
p--
architecture
Ernie,
says
to
protect
trust
anchors.
It
talks
about
them
talks
about
protecting
the
trust
anchors
inside
of
at
eee.
You
store
the
trust
anchors
inside
ite.
E
The
question
is:
what
do
you
want
to
do
in
the
t,
parka
tech
chure,
so
he
could
copy
the
definitions
from
the
suit
architecture,
given
that
we're,
depending
on
the
suit,
manifest
and
say
now,
the
text
is
the
same
text
in
both
documents.
We
could
say
this
document
uses
the
definitions
of
TR,
stanker
and
trust
anchor
store,
as
defined
in
suit
architecture,
and
not
copy
them
in
here.
Just
include
them
by
reference
and
say
as
defined
in
there
or
we
could
take
some
other
approach.
E
Would
you
say
yeah
Honus
said
not
at
the
mic:
he
prefers
number
two
I
don't
know.
If
anybody
else
has
a
preference,
oh
I
see
rust
back.
There
also
says
you
thumbs
up
on
number
two:
okay,
Dave
Walter
wire,
so
we
have
the
other
suit
chairs,
saying
a
thumbs
up
on
number
two:
okay,
that's
hopeful
direction
to
the
editors.
Thank
you.
E
Alright,
then,
there's
two
issues
that
are
related
because
I'm
gonna
show
them
both
in
the
same
table
there
on
part
of
their
little
bit
interrelated,
which
is
about
this
term
device.
Secure,
storage,
hey
so
figure.
Six
in
the
architecture
document
has
a
table
and
I'm
always
showing
or
summarizing
two
rows,
and
only
a
couple
columns
out
that
table
which
says:
here's
a
bunch
of
keys
and
certificates
and
here's
where
they
are,
and
here's
allottee,
okay
and
so
it
talks
about.
E
You
can
have
trusted
firmware
that
has
its
own
key
pair
and
certificate
and
can
have
a
te
that
has
its
own
key
pair
and
certificate.
And
what
the
document
says
right
now
is
the
trusted
firmware
is
key.
Pair
and
certificate
are
stored
in
what's
called
device,
secure
storage,
which
is
a
term
that's
never
defined,
and
a
te
has
stuff
that
stored
in
the
device
EE
and
it
says
the
cardinality,
the
device,
secure,
storage,
the
trusted
firmware
has
one
per
device
and
the
TE
used
to
say
one
per
device,
but
issue
number
30
was
pointing
out.
E
Well,
that's
not
correct,
because
the
document
already
talks
about
that
you
can
have
multiple
te
es
per
device,
and
so
it
doesn't
make
sense
to
have
things.
That's
one
per
device
when
you
have
multiple
per
device,
and
so
that's
changed
to
say
one
per
te.
That's
the
part!
That's
in
red
there
that
so
leaves
the
question
of
what
the
top
middle
box
should
say
about
device,
secure
storage.
So
the
filer
and
number
58
I
forget
who
filed
it
asked.
What
is
this
device?
Secure
storage?
E
D
I
was
wondering
whether
we
could
recycle
some
of
the
discussions
from
the
rats
group
here
who
talked
about
the
root
of
trust
and
in
some
sense
you
what
it
boils
down
to
in
practices.
Then
you
rely
on
some
sort
of
rom
code
or
a
code
that
can
be
then
made
sort
of
read-only
at
some
point
in
time
at
the
PIM
minimum.
E
Within
the
suit
working
group,
there
was
a
discussion
a
while
back
coming
more
than
a
year
ago
and
the
question
the
suit
working
group
was.
Should
we
roughly
paraphrase
how
the
question
was
asked
and
the
question
was
something
like:
should
we
use
the
term
root
of
trust,
or
should
we
use
the
term
trust
anchor
or
some
other
variation
of
that
question?
D
D
D
But
at
some
point
in
time
you
have
to
have
some
code
in
there
and
the
key
along
with
it.
That
cannot
be
changed
because
otherwise,
someone
with
someone
who
you
may
or
may
not
like,
will
change
the
code,
and
then
security
goes
out
of
the
window,
but
so
so,
in
that
sense,
their
secure
storage
then
refers
to
like
literally
rum
or
something
similar
like
coat.
D
F
F
D
E
I
Money,
I'm
Qualcomm,
if
looking
back
into
the
Common
Criteria
T
protection
profile,
they
do
the
way
they
define
trusted
storage
seems
to
include
not
just
ta
persistent
data,
but
also
the
trust
anchor
store.
I
guess.
Are
you
looking
at
device
secure
storage
to
be
a
superset
of
that
of
trusted
storage,
or
do
you
think
of
it
as
being
a
or
do
you
think
of
it
as
being
equivalent
in
the
te
context.
E
My
reading
of
the
table
since
I
wasn't
the
person
that
wrote.
It
is
a
subset
that
everything
in
the
table
is
a
trust.
Anchor
store.
Okay,
so
your
trusted
firmware
has
a
trust,
anchor
it's
store
for
the
trusted,
firmwares
key
or
a
certificate,
maybe
in
a
different
location,
than
a
different
component
like
the
TE.
So,
for
example,
I
have
a
device
that
has
I
have
a
laptop
that
has
both
SGX
and
a
TPM
in
it.
Okay
and
may
have
some
trusted
firmware
or
micro
code
or
whatever
in
the
processor.
H
My
comments
are
kind
of
in
line
with
what
I
was
saying
before.
Whenever
you
use
the
word
secure
or
trusted
you're
sort
of
trying
to
imply
something
as
absolute
and
I,
don't
think
of
anything
ever
is
so
you
have
to
say
secure
against
what
trusted
for
what
is
it
and
and
if
you're
storing
and
it's
also
matters
of
your
storing
material
that
has
to
be
immutable
or
versed
stuff
that
needs
to
be
secret.
So,
if
you're,
storing
a
public
key,
all
you
need,
is
you
immutability?
H
If
you're,
storing
a
secret
key,
you
need
secrecy
so
and
and
I
say
you
know,
think
about
attacks.
Okay,
ROM,
you
say:
wow,
that's
cool,
that's
wrong,
but
if
I
got
a
fib,
a
focused
ion
beam,
I
can
I
can
change
rom
all
right
people
do
that
right
and
depends
on
your
attacking
an
attacker.
Are
you?
What
are
you
protecting?
Are
you
protecting?
You
know
the
secret.
E
Of
the
device,
it
would
have
been
useful
for
me
to
copy
in
the
text.
That's
in
the
suit
manifest
it's
that
extra
sentence,
that's
the
requirements,
are
trust
anchor
store.
I
suspect
that
what
you're
talking
about
that
sentence
tries
to
address
whether
it's
sufficient
or
not.
It
would
be
a
question
to
you
and.
H
H
It
seems
like
all
you
can
do
in
a
protocol
document
certification
documents
different
than
a
protocol
document
is,
you
can
just
say:
secure.
Storage
is
a
place
that
is
kind
of
for
storing
things
like
this
and
how
secure
it
is
depends
on
certification
and
your
requirements,
and
that's
all
you
need
to
say,
I'm.
J
Yes,
two
comments
here.
First
of
all,
I
had
to
they
aren't.
You
know
a
background
of
this
right.
We
talked
about
the
last
sickest
are
just
is
referred
to
the
trust,
firmware
key
that
it
was
one
per
device.
They
will
have
a
separate
e
key
yeah
that
one's
a
Teague
he's
a
warm
party
and
I.
We
already.
Rather
you
have
come
here.
One
purty
thats
thought
he
would
do
not
measure
in
a
secure
storage,
so
their
compact
that
the
trust
for
my
kid
that
also
is
optional
with
a
mate,
is
and
not
a
mandatory.
J
And
they'd
write
data
for
the
trust
for
Wiki
original
motivation
was
that
it
will
be
in
hardware
for
device
right,
a
window
forsake
your
putti,
you
put
the
load
of
somewhere,
just
secretive
because,
with
general,
your
secret
storage
in
the
means
and
someone's
saying
incredibly
even
use
fusion
key
right.
I
wouldn't
come
out
to
the
device
manufacturer
so
that
it
was
of
a
general
meaning
of
the
time
and
it
is
entrusted
for
more
keys.
A
particular
application.
Applying
to
this
saucer
form
away
key.
E
A
E
D
Is
honest
I
like
what
Lauren
said,
because
indeed
the
terms
trusted
and
secure
have
different
meanings
to
different
people
and
may
vary
in
context
and
and
I?
Don't
think
this
text
was
meant
to
be
sort
of
overly
constraining
in
any
way,
but
so
what
I'm
suggesting
is
maybe
wish.
We
could
provide
some
examples
here
on
what
people
typically
do
it
today
they
may
do
it
differently
in
the
future,
but
I
think
that
already
gives
a
good
indication
to
the
read
on
like
what
are
the
different
sort
of
sort
of
cases.
Essentially.
J
Yeah
I
think
I,
agree.
I,
think
maybe
you
could
give
me
example.
I
know.
I
can
I
have
a
good
talk
with
a
few
people
on
this
one.
That
is,
if
how
much
time
we
talk
about
the
former
key
had
to
burn
there.
There
was
a
even
we
have
subparagraph
II
in
the
past.
How
to
do
that
and
as
for
the
arm
table,
has
done
as
a
follow-up
I
think
we
can
add
some
example
here.
What
that
missed?
Being
a
strict
definition,
looks
a
bit
tricky
here,
as
we
are
discussing
I.
A
H
Ahead
so
in
terms
of
defend
against
I
think
defend
against.
You
know
like
whether
it's
read
right
sign
with,
but
don't
give
me
the
key
decrypt.
That's
that
makes
sense
if
it's
defend
against
you
know
a
script
kiddie
or
a
guy
with
the
focused
ion
beam
or
a
buffer
overrun.
That
does
not
make
sense.
I
agree.
E
All
right
trust
anchor
update,
so
this
is
number
32
also
called
out
by
jörgen.
The
current
text
says
it's
out
of
scope
to
update
trust
anchors.
It's
out
of
scope
to
update.
You
know
the
key
that
the
set
of
certificates
that
you
will
consider
trusted
like
the
tam
certificate,
that
is
in
the
device.
The
device
is
difficult
and
says
that's
out
of
scope
and
that
a
device
manufacturer
is
expected
to
provide
its
trust,
anchors,
live
update
or
out
of
band
update
you
device
administrators.
E
So
right
now
it
says
you
don't
use
the
teak
protocol
or
ot
RP
to
update
trust
anchors
and
to
people
ask
well
t
p--
is
for
provisioning
te
ease
both
code
and
data,
you're,
storing
trust,
anchors
and
te.
Can't
you
use
t
protocol
to
update
them.
That's
basically
with
issues
asking
its.
The
proposal
is
to
allow
that,
but
not
mandate
it
okay.
E
So
here's
an
example,
a
sure
could
have
a
trust,
anchor
manager
ta
with
trust
anchors
in
the
configuration
ADA
for
that
ta,
showing
as
an
example,
here's
a
way
that
you
could
actually
use
the
T
protocol
to
do
you
don't
have
to
do
it.
This
way,
but
I'm
saying
it
would
be
applicable
if
you
chose
to
do
this,
especially
since
two
people
ask
isn't
that
what
T
protocol
is
supposed
to
your
teeth
is
supposed
to
be
doing,
is
managing
T
ease
and
provisioning
them.
E
B
E
To
explain
because
they're
not
actually
talking
about
the
same
thing:
okay,
so
yeah!
Let
me
go
back
here.
This
right
here,
I
said:
there's
only
a
subset
of
the
rows
and
the
only
a
subset
of
the
columns,
I'm
actually
jumping
over
to
calm
now
and
I'm.
Sorry
I
didn't
make
that
be
clear
before
I
understand
the
confusion.
Okay,
this
is
talking
about
you
have
the
de
and
you
have
it's.
The
te
has
the
key
pair
for
itself.
So
in
other
words,
you
have
and
private
Keeks
is
about
you,
okay,
so
it's
like
your
own
trust.
E
I!
Try
to
anchor
for
yourself
separately
from
that
you
have
the
set
of
say
public
keys
that
you
trust
okay,
but
you
know
the
private
key
for
that's
information
about
somebody
else.
This
is
about
updating
those.
The
public
keys
that
you
consider
trusted.
If
the
certificates
you
consider
trusted,
how
do
I
update
those,
because
that
is
mutable?
How
do
I
do
ownership
transfer
right?
How
do
I
say
your
new
Tam
key,
because
your
Tam
gets
revved
it's
certificate
and
here's
your
new
tan
certificate
can
I
update
that,
because
I
do
key
rollover.
E
B
D
Yeah,
along
the
same
lines
of
been
I,
think
there
would
be
probably
be
a
policy
question.
Here's
well
whether
you
are
able
until
how
to
do
that,
then
also
practically,
if
something
if
there
may
be
different
layers
of
keys
even
on
a
device
and
so
different
types
of
trust,
anchors
and
some
may
not
be
modifiable
or
updatable
in
yeah.
That's
just
a
deployment
strategy
and
preference,
and-
and
you
can't
have
the
protocol-
can
change
that,
but
having
the
possibility
to
update
them
and
make
sense
to
me
mean
I.
E
Right
yep
well,
I
would
be
allowed
where
previously
it
was
declared
to
be
out
of
scope,
as
opposed
to
you
know,
you
could
use
it
okay.
Moving
on.
We
may
add
to
this
based
on
discussions,
but
this
is
just
my
list
of
things
that
some
of
the
things
we've
talked
about
that
would
I.
Then
I
would
then
relay
to
suit
as
things
that
we
depend
on
that.
The
suit
manifest
may
or
may
not
already
provide,
and
so
to
say,
Haiti
would
be
making
use
the
following
things.
E
You
may
already
provide
them
if
so,
hey
Brennan
great,
tell
us
how
they're
already
there
or,
if
not,
consider
adding
it
alright.
Now,
when
we've
on
off
of
the
suit
related
ones
over
to
the
rats
related
ones.
Okay,
so
as
a
reminder,
the
teep
working
group
previously
has
had
consensus
to
say
rather
than
doing
attestation
in
the
t,
p--
protocol
RTP
working
group.
We
would
like
to
just
push
that
over
to
the
rats
working
group
and
not
have
to
compete
with
them,
but
just
use
the
be
a
consumer
of
their
technology.
E
F
Want
a
day
of
altameyer
I
just
wanted
to
mention:
you've
raised
a
few
issues
of
requirements
on
suit.
I
just
wanted
to
have
a
brief
conversation
today
about
how
we
might
capture
those
requirements
so
that
you
know
suits
not
gonna
work
on
the
manifest
forever.
We
need
to
make
sure
that,
as
we're
finishing
it
up,
we
have
addressed
everything
so
I'd
like
to
have
some
discussion
about
a
mechanism.
You
need
that
now
or
later
I'm
I'm
good,
either
way,
but
I
think
it's
worth
in.
F
A
F
E
So
I
would
take
this
slide
here
as
the
conveyance
mechanism
and
carry
this
into
the
suit
working
group
and
present
this
slide
as
being
asked
from
teep
to
say:
can
you
tell
us
whether
these
are
already
met
and
if
so,
please?
If
not,
please
consider
them,
and
so
this
is
the
equivalent
the
wiki
that
you're
asking
right,
but.
F
A
E
F
E
Some
point
previous
T
interim
meeting
that
was
in
the
first
half
of
this
year.
Sometime
Brendan
Brent
Brennan
gave
a
presentation
on
the
suit
manifest
the
teep
working
group
and
explained
yep
I,
think
everything's,
you
guys
are
doing,
could
be
used
to
the
suit
manifest
could
be
used
for
and
at
that
time,
other
thing
that
we
had
talked
about
as
a
requirement
he
thought
was
already
met.
A
E
E
E
K
E
Right
all
right:
here's
access
station
there's
at
least
three
issues
that
are
related
to
a
test
station
that
our
comments
on
the
attestation
text
in
the
document
and
now
that
we've
said
we're
not
going
to
do
a
test
a
ssin.
Hopefully
a
lot
of
this
is
can
be
addressed
by
removing
text
and
replacing
least
of
reference
to
rats
things,
and
so,
for
example,
17
is
about,
say,
is
about
this
notion
of
attestation
key
that
might
not
be
available
because
it
is
it
a
bunch
of
discretion.
On
attestation
keys,
31
is
talking
about
seeds
for
attestation.
E
The
attestation
hierarchy
says
I
wanted
details.
Why
the
hesitation
70
has
talking
about
the
text.
Has
the
tea
parka
texture
has
discussions
of
specific
crypto
algorithms
and
which
versions
of
which
crypto
algorithms
are
okay,
which
is
also
details
about
attestation
and
in
point
was
that
list
can
get
out
of
data
over
time?
And
maybe
the
informative
architecture
document
is
not
the
right
place
to
have
normative
requirements
around
crypto
algorithms?
That's
what
that
one
says.
So
all
this
is
about
problems
that
existing
text
with
the
agreement
that
the
tea
protocol
should
just
depend
on
stuff.
E
Coming
out
of
rats,
the
proposal
is
that
the
arc
doc
and
students
did
explain
the
relationship
between
t,
p--
and
attestation
reference
the
rats
architecture
and
we've
all
the
protocol
details
to
to
either
the
t
protocol
spec.
If
it's
a
tea
protocol
issue
or
to
arrest
thing,
if
it's
a
rats
issue
and
specifically
text,
it
would
be
removed,
it
would
be
information
talking
about
anything
being
signed
by
an
SS
station,
key
or
seating
of
attestation
keys
or
a
specific
crypto
algorithms
for
attestation.
All
that
text
would
just
go
away.
That's
the
proposal.
H
Lauren
slim
blade
co-author
of
the
document
in
rats,
so
on
the
the
first
of
the
the
the
keys
and
seating
and
all
that
that
makes
some
sense
to
me.
The
crypto
algorithms
I'm
think
we're
gonna.
Leave
that
a
lot
to
profile
documents
and
I,
don't
know
how
the
profile
documents
get
factored
like.
I,
don't
know.
H
If
the
rats
working
group,
what
profile
documents
the
rats
working
group
will
construct
and
I,
don't
know
whether
they
will
be
suitable
for
keep
and
probably
wouldn't
be
something
we
would
want
to
do
so
you
might
want
to
actually
have
a
profile
document
for
keep.
Yes,
you
write
our
charter
says
we
will.
E
I
To
the
Charter:
yes,
your
Manya
mall,
so
a
co-editor
of
the
rats
deliverable
the
MT
attestation.
Token
token
document
is
continuing
on
continue
on
with
the
you
know,
a
teep
specific
profile
for
attestation,
I
guess
one
of
the
things
I
struggle
with,
while
reviewing
while
reviewing
the
arc,
the
T
parka
texture
was
what
concepts
are
so
fundamental.
They
should
form
claim
profiles
within
the
eat
document
itself.
I
One
thing
and
when
one
thing
is
an
example
could
be,
for
instance,
identifiers
on
the
device
that
are
service
provider.
Specific
I.
Can
we
just
do?
Is
the
proper
way
forward
not
to
be
not
to
address,
keep
specific
aspects
of
attestation
within
the
rat's
working
group
and
have
it
be
addressed
all
within
that
t
profile,
including,
for
instance,
identifiers
that
could
be
customized
on
a
service
provider
basis,
rather
than
that
identifier?
Is
it
or
does
that
are
universal
across
the
device.
B
E
My
opinion,
I,
don't
know
what
other
editors
opinion
is.
Is
that
in
general
the
answer
I
would
say
is
yeah
all
the
details
should
be
in
a
teep
claims
profile
stuff.
There
may
be
cases
where,
if
there's
some
decision,
that's
made
within
rats
of
which
teep
is
a
user
of
you
might
want
to,
then
the
rat
should
be
free
to
say
an
example
of
something
would
use
this
as
the
t
p--
mechanism,
and
so
you
might
use
it
as
an
example.
B
I
think
I
have
a
similar
stance,
which
is
you
know
gary
in
lawrence.
You
should
not
feel
obligated
to
include
anything
too
specific
in
the
rats
working
group
documents.
I
mean
if
you
think
that
there's
something
that
we're
doing
that
has
a
more
general
utility
and
you
think
on
your
normal
criteria
for
including
widely
used
claims
or
whatnot
in
the
eat
document
by
all
means.
Do
that,
but
don't
feel
like
you're
obligated
to
have
anything
specifically
for
us
all.
E
Right
two
analogies
one
secure
domain
level
in
sweet,
manifest
industry
domain.
We
said
we're
gonna,
remove
it
from
any
formal
concept,
but
we're
gonna
still
reference
it.
By
way
of
example,
is
if
you
have
a
security
domain,
here's
how
you
can
use
our
stuff.
Okay,
that's
as
great
an
example.
What
was
other
example?
I
just
said
I
was
going
to
have
the
the
suit
manifest.
So
we
said
if
we
have
some
requirements
were
passing
a
suit
and
suit
put.
E
Some
of
those
rooms
has
a
way
to
meet
those
requirements
that
keep
is
currently
the
only
user
of
those.
Then
the
suit
manifest
should
be
able
to
say
an
example
of
a
reason
why
that
would
use
this
is
because
they're
going
to
be
used
by
the
t
protocol,
they
should
be
allowed
to
say
that
yeah
and
so
I'm
just
giving
you
the
same
answer.
I
would
use
if
Brennan
asked
me
the
same
question
for
the
super
manifest
we.
E
Next
one,
the
document
still
has
some
text
here
about
saying
that
the
TAM
needs
to
actually
validate
the
device
search
rights,
and
so
basically
the
device
cert
is
basically
the
SS
station
informations.
So
you
can
think
of
the
device
cert
here,
if
you're
a
rats
person
you
can
think
of
this
as
relying
party
validation
of
attestation
results.
That
would
be
my
generic
rats.
E
Phrasing
of
the
title
here,
okay-
and
so
the
document
currently
has
some
stuff
saying
you
know,
should
be
validated
by
at
am
with
you
know,
such-and-such
and
you're
gonna
ask:
why
is
that
I
should
be
validated
and
not
a
must
be
validated.
That's
his
question.
Okay,
so
it'd
be
like
saying:
if
the
document
in
a
rat's
document
said,
a
relying
party
should
validate
attestation
results
from
a
verifier
and
you're
going
to
ask:
why
is
that
should
or
not?
Must
that
would
be
an
equivalent
question?
E
This
is
just
the
tip
and
sensation,
so
we
could
remove
discussion
of
what
a
relying
party
does
and
just
sort
of
incorporate
that
by
reference
that,
when
rat
specifies
what
relying
parties
do
with
that
test
station
results
that
will
just
automatically
apply.
We
could
leave
the
shrewdest
as
is
but
elaborate
on.
Why
so
those
protects
would
be
similar,
but
we
just
answer
you're
against
questions
in
here
or
you
change
it
to
must:
okay,
benkei.
B
B
You
know
you
looking
at
the
sentence,
and
you
know
if
I
was
to
you
guys,
you're
here
or
something
on
it.
I
would
say.
The
intent
of
this
is
probably
that
you
have
to
do
any
revocation
checking
that
your
eco
system
requires
CRLs
and
OCSP
are
like
the
common
ways
to
do
that.
So
we
say
you
should
do
those,
but
if
you
have
some
other
way
of
checking,
revocation
information-
or
you
know
that
there
will
no
be-
there-
will
never
be
any
replication
information
in
your
particular
deployment.
B
E
J
Yes,
I
also,
second,
a
number
to
answer
that
most
upon
my
origin
of
text.
Here,
yes,
first
one
for
first
margin.
No,
that
addressed
right.
It
will
be
limited
by
that.
All
the
time
seen
a
server
site,
but
it
is
to
my
certificate
check,
is
just
standing
away
right,
license
standard
way
to
chicken
over
vacation.
I
would
like
to
leave
it.
There
just
explain
the
shirt
part.
E
H
Not
sure
I
would
line
up
with
any
of
those
options,
or
maybe
it's
one.
This
well
you're
presuming
x.509
certificate
chains.
Here
we
are
not
presuming
that
in
e
Arats,
and
this
has
a
lot
to
do
with
the
manufacturing
and
other
issues
of
putting
attestation
keys
into
chips
and
devices,
which
is
not
a
straightforward
thing
at
all.
So
the
expectation
is
that
some,
some
people
might
even
put
symmetric
keys
in
and
have
some
sort
of
a
web
service
that
that
you
submit
to
the
chip.
Bender
and
they'll.
H
Tell
you
with
something
as
valid
or
not
so
it
seems
like
you
have
to
leave
a
big
open
space
there
for
how
that
kind
of
validation
is
going
to
happen,
and
maybe
it's
URLs
may
be
weak
or
maybe
we
you
know
reinvent
and
and
it's
all
seal
or
base
certificates
and
stick.
We
call
them
something
else.
I
mean
it
seems
like
there's
a
whole
range
of
stuff
here,
so
I'm
not
sure
which
option
I'm
picking,
but
that's
the.
E
Comment
you're
making
me
realize
that
the
text
that
I'm
pulling
from
here
I
think
this
is
partly
what
Ben
was
saying
is
that
some
of
the
text
here
can
apply
independent
of
attestation.
It's
just
whatever
are
the
certificates
that
the
tea
protocol
is
using
for
its
own
authentication
or
encryption
or
whatever,
which
might
be
separate
from
the
attestation
part,
but
for
the
SS
station.
I
get
your
point.
If
t
p--
is
using
x.509.
K
E
D
The
son
is
yeah
I,
think
that
was
very
good
input,
so
I.
It
seems
that
we
have
to
revisit
this
section
or
this
paragraph
altogether,
because
I
when
Ben
came
to
the
mic,
this
the
shoot
was
exactly
there
because
of
those
the
qualifications
of
the
CLS
and
o'seas
OCSP,
but
indeed
this
we
switched
over
to
to
use
some
of
those
other
techniques
like
the
cozy
and
and
Jose
stuff.
D
We
should
also
think
about
whether
we
really
rely
only
on
x.509
certificates
and
specifically
also
keep
in
mind
now
that
we
untangle
sort
of
the
attestation
work
from
the
use
of
potentially
a
different
key
for
the
protocol
messages.
I
think
that
needs
to
be
brought
out
a
little
bit
more
clearly
and
they
may
they
may
not
even
be
the
same
types
of
key.
You
may
use
x.509
certificate
for
one
versus
sort
of
a
something
else
in
the
other
fly
cairo
public
use
it
so.
E
I'm
gonna
based
on
Russ,
is
coming
I'm
gonna,
add
a
number
four
there
and
see
what
people
think
number
four
would
be
to
move
the
discussion
to
the
tea
protocol
spec
and
keep
it
out
of
the
architecture.
Document
I
saw
two
thumbs
up
from
Russ,
because
this
is
the
point
about.
If
we're
not
going
to
use,
the
normative
must
should
maze
in
here.
Does
it
make
sense
for
these
to
use
motion
as
if
so
the
tea
protocol
aspect
is
a
better
place
for
that,
and
so
everything
we
just
said
would
still
apply.
E
But
I
can
finish
the
right
section,
yeah
all
right.
This
is
the
rats
profile
point
that
Lauren
brought
up.
There
is
no
issue
in
github
yeah.
This
is
the
only
slide
that
I
have
that
no
github
issue
was
filed
yet
and
there's
none
that's
filed
yet
because
it
wasn't
obvious
before
and
that's
part
of
the
question
here
is:
is
there
any
change?
As
what
document
would
you
file
it
against,
or
is
it
just
in
an
in
a
new
document?
E
So
here
the
question
is
whether
and
to
what
extent,
the
architecture
document
should
talk
about
this
concept.
Okay,
so
to
you
that
if
you
are
new
to
the
rat's
discussion
here
in
order
to
use
rats
work,
you
need
a
list
of
what
claims
that
a
tam
is
expecting
to
come
in.
Now.
If
you
look
in
the
OT
R
P
protocol
spec,
where
it
does
add
that
station
itself
you'll
find
a
bunch
of
specific
elements,
that's
in
there
that
could
be
used
to
help
generate
that
list.
That's
in
a
protocol
spec,
not
an
architecture
document
right.
E
B
E
New
doc,
or
is
it
in
the
protocol
spec
there's
only
difference
between
two
and
three.
My
preference
would
be
three
okay.
So
unless
do
you
want
to
get
an
object
number
three?
Then
the
list
goes
in
here
and
then
the
bullet
underneath
three
that's
implied,
is:
should
the
architecture
document
then
mention
its
existence
or
should
the
architecture
document
continue
to
remain
silent
on
this
topic?
E
J
Your
on
me,
yeah,
yeah
yeah.
Well,
actually
my
points
are
omission.
It
even
separate
document
we
need
to
make
it
right
understand
that
then
options.
Three,
you
put
releasing
a
new
tip
document
that
are
specifies
us
profiles,
but
I
click
told
me
she'd
point
it
because
agitation
is
a
part
of
it
and
she'd
point
to
that.
J
E
And
there's
not
a
document
to
reference,
yet
is
the
only
problem
number
three:
if
we
wanted
a
reference,
it
okay,
you
could
say
left
for
future
work
and
it's
because
my
intentions
between
now
and
December,
we
will
have
an
editor's
copy
and
then
generate
a
new
submission
of
the
internet
draft
and
then
the
church
can
then
decide
whether
to
put
that
to
work
in
your
class
call.
It
follow
some
other
process,
but
we
want
to
have
a
new
document
before
December
mean.
E
E
J
B
A
E
E
A
A
E
And
see
where
we're
at
okay,
okay,
okay
issue
number
11
was
having
a
common
way
to
coordinate
between
the
transport
spec
and
the
protocol
spec
such
that
the
transport
specs
names
for
events
that
get
passed
between
those
two
things
has
a
common
name.
So
when
you
do
it
the
two
specs,
you
know
this
one
signals
the
BLA
event
and
every
one
was
when
the
BLA
event
is
signaled.
E
Something
happens
that
you
have
a
common
name
for
handoff
between
the
two
specs
in
this
working
group,
and
so
we
did
that
that
there
is
this
notion
of
conceptual
API.
So,
like
a
name
for
an
event,
if
you
will
and
so
right
now,
the
list
is
in
the
github
issue:
pull
request
74,
so
the
github
issue,
number
11,
the
per
request
74
and
in
the
transport
spec,
but
not
in
the
protocol,
spec
other
than
the
OTR
PE
spec
had
one
of
them,
but
not
in
the
T
protocol.
Spec
right,
that's
a
separate
issue
here.
E
So
here
was
for
labels
for
events
instead
of
process.
Okay,
P
message:
you
can
see
it's
processed
teep
message
that
was
recently
changed,
and
so
this
is
saying
here's
a
pull
request
that
just
explicitly
list
these
in
its
discussion
about
how
brokerage
were
that
says,
here's
a
couple
of
events
that
kind
of
happen-
and
these
are
used
to
refer
together
between
the
T
Protocol
spec
and
the
T
over
HTTP
spec
uses
these
events
as
the
interface
between
those.
This
is
just
abstract.
E
F
E
Use
of
IOT
DDoS
draft
issues
there
was
his
presentation
is
about
things
like
that:
Moriah
botnet
would
infect
IOT
devices
and
his
question
was:
can
t
poor,
the
working
group
or
whatever
it
be
used
to
help
prevent
those
DDoS
attacks?
These
DDoS
attacks
are
really
about
getting
mail
were
on
to
the
rich
execution
execution
environment
of
the
device,
not
the
te
of
the
device
least,
the
ones
that
are
discussed
there,
and
so
since
we
did
not
have
time
for
that
discussion
last
time.
A
E
A
A
Okay,
we
can
start,
if
he's
on,
will
we'll
kick
it
off?
If
not?
Okay,
we
can
defer
okay.
So
with
that
we
will
reconvene
again
tomorrow
and
on
the
agenda,
we
will
go
through
the
Ohana's
left.
The
the
proposed
so
I'll
ask
the
question
tomorrow.
So
Hannes
we'll
go
through
what
we
hope
to
be
the
next,
not
next,
but
the
new
proposed
deep
protocol
that'll
be
the
focus
for
tomorrow
and
a
couple
of
announcements
as
well
as
updates
from
the
transport
protocol
by
Dave.
So
with
that
I'll,
let
you
guys
go
I'll,
see
you
tomorrow.