►
From YouTube: RATS and SUIT WG Interim Meeting, 2022-01-26
Description
RATS and SUIT WG Interim Meeting, 2022-01-26
A
A
Need
identify
some
scribes.
B
So
this
is
saying
I
I
understand.
B
Be
here
because
this
is
at
least
fifty
percent
about
suit,
but
brandon
just
informed
me
that
he
will
be
late,
so
he
was
in
charge
of
slides,
I
scraped
the
slides
and,
as
I
thought
he
would
present
them.
I
now
propose
them
as
proposed
slide
to
the
data
tracker.
B
I
know
this
is
relatively
last
minute,
but
yeah
at
least
I
was
able
to
get
them
so
yeah
and
so.
A
B
That
yeah,
I
saw,
I
saw
the
tip
requirement.
So
if
you
start
with
that,
that's
fine
and
we
can
give
brandon
some
time
to
join
in
later.
I
just
wanted
to
highlight
that
the
slides,
brent
and
I
prepared
are
now
as
proposed,
slides
on
the
data
tracker
for
this
interim,
because
that
was
my
alternative
route.
B
D
D
Only
open
issues
are
left
yeah,
so
I
I.
D
The
the
10
a.m,
tuesday,
is
still
of
is
sort
of
available,
or
I
can
try
to
make
keep
it
available
for
me.
I
just
thought
I'd
ask
in
this,
since
many
of
us
are
here,
if
that's
a
okay
thing.
C
A
D
Well,
I
just
I
didn't
want
to
scribe
in
a
place
that
no
one
know
I'll
I'll
make
up
a
hedge
I'll
hedge.
It
off.
B
B
Which
is
hedgehog
now
and
yes,
there
should
be
one
I
found
it.
It
is
auto
generated
with
the
invite.
I
will.
B
B
G
Iutf
data
tracker,
page
of
all
the
intro
meetings
gets
to
that
link,
as
well
as
the
the
webex
link.
A
All
right,
so,
let's
get
started.
G
I
didn't
know
if
that
you,
as
the
chair,
wanted
to
put
up
a
note
well
or
something
slide.
First,.
B
There's
nothing
showing
yet
no
it's
something.
A
B
A
Another
thing:
okay,
so
just
a
reminder
by
participating
in
ietf,
you
agree
to
the
following:
itf
process
and
policies.
A
If
you're
aware
that
any
itf
contribution
is
covered
by
patents
or
patent
applications
that
are
owned
or
controlled
by
you
or
your
sponsor,
you
must
disclose
that
fact
or
not
participate
in
the
discussion
as
a
participant
in
or
attendee
to
any
ietf
activity.
You
acknowledge
that
written
audio,
video
and
photographic
records
of
the
meeting
may
be
made
public
personal
information
that
you
provide
to
ietf
will
be
handled
in
accordance
with
the
ietf
privacy
statement
as
a
participant
or
attend.
Do
you
agree
to
work
respectfully
with
other
participants?
A
Please
contact
the
buds
team
at
the
link.
If
you
have
questions
or
concerns
about
this.
H
B
A
G
E
G
All
right,
so
this
presentation
is
from
the
t
perspective
right,
because
really
we
have
three
different
working
groups
that
are
relevant
rats,
suit
and
teep,
and
so
this
one
is
from
the
t
perspective
and
I'm
hoping
that
brennan's,
slides
and
stuff
will
cover
from
the
suit
perspective,
which
is
in
some
sense
wider
than
than
teep.
But
here
I'm
gonna
be
quoting
out
of
the
teep
discussions.
G
Okay,
so
what
does
teep
require
as
opposed
to
what
other
cases
would
suit
require,
which
I
think
is
I'm
glad
to
hear
that
hank
and
brandon
have
slides
to
to
cover
that
part,
meaning
yeah
with
my
suit
chair
hat
on,
I
would
I
look
forward
to
that
discussion
too.
G
So,
all
right
so
from
a
tea
perspective-
and
I
see
we
have
nancy
as
a
chair-
and
I
see
hanus
is
one
of
the
co-authors
and
stuff
so
just
to
remind
people
about
teep
in
one
slide:
here's
the
relevant
parts
about
teep
and
one
slide.
G
Okay,
so,
first
of
all
the
suit
manifest
format
is
used
to
express
dependencies
and
reference.
You
know
firmware
software
updates
and
versions,
the
installation,
steps
and
so
on
so
t
depends
on
suit,
for
that
teep
is
a
protocol.
That's
used
for
remediation
when
attestation
fails
or
the
attestation.
The
reason
for
the
failure
is
seen
to
it
being
because
a
tee
or
trust
execution
environment
is
currently
out
of
compliance.
So
how
do
you
get
it
back
into
a
good
state?
G
And
the
answer
is
you
use
the
t
protocol
and
it's
kicked
off
as
a
result
of
attestation
failure,
okay,
and
so
it
needs
enough
information
on
the
attestation
failure,
or
at
least
in
the
evidence,
to
be
able
to
kick
off
what
the
right
remediation
steps
are.
Okay,
so
the
t
protocol
is
defined
to
use
eat
for
attestation.
G
Although
it
does
allow
extensions,
you
could
use
something
of
the
neat,
but
the
only
thing
that's
sort
of
standardized
is
the
use
of
eat
in
the
protocol,
and
it
uses
suit,
manifests
for
actually
doing
the
application
of
the
updates.
Okay,
and
so
the
teep
is
just
the
protocol
that
carries
the
suit
manifest,
because
soup
does
not
specify
a
protocol.
Teep
is
a
protocol
that
goes
between
a
tee
and
a
trusted
application
manager,
okay,
and
so
each
claims
are
then
used
in
the
teep
scenario
to
determine
which
suit
benefits
are
applicable
for
remediating
right.
G
So
how
does
the
trusted
application
manager
know
what
suit
manifest
to
push
down
to
say?
Hey,
you
need
to
apply
this
particular
thing
right,
and
so
it's
using
the
claims
and
the
attestation
attestation
fails.
I
use
the
claims
that
result
in
the
failure
and
I
use
that
to
select
which
manifest
or
set
of
manifest
then
push
down
into
the
into
the
tee
all
right.
So
this
notion
of
remediation
when
attestation
fails
is
not
specific
to
a
tee
right.
So
presumably
this
analogy
for
some
of
these
having
nothing
to
a
teeth.
G
It's
just
remediation
when
out
of
compliance
right,
if
you're
doing
it
with
like
the
kernel
or
your
bios,
or
something
like
that,
you
wouldn't
use
the
t
protocol,
but
you'll
see
that
there's
a
lot
of
the
same
needs
right,
but
I'm
only
going
to
talk
about
the
cheap
ones,
but
you
should
be
thinking
about,
and
I
think
I
have
one
bullet
somewhere
to
show
you
how
things
generalize
beyond
t
right,
because
the
claim
is
that
these
are
not
just
keep
requirements.
These
are
cheap
requirements,
but
they're
not
just
keep
requirements.
G
G
So
I
can
claim
that
there's
been
a
deep
working
group
consensus
for
quite
a
while
now
as
declared
by
nancy
and
her
co-chair,
and
it's
been
in
that
state
for
a
while.
I
think
it
just
went
through
ed
review
and
we
have
some
editorial
things
to
follow
up
on,
but
it
got
working
or
consensus
long
ago,
all
right,
so
I'm
going
to
walk
through
three
requirements,
of
which
my
opinion
is
that
two
of
the
two
of
those
requirements
are
relevant
to
this
discussion.
G
One
of
them
is
not,
but
for
our
completeness,
I'm
going
to
show
you
all
three
classes
of
requirements
and
because
there's
some
in
a
relationship,
I'd
rather
hold
questions
until
I've
shown
you
all
three
and
then
I'm
happy
to
go
back
and
do
it
with
them,
because
they're
they're
interrelated
right,
so
I'm
gonna
walk
through
them.
I
got
three
requirements.
One
slide
per
requirement
with
some
examples,
so
first
one
is
a
class
of
device.
Okay,
so
here's
the
actual
quote.
G
The
following
information
is
required
for
t
test
station
and
it's
in
this
paragraph
on
device
identifying
information
which
includes
some
other
things
too.
Beyond
this
requirement
right
things
like
unique
device:
identification,
okay.
Well,
that's
other
requirements,
they're
already
met
by
other
things
right
in
particular,
there's
the
bolded
sentence.
Okay,
and
so
this
is
how
do
I
know
that
this
is
all
in
the
context
of
how
do
I
know
which
suit
manifest
to
send
to
the
device?
G
Okay,
in
some
case
some
use
cases,
it
may
be
sufficient
to
identify
only
the
class
of
the
device
right,
not
the
unique
device
right,
because
I've
got
a
suit
manifest
not
per
device
but
for
dev
or
classic
device
right,
the
following
binary
or
installation
steps
or
whatever
are
relevant
to
all
the
machines.
That's
all
the
devices
that
meet
the
following
criteria,
or,
in
this
case,
all
the
tees
that
meet
the
following
criteria.
So
here's
a
couple
of
real
examples
that
are
not
in
the
document.
G
Okay,
what
are
things
that
have
come
up
in
discussions
or
whatever
to
tie
it
to
like
real
world
use
cases?
One
example
would
be.
You
have
an
sgx
enclave
library
that
runs
on
any
sgx2
capable
intel.
Processor
right
intel
has
lots
of
processors,
of
different
models
and
so
on,
and
this
is
a
capability
that
each
intel
processor
version
may
or
may
not
have,
and
so
this
sgx
library,
enclave
library,
is
dependent
on
intel,
okay
and
but
it's
not
dependent
on
any
particular
version
or
revision
of
things.
It's
anything
that
complies
with
the
sgx2
thing
now.
G
The
same
thing
could
be
true
of
any
other
processor
feature
beyond
the
te
use
case,
but
this
example
is
a
is
the
sgx2
processor
case,
and
this
is
an
example.
Unlike
the
other
requirements,
this
is
example
of
a
class
that
is
actually
within
a
particular
manufacturer
right,
so
some
intel
processors
support
sgx2,
some,
don't
you
can
there's
a
little
more
wider
one.
Some
intel
processors
support
sgx
in
general,
some
don't
right,
and
so
this
means
that
it's
actually
manufacturer
specific
device
class
right.
G
So
in
this
particular
example,
okay-
and
so
that
means
that
whatever
the
claim
is
the
actual
value
of
the
meaning
of
the
value
is
up
to
the
manufacturer
right,
because
intel
is
going
to
be
authoritative
as
to
what
it
means
to
be
sgx2
capable,
and
so
this
is
an
example
of
one
that
say
intel
would
request.
Oh,
I
need
a
particular
value
in
a
standard
claim,
or
they
have
to
do
some
intel
specific
claim
to
do
this
or
whatever
okay
so
again
require
number.
G
One
is
an
example
where
you
have
a
class
across
different
processors
from
the
same
manufacturer.
Okay,
all
right!
So
that's
that's
how
it
will
differ
from
requirement
to
requirement
two.
It
talks
about
te,
identifying
information,
it
talks
about
the
type
of
tee
and
it
says
the
same
tee
type
created
by
different
manufacturers.
Okay,
so
what
does
that
mean?
So
here's
some
real
world
examples.
Okay,
so
let's
say
you
have
a
suit
manifest.
That's
the
point
that
the
expresses
dependency
or
expresses
the
package
of
a
particular
version
of
opti.
G
Now
opti
is
a
secure
kernel
using
the
term
sorry
secure,
kernel
or
os
using
the
term
loosely
that
runs
on
trust
zone
on
rm,
cortex,
a
processors,
okay,
there's
a
specific
spec
that
arm
puts
out
that
any
manufacturer
that
complies
with
that
spec.
This
will
run
on
okay.
So
in
this
case
the
spec
is
a
proprietary
spec,
but
the
manufacturer
is
not
the
owner
of
the
spec
and
there
can
be
many
manufacturers.
G
This
is
example
that
says
I
need
something
that
complies
with
the
you
know,
arm
v8
architecture
and
so
on,
spec
for
from
arm,
but
any
manufacturer,
nxp,
etc
on
the
manufacturers
here.
So
this
is
not
per
manufacturer.
The
common
thread
on
this
one
is
there's
actually
a
well-known
spec
that
applies
to
it
just.
My
first
example
is
one
with
a
spec
as
a
proprietary,
spec
and
yeah.
I
honest
points
out.
The
specs
themselves
are
public
right,
but
they
come
from
a
manufacturer.
G
They
come
from
arm
not
from
a
standards
org
per
se,
but
the
spec
is
itself
public
and
referenceable,
and
so
on.
So
thanks.
Thomas
second
example
is:
where
risk
five,
which
is
not
a
company.
It's
a
consortium,
risk
five
puts
out
specs,
and
so
some
of
our
pt
folks
that
are
heavily
involved
in
the
specification
implementation
are
from
the
risk
five
community
and
risk.
G
Five
also
puts
out
specs
on,
say,
here's
a
version
of
a
spec
for
tees
and
so
on
and
again
multiple
manufacturers
implement,
according
to
the
spec,
the
particular
arrival
of
a
particular
spec,
and
so
you
can
say,
here's
a
particular
trusted
app,
and
I
don't
know
the
specific
example
here.
Akira
or
somebody
would
have
this
specific
example
of
a
one
that
they're
using
which
says
that
this
suit
manifest
depends
on
the
ability
to
have
a
risk
five
processor,
according
to
the
following
spec
and
rev.
Okay.
G
This
is
one
that
is
again
not
manufacturer
specific,
but
this
one
is
also
the
spec
itself
comes
from
a
consortium,
not
a
vendor
like
in
the
arm
case.
It
comes
from
a
vendor,
but
both
of
them
are
kind
of
the
same
case
right.
He
says
I
want
a
value.
That
means
a
particular
spec,
okay
and
anything
that
complies
with
that
spec
it
applies
to.
Then
there
are
things
that
are.
This
is
also
generalizable
to
non-te
specific
right.
G
You
might
say
I
have
a
given
image,
and
maybe
this
is
something
that
will
be
in
brandon's
presentation,
give
an
image
that
runs
on,
say,
arm,
cortex,
m
processors
from
multiple
manufacturers
right
and
it's
the
boot
image,
or
something
like
that
right
and
so
for
that
look
towards
I'm
guessing
brandon
hex
hangs
presentation.
But
my
point
is
my
expectation:
is
that
will
have
a
similar
requirement,
if
not
the
same
requirement
from
a
non-te
perspective
to
say
any
device,
any
piece
of
hardware
that
conforms
to
a
particular
spec.
G
So
that's
requirement
two,
which
is
things
that
are
not
manufacturer,
specific
and
have
a
spec
technically
current
number
one
intel
probably
has
a
spec
too,
but
they're,
the
only
ones
that
implement
it,
and
so
the
spec
isn't
isn't
as
important,
because
it's
not
one
that's
meant
for
implementers
right,
it's
more
like
a
user
guide
or
a
api
guide
for
people
writing
apps.
On
top
of
it
and
there's
a
third
requirement
that
I
claim
is
not
part
of
this
discussion,
but
I'll
share
it
just
to
make
sure
we
all
agree.
It's
not
okay.
G
So
in
the
same
text
here
that
I
highlighted
some
text,
I'm
gonna
highlight
different
text
here,
so
it
says,
t
identifying
information.
It
talks
about
things
like
reversion,
identification,
information
for
hardware
firmware
and
software
version
of
the
tee
okay.
So,
besides
properties
of
the
hardware,
there's
also
things
that
are
properties
of
you
know
the
firmware
properties
of
the
software
that
you
depend
on
okay,
so
this
wouldn't
be
a
hardware
class
id.
G
This
would
be
more
like
a
firmware
or
a
software
class
id
or
something
okay,
and
so
this
could
be
considered
to
be
a
class
id,
but
my
own
reading,
my
current
belief,
is
the
current
ability
in
each
where
you
can
use
a
suite
or
coswood
already
solves
that
particular
requirement,
and
so
I
don't
think
there's
any
requirement
here
that
is
not
met.
That's
part
of
the
discussion
around
the
you
know
draft
bar
called
suit
rat
claims
document.
I
think
that's
one
that,
with
the
current
version
they
expect.
G
My
belief
is
that
this
is
already
met
and
we
can
concentrate
just
on
requirements,
one
and
two
which
again
have
a
lot
of
overlap.
Where
my
view
was
lawrence's
original
pro
request
would
have
met
both
requirements
and
one
and
two
in
the
eat
spec,
but
wherever
it
goes,
my
point
is
that
there
is
a
requirement.
Here's
some
real
world
use
cases
happy
to
take
questions
and
I
think,
there's
probably
other
manufacturers
on
the
call
that
know
better.
G
So
all
right,
I
think
that's
it
in
unless
there's
questions
and
stuff
for
me,
ed.
D
Okay,
I
had
a
question
so
did
you
have
you
tried
to
draw
a
venn
diagram
of
the
different
ways
in
which
things
might
be
explained,
particularly
on
two
yeah.
D
Well
so
so
I
heard
that
there's
a
because
there's
a
lot
of
overlapping
things
that
that
that
can
be
done
and
the
example
you
gave
was
that
the
intel
sgx
was
a
specific
manufacturer,
whereas
the
risk
was
a
class
okay,
and
I'm
wondering
whether
or
not
some
of
this
is
could
be
more
clearly
generalizable.
G
Why
that
how
my
interpretation
of
lawrence's,
pure
request
would
have
met
both
requirements,
one
and
two.
If
that
would
help?
D
G
But
yeah,
my
belief
is
that
both
one
and
two
can
be
done
with
the
same
mechanism
using
a
registry
that
anybody
that
develops
a
spec,
whether
it
is
a
whether
it
is
a
consortium
licorice
5,
whether
it's
a
vendor-like
arm
or
a
manufacturer
like
intel
right
as
long
as
there
is
some
thing
that
they
can
do,
and
the
other
part
of
the
question
is
is
there
is
a?
Is
a
device
only
going
to
have
a
single
class
id,
and
the
answer
is
no?
The
more
interesting
question
is:
is
there
only
one
per
claim
set?
G
Okay,
where
it
might
be
possible
to
say
that
there's
only
one
per
claim
set
and
having
one
standard
one
if
you
ever
need
multiple
ones?
You
just
use
different
claim
sets
like
the
claim
set
for
the
tee
versus
the
non-tee
is
a
good
example
where
I
would
probably
want
to
have
multiple
claim
sets,
and
that
makes
perfect
sense,
and
so.
D
D
G
Hank
or
brendan
do
we
have
a
suit
view
ready
to
go
yet
or
do
we
need
to
keep?
I
see
brandon
is
now
on.
So
that's
why
I'm
asking
her
to
be
ready
to
go.
B
So
there
are,
and
brent
already
highlighted,
that
there's
no
explicit
claim
discussion
in
the
slides
we
prepared.
I
just
wanted
to
highlight
with
respect
to
the
class
hardware
class,
let's
call
it
that
there
will
be.
I
think
the
the
problem
with
semantic
interoperability
is
that
if
things
are
named
very
similar
people
assume
they
are
the
same,
and
I
am
afraid
this
is
not
the
case
here.
B
G
I
I
My
take
on
this
is:
is
that
what
we
really
care
about
is
compatibility,
and
so
really
what
we're
looking
at
is
a
notional
compatibility
identifier
and
the
thing
is
it
doesn't
matter
what
it
is?
It
really
doesn't
matter.
If
it's
you
know
from
a
vendor
or
a
consortium
or
a
standard
setting
organization,
none
of
it
matters.
It
just
identifies
whether
it's
compatible
or
not,
and
if
so,
from
a
suit
perspective.
That's
what
we
care
about.
We
really
don't
care
what
it
is
we
just
care
that
it
matches.
I
B
H
G
But
I
think
there's
an
advantage
of
saying
I
conform
to
the
following
spec,
rather
than
making
the
other
end
try
to
match
up
across
a
very
long
list
of
you
know,
processors
or
hardware
ids
and
things
it's
easier
to
have
a
suit
manifest.
That
says
anything
that
confirms
to
the
spec,
including
future
things.
As
long
as
it
confirms
the
spec,
I
don't
have
to
enumerate
the
full
list
right
so.
I
G
Sorry,
if
that's
a
question
for
me,
I
can
give
answers.
The
verifier
may
be
dealing
with
a
large
heterogeneous
set
of
a
testers
say
all
the
machines
in
my
enterprise,
okay,
for
some
definitions
of
enterprise
I
mean
there
may
be
iot
devices,
they
may
be
laptops,
they
may
be
whatever,
but.
I
G
B
Yeah,
so
the
knowledge
about
these
tests
are
the
explaining
testers
to
verifiers
does
not
happen
by
their
testosterone.
It
can,
they
can
be
hints
by
the
tester,
but
the
tester
cannot
explain
itself.
It
can
only
provide
claims
about
it
in
evidence,
so
the
explaining
of
our
tests
to
verifiers
happens
via
the
endorsements
and
and
and
the
reference
values
complement
to
complementarily.
So
so
these
are
the
things
that
will
tell
you
the
the
context
about
a
partner
environment.
Then
right.
G
I
think
there
was
one
point
that
I
think
brennan
was
making
that
if
I
understood
it
right,
I
agree
with,
but
let
me
just
verify:
there's
the
entity
that
creates
and
signs
the
suit
manifest
and
there's
the
verifier
and
those
two
entities
can
be
different
entities,
different
roles
or
even
different
organizations.
Right.
A
Let
me
can
I
interrupt
so
we
we,
we
lost
our
our
note
taker,
so
we
need
to
before
we
can
continue.
We
should
be
taking
notes.
I
can
volunteer
to
do
that
if
someone
else
wants
to
take
over
the
chair
duty
or
somebody
else
can
volunteer.
A
Okay,
so
let
us
know
when
you're
ready,
we'll
continue
at
that
point.
G
Go
ahead.
Okay,
I
think
there's
two
related
things
that
I
think
brennan
is
pointing
out
that
they're
different,
but
I
think
that
they're
related
right
one
is
what
goes
in
the
soup
manifest
and
the
soup
manifest
in
the
remediation
case.
The
suit
manifest
is
designed
to
be
processed
by
the
same
device
that
has
the
attester
right,
and
so,
whatever
you
put
in
the
certain
suit,
manifest
the
box
that
we'll
call
via
tester
for
lack
of
a
better
box
back
just
for
rats.
G
Folks,
we'll
call
it
the
tester
box,
the
tester
device
is
gonna,
have
to
look
at
that
suit,
manifest
and
verify
yep.
I
agree
that
this
is
actually
relevant
for
me,
so
you
got
to
put
it
up
in
the
suit
manifest
for
it
to
know
that
it's
relevant
to
it
then
there's
a
separate
piece:
that's
what
is
in
the
verifier.
That
says
is
the
thing
actually
updating
compliance
or
whatever
or
do
I
need
to
kick
off
a
suit
update,
okay,
we're
on
the
same
page
so
far
brendan.
G
Okay
and
what
goes
in
the
claims
is
for
purposes
of
the
verifier
deciding
whether
you
need
a
suit
manifest
or
not,
and
then
what
does
this
manifest
is
for
the
tester
to
just
verify
that
it
got
the
right
one,
that's
applicable
to
it
right,
because
it
could
have
gotten
it
via
more
than
just
this
protocol.
You
know
sneakernet
whatever
right,
and
so
the
main
purpose
of
this
meeting
is
about
what
goes
in
the
evidence
or
what
goes
in
the
claims.
G
G
In
the
teep
use
case,
where
there's
teep
rats
and
suit
all
used
together,
then
the
topology
and
there's
a
slide
that
I
don't
have
in
that
deck.
But
it's
in
older
tape,
slides
that
were
shared
with
rats
and
suit.
Both
I
think
the
teep
typically
but
doesn't
have
to
it
typically
uses
the
background
check
model
where
the
relying
party
is
the
trusted
application
manager
and
the
verifier
is
a
backend
behind
the
trusted
application
manager,
right
and
so
in
the
teep
protocol.
You
send
your
evidence
from
the
tester
to
the
relying
party
here.
G
The
trusted
application
manager
trust
the
application
manager
checks
for
the
verifier,
the
verifier
says,
you're
out
of
compliance
or,
if
you're
out
of
compliance,
you're
out
of
compliance
and
the
trusted
application
manager.
Being
relying
party
says:
oh
you're,
out
of
compliance.
I
guess
that
will
kick
off
some
reputation
and
it
will
use
the
t
protocol,
which
is
the
protocol
between
the
test
and
lying
party,
to
pass
the
suit
manifest
right.
That's
the
topology
in
the
teap
specific
use
case,
okay,
and
so
what
goes
in
the
claims
is
goes
through.
G
The
relying
party
or
tam
up
to
the
verifier,
whatever
comes
in
the
so
it
it
has
those
and
then
whatever
comes
in
the
attestation
results,
is
what
the
remediator
the
tam
is
going
to
use
to
kick
off
stuff
and
so,
in
a
tip
use
case.
It
would
be
very
common
if
you
have
to
make
a
decision
on
what
suit
manifest
to
send
to
say.
I
want
the
information
to
be
in
the
ssd
in
the
fill
your
attestation
results,
which
may
be
copied
copying
some
claims
from
the
evidence.
G
Okay,
just
be
clear
that
says
when
we
put
something
like
a
hardware
class
id
or
whatever
replaces
it
into
claims,
the
expectation
is
that
would
be
inserted
into
the
attestation
results.
It
might
be
copied
from
the
claim
in
the
in
the
evidence
and
that's
what
their
lying
party
would
use
to
kick
off
remediation,
so
just
to
be
clear
that
in
the
original
discussions
the
assumption
was,
this
claim
would
be
both
evidence
and
an
attestation
result.
I
So
far
so
good,
so
the
the
assertion
that
I
made
earlier
was
essentially
saying
that
the
attestation
evidence
does
not
need
to
contain
any
hardware,
identifier,
taxonomy
and
the
reason
I
say
that
is
because
if
you
are
a
testing,
you
have
a
prior
relationship
with
the
verifier.
I
If
the
verifier
has
a
prior
relationship,
then
it
already
knows
all
of
the
identifiers
you
might
send
it
and
it
can
fill
in
the
taxonomies
in
the
attestation
results.
This
reduces
the
bandwidth
between
potentially
small
devices
and
the
either
the
relying
party
in
a
background
check
model
or
the
verifier
in
a
passport
model.
This
is
not
a
bad
thing
right.
We
don't
actually
need
to
send
redundant
information
so.
I
I
G
I
Model
numbers
where
you're
using
soft
tees
software
versions.
You
know
all
these
kinds
of
things
can
get
bundled
together
to
construct
a
set
of
different
identifiers
that
are
broadly
the
identifiers
that
you
use
for
evaluating
compatibility,
which
is
why
I.
G
G
Earlier
to
take
the
intel
example,
are
you
saying
that
what
would
be
in
the
evidence
would
be
something
like
the
processor
model
number
and
the
verifier
would
just
have
to
know
which
ones
are
sdx
capable.
I
G
No,
that
I
say,
there's
two
ends
of
the
spectrum
that
we
have
to
talk
about
both
ends
are
interesting
right.
The
intel
case
in
particular,
is
a
case
which
is
not
really
your
iot
case.
It's
your
bigger
devices
that
have
intel
processors,
for
which
bandwidth
is
probably
less
of
an
issue
compared
to
the
other
end
of
the
spectrum.
Okay-
and
you
might
have
ex
very
large
numbers
of
it
technically-
have
very
large
numbers
of
both
ends
right.
G
Right
so,
let's
take
because
I
I
agree
that
both
cases
are
interesting
and
I
don't
want
to
preclude
either
of
them.
Okay,
so
in
your
example
you're
talking
about
what
goes
in
the
evidence:
okay,
yeah.
E
G
Your
example,
where
the
evidence
itself
only
contains
you
know
the
processor,
you
know
manufacturer
model
number
that
type
of
stuff,
and
so
you
know
I've
got
a
an
st
micro
blah
blah
blah
blah.
It
happens
to
be
cortex
m
compliant,
but
I'm
not
gonna
put
that
in
I'm
just
gonna,
say
it's
an
st
micro
model
number,
whatever
okay.
I
still
believe
that
even
in
that
case
results
to
communicate
that
to
the
relying
parties,
the
relying
party
does
not
need
all
that
information.
G
All
right,
because
I
said
the
anticipation
results
is
what
the
relying
party
the
tam
is
going
to
use,
but
whether
it
gets
it
copied
out
of
the
evidence
or
whether
it
derives
it
from
other
information.
Like
you're
saying,
if
you
had
other
information,
the
verifier
could
derive
it
and
say
my
policy
is
to
insert
the
cortex-m
compliance
claim,
based
on
by
based
on
the
fact
that
it
supports
this
st
micro
version.
I
I
Yeah
yeah
yeah
after
station
results
probably
do
need
it
broken
out
and
probably
do
need
more
detail,
because
the
the
ultimately
the
the
entity
that
is
most
likely
to
know
this
information
is
the
verifier.
So
breaking
it
out
in
the
attestation.
Results
makes
sense
to
me,
but
I'm
requiring
it
in
the
evidence,
does
not.
B
G
B
A
B
Yeah,
it's
a
policy
I
I
see
and
in
the
end
you
could
just
sector
as
check
the
signature,
because
then
that,
then
you
would
put
offload
everything
to
the
attester
which
is
possible
and
allowed
by
the
architecture.
But
it
reduces
the
effective
means
that
would
establish
a
set
of.
G
So
last
comment:
just
with
a
t
hat
on
from
the
t
perspective,
the
t
working
group
does
not
care
about
what
the
requirements
are
for
the
for
the
evidence,
because
the
t
protocol
never
sees
the
evidence,
it's
just
a
pass
through
right.
The
tam
is
it's
opaque
right.
It's
between
the
tester
and
the
verifier.
What
type
actually
depends
on
is
what
goes
the
attestation
results
right
and
how
you
get
it?
Whatever
rat
says,
you
should
get
it.
That
will
be
okay
for
the
t
protocol,
so.
A
So
a
question:
if
the
attestation
results
chose
to
use
an
identifier,
that's
meaningful
to
the
relying
party
but
not
meaningful
to
the
attester.
The
verifier
could
make
the
association
between
those
separate
identifiers
that
would.
G
That's
an
implementation
detail,
but
my
main
point
is
the
teat
protocol
doesn't
care.
All
the
t
protocol
care
is
about
is
what
goes
in
the
attestation
results,
because
that's
the
only
thing
that
a
teep
entity
uses,
of
course,
you're
going
to
have
to
have
a
tester
in
the
same
box
as
your
t
agent,
and
to
that
extent,
but
the
t
protocol
itself
doesn't
see
that
it's
an
opaque
blob
that
gets
carried
as
payload,
so.
A
So
any
other
questions
we
have
two
other
presentations
brendan
has
a
presentation
and
hank
has
a
presentation,
though
we
have
20
minutes
left.
So
maybe
we
can
go
to
those
presentations,
and
so
I
think
brendan.
We
can
do
yours
next.
If
you
don't.
I
Mind
I
I
would
be
happy
to,
although
it
appears
that
since
I
don't
have
the
webex
app
installed,
I'm
not
going
to
be
able
to
share
my
screen
I'll
share
it.
Thank
you.
I
So
this
is
a
very
short
presentation,
so
hopefully
we'll
get
some
of
that
time
back
essentially
what
well
hank-
and
I
want
to
talk
about
in
this-
is
some
of
the
overlap
between
the
rat
suit
claims
draft
and
the
ietf
suit
report.
Draft
next
slide.
Please,
so
we've
got
two
different
drafts.
They
do
have
a
relationship,
they
have
subtly
different
reasons
for
existing
and
they
define
slightly
different
things.
So
the
suit
rats
claim
draft
defines
eight
claims
for
suit
specific
values.
I
Its
sole
purpose
is
for
remote
attestation
and
what
it
provides
essentially
is
a
mapping
of
suit
parameters
into
each
claims.
I
The
ietf
suit
report,
on
the
other
hand,
has
a
or
is
a
reporting
format,
so
to
explain
what
has
happened
during
suit
processing.
It
is
essential.
Its
purpose
is
essentially
just
for
status,
reporting,
post
invocation
or
post
installation
and
and
to
report
failures
in
those
if
they
have
happened,
but
what
it
does
in
it
is.
It
specifies
a
container
for
parameters
that
are
defined
in
the
suit
manifest
and
any
of
its
extensions.
I
So
that,
essentially,
is
the
overlap.
It
starts
looking
a
bit
like
the
rat's
claims
next
slide.
Please
so
what
we're
proposing
is
that
it
might
make
sense
to
take
the
the
claims
that
are
already
composed
in
suit
rats
claims
and
put
them
within
a
single
claim
in
the
relevant
section
of
the
suit
report.
I
So
that
would
give
you
an
array
of
suit
parameter
sets
one
for
each
suit
component,
and
I
guess
the
details
of
that
probably
aren't
entirely
relevant
for
the
rats
working
group.
But
that's
the
idea
next
slide.
Please,
and
so
what
that
means
is
that
the
draft
ietf
suit
report
will
consume
the
suit
rats
claims
document
and
define
one
eat
claim,
which
is
essentially
this
suit
system
properties
claim,
and
that
will
contain
a
an
array
of
any
number
of
maps
of
suit
parameters.
Each
one
specifying
one
suit
component
identifier,
and
that
is
essentially
it.
H
I
I
had
gotten
the
impression
correct
me
if
I'm
wrong,
please
that
we
could
define
a
claim
in
suit
reviewed
by
rats
and
published
as
a
suit
draft.
Yes,
we
could
do
that.
I
was
trying
to
understand
what
you
were
saying.
I
B
I
Well,
so
the
idea,
essentially,
is
this
right.
Now,
the
the
suit
rats
claims
document
has
a
mapping
of
every
suit
parameter
to
a
claim,
and
that
isn't
necessarily
how
things
are
going
to
work.
I
So
it
needs
some
reworking
from
that
perspective,
but
on
top
of
that,
all
of
those
identifiers
are
already
defined
in
the
suit
manifest
draft.
So
having
a
whole
separate
definition
where
they're
translated
from
one
kind
of
definition
to
a
claim
seems
like
a
lot
of
of
extra.
That
may
not
actually
be
necessary
and
we
already
have
a
container
format,
that's
defined
in
the
suit
report
for
reporting
these
things,
hopefully
in
a
constrained
environment
friendly
way.
I
So
the
idea
is
that
we
just
reuse
that
container
and
we
use
the
whole
container
as
a
single
claim.
G
Okay,
so
I
think
I
understand
that
so
in
in
the
sioux
claims
section
of
the
document-
and
I
don't
know
if
you're
presenting
ned,
if
you
have
it
or
whatever,
but
I
have
it
up
on
a
different
screen
on
mine,
which
is
the
the
table
of
contents.
The
suit
claims
section
there's
two
categories
of
claims
which
do
map
to
this
slide
right.
There's
the
system
properties
claims
there's
the
interpreter
record
claims.
Okay,
the
interpreter
record
claims
I
get
what
you're
talking
about
that
makes
sense.
The
system
properties
claims.
G
G
Yeah,
that's
that's
entirely
possible.
The
other
that
was
my
assumption
interpreter
record
claims.
Part
of
that
document
would
go
to
suit
the
system.
Properties
claims
would
be
removed
because
it
was
redundant
with
the
eat
spec,
the
only
difference
being
the
hardware
class
identifier
that
we
were
just
talking
about,
which
is
one
of
those
sub
bullets.
So
as
long
as
we
were
there,
then,
I
think
all
the
rest
of
the
suit
properties
claims
don't
need
to
be
in
suit
at
all.
B
Exactly
but
it's
very
important
to
understand
and
make
sure
that
the
existing
definition
of
the
suit
claims
that
the
system
property
claims
in
this
id
are
actually
semantic
equivalent
to
what
is
in
each
if
they
are
not
yeah
yeah,
and
that
is
the
problem
I
was
thinking
at
the
very
beginning.
This
is
suddenly
not.
That
is
a
problem
right.
G
G
So,
okay
yeah,
all
I'm
doing,
is
I'm
presenting
the
table
of
contents
from
draft
burkhole's
suit.
Rats
claims
right
and
so
in
here
here's
the
list
right
so
somewhere.
I
have
a
slide
that
I
don't
have
up
right
now
that
had
well.
This
one
matches
each
section
whatever
this
one
matches
each
section
whatever,
where
this
is
the
only
one
that
didn't
match,
and
that
was
where
the
hardware
class
id
stuff
came
from
was
that
section
here
everything
else
matches
so
so
I'd
like
to.
I
Bring
up
a
bit
of
a
possible
spanner
in
the
works
for
that,
it's
completely
legitimate
in
suit
to
have
multiple
class
and
vendor
claims
per
component.
There's
there's
no
problem
with
that.
In
fact,
it's
it's
almost
encouraged.
I'm
not
sure
how
that
would
map
into
rats.
G
Are
you
talking
about
that?
The
following
suit
manifest
is
applicable
to
different
sets,
you're
talking
about
that
on
a
particular,
a
particular
device?
Where
I
tried
to
install
my
report,
is
it
succeeded
or
failed,
and
I
was
this,
which
one
did
you
mean
both
actually
as
in
in
the
former
case?
I
get
it
in
the
latter
case.
I
don't
understand
how
that
could
happen
unless
you
actually
have
different
claim
sets
in
which
case
eat
already.
Has
that.
G
I
Yeah,
so
I
I
mean-
maybe,
but
not
necessarily
and
and
the
reason
I
say
that
is
because
you
can
come
up
with
interesting
constructs
like
you've,
got
a
particular
version
of
your
updater,
which
is
specific
to
the
bootloader.
That's
installed
on
one
of
your
devices
and
you
haven't,
had
a
hardware
update,
but
you've
decided
to
move
to
a
new
bootloader.
So
that's
something
that
you
have
to
check
and
the
way
that
you
check.
I
G
G
G
At
least
a
bunch
of
people
have
a
particular
view
of
how
things
work
and
maybe
different
people
have
different
views,
because
I
know
there's
been
some
discussion
about
that,
but
I
think
lawrence
and
I
are
aligned
on
this
one
as
to
how
we
think
it
works,
but
if
you
have
other
things
that
it
doesn't
work
for,
we
got
to
modify
our
thinking,
we'd
love
to
hear
that
and
from
a
rest
perspective,
but
class
identifier
is
the
only
one,
that's
interesting
to
say.
G
Well,
if
I
got
a
processor
or
a
component
that
is
compliant
with
multiple
specs,
just
to
use
the
the
the
terminology
that
that
I
had
before,
maybe
I'm
compliant
with
both
the
arm
v8
architecture
and
a
particular
global
platform
spec
for
example.
How
could
I
do
that?
Okay,
when
I
do
that
in
two
different
claim
sets-
and
this
was
what
I
was
alluding
to
earlier-
I
said:
would
you
have
one
multiple
claim
sets
or
multiple
values
or
what
and
I'm
not
sure
there.
I
Yeah
so
my
my
argument,
is
you
probably
need
to
specify
multiple
and-
and
you
gave
a
great
example-
I
I
mean
there-
there
are
others,
but
we
don't
necessarily.
G
Use
the
same
claims
that
versus
in
different
claim
sets
is
the
question
that
I
have,
because
if
this
is
the
only
example
of
multiple
values
in
the
same
claim
set,
then
it
just
means
you
want
to
claim
with
multiple
values
in
it,
as
opposed
to
you
know
having
it
be
a
general
thing
in
each
or
whatever
you
say:
hey,
you
have
a
claim
that
can
have
a
list
of
stuff
right,
a
list
of
opaque
values.
So,
okay,
I'm
going
to
stop
shooting.
I
G
F
F
You
know
if
there
are
clear
claims
that
there
is
clear
agreement
on
that
are
broad
in
general,
for
lots
of
software
update
and
other
use
cases,
then
we
can
put
them
in
the
e-document,
but
you
know
I
mean
I
understand
a
lot
of
the
design
things
and
you
know,
like
brendan's
design
seems
like
there's
some
good
things
in
that,
and
but
it
sounds
like
a
software
update
thing,
not
a
really
general
purpose,
eat
thing
and,
and
so,
and
you
know,
eat
claims
you
can
anybody
can
define,
you
know,
eat
planes
or
cwd
claims
and
lots
of
working
groups
and
standardize
them
and
publish
them
and
use
them.
F
This
way,
use
them
that
way
that
that's
all
fine,
there's,
no
there's
nothing
particularly
magic
about
it,
something
having
to
go
in
the
document.
So
at
this
point
I'm
my
preference
would
mean
none
of
this
goes
in
the
doc
yeah.
None
of
this
goes
in
the
document
and
then
we
in
particular
we
don't
hold
up
eat
any
further
for
any.
For
this.
You
know.
I
B
Okay-
and
we
have
to
make
sure
that
the
system
property
claims
that
are
in
the
document
that
have
moved
out
semantically
equivalent
to
the
claims
in
each
and,
if
not,
we
have
to
make
that
very
clear
when
we
define
additional
claims
or
the
different
information
first
that
I
already
find
in
in
suits
the
definition
is
done,
but
if
they're
not
equivalent
or
assessed
to
be
not
equivalent.
But
there
has
to
be
a
note
in
the
report
that
this
is
equivalent.
B
This
can
be
used
as
and
used
in
the
reds
educational
result,
but
this
is
not
the
same
as
this
is
this.
We
will
spell
this
out
in
suit.
I
assume.
F
So
what
I'm
really
interested
in
the
most
is
that
the
claims
that
are
in
the
in
the
current
heat
draft,
whether
they
need
any
modification
or
clarification
or
use
here,
that's
my
number
one
priority
and.
B
I
think
that's
only
three
one
three,
once
that's
a
device
vendor
and
version,
this
is
the
three
ones
that
we
just
have
to
spin
off
like
half
an
hour,
really
look
at
them
in
a
small
group
discussion
to
break
out
a
design
team
whatever
and
and
then
come
back
with.
Yes,
this
is
the
same
thing.
Go
ahead.
F
F
Can
I
please
finish-
I
haven't
said
very
much
here.
The
claims
I
would
be
interested
in
are
uuid
or
ueid
hardware
vendor
that's
our
hardware,
oem
hardware
model
and
hardware
version.
So
that's
the
the
things
there.
Hardware,
hardware,
oem
hardware
model
and
hardware
version.
Those
are
the
the
existing
claims
that
I
think
need
some
discussion
and
might
be
relevant
here
or
might
not.
F
So
that's
so
that's
a
hardware
vendor
not
not
a
tester
vendor.
A
So
so
I
think
it
sounds
like
there's
an
item
to
go
to
do.
Have
that
discussion.
I
don't
know
we
can
have
that
in
the
last
three
minutes
of
this
meeting,
but
so
I
think
that
what's
on
the
table
is
whether,
where
that
discussion
should
happen,
should
it
happen
in
rats
or
should
it
happen
in
suit?
A
F
H
This
is
russ
that
makes
sense
to
me,
and
I
think
that,
but
from
the
suit
charter
perspective,
where
it
says
one
of
the
two
groups
will
take
the
lead
on
the
document,
that's
going
to
explain
how
firmware
update
status
is
the
other
block.
I
think
we're
suggesting
that
part
goes
in
suit
dependent
as
much
as
it
can
on
each
clean
definitions.
G
That's
what
I
was
trying
to
share
in
that
table
of
contents
right
from
this
discussion
is
that
five
of
the
sections
in
the
burkholz
document
go
to
rats
because
they're
general,
I
mean
the
system
properties
claims
other
than
hardware
class
right,
the
other
five
there.
They
don't
match
one
to
one,
because
it
just
so
happens
in
e.
G
That
covers
like
three
of
those
in
one
meaning
they're
combined
into
a
into
a
causeway,
but
those
five
sections
go
out
of
there
and
would
not
need
to
be
defined
in
suit,
but
can
be
discussed
in
suit
to
ross's
point
it
says:
how
would
you
use
those
in
a
software
context
that
can
define
the
other
ones.
A
A
G
Lawrence
has
explained
that
the
eat
spec
he
listed
a
specific
things
euid
and
so
on
that
people
should
redone
themselves
and
verify
there's
no
gaps
in
there
right
and
that's
the
the
five
sections
that
I
refer
to
are
the
ones
that
I
personally
claim
that
do
map
and
that
the
eat
spec
is
fine,
but
others
should
do
that.
You
know
hank
and
folks
should
do
their
own
checking
and
make
sure
they
can't
spot
something.
That's
missing.
B
A
E
And
to
clarify
that
okay,
I'm
gonna
do
this
as
a
chair.
I
think
the
discussion
needs
to
be
crossed
for
now
until
we
make
a
final
decision,
meaning
the
discussion
should
be
joined
in
both
rats
and
suit
yeah.
Perhaps
the
three-way
right
include
teep
as
well.
A
At
least
when
we
come
to
a
conclusion,
we
should
present
the
conclusion
to
t
yeah.
B
A
Thank
you
yeah,
so
I
think
we
can
close
the
meeting
now
unless
there's
any
last
minute
discussion
that
needs
to
be
out
there.