►
From YouTube: IETF111-RATS-20210729-2030
Description
RATS meeting session at IETF111
2021/07/29 2030
https://datatracker.ietf.org/meeting/111/proceedings/
B
Going,
let's,
who
hasn't
done
it
for
a
while,
please
please
volunteer.
That
would
be.
B
B
C
C
B
All
right:
well,
let's
get
started
we're
a
minute
over.
So
agenda
is
on
the
screen.
We
have
su
id
and
e
relation
to
idev
id
topic
by
lawrence.
So
let's
jump
into
that
and
I
can
I
can
share
slides
if
you
want
lawrence
or
you
can
yourself,
whichever.
F
Okay,
now
it's
okay
yep!
Can
you?
Can
you
hear
me
yeah,
okay,
separate,
so
the
the
main
new
addition
to
eat
to
be
discussed
today
is.
F
So
u-e-I-d
and
s-u-e-I-d
are
device
identifiers
in
that
they
identify.
You
know
we
identify
a
lot
of
different
things
in
rats
and
the
intent
here
is
to
identify
an
instance
of
some
hardware,
so
a
physical
thing.
So
if
you
have
a
million
devices,
you
have
a
million
ueids,
it's
not
an
identification
of
the
manufacturer
or
the
vendor,
or
the
software,
or
anything
like
that.
This
is
focused
strictly
on
individual
bits
of
hardware,
so
ueid
is
defined
today
as
a
binary,
byte
string
and
there's
three
ways
that
are
for
constructing
it.
F
F
Another
way
to
do
it
is
just
to
reuse.
A
mac
address
same
the
same
as
an
eui
64.,
the
uniqueness
of
that
the
global
uniqueness
of
that
is
based
on
management
by
the
ieee,
and
then
you
can
also
do
a
14
byte
imei
again,
that's
managed,
I
think,
by
3gpp
the
uniqueness
of
it
all
of
these
identifiers
are
you.
Ueid
is
always
intended
to
be
globally
unique
without
the
need
for
any
qualifier.
F
So
you
don't
need
to
add
in
like
the
the
the
vendor
or
the
domain
or
the
protocol,
or
anything
like
that,
they're
just
globally
unique.
So
you
can
pick
one
up
and
and
know
that
it's
globally
unique,
there's
a
a
statistical
analysis,
an
appendix
in
the
appendix
of
the
document,
for
that
justifies
the
size
for
the
crypto,
the
random
number
generator
based
one.
F
So
based
on
some
comments
from
geary,
like
I
think,
a
meeting
or
two
ago
and
some
other
things,
I
realized
that
just
having
ueid
by
itself
was
probably
not
enough
that
there
is
the
need
to
have
identifiers
that
change
on
life
cycle.
Events
such
as
a
change
of
ownership
factory
reset
to
it
maybe
to
address
other
privacy
issues
and
stuff
like
that,
then
I
went
and
read
the
I
I
dev
id
spec.
I
think
that's
ieee
802
11ar
secure
device
ids.
F
I
don't
remember
if
I
got
the
right
ieee
number
there,
but
and
they
have
that
that
has
an
idev
id
and
ldev
ids,
so
I've
added
to
the
eatspack,
an
sue
id
and
or
a
set
of
suids.
So
so
a
device
can
have
multiple
su
ids
and
they're,
basically
exactly
the
same
format
as
a
ueid,
and
you
have
a
list
of
them.
F
There
is
a
simple
string
label
to
distinguish
one
from
another,
so
you
you
know.
If
you
have
three
of
them,
you
could
have
three
different
strings
identifying
them
and
they
could
be
like
the
the
use
case
for
which
they
were
generated.
For
example,
maybe
one
is
for
fido
or
for
some
application,
or
something
like
that,
so
the
identifying
string
could
just
be
fido
the
no
registry
for
the
strings.
I
assume
there's
going
to
be
a
only
a
small
number
of
them,
so
that's
the
kind
of
top
level
of
ueid
and
s-u-u-e-id.
F
In
that
the
new
edition
of
sue
id,
I'm
gonna,
I'm
gonna
keep
going
and
wait
for
questions
to
to
to
the
end.
I
think
next
slide.
F
So
I
spent
a
fair
bit
of
time
trying
to
understand
how
eat
and
its
ue
id
might
relate
to
an
idev
id.
So
anyone
looked
at
the
spent
a
lot
of
time,
reading,
idev
id
and
and
trying
to
understand
that-
and
I
kind
of
can
categorize
there's
three
ways
they
can
relate
to
each
other.
You
know
the
first
way
and
I'm
going
to
go
through
these
in
detail
in
the
next
few
slides.
F
The
first
way
is
the
idev
id
is
the
sort
of
the
key
material
and
endorsement
for
use
with
the
e
protocol,
so
they're
they're
both
implemented
and
they
work
together.
F
The
second
is
they're
looked
at
as
competitors.
They
both
provide
the
identity
of
the
device
and
a
little
bit
of
manufacturing
and
for
information.
It's
one
of
the
other.
F
In
this
case,
I
think
idev
id
gets
used
with
eap.
Then
the
third
case
is
we,
you
take
the
eat,
claims
and
kind
of
stuff
them
into
an
idev
id,
and
so
it
gets
becomes
they're
kind
of
both
implemented.
But
it's
not
really
a
protocol,
it's
more
just
a
set
of
claims
that
are
put
into
an
idev
id.
F
I
guess
this
is
kind
of
passport
model.
No,
no!
It's
not
never
mind
that
comment.
It
was
they
put
an
endorsement
in
in
the
dev
id
module.
Then
the
tester
is
something
that
you
know
this
kind
of
surrounds
or
is
larger
than
the
dev
id
module.
Always
an
announce
comes
from
the
verifier
or
the
relying
party,
and
here
I've
just
collapsed.
The
verifier
and
relying
party
for
simplicity.
F
One
interesting
thing
to
note
is
that
dev
id
modules
dev
id
endorsement
certificates
have
a
serial
number
of
the
device
not
of
the
certificate
but
of
the
device
in
the
x
509
subject
field
they
can
have
that.
So
if
they
have
that
in
the
subject
field-
and
there
is
also
a
ue
id-
I
would
expect
those
two
to
be
coordinated
somehow,
so
they
are
basically
the
same
or
one
is
derived
from
the
other.
So
there's
not
like
conflicting
identifiers
arriving
at
the
relying
party.
F
I've
been
looking
in
a
little
more
detail
on
that.
A
dev
id
serial
number
is
a
text
string
up
to
quite
a
large
number
of
bytes,
so
you
can
base64
a
ue
id
and
put
it
in
there
or
you
could
go
the
other
way
around
and
hash.
The
the
serial
number
in
the
x519
subject
field
to
turn
it
into
a
ueid
next
slide.
F
The
one
interesting
part
of
this
diagram
is
kind
of
right
in
the
middle,
where
I'm
showing
a
box
that
says
signed
nonce,
I
mean
there
has
to
be
assigned
nonce
going
back
from
the
device
to
the
rolling
party,
otherwise
that
you
can
have
replay
and-
and
I
think
in
most
cases-
that's
the
intended
implementation.
There
is
with
eep
eap,
but
my
understanding
is
that
dev
id
does
not
require
any
particular
protocol
there.
You
could
use
any
any
particle.
You
want.
F
F
So
now
we
can
take
the
eclipse,
eat
claims
and
put
them
into
x509
v3
extensions
in
a
dev
id
certificate.
So
you
could
do
this
with
an
asn1,
syntax
and
oid
for
each
claim.
So
you
go
through
all
the
claims
in
in
like
the
cwt
registry
and
in
addition
to
the
labels,
the
the
the
labels
you
have
to
find
there,
you
define
an
oid
for
each
one
and
asm1
syntax
for
each
one
and
then-
and
we
may
have
interest
in
doing
that
anyway
and
then
those
get
put
into
the
x59v3
extensions.
F
One
thing
to
note
here
is
this:
only
works
for
static
eat
claims
because
dev
ids
are
generated
by
the
manufacturer,
not
by
the
not
on
the
device.
So
you
can't
use
like
gps
location,
debug
status
and
some
software
measurements
that
are
conducted
on
the
device.
Those
can't
be
used
there.
So
not
everything
and
also
note
that
it
is
not
the
protocol
between
the
device
and
the
relying
party
or
the
verifier,
that's
probably
still
eep
or
something
like
that.
F
F
Certificate:
okay,
one
more
slide
just
to
make
sure
I
didn't
forget
anything.
F
Okay,
yeah,
you
can
go
back
okay,
so
that
leaves
like
five
minutes
for
comments
and
questions.
F
G
Yeah
the
good
stuff
lawrence-
I
I
I
like
the
slides-
I
don't
have
any
problems
with
the
slides.
They
actually
made
me
think
that
there's
some
analogies
that
somebody
else
could
do
the
same
kind
of
exercise
without
their
face.
So
just
a
couple
of
comments
that
are
outside
the
scope
of
what
you
are
trying
to
do.
That
might
be
invitations
for
other
people
to
to
do
similar
exercises.
G
So
the
first
comment
is
that
when
you're
talking
about
you,
know
device
identifiers,
there's
a
bunch
of
device
identifiers
that
are
out
there
or
things
that
people
use
in
lieu
of
them,
and
you
mentioned
some
of
them.
You
know
mac,
address
and
so
on.
G
We
had
the
medina's
buffer
in
the
in
the
week
where
people
were
using
mac
addresses
for
things
because
they
didn't
have
something
else,
and
how
do
we
get
them
off
of
that
and
so
on,
and
so
a
lot
of
the
same
exercise
that
you
did,
somebody
else
could
repeat
for
any
other
type
of
device
identifier.
You
know
you
could
take.
G
What's
the
relationship
between
eat
and
eui
64
is:
what's
the
relationship
between
eat
and
mac
addresses
or
eat,
and
pick
anything
else
that
you
can
think
of,
and
you
can
have
a
very
similar
exercise,
and
I
see
a
lot
of
parallels
between
your
observations
here
and
things
that
would
be
similar
observations
when
doing
an
exercise
for
any
of
these
other
spaces,
and
so
I
think,
some
of
the
things
what
you
have
is
kind
of
a
template
for
anybody
else
doing
this
kind
of
exercise
and
a
lot
of
these
observations
are
generalizable
to
other
things
than
than
just
idev
id
that
you're
looking
at
so
good
work
on
idev
id
I'd
like
to
see
people
do
the
same
thing
for
other
things,
because
I
think
there's
actually
some
more
general
observations
here
that
I
think
you're
exactly
right
about
and
then
the
last
point
I
would
say,
is:
although
you're
doing
this
for
a
device,
identity
right,
somebody
else
could
do
an
exercise
that
says
for
other
types
of
identity.
G
That's
not
device
identity
right
where
you
talked
about
you
know
eats,
have
things
that
can
be
used
for
a
device
identity,
but
people
could
bring
in
claims
that
are
identities
of
things
other
than
the
device
per
se.
So
we'd
have
like
software
identity
and
coswoods
and
things
we
have
potentially
user
identity.
G
So
this
is
just
an
invitation
and
if
anybody
else
knows
of
other
things
that
were
done
similar,
please
bring
them
up,
but
otherwise
it's
an
invitation
to
say.
Can
other
people
look
at
things
similar
to
what
lawrence
has
done
here
for
eats
versus
high
debates?
Thanks.
F
Before
going
on
to
the
next
comment,
I've
been
running
a
bit
of
a
side
discussion
with
some
of
you
and
I'll
probably
surface
it
to
the
list
about
eat
versus
or
the
ueid
in
comparison
to
other
efforts
and
in
particular,
there's
a.
I
think
it's
in
1939
that
just
came
out,
which
is
a
urn
format
for
device
identifier,
so
I
I
think,
there's
some
good
discussion
to
be
had
on
the
list
and
maybe
even
cross
working
groups
on
this.
I
think
russ
was
next.
F
I
don't
have
a
strong
opinion
on
that.
I
mostly
have
enough
work,
so
I
hadn't
really
dug
into
that.
So
I
guess
not
really
an
opinion.
I
would
assume
it's
more
of
a
just
dealing
with
syntax
and
in
coding
rather
than
semantics.
So
maybe
it's
not
too
hard.
D
Eric
one
of
the
things
you
had
mentioned
was
that
you're
going
to
be
looking
at
composite
devices,
including
structures
of
different
elements
contained
into
one,
especially
because
you're
getting
an
identity.
I
think
it
would
be
good
to
talk
about
the
hierarchies
of
identities
that
are
going
to
be
dependent
on
each
other.
D
So
if
you
thought
at
all
about
the
relationships
of
the
identities,
because
the
relying
party
is
going
to
have
to
understand
the
types
of
identities
and
the
relationships
for
them
in
order
to
have
a
policy
to
evaluate
the
relationships
between
those
identities,.
F
I
haven't
thought
about
it
too
much
mostly
trying
to
define
a
good.
You
know
clear
or
useful
claims.
I
mean
trying
to
think
about
architectures
of
how
things
are
combined
yeah.
I
guess
we
can
think
about
that.
Hopefully,
a
lot
of
that
is
is
expressible
via
sub
modules
in
eat,
but
I'm
not
sure
I
mean
it
sounds
more
like
you're
talking
about.
D
F
B
Lawrence
you're,
at
the
top
of
the
spot
for
this
topic,
you
can
continue
it
you're,
going
to
be
stealing
from
the
next
topic.
B
F
So
just
a
little
kind
of
comment
on
the
purpose
of
attestation,
I
mean
I
see
the
end
purpose
of
anastasia
is
to
give
results
to
the
relying
party,
because
the
relying
party
is
going
to
make
the
decision
about
what
to
do
so.
The
relying
party
is
kind
of
the
the
serving
the
rolling
party
is
our
goal
here.
F
That's
what
we're
trying
to
do
and
also
observe
that
a
lot
of
rolling
parties
may
use
machine
learning
and
they
want
every
scrap
of
information
that
are
even
of
remote
value,
just
because
there
might
be
some
correlation
between
something
that
that
no
one
thought
there
was
a
correlation
between.
So
I
think
eat
is
a
relatively
obvious
choice
to
convey
attestation
results
to
the
relying
party.
Eight
supports
jason,
which
is
good
representation
for
the
server
side.
Eight
is
flexible
in
terms
of
security
options
and
you
can
have
the
signed
format.
B
B
F
And
then
getting
into
more
of
the
interesting
part
of
this,
this
discussion
is
that
I
see
a
lot
of
the
claims
as
appropriate
to
pass
directly
through
the
verifier
to
the
relying
party
and
when
I
first
came
up
with
the
idea
for
eid,
there
was
no
separation
between
verifier
and
relying
party,
so
I
was
thinking
of
all
of
them
that
way,
but
then
this
many
interesting
discussions
later
we
have
an
architecture
and
lots
of
interesting
things
going
on.
F
Okay
next
slide,
so
I
believe
this
is
a
list
of
claims
that
I
think
are
interesting
to
pass
through
the
verifier
to
the
reliant
party,
the
nonce,
although
the
nots
there
and
replay
freshness,
there's
a
lot
of
complexity
behind
that
that
I
won't
go
into.
F
F
Relying
parties
may
want
to
know
the
the
manufacture
of
the
hardware
of
the
device.
Oem
id
a
hardware
version
may
not
always
be
as
useful.
You
know
when
I
think
of
something
like
clearing
financial
transactions.
Maybe
hardware
versions,
not
that
exciting,
but
it's
there
and
it
can
pass
through.
You
know
the
assumption
on
all
of
these
is
that
the
verifier,
as
doing
some
sort
of
at
least
verifying,
that
the
the
authenticity
of
these
from
the
the.
B
F
And
may
be
doing
other
consistency
checks
on
them,
so
so
debug
status,
I'm
not
gonna.
I'm
gonna
go
through
these
quickly,
gps
location,
obviously
useful
to
the
rolling
party.
Then
software
manifests
like
coswood.
That's
currently
how
eat
is
attempting
to
characterize
software
on
the
device
is
just
through
cosway,
just
through
reuse
of
coastwood.
F
Then
another
really
interesting,
one
that
I'm
going
to
talk
about
a
little
bit
more
here
later
is
some
the
results
of
a
software
measurement,
something
very
simple
where
the
relying
party
can
just
get
it
more
or
less
a
thumbs
up
or
thumbs
down
on
whether
the
software
measurements
were
or
validated.
Note.
Also
that
some
testers
can
measure
and
validate
subsystems.
F
So
you
don't
have
the
the
measurement
results
does
not
have
to
be
carried
out
by
the
verifier
that
can
be
done
by
the
the
attester.
Then
you
know
key
material
is
like
android
keystore.
You
definitely
want
to
pass
key
material
through
to
the
end
to
the
rolling
party
and
then
sub
modules
characterizing
the
device.
So
next,
so
here's
a
couple
claims
that
next
slide
yeah
a
couple
claims
that
more
most
likely
are
generated
by
the
verifier.
F
For
the
relying
party,
so
they
did
not
come
from
the
the
attester,
so
some
sort
of
an
identifier
for
the
particular
results
report,
a
time
stamp
and
a
nonce.
Those
are
all
fairly
straightforward.
F
The
verifier
may
know
a
security
level
for
the
device
like
you
know
whether
it
was
t
e
or
ree,
and
then
the
results
of
a
I'll
get
I'll
get
to
you
in
a
minute
eric
the
the
results
of
the
the
software
measurements
and
then
this
thing
called
a
dlla
which
is
defined
by
global
platform,
which
describes
the
certifications
received
by
a
device.
F
So
those
are,
I
think,
some
claims
that
can
be
generated
by
the
verifier
for
the
relying
party
eric
did
you
still
have
a
question.
D
Quick,
I
think
that
the
the
place
where
the
attestation
results
draft
that
we
talked
about
last
session
were
probably
around
the
software
results
side
and
the
security
level
side.
I
think
it'd
be
interesting
to
normalize
these
two
talking
about
identities
as
well
as
identities
of
what
you
think
are
identified
as
levels
as
well
as
what
you
think
are
important
for
the
software
results.
So
I
think
this
is
something
for
a
good
offline
merger
before
that
off
site
that
we
have.
F
F
You
know
in
and
eat
only
a
url
to
retrieve
the
dloa
would
be
in
the
registrar
or
would
be
in
the
in
the
heat.
So
the
it's
pretty
simple.
What's
in
a
dla,
you
know
the
authority
who
issued
it,
for
example,
emvco
a
identifier
which
is
basically
kind
of
a
sequence
number
serial
number,
then
there's
the
loa
scope,
which
was
unable
to
find
an
example
of,
but
I
assume
that
is
more
or
less
has
something
to
do
with
the
type
of
certification
that
was
granted.
F
Then
there
is
somebody
an
identifier
of
the
platform
to
which
the
certification
was
granted,
and
then
you
know
issuance
and
expiration
date.
So
next
slide.
F
So
this
this
is
a
proposed
claim,
eat
claim
for
a
dloa,
it's
just
in
github
right
now,
it's
not
in
any
of
the
drafts,
so
it
would
be
an
array
of
more
one
or
more
dloa
references,
so
in
that
case
a
dloa
type
and
a
dloa
reference.
Basically
is
the
fields
to
construct
a
url
to
fetch
the
dloa
from
the
dloa
registrar.
F
The
other
point
is
that
that
the
dloa
claim
would
only
be
present
and
eat
if
that
certification
was
granted,
so
you
wouldn't
just
put
put
them
in.
I
don't
know
you
wouldn't
put
them
in
for
any
other
reason,
and
then
the
the
dloa
scope
is
limited
to
the
submodule
that
it's
in
so
it
just
works
with
sub
modules,
as
as
all
the
other
claims
work
with
sub
modules.
F
F
E
B
F
It's
definitely
not
an
endorsement.
I
don't
think
it's
an
endorsement.
Basically,
you
know,
if
you
you
know,
if
you,
if
you've
got
an
anistation
about,
let's
say
a
secure
element.
This
is.
I
got
an
attestation
from
a
secure
element
and
I
want
to
know
whether
that
sort
of
that
that
secure
element
had
made
it
through.
You
know
a
particular
common
criteria.
Certification,
then
the
dl
dloa
would
be
included
as
a
claim
in
the
attestation
result,
and
the
relying
party
could
know
that
it
received
that
certification.
F
H
Yes,
hi
so,
and
that
is
funny
because
literally
the
first
thing
I
thought.
Oh,
this
is
an
endorsement
so
because
it
is
a
an
expression
that
is
like
evidence,
but
the
attacker
cannot
create
it
about
itself.
So
if
it's
not
evidence,
but
it's
like
evidence,
but
coming
from
a
third
party
that
is
literally
an
endorsement,
I
thought,
but
now
you're
also
telling
me
it's
an
attestation
result
content
and
this
seems
to
be
all
over
the
place
so
who
and
how?
How
is
the
claim
collection?
H
F
Well,
the
way
I
would
expect
this
to
happen
is
that
the
verifier
would
receive
attestation
evidence
that
included
things
like
the
oem
id
and
the
version
and
information
about
the
software
and
hardware
versions,
and
all
of
that
that
verifier
would
have
a
table
of
lookups
and
say
that
guy.
I
know
that.
F
H
So
so
I
so
my
first
thought
is
that
this
lookup
is
a
inquiry
to
an
endorser
fetching
the
endorsement
and
then
somehow
expressing
that
in
the
attestation
result
that
there
was,
but
again
a
relying
party
has
to
make
sense
of
that.
So
so
there
can
be
a
thousand
types
of
endorsements
like
this
is
certified
by
foo
and
the
relying
party
might
not
need
that
information
just
that
it
has
some
certain
level
of
assurance
now
due
to
that,
so
so
maybe
an
abstraction.
H
F
H
F
The
actual
dla
dloa
would
be
fetched
by
the
relying
party.
I
don't
think
there
are
very
many
types
of
certifications,
particularly
people
that
are
interested.
B
F
Are
I
mean
there's
not
that
many
certification
programs
certification's
really
expensive
and
complicated?
So
there's
not
that
many,
not
not
that
many
issues,
so
I
don't
think
there's
thousands
and-
and
it's
not
an.
F
It
is
not
telling
you
that
the
the
attestation
evidence
from
this
attester
is
is
to
be
trusted.
It's
telling
you
something
about
certification
of
the
device.
What
okay.
H
H
Before
I
don't
want
to
block
the
mic
line
here,
actually,
a
question:
is
this
done
in
tps
in
gp,
the
dloa
stuff
trusted
platform
services
working
group
in
a
global
platform.
F
G
Dave
all
right,
so
I
originally
asked
the
endorsements
question
and
I
got
in
line
to
say
I
think
your
answer
is
correct
lawrence,
but
I
want
to
explain
why
to
at
least
help
out
with
the
answer
there.
I
think
the
deal
dloa
as
you
described,
it
does
not
say
anything
about
the
individual
instance
of
the
device.
It
basically
says
this
class
of
devices
right.
This
model
number
has
been
certified
right
where
normally,
when
we
think
of
an
enforcement,
it's
saying
this
particular
instance
has
a
private
key
and
I'm
endorsing
that
particular
private
key.
G
As
being
you
know,
intel
inside,
if
I'm
intel
endorsing
it,
it
really
is
is
my
thing
and
it's
not
doing
that
in
that
sense,
lawrence,
I
think,
is
you're
you're
exactly
right
in
terms
of
it's
not
an
endorsement
in
that
sense,
because
it's
a
statement
about
the
class
or
model
number,
not
a
statement
about
the
incense.
That's
why
it's
not
an
endorsement.
G
So
that's
what
I
got
in
line
to
say,
but
I
interpreted
your
slide
as
being
the
not
this
slide,
but
maybe
the
previous
one
and
you
don't
have
to
go
back.
We
were
talking
about
a
claim
that
carries
information
about
the
dla
and
that
gets
inserted
by
the
verifier.
And
then
you
said
that
the
doa
was
resolved
by
the
relying
party
is
the
point
of
the
claim
to
tell
the
the
relying
party
enough
information
so
that
it
can
resolve.
The
correct
thing.
Is
that
my
is
that
the
right
takeaway
that
I
should
get.
G
F
Okay,
I
I
suspect
this
one
will
be
a
few
minutes.
This
one
will
be
kind
of
interesting,
so
I
I've
you
know
this
is
in
github,
not
in
a
draft.
This
is
a
proposal
for
a
claim
that
summarizes
at
a
very
high
level
the
result
of
a
software
measurement.
Let
me
do
this
slide
and
then
eric
I'll
get
you
okay.
So
the
the
claim
is
defined
so
that
it
can
contain
multiple
results
and
each
claim
has
yeah
each
result
has
three
parts.
F
Maybe
four
one?
Is
the
text
string
just
describing
the
measurement
process,
product
or
standard
or
scheme,
and
then
it
has
two
enumerated
types.
One
is
what
was
what
was
enumerated.
So
was
everything
in
the
sub
module
or
the
device
enumerated?
Was
it
partial
or
do
we
know
enough
to
say?
Well,
it
was
just
the
firmware.
It
was
just
a
kernel.
It
was
just
the
privileged
software,
mostly.
I
think
it
would
either
be
all
or
partial,
with
the
other
ones
being
just
used
in
rare
cases
and
then
the
other
is
enumerated
type.
F
That
says
whether
you
know
what
the
result
of
the
verification
was:
did
the
measurement
run
and
complete
and
was
fully
verified?
Did
the
measurement
run
and
then
fail?
Did
the
measurement
run
and
the
results
were
indeterminate?
You
know
perhaps
because
the
the
the
measurement
something
went
wrong
with
measurement
like
it
was
unable
to
parse
something
or
something
like
that.
So
you
don't
really
know
it.
Could
it
could
be
right?
F
It
could
be
wrong,
it
could,
you
could
say
the
verification
was
not
run
or
you
could
say
the
verification
was
partly
verified
and
then
you
could
also
have
another
part
here
which
says
what
the
objective
of
the
verification
was
and
that
just
a
text
string.
So,
for
example,
android
kernel
next
slide.
F
D
D
B
The
what
we
want
the
slide.
D
Ketchup,
the
idea
of
things
like
verification
partially
verified-
I
don't
know
at
a
relying
party
how
to
handle
what
partially
means
as
a
design
principle.
It
would
be
interesting
to
consider
this
versus
either
a
binary.
It's
verified
or
it's
not.
So
I
wonder
how
much
is.
Is
there
a
design
principle
for
trying
to
figure
out
what
the
relying
poli
party's
policy
language
is
to
make
sure
you're
not
overloading
it
with
things
that
are
difficult
to
parse.
F
Well,
yeah,
I
I
mean
I
understand
partial
is
pretty,
it
could
be
pretty
useless
one
of
the,
but
you
know
when
I
think
about
you
know
verification
of
a
sort
of
subsystems
on
an
android
phone.
You
know
it's.
I
think
one
of
the
ways
you
avoid
partial.
Is
you
structure
your
sub
modules?
So
you
don't
ever
have
partials.
F
I
I
mean
I'm
open
to
other
possible
solutions
here.
I
was
just
trying
to
you
know:
figure.
D
Out
something
that
could
fit,
we
should
connect
offline
because
they're,
I
think,
matching
this
to
the
needs
of
the
policy
language
on
the
relying
party
drives
some
some
interesting
decisions
here,
so
I
could
connect
on
the
list
talking
about
some
potential
design.
Principles
for
the
software
result
claim
that
try
to
drive
it
from
how
you
would
consume
this
yeah.
I.
F
Know
there's
a
lot
of
work
can
come
in
korean
and
other
other
things
and
there's
probably
a
difficult
thing
to
get
right,
but
I
did
think
it
was
useful
to
have
something.
That's
very
simple,
a
very
simple
top-level
claim,
because
I
think
a
lot
of
reliant
parties
don't
want
to.
They
don't
want
to
see
the
the
hash
values
and
like
hear
that
six
of
them
were
matched
and
five
of
them,
weren't
and
or
something
yeah.
D
B
Thanks
lauren,
thank
you.
So
we're
gonna
go
to
tape,
requirements
for
you,
dave
theater,.
G
G
So
the
keep
working
group
has
a
set
of
requirements
that
have
gone
through
working
group
last
call
and
just
got
submitted
to
the
iesg,
which
are
the
abstract
requirements,
and
then
the
protocol
document,
which
is
still
under
in
progress,
then
it
maps
the
requirements
to
the
what
is
currently
listed
in
various
each
specs
and
so
what's
on
the
screen
here
is
not
what's
in
there
it
may
you
can
think
of
the
the
leftmost
column
as
being
what's
the
architecture
document
in
text
form
that
went
to
the
iesg
everything,
but
the
first
column
is
stuff.
G
That
is
still
you
know
flexible
and
we
can
correct
or
whatever
okay
and
so
the
point
is
the
typework
group
has
requirements
for
attestation
results.
The
attestation
results
in
teep
are
consumed
by
the
entity,
antique
that's
called
the
tam
of
the
trusted
application
manager
and
that's
what,
in
the
case
of
an
attestation,
failure
does
the
remediation
okay,
and
so
the
point
of
the
attestation
results
here
is
to
pay
attention
to
the
failure
results
and
to
be
able
to
use
the
results
of
failure.
G
That
says
this
is
the
current
state:
here's
where
it's
out
of
compliance,
I'm
going
to
kick
off
the
remediation
steps
and
that's
what
the
t
protocol
does.
Okay,
so
as
we
go
down
the
list
of
requirements
and
map
those
to
the
claims
this
table
or
a
version
of
it
appears
in
the
current
t
protocol
specification.
G
And
so
if
there
are
errors,
please
call
them
out
or
whatever
that's
fine.
If
there
are
gaps
and
so
you'll
notice
that
the
references
that
it
makes
to
right
now
is
eat
document
and
draft
bar
calls
rat
suit
claims,
and
so
one
of
them
is
the
rats
working
group
document.
The
other
one
is
an
individual
submission,
and
so
the
teep
requirements
is
that
we
have
something:
that's
a
working
group
document,
whether
it's
in
rats
or
elsewhere,
that
meets
the
requirements
on
the
left.
G
Okay,
so
again,
these
are
requirements
for
things
that
appear
in
attestation
results
and
you
notice.
These
are
not
booleans,
because
the
point
is
to
provide
details
when
you're
out
of
compliance
that
helps
you
get
back
into
compliance.
Okay
and
I
see
brendan's
in
queue.
So
I
will
pause
here
and
take
brennan's
question.
I
Hi
brandon
moran,
the
I
see
that
the
device
unique
id
is
at
the
top
and
I
I
think
it's
important
to
bring
up
in
case
it's
a
question.
I
I
don't
actually
see
a
need
in
suit
from
in
most
cases
for
a
device
unique
id.
I
think
that's
a
corner
case
in
suit,
so
if
there
are
particular
requirements
for
the
type
of
device
unique
id
that
gets
used
here,
I
don't
think
that
suit
should
have
a
strong
preference
on
that.
I
G
Yep,
I
agree
that
the
the
point
is
these:
are
requirements
from
teap
it's
up
to
rats
to
choose
how
to
address
these
and
as
I'll
get
to
later
on.
My
belief
is
that
most
of
the
things
should
be
things
that
are
not
really
teep
specific,
there's
a
profile
that
says
you
need
the
following
things
in
attestation
results
and
that
profile
is
type
specific,
but
based
on
previous
list
discussion,
I
don't
think
there's
anything
in
the
profile-
that's
inherently
only
usable
by
teap
and
so
we'll
get
to
that
in
a
minute
here.
G
Okay,
so
when
we
look
in
draft
birkhole's
rat
suit
claims,
okay,
it
has
two
types
of
claims:
there's
system,
properties,
claims
and
there's
interpreter
record
claims.
Okay,
the
interpreter
record
claims
are
clearly
about
sue,
but
the
parts
that
are
highlighted
in
yellow
there.
G
There
was
early
list
discussion
when
teep
first
introduced
these
requirements
about,
could
things
in
the
eat
spec
be
used,
and
the
answer
at
that
time
from
I
think
lawrence,
and
I
were
in
agreement
on
that
thread
that
the
things
that
were
sitting
in
the
eat
spec
could
not
be
used
as
then
specified,
and
then
hank
wrote
this
document
to
put
those
things
that
were
discussed
in
that
thread
into
this
other
document
and
that's
the
highlighted
ones,
I'm
not
going
to
comment
on
five
six
or
seven,
but
the
five
that
are
highlighted
in
yellow
are
the
ones
that
teep
is
currently
referencing.
G
G
Okay
in
the
system
properties
claims
the
ones
in
yellow
bear
okay,
so
really
the
question
is
that
teep
says
is
that
the
ones
that
are
in
yellow
should
be
in
some
document
that
it
can
reference
normatively,
an
ietf
document,
ideally-
and
it's
not
really
teep
specific
and
it's
not
really
suit
specific,
and
so
that
leads
us
to
the
next
next
slide,
which
is
the
question
which
is
a
dispatch
question?
G
Okay,
so
what
should
happen
with
this
document?
Okay,
there
are
at
least
three
options.
Okay,
one
is
okay,
rat
should
adopt
it,
but
some
of
those
claims
being
the
ones
at
the
bottom
on
the
previous
slide
are
really
suit
specific.
So
you
might
argue
that
that's
not
right.
The
second
option
is
well.
The
whole
document
could
be
adopted
in
suit
and
suit
is
actually
rechartering
to
allow
things
like
this,
but
it
has
some
claims
that
are
not
suit
specific,
so
that's
possible.
G
Okay,
but
the
top
ones
aren't
really
suit
specific
they're
things
that
could
be
usable
outside
of
a
suit
context.
So
you
really
want
stuff
in
a
suit
working
group
for
things
that
are
actually
system.
Generic
properties
and
the
third
option
is
well.
We
could
split
the
document
and
say
well.
The
suit
stuff
should
go
into
suit
working
group
and
the
rats
working
group
should
take
on
those
general
claims
that
were
the
ones
in
yellow
and
my
own
preference
would
be
c
with
the
general
claims
ed
under
the
eat.
Spec.
G
But
that's
a
preference
if
you
want
to
put
them
somewhere
else,
but
my
personal
preference
is
that
the
parts
that
were
highlighted
in
yellow
should
be
in
rats
and
the
other
parts
that
are
suit
specific
should
be
in
suit.
This
is
the
main
question
that
I
want
discussion
on.
The
rest
is
examples
and
what
you
know
specific
details
about
the
claims,
but
this
is
a
general
question
here
that
I
would
like
working
with
consensus
on
you
notice.
G
I'm
not
asking
for
a
document
to
be
adopted
here,
because
my
personal
preference
is
the
suit
working
group
should
adopt
this
document,
but
some
of
the
content
should
move
out
into
a
rat's
document,
which
is
my
opinion,
not
a
new
document.
I
put
them
into
eat
spec
itself,
but
I'll
leave
that
to
the
eat
authors
to
say
whether
the
eat
spec
itself
wants
to
be
defragmented
or
just
put
all
the
generic
claims
in
there.
I
will
leave
that
to
the
working
group,
so
this
is
my
main
question.
G
H
So
hi
thanks
dave
yeah,
I'm
happy
to
see
attention
to
this
idea.
H
H
Documents,
japanese
claims
are
suit,
specific.
G
H
G
H
Target
this
for
rats:
that's
why
rats
is
the
first
working
group
name
here.
So
it's
related
in
the
red
data
tracker.
We
could
split
it,
but
then
again
that
would
cause
confusion,
because
now
you
have
to
look
at
two
different
documents.
This
is
all
used
by
suits
or
suits
engineer.
Implementer
would
look
at
the
blob
of
it
and
now
would
have
to
dissect
where
to
find
anything
specific.
H
So
so
I
agree
with
you
also
that
as
the
yellow
items
that
you
the
tip
wants
to
use,
then
that's
why
we
call
them
system
properties
and
that
separated
them
from
the
interpreter
ones
are
more
generic
and
that's
intentional.
So
even
battery
life
is
is
more
generic
than
than
suit,
apparently,
and
so,
but
not
maybe
not
keep
specific.
So
so
the
the
actual
oil
system,
property
claims
are
suit
agnostic
as
to
be
emplaced
in
rats,
and
if
you
want
the
other
section
to
be
ensued,
I'm
not
strongly
arguing
against
that.
G
Is
I
I
I
now
understand
the
authors
want
a
my
personal
preference
is
c
and,
of
course,
b
would
be
up
to
the
suit
working
group,
but
I'm
saying
it's
not
out
of
the
question
from
a
suit
perspective,
given
the
recharger
that
will
be
discussed
tomorrow,
that
could
come
up
tomorrow
and
I'd
like
to
have
an
answer
before
that
discussion
tomorrow
in
the
suit
working
group
as
to
what
the
right
dispatch
answer
should
be
here,
for
this,
at
least
for
the
yellow
claims.
B
H
Option
a
yeah,
it's
profile
it
can
cannot
contain
the
world
and
and
and-
and
I
hear
people
arguing
for
it-
should
cross
a
finish
line.
So
so
we
want
to
don't
want
to
deliberately
overload
that
and
delay
that
so
so
it
is
plant
extensible.
It
has
all
the
extensible
mechanisms
in
there
and-
and
I
think
we
we
should
really
work
with
lawrence
to
make
this
seamless
as
possible
and
and
it
can
go
across
the
finish
line
only
months
later.
H
I
don't
know
so
that
would
be
my
right
ticket
that
because
we
also
need
an
example
that
eat
actually
can
do
that,
because
we
don't
have
a
each
edition
thing,
and
this
is
the
first.
G
Yeah-
and
I
have
a
slide
after
this-
if
we
get
to
it,
it's
up
to
the
chairs
whether
you
call
time
on
me
that
shows
the
example
out
of
a
deep
architecture
document.
Only
if
an
example
is
useful
to
this
discussion,
I
think
option
a
would
be
the
suit
profile,
which
is
at
least
the
student
interpreted
interpreted,
claims
the
bottom
half
of
the
table
of
contents
would
be
adopted
as
a
profile
in
the
rats
working
group.
G
Option
b
is
the
suit
profile
would
be
adopted
as
a
working
document
suit
and
option
c
is
to
split
it
so
that
the
suit
specific
parts
get
adopted
in
one
of
the
other
working
groups,
and
I
guess
one
could
go
into
suit.
One
could
go
into
rats
and
split
into
two
docks,
of
which
one
of
those
an
option
would
be
editing
it
into
the
spec
and
not
having
a
new
dock.
So
all
those
are
possibilities-
and
I
see
a
queue-
is
built
up
so
go
ahead.
Michael.
K
G
Go
back
one
slide
ned.
If
you
can
yeah
the
table
of
contents
slide
the
ones
at
the
bottom
go
back
to
the
table
of
contents,
one.
I
think
yeah.
B
K
Exactly
go
for
it
again,
so
you
know
those
are
really
attractive
named
things,
and
so,
unless
they
have
a
really
really
suit
specific
thing.
What
I
think
is
that
someone
else
would
never.
B
K
Read
the
read
the
document
and
go
hey.
Actually
I
want
what
suit
want
has
and
we'll
go
forward
or
if
it.
If
not,
I
think
that
there
is
some
advantage
to
our
whole
ecosystem
for
having
well
specified
claims
in
a
easily
findable
place,
and
so
that's
why
I'm
a
little
bit
more
prefer
to
say
option
a
even
if
that
means
that
you
know
we
say
these
are
suits,
are
type
specific
or
suit
specific
and
other
people
shouldn't
use
them.
K
But
at
least
that
description
is,
I
think,
really
easy
to
find
and
I'm
I,
but
if,
if
you're,
really
convinced
that
the
two
documents
will
you
know
go
through
faster,
then
I
have
my
my
doubts,
but
I
won't.
I
won't
sit
on
that.
I
won't
it's
not
a
it's,
not
a.
What
is
the
right
word?
It's
not
a
sword.
I'm
willing
to
fall
on.
B
F
Barely
the
main
thing
I'm
interested
in
is
the
claims
that
are
really
possible
to
be
generic
to
to
work.
Do
the
work
to
make
them
generic.
Like
you
know,
vendor
identification
seems
like
a
really
important
thing
to
be
done
well
in
wrath
and
in
eat,
and
that
seems
very
universal,
so
I'm
maybe
less
intent
on
which
document
it
goes
into
and
more
intent
in
that
it's
well
done.
So
I'm
basically
agreeing
with
a
lot
of
what
michael
said
on
that.
G
Okay,
okay,
then
pointing
out
by
flipping
to
the
slide
that
there's
one
other
ask
the
working
group
to
tie
into
this,
which
is
those
five
which
are
the
ones
that
were
in
yellow
before
plus
one
of
the
ones
in
eat
do
not
have
early
assignment
so
in
the
eat
document.
The
early
assignment
section
makes
early
assignment
for
a
number
of
things.
G
It
doesn't
do
so
for
one
of
the
things
in
eat
that
teep
depends
on,
and
so
that
leaves
six
being
the
five
in
yellow,
plus
the
one
that's
in
eat
already,
which,
if
I
remember
right,
is
chip
version
scheme
that
we
need
early
assignment
for
those,
because
there's
implementations
right
now
that
need
to
use
those
there
might
be
bugs
in
the
actual
example
here,
if
you
say,
because
this
is
a
simplified
example
in
a
real
example,
you
might
use
you
know
sub
modules
and
things
in
here
too,
but
in
the
simplified
example
just
to
make
it
easy
to
understand
this
kind
of
flattens
everything
and
puts
them
all
in
one
claim
set,
and
then
those
tbds
are
the
ones
that
are
blocking
implementation
right
now.
G
H
So
I
have
a
wild
idea,
so
maybe
we
just
introduced,
I
haven't
coordinate
with
this
brandon,
so
he
might.
I
don't
know
we
might
have
to
still
talk
about
this,
but
maybe
why
don't
we
pull
lawrence
onto
the
red
suit
claims
id?
He
can
govern
the
interoperability.
H
We
can
orchestrate
an
adoption
and
then
get
these
early
assignments
done
for
tip,
because
I
think
that's
the
actual
goal
we
want
to
achieve
here.
Early
assignments
of
dvds,
so
that
and
and
how
that
really
works
just
has
to
be
working
well.
Lawrence
has
the
overview.
H
G
Yeah,
so
my
personal
opinion
is
that
none
of
the
five
none
of
the
six
even
that's
listed
with
tbd
just
are
things
that
are
really
suit
specific
now,
maybe
the
wording
needs
to
be
updated
to
lawrence's
point
about
doing
the
work
to
make
them
be
generic,
but
my
personal
opinion
is
from
reviewing
all
the
drafts
in
question
that
every
single
one
of
those
that
is
in
on
the
screen
right
now
in
the
red
there
actually
belongs
in
the
document
is
not
being
suit.
Specific
there's
other
ones
that
are
specific
in
this
example.
G
G
F
F
You
know
the
more
open
space
and
then
you
you
have
to
have
a
transition,
but
that
transition
is
not
too
bad.
It's
on
the
receiving
side.
So
I
I
don't
see
early
assignment
as
a
blocker,
I
mean
I
actually
wrote
the
code
to
do
that.
To
do
that,
you
know,
and
it's
part
of
the
c
token
library
it
does
it.
So
I
assume
it
seems
like
you
can
go
either
way
on
that.
You
know.
Early
assignment
is
nice,
but
it's
not
required.
So
I'm
and
happy
to
take
wisdom
on
that.
But
that's
my.
G
Thought
you
need
to
take
it
to
the
list,
or
can
you
give
me
an
answer
right
now
on
what
should
happen
with
this
document?
As
far
as
what
the
working
group
thinks,
I
mean
we
wanted
to
confirm
stuff
on
the
list,
but
is
there
any
tentative
thing
or
do
you
just
want
to
do
it
on
the
list
and
they're
out
of
time,
or
how
do
you
know.
B
We're
running
out
of
time,
I
would
think
we
need
to
move
it
to
the
list.
The
comments
and
the.
B
Of
which
option
to
take,
although
option
b
seemed
to
seem
to
not
have
any
takers.
So
I
think
we
need
to
discuss
more
between
option
a
and
option
c
and
we're
going
to
run
out
of
time
here
in
seconds.
B
B
H
B
Okay,
so
without
it
we're
done
for
for
today's
agenda,
and
I
think
what
we
are
going
to
do
in
the
future
is-
is
plan
for
a
virtual
interim
so
that
we
can
address
some
of
the
topics
that
we
weren't
able
to
disposition
during
this
week's
meetings,
and
that
will
be
that
planning
will
be
forthcoming.
H
Yep
thank
thank
you,
kathleen
net
and
yeah
nancy,
who
is
not
here
with
us
anymore,.
B
Yeah,
thank
you,
matthew
and
roman.