►
From YouTube: RATS Architecture Design Team, 2020-01-14
Description
RATS Architecture Design Team, 2020-01-14
A
A
C
E
E
E
B
B
E
G
D
So
this
is
monty,
so
measure
does
measure
the
way
we've
defined
it
in
tcg
measure
and
before
that,
tcpa
measure
doesn't
define,
doesn't
create
an
assertion.
It's
simply
the
equivalent
of
making
an
entry
in
an
auto
log.
The
assertion
of
the
autolog
is
somebody
signs
it.
Somebody
looks
at
it.
Somebody
has
some
proof
that
it's.
F
D
G
D
G
D
C
D
Yeah
now
the
the
the
one
thing
that
has
that
we've
had
a
hard
time
with
in
tcg
is,
does
measure
encompass
the
just
focusing
on
hash
the
implementation.
I'll
say
the
is,
is
measurement
just
simply
the
process
of
creating
the
or
use
the
term
identity
thumb
print
whatever
using
the
hash
is
one
of
them,
or
is
it
a
kind
of
a
set
of
operations
where
you
create
the
identity
of
the
module?
D
You
extend
it
into
something
record.
It
you'll
see
I'll
use.
The
word
record
instead
of
extend
to
that
extent
as
a
particular
operation,
you
record
that
that
identity
and
then
you
make
an
entry
potentially
into
a
log
somewhere.
It's
a
very
tcg
centric
sequence,
but
does
the
term
measurement
just
simply
mean
the
creation
of
the
identity
that
can
be
put
somewhere
or
is
the
definition
of
measurement
creation
of
the
identity?
D
D
F
G
D
F
D
I
think
that
we
ought
to
have
a
term
that
applies
like,
for
example,
we
can
measure
you
just
using
the
term
assuming
we
accept
it.
We
can
measure
the
the
bio
settings
so
basically
in
bitmap,
for
example,
of
whether
usb
ports
are
turned
on
and
stuff
like
that
right,
that's
not
really
a
component,
that's
not
an
identity
right,
so,
in
which
case
my
term,
my
use
of
the
term
identity
was
incorrect
for
measuring
things
like
that
and
location
is
certainly
one
of
them.
D
D
D
C
We
already
have
that
yeah,
so
I
yeah
I,
like
the
terms
collector.
What
was
the
other
one
that
you
mentioned
record
collector
record,
I
think,
are
as
good
as
measure
I'm
okay
with
any
of
those
three
okay,
a
record.
I,
I
think,
collect
and
record
are
probably
closer
to
layman's
speak
than
measure.
So
that's
why
I
kind
of
like
either
of
those.
D
H
D
D
G
E
C
E
I
I
agree
it
doesn't
occur.
That
was
the
question
whether
or
not
we
wanted
to
introduce
the
term.
I'm
just
saying
that
I
don't
think
we've
I
don't
think
record
or
collect
is
acting
the
same
way
that
measure
measurement
is
oh,
I
guess
it's
acting
the
same
way
as
a
measure,
but
not
measurement
correct.
C
Correct
and
so
right,
I'm
all
in
favor
of
not
adding
more
terms
and
trying
to
keep
the
number
of
terms
minimal,
and
so
that's
why,
between
measurement,
I'm
trying
to
find
ways
to
just
use.
The
word
claims
with
appropriate
claim,
with
appropriate
wording,
rather
than
measurement
to
see
if
it's
possible,
to
only
use
the
term
claim,
rather
than
using
both
claim
and
measurement.
C
B
Yeah,
this
is
my
problem,
because
claims
are
not
only
key
value
pairs,
they
are
key
value
games
in
cfd
and
jwt.
They
are
not
key
value
pairs
in
x549
certificates
and
there
we
will
also
have
the
claims.
All
the
things
we
collect
or
measure
or
record
are
in
somewhere,
and
these
are
the
general
term
was
assertion,
and
then
we
agreed
on
hijacking
the
data
model
term
claim
for
our
abstract
architecture,
but.
A
B
B
Yeah,
okay,
so,
but
still
in
theory,
you
could
just
emit
keys
if
you
have
very
static
structures
in,
I
don't
know
a
solution
protocol
and
still
have
all
the
values
without
any
keys
have
their
meaning
because
of
ordering
and
still
convey
the
same
information.
I
I
don't
think
we
won't
force
anyone
to
use
keys
here
and
again.
This
is
a
data
model
construct
and
we
are
not
using
it
in
that
way.
We
are
just
assuming.
A
B
H
H
B
C
B
B
B
B
H
B
It's
as
simple
as
that,
I
think
lawrence
exactly
that,
but
we
have
to
spell
it
out
at
least
once
somewhere.
Otherwise
this
would
people
who
are
used
to
just
such
as
implementing,
and
this
is
the
problem
here.
I
heard
that
this
document
will
be
read
by
implementers
directly.
This
is
what's
one
notion
on
the
list
and
then.
H
B
H
B
E
H
C
I
think
there
was
an
argument
that
we
should
actually
have
a
definition
of
claim.
That
explains
our
generic
sense,
and
maybe
with
a
note
that
says
that
that
explains
you
know,
depending
on
how
claims
are
encoded,
the
semantic
meaning
may
be
implied
or
denoted
or
indicated
by
virtue
of
having
a
name
or
id.
C
C
B
C
E
C
C
E
E
C
A
E
C
G
F
And-
and
this
is
elliot
one
of
the
things
that
we
end
up-
I
think
you're
exactly
right,
david
in
that.
If
you
start
talking
about
how
the
tee
is
going
to
validate
everything,
that's
on
board
exactly
how
that
happens
is
going
to
be
probably
somewhat
implementation
specific
and
we
can
get
into
great
details
that
people
will
sit
there
and
bicker
over
yes,.
F
On
the
other
hand,
I
do
think
it's
probably
useful
to
highlight
that
that
is
an
interesting
area
for
for
for
further
work
to
to
document
precisely
those
sorts
of
issues
how
you
do
those
proofs
on
on
a
platform
by
platform
basis.
I
think
it's
useful
to
at
least
say
that
somewhere
in
the
document,
so
that
gives
me
the
future
work.
B
H
A
No,
no,
it's
not
it's.
A
qualcomm
announced
something
called
the
secure
processor
unit
last
year
and
it's
actually
integrated
even
better
than
I
mean
it's
even
more
tightly
coupled
to
the
system
on
chip
than
it
embedded
and
it's
and
it
has
all
the
capabilities
of
the
of
the
sim
card
that
a
sim
card
would
today
or
an
nfc
secure
element.
It
is
not
a
tpm.
G
C
A
I
C
C
G
C
A
C
But
it's
typically
not
programmable.
The
invented
sim
is
or
embedded
secure
element
is
a
separate
chip
that
is
programmable
with
like
a
java
outlet
and
classic
tvs
like
trust
on
sgx
are
on
the
main
processor.
So
that's
why
there's
three
separate
classes
of
things
but
they're
all
security-hardened
things,
somebody's.
A
I
C
B
H
C
C
A
I
certainly
agree
with
the
ideas
that
that
we
have
nested
environments.
It
might
be
worth
what
hank
says
to
go
ahead
and
have
a
section
here,
and
this
might
be
a
place
where
we
could
talk
about
the
tpm
without
having
to
to
go
ahead
and
hit
the
other
later
section
talking
about
the
testing
environment
there,
because
I
do
think
that
there's
value
since
there's
a
lot
of
people
who
care
about
that
environment
of
explaining
a
way
that
it
could
be
used.
With
these
terms,
I.
F
C
C
Yeah,
I
think
that's
good.
I
want
to
tie.
I
think
we
have
three
different
related
things.
I
think
there's
this
pr,
which
tries
to
concentrate
on
filling
out
the
definitions
of
a
testing
environment,
target
environment,
whatever
terms
that
we
use
and
then
there's
williams,
pr
that
we
talked
about
last
time
that
I
see
he
just
did
another
commit
to
that.
I
haven't
read
yet,
which
was
about
the
sub
environments
and
so
on,
and
then
there's
hank
and
hank's
point
here
about.
C
I
think
it's
fine
to
treat
those
as
three
different
prs
and
saying
there's
a
generic
one
and
then
maybe
there's
a
layered
specific
extension
as
a
separate
pr,
and
if
you
want
to
take
the
action
item
on
that
one
and
create
and
change
this
paragraph
into
a
subsection
or
something
like
that
in
this
in
a
different
pr.
That
would
be
great.
J
C
J
J
J
C
B
I
F
C
A
A
That
works
for
me.
I
did
see
where
you
did
there
and
I
do
think
there
are
elements
that
could
be
comprised.
I
think
that
when
I
read
your
section
I
was
thinking
the
line
card
assembly
yeah
yeah,
so
yeah.
Let's,
let's
go
back
and
forth
on
that,
so
I'm
trying
not
to
step
on
it.
If
you
want
to
take
a
first
cut
at
the
texans,
you
already
delayed
stuff,
I'm
just
making
sure
it
gets
covered.
So
if
you
want
to
give
it
a
shot,
I
have
no
problem
with
it,
but.
C
Yeah
I'm
imagining
there
might
be,
I
mean,
feel
free
to
give
different
proposals,
but
I'm
imagining
that
underneath
this
section
there
might
be
two
following
subsections
of
this
section,
one
on
the
layered
part
that
maybe
eric
authors
and
then
one
on.
I
don't
know
what
the
right
term
is,
where
you
have
a
composite
device
section.
A
A
A
G
J
C
E
C
Device
one
which
is
related,
and
so
that's
what
I
was
saying
is.
I
think
this
one
should
become
whatever
the
result
of
this
one
is
because,
like
I
said,
I
have
not
reviewed
the
new
commit
that
happened
last
night
in
my
time
once
this
one
is
ready,
then
I
think
this
most
likely
belongs
as
a
subsection
immediately
following
the
pr
that
we
just
merged.
J
I
agree
with
that,
but,
but
I
have
one
thought
about
first,
I
have
actually
two
thoughts.
First.
Is
that
from
hank's
reply
to
my
comments,
I
think
I
think
this
can
be
a
part
of
the
layered
attestation
section
and
the
second
is
that
the
dead
flow
you
can,
you
can
see
the
I
update
the
date
flow
program.
You
can
you
can.
You
can
see
the
diagram
and
I
think
it's.
J
J
Because
you
know
in
the
diagram
and
the
verification
result
of
the
sub-
let's
just
say
subunits-
can
be
the
part
of
the
evidence.
So
this
can
result
in
the
young
module
of
testing
results
can
be
part
can
be
reused
in
the
module
of
evidence,
so
I
think
it
can
be
used
can
also
can
be
described
in
the
dataflow.
J
J
I
B
The
procedure
wise,
I
think
we
have
to
still
review
this
one
more
time
due
to
time
constraints.
I
guess
and
then
see
how
to
accept
this
into
the
document
for
the
two
through
things
here
they
are
the
composite
device
concept
in
general
and
then
there
is
a
specific
way
how
we
express
it
in
diagrams.
I
think
the
diagram
and
terminology.
G
F
B
I
don't
think
that
the
I
don't
know
if
the
new
pull
request
addresses
the
split
brain
two
diagrams
the
same
layer
would
have
different
terms
in
it,
if
so
cool.
If
so,
if
not,
we
still
have
to
do
that,
but
but
this
does
does
this
in
our
sequence,
procedure-wise,
do
we
have
to
resolve
the
complete
pull
request?
First,
before
we
start
a
section
on
device
composition
of
this,
be
the
seedling.
G
C
C
G
E
E
J
J
H
So
I
haven't
tracked
all
the
diagrams,
but
my
preference
is
that,
to
use
the
term
a
tester
for
the
the
smallest
most
atomic
tester
component,
to
use
the
term
aggregate,
a
tester
for
something
that
aggregates
more
than
one
a
tester.
So
in
this
diagram
I
would
change
subatester
b
and
subtester
b
to
just
be
a
tester,
and
then
I
would
have
would
put
a
box
around
all
of
it
and
call
it.
The
aggregate
attacher.
H
C
D
D
C
F
C
C
If
you
have
a
manufacturer
certificate
of
origin
for
a
particular
piece
of
hardware,
then
that's
an
example
of
what
you
just
said,
where
in
some
sense
the
manufacturer
is
testing
or
collecting
claims
about,
whatever
term
that
we
use
where
the
hardware
is
the
target
environment,
and
so
you
could
view
it
as
that.
If
you
chose
to
yeah.
D
C
C
J
A
A
G
The
idea
is,
there's
layering
within
a
single
component,
but
there
can
also
be
multiple
components
or
devices.
If
you're
doing
drill
down,
you
could
say
local
components,
one
of
those
components
drill
down
into
it.
There's
layering,
that's
where
you
get
the
target
and
the
testing
environment,
but
then
there
can
be
multiple
of
them
is
what
we're
saying
for
the
layering
all
right.
F
C
C
I
think
layering
and
composite
are
both
important
concepts
to
explain
here
and
it's
because
there's
a
one
of
the
things
that
the
working
group
has
talked
about
is
how
you
have
different
claim
sets
relate
to
each
other.
In
the
actual,
I
don't
know,
data
model
or
serialization
format,
right
and
being
able
to
motivate
the
architecture,
the
two
types
of
relationships
which
then
motivates
why
you
have
different
ways
of
encoding
things
in
the
encoding
format.
C
Right
right,
which
is
why
I
don't
want
all
the
possible
combinations
and
have
a
unified
diagram
that
shows
how
they
fit
together.
I
think
that
is
overkill,
but
just
motivating.
Why
there's
two
types
of
relationships
that
show
up
in
the
encoding
format.
I
think
that's
what
we
said
as
a
working
group
that
we
expected
there
to
be
something
in
the
architecture
document
that
motivated.
F
G
For
example,
should
be
fairly
clear:
the
bottom
half,
I
think,
there's
a
question
of
what
is
a
component.
Is
it
something
physical
or
is
it
just?
You
know
some
kind
of
a
software
layer
like
is
it
you
know,
so
I
think
there
are
different
software
modules
are
connected.
Together
is
a
question.
I
don't
know
if
that's
what
other
people
are
thinking.