►
From YouTube: RATS Architecture Design Team, 2021-12-14
Description
RATS Architecture Design Team, 2021-12-14
A
A
Yeah
sure
I'm
not
I'm
not
capable
of
screen
shares,
but
I
am,
I
will
be
able
to
lead
the
discussion,
so
it
is
a
extraordinary
meeting
because
of
the
I
think,
a
small
issue
that
is
presented
by
this
was
issued,
defiled
by
thomas
on
the
github
repository
thomas.
Could
you
remind
me
again
of
the
issue
or
could
you
share
maybe
even
the
the
github
issue,
checker
the
corresponding
one
and
or
can
you
even
hear
me.
A
A
Well,
my
webex
also
has
a
ton
of
new
features,
so
there
is
as
this
I
will.
I
will
look
into
this.
There
are
not
a
lot
of
open
issues,
so
the
trust,
anchor
definition
is,
I
think,
the
issue.
It's
number
three,
nine,
two
and
mistakingly,
because
I
was
taking
this
from
the
top
of
my
head.
I-
and
this
is
a
little
bit
embarrassing.
A
B
A
Yeah,
so
so
the
trusted
thing
is
on
the
threads
are
basically
roots
of
trust,
the
thing
in
the
device.
This
is
about
terminology
about
the
authority
endorsing
from
the
outside
of
the
device.
So
thomas,
could
you
just
quickly
walk
us
through
this
issue
and
it's
basically
in
two
senses,
as
you're,
muted.
D
A
A
B
E
F
C
Is
it?
This
is
the
issue
it's
purely
editorial,
but
it
seems
important
to
me,
and
it
is
because,
throughout
the
document,
the
the
term
trust
anchor
is
meant
as
a
public
key
and
associated
metadata,
and-
and
this
is
true
for
you-
know
some
of
the
neat
cases,
but
it's
not
true
for
the
attestation
schemes
that
are
based
on
symmetry
crypto
like
mars,
like
certain
modes
of
dice,
certain
modes
of
psa
and
so
on.
C
Although
one
might
question
the
sanity
of
whoever
wants
to
to
deploy
submitter
keys
in
in
a
while,
but
anyway
those
things
exist
and
those
things
need
to
be
covered
by
by
the
architecture.
I
think
so
there's
some
editorial
work
to
do,
because
these
things
trickles
through
a
few
sections
of
the
document
and
yeah.
A
That
actually,
the
the
use
of
trust
anchor
is
very
scoped
in
the
document.
It
is
in
the
trust
model,
basically
with
the
relying
party,
and
then
it's
complement
the
verifier
here
and
then
it
is
tied
together
in
how
to
protect
the
trust
anchor.
So
they're,
actually
only
three
subsections
really
involved
in
all
the
terminology
issue.
I
think
so.
Editorial-Wise
we
are
in
a
good
space.
It
could
be
worse
way,
worse,
yeah.
C
B
B
G
B
H
B
C
B
B
C
H
B
Yeah,
so
this
is
the
main
section
I
think
you're
that
you're
the
last
sentence
of
that
one
so
as
defined
it.
I
think
that
one
is
fine
or
says
in
the
last
sentence
that
the
trust
anchor
may
be
a
certificate
or
it
may
be
a
raw
public
key.
I
think
that
sentence
would
you'd
want
to
augment
that
one.
The
trust
anchor
could
also
be
a
symmetric
key.
B
G
B
So
I
don't
think
it's
that
difficult
here.
I
think
you're
right,
it's
just
editorial
she's,
getting
the
right
text
added,
because
I
think
the
it's
fine
for
the
paragraph
to
begin
with,
as
divided
in
6024
right
and
then
augment
that
to
say
in
addition
to
the
coverage
in
6024
in
various
cases
today
right.
The
trust
anchor
could
also
be
a
symmetric
key.
Something
like
that.
So
yeah.
F
C
B
B
B
I
B
A
B
It's
my
preference
right
now
would
be
if
it's,
if
people
can
grumble
grumble
or
grumble
live
with
it,
then
it's
probably
not
worth
changes,
but,
like
thomas's
point
was
there's
something
that
just
doesn't
work
for
some
cases.
Right,
including
you
know,
I
think
psa
you
mentioned
right,
so
I
I
get
why
the
other
one
is
is
necessary.
So,
okay.
A
Yeah,
so
you
can
move
on
with
this
proposals
will
be
give
you
by
other
editors
and
volunteers,
of
course,
and
thank
you
already
for
that
beforehand,
and
so
you
can
assign
me
as
a
review.
I
will
look
at
it,
so
I
promise
because
I'm
on
vacation
I
just
have
kids
to
go,
which
is
a
delight
quite
the
rest
of
the
year.
So
having
addressed
the
trust
anchor
issue,
the
the
actual
literature.
B
B
A
E
A
B
Which
I
agree
with,
that
is
the
general
rule,
and
I
guess
I
I
am
slightly
biased
by
the
discussion
in
suit,
since
I'm
one
of
the
chairs
of
that
one
where,
in
the
suit
architecture
document,
unlike
the
rats
architecture
document,
the
suit
working
group
explicitly
chose
to
never
use
the
term
word
of
trust.
It
only
uses
the
term
trust
anchor
and
is
always
very
specific,
and
maybe
thomas
f's
issue
on
trust
anchor
might
appear,
might
applaud
that
one
too
if
anybody
uses
symmetric
keys
with
software
updates.
B
But
I
I
was
convinced
by
the
suit
argument
that
root
of
trust
means
lots
of
things
to
different
people
and
it's
not
an
ietf
term
per
se.
It
comes
from
various
other
places
and
so
suit
shows
to
just
not
use
the
term
at
all,
and
so
that's
my
bias,
and
so
that's
why
I
agree
with
thanksgiving
summary
there
so
now
root
of
trust.
We
do
use
in
the
rats
architecture
as
a
carefully
crafted
consensus.
A
Yeah,
that's
where
we
are
at
the
moment.
That
is
the
problem,
so
so
michael
also
has
some
strong
feelings
about
putting
some
words
in
here
and
I've.
I've
read
on
the
list
like
like,
like
like
a
middle
layer
of
of
root
of
trust
definition.
I
think
the
term
was
root
of
trust
for
attestation
and
then,
of
course,
ned
sprang
the
typical
trap.
That
is,
of
course,
there
are
a
lot
of
subclasses
of
these
roots
in
in
for
remote
station,
naturally,
and
so.
K
A
There
was
one
there
was
one
story.
Let
me
just
quickly
finish
that
there
was
one
proposal
that
I
think
came
relatively
close
to
something
I
would
be
okay
with,
but
that
was
would
unsettle
or
unrest
the
the
the
peace.
That
is
the
current
agreement.
We
just
used
the
term
but
not
define
it,
but
there
was
someone
correcting
me
and
saying
yeah,
but
it's
not
the
intended
one
and
there
was
a
counter
proposal.
I
think
it
was
from
lawrence
or
from
jeremy.
I
actually
don't
know
anymore,
and
so
so
that
one
was
close.
I
A
I
B
I
I
A
B
A
A
A
We
have
to
say
that
there
is
a
there's,
a
thing
that
enough.
If
I
find
a
synonym
for
roots,
because
I
would
say
rooting,
that
is
the
basis
for
trust,
assumption
trust
relationships
that
is
implemented
in
a
device,
and
at
that
point
people
would
like
ask
me:
you
are
talking
about
the
root
of
trust,
right
and
and.
M
B
You
know
the
secure
boot
scenario
and
so
on
without
ever
using
the
terminative
trash
which
it
did.
Okay,
so
I
think
the
fact
that
it
means
it's
that
I
I
believe
that
it
is
possible
to
do
okay.
Secondly,
I
think
the
root
of
trust
itself
is
confusing
in
the
sense
that
that
ira
mentioned
so,
for
example,
once
you
have
endorsements,
then
the
trust
anchor
in
your
trust
anchor
store
is
not
anything
that
is
device
specific
right.
B
A
B
L
A
A
B
Root
of
trust
is
confusing
for
two
reasons:
right
one
is,
it
always
has
to
be
qualified,
as
thomas
h
is
pointing
out
in
the
chat
right,
he
would-
and
I
think
that
was
in
one
of
the
messages
you
were
responding
to
hank,
because
I
didn't
see
a
note
about
that
and
the
other
one
is
the
fact
that
root
is
not
really
a
trust,
anchor
or
may
or
may
not
be
a
trust
anchor,
and
it's
confusing
enough.
No.
D
I
Yes,
no,
I
know
if
so
one
has
a
chain
a
certificate
chain
or
a
chain
of
trust,
bad
term.
For
that
reason,
but
nonetheless
it
it
is
very
different
than
a
root
of
trust
which
myth
at
citu
iso
many
have
defined
for
many
years
to
be
a
small
piece
of
code
that
can
be
trusted,
partly
because
it
is
small
and
it's
extremely
carefully
vetted
and
you
know
verified
code,
because
otherwise
it
has
to
be
trusted
because
there's
nothing
behind
it.
It's
at
the
bottom
of
the
turtles
as.
A
It's
at
the
bottom
of
the
turtles
exactly,
and
that
is
the
difference.
That
is
the
difference,
the
bottle.
When
we
talk
about
remote
attestation,
I
think
a
very
essential
part-
and
each
I
think
is
this
is
showing
that
is
the
evidence
created
by
the
system
and
the
evidence.
Creation
generator
generation
of
evidence
is
based
on
a
blind
trust
and
that
blind
trust
is
put
through
the
root
turtle.
B
N
I
A
B
B
A
But
now
now
you
have,
you
have
key
software.
You
have
one
private
key
that
lives
up
in
the
sky
at
some
ca,
and
that
is
your
trust
anchor
and
then
you
have
a
the
effective
one
right.
If
that
secret
is
gone,
your
trust
anchor
is
gone
right
and
then
you
have
one
secret
key.
That
is
the
other
end
of
this
certification
path
and
that
is
rooted
in
the
device
by
a
protected
capability
and
that's
your
route
of
trust.
So
if
two
ends
here,
one
of
them.
G
A
For
the
evidence,
wait
for
it
we're
just
starting
the
signing
of
the
evidence
that
is
at
the
low
level
here,
or
it's
derived
in
dice
states
down
to
this
level.
Okay,
but
the
other
one
is
in
the
the
sky,
the
bureaucracy
where
you
do
the
ca
stuff.
So
these
are
the
two
ends
and
just
highlighting
one
end
is
just
like
the
other
is
simply
wrong.
B
I
agree
with
a
couple
of
your
points
and
disagree
with
a
couple
of
your
points:
okay,
the
fact
that
there
is
exactly
two
ends
I
disagree
with
once
you
have
composite
devices
the
multiple
processors
and
line
cards
and
networks
in
between
them.
Then
your
layers
can
and
be
across
multiple
chips
and
multiple
depending
right,
and
so
my
point.
B
A
B
B
B
Every
use
of
I
should
say
I
don't
want
every
many
uses,
at
least
at
the
bottom
of
the
chain
of
of
a
testing
environment
to
target
environment
can
be
cross
processor,
and
so
that
means
that
it's
not
just
binaries
might
be
employed.
So
that's
one
of
the
points
I
want
to
make.
There
was
another
one
too,
and
I
forgot
what
it
was
absolutely.
B
A
B
Okay,
exactly
and
this-
and
if
you
say
every
a
testing
environment,
or
at
least
many
of
them
are
roots
of
trust,
all
the
ones
that
have
a
hardware
component
and
maybe
even
some
with
a
software
component.
You
might
consider
roots
of
trust
depending
on
your
definition
right,
because
it's
a
fuzzy
definition
and
people
debate
about
it.
Yeah.
G
B
In
my
opinion,
it's
since
ira
gave
me
permission
of
getting
in
my
soapbox
for
a
second,
the
most
it's
safe
to
do
is,
if
you're,
going
to
reference
a
specific
document,
you
can
say
in
a
block
context.
This
term
is
used.
Is
this
is
the
same?
What
we're
talking
about
here
an
example
is
the
root
of
trust
for
blah
in
the
following
scenario:
right
where
it's
a
very
narrow
statement.
A
A
I'm
fine
with
that.
Then
the
connection
to
the
outside
world
is
established.
People
who
really
obsess
on
the
rule
of
trust
things,
and
there
are
a
lot
of
these
sorry.
They
will
find
a
connection
to
this
document.
That's
what
I
think
is
important
for
the
for
the
strategy
value
of
this
document
that
people
can
relate
to
it
and
they
can't
understand
how
this
works
and
and
but
but
but
we
don't
have
to
do
it
all
over
the
place.
A
We
can
do
it
in
one
specific
place
with
a
good
reference,
and
I
think-
and
that
was
one
of
the
examples
net
raised
on
the
email
thread-
was
the
root
of
trust
reporting,
I
think,
is
the
most
obvious
one,
because
that
is
creating
the
evidence
and
so
so
going
for
that
one
as
an
example
and
saying
this
is
how
it
works
and
then
stay
off
that
and
maybe
tying
that
definition
to
the
testing
environment
definition
somewhere.
I'm
happy
with
that
that
we
can
remove
the
other
occurrences
so.
J
Root
of
trust
for
attestation,
just
because
I
wanted
to
distinguish
it
from
general
notion
of
roots
of
trust,
so
that
was
only
conditional
if
on
the
idea
that
we
were
actually
going
to
use
the
term
root
of
trust
throughout
the
documents
I
I
I
and
I
I
really
lined
up
with
dave
and
actually
hank's
last
comment
where
we
don't
use
the
term
and
you
know,
but
maybe
reference
it
as
an
example.
You
know
once
or
twice
so
I
I
think,
I'm
basically,
you
know
agreeing
with
everything.
J
J
A
I
The
issue
was
really
on
trust
anchor,
which
we
realized
and,
in
the
early
part
of
the
conversation,
we
agreed
that
trust
anchor
was
the
topic
not
root
of
trust,
not
withstanding.
The
email
threads
and
I
suggested
and
dave
chimed
in
and
said.
Okay,
then
I'll
speak
up
and
others
now,
I
think,
have
chimed
in
saying:
let's
just
remove
the
use
of
root
of
trust,
completely
normatively
and
have
one
or
two
informative
out
references
to
an
sp
800
document,
for
instance,
of
a
particular
route
of
trust.
A
All
agree
on
how
this
you
can
create
evidence
with
that
is
very
useful,
but
this
is
an
example.
The
important
thing
is,
we
have
two
environments,
one
that
they're
testing
that
so
so
I
think
with
that
way,
we
could
resolve
the
let's
call
it
contentious
use
of
the
term,
but
still
connect
to
the
people
that
feel
it's
very
important
to
their
work.
A
K
Let
me
check
that.
I
think
you
know
to
replay
some
of
the
conversation
in
the
past.
We
had
discussion
around
no
around
the
separation
of
of
we
had
discussion
around
hey,
you
can't
check
yourself
and
so
exactly
ended
up
with
the
testing
environment
and
the
target
environment,
which
is,
I
think,
that's
fine,
addresses
it
and
then
again
again
the
layering
and
the
layering.
So
so
in
some
context,
every
in
every
example
of
a
testing
environment
target
environment
is
a
layering
example.
K
You
could
have
you
know
more
more
layering
than
that,
and
the
question
then
is
around:
how
do
you
establish
trust
in
the
testing
environment
and,
if
there's
more
than
one
where
there
then
then
that
sort
of
becomes
the
de
facto
root
of
trust?
You
don't
have
to
use
the
term,
but
but
the
conversation
should
be
around.
How
do
you
establish
trust
in
the
bottom
turtle?
Essentially
yeah,
and
and
that's
where
the
endorsement
and
and
so
forth
comes
in
so.
A
A
I'm
not
agreeing
with
every
everything
in
there,
but
I
think
it's
good.
They
have
bootstrapped
roots
because
you
know
layering
and
such
so
they
have
the
concept,
actually
they
just
name
it
differently,
and
so
so.
For
this,
I
would
would
like
to
have
a
bouquet
of
references,
which
is
the
nist
document,
which
is
the
global
platform
document
and
which
is
the
glossary
of
the
tcg,
and
then
we
can
say
this
is
this:
is
we
could
even
state?
This
is
difficult
to
run,
and
that's
that
specific
realm,
where
we
just
say
rule
of
trust.
A
Once
we
can
say
this
is
difficult,
but
in
essence
what
we,
what
we
can
derive
from
all
these
definitions
and
that's
our
own
conclusion
in
the
document-
that's
informational-
is
that
a
root
of
trust
cannot
create
evidence
about
itself.
It
has
to
be
endorsed
from
the
outside
and
it's
somehow
the
start
of
it
in
a
device
when
you
want
to
build
up
the
evidence
that
is
consumable
by
verifier,
and
if
you
go
with
that,
I'm
also
fine
with
that.
A
A
No,
I
think
I
think
the
last
the
next
I
I
is,
I
think
tomorrow
or
next
day
the
first
day
so
this
week
and
then
they
are
done
and
then
there
will
be
nothing
behind
nothing.
So
when
we
go
into
the
christmas
zombie
mode
and
I'm
absolutely
fine
with
with
going
into
this
video
innovated
in
january
and
then
waiting
for
a
pull
request,
then,
and
then
we
can
do
the
battles
on
on
tiny
words.
Then.
B
I
I
I
You
care
about
the
integrity
of
the
virtual
machine,
which
is
the
only
thing
it
knows
about,
and
those
are
much
more
commonly
a
an
application.
The
iab
model
call
last
week
was
all
about
the
fact
that
attestation
is
about
applications,
maybe
privileged
applications.
You
know
privileged
services,
but
but
it
is
not
about
devices
very
often,
and
the
extremely
heavy
focus
in
rats
architecture
on
device
is,
I
think,
going
to
get
pushback
in
the
course
of
ietf.
A
I
A
Can
be
a
service
and
a
lot
of
things
here
will
be
services.
I
I
grant
that,
and
some
are
functions
that
are
called
on
some
apps,
and
that
is
fine,
but
all
of
these
would
fall
under
a
system
component
that
is
covered
by
rfc
4949.
The
problem
with
entity
is
that
a
system
entity
can
be
a
person
or
an
organization
yep.
I
don't
want
to
conflate
that
that
is
a
hard
no
for
me,
because
I'm
an
entity
and
my
manufacturers
were
my
parents,
and
they
have
nothing
to
do
with
this,
which
is
my
go-to
example.
K
I
A
E
A
Yeah,
that
is
where
the
endorser
owner
and
the
relying
party
owner
come
into
play.
They
can
have
our
other
roles
here
assigned.
I
think-
and
I
think
these
are
the
responsible
parties
that
are
humans
and
so
so
the
dorsal
it
has
some
responsibility
for
me
being
how
I
am
and
how
I
behave
and-
and
so
so
I
guess
that's,
that's.
That's
the
upper
bureaucracy.
Again,
I
think
that's
on
the
endorsement
and
and
the
the
party
owner
a
level.
K
A
J
Yeah
yeah
I
mean
I
I
the
question
I
wouldn't
wanted
to
ask:
is
you
know,
is
there
really
a
strong
objection
to
entity?
I
I
I'm.
I
mean
I
picked
it
because
I
thought
it
was
a
good
word
and
that
was
long
before
any
of
this.
You
know,
I
knew
any
of
you
guys.
Actually
I
I
personally
I'm
okay
with
entity
and
then
you
know
and
I'd
like
to
stick
with
the
term
entity,
particularly
you
know
in
in
the
eat
document.
Since.
B
G
B
Sense
for
rats
purposes,
system
component
is
actually
a
much
better
term
than
entity
and
entity
is
not
really
well
supported
in
the
rats
context
in
the
4949
sense
and
so
yeah.
If
that
means
that
each
is
problematic,
that
means
each
is
problematic
or
not
right.
That's
the
debate,
but
I
think
the
rats
architecture.
I
think
I
did
not
have
a
problem
with
device,
but
I
read
just
now
right
through
the
definition
that
hank
was
playing
to
a
system
component,
and
I
would
have
no
objection
for
that
one.
I
G
I
A
I
thank
you
for
bringing
that
up.
That
is
a
good
connection,
because
we
will
be
fueled
by
people
who
have
to
explicitly
sign
and
endorse
and
reference
value-esque
things
that
our
software
components
and
packages
do
to
the
executive
order.
So
rats
will
be
fueled
by
the
eo
in
the
very
short
term,
and
so
I
think
aligning
that
is,
I
think,
also
a
nice
thing
to
do
so.
A
Yeah,
I'm
all
about
removing
the
use
of
device,
and
maybe
we
can
just
establish
a
synonym
of
component
or
system
component
as
other
documents
do
and
then
and
then
go
from
there.
And
then
we
just
have
to
substitute
devices
component
and
then
have
also
this
realm
being
better
connected
to
us
because
believe
me,
s,
bomb
and
remote
attestation
will
be
a
have
a
close
relationship
in
the
long
run.
B
A
B
I
D
G
A
B
A
A
A
B
B
K
B
N
A
A
B
A
B
J
O
J
Got
two
different
ones
and
they
have
well,
let's
say:
have
three:
two
of
them
have
the
same
class
id
and
the
third
one
has
a
different
class
id.
What's
the
characteristic
that
tells
me
that
that
third
one
should
have
a
different
different
class
id
and
the
characteristic
that
tells
me
that
those
two
should
have
the
same
class
id.
G
B
So,
first
before
I
get
to
that,
let
me
point
out
that,
since
each
you
can
have
multiple
claim
sets
where
you
have
a
different
claim
set
say
for
each
layer
or
for
each
part
of
a
composite
device
or
whatever
that
each
one
of
those
can
have
a
class
id
with
a
slightly
different
meaning
right.
You
could
have
a
class
id
for
the
hardware
and
a
class
id
for
the
firmware
and
a
class
id
for
the
software,
for
example
right
yeah,
yeah,
yeah,
okay.
B
So
as
long
as
we're
talking
about
stuff,
that's
in
the
same
category
right
so
let's
say
I
got
three
pieces
of
hardware
with
class
ids
and-
and
I
can
answer
your
question
there
and
three
pieces
of
software-
the
class,
ids
and
I'll
answer
your
question
there.
But
it's
a
different
answer:
right:
yeah,
yeah,
yeah,.
B
B
So
this
is
the
teep
architecture
document
and
I'm
just
going
to
point
out
a
phrase
or
two
here,
because
it's
in
some
parts
are
intentionally.
I
don't
know
vague,
isn't
the
right
term,
but
intentionally
worded
such
they
can
be
used,
multiple
ways
right
to
have
to
maximize
the
use
cases,
and
so
I'm
going
to
elaborate
on
at
least
some
some
of
my
thoughts
on
the
language.
That's
in
here.
B
B
B
B
So
this
is
where
it
talks
about
the
unique
device
at
a
time
right.
This
is
not
class
id
right.
It
may
be
used
to
uniquely
identify
the
device
to
a
tam.
In
some
cases,
the
privacy
device
identification
will
vary
with
a
type
of
ta
provision
of
the
te
the
sentence
I
was
looking
for
had
to
do
with
the
purpose
of
attestation.
Maybe
the
word
purpose
was
there.
B
Okay
yeah
here
it
is
here's
the
sentence,
I'm
looking
for.
Okay,
antique,
the
primary
purpose
of
an
attestation
is
to
system
component,
the
attester
to
prove
or
a
system
the
attester
to
prove
to
a
tam.
The
relying
party
the
t
in
the
device
has
particular
properties
was
built
by
a
particular
manufacturer
and
or
is
executing
a
particular
ta
right.
So
this
is
an
interesting
phrase
right
here
that
gets
to
your
main
question
there,
because.
B
B
Thing
I'll
elaborate
on
that
in
just
a
second:
that's
the
main
point
I'm
getting
too
okay,
so
this
includes
version
identifying
information
for
hardware
firmware
and
software
versus
applicable
by
the
te
type
again.
There's
that
phrase
here,
the
manufacturer
information
for
the
te
is
required.
Okay,
so
we
know
that
it
has
a
manufacturer
information,
but
manufactured
information
is
quite
the
same
thing
as
the
e-type
okay
and
it's
required
in
order
to
disambiguate
the
same
te
type
created
by
different
manufacturers.
B
Okay,
okay,
so
I'll
give
you
some
examples:
okay,
so
a
single
manufacturer
te
example
would
be
sgx.
Okay
or
intel
is
the
only
manufacturer
that
creates
sgx
and
sgx
is
done
purely
in
hardware,
although
there's
like
a
driver,
support,
that's
necessary
to
to
leverage
sgx
so
that
one's
a
fairly
simplistic
case.
B
No
there's
a
version
because
there's
sj
there's
actually
three
versions
of
sgx
there's
the
first
one
is
just
called
sgx.
The
third
one
is
called
sgx2
and
the
second
one
is
sgx
with
such.
I
can't
know
what
the
actual
term
is
and
that
isn't
in
the
call
anymore.
But
the
point
is
there's
actually
three
versions
of
the
hardware
that
have
additional
capabilities,
like
whether
you
can
support
authenticated
boot,
for
example,
is
something
that
is
only
in
sgx2
but
not
sgx.
You
can
only
do
measured
boot
for
sgx.
B
In
other
words,
you
can't
white
list
things
right
and
and
so
on
and
and
sgx
it
has.
It
will
only
launch
things
that
have
an
intel
signature
where
sgx2
it
has
a
layer
of
indirection
there.
Where
you
can
say
what
is
the
key
that
things
have
to
be
signed
with,
and
then
it
will
launch
anything
with
that
sign
with
that
key
anything
that's
been
signed
by
that
signer
or
sgx1,
the
signer
had
to
be
intel.
B
So
even
though
there's
three
different
versions,
you
don't
need
three
different
class
ids
or
anything
like
that
right.
You
only
need
one
okay.
So
a
more
complicated
case,
though,
is
the
way
that
trust
zone
works.
Okay,
where
trust
zone
by
itself
is
the
hardware
capability,
but
by
itself
it
isn't
the
tee.
B
The
te
is
the
chip
plus
the
piece
of
firmware
that
goes
on
top
of
it,
okay
and
which
there,
since
there
can
be
multiple
manufacturers
of
trust
zone
right
because
arm
just
sells
the
design
and
different
manufacturers
build
the
chips
so
like
the
chip
might
be
from
nxp
with
an
arm
certified
design
and
there's
multiple
vendors
there.
So
the
manufacturer
id
in
this
case
are
the
nxp
not
arm
okay,
and
so
you
need
something
to
say:
okay.
B
Trustee,
I
think,
is
the
one
that
google
uses
in
android,
and
so
those
are
the
top
two
is
opti
and
trustee,
and
if
you're
creating
an
application
to
run
on
those
you
gotta
know
is,
it
is,
is
it
this
is
designed
for
opt
or
is
this
designed
for
trustee
when
I,
and
so
in
an
attestation
you'd
want
to
say
well,
my
tea
is
of
this
type.
Now,
maybe
you
could
do
that
by
saying.
B
Opti
and
trustee
have
a
separate,
coswood,
okay
on
top
of
trust
zone
as
the
hardware
part
and
that's
up
to
the
vendor
or
arm
or
somebody
else.
That
does
a
profile
to
say.
What's
the
actual
te
type
for
what
you're
supposed
to
decide?
What's
the
actual
class
id
that
you
want
to
use
for
trust
zone?
Is
it
is
the
class
id
something
identifies
op
to
yours?
Is
the
class
80,
something
that
only
identifies
trust
zone
right?
B
The
more
obvious
thing
here
is:
probably
it
just
identifies
trust
zone,
but
this
is
a
point
of
something
that
the
profile
would
be
responsible
for
not
eat
right,
you're,
just
creating
a
space,
and
then
somebody
that
defines
the
number
in
the
space
says:
here's
what
that
number
means
right
right
now.
I
could
be
wrong,
but
my
expectation
is
use
a
coswood
for
for
the
trustee
versus
opti
they'll
have
separate
coswoods,
but
the
te
type
here
cross
vendor
the
class
id
would
be
trust
zone.
B
That's
my
personal
guess
right
now,
I'm
just
trying
to
give
you
some
flavor
of
things
that
you'd
be
able
to
use
it
for
because
options
can
work
on
any
trust
zone
right.
There's
different
chip
manufacturers,
sir,
but
they're
all
going
to
be
the
same
because
they
have
all
applied
all
comply
to
the
same
official
arm.
Spec
for
for
va
to
the
architecture,
for
example,.
J
J
B
Happens
is
the
the
the
relying
party
here
in
the
teep
scenario.
The
relying
party
is
the
entity
that
is
going
to
push
down
a
software
or
firmware
update
to
a
system.
Okay,
and
so
the
attestation
is
going
to
say,
are
you
healthy
or
not?
Here's
the
current
state
right
and
the
desired
state
if
it
doesn't
match
it
during
verification.
B
If
it
doesn't,
then
the
job
of
the
airline
party
is
in
fact
to
do
the
remediation.
So
he's
going
to
kick
off
the
remediation
and
he's
going
to
use
the
attestation
information
to
say
what
is
it?
That's
part,
that's
out
of
compliance
right
now
and
those
are
the
parts
that
I'm
gonna
push
on,
updates
to
it's
either
running
their
older
version
or
it's
missing
a
piece
or
there's
now
a
new
piece,
because
the
desired
state
has
changed
to
have
some
new
component
in
it.
B
Then
I
need
to
push
down
some
some
new
piece
of
software
or
firmware
that
wasn't
that
in
this
case,
to
be
software
right,
new
piece
of
software
that
wasn't
there
before
so
I
may
have
to
rev
the
firmware,
and
so
it's
really
the
information
that
would
be
in
the
attestation
results
right,
which
might
be
copied
out
of
the
evidence
or
derived
from
the
evidence
where
the
relying
party
is
going
to
use.
That
is
a
key
to
say:
okay,
here's
the
types
of
software
firmware.
B
I
need
to
push
down
and
install
on
the
device
or
rev
on
the
device.
Sorry,
the
system,
and
so
that's
what
it's
used
for
and
a
piece
of
information
that
you
have
to
have
in
order
to
push
down
the
right
piece
of
software
or
firmware
is
in
fact
this.
You
know
te
type
right.
I
can
generate
the
new
version
of
opti
if
I
know
that
your
trust
zone,
regardless
of
manufacture
that
type
of
thing.
B
B
J
J
J
J
So
if
you
want
to
identify
a
piece
of
hardware,
you
have
the
the
you
know
you're
going
to
have
an
oem
id,
then
you
probably
have
a
class
id,
which
is
the
model
and
you
could
you
may
or
may
not
have
a
version,
but
that
model
number
the
class
id
is
definitely
qualified
by
the
oem
ide
in
in
this.
In
this
particular
design.
B
B
Risk
five
right
because
it's
it's
an
open
source
heart,
it's
an
open
hardware,
design
that
anybody
can
conform
to,
and
so
there's
things
like,
tes
or
other
pieces
of
software,
or
not
to
use
being
designed
for
risk
five,
as
long
as
it
meets
the
specs.
So
it's
going
to
follow
the
same
type
of
ecosystem
that
arm
uses.
It
just
happens
to
be
a
consortium
that
owns
it
rather
than
a
single
company
that
owns
the
the
reference
architecture.
So.
B
J
A
The
amount
of
class
differentiation
will
grow,
yes,
people
will
have,
the
classes
will
be
be
more
aligned
to
capabilities
and
I
would
like
to
say
protected
capabilities
more
than
design
principles
over
the
years,
so
so
looking
into
the
future.
Today
we
were
talking
about
trustee
and
opti
and
and
and
case
for
enclaves
and
such
but
but
in
the
end
it
will
end
up
what
what?
B
Class
id
is
on
a
per
claim
set
basis
and
in
some
cases
you'll
have
a
different
claim
set
for
your
te
versus
your
non-te
right.
There
are
some
architectures
and
so
on
and
so
class
id
you'll
have
multiple
of
multiple
class
ids
per
evidence
right,
because
you'll
have
one
for
each
claim
set
right.
I
think
layer,
documentation.
G
B
G
B
Can
actually
rev
the
firmware
over
time,
and
so
you
can
change
class
ids
over
time
and
the
firmware
apart,
but
not
for
the
hardware
part.
And
so
that's
why
it's
up
to
the
profile
to
define
the
meetings
of
values
and
stuff
as
long
as
there's
a
way
to
to
express
it
in
a
claim
set,
which
is
all
the
requests
work.
B
J
B
G
B
Not
it
doesn't
have
to
be
in
rats
that
can
be
in
teep
as
long
as
the
heat
can
accommodate
that,
and
specifically
the
use
case
that
we
know
of
that
you'd
use.
Class
ids,
for
is,
for
the
hardware
level,
where
you
have
multiple
menu.
Multiple
hardware
oems
that
all
conform
to
the
same
spec.
That
upper
layers
depend
on.
J
A
A
B
Okay
and
then
that
allows
the
t
profile
to
say:
okay
should
qt
versus
trustee
versus
opti.
Should
those
be
class
ids
or
should
those
be
coswoods,
that's
the
discussion
that
should
happen
antique
when
doing
it
and
doing
the
rats
profile,
yeah,
okay,
but
we're
not
gonna.
We
really
don't
want
to
have
that
discussion
when
saying
okay
trust
zone
versus
whatever
risk
five
calls
it
you
know
keystone
or
whatever,
there's
a
name
for
it
and
so
on.