►
From YouTube: IETF102-TEEP-20180717-1330
Description
TEEP meeting session at IETF102
2018/07/17 1330
https://datatracker.ietf.org/meeting/102/proceedings/
A
A
The
blue
sheets
should
be
going
around
by
now.
I
know,
on
my
left
hand,
side
they
should
be
halfway
through,
if
not
already,
but
just
make
sure
you
you
sign
the
blue
sheets,
so
in
advance.
I
will
thank
Roman
for
being
an
ether
pad
and
Mike
for
being
one
of
the
note
takers,
I
would
like
to
have
one
other
note
taker
and
a
jabber
scribe.
We
we
actually
need
a
jabber
scribe.
So
could
we
get
a
volunteer
or
two?
Please
jabber,
scribe.
A
C
A
That's
my
band,
you
can
see
my
cut
and
paste
doesn't
always
work.
But
yes,
this
is
the
ietf
102.
So
please
make
sure
we
note
that
down.
Okay,
so
let's
bash
the
agenda
so
for
today
the
authors
have
updated.
So
at
the
last
face-to-face
meeting
we
agreed
that
we
needed
to
have
a
working
group
architecture
draft.
So
thanks
to
the
authors,
there's
there's
a
draft.
That's
been
posted
for
a
week
now,
so
Hannes
and
Ming
will
provide
the
overview
for
that.
There
has
already
been
some
comments
which
there'll
be
discussions.
A
There's
also
been
an
update
to
the
ot
RP
solution.
Draft
again
comments,
but
there'll
be
a
presentation
for
that.
We
actually
had
one
person
and
that's
my
co-chair,
who
will
be
presenting
his
report
thereafter
and
then,
given
some
of
the
comments
and
feedback,
we
think
it
would
be
a
good
idea
and
they've
volunteered
to
provide
not
really
a
SGX
overview,
but
rather
in
the
context
of
teep
how
SGX
would
fit
and
some
of
the
things
that
we'll
need
to
work
through.
So
that
really
takes
us
to
the
end.
A
We
have
a
full
agenda,
so
I
will,
while
I
put
30
minutes
in
there,
depending
how
the
Q&A
goes
and
and
the
presenters
I
may
reserve
the
last
five
minutes
for
QA.
So
it
may
be
that
you
only
get
25
minutes
and
then
we'll
go
from
there.
So
that's
what
we
have
on
the
agenda
today.
Any
objections,
any
other
comments
going
once
going
twice:
cool.
Okay.
So
let's
go
ahead
and
get
started
with
the
review
of
the
milestone.
So
at
the
last
face-to-face
we
had
put
the
tentative.
A
C
The
parts
in
red
have
been
updated
since,
lest
I
ETA
that
was
discussed
at
last
IHS,
the
milestones
were
kind
of
wonky
that
they
we
had
one
case
where,
like
we
submitted
a
yes
G
before
adopting
it
as
a
working
group,
last
call
and
things
like
that,
and
so
those
dates
we
believe,
are
consistent
with
the
discussion
last
time
and
the
data
tracker
now
shows
the
parts
in
red,
but
that's
not
something.
We've
shown
you
before
other
than
what
we
were
going
to
do
now.
D
Was
just
wondering
but
like
it
would
be
more
sensible
to
use
to
March
IDF
meeting,
forgetting
the
architecture
document
I
know
I
haven't
had
that
in
February,
so
it's
have
finished
in
in
March,
for
example,.
C
Months
is
to
start
a
working
group
last
call
to
include
at
an
IETF
meeting,
discuss
any
last
call
comments
at
the
IETF
meeting
and
then
submit
it
afterwards,
and
so
that
may
be
in
one
eye.
Atf
meeting
you
have
first
working
group
last
call
the
next
one.
You
have
other
discussion,
but
the
point
is
we
decided
to
submit
it
right
after
the
IETF
meeting,
instead
of
right
before
so
that
we
could
make
sure
that
we
had
consensus
on
it
at
the
meeting.
That
was.
That
was
the
goal.
C
A
A
C
F
This
hello,
yeah
I'm
meeting
a
PI
and
I,
talked
about
a
quick
introduction
after
the
document
status,
so
we
published
submitted
a
document.
First
raffle
will
Google
draft
about
two
weeks
ago,
as
in
July
2nd.
It's
a.
We
already
received
a
couple
of
good
comments.
You
know
mainly
the
father's
after
after
the
content
itself,
it's
a
largely
farmer
earlier
open,
transit,
Paula
caught
draft
right.
That
was
a
combined
alone.
F
It
has
the
architecture
and
protocol
and
I
had
to
talk
him
into
the
top
date
right
after
I
talked
him
and
we'll
cool
but
option
there
was
a
pleated
a
Miss
obtain
to
half,
but
this
issue
has
a
moral
that
right.
We
started
some
comments
from
Lhasa
local
and
also
additional
feature
request
for
that.
So
we
tried
to
throw
cetera
posted
feedbacks
there.
F
So
current
alchemist
structured
ASIC,
here's
a
contact
quicker
cook,
one
night:
we
we
have
a
profile
video.
They
have
terminologies
that
a
long
area
I
think
a
finance
in
the
table
to
talk
about.
We
have
another
self
again,
so
many
definitions,
there's
a
use
different
astray-
are
using
different
furrows
Rudy's.
Did
he
find
out
what
a
scope
this
architecture
to
cover
because
they
was
a
initially
you
know
key.
The
South
has
from
trusses
well
and
has
different
background
versus
tak
saw
so
that
were
to
scope
of
what
architecture
address
and
I
will
talk
about
it.
F
I
use
the
cases
were
this
deep
applications
are
taken.
All
that
can
be
used
really
well
for
primer
areas
with
talk,
so
please
welcome
you
to
rate
and
give
us
enough
feedback.
Other
use
cases
right.
So
today
it
has
been
using
payment,
whether
you
have
a
secure
application
to
the
payment
transaction,
useful
indication,
right
device
used
a
source
indicator
and
the
larger
user
IOT
devices.
Now
you
have
embedded
security
there
and
the
roller
added
is
a
cloud
computing
that
was
really
out
there
from
there
and
others
from
to
look
at
group
before
and
so
now.
F
Cloud
host
provider
does
not
have
a
liability,
no
in
attendance.
The
data
right
so
host
my
application
in
a
cloud
application
across
board
with
Azure
database
at
Google.
Right
I
can
roll
my
application
layer,
but
they
do
not
have
to
know
what
I'm
running
there
that
were
valuable
use
case.
That's
the
addition
on
the
from
original
ot
RP.
F
So
those
some
future
that
are
quickly
highlight
here
for
original
TRP
draft
I
am
so
wrong.
S
get
their
comments
from
multiple
people
and
terminology
right,
terminology,
unification,
so
the
worst
concept,
a
secret
to
the
module
and
Trust
firmware.
It's
an
hour,
you
need
I
pick.
A
walk.
I
saw
some
fun
where
it's
the
world,
we
choose
two
years
actually
I
said
foresee:
kaput.
Now,
look
at
the
concept
of
security,
civil
provider,
applicant
developer,
key
a
provide
and
so
on.
F
So
then,
what
that
model
should
you
use
and,
as
this
particular
civil
provider
they'll
be
much
discussion
later,
a
slide
for
that
we
added
a
diagram
about
their.
What
a
usage
Japan
will
look
like
when
you
saying
trust
each
environment
when
to
distribute,
deploy,
running
and
a
managed
trusted
application.
So
there's
a
athletic
background
flat
long
and
based
on
the
feedback,
which
is
roughly
the
back
trestle
for
morale.
Wolf
gets
become
option
now.
It's
now
required,
like
in
SDS
case,
not
needed,
so
we'll
make
an
optional
the
proposal
for
that.
F
We
also
added
one
to
make
it
transport
support
as
a
requirement.
It
was
a
optional
interval
pequeña
right
now,
we
say
case
as
art,
educators
that
any
solution
document
should
provide
the
transport
of
support.
We
also
try
to
make
assumption
that
architecture
support
multiple
tes,
how
to
test
that
or
that'll
leave
it
to
a
solution.
F
Implementation,
wise
right,
but
it
architects
at
yes
and
make
it
a
pond
or
a
distribution
to
s
once
about
time
well,
is
about
the
current
application
how
to
get
done,
but
its
architecture
that's
more
to
come
up,
but
that's
assumption
that
you
want.
We
want
to
address
so
that's
a
Mainer
scope
of
that
changing
introduced
to
there.
D
So
we
tried
to
do
that
or
we
tried
to
massage
the
document
to
get
rid
of
these
different
text
segments
that
are
relevant
to
this
trusted
firmware,
but
they're
still
sort
of
reading
through
the
document
after
the
submission
deadline.
I
I
realized
that
there's
still
some
left
over
so
there's
some
editorial
work.
That
needs
to
be
done,
which
will
be
done
in
the
next
version,
but
I
think
we
are
settled
on
this
and
and
the
motivation
for
it
will
come
later.
D
We
could
do
probably
a
better
job
in
explaining
some
of
those
architectural
differences
between
the
different,
at
least
between
those
types
of
DES
I,
think
that
could
be
quite
informative
for
everyone,
not
not
just
for
the
audience
here,
but
for
others
who
are
not
involved
in
the
process.
I
think
that's
quite
from
an
if
you
are
into
the
hardware
design
in
a
security
design
of
hardware
I,
think
that's
a
pretty
cool
concept
and
difference.
D
So
I
will
keep
that
short.
This
one
is
an
important
one
that
we
should
spend
some
time
on,
and
it's
also
something
that
dave
has
created
a
few
slides
with
with
message,
charts
or
message
diagrams
to
talk
about
the
app
distribution
or
the
anticipated
attribution.
So
one
that
we
focused
on
first
was
the
the
second
one,
the
second
mode,
which
is
sort
of
the
trusted
app
being
distributed
by
the
by
the
dam,
and
that
was
all
along
in
an
initial
version
of
OTR
P.
D
D
There
are
some
side
effects
of
doing
that
and
it's
will
be
covered
in
in
in
Dave's
presentation.
So
this
is
definitely
something
we
need
to
make
a
decision
on.
One
aspect
as
a
food
for
thought,
on
what
the
challenges
or
implications
is
that
when
you
think
about
not
just
bouncing
binaries
around,
there
are
the
same
for
all
of
the
devices
but
binaries
that
actually
personalized
or
that
have
instants.
D
Finally
instance,
specific
information
so
like,
if
you
think
about
the
web
and
the
application
distribution,
there's
a
lot
of
customization
for
the
individual
binary,
sometimes
done
that
are
getting
that
are
being
downloaded
easier,
obviously
with
JavaScript
in
for
these
type
of
things,
and
so
this
is
something
that
the
dam
has
taken
over
responsibility.
It's
probably
not
as
explicit
as
it
could
be
in
a
document,
but
probably
worthwhile
to
point
out.
This
is
since
this
is
actually
functionality
being
used
today.
D
There's
also
the
question
of
like
how
over
the
life
cycle
is
the
application
updated
the
client
application,
as
well
as
the
then
corresponding
need
the
trusted
application
and
and
I
just
wrote
a
few
questions
there
like
who
authorizes
that
update
of
an
application
and
the
TA,
and
also
what
would
be
the
security
domain
and
we're
going
to
talk
about
the
security
domain
in
a
latest
light.
In
case
you
forgot
the
concept,
so
this
book
will
also
be
covered
in
more
detail
in
in
Dave's
presentation.
D
There's
there's
a
topic
that
came
up
on
the
mailing
list,
namely
the
question
about
a
device
having
one
de
or
multiple
T's
that
can
come
in
in
a
single
process
of
having
multiple
T's
or
having
even,
for
example,
different
e
technology
allowing
having
at
the
trustzone
component
in
the
processor
in
a
separate
TPM
chip.
For
example.
D
In
the
use
cases
we
initially
worked
on,
we
focused
on
the
1t
per
device
model,
which
is
sort
of
like
the
mobile
phone,
that
of
use
case
and
in
in
this
atom
model
or
other
deployment
situation
came
along
and
that
they're
the
primary.
The
primary
question
that
was
raised
through
this
sort
of
expansion
in
the
architecture
was:
how
do
we
actually
make
sure
that
the
messages
that
come
from
the
TAM?
D
How
are
they
actually
routed
to
the
right
T
since
there
are
now
multiple
of
those
and
an
assumption
that
and
we're
going
to
talk
about
the
deep
agent
terminology
as
well?
So
there
was
this
middleman
that
relate
yup,
the
the
OTR
be
a
messages
back
and
forth,
and
it
didn't
have
any
understanding
of
the
content
of
those
messages.
It
was
purely
a
relay
passing
messages
from
from
the
the
secure
word
if
you
will
to
determined
and
backwards.
D
C
So
the
one
use
case
that
came
up
at
I
think
was
at
the
IETF
101
meeting.
It
could
have
been
on
the
mailing
this,
but
the
one
example
that
somebody
else
gave
and
I
can't
remember
who
it
was.
Maybe
it
was
something
this
room
said
well
I
had
that
the
reason
they
have
multiple
T
E's
is
because
there
are
different
types
right.
Maybe
I
have
you
know
a
TPM
like
thing
and
a
non
TPM
like
thing.
C
There
are
different
categories
right,
and
so,
if
you
have
a
TA
binary,
I
can't
just
pick
any
one
of
them.
It's
a
TA
binary,
that's
written
to
go
in
a
particular
type
of
te
e
right.
This
is
meant
to
go
in
inside
sgx,
or
it's
meant
to
go
and
Trust
so
and
out.
The
other
thing
there's
multiple
things,
and
so
the
example
case
that
I'm
showing
here
is
for
a
case.
C
We
have
heterogeneous
tes
and
a
device
is
what
binary
is
written
to
go
for
a
particular
type,
and
so
the
distinction
is
type
A
and
type
B,
whatever
those
are
okay,
and
so
this
is
all
supposed
to
be
protocol
agnostic.
In
terms
the
picture
here,
this
is
architectural
right
and
so
at
some
point,
some
application
or
installer
of
an
applications
to
step.
One
gets
the
notion
of
I.
Have
this
ta
I
need
to
be
able
to
install
that
such-and-such
depends
on
it
and
here's
some
constraints
about
like
this
is
a
binary.
C
That's
meant
to
run
on
a
bla
processor
inside
of
a
particular
type
of
thing
right.
This
is
a
signed,
STX
DLL
or
at
Sadaat
a
you
know,
trusts
own
binary
for
such-and-such
a
processor
and
so
on.
So
at
this
point
the
Box,
I'm,
labeling,
facilitator
and
we'll
talk
about
the
terminology
later
in
this
example
protocol
independent.
He
knows
because
the
metadata
says
this
requires
a
type
a
to
e
e
and
he
knows
he's
running
on
a
box
with
type
A
and
type
B.
So
he
knows
which
is
the
correct,
ot
RP
client.
C
That
needs
to
be
able
to
be
needs
to
be
the
one.
That's
communicating
with
that
Tam
for
purposes
of
finding
out
whether
it
can
install
ta,
X,
okay.
So,
in
this
case
he
know
what
he
knows,
that
it
goes
to
ot
RP
client,
one
because
he's
the
one
that's
in
Taipei.
That's
the
routing
decision
in
this
example,
slice
is
done
at
the
time
when
the
first
API
call
is
made
into
the
TE.
The
outside
knows
what
it
is
based
on
the
metadata.
That's
the
proposed
answer
to
the
open,
open
issue.
C
Okay,
at
this
point
now
you
can
set
up
a
session-
that's
an
OT
RP
session
between
that
particular
ogip,
client
and
the
right
time,
and
this
is
not
a
slide
about
picking
the
right
town
as
a
different
question
right
but
assume
you
can
pick
the
right
time.
So
there's
a
transport
session
that
he
facilitates,
and
so,
if
you
had
two
different
clients
for
two
different
tes
are
two
different
trusted
applications.
C
You
have
two
different
transport
sessions,
so
you
see,
the
transport
session
is
tied
to
going
between
a
particular
Tam
and
a
particular
tes
OT,
RP
client,
and
so
any
messages
that
come
from
the
team
come
in
the
context
of
a
particular
transport
session
and
are
obvious
which
one
to
go
to
it's
the
one
for
that
that
sessions
bound
this
ot
RP
client.
Okay,
so
that's
my
answer.
C
The
routing
decision,
if
you
will
is
made
at
the
time
that
the
metadata
is
used
in
a
facilitator,
starts
to
open
up
a
connection
on
behalf
of
a
particular
ot
RP
client
and
after
that
the
answer
is
easy.
So
this
is
my
proposed
answer
to
the
open
issue
using
again
the
use
case
that
was
discussed
last
time
by
somebody
else
that
says:
I
have
heterogeneous
te
es
on
the
same
device.
E
D
It
addresses
the
question
of
like
how
does
the
message,
interaction,
actually
work
between
the
client
application,
the
Tam
and
the
TAS
and
they've
tried
out
a
couple
of
different
approaches.
He
posted
that
question
to
the
list
beforehand
before
he
then
went
off
and
experimented
with
the
code
and
to
see
what
a
how
he
can
actually
unsay
to
yourself.
So
that's
why
I
leave
it
to
Dave
to
actually
answer
his
own
question.
So
that's
a
quite
pragmatic
approach
and
that's
yeah.
C
Yet
we
had
a
lunch
discussion,
and
so
this
was
actually
my
diagram
that
he
included
into
his
deck.
So
one
of
the
pieces
of
feedback
on
the
architecture
document
was
the
term
agent
as
used
is
an
English
word
that
doesn't
mean
to
most
people
what
it
means
in
the
document
right
in
normal
English.
An
agent
is
somebody
that
is
authorized
to
act
on
your
behalf.
C
In
the
document,
the
term
agent
is
used
to
refer
to
something
in
the
rich
operating
system
that
in
the
Ritualist
that
is
not
authorized
to
act
on
your
behalf,
okay,
and
so
the
point
here
is
agent
is
probably
the
wrong
word
to
use
for
the
thing.
That's
not
authorized
act
in
your
behalf.
That's
just
authorized
to
relay
messages.
It
can't
understand.
Okay,
and
so
the
this
is
a
purely
editorial
terminology.
C
C
Be
a
discussion
for
the
the
list
right,
but
the
point
is
the
thing
that
we're
talking
about
is
this
piece
out
here?
We
need
a
name
for
it.
There's
an
OT
RP
session,
that's
encrypted
that
goes
between
or
at
least
authenticated,
if
not
encrypted
right.
That
goes
between
some
server
thing
over
here
and
the
term
that's
over
here.
The
document
doesn't
actually
have
a
term
for
this
piece
right
here,
I
made
up
a
term
OT
RP
client.
D
We
posted
a
list
and
at
some
new
term
for
another
terminology,
pieces,
the
service
provider
and
and
currently
it's
defined
as
an
entity
that
wishes
to
supply
trusted
applications
through
motor
devices.
But
then
the
document
the
architectural
document
goes
on
and
it
provides
a
little
bit
of
extra
text
and
also
distinguishes
between
a
device
administrator,
and
it
says
the
device,
administrator
or
service
provider
of
the
device
need
to
determine
security.
D
So
they've
came
along
in
his
review
and
asking
whether
the
device
administrator
is
actually
responsible
for
controlling
what
apps
run
in
a
te
on,
for
example,
an
IOT
class
device
and
whether
the
device
administrator
has
just
another
form
of
service
provider
or
whether
those
terms
are
actually
mutually
exclusive
and
it
it's
a
little
hot.
It's
obviously
not
as
straightforward
answer.
That's
why
I
still
still
an
open
issue
currently
so
I'm
I'm
a
little
bit
mixed
about
this
one.
To
be
honest,.
F
Clarify
a
little
bit,
you
know:
origin
document,
it
was
only
silver
provider,
so
silver
provider,
like
a
bank
right
back,
dedicate
the
Chaucer
application
installation
to
devices
through
a
tam
provider,
so
silver
party,
like
a
bank
card
of
a
console,
and
then
there
is
a
the
Western
me
traitor
as
a
user
case
was
asked
right.
You
know
last
workgroup
in
a
long
one.
So
now
it's
compact,
the
white
smooth
trader
may
means
the
manufacture,
maybe
person
who
Magda
devices
it's
a
different
from
pack.
F
C
So
they
favor
so
I
asked
what
sits
on
I
think
it's
on,
so
they
they
were
so
I
asked
the
question
as
an
individual
reviewer
of
the
document
and
I
like
the
first
definition,
meaning
that
the
the
top
bullet
on
the
slide
right
I
think
that
one
is
unambiguous,
although
I
would
tend
to
prefer
a
term
like
ta
provider
rather
than
service
provider.
I
think
it's
actually
much
closer
to
the
definition
unless
and
more
clear.
But
that
said,
the
question
came
up
out
of
the
two
sub-bullets:
is
there
where
it
has
the
orbits
in
there?
C
Okay,
my
preferred
resolution
of
this
terminology
is
to
say
it's
the
EE.
If
blah
blah
blah
is
the
device
administrator
just
another
type
of
provider.
Answer
yes,
would
be
my
preferred
resolution
and
if
it's
defined
that
way,
then
you
don't
need
those
orders.
In
there
you'd
say
a
TI
ta
provider
needs
to
determine
an
ata
and
a
device
needs
to
determine
whether
the
TA
provider
was
that
so
on
and
so
on.
You
wouldn't
need
to
express
them
both
because
the
device
administrator
is
just
a
sub
case
of
one
particular
type
of
ta
provider.
H
Think
that
needs
to
be
built
into
the
Tam
kind
of
interactions
and
the
Tam
is
sort
of
the
entity
that
takes
the
place
of
the
device
administrator
because
he's
making
a
lot
of
decisions
on
what
tas
get
installed
and
and
signed,
and
things
like
that.
And
then
the
service
provider
is
just
the
one
who
is
asking
for
a
particular
ta
to
the
install.
That's
that's
the
way.
I
see
it,
I,
don't.
E
E
C
Of
the
possible
use
cases
discussed
just
help
you
think
about.
It
was
a
case
where
there's
a
relationship
between
the
Tam
and
the
service
provider
and
a
relationship
between
the
Tam
and
the
TE,
and
so
it's
only
indirect,
so
there's
a
direct
use
case
as
an
indirect
use
case.
Are
they
both
in
scope
is
kind
of
the
question
yeah.
D
But
I
think
from
from
the
feedback
like
I
liked
the
sort
of
the
change
or
that
justement
of
considering
the
service
provider
being
more
that
the
trusted
application
repository
in
some
sense
or
provider,
and
if
you
see
it
that
way,
I
think
the
answer
to
your
question
is
whether
this
is
just
the
device
administrator.
That's
just
a
subcategory
of
service
providers
for
David's
comment.
This
is
know
so.
F
So
yeah
I
could
say
that
I
said
it's
different,
but
my
opponents
say
I,
say
altar
server
provider
or
used
the
party
furtive,
and
it
maybe
is
just
in
your
scope.
The
wilder
me
traitor
say:
there's
a
word
itself
I'm
the
minister
to
myself
whether
I
should
be
in
scope.
It
was
out
of
scope,
I
think.
Maybe
just
I
would
just
the
higher
that
the
TA
supplies
Sol
provider
case.
D
D
There's
also,
this
other
key
beer
which
is
used
in
force
for
signing
and
potentially
for
encrypting
of
the
software
which
is
separated
at
and
also
needs
to
have
some
keys
or
should
associate
with
it
so
different
proposals
on
what
we
should
do
about
it.
So
they
they've
came
up
with
a
somewhat
detailed
proposal
on
how
we
should
distinguish
those
two
terms
and,
on
the
other
hand,
suggested
to
just
remove
the
trust
anchor
terminology,
and
then
we
don't
have
to
worry
about
the
distinction
between
those
two.
D
Of
course,
the
trust
anchor
term
is
used
to
out
the
document.
I
thought
it
was
a
pretty
I
argued
that
both
terms
are
very
similar.
I
didn't
want
to
go
into
the
details
own
or
have
separate
just
because
we
use
the
keys
differently
because
they
are
described
or
the
key
use
which
is
described
throughout
the
document
anyway,
including
the
table
that
had
just
shown.
I
So
if
you
would
back
up
to
the
table
sure
it
appears
to
be
the
case
that
a
certificate
authority
is
involved
in
all
of
these
cases.
Yes,
and
so,
if
you
want
to
just
reference
5280
and
say
validate
the
cert
like
described
over
there,
you
ought
to
use
the
words
described
over
there,
yeah,
which
is
trust
anchor,
which.
H
I'm
not
sure
that
it
all.
This
is
Dave
wheeler
from
Intel
I'm,
not
sure
that
in
all
cases
you
do
have
a
certificate
the
table.
Yes,
the
table
may
be
wrong,
but
I
may
have
a
different
opinion.
Okay,
but
but
I
think
we
need
I.
Think
we
need
to
talk
through
that
or
carefully
because
in
in
some
cases
in
trusted
firm,
where
I
may
not
have
a
certificate
associated
with
that
key
I.
H
Also
think
that
we
need
to
think
we
need
to
make
sure
that
we,
the
cardinality
here,
is
correct
as
well,
because
I
think
if
we
have
multiple
devices,
we
might
have
multiple
t'ee
keys,
but
it's
also
possible
that
he
may
have
multiple
attestation
keys
in
order
to
provide
anonymity
right.
So
so
I
think
we
need
to
think
through
our
use
case
here
and
and
whether
they
are
signed
under
a
CA
and
what
the
commonality
is
and
talk
through.
Some
of
those
whose.
D
Key
s
so
the
first
one
on
the
trusted
phone,
where
key
that
is
really
sort
of
left
over
from
what
I
mentioned
earlier.
So
maybe
that
should
actually
not
be
so
prominent
in
in
that
table
or
throughout
the
document
in
the
first
place,
because
it
related
related
to
the
issue
that
I
mentioned
from
earlier.
Currently
there's
only
one
at
the
station
mechanism
defined
in
sort
of
the
architecture
which
is
based
on
a
per
device,
ki
ki
Pia.
And
that's
that's
why
the
cardinality
is
right.
I
Brussels
Li,
what
I
think
Dave
was
talking
about
is
whether
you
validate
a
certificate
or
you
validate
a
signature
directly
with
the
public
key
that
is
stored
in
the
device.
That's
the
trust,
anchor
versus
something
else
is
right.
Okay,
so
we
address
that
same
issue
in
a
another
protocol
called
tamp
trust
anchor
management
protocol.
So
again
we
could
just
grab
the
same
terminology
and
not
have
the
argument.
Yeah.
D
C
C
We
need
to
explain
that
it's
the
same
as
what
the
other
community
is
used
by
the
other
term,
and
so,
for
example,
even
our
Charter
says
we
have
to
give
a
good
relationship
with
you
know,
TCGA
and
global
platform,
and
so
on
and
TCG
and
global
platform
both
use
root
of
trust
for
X
as
their
terminology.
Okay.
So,
whichever
one
you,
if
you
let's
say
you
choose
trust
anchor,
that
might
be
fun
using
the
document
as
long
as
there's
some
place.
C
That
says-
and
this
is
the
same
thing-
that
these
other
community
mean
by
root
of
trust
for
X,
okay
and
so
in
that
sense,
you're
using
them
both
but
you're,
using
one
of
them
only
in
one
place
and
using
the
other
term
everywhere.
And
the
question
is
which
term
you
want
to
use
everywhere
and
the
other
one
you're
going
to
use.
Only
in
one
place,
which
is
like
in
the
definition
or
something
nice
and.
D
Maybe
I
I
wonder
what
it's
good
to
sort
of
like
you
know
very
generically
refer
to
DBMS,
because
many
of
them,
as
we
had
discussed
earlier,
actually
don't
allow
that
functionality
we
are
talking
about
here.
They
are
sort
of
hardwired.
So
any
of
this
is
sort
of
not
applicable
so
I
I
guess
it
would
be
up
to
someone
who
is
really
into
that
organization
to
sort
of
refer
to
the
right
terminology
to
the
reference
technology
that
actually
allows
even
the
use
of
the
odo
TRB
and
the
update
of
trusted
applications,
and
so
on.
So.
D
F
Mean
PI
are
two
points.
First
of
all
about
the
public
key
versus
certificate.
Current
document,
as
in
Scorpius,
will
require
certificate,
request,
certificate
purpose
of
that
once
a
time
to
know
what
made
too
many
public
keys
that
are
like
it
just
from
where
all
the
public
isn't
managed
by
tap
that
tunnel
scale.
That's
who
purpose
we
want
to
you
say
certificate.
There
won't
come
well,
it
didn't
many
devices,
that's
a
limitation,
so
we're
very
important.
The
choice.
There
second
point
is
about
your
ability.
That
was
wrong,
that
you
can
have
multiple
T
keys
per
device.
D
So
currently
we
have
this
this
concept,
where
there's
an
isolation
concept,
at
least
where
the
on
the
de
site,
where
trusted
applications
recite
in
a
security
domain
and
if
two
trusted
applications
in
that
security
domain,
they
are
able
to
share
resources.
That
sort
of
like
the
definition
from
from
the
from
the
document,
and
there
are
messages
that
allow
you
to
create
those
security
domains
and
then
put
the
trusted
applications
in
there.
D
So
the
question
is
that
arises
is
or
that
came
up
is
what
happens
if,
in
most
cases,
they're
just
one
trusted
application
per
security
domain?
What
is
the
implication
on
on
the
protocol?
Exchange
can
can
be
actually
get
away
with,
having
always
to
go
through
a
separate
security
domain
establishment
when
you
actually
want
to
just
have
one
application
burden
per
security
domain,
as
it
is
the
case
in
some
technologies.
That's
something
that
we.
We
still
have
this
struggle
with.
That's
it.
D
F
This
is
now
the
protocol
part,
so
architecture
may
won't
change.
I.
Think
a
lot
more
discussion
that
thrive
in
the
solution
document
right
so
just
briefly
talk
about
the
most
part.
Do
not
need
30
minutes
for
that
one,
so
it
should
give
a
quick
status
update
or
that
one
and
talk
about
the
changes
we
made
in
the
document
which
a
private
document
a
little
bit
to
talk
about
today,
architect
the
program
map.
Here,
it's
roughly
it's
a
so
far
consistent,
but
we
are
the
more
features
into
architecture.
F
As
this
discussion
is
see,
they
will
accompany
change.
A
practical
part,
so
I
think
in
the
timing
alone
would
be
the
architecture.
So
let's
give
you
a
quick
update
that
one,
so
we
had
a
draft
approved
by
workgroup
or
in
a
much
much
that
meeting
then
officially
get
in
a
I
in
April
and
the
mighty
change
right
after
name
to
look
for
name
and
a
few
comments
to
change
our
or
that
one
they
were
made
their
wishes.
Oh
it's
a
that
is
when
we
produce
the
architecture
document.
No,
we'll
make
a
change.
F
F
And
there
are
things
documents
very
much
general,
then
original
itrp.
So
that's
change.
Let
update
that
wrong.
So
here's
a
quick
word
for
a
show
like
how
many
people
have
a
read
and
the
OTR
P
is
a
draft
if
it
was
theater.
Yes,
okay
chances
are
how
quickly
will
fresh
here
right
for
people
news
that
what
they?
It
is
right.
So
you
know
architect,
aqua,
know
what
rocket-jumping
and
so
assume
you
already
know
so,
but
a
cool
to
average.
Here's
our
Archon
is
a
little
commander.
F
F
What's
the
mass
of
the
particle
there's
what's
AP
is
yeah,
so
if
undercover
the
protocol
easily
miss
of
the
protocol,
the
mystery
protocol,
mister
party
first
message,
exchange
between
a
PE
and
time
time
is
a
trust.
Application
manager,
trust
layer
manager.
We
choose
to
use
Jason
face
a
message
for
now.
There
were
other
comments,
also
desire
to
go
to
more
compressed
more
finally
Merced
if
I'm
at
residence,
all
so
well
major
choice
or
else
that'll.
We
use
a
symmetric
key
and
a
certificate
like
I
was
certificate
or
like
admission
or
earlier
asymmetry.
F
Remove
cells
like
a
time
and
the
rice
you
need
to
communicate.
I
talked
about
here.
We
introduce
this
agents
right
over
those
discussions.
That
name
is
looks
different
now
will
make
change
to
the
proko
connector
or
something
all
right.
So
that's
a
really
Rolo
message:
repent,
the
lice
and
tam
someone.
We
may
ask
why
you
need
such
a
connector
just
noted
I,
but
many
of
you
know
he
fell
out
of
a
capability
to
handle
transport,
so
at
least
the
trestles
on
te
implementation.
F
It
doesn't
know
how
to
talk
outside
of
it,
so
you
must
have
a
application
in
rich
world
in
another
word
to
facility
that
that
words
is
introduced
right
normal
occasion.
Like
a
mobile
phone
case.
You
know
my
application,
your
couple
time
utility
you
need
something
that
it's
not
always
introduced
at
the
part
of
architecture,
and
we
add
that
alone
to
support
transport
idea
that
it
means
between
tb20
and
the
time
time
needed
something
you
ever
wear
with
some
messages
which
application,
instead
of
whatever
this
agent
new
target
time.
F
F
What's
the
wisest
idea,
how
many
chess
application
running
in
the
rice
and
what
he
did,
what
he
it
is
and
what
shows
application
running
and
what's
a
circuit
them
as
you
have
alphabet,
it's
just
a
to
set
well
Megaman,
api's,
first
major
circuit
domain,
so
secret
the
music
central
to
the
concept
of
this
protocol.
It's
a
critical
domain.
You
can
participate
domain
and
it
to
leave
a
secret
domain.
F
So
when
we
map
to
the
other
te
like
STX,
we're
also
a
distinct
pattern,
this
concept
and
apply
or
the
what
the
means
that
oscillation
of
the
T
applications
just
applications.
So
major
was
about
chess
obtain
major
one.
That's
a
big
target
right
eventually
secure
promise
isolation,
but
they
will
have
the
Union
status.
Application
was
installed.
Life
cycle
is
really
the
life
cycle
management,
Union
status,
application.
After
the
first
application
to
be
trans
application,
so
that's
it
automated
goal.
F
Okay,
well,
you
could
ask
years
others
that
ultimate
one,
so
you
have
a
application
either
one
there.
So
that's
a
related
product
out.
The
plan
is
try
to
cover
and
it
is
significantly
put
a
scope
right
say
you
have
messages
with
the
phone
message
protocol,
but
between
T
and
a
time
between
T
at
time
right
now,
you're
the
most
Aditi
fine.
No,
we
have
this
convo
kotfe
agent.
F
This
is
a
may,
not
be
precise
word.
So
this
was
used
to
transport,
it's
a
really
for
city
transport.
So
you
have
some
messages
from
time.
You
need
some
team
and
you
have
responsibilities.
You
need
send
a
pattern
right.
They
kind
of
there's
no
connection
you
can
establish.
Some
thing
here
need
to
do
that.
Job
and,
as
I
got
a
note,
EAP
agent,
but
they
are
say,
you've
got
transfer
connector.
The
subtle
sounds:
it
may
be
closer
to
the
update
functionality.
It
is.
F
So
it
needs
to
give
a
flavor
of
the
message.
Is
this
is
a
standard
to
json
measure
using
it
for
api
car,
quite
a
circuit
on
a
request
and
a
cricketer,
no
response.
Those
will
be
cheerful
messages,
but
the
message
you
need
be
signed
and
encrypted
and
assigning
the
encryption
uses
standard
tears
on
spec.
You
see
all
right
is
to
officer
for
that
one.
Okay,
that's
a
within
a
way!
You
don't
wanna
get
reading
with
this.
It's
just
use
whatever
you
obviously
already
specified
the
chat
akira
for
level.
What
it
how
to
look
like.
J
F
A
quick
one
here,
it's
a
remove
general
architecture
specification
to
the
arcade
draft
and
it
will
change
it
over
your
part.
So
the
protocol
part
of
change.
Yours
wait,
it's
just
the
instruction
part
we
a
little
bit
Chan
movie
or
the
instruction
change
so
now
I
say.
Is
that
a
follows
that
architecture
draft?
That's
all
some
talk,
my
update
for
that
not
really
ready
ready
for
the
change.
We
refer
to
terminology.
F
We
will
move
it
out
to
the
terminal
section
be
the
world
if
I
wanted
one
architectural
community
found
that
one
will
use
the
same
terminology
or
no
repeated,
but
it
will
attempt
no
say
integer
relationship
and
a
key
type
of
saw,
because
that
was-
and
it
has
been
what
the
OTR
be
used
as
a
solution
right
and
architect.
Dogmas
refer
to
that
one!
You
see
this
to.
You
will
be
consistent,
but
it
was
terminology
and
architecture,
realization.
F
So
they'll
be
no
API
level
change
and
no
message
change,
because
that
was
a
call
protocol.
Part
there's,
no
change
it
more
part
of
the
document
that
complies,
but
a
room
changing
was
about
trust
of
firmware
trust
for
more
part
as
a
request
that
it
should
not
be
required.
So
now
I
will
make
it
optional.
Okay,
what's
the
option
on
now
time
has
a
decision
to
make
today
say
you
receive
a
message
from
tae
Vee
it
may
offer.
F
You
include
some
other
social
imperative
transformer
order
from
Renault
transform
where
so
it'll
be
decides,
I've
trusted
it
or
not
trusted
it,
but
that
is
a
backward
compatible.
Also
can
support
other
cases,
and
then
we
also
have
some
coming
up
at
a
terminology.
Once
a
in
part
to
this
us
sick,
you
put
a
module
and
that
they
will
give
it
a
comments
item.
We
have
to
load
a
207,
so
we
just
keep
the
one
and
got
a
choose
to
use
the
trust
from
where.
F
This
one's
I
think
I
take
stock,
Martin
I
will
not
repeat
here.
So
this
also
there's
a
caps
today,
because
new
features,
a
kind
of
multi
you
support,
t
upon,
or
distribution
pipeline
application,
those
kind
not
being
designed
in
Saudi
Pia
Parker
yet,
but
will
continue
to
work
on
the
architecture.
What's
a
real
solution
for
that
one
then
we'll
put
into
the
protocol
March
Oracle
pod.
F
So
this
is
the
mall
for
that.
One
look
at
summer
idea
here
just
discussing
how
to
a
support,
multi,
BTE
and
then
hope
you
get.
There
were
also
talked
about
his
Salida
diagram
right
how
to
facilitate
even
multiple
tes
typewriter.
He
already
explained
I,
don't
know
what
repeated
a
song
found:
a
distribution.
F
There
was
some
the
finest
talk
about
rather
challenges.
We
want
to
trust
that,
because
your
honor
inside
a
client
application
will
challenge
a
few
challenges,
are
all
repeater
repeater
here,
but
it
was
also
discussed,
will
put
in
a
protocol
because
there's
an
issue
of
support
to
the
lifecycle
management.
Now
the
first
one
is
the
after
that,
how
to
imagine
to
secure
domain
or
how
to
update
the
trust.
Applications
are
and
then
how
to
refer
to
the
agent
part
so
most
to
be
continued
to
work.
I
will
expect
an
excavation
will
cover
more
in
this
aspect.
C
Okay,
this
is
Dave
Thaler
as
an
individual
participant
and
she's
the
chair
over
there.
So
at
hackathon
there
was
no
teep
stuff
like
pre-prepared
or
whatever,
but
since
I
was
at
hackathon,
I
decided
to
use
that
as
an
opportunity
to
say
what
would
I
need
to
do
to
implement.
Otr
P
could
I
do
it
just
by
looking
at
the
spec
and
so
I
started
that,
of
course,
I
didn't
get
very
far,
but
I
got
far
enough
to
generate
a
bunch
of
issues.
I
should
mention
that
I
already
have
experience
in
writing.
C
Trusted
applications
for
both
trust
zone
and
SGX
I've
done
both
in
fact
that
done
business
logic
that
worked
that
can
be
compiled
into
both
Ness
X
Enclave
and
a
trust
so
and
so
I
understand
both
issues,
and
so
I
was
reading
code
to
try
to
be
as
not
agnostic
as
possible,
but
I
was
doing
on
an
SGX
capable
laptop,
okay
and
so
I
didn't
have
trust
owned
hardware
in
hand
I
had
s
Jack's
capable
hard
to
enhance
so
anyway.
This
is
a
hackathon
report.
C
C
So
then,
anyway,
this
I
sent
to
the
list
list
of
ten
issues:
I'm
not
going
to
go
through
all
of
them,
because
at
least
one
or
two
of
them
David
Weaver's,
going
to
cover
in
his
presentation
but
I'm
going
to
cover
some
of
them,
and
so
I'm,
just
gonna
show
up
there
what
they
are
and
I'll
focus
on
a
couple
of
aspects
in
there.
Okay,
so
the
first
one
is
that
the
first
step
that
happens
and
I'll
show
this
on.
The
next
slide
is
that
something
reaches
out
to
the
Tam
to
provide
it.
C
A
here's,
the
TA
that
I
need
the
OT
RP
document
does
not
define
any
message
syntax
for
doing
that.
In
fact,
it
implies.
That's
not
part
of
out
here
P,
but
it's
ambiguous,
so
I
couldn't
actually
implement
the
first
message
in
the
exchange.
So
I
made
something
up
and
you'll
see
that
on
the
next
slide
right
I
made
something
up.
That
actually
does
not
require
that
message,
because
it
doesn't
say
what
it
is
right.
C
Okay,
so
the
second
issue
and
dave
is
going
to
talk
about
this
one
is
the
Tam
needs
to
keep
track
of
what
TAS
are
installed,
and
so
I'm
not
going
to
talk
about
this
in
more
detail
because
Dave
wheeler
is,
and
we
keep
seeing
Dave's
in
a
cover.
This
sometimes
people
me
and
sometimes
people,
men,
wheeler,
okay,
so
the
third
one
is
there's
an
extra
round
trip,
and
so
I
discussed
this
in
the
list
and
that's
where
I'm
gonna
get
to
my
slide
here.
Okay,
this
is
what
the
draft
says:
okay,
step
one.
C
This
is
an
example
flow
I
found
the
example
flow
section
be
extremely
useful.
I
could
use
that
to
say
here's
step,
one
step
two
step
through
this
is
what
I
will
implement.
Okay,
what
it
says
is
that
something
gets
ahold
of
the
TA
or
the
reason
so
step.
One
is
not
a
protocol
thing,
it
happens,
sort
of
out-of-band.
You
figure
that
out
right.
You
now
know
that
you
need
to
install
this
rich
application
and
it
depends
on
the
following
ta,
whether
that's
bundled
or
not.
It
gets
the
metadata
okay.
C
What,
then
it
says
it
says,
I
reach
out
to
the
Tam
I
know
which
Tam
it
is
based
on
meditate
or
whatever
and
say:
I
need
ta
X
with
no
syntax
defined.
Okay.
This
is
not
an
encrypted
OT
RP
session.
It's
an
unencrypted,
unauthenticated
untrusted
message
at
this
point.
The
team
can
now
reach
out
to
the
OT
RP
client
using
an
encrypted
trusted
session
that
goes
between
the
tail
and
to
end
the
TE
e.
That
says:
hey.
What
are
you
in?
What
th
do
you
have
and
the
response
in
the
step?
C
Secondly,
this
notion
that
the
rich
app
has
to
be
running
and
the
drish
app
has
a
tam
transport.
It
does
not
say
that
that's
mandatory,
that's
just
how
it
was
described,
and
so
one
can
infer
that
is
mandatory
because
it
doesn't
say
so.
This
is
what
the
dress
says
as
an
implementer.
Here's,
what
I
wanted
to
do?
C
What
I
wanted
is
I
wanted
there
to
be
something
like
an
app
installer
like
an
app
store
thing
that
talks
to
you
know
steam
at
the
Google,
Play
Store
or
the
Xbox
store
or
whatever
it
is.
That
goes
and
grabs
stuff
and
gets
manifests,
and
that
has
the
facilitator
code
in
it.
So,
but
the
rich
app
doesn't
have
to
be
launched
if
it
is
going
to
fail,
because
the
dependency
is
rejected.
C
Okay
and
so
what
I
want
is
I
wanted
one
message
that
says:
I'm
a
foo
and
I
need
ta
X,
so
here
there's
a
different
flow.
That's
what
I
wanted
where
I
wanted.
The
facilitator
piece
in
here
to
start
by
saying:
hey,
ot,
RP
client
I
have
a
dependency
on
ta
X.
This
thing
can
then
initiate
in
the
other
direction,
so
in
other
words
the
first
message.
C
Ogip
message
goes
in
the
OT
RP
client
to
the
tam,
as
opposed
to
how
it's
defined
right
now
with
the
first
otome
message
goes
from
a
tam
to
the
to
the
down
to
the
TE
right
and
so
as
those
backwards
in
terms
of
the
first
message.
This
is
what
I
wanted
to
implement,
but
I
couldn't
do
that
in
the
current
spec,
okay,
and
so
the
what
I
wanted
was
one
message:
instead
of
three
to
get
the
information,
this
doesn't
have
the
problem
that
David
wheeler
is
gonna.
C
Mention
talked
about
which
is
I
have
to
keep
track
of
all
the
installed
TAS
over
here
it
doesn't
have
that
requirement
and
if
he
says
reject,
then
there's
no
reason
to
even
launch
this
rich
application.
The
future
I
don't
have
to
worry
about
installing
the
rich
application.
If
the
metadata
says
that
dependency
is
a
heard,
dependency,
okay,
so
that's
what
I
want
and
I
couldn't
do
that.
C
But
this
is
my
use
case
as
to
what
I
wanted
to
implement
and
so
I
started,
implementing
the
closest
thing
that
I
could
and
that's
where
my
comments
came
from:
okay,
okay,
next
couple
of
issues
I
mentioned
that
there
Oh
OCSP
stapling
data,
there's
no
normative
reference,
I'm,
not
a
no
CSP
expert,
I,
didn't
know
where
to
look,
and
so
I
skipped.
This
part
I'm
saying
remember:
the
task
was:
could
I
implement
it
from
the
document
not
having
any
extra
knowledge
and
I
found?
No
I
couldn't
do
that?
C
C
If
not,
it
must
have
been
destined
for
the
wrong
person
the
wrong
entity
and,
to
me
this
seems
redundant
because
it
came
from
a
te
across
session
or
whatever
that
that
could
go
away,
I
think,
but
if
it
can't,
then
it
seems
to
be
missing
from
some
of
the
other
messages
that
Ming
had
on
a
slide,
and
so
that
was
a
point
of
confusion
in
a
document.
I
wasn't
sure
exactly
how
to
deal
with
that.
C
Okay,
the
next
one
I
think
Andrew
responded
on
the
list
that
there's
some
blue
boolean
ish
fields
there
to
find
the
strings
and
Andrew
pointed
up
in
the
list
that
actually
the
document
itself
was
internally
inconsistent.
In
some
places
it
says
the
same
field
is
of
type
boolean
and
JSON
and
other
places.
It's
a
type
string
quote
true
quote
false
even
for
the
same
field
and
Andrew
said
yeah.
That
was
an
oops,
but
I
wanted
to
be
boolean
types,
not
strings,
because
if
you
do
allow
zebra
or
encoding
Ming
mentioned,
it
was
Jason
right
now.
C
There
is
an
individual
document,
that's
the
Seabourn
coding
proposal,
I,
think
it's
known
folks
from
Carson
or
whoever
else.
If
we
go
that
way
in
the
future,
then
having
it
via
type
gives
better
compression.
It
is
implementable,
except
for
the
point
where
the
same
feel
that's
discussed
as
being
contradictory
in
two
places.
C
So
here's
what
the
exchange
says
right
now
but
Tam
says
creating
a
security
domain
and
it
comes
back
and
says:
okay,
here's
a
key
that
you
can
use
for
subsequent
operations
and
then
the
Tim
says:
okay,
I'd
like
to
install
this
ta
in
the
security
domain.
Here's
the
key
that
I
have
for
the
site-
and
it
says
okay
done
because
these
two
steps
here
now
in
the
common
case
there's
exactly
one
ta
per
security
domain.
C
Wouldn't
it
be
nice
if
I
didn't
need
to
send
this
message?
It
could
just
be
done
by
sending
this
message,
because
if
you
look
at
the
inputs
in
here
and
the
inputs
in
here,
they're
the
exactly
the
same
things
in
that
message,
the
only
exception
being
that
did
field.
That
I
was
mentioning
the
previous
slide.
That
I
found
confusing
okay
and
so
I
said.
Could
you
optimize
this
out
to
say
the
first
one
of
these?
Does
this
as
a
side
effect?
If
it
isn't
there
create
it?
Okay,
could
that
be
a
side
effect
for
optimization?
C
Again,
that's
still
backwards,
compatible
you're,
just
providing
an
optimization
that
says
if
it
hasn't
been
done
yet
do
it
as
a
side
effect.
So
we
had
this
exchange
on
the
list
where
I
think
it
was
Andrew
was
explaining.
Oh,
but
this
key
that
you're
getting
is
is
the
main
thing:
okay,
because
what
this
key
lets
you
do
is,
if
you
choose
to
encrypt
the
TA
binary
or
the
data
associated
with
it,
with
information
that
is
unique
to
that
device,
like
only
that
device
can
decrypt
here's
the
data
that
goes
with
it.
C
Okay,
when
this
key
is
useful
here,
so
he's
saying
if
there's
encryption,
okay,
so
first
of
all,
encryption
is
not
mandatory.
So
there's
two
cases:
okay,
if
you're
not
using
encryption,
then
of
course
it's
redundant
information
at
just
an
extra
round
trip.
Okay,
you
can
implement
this.
Yes,
it's
just
inefficient,
I
didn't
like
it,
but
I
could
implement
it.
Okay,
so
it
doesn't
carry
additional
information
and
it's
just
less
efficient
right,
so
it
could
be
done.
C
So,
let's
take
the
case
that
he
was
talking
about
where
you
require
encryption,
so
the
key
that
you're
getting
out
of
create
SD
right
now
is
a
different
key
for
each
security
debate.
The
architecture
document
explains
to
the
same
security
provider,
can
have
any
number
of
security
domains
like.
If
you
have
five
apps
in
the
device
you
could
have
each
one
have
its
own
security
domain,
so
I'm
the
security
that
the
provider
I
got.
Five
apps
and
therefore
I
have
five
security
domains
because
I
want
them
to
have
no
memory
protection
from
each
other.
C
Hey,
that's
my
choice
and
so
how
many
keys
do
I
have
if
I
create
a
new
security
meaning
for
each
one,
I
have
five
keys.
If
you
go
back
to
that
table
that
we
were
commanding
on
with
Hannes
and
Russ
and
I,
it
was
labeled
as
a
service
provider
key
that
was
create
a
main
key.
So
what's
the
granularity
here?
Is
it
one
key
first
security
domain
where
there's
multiple
per
service
provider,
or
is
he
just
one
per
service
provider?
C
So
I
claim
that
bundling
the
notion
of
the
service
provider
key
into
a
per
SD
message
is
not
the
right
granularity.
That
was
my
conclusion
and
thinking
through
this
okay,
as
it
may
not
be
the
right
message
to
do
that
operation
in
or
maybe
we
need
some
other
variation
of
that
exchange.
I,
don't
know
what
the
answer
is.
I'm
we're
saying
that
was
the
issue.
Is
that
I
end
up
with
five
keys,
even
though
the
architecture
document
or
the
the
table
says
they
all
need
one
size
mismatch?
C
C
There's
ID
fields
that
are
under
specified
and
I
think
even
Andrew
agreed,
yes,
they're
under
specified
I
just
says
they
need
to
be
unique,
it
doesn't
say
what
they
have
to
be
unique
within.
Do
they
have
to
be
globally
unique.
They
have
to
only
be
unique
within
a
particular
session
between
the
t'ee
and
the
TAM
right,
for
example,
can
I
use
a
sequence
number
or
not?
If
I
use
a
sequence
number,
it
is
not
globally
unique.
It's
unique
within
my
session.
C
It
didn't
say
right
now,
they're
both
right
now
they
are
strings
and
Andrew
said
oh
well.
That
means
you
could
use
Goods
if
you
need
global
uniqueness.
This
is
good.
You
can
use
Goods
if
you
only
need
per
session
uniqueness
extra
complexity.
That's
overkill.
Tell
me:
I
can
use
a
sequence
number
okay,
the
document
doesn't
say
right
now,
so
I
didn't
know
how
to
implement
that,
and
so
that's
kind
of
where
I
started,
saying
what
do
I
do
here
and
making
a
guess
and
which
could
be
wrong?
Okay.
C
C
And
then,
lastly,
this
was
an
editorial
issue.
I
found
it
confusing
that
this,
what
looked
like
the
same
thing
was
referred
to
by
two
different
strings
in
here
you
can
see.
The
only
difference
is
the
te
e
and
t
BS
in
the
middle
of
it.
There
was
an
explanation:
I
think
it
was
being
posted
to
the
list
that
I
didn't
understand.
It
also
I
still
understand
this
one,
but
this
is
purely
at
a
trial.
There's
no
technical
issue
here.
I
could
implement
it,
no
matter
what
I
just
found
it
longer
to
implement
it.
C
Cause
I
had
to
flip
back
and
forth
between
places
to
figure
out
what
it
was
talking
about,
and
then.
Lastly,
this
one
is
kind
of
architectural
specific,
as
I
was
thinking
about
how
to
arrange
code.
It
is
unclear
in
the
document,
at
least
in
the
places
that
I
could
find
when
I
was
looking
at
the
time
whether
a
rich
app
is
allowed
to
depend
on
two
ways
from
different
Tam's.
C
C
My
claim
is
that
the
way
that
the
more
trusted
applications
to
get
developed,
the
more
and
more
likely
it
is
that
that
same
model
will
translate
over
for
the
same
types
of
reasons
as
people
do
it
for
the
rigid
location
dependencies.
Okay,
so
I
fully
expect
this
to
become
common,
even
if
it
is
not
common
now,
I,
don't
think
the
protocol
has
to
change
significantly
to
accommodate
this.
So
I
don't
think
it's
a
showstopper
to
say
that
yes,
a
TA
can
depend
on
another
ta.
C
F
F
A
A
F
F
It
was
not
any
original
scope
right,
much
Matias,
Cheney
relationship.
So
now
a
TA
install,
not
ta.
That
was
not
is
that
I
think
we
need
to
discuss
offline
little
bigger
a
little
bit
the
scope
chain,
nine
nine
euros
replied
say
at
the
wires
muhammad
wa
t
so
get
it.
The
worst
state
response
consider
at
least
of
get
authorities
dead,
TPA
responses.
That
was
a
relationship;
okay,
one.
Yes,
a
list
of
others.
Okay,
that
I.
F
F
B
B
Firstly,
thanks
to
David
is
really
important.
We
will
get
feedback
from
people
working
with
the
protocol
to
raise
these
issue.
I
do
want
to
cover
the
point
about
the
encryption
of
the
ta
being
optional,
which
I
think
you
I
think
David.
He
was
saying
that
the
a
encryption
was
optional
and
for
the
case
where
it
wasn't
required.
The
message
protocol
could
be
important,
I
believe
right
now
in
the
protocol
document,
the
TA
encryption
is
mandatory.
F
Yeah,
okay,
okay,
continue
here:
okay,
let's
just
jump
on
this
issue.
So
today,
yes,
I,
think
that's
a
you
made
good,
a
purple,
I
think
there's
a
optimisation
case.
You
know
before
the
cool
part
was
soon
right,
the
very
very
population,
a
tip
under
itself.
It
will
be
always
encrypted
so
that
one
pass
former
supply
to
te.
No
Manmeet
are
you,
including
any
client
applications.
You
never
see
the
finer
self
so
that
they
couldn't
reverse-engineer.
So.
F
C
H
F
You
know
you
go
back
which
one
87
okay,
there
yeah
intercept
it
uniquely
yeah
those
who
one
size
away
at
the
other
coming
alright.
So
that
was
a
more
consumer,
then
that
cameras
off
to
track
this
request,
I
sent
when
next
unit
station
responsive
company
I
can
link
myself
it's
a
really
unique
within
Pam.
C
F
I
could
come
I'm,
gonna
say
my
okay
say
one
so
today
there
was
a
design
purpose
in
the
beginning.
So
when
your
application
says
I
want
even
start
yeah,
maybe
it
here
already
installing
twice.
So
it
is
an
upgrade
or
Sydney
reinstallation.
That's
why
it
to
make
a
round
trip
to
time.
First
time
said,
tell
me:
do
you
have
the
TA
already?
Not
if
you
do
its
upgrade,
not
installation,
so
that
was.
C
F
A
F
Initiate
the
first
request
get
the
one
state
it
as
T.
Tell
me
what
years
you
already
have.
If
you
ought
to
have
the
TA
I
was
sending
us
an
update.
Yeah
no
say
you
thought
yeah
that
why
that
was
a
gated
on
stage.
There
was
always
a
first
call,
secondly,
other
than
the
appropriate,
adversely
new
installation
decision.
It'll
make
this
also
integrated
part.
There
may
be
multiple
controller
station
here
already
installing
benefit
I
do
all
because
of
some
a
second
attempt.
F
C
K
C
F
K
F
C
F
F
F
C
The
document
is
written
for
one
and
I
wanted
to
use
model
and
I
wanted
a
document
that
would
allow
me
to
use
model.
You,
okay,
I,
don't
believe
I'm
asking
for
anything
that
could
not
be
perfectly
backwards
compatible.
If
you
had
an
existing
implementation
right,
I
just
mean
that
you
would
be
using
different
message
or
using
optional
fields.
You'd
skip
some
messages
like
create
SD
or
whatever.
It
is
all
right.
F
K
C
C
F
C
C
Session,
because
not
shown
here,
it
was
on
your
slide
on
the
slide
we
had
earlier.
The
track
work
session
in
general
has
to
be
initiated.
Outbound
right
because
it
could
be
far
away
and
stuff
here
is
only
outbound
will
work.
That
means,
if
the
connection
is
outbound
here,
it's
not
a
burden
to
have
the
first
message
be
in
the
OTP
right
client
to
the
Tim.
C
F
D
F
F
I
A
We
start
with
David
I
want
I
just
wanted
to
call
it
a
couple
of
logistical
things.
So
no
I
don't
need
that.
You
can
give
it
to
these.
So,
given
that
you've
listed
out
the
ten
issues
right
so
I
think
we
need
to
start
keeping
track
of
this.
So
my
suggestion
is
to
start
and
github
put
the
documents
in
there.
David
wheeler
has
also
volunteered
to
help
be
one
of
the
editors
for
at
least
the
architecture
draft.
A
H
Great
so
my
name
is
Dave
wheeler
I'm
from
Intel
I'm,
going
to
talk
some
about
the
issues
in
looking
at
teep
in
SGX
I'm,
not
going
to
satisfy
all
your
curiosity
about
SGX
there's
some
references.
These
are
posted,
so
you
can
go
look
more
about
it.
So
I
just
ask
if
we
maintain
our
questions
focused
on
on
teeth,
I'm,
going
to
talk
a
little
bit
about
what
SGX
is
and
then
talk
about
some
of
the
problems.
H
From
that
perspective,
with
teep
I'll
talk
about
the
trusted
computing
base
and
how
that
has
impacts
to
teep
and
then
I'll
talk
about
attestation.
I've
got
some
other
slides
too,
to
talk
a
little
bit
more
in
pictures
about
some
of
the
flows,
which
I
think
will
help
more
of
the
conversation.
So
I'm
gonna
go
through
these
first
ones
pretty
quickly,
and
then
we
can
have
questions
over
the
pictures,
because
I
think
it'll
be
easier
to
talk
through
that
way.
H
So
SGX
is
very
different
from
trust,
owns
and
perhaps
other
tes
instead
of
having
some
sort
of
kernel
or
think
something
like
that.
Ollis
Jex's
is
really
some
enclave,
page
cache
some
encrypted
memory
and
what
an
application
does
an
application
in
includes
the
enclave
code
and
then
loads
that,
through
some
processor
instructions
he
enter
and
and
re-creating
things
to
actually
create
the
Enclave,
and
so
that
that
Enclave
is
actually
part
of
the
client
process.
H
The
operating
system
manages
the
page
tables,
but
but
can't
do
anything
to
them
because
they're
encrypted,
so
it's
one
process
and
for
one
Enclave
to
talk
to
a
different
Enclave.
There
has
to
be
some
some
special
things
going
on.
So
when
an
Enclave
is
launched,
the
application
executes
an
instruction
that
talks
to
a
special
platform
service
called
the
launch
control,
and
that
does
some
integrity
checks
on
the
Enclave
itself
to
make
sure
it's
properly
signed
and
with
a
key,
that's
signed
by
the
launch
key.
H
So
all
of
this
is
kind
of
very
different
flow
than
what
T
kind
of
talks
about
from
an
arm
perspective.
So
the
first
piece
is
the
trusted.
Application
isn't
separate
from
the
client
application
so
typically
when
we
deliver
an
application
that
all
the
TAS
are
bound
into
it
and
you
don't
have
to
go
searching
for
a
ta-tas,
don't
get
installed
separately
from
the
client
application
itself.
H
Now
it
isn't
the
case
that
you,
you
couldn't
change
that,
because
a
trusted
application
acts
just
like
a
dll,
and
so
you
could
have
the
DLLs
outside
of
the
application
and
actually
install
them,
but
the
unclothed
doesn't
exist
until
the
code
is
actually
loaded.
So
there
isn't
something
for
me
to
go,
ask
and
say:
hey:
do
you
have
this
TA
or
is
this
TA
loaded?
That
really
is
a
non-secretor
in
in
SGX?
There
is
no
security
domain
because
we're
not
we
don't
have
a
large
t'ee
that
we're
separating
for
applications.
H
@Ee
is
basically
instantiated
in
memory
for
a
particular
Enclave,
so
you
could
consider
that
security
domain
of
one,
but
you
know
I,
think
we
need
to
talk
about
what
what
are
we
trying
to
get
out
of
security
domains
and
I'll
talk
more
about
that
a
little
later
and
and
so
there
is
no
really
internal
agent
watching
all
the
enclaves.
I.
Don't
have
some
registry
somewhere
where
I
say
you
know:
I've
got
these
27
TAS
installed
somewhere
on
my
platform,
and
these
three
are
currently
running
there.
H
Dave,
Thaler
and
I
talked
about
some
some
options.
For
this
his
perspective
was
it's
it's
kind
of
onerous
I
guess
in
in
current
sjx
to
to
go
get
your
application
signed.
You've
got
to
go,
get
a
key
from
Intel
and
get
that
signed
by
the
launch
key
we're
working
to
make
that
a
little
easier.
But
this
concept,
then
of
I've,
got
to
have
a
key
that
allows
me
to
operate
on
the
platform
and
if
I
have
different
platforms
with
different
keys,
then
then
that
can
become
kind
of
interesting.
H
That's
where
a
Tam
might
come
into
place
and
might
be
very
useful,
so
that
I,
don't
necessarily
have
my
ta
sign
for
that
platform.
I
used
the
TA
to
do
that,
so
I
say:
hey
ta,
I
want
to
run
this
or
Tam
I
want
to
run
this
ta.
The
TA
will
sign
it
for
you
and
return
it
back,
and
then
it
will
be
able
to
launch
on
the
platform.
I
thought
that
was
a
really
interesting
idea.
There
also
isn't
really
a
start-stop
or
things
like
that.
The
application,
the
client
application
has
control
of
the.
H
So
let's
switch
a
little
bit
to
SGX
the
trusted
computing
base,
and-
and
this
really
goes
back
to
some
of
the
things
we
had
talked
about
on
the
mailing
list-
we're
not
tied
to
secure
booth.
So
the
perimeter
on
the
your
right
hand,
side,
you
can
see
what
s
Jack's
attack
surface
is
it's
really
just
the
hardware
sjx
is
implemented
in
in
microcode
in
the
cpu,
so
it's
security
perimeter
is
the
cpu
package.
H
All
of
the
memory,
if
that's
off
package
is,
is
encrypted,
so
so
that's
outside
of
the
the
boundary
the
BIOS
and
any
of
the
secure
boot
is
also
outside
the
TCB.
It's
true
that
the
BIOS
does
set
up
the
memory
for
how
much
memory
you
have
in
the
Enclave
page
cache,
but
the
only
thing
that
the
BIOS
can
do
is
not
give
you
memory.
So
it's
a
denial
of
service,
it
doesn't
have
control
of
the
keys
or
any
of
that
the
OS
is
also
formally
outside
of
the
TCB.
H
So
again,
we
we
don't
really
depend
on
secure
boot
and
in
fact,
if
you're
using
SGX
on
a
platform
you
may
not
even
have
secure
boot
turned
on
so
to
go.
Ask
for
a
measurement
of
how
your
platform
was
booted.
It
may
not
even
be
possible.
Sjx
has
its
own
trust
routes
and
its
own
keys
for
verification
and
measurement
and
so
forth.
H
So
now
whether
secure
boot
is
on
or
not
you
know,
that's
that's,
maybe
more
of
a
personal
decision
and
at
am,
as
Ming
pointed
I,
think
it's
a
good
idea
to
make
that
optional
and
then
a
tam
can
then
make
the
decision.
Do
I
really
want
to
run
my
application
on
this
platform
if
it
doesn't
have
secure
boot
and
and
I?
H
Guess
this
as
another
point,
what
I'd
like
to
do
talk
more
about
maybe
using
eat
tokens
as
a
way
to
give
us
more
flexible
attestation
capability
in
in
teep
and
and
then
allow
the
claims
to
then
be
decided
upon
by
the
Tam
and
say:
hey
I'd
like
to
have
this
kind
of
token,
with
these
kinds
of
Atta
stations
and
and
then
that
that
would
give
us
some
more
flexibility,
I
think
going
forward.
But
whether
we
want
to
tie
those
things
together.
Is
this
something
we
can
discuss.
H
So
the
last
set
of
slides
here
is
on
attestation.
There's
two
types
of
active
station
that
happened
with
SGX,
there's
a
local
and
in
a
remote
attestation,
so
between
two
enclaves
on
the
platform.
I
can
do
an
access
station
between
them
and
that
uses
an
a
ESC
map
key.
So
it's
just
like
an
H
map
construct
and
the
CPU
is
really
the
trusted
entity
between
the
two
enclaves
and
provides
measurements
between
them.
So
you
can
have
two
enclaves
set
up
a
trusted
channel
or
shared
data
or
or
whatever.
H
If
you
want
to
do
an
attestation
outside
of
the
platform,
we
call
that
a
remote
attestation
and
that
uses
an
algorithm
called
epic.
If
it
is
an
elliptic
curve.
Group
signature,
algorithm,
I'll
talk,
I
have
another
slide
to
talk
a
little
bit
about
that.
But
what
you
do
is
you
and
an
unclaimed
would
do
a
local
attestation
and
then
provide
that
local
attestation
outside
of
the
TE
e
to
the
rich
app.
I
H
H
Each
each
Enclave
gets
keys
derived
from
some
internal
parameters
and
then
gets
a
symmetric
key,
that's
unique
to
them
in
their
state
when
you
pass
that
report
off
to
another
Enclave.
What
is
included
in
that
report
is
information
about
the
Enclave
who
sent
you
that
attestation
and
then
that
information
is
then
passed
to
the
CPU,
which
creates
that
key
or
verifies
that
key
for
you.
So
that
he's
just
symmetric.
H
Okay,
so
what's
relevant
to
teep
I,
think
the
the
primary
thing
is
as
we
we
look
at
the
crypto
in
order
to
be
able
to
do
a
test
ations
to
at
am
and
outside
entities.
We
need
to
be
able
to
support
epic
as
an
optional
algorithm.
I
wouldn't
say
that
that's
something
that
we
need
to
have
mandatory,
but
for
Tam's
and
TAS
and
service
providers
that
want
to
interface
within
SGX
on
they
need
to
support
method.
H
H
What
one
thing
I'd
recommend
is
that
we
look
at
post
quantum
I
know
Intel
is
very,
is
trying
to
make
sure
that
all
of
the
products
and
things
that
they're
pushing
out
our
our
post
quantum
secure
to
the
best
of
the
NIST
recommendations.
I
listed
some
algorithms
down
here,
based
upon
some
reviews,
I
changed
some
of
the
things
that
we
talked
about
at
lunch
the
other
day
and
adding
in
the
epic
group
things.
Obviously
that's
something
that
we
can
discuss
more
on
on
the
mail
list.
H
So
let
me
transition
more
into
some
pictures
where
maybe
we
can
have
some
more
conversation
about
this,
so
so
out
of
these
things,
with
with
some
of
these
SGX
idiosyncrasies
discussed,
you
know
what
what's
relevant
as
far
as
teep
services
goes
right.
So
if
we
had
t
p--
on
an
STX
platform,
it
would
operate
quite
a
bit
differently.
H
Maybe
then,
some
of
the
flows
that
are
currently
described,
the
t,
p--
agents
counterpart
inside
the
t,
ee,
would
have
to
be
an
enclave
just
like
any
other
enclave,
and
it
wouldn't
really
have
this
omnipotent
universal
knowledge
about
what's
going
on
inside.
So
the
only
thing
that
we
could
really
do
is
a
best-effort.
If
applications
cooperated
with
some
ree
service,
that
was
the
the
t,
p--
agent
or
broker,
or
whatever
we
end
up,
calling
it.
Then,
then
that
agent
could
respond
out
of
the
Enclave
to
a
tam
to
discuss.
H
You
know
what
bubbly
installed
and
what's
probably
available,
but
really
because
of
the
way
that
STX
is
normally
packaged
today.
That
may
or
may
not
be
real
useful
it
the
most
important
information
that
would
be
hey.
How
much
memory
has
been
allocated
to
to
SGX?
How
big
is
my
page
cache
because
I
don't
want
to
have
a
hundred
and
twenty
eight
megabyte
page
cache
and
trying
to
download
a
200
megabyte
a
ta,
but
so
there
might
be
some
things
that
are
limited,
but
what
what
I
wanted
to?
Let's
see?
Do
we
have
the
other?
K
H
H
Yeah,
that's
good
okay,
so
so
we've
talked
a
lot
about
how
TAS
are
packaged
and-
and
some
of
this
has
to
do
with
how
they're
signed
so
I
spent
some
time.
You
know
thinking
about
this
from
an
SGX
perspective
kind
of
folding
in
some
of
Dave's
ideas
and
things,
and
so
as
I
look
at
this
or
as
I
think
about
this
I,
see
kind
of
four
quadrants
along
the
top.
H
On
the
right
hand,
side
the
TA
may
be
signed
it's
signed
by
an
SPE
or
developer,
but
it
doesn't
have
the
right
signature
for
the
platform,
and
so
this
is
where
it
might
be
interesting
to
be
able
to
for
the
rich
app
or
for
ot
RP,
to
be
able
to
send
that
that
bucket
of
bits
that
the
T,
that
is
the
TA
and
say
hey.
Can
you
sign
this
for
me
so
that
I
can
run
it
on
this
particular
platform
along
the
bottom?
H
Okay,
all
right,
so
so
in
the
case
where
the
TA
is
packaged
with
SGX,
you
would
install
the
application
by
some
means,
whether
it's
a
USB
stick
or
something
like
that.
You
get
that
onto
the
application
and
then
the
client
application
has
to
run
and
it
would
have
to
talk
to
some
teep
agent
or
broker,
or
something
and
say
hey
is
my
TA
properly
signed.
If
it
is,
then
the
application
would
just
load
it
and
and
run
it
and
there's
no
need
for
for
Tim
interaction.
H
H
H
When
you
ask
for
a
TA,
it
gets
instantiated
by
a
trusted
agent
inside
trust
zone,
but
in
in
sjx
it
doesn't
work
that
way
the
bucket
of
its
kind
of
has
to
come
out
and
then
get
put
back
in.
So
it's
good
to
the
next
slide.
So
so
the
way
I
kind
of
thought
about
this
is
so
you
install
the
app
and
then
in
step.
Two,
you
say:
hey
I
need
these
to
these
TAS
right
and
so
I
showed
that
I've
got
some
dependency.
H
It's
probably
a
manifest
that's
signed,
or
something
like
that
and
and
that
would
go
into
the
heap
agents
Enclave
and
then
that
tip
agent
Enclave
would
would
go
and
talk
to
the
Tam.
Now,
obviously,
that
does
have
to
I
didn't
show
it
here,
because
it
gets
a
little
crazy.
It
would
have
to
go
back
out
to
the
cheap
agent
and
the
cheap
agent
would
have
a
socket
right
out
to
the
Tam
and
then
that
Tam
act
interaction
would
either
get
assigned
ta.
H
If
it
wasn't
in
the
registry,
the
the
teep
agent,
the
Enclave,
could
maintain
a
registry
of
TAS
just
like
we
do
in
in
trustzone
whether
we
want
to
do
that
or
not
becomes
interesting.
As
we
talk
more
about
you
know,
normally
the
SGX
enclaves
are
tied
to
a
particular
application
and
that's
because
keys
and
secrets-
and
things
like
that
are
sealed
to
the
Enclave.
H
So
if
we
share,
if
Hannes
and
I
share
a
TA,
then
or
an
enclave
in
the
SGX
case,
then
I
can
see
Hannes
keys
and
misused
them
because
I'm
an
evil
guy
and
then
I.
Could
you
know,
sign
him
up
for
a
big
debt
or
something
like
that
and
get
the
check
so
there's
reasons
why
we
probably
don't
want
to
sign
duty
share
TAS
that
way
and
that's
something
we
can
can
talk
about
us
as
we
move
forward.
H
But
if
we
did
that
this,
this
would
sort
of
be
a
way
to
allow
that
to
to
occur
in
that.
In
this
case,
then,
you
know:
uninstall
an
update
and
delete
of
TAS
actually
makes
sense,
because
you'd
be
talking
to
to
this
registry.
I
still
think
we
have
some
sort
of
issue
with
return
when
the
teep
agent
Enclave
returns,
the
in
in
the
last
step,
returns
the
TA
to
the
untrusted
app
or
the
client
app.
H
It
has
to
go
through
the
teep
agent
and
and
that's
where
the
TA
could
be
could
be
attacked,
and
that
becomes
problematic,
not
not
so
much
that
the
TA
itself
could
be
changed,
because
the
integrity
will
be
checked
on
the
load
by
SGX.
But
if
I
don't
know
what
specific
ta
I'm
trying
to
get,
it
might
have
other
functionality
in
it.
That
would
allow
someone
else
to
do
something
that
I
don't
want
it
to
do.
So
we
have
to
sort
of
talk
about
that
and
that
may
require
the
client
app
to
do
some
additional
verification.
H
Like
I
said
in
yellow
there
right
do
some
sort
of
secondary
verifications.
This
really
the
TA
that
I
want
to
check
the
hash
check.
The
developer
signature
on
it
check
the
version
number
and
like
that.
So
you
know,
and
as
we
as
we
kind
of
use
some
of
these
sequences
to
talk
about
like
the
the
T
IDs
and
the
our
IDs.
If
I've
got
multiple
TAS
talking
to
the
Tam,
I,
don't
have
a
I
may
not
have
a
universal
agent
right
talking
to
the
Tam.
So
how
we
do
that?
H
How
we
get
that
the
our
IDs
and
things
like
that
to
work
become
interesting,
and
then,
though,
the
next
slide
I
think
is
the
summary.
So
as
I
as
I
thought
through
this
I
try
to
reduce
down
what
I
think
we
need
to
do.
I
think
we
still
need
lots
of
conversations
about
how
the
app
is
is
packaged
and
what
T
messages
apply
to
that
and
how
what
security
implications
we
tie
to
those,
but
other
than
that.
You
know
that
that's
sort
of
that
ta
delivery
within
a
client
app.
H
H
H
What
does
it
mean
to
package
to
TAS
and
one
security
domain
other
than
just
ease
of
management
right
ease
of
management
could
be
one
thing,
but
what
does
that
mean
inside
the
t'ee
and
make
sure
we
crisp
up
that
definition
and
if
we're
going
to
continue
to
use
that
and
I
think
it's
fine
to
then
say
in
some
instances
like
an
arm
there,
there
can
be
a
security
domain
of
more
than
one
on
STX.
It
would
would
likely
be
just
one
and
then
we'd
have
to
look
at
if
it's
valuable.
How
do
we
simulate
that?
H
Because
I
think
we
could
do
that
if
we
needed
to
and
I
think,
we've
already
started
to
address
some
of
the
platform
specific
things
that
that
are
there,
so
so
that
was
that
was
really
fast
through
SGX.
If
you
see
me
around-
and
you
have
some
questions,
please
feel
free
to
you
know,
ask
me
I'd,
be
very
happy
to
talk
to
you
about
it,
some
more,
but
maybe
there's
some
questions
over
what
what
we've
talked
about.
We
can
go
back
to
some
of
the
other
slides
if
we
need
to.
A
Now
it's
the
time
to
speak
up,
so
procedurally
dave
has
put
the
list
of
the
recommendations
and
I
think
I,
don't
remember
if
it
was
Hannes
or
main
so.
We've
already
talked
about
having
support
of
the
ta
delivery
within
a
client
application,
so
I
guess
rather
than
reading
each
one
of
them
again
since
dave
has
already
gone
through
them.
The
question
that
I
put
here
is:
are
there
any
objections
to
the
musts
and
shoulds
that
are
on
this
list?.
D
Two
comments:
the
first
one
is
about
eep-eep
and
in
some
sense
you
raise
the
question
of
like
how
do
we
accommodate
for
different
attestation
mechanisms?
Because
it's
not
just
the
algorithm,
it's
it's
more
than
that
right
and,
and
you
propose,
or
do
you
sort
of
brainstormed
about
the
idea
on
the
a
token
usage
and
and
maybe
that's
a
way
for
it
depends
on
how
that's
moving
along.
But
it's
it
is
a
need,
an
issue
that
will
have
implications
on
post
protocol
document,
but
also
that
the
architecture
document
in
in
supporting
those.
A
Yeah
I
think
that's
fine
Hannes,
so
if
I
were
to
interpret
what
you're
saying
for
the
third
bullet,
I,
don't
think
you're
objecting
I
think
it's
just
the
question
of
how
we
move
move
forward.
So
again,
the
question
on
floor
is
because
of
time.
Please
only
speak
up
if
you
have
objections
because
we're
getting
short
on
time,
things
on
this
line,
Hank
yeah.
J
I
agree
with
disagree
with
tip
should
not
require
secure
boot.
Attestation.
I
would
agree
that
steep
should
not
require
the
deprecated
six-year
boot
and
then
now
current.
It
is
to
offer
to
get
a
boot,
because
that
is
what
it
is
now
I
would
strip
the
term
attestation
from
secure
boot
entirely
every
what
chip
must
avoid
definition
and
of
operations
is
okay
and
definition.
Operation
secure
boot
again
is
deprecated.
It's
authenticated,
Buddha,
okay,.
J
K
A
J
A
F
C
I
think
that
there's
many
ways
to
allow
algorithm
agility,
including
ways
that
include
things
like
I,
Anna,
registries
and
so
on,
and
so
there
are
ways
to
allow
vendor
to
do
vendor.
Specific
things
have
been
done.
Another
protocols
and
David
you're
saying:
should
there
be
some
way
to
allow
a
vendor
specific
algorithm
here,
because
there's
a
use
case
for
that
for
using
epital
be
nice
if
there
was
some
way
for
that
vendor
to
use
this
protocol?
Okay,.
F
Okay,
yeah,
that's
yeah
muscle,
suppose
I,
don't
but
I
think
in
a
sort
of
pull
later
I
said
a
pony,
I
say:
should
support
quarter,
AB
selects
a
it's
all
it
does,
but
I
say
that
was
to
me.
Is
that
sure
to
support
our
maturity
and
our
maturity,
we
can
post
more
quantum
as
a
harness
away.
Well
same
page
right,
it's
a
really
Alchemist.
All
right,
you
see,
a
nice
is
broken
by
a
quarter
more
potentially
right
so
sighs.
We
all
have
a
charity.
F
A
F
A
Hearing
the
objection
so
yeah,
so
what
we'll
do
is
well
we'll
put
the
fourth
one
as
an
issue.
Yeah
we'll
put
the
other
ones
as
confirmation
on
the
list,
and
it
sounds
like
you
know.
What
I
would
ask
for.
Those
that
have
spoken
up
is
to
make
clarifications
Honus
and
named
right
to
the
third
one
for
the
post
quantum
to
put
the
recommendation
for
how
we
could
move
forward
to
them
hearing
on
no
judgments.
Sorry,
second,
then,
third,
okay,
any
other
is,
is
that?
Okay,
thanks
Dave,
okay,
any
other
well
I,
know
I
I,.