►
From YouTube: IETF103-RATS-20181106-1350
Description
RATS meeting session at IETF103
2018/11/06 1350
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
So
we
have
all
sorts
of
kind
of
materials
prepared
for
you.
One
of
the
things
we're
gonna
talk
about.
If
we
get
there
to
the
end,
is
some
charter
text
and
that's
the
link
that
will
get
you
there
if
you
haven't
found
it
yet
on
the
mailing
list?
Of
course,
this
is
an
ITF
meeting.
So
the
note
well
applies.
Please
make
note
of
the
text
there.
If
you
have
questions
by
all
means,
ask
we
have
some
administrative
things,
of
course,
to
cover.
First,
the
blue
sheets
have
been
handed
out
so
they're
going
around.
C
A
Perfect,
so
we
have
an
agenda
here
that
will
bash
in
a
second
first,
we
wanted
to
just
explain
what
the
layout
is
and
the
thinking
we
wanted
to
first
have
a
little
bit
of
an
introduction
about
the
problem
statement.
We
want
to
talk
about
and
then
talk
about
some
relevant
work
after
we
do
that
we
have
a
block
of
open
mic
time
to
discuss
the
problem
statement
after
that
block
of
time
related
to
the
problem
statement.
A
We're
then
gonna
talk
about
potentially
starting
point
drafts
for
some
of
that
work
and
then,
after
that,
we
have
another
block
of
time
to
you
know,
respond
to
that
or
respond
to.
You
know
anything
you've
kind
of
heard
so
far,
and
you
know,
depending
on
how
that
conversation
goes,
we
may
dive
into
specifics.
So
it's
kind
of
the
chartering
or
we
may
be
still
working
to
polish,
what
the
scope
might
be.
Would
anyone
like
to
bash
this
agenda.
A
Hearing
no
we'll
proceed
forward
just
to
introduce
to
you
from
the
language
from
the
Charter
we're
going
to
talk
a
lot
more
about
this.
The
whole
intent
of
rats
is
about
remote
attestation
and
providing
a
means
for
a
relying
party
to
better
understand
the
other
half
of
its
conversation
to
understand,
with
whom
it's
communicating
and
getting
various
kind
of
statements
claims
with
high
confidence
about
what
that
system
looks
like
and
we'll
talk
a
lot
more
about
that.
A
If
you've
looked
at
the
Charter,
if
you
look
kind
of
looked
at
the
Charter
notionally,
five
things
have
been
tossed
out
that
we
could
be
working
on,
and
this
is
all
open
to
discussion.
I
can't
iterate
that
enough.
I
just
lay
this
out
for
you
to
understand
why
you're
gonna
be
hearing
kind
of
talk
to
the
subsequent
talks.
You
know
the
Charter
talks
about
things
like
you
know.
We
need
to
lay
out
terminology
and
architecture
for
this
space.
A
It
lays
out
the
need
for
an
information,
a
data
model
and
a
set
of
protocols
to
convey
that
convey
that
information,
and
so
the
drafts
you
see
listed.
There
are
potential
starting
points
for
some
of
that
work,
assuming
that's
the
work
that
we
wanted
to
take
on,
so
that
Orient's
the
drafts
that
are
on
the
agenda
and
because
this
is
above
what
we're
looking
to
answer
are
those
questions
up
there,
so
I
toss
them
up,
not
that
we're
gonna
talk
about
them
now,
but
towards
the
end
of
the
Boff.
This.
A
These
are
the
kinds
of
questions
we're
gonna
move.
We're
gonna
want
to
answer
related
to
do
we
understand
really
what
working
on
is
the
IETF
the
right
place
to
work
on
it
and
what
classes
of
individuals
would
want
to
what
individuals
r1
work
on,
what
classes
of
the
problem
whether
it's
create
those
drafts
or
review
those
strats?
A
So
with
that
we're
gonna
get
started
with
the
agenda
first
up
is
we're
gonna,
have
a
Hank
and
Ned
talk
to
us
about
the
problem
statement
and
again
framing
the
agenda
of
what
we
would
ask
is
let
Hank
and
Ned
get
through
their
material,
then
let
Eric
and
Hannes
get
through
the
material.
Please
only
ask
clarifying
questions,
and
so
this
will
be
a
block
of
a
balla
half
hour.
A
D
E
Yeah,
that's
a
deado
hi
I'm,
Hank
I'm,
one
of
the
proponents.
What
a
few
people
would
like
say
the
lead
performance
of
this
birds
of
a
feather
meeting,
which
is
a
second
meeting.
If
you
count
the
barb
off
in
monorail,
which
we
had
in
a
room
in
one
well,
unfortunately,
because
we
wanted
have
more
remote
attention
at
these
presents,
so
this
is
a
collaborative
effort.
As
you
can
see,
there
are
four
highlighted
proponents
myself
of
course,
and
then
there's
into
this
net,
yes,
general
electrics
for
advisement,
who
unfortunately
cannot
be
here
today.
E
So
in
order
to
start
where
the
problem
actually
lies.
There's
this
trend
to
say
35
years
ago,
something
was
in
today.
It
isn't.
This
graph
tells
you
that
there
was
the
assumption
of
an
attacker
model
35
years
ago.
That
channel
between
hosts
is
under
the
control
of
an
attacker
and
that
host
basically
is
not
so,
as
you
can
see
the
today,
this
converged.
We
have
conversions
most
everywhere
and
in
this
is
kinda.
The
trust
that
hosts
and
channels
are
not
under
the
control
of
attacker
is
basically
gone.
E
We
assume
both
are
always
potentially
under
the
control
of
an
attacker.
This
is
the
current
trend
forward
should
move
forward,
but
it
doesn't
thank
you
so
the
problem
and
the
problem
is,
there's
the
desire
to
understand
the
host
characteristics
now,
because
the
Internet
is
communication
between
peers
and
to
prevent
communication
between
peers
of
compromised
integrity.
Sometimes
I
do
not
want
to
tell
if
here
that
is
compromised
a
confidential
privacy
or
some
other
relevant
information
and
assertions.
E
The
content,
integrity
of
water
holes,
correct
X,
cannot
be
assured.
With
software
solutions
alone.
We
have
that
we
have
a
posture
assessment
with
procedure
that
is
called
Network
and
endpoint
assessment
has
agents
on
the
clients
and
on
hosts
and
servers
on
the
peers,
and
it's
aggregated
as
posture
information
and
as
trying
to
consolidate
it
correlated
and
give
you
a
bigger
picture
about
the
state
of
your
system
and
network
topology.
E
But
what
you
actually
need
is
assertions
about.
The
character
occurs.
What
appears
that
is
anchored
in
some
hardware
root
of
trust,
and
it
will
go
more
into
that
and
you
need
appropriate
means
to
convey
this
information
between
the
different
parties
that
do
these
remote
attestation
procedures
and
not
all
of
these
network
protocols
have
the
same
purpose
and
are
used
in
the
same
way
or
they
always
have
to
do
it
in
a
timely
and
secure
fashion.
E
Headaches
like
this
I,
don't
know
what
there's
not
next
sliding
so
I'm
unpacking
some
terms.
Iam
was
using
host
characteristics,
but
if
I
say
that
what
I
mean
is
a
system
component,
that's
defined
by
RFC
49:49,
it's
very
defined,
so
they
can
be
physically.
There
can
be
virtual,
they
can
be
nested.
It
takes
into
account
effect
of
all
the
other
old
glossary
that
hosts
are
rather
complicated
things.
E
Probably
they
are
aggregated
things
and
probably
they
are
more
complex
than
you
think
they
can
even
be
systems
like
120
hosts
that
are
hidden
in
a
single
finger
to
perceive
it
as
a
speed.
It's
a
pizza
box
also
I
want
to
unpack
the
term
post
characteristics.
I
already
mentioned
assertions.
Emotions
are
statements
about
something
that
are
not
accompanied
with
a
statement
of
validity.
So
again,
we
want
to
trust
something
he
want
to
know
it's
true
and
the
old
definitions
phase.
They
don't
have
with
us
an
extra
pizza,
so
we
use
routes
of
trust.
E
These
are
hidden.
Sometimes
you
don't
even
know
that
have
some
some
implemented
in
software,
some
implanted
in
hardware.
They
are
all
providing
primitives
that
you
trust
and
I
could
say
this
figuratively
blindly,
because
they
always
behave
in
an
expected
manner
and
they
are
never
when
the
misbehavior
of
them
is
never
detected
so
their
axiomatically
trusted,
and
that
is
a
concept
introduced
quite
a
while
ago
and
NIST
has
a
publication
about
it
and
as
discussion
showed
inside
proponents
and
and
other
bigger
groups
like
the
last
Bob
office,
basically,
everything
can
be
a
good
of
trust.
E
Your
notebook
could
be
it's
rather
unlikely.
That
is
really.
It
is
because
again
it
could
be
under
the
control
of
an
attacker.
So
it
depends
on
scope,
capabilities
and
applications
like
a
light
bulb
properly,
is
never
as
trustworthy
as
something
that
is
ships
approved
and
in
a
black
box
of
a
very
plain,
so
trusting
a
trust.
Eleuthera
of
trust
is
a
decision.
You
make
it's
a
management
decision
and
sometimes
very
founded
basis
to
make
this
decision
to
trust
something
in
the
nodes
of
the
internet
to
assume
they're
trustworthy,
and
sometimes
you
just
realized.
E
Okay,
it's
just
a
normal
host.
I
can
also
trust
that,
but
there's
a
different
level
of
insurance,
a
different
level
of
confidence
you
establish
here
so
always
I
was
talking
about.
We
have
to
convey
this
information,
so
if
you
have
peers
that
want
to
talk
to
each
other,
apparently
at
some
point
you
have
to
establish
that
yeah
trustworthiness
exists
with
your
communication
partner
that
you
appear
and
at
some
point,
probably
before
you
expose
vital
information
or
before
you
expose
information
that
basically
could
collapse
your
topology
on
a
control
plane
level.
E
If
you
expose
it
because
it's
light
falls
and
it's
falsified,
you
need
to
add
a
way
to
include
this
remote
as
a
station
procedures
in
existing
network
protocols
or
create
entirely
new
ones
to
address
the
needs
that
actually
defined
and
that
defined
in
greater
detail
in
this
worker
group
and
I
thought
I
wanted
to
go
to
the
message
formats,
because
that's
always
a
big
discussion.
Often
you
hear
and
asn.1
never
again,
and
sometimes
you
hear
that
you
hear
biggering
about-
has
to
be
even
readable
or
is
a
very
canary
compact.
E
You
know
how
you
you
structure
it.
So
this
is
a
this
is
a
detail
to
the
problem,
but
it's
a
vital
detail,
because
the
message
formats,
as
well
as
a
network
protocols,
are
the
basis
for
the
interoperability
of
all
that
stuff,
and
there
are
some
solutions
out
there
that
address
this
problem,
but
they
first
of
all
I,
never
heard
the
term
interoperability,
I,
think
and
also
they
are
very
problem
specific,
and
that
is
why
we're
here
in
the
ITF.
E
We
want
to
have
semantic
interoperability,
especially
about
the
things
you
want
to
prove
that
are
relevant
about
integrity,
and
we
want
to
have
very
defined
easy
to
parse,
IOT
friendly
and
even
super
complex
safety,
critical
system,
complex,
relevant
and
appropriate
message
formats
and
solutions.
So
some
of
the
real
friends
we
are
going
to
address
are
freshness
so
everything
about
integrity.
You
know
about
the
peer,
a
house
or
system
component
in
the
end
that
is
a
year
old
and
can
be
replayed.
It's
a
very
simple
example
of
no
use
it's
another
kind
of
being
attacked.
E
We
have
to
ensure
the
integrity
confidentially
and,
of
course,
there
are
privacy
concerns
to
this.
So
yeah,
you
guys
are
talking
about
about
identities,
a
lot
and
how
they
have
been
creatively
used
in
the
last
20
30
years
and
there's
always
some
privacy
concerns.
So
today,
that's
what
everything
we
do
here
has
to
be
vetted
at
least
once
thoroughly
with
respect
to
what
happens,
if
we
not
users
and
security
automations
or
the
IOT.
What
happens
if
we're
doing
this
was
financial
attraction
as
transactions
or
system
health
and
humans?
E
Again,
so
that's
so,
to
give
you
a
nice
right,
tiny
impression
of
Hollis
was
looking
like
the
last
15
years.
There's
that
we
have
a
components
on
the
right
side:
that's
a
verifier
that
knows
all
the
stuff,
how
it
should
be,
let's
call
it
a
roll
or
a
service.
Typically,
it's
a
verification
service
and
the
service
challenges.
A
newcomer
tell
me
about
you,
and
this
is
a
challenge
response
handshake
freshness
here
you
can
see,
there's
a
nonce,
so
the
nonce
included
in
the
challenges
which
arms
were
the
response.
E
So
you
know
that
at
least
this
answer
is
created
in
a
timely
fashion,
but
you
have
to
do
a
lot
of
entangling
our
food
of
trusts,
a
lot
of
cryptographic
procedures
in
order
to
prove
in
the
end,
oh,
no,
that
is
actually
the
worst
term
I
could
have
used
in
order
to
provide
evidence
back
to
the
verifier
that
can
be
appraised
and
based
on
that
evidence
you
can
make
a
decision.
I'm
I'm,
trusting
this,
and
what
is
the
level
of
confidence
in
my
trust
yeah?
E
Is
it
a
notebook,
there's,
no
proof
of
who
dove
trots
no
endorsements
of
any
of
its
components,
or
is
it
rather
safety,
critical
systems
and
the
military
system?
It's
if
there's
a
big
spectrum
here
and
in
health
systems
and
financial
systems,
and
even
systems
that
are
transitioning
to
the
internet,
because
they
didn't
had
one
and
a
significant
skill
before
rely
on
these
kinds
of
pool
of
trust,
because
they
will
be
attacked
by
something
that
is
state-of-the-art
today
by
introducing
something
other
people
had
for
the
last
five
years.
E
So
now
we
will
get
the
next
night
to
Ned
Smith,
because
he
will
tell
you
about
the
ugly
truth.
That
is
not
a
simplified
slide
here,
but
the
things
that
is
are
there
and
some
things
we
cannot
address
at
once.
So
we
will
have
phasing
in
this
work.
We
will
with
step
by
step,
because
if
we
would
try
to
solve
it
all
once
it,
it
seems
a
little
bit
instruction.
F
So
here's
an
example
everybody
at
the
station.
That
shows
a
little
more
of
the
detail.
So
you
can
see
here,
there's
actually
there's
actually
three
more
than
three
parties
in
this
example.
So
we
have
the
device
which
is
the
tester,
and
then
you
have
the
relying
party
or
the
verifier,
but
you
also
have
the
manufacturer
who's
going
to
play
a
role
in
this
and
then
in
in
the
sense
that
we
described
earlier
that
that
part
of
the
challenge
was
that
we're
combining
the
the
communication
components
and
the
device
components
we're
not
trusting
them
at
all.
F
So
there's
the
notion
of
the
device
manufacturer
who's
going
to
essentially
issue
some
sort
of
a
certificate,
and
that's
going
to
provide
that
certificates
of
could
provide
a
set
of
assertions
about
the
device
and
then
in
this
example,
we're
showing
a
subcomponent
which
is
a
root
of
trust.
That
also
has
some
assertions
that
are
made
by
a
root
of
trust
manufacturer.
F
So
you
sort
of
start
to
see
the
complexity
of
supply
chain
where
all
the
parts
that
make
up
the
system-
maybe
don't
come
together
at
different
times
and
there's
potential
for
sort
of
different
sets
of
assertions
about
the
different
parts
at
different
phases
in
the
supply
chain.
As
things
come
together
into
a
final
product
and
then
on
the
in
the
context
of
the
root
of
trust.
F
There
are
some
measurements,
which
is
essentially
the
true
measurement,
refers
to
some
ability
to
compute
a
hash
of
some
relevant
component
of
the
system,
for
example
its
firmware
and
then
there's
some
some
component
in
there,
which
is
doing
this
doing
the
evidence,
creation
or
collection
assembling
it
in
a
certain
way
and
then
signing
it
and
creating
this
thing
called
the
remote
active
station.
Think
of
that,
as
the
message
that
gets
passed
to
verifier
and
then
on
the
verifier
side,
there's
potentially
multiple
components
over
there.
F
G
E
E
E
That
is
very
important
to
highlight,
which
does
never
does
not
mean
that
we
will
never
come
through
points
like
how
does
a
suitable,
inter
supply
chain,
provisioning
list
mechanism
and
trusts
system
works.
How
is
a
root
of
trust,
able
to
assess
locally?
What
is
trustworthy
or
not?
Sometimes
you
are
just
don't
have
this
interconnect
here,
so
how
is
it
free
free
will
previously
deployed
with
protection
profiles.
How
is
it
verified?
So
we
are
talking
about
verification
service
before,
if
you
think
about,
for
example,
software
component
integrity.
E
Your
notebook
has
like
I,
don't
know
the
quarter
million
software
components,
I
think
a
lightbulb
will
be
a
little
bit
overwhelmed
being
a
verifier,
so
this
is,
it
has
to
be
offloaded.
This
is
a
birdie.
This
one
just
wants
to
have
a
interesting
and
tangible
information
bar
to
trust
worthiness,
but
maybe
it
has
to
be
detached,
we'll
be
roles
and
now
I'm
going
into
details
already,
but
I'd
really
wanted
to
highlight
we
defragment
the
problem
and
we're
starting
with
that.
E
A
H
A
E
I
A
K
K
I
sorry
I
couldn't
be
there
today
and
maybe
I
can
do
better
clicking
my
in
the
queue
buttons,
but
thanks
for
letting
me
talk
remotely
and
I'm
going
to
be
talking
about
rats
in
routers
and
switches,
which
of
course
is
why
I
called
my
presentation
compromised,
trustworthy
visibility,
working
systems,
I
probably
should
just
called
it
rats
and
routers
and
switches.
So
you
know
that's
where
rat
I
can't
see
the
slide,
so
I'm
going
to
just
say:
go
to
the
second
time
a
slide
of
the
agenda
slide.
You're.
K
Right,
obviously,
this
slide
and
the
compromised,
trustworthy
visibility
is
a
slightly
awkward
title.
I
initially
just
called
this
compromised
visibility.
However,
compromises
are
often
visible.
The
real
trouble
is
knowing
where
to
look
and
being
able
to
trust.
The
visibility
of
what's
going
on
is
is
the
hard
problem,
and
the
reason
you
know
talking
to
the
others
and
the
proponents
is
why
they
wanted
me
to
talk
now.
K
K
Nevertheless,
they
really
do
share
quite
a
few
characteristics
with
PCs
and
other
attested
devices,
and
and
what
a
girly
talk
about
now
is
some
of
the
things
that
bring
them
together
when
you're
trying
to
attest
a
router
and
switch.
You
need
to
have
several
bits
of
information
that
you
can
look
at
and
see
if
it's
compromised
or
not.
For
example,
is
there
a
known
good
value
to
your
software
boot,
something
that
is
a
known
hash
that
you
expected?
Is
there
an
imprint
value?
K
K
So
basically,
a
testing
switches
and
routers
mean
that
you're,
comparing
against
event
occurrences
and
put
values
and
no
good
values,
and
these
are
really
the
items
that
are
put
together
for
a
good,
a
testing
system
for
switches
and
routers
next
slide
now,
I'm
looking
at
switches
and
routers,
there
are
some
difference
from
PCs
and
IOT.
The
biggest
part
really
is
the
modularity
of
the
systems
and
the
size
of
the
systems
in
implementations
that
we
see
on
the
vendor
side,
we
can
break
that
down
into
various
categories,
such
as
what
are
the
secure
boot
items?
K
What
is
the
software
when
it
logs
the
hardware?
How
many
chips
do
we
have
to
track?
What
are
the
identity
of
chips
and
the
configuration
do
you
have
a
expected
configuration?
Has
it
changed?
These
again
are
things
that
are
showing
that
this
is
more
than
just
booting
time.
Integra
or
something
you'd
see
like
an
ima.
K
There
are
things
that
make
checking
out
routers
and
switches
a
little
bit
easier
as
well.
It's
not
just
the
complexity
of
the
monolithic
system.
You
also
have
lots
of
keys
or
other
items
that
you
have
to
track
in
a
system
which
is
fairly
predictable
versus
random
software,
that'll
be
added
potentially
in
a
in
a
PC
or
a
IOT
or
phone
device,
and
because
of
this
because
we
have
a
system
which
is
more
locked
down,
you
typically
have
less
stuff
that
you
have
to
check
out
from
unknown
software
running
on
the
device.
K
Now,
on
the
other
side,
we
do
have
to
check
a
number
of
things
that
are
a
little
bit
more
complicated,
or
at
least
from
my
perspective,
from
from
smaller
devices,
and
these
are
things
like:
do
you
want
to
attest
to
the
identity
based
on
the
adjacencies
of
the
routers
and
switches?
Next
to
you,
do
you
want
to
go
ahead
and
look
at
your
neighbors?
Do
you
want
to
attest
for
configuration
of?
Let's
say,
access
control
lists?
K
All
these
things
could
be
relevant
to
routers
and
switches,
and
the
big
thing
we
have
to
worry
about,
especially
with
routers
and
switches,
is
the
big
word
asynchronous
at
the
bottom
of
the
slide.
We
care
about
things
that
change
we
care
about
things
that
change
and
we
have
to
get
alerts
on
as
they're
happening.
This
does
make
stuff
a
little
bit
different
in
our
environment.
K
K
The
circle
on
the
top
left
with
the
red
shows
us
finding
potential
issues
with
four
out
of
six
devices
that
were
monitoring
and
those
devices
again
might
have
hardware
issues
or
software
issues
and
really
what
you're
just
doing
is
seeing
a
breakdown
of
those
routers
against
those
known
attack
types.
If
I
were
to
choose
one
of
the
routers
or
one
of
the
attacks.
K
What's
going
on
we'll
go
to
my
last
screen,
shot
so
slide
six,
and
in
that
screenshot
you'll
see
things
that
should
be
pretty
familiar
to
people
who
are
a
couple
with
remote
add
to
station'
we're
at
the
very
bottom
of
the
slide.
You'll
see
a
a
boot
status
of
failed
with
an
integrity
signature
and
a
nonce
that
was
provided
from
that
router
and
the
fact
that
that
boot
signature
the
file
boot
file
is
failed.
K
Just
lets
you
highlight
that
you
probably
have
something
going
on
with
your
router
and
switch
that
you
have
to
take
some
take
some
remedial
action
on
and
for
anybody
who
wants
to
look
more
and
learn
more
about
what's
possible
here.
I
do
have
a
link
at
the
bottom
of
the
slide,
but,
as
I
mentioned,
my
first
premise
of
what
I
want
to
do
is
fairly
short.
K
L
Howie
I
have
two
questions.
The
first
is:
can
we
go
to
your
the
force,
the
force
stage?
Oh
sorry,
the
full
page.
Okay
in
this
video,
you
have
lists
a
lot
of
fun
information
that
you
can
collect
to
do
the
demo
Tata
station.
My
question
is
I
see
some
of
them,
maybe
is
not
so
related
to
the
interpreted
integrated
track,
for
example,
some
configuration
or
some
some
interface
state.
So
so
so
are
you
going
to
just
the
collector
that
the
draw
information?
B
L
G
K
M
K
And
why
and
that
list
of
things
that
Frank
pointed
out
earlier
you're
going
to
be
point
pointing
to
lots
of
possible
information
which
could
be
identifying
the
health
of
the
system.
And
that's
why
I
heard
on
the
larger
size
of
things
that
we
might
want
to
attest
to
just
to
support.
What
was
people
are
talking
about
with
eat
earlier
and
having
a
standard
set
of
parameters
that
you
might
send
up
and
one
to
attest
from
that's
one
of
the
reasons.
I
use
the
larger,
more
targeted
set
of
future
definitions,
as
I
thought.
E
The
other
conversation,
so
this
is
Hank
from
the
floor,
and
yes,
of
course,
this
is.
This
is
not
all
correlated,
of
course,
but
it
is
based
on
if
you
start
with
remote
attestation
from
the
very
beginning,
and
you
have
the
high
confidence.
This
is
a
trustworthy
system
and
then
the
evidence
that
high
confidence
tells
you
some
of
things
of
this
quality
change.
E
Then
the
concern
is
very
higher
because
everything
has
been
actually
healthy
before
it's
not
just
you
got
data
that
was
false
and
now
you've
got
other
data
about
might
be
false,
so
the
difference
here
is
if
something
changes
in
this
timeline
Korell
computed
with
remote
Association
procedures.
It
is
very
more
of
interest
if
it
if
we
wouldn't
use
them
Thanks.
N
To
answer
a
Lisa's
question:
I
had
to
Eric
it's
for
the
same
reason
that
we
have
common
data
models
for
evaluating
operational
state.
We
want
the
same
for
the
same
reason:
we
want
it
to
be
interoperable
because
a
tester
and
the
testees
could
come
from
different
vendors,
and
you
don't
want
to
do.
Don't
want
to
do
attestation
based
on
the
vendor
that
st
is
coming
from.
N
O
O
On
what
type
of
hard
ways
is
running
on
what
type
of
software
is
running
on
the
service?
Don't
know,
wouldn't
it
be
great
if
we
actually
have
that
capability
and
there's
actually
a
document
that
few
folks
in
the
working
group,
then
I
was
working
through
put
together
called
device
posture
where
they
tried
to
come
up
with
some
of
that
information,
and
obviously
there
needs
to
be
as
some
security
protection
around
it.
O
That's
one
of
the
the
cases
that
we
are
looking
into
next
one,
the
Internet
of
Things
case,
is
it's
probably
even
simpler
to
ports
with
me,
Bosa
there's
a
white
and
red.
You
won't
see
much
more
than
that,
because
these
things
are
small,
even
though
it's
a
developer
port
basa
arm
cortex-m
microcontrollers.
This
is
a
new
generation.
Our
latest
our
latest
generation
called
v8
M.
O
This
one
is
the
earlier
generation
b7m
and,
if
you're
not
working
in
the
IOT
space,
that
means
exactly
sir,
to
you,
but
on
the
server
side,
if
you
have
devices
that
are
connecting
to
your
servers
or
work,
for
example,
to
your
home
appliances,
you
may
care
about
knowing
which
device
connects
to
you
what
hardware
capabilities
it
has
because
this
one,
the
red
board,
actually
has
trustzone
capabilities,
which
you
also
using
on
your
mobile
phone
and
the
other
one.
The
white
board
doesn't,
and
so
that's
good
to
know.
O
You
also
may
want
to
know
like
is
that
functionality
really
used,
even
if
it
has
some
hardware
security
feature,
is
it
actually
used,
because
obviously
the
software
matters
as
well?
It
may
just
completely
ignore
it
or
the
whole
thing
may
run
in
a
queue,
emo
image,
and
there
may
be
no
hardware
like
IOT
hardware
at
all
and
that's
something
we
would
like
to
communicate
securely,
obviously
and
having
a
standardised
mechanism
to
do
so.
That's
essentially
there.
A
L
Okay,
I
think
I
can
ask
a
more
question
now:
okay,
we
have
seen
at
least
the
two
use
cases.
Vine
from
the
network
device
and
another
is
about
IOT,
so
I'm
wondering
if
we,
if
we
cover,
if
we
include
so
many
use
cases
in
this
working
group,
so
can
we
produce
a
single
protocol
for
so
many
different
use
cases
I-I-I
think
that
maybe
they
are
a
different
government
and
different?
Is
I
fulton
so
that
concerns?
Maybe
we
can
produce
what
and
the
second
concerns
me
about
it.
L
If
we're
talking
about
a
network
device,
I
want
attestation
protocol
I
think
maybe
we
also
in
working
in
this
working
group.
Maybe
we
should
also
consider
the
backward
competitive
program,
because
if
we
want
to
this
because
there
are
already
a
lot
of
devices
destroyed
in
the
fear
in
the
network,
so
if
we
want
to
actually
address
run
from
our
side,
if
we
have
this
protocol,
we
want
it
protocol
to
be
very
easy
deployed
to
the
current
existing
devices
and
we
can
enhance
our
security
in
our
network.
A
L
Actually
I
I
I
remember
in
last
iik
meeting
we
proposed
the
individual
draft
about
the
and
every
environment,
the
use
case
about
the
limited
hesitation,
but
unfortunately
we
don't
present
in
Vista,
but
so
we
have
our
G.
We
have
network
device,
we
have
our
Fe,
so
a
lot
so
common
use
cases
yeah
thanks.
H
So
from
Microsoft,
and
we
do
things
like
Xbox
and
Azure
sphere
and
things
to
do
attestation
with
hardware,
it's
a
trust
we
deal
with
SGX
and
Trust,
so
and
and
so
on,
and
so
I
personally
have
at
least
some
familiarity
in
this
space.
I
may
not
be
as
expert
in
some
other
people,
but
I
have
some
familiarity
in
this
space,
and
so
I
wanted
to
talk
about
the
proposed
remote
attestation
model.
H
Then
you
don't
have
to
go
to
the
slide,
because,
with
all
of
my
familiarity,
I
couldn't
understand
that
slide
at
all,
and
so
I'm
not
going
to
talk
about
it.
I'm
gonna
talk
about
what
I
think
they
proposed
at
remote
attestation
model
ought
to
be,
and
maybe
other
people
can
tell
me
whether
it
maps
to
what
they
have
in
their
head
or
if
they
understood
that
slide
or
whatever
there's
three
entities.
Potentially,
that
I
think
are
useful.
There's
the
entity
that
you
want
to
figure
out.
H
It's
health
like
the
boards
that
Hannes
is
holding
up,
there's
the
entity
that
it
wants
this.
The
relying
party
that
it
wants
to
communicate
with
that
wants
to
tell
whether
that
thing
is
healthy
according
to
some
policy
and
then
the
third
entity,
which
will
often
exist,
but
maybe
in
some
implementations
it
doesn't.
It
is
an
attestation
server,
that's
what
supplies
to
the
device,
something
that
can
handle
the
growing
party.
H
Okay,
that's
the
architecture
that
understand
and
there's
other
you
know
more
completed,
complication
or
complicated
instantiations,
where
there's
like
multiple
of
them
and
chain
ones
and
so
on.
But
the
simple
case
is
only
three
entities:
okay
and
so
that
leaves
at
least
two
protocols.
There's
one
protocol
that
says:
I
am
a
device
like
Hana,
says,
read
board
and
when
I
get
something
that
I
can
supply
to
relying
parties
yeah.
This
is
one
that
don't
understand.
Okay
and
so
I
want
to
get
that
thing.
H
I
can
understand
pieces
of
this
right,
and
so
that's
where
things
like
Alyssa's
question
is
relevant.
That
says:
okay,
if
that's
the
manufacturer
between
the
device,
do
I
actually
need
interoperability
there.
Okay,
that's
the
right
question
to
ask:
okay,
my
personal
opinion
is
yes,
but
maybe
other
people's
opinions
may
differ,
but
that
is
the
right
question
to
ask
and
then
the
second
thing
is:
there's
a
protocol
that
goes
between
the
device
and
a
relying
party.
Okay,
that
protocol
is
thinks
that
device
is
already
doing
today,
typically
hey
or
maybe
something
in
the
future.
H
That's
not
doing
yet
there's
plenty
of
other
protocols
that
it
wants
to
communicate
with.
Okay,
whether
that's
you
know
co-op
in
some
IOT
cases
or
HCP
or
whatever
else,
okay,
and
so
it
wants
to
pass
this
to
that
instrument
best
this
to
the
relying
party
that
it's
already
gonna
communicate
with.
We
have
protocol,
they
both
know
and
it
may
be
already
a
standard,
maybe
not
okay,
and
so
this
goes
back
to
the
question
of
how
many
different
formats
do
we
need
right.
H
This
is
the
question
was
a
second
ago:
okay,
there's
a
large
number
of
different
protocols
that
already
exist
and
we're
not
going
to
reinvent
all
of
them
right.
This
is
the
IETF.
We
don't
reinvent
every
protocol
in
the
world.
We
try
not
to
by
oh
boy
the
ocean,
so
what
that
means
that
different
protocols
have
the
ability
to
do
different
things,
some
of
them
passed,
say
x.509
certain
past
JSON
web
tokens,
some
of
them
passed
see
where
web
tokens,
some
of
them
might
pass
epic
things.
Okay.
H
That
means,
if
you
want
to
use
this
as
one
of
those
and
you
don't
want
something
extra
complicated.
That
means
the
thing
that
you
want
to
supply
across.
There
is
one
of
those
aforementioned
things
that
you
can't
dictate,
which
one
it's
going
to
be.
It's
the
protocol
that
you're
going
to
use
that
dictates,
which
one
is
gonna,
be
okay,
so
that
means
that
I'm
in
favor
personally
of
saying,
yep
I
want
there
to
be
a
format
that
works
with
protocols.
They
use
x.509
service,
yep
I
want
there
to
be
a
by.
H
You
know
a
token
right.
I
want
there
to
be
something
that
works
with
the
protocols
the
past
year,
sound
web
tokens
whatever
it
is,
that's
a
common
mechanism
I,
don't
want
to
reinvent
I,
want
to
be
able
to
get
a
token
or
for
our
set
of
SS
station
claims.
That
is
in
that
format
that
I
can
supply.
That's
what
I
think
the
problem
statement
is
the
end.
A
B
H
Is
a
problem,
in
fact,
potentially
two
problems
that
I
want
to
solve.
I
think
I
personally
want
to
solve
a
problem
of
having
an
interoperable
protocol
that
goes
between
a
device
that
wants
to
be
attested
and
an
attestation
server
of
some
sort.
Okay,
that
is
there
to
get,
and
that's
a
station
token
or
whatever
term
you
want
to
use
and
then
I
want
to
specify
or
I
want
to
have
standards
for
the
token
that
you
supply,
where
there's
probably
multiple
formats,
because
they
got
to
be
used
in
different
protocols
that
already
dictate
different
formats.
P
You
hi
Elliott,
leer
Wow
am
I
glad
I
went
after
Dave.
It's
always
always
a
good
idea
to
go
after
Dave.
Just
a
couple
points.
First
of
all,
I
I
think
I
see
two
different
questions
that
came
out
of
this
presentations.
The
first
was,
if
I
understand
correctly,
really
I'm
in
a
known
state
and
have
I.
Has
that
state
changed
right?
P
It
has
somebody
monkeyed
with
a
state
in
a
way
that
that
I
can
notice
and
the
other
is.
What
is
it
that
what
does
that
state
consists
of
I
think
these
are
two
separate
questions.
I,
don't
know
if
they
can
be
answered
in
one
single
list.
It
want
one
single
bit
of
bag
of
bits.
If
you
all
Dave
in
terms
of
you
know
whether
how
how
its
formatted
and
or
encoded
it's
not
is
not
my
concern
at
the
moment.
It's
can
you
even
reduce
down
to.
P
Is
it
one
question
or
two
questions
that
you've
got
there
right?
Is
it
the
state
change
or
is
it
what
the
state
is?
So
that's
that's
one
point,
and
the
second
point
is
that
I
think
I
agree
with
the
I
also
agree
with
Dave
that
this
stuff
is
going
to
be
transported
in
different
ways
using
different
trust
methods,
I
think
in
all
likelihood,
and
so
I
have
this
exact
point.
We
have
this
exact
problem
actually
with
IOT
on
boarding
right.
It's
the
exact
same
problem
and
it'd
be
nice
as
we're
thinking
about
this
problem.
P
Not
bringing
on
boarding
here,
but,
let's
think
beyond
just
you
know,
let's
not
try
it
as
as
Dave
said,
let's
try
not
to
invent
too
many
new
mechanisms
and
if
we
can
use
if
we
can
think
in
the
same
dimensions
and
we
have
if
there's
the
opportunity
to
capitalize
on
that,
I
would
love
to
to
the
to
link
to
do
a
little
bit
not
tightly,
but
at
least
architectural
II.
The
dimensions
are
similar.
Okay,
so.
A
To
wrap
that
up,
you
would
you
would
also
assert
there
is
a
problem
here.
Your
view
is
that
you
dude
there's
two
problems
when
you
talk
about
formats,
there's
this
notion
of
detecting
the
change
in
stage
and
then
what
is
the
the
state
itself
and
you're
reiterating
also
that,
in
the
blob
of
bits
that
characterizes
one
of
those
kung-fu
formats,
there's
need
for
flexibility
on
what
these,
the
transport
that
ships
them
yeah.
J
A
A
G
Attestation
blob
in
the
center
right,
but
this
two
or
three
comments
I
want
to
make
one-
is
that
this
picture
has
this
device
manufacturer
at
the
top
right
and
I?
Don't
think
that
that's
necessarily
desirable
and
inflexible
enough,
because
for
two
reasons
one
is
that
well.
That
makes
that
few
places
basically
the
root
of
all
trust
in
the
universe
or
at
least
on
this
planet
and
that's
a
very
attractive
target.
G
But
it's
also
the
case
that
somebody
who
takes
possession
of
a
device
they
might
well
bear
well
go
through
and
do
their
own
checks
with
electron
microscopes,
whatever
right
and
they
might
and
say.
Well
now
this
is
actually
mine.
I
have
actually
checked
it
out.
I
want
to
make
these
be
mine
from
the
perspective
of
the
root
of
trust
and
so
I.
Don't
think
we
should
hard
code
that
that's
a
device
manufacturer
I,
don't
care
about
the
mechanisms
but
but
but
I
think
we
need
a
bit
more
flexibility.
G
Well,
I'm,
not
gonna,
say
the
onboarding
problem,
but
but
but
in
terms
of
the
architecture
right
there
is
something
there.
That
is
a
root
of
trust.
There
might
be
multiple
because
it
might
be
the
manufacturer,
it
might
be
the
owner
or
whatever
type
thing
right
and
thinking
about
they
could
be
more
than
two
I
mean.
G
Right,
the
other
one
I
think
is
also
terminology
one,
which
is
that
in
many
cases
we
talk
about
Hardware,
root
of
trust
and
I.
Think
that
that
might
lead
us
start
around
also
a
path,
that's
not
flexible
enough.
Just
from
a
terminology
perspective,
I
suspect,
a
TPM
chip
has
some
firmware
on
it.
You
can't
change
it,
but
I
suspect
affair
right
and
and
the
notion
that
yes,
there's
actually
different
degrees
of
tamper-proof
knows
whatever
we
associated
with
the
stuff.
Tpm
chips
is
upon.
G
A
TPM
piece
of
firmware
running
in
the
BIOS
is
a
different
one
and,
and
that
sort
of
brings
in
these
other
things
with
us,
Jackson
and
and
trust
stones
and
other
ways
of
implementing
this
stuff,
where
you
have
different
levels
of
tamper-proof
nice
built
into
the
system
and
the
third
one
I'm
bringing
going
back
to
the
privacy,
it's
very
good
to
bring
that
up.
I
think
that
we
need
to
think
about
that
more.
G
The
notion
that
I
will
disclose
all
assertions
to
everybody
that
I'm
going
to
talk
to
it
not
is
not
necessarily
good
from
a
privacy
perspective,
so
how
the
policy
is
thinking
about.
How
are
there
policies
in
the
system
not
to
random
web
server?
I
will
provide
some
assertions.
Maybe
I'll
provide
more
of
them
to
be
the
bank.
However,
I
know
that,
as
opposed
to
as
part
of
you
know,
being
part
of
a
management
system
where
my
my
generator
is
being
managed
by
the
generator.
R
Max
Pinocchio
led
several
comments,
actually
stole
most
men
about
the
privacy
issues.
I
think
it's
very
important-
and
you
know
I-
want
to
stress
that
that
aspect,
one
of
the
things
that
he
was
saying
and
I
totally
agree
with
it
was
they
they
fed
that
and
we
need
to
actually
tackle
the
problem.
Who
can
access
which
type
of
assertion?
Because,
as
you
were
saying,
some
assertions
can
expose
some
data
that
you
don't
want
expose
to
the
Internet
tokens,
for
example,
others.
R
Instead
in
local
conversation
with
some
other
artwork
that
you're
integrating
with
you
might
want
to
expose
separate
information,
and
that
is
something
that
probably
is
very
hard
to
do.
It
might
require
some
authorization
to
who
can
actually
request
and
remote
attestation.
Not
everybody
can
can
be
entitled
to
do
that.
R
The
other
one
is
you
know
to
protect
this
data,
we
need
to
use
some
form
of
cryptography
and
can
totally
rely
on
trust
anchors
at
some
point
and
now
in
a
open
environment.
That's
a
problem
right
because
you
need
to
be
able
to
distribute
these
trust
anchors
and
to
make
sure
that
I
can
verify
their
remote
attestation
somehow
right
by
means
of
cryptography.
So
this
is
probably
the
discussion
about.
The
protocol
should
be
also
taking
consideration
these
aspects.
How
do
we
trust
that
information?
R
How
do
we
build
a
trust
infrastructure
that
can
support
this
kind
of
remote
at
the
station?
And
the
other
thing
is
more
about
what
we
you
know.
Everybody
is
saying
we
already
have
a
lot
of
promoted
station
solutions.
Some
of
them
are
proprietary.
There's
probably
lots
of
patterns
around
that,
and
so
it's
probably
a
minefield
at
some
point.
So
we
have
to
be
careful.
One
of
the
questions
that
I
have.
It
was
about
something
that
was
say
then,
most
not
saying
we
start
with
the
protocol,
and
then
we
look
at
other
aspects.
R
In
my
experience,
most
of
the
solutions
that
you
know
do
remote
at
the
station.
What
they
actually
do
is
a
local
at
the
station
that
someone
can
access,
and
it's
there's
always
the
problem
of
time
with
jacket,
time
or
views
right.
So
you
verify
most
of
the
time
firmware
operating
system,
maybe
the
application,
if
you,
if
you're,
very
good
at
very
lucky,
but
in
a
multi
threaded,
Multi
multi
process,
multi-process
environment.
R
This
is
very
dynamic,
and
so
it
cannot
really
be
attested
reliably
or
you
know
sufficiently,
or
at
least
I
didn't
see
in
my
spirit,
didn't
see
any
good
solution
about
that.
So
maybe
try
to
define
what
what
are
we
trying
to
attest
right?
Are
we
trying
to
make
a
basic
at
the
station
that
the
device
was
booting
in
certain
way,
and
now
you
have
more
more
or
less
okay
or
are
we
trying
to
say
this
is
the
whole
status
at
this
time
of
the
device
right?
Those
are
two
very
different
things.
R
S
Bret
Jordan
I'm
really
excited
about
this.
I
see
this
as
being
something
that
can
be
used
in
in
many
spaces.
There
are
gonna,
be
some
challenges.
There's
gonna
be
some
things.
We're
gonna
need
to
work
through
and
there's
gonna
be
some
hard
problems
that
we're
gonna
have
to
answer,
and
some
some
really
hard
questions.
I
can
see
this
being
used
in
some.
S
The
work
that
I'm
bringing
to
the
IETF
through
course
of
action
and
playbooks,
but
I,
also
see
this
being
used
in
beyond
beyond
court
like
when
you
look
at
Google's
behind
Corp,
they
are
required
to
know
everything
about
the
in
device.
What
happens
when
you
don't
have
all
the
knowledge
about
the
end
devices
I
see
that
this
could
be
a
stepping
stone
for
getting
us
to.
You
know
a
next
level,
and
so
I'm
really
super
excited
about
this
I
fully
support
it
and
I
will
be
contributing
here.
E
Hi,
this
is
Hank
from
the
floor
clarifying
some
of
the
points,
so
I
heard
well,
of
course,
we're
focusing
on
a
set
of
network
protocols
and
formats
necessarily
we're
doing
protocols,
but
which
is
not
basically,
but
you
come
later,
but
I
want
to
highlight
before
now.
The
assertion
semantics
are
the
essential
basis
for
the
semantic
interoperability
apparently,
and
those
will
always
have
a
Privacy
annotation.
So
cements
with
semantics
of
assertions
can
be
totally
uncritical
in
one
domain,
but
absolutely
confidential.
Another
problem
domain
and
and
Suresh
or
Nestle
sorry
alexey,
was
pushed
the
idea
of.
E
Why
don't
you?
How
do
you
apply
all
these
required
things?
Consider
a
brewski
consider
Acme,
please!
This
is
a
I
think
that
was
coming
from
you.
So
and
yes,
of
course,
there
are
a
lot
of
existing
protocols,
but
this
is
most
certainly
not
phase
one,
but
we
are
aware
that
these
have
to
be
somewhere,
for
example,
protection
profiles
for
local
attestation.
Yes,
of
course,
he
aware
of
that,
and
and
yes,
this
is
done
in
box,
but
we
will
not
deal
with
how
to
supply
them
in
a
meaningful
interoperable
today.
This
will
always
come
later.
E
If
we
try
to
solve
everything
at
once
this,
this
is
the
implode
very
hard
very
soon.
So
this
was
the
biggest
thing
and
the
the
non
reinventing
the
view.
Of
course,
we
have
talked
by
never
other
some
slots.
We
can
put
stuff
and
is
very
important
to
us,
because
that
would
mean
a
lot
of
bickering
and
work.
This
is
futile
and
this
is
most
certainly
not
what
we
invent
here
to
do
so.
Yeah,
that's,
basically
the
biggest
things
I
wanted
to
highlight.
Also
to
Elliott's
point.
E
You
said
there
are
two
options
on
the
left
side
like
it,
where
your
questions
changing
and
then
that
one
and
then
there's
the
third
one,
that's
going
through
the
verifying
service.
That
can
be
very
big
thing.
As
how
do
you
compare
stuff
to
you?
How
do
you
check
that
evidence
is
actually
okay
and
and
again
the
relying
party
once
this
gray
area
is
adjust.
Eric
was
asking
this
the
green
or
red,
or
something
in
between
and
and
if
there's
something
between,
you
need
a
very
a
lot
of
complicated
verification
processes.
E
U
U
What's
what?
What
makes
a
jot
a
sec
event
token
right,
and
the
only
thing
people
could
agree
on
basic
is
that
it
contains
a
timestamp
of
it
with
a
particular
semantic
right,
and
you
know
that
doesn't
amount
to
much
so
I
think
maybe,
if
you
were
to
do
something
of
value
here,
is
to
write
down
the
architecture
for
like
a
best
practice
architecture
for
establishing
an
attestation
platform
or
not
at
the
station
system.
Right,
it's
all
about
signatures
X.
U
Instead
of
protecting
the
transport
right,
there
are
privacy
considerations
that
go
over
here
and
but
not
over
there
right.
All
of
that
stuff.
You
could
write
down
in
an
architecture
document
have
that
published
in
a
working
group
document
in
a
working
group
and
do
nothing
else
right,
and
at
least
we
could
like
not
have
a
repeat
for
these
kinds
of
working
group
in
a
lot
of
domains,
because
I
I'm
not
entirely
sure
that
this
is
like
valuable
as
a
broadly
scoped,
broadly
scoped
work
in
the
idea.
A
T
Being
a
duck,
so
I'm
really
happy
to
hear
that
we
had.
You
know
several
people
coming
up
and
you're
grading
that
there's
privacy
considerations.
Of
course
we
have
to
deal
with
that
and
also
you
know
the
same
statement
about
needing
some
sort
of
authorization
checks
for
who
do
you
actually
send
these
attestation
statements
to
because
you
don't
want
to
be
ISM
Oracle.
That
just
says
anybody
on
the
Internet
can
suppress
your
button
and
I
will
spew
all
my
my
data
at
them.
You
know,
of
course,
cos
the
devices
I
was
gonna.
T
Max
it
brought
up
the
question
of
you
know
you
are
we
trying
to
answer
the
question
of?
Is
this
device?
Okay
and
some
holistic
sense?
I?
Don't
think?
That's
something!
That's
really
possible
to
do.
I
think
that
the
scope
here
is
just
gonna
be
limited
to
you
know
here
is
some
data
and
some
cryptographic
assertions
that
chain
up
to
some
rooted
trust
and
the
verifier.
Has
this
very
fuzzy
you
know
risk
model
basically
to
try
and
make
its
decision
on
I.
Don't
think
we
can
try
to
say
yes
or
no.
T
This
is
good,
and
so
you
know
some
really.
With
that
verifier
fuzzy
risk
model.
You
know
the
verifier
can
choose
what
routes
of
trust
it
is
or
is
not.
Gonna
trust.
I.
Think
that's
important
to
remember,
and
several
people
also
spoke
to
the
question
of
you:
where
is
the
interoperability
gonna
be
here
and
I?
Think
there's
potentially
broad
scope
for
interoperability?
J
And
edlin
one
thing
to
bring
up
is:
there
has
been
work
going
on
in
the
w3c,
unverifiable
claims
and
so
they're
trying
to
do
is
a
data
model,
but
they've
chosen
this
nasty
thing
json-ld
and
so
that's
their
particular
model.
In
a
lot
of
cases.
It
doesn't
work
for
devices
and
things
like
that,
but
they
have
tried
to
lay
out
the
data
models.
They're,
not
looking
at
a
transport
they're.
Just
looking
at
the
various
data
models
for
for
claims
and
attestations
got
it.
So
some.
H
Although
you
might
want
to
say
what
here's
the
type
of
entity
that
I'm
talking
to
that
might
dictate
what
appears
in
the
token
that
you're
gonna
pass
off
right,
and
so
you
might
have
some
policy.
That's
done
at
that
level
right,
so
you're
passing
off
different
things,
different
types
of
entities.
So
if
you
do
that,
then,
if
you
can't
agree
on
all
the
stuff,
then
maybe
what
goes
in
there
as
a
minimal
set
is
very
small.
H
It's
the
fact
that
it's
signed
by
the
server
okay
and
that's
the
yes/no
is
either
it's
signed
by
the
server
that
you
trust
or
it's
not
signed
by
the
server.
You
trust,
and
if
you
want
to
be
more
complicated
that
then
you
can
add
in
a
security
level
or
something,
but
then
that's
what
gets
you
into
the
arguments
that
the
leek
is
talking
about
right,
so
the
simplest
possible
model?
Is
you
send
off
all
the
grades
off
of
the
server
either?
H
Gives
you
a
token
or
he
doesn't,
and
you
pass
that
off
there
lying
party
says
yep
but
see
they're
in
policy
according
to
that
server.
It's
not
that's.
The
simplest
possible
model
doesn't
care
anything,
but
the
timestamp
and
the
fact
that
it's
signed
by
the
server
said
error,
summary
okay
and
he
says,
and
then
it
looks
exactly
like
yeah.
A
Yeah
got
it
all
right,
so
thank
you
for
all
of
that
feedback.
On
the
problem
statement.
I
will
attempt
to
on-the-fly
summarize
what
everyone
has
kind
of
told
us
according
to
some
wide
bins,
I'm
projecting
kind
of
here.
So
we
predominantly
heard
that
mostly
folks
said.
Yes,
there
seems
to
be
a
unique
and
important
problem
starstar
with
kind
of
a
lot
of
caveats.
A
A
A
As
we
think
about
what
the
solution
is,
we
got
to
think
about
privacy
in
a
lot
of
different
ways:
let's
prevent
correlation,
let's,
let's
think
through
who
we
send
it
to
and
what
they
can
see
some
flexibility
on
the
device,
knowing
what
it's
gonna
pass
and
it's
not
a
one-size-fits-all
about
what
it
passes
and
there's
a
there's,
a
lot
of
related
work.
We
heard
a
lot
about
second
vents,
as
potentially
being
some
part,
some
part
of
that
same
problem
w3c
as
well,
and
then
open
questions.
We
heard
mentioned
a
couple
times
more.
A
W
Aaron
Falk
I
think
that
your
next,
the
last
bullet
that
you
you
you
don't
have
a
clear
understanding
of
where
interoperability
is
needed,
really
underlies
our
negates.
Your
first
statement,
which
is
that
there's
some
agreement
that
there's
a
unique
and
important
problem
I,
don't
think
that
what
I've
heard
in
the
discussion
today
is
that
there's
agreement
that
there's
a
unique
and
important
problem,
I
think
if
you
can
define
where
you
need
interoperability,
then
you'll
know
if
you
have
a
problem,
that
the
ITF
can
solve.
W
P
The
second
point
I
wanted
to
make
was
in
terms
of
the
architecture
I,
think
and
and
where,
where
there
is
some
flexibility,
how
we
can,
what
the
root
of
trust
looks
like
or
the
chain
to
that
root
of
trust
looks
like
how
that
is
anchored.
I
think
it's
also
an
area
in
which
we
may
not
be
able
to
to
nail.
One
particular
means
down:
this
goes
back
to
Eric,
Nord
Mark's
point
right,
which
was
is:
does
this
go
back
to
manufacturer?
Does
it
go
to
work,
or
does
it
go
to
some
local
deployment?
P
A
I'm
gonna
cut
the
line
in
response
to
kind
of
this
summary.
Everyone
aligned
by
all
means
gonna
proceed,
we're
again
in
terms
of
agenda.
We're
gonna
have
a
talk
about
one
draft
that
potentially
addresses
some
of
that
and
then
we're
gonna
open
up
the
line
again
for
all
sorts
of
comments
for
whatever
we
want
to
talk
about,
but
hi.
X
My
name
is
Michael
Richardson
in
the
anima
net,
comp
and
sixish
group.
We
wanted
producing
this
RFC
83
66,
which
is
the
voucher
artifact.
There
are
some
relationships
between
what
we
asserted
and
what
you
may
assert
to
two
years
ago.
We
were
quite
convinced
the
voucher
was
a
private
arrangement
between
the
manufacturer
and
the
vices
that
manufacture
manufactured
dr.
Zeus.
That
way.
But
the
point
was
that
we
we
believed
that
we
needed
to
transport
it
across
the
internet
and
that
beyond
saying
this
is
a
voucher.
X
Think
that
that
we
are
essentially
that's
the
difference
between
the
multitude
of
proprietary
verticals
that
have
done
attestation,
and
what
we're
trying
to
do
is
that
we
recognized
that
we
have
this.
We
have,
we
have
other
required.
We
have
other
devices
that
need
to
interact
with
those
statements,
at
least
to
record
them,
at
least
to
record
them
for
the
purposes
of
the
lawsuit
later
on,
okay
and
because
seriously
because
the
device
said
it
would
do
X
and
it
didn't
do
X
and
whose
fault
is
it
can
who
who
is
who
said
what
it
would
do?
X
What
right
so
I
think
that's
the
the
important
part,
and
so
even
if
we
wind
up
with
six
different
formats,
because
there's
six
different
verticals
were
working
into
the
semantics
will
be
the
same
and
we'll
actually
have
six
documents.
That
says:
there's
six
formats
and
that
kind
of
sucks.
But
that
may
be
the
reality.
So
that's
where
I'm
kind
of
at
and
and
we're
why
we
need
interoperability
and
I
want
to
further
suggest
that.
But
even
if
that
wasn't
an
issue
to
Alyssa's
point,
there
are
manufacturers.
R
R
Many
companies
actually
they're
trying
to
secure
more
access
to
their
network
and
with
the
number
of
many
different
devices
and
not
say
just
IOT
just
devices
having
a
mechanism
that
is
actually
interoperable
across
different
vendors
and
that
we
can
leverage
to
say,
I
put
you
in
this
particular
subnet
or
this
other
in
your
Wi-Fi,
because
this
is
more
trusted,
and
this
other
one
is
not.
Actually
it's
very
useful
and
I
think
that
it's
gonna
be
leverage,
but
as
soon
as
is
available.
So
the
point.
A
A
R
A
H
Gonna
give
you
the
same
answer
as
Eric
mark
mark
there's,
potentially
a
manufacturer
of
the
security
chip-
that's
relevant,
maybe
at
the
beginning,
but
certainly
at
the
end
of
day.
There's.
Whoever
owns
the
policy
for
whether
that
device
is
healthy
or
not.
Okay,
it
may
or
may
not
be.
The
device
manufacturer
may
be
the
owner,
but
somebody
is
the
owner
of
that
particular
device
that
is
in
charge
of
the
policy
for
whether
that
thing
is
healthy.
That's
who
runs
the
anta
station
Terry.
Okay
is.
A
V
V
Gonna
introduce
myself
so
I
was
at
Qualcomm
for
many
years
recently
left,
while
I
was
at
Qualcomm,
I
developed
it
basically
and
at
the
attestation
too
touken.
It
is
in
a
commercial
qualcomm
product
today
and
I'll
kind
of
go
into
some
of
the
background
for,
like
you
know
where
that
was
coming
from
and
what
we
did
there
so
so
this
is
the
the
original
version
of
the
slide.
V
The
it's.
The
three
parties
definitely
agreed
on
the
three
parties,
the
I'm
showing
entity
manufacturer
at
the
at
the
top
there
I.
This
should
be
looked
at
as
more
of
an
example
or
a
model
than
saying
it
only
can
be
the
entity
manufacturer.
Actually,
the
the
vision
here
with
eat
was
that
that
might
be
combinations
of
and
I'll
show
you
some
examples,
combinations
of
things
there
could
even
be
delegation
or
attestation
server
coming
from
a
chip
vendor
point
of
view.
It
was
interesting
from
a
chip
vendor
I.
V
Think
it's
interesting
to
note
that
Intel,
for
example,
opera
operates
the
service
there
with
EPA
Qualcomm,
actually
operates
a
service
for
this
sort
of
this
thing
and
I'm
gonna
Google
actually
operates
a
service
for
this
they're,
not
a
enemy
manufacturer,
but
they
do
care
for
Android.
So
the
point
here
is
that
there's
a
these
these
three
parties,
the
the
entity
they're
the
device
and
the
the
point
of
entity
here-
is
that
it
is
quite
open-ended.
V
The
relying
relying
party
has
to
get
some
key
material
from
the
third
party
up
at
the
top
there
to
be
able
to
verify
the
signatures,
but
I'm
purposely
open
about
what
that
crypto
is
because
there's
a
lot
of
different
possibilities.
There
symmetric
Keys,
asymmetric
based
on
x.509
or
based
on
something
like
ec
daa.
If
you're
gonna
do
privacy
now,
given
that
home
model
the
target
for
eat
now,
we
actually
brought
eat
as
a
draft
to
we
had
to
actually
had
a
boffin
montreal
as
well.
Actually,
rats
and
Eve
eat
arrived
at
montreal.
V
At
the
same
time,
we
chose
not
to
have
an
Eightball
here
kind
of
combining
that
so,
but
they
kind
of
came
came
to
this
in
parallel
eat.
Coming
from
the
mobile
world
of
biometric
authentication,
world
and
payments
world
very
different
world
from
the
kind
of
TCG
TPM
and
network
and
routing,
though
so
anyway,
the
the
the
interesting
part
that
was
proposed
for
Standardization
and
E.
V
Is
that
particular
token
there,
the
green
box
I'm
showing
right
there
and
in
particularly
the
claims
that
the
semantics
of
the
claims
in
that
box
or
the
things
and
and
I
think
that's
lining
up
to
some
degree
with
what
where
people
say,
there's
interest
in
achieving
interoperability,
the
the
key
material
exchange
on
that
seems
difficult
to
me
to
standardize.
At
this
point,
their
system
seems
like
there's
too
much
variation
going
on
too
many
options
and-
and
you
know
some
symmetric,
some
asymmetric
or
a
CDA.
V
There's
there's
many
options
there
and
the
idea
was
that
you
know
those
could
be
standardized,
maybe
in
a
second
phase
for
there
down
the
line
when
there's
more
understanding
about
what
attestation
is
so
I
got
to
eat
by
looking
at
Fido
and
the
proliferation
of
at
a
station
formats
in
Fido.
It
was
really
disappointing
to
me
because
it's
blowing
up
the
interoperability
of
Fido,
though
the
sort
of
the
last
one
that
got
me
was
the
you
know.
Moving
on
to
Android
based
attestation,
we
had
a
couple
of
standards
in
the
final
Alliance.
V
Then
they
kept
adding
them.
So
Fido
has
pluggable
attestation,
so
people
were
plugging
things
into
it
and
there's
a
couple
interesting
points
about
that
in
terms
of
the
fight
out
case
here,
one
it
has
pluggable
attestation,
so
it's
got
a
protocol
already
with
a
place
to
plug
in
and
attestation,
so
that
solves
in
the
fight
of
environment
that
solves
the
transport
problem.
It's
already
there.
V
V
So
eight
is
one
thought
is
that
it
could
become
the
standard
or
a
standard
another
standard
for
at
a
station
in
the
phyto
use
case.
In
that
case,
the
the
what's
going
on
on
the
phone
here
or
the
Authenticator
side
is
not
necessarily
that
there's
a
TPM
root
of
trust
you
you
could
do
this
with
trust
so,
and
you
could
do
this
with
SGX
and
people
do
do
it
that
way,
you
could
even
do
it
with
a
secure
element.
I
mean
other
yeah
there.
V
So
the
other
cases
there's
here's
another
case
of
a
real
deployed
at
a
station
service.
Android,
Oh,
key
and
key
store
has
a
way
to
attest
to
a
public
key
that
is
stored
and
controlled
by
a
biometric
authentication
in
the
Android
key
store
and
in
this
case
Google
operates
a
server
that
can
do
these
verifications.
Google
also
supplies
key
material
for
this
whole
loop.
So
now,
I'm
looking
at
here,
here's
one
world,
the
Android
world,
hundreds
of
millions
of
devices
deployed
here
using
attestation.
You
know
in
a
format
I
had
we've
had
some
interactions.
V
So
here's
another
example
and
what's
important
to
look
at
here
is
the
lower-right.
The
output.
There
is
a
payment
risk
engine.
There's
a
company
called
41st
parameter
because
they
have
41
parameters
that
go
into
the
risk
engine,
those
the
the
was
bought
by
experient
lee.
They
probably
up
to
more
those
those
risk.
Risk
parameters
are
browser
strings
all
kinds
of
really
low
quality
unsecured
stuff.
So
the
idea
here
is
to
get
them
better
data.
V
Here's
a
case
about
a
home
appliance.
Let's
say:
Maytag
has
a
web
service
that
they're
washing
machines
connect
to.
They
do
not
want
some
other
manufacturers
washing
machines
connecting
and
using
their
service.
So
they
need
to
know
those
are
Maytag
washing
machines,
so
they
in
here
it's
probably
a
really
low
security
thing,
because
it's
just
about
some
washing
machine
stuff
I
mean
sure.
V
Maytag
thinks
it's
important,
but
you
know
it's
not
a
$10,000
payment,
so
you're
really
just
trying
to
keep
track
of
manufacturers,
and-
and
in
this
case
I
don't
think
you
need
I
mean
the
only
software
running
on
the
device
is
from
Maytag.
So
you
don't
need
a
fancy
route
of
trust.
You
don't
even
need
to
partition
the
route.
The
attestation
signing
keys
from
the
rest
of
the
software.
V
In
IOT
a
lotta
you,
when
you
onboard
an
IOT
device
into
an
int
management
system,
you
need
to
know
something
about
where
that
device
came
from
the
IOT
devices,
in
this
case
I'm
showing
some
interesting
key
material
and
key
management
stuff
here.
So
all
the
IOT
manufacturer
does
is
put
in
a
256
bit
seed.
V
Phyto
also
operates
with
security
keys
like
little
USB
or
NFC
connected
things
here
they
probably
run
on
a
secure
element.
So
now
is
another
kind
of
use
case
here
where
you're
looking
at
the
the
implementation
is
all
on
a
secure
element,
so
they're
not
really
even
at
partition,
that
of
that
device.
It's
all
in
a
secure
element.
V
So
the
the
primary
goal,
with
least
by
thinking
about
eat,
was
the
things
we're
gonna
standardize
on.
Are
the
device
identity
I
mean
you
got
a
million
devices.
You've
got
a
million
serial
numbers
we
want
to
know
which
is
which
we
want
to
do
measurement.
So
that's
measuring
the
software
for
the
state
of
the
software
on
the
device.
V
That
could
be
one
time
at
boot
or
run
time.
You
know
once
a
day
we
want
to
know
boot
debug
and
configuration
States
twice
it's
important,
so
geographic
location
like
GPS,
coordinates,
inventory
of
device,
hardware
and
device
software
and
then
a
really
important
one
is
a
public
key.
That's
created
on
the
device
that
the
R
key
pair
that's
created
on
the
device
and
you
transmit
the
public
key
belief,
basically
believe
the
claims
should
be
generally
applicable,
so
not
specific
to
TPM
is
trusted.
V
V
The
idea
was
also
to
use,
see
war
claims
because
they're
very
flexible.
You
can
express
lots
of
different
data
with
them.
The
wound
one
a
standardized,
a
basic
set
of
claims,
but
we
want
to
be
very
flexible
about
the
claims.
I
think
privacy
is
an
interesting
point
here,
because
privacy
affect
is
affected
both
in
the
key
material
and
with
the
claims
ec
daa
gives
you
privacy
around
the
signing
system.
But
then
you
don't
have
to
be
careful
about
the
privacy
of
the
claims.
V
V
V
C
D
You
I
just
was
standing
here
waiting
for
my
open
mic
and
I
am
cursed.
Woman.
Thank
you,
so
I
just
wanted
to
make
one
minor
point
that,
because
we
have
been
looking
at
slide
wave
for
for
90
minutes
now,
and
people
who
are
making
slides,
of
course,
try
to
make
the
simplest
possible
picture,
and
so
in
these
slides
you
usually
see
one
server
doing
something
and
the
reality
is
that
is
not
the
reality.
D
So
even
even
Lawrence's
slides
had
some
cases
where
you
had
two
servers
and
in
general
you
have
to
expect
that
that
a
serious
attestation
system
has
a
few
entities
that
will
cooperate
in
creating
the
attestation
we
actually
need.
So
it's
that's
actually
one
place
where
we
need
the
interoperability
to
make
that
happen.
So
we
can
have
multi-stakeholder
sisters.
H
H
Okay,
it
was
also
the
line
that
was
showed
in
those
diagrams
that
went
from
the
relying
party
to
the
server
at
the
top
okay,
and
so
I
wanted
to
ask
about
that
line,
or
maybe
comment
on
that
line
and
said
and
say
going
back
to
Alice's
question
is
interoperability?
Need
it
there?
What's?
The
trust
model
is
the
assumption
that
the
relying
party
trust
the
attestation
server
in
this
and
because
what
I
got
out
of
the
last
presentation
was
the
implicit
answer.
Do
we
care
about
interoperability
there?
H
The
presenters
answer
was
no,
and
so
I
will
ask
the
rest
of
the
room,
the
people
care
about
interoperability.
In
this
case
it
would
be
line
number
two
okay,
because
I've
heard
every,
but
a
lot
of
people
say
I
want
interoperability
for
line
number
one
I
haven't
Ernie,
but
it
haven't
heard
anybody
heavy
will
articulated
argument
for
why
they
went
in
irritability
between
line
number
three,
but
line
number
two
I
haven't
heard
anybody
comment
on
at
all,
and
so
we
asked
of
the
implicit.
No,
that
was
in
the
eat.
H
U
I
actually
came
up
to
say
something
else,
but
I'll
see
if
I
can
I
think
experience
from
like
other
third
trusted
third
party
systems
and
in
identity
space.
You
know
it's
not
initially
important
to
have
interoperability
other
than
in
a
two.
That's
what
you
need
right
at
to
let
line
number
two:
that's
where
you
need
interoperability
from
the
start
right.
U
Well,
I,
so
I
I,
sort
of
sort
of
see
line
number
one
is
where
the
vendors
sort
of
the
existing
solutions
for
lab
today,
all
right
all
right,
I,
never
mind
I,
came
actresses,
say
something
completely
different:
a
lot
about
privacy
in
a
couple
of
the
slides,
I've
seen
lines
along
the
Rhine.
You
know
statements
along
the
Rhine,
so
we
can
deal
with
privacy
by
just
asking
the
user
by
asking
the
user
by
getting
consent
and
I
want
to
make
a
note
of
the
fact
that
consent
is
a
lot
more
difficult,
especially
in
legal
regimes.
U
In
the
you
we're
talking
about
free
and
informed
consent,
so
it's
not
actually
always
applicable
to
ask
the
user
for
permission,
especially
if
the
user
can't
say
no.
So
you
know
when,
when
you
write
privacy
considerations,
sections
for
stuff
like
this,
you
know
it's,
it
I,
don't
think
it's
okay
to
just
sort
of
point
to
some
sort
of
imagined
consent,
mechanism
and
I
use
that
as
a
cop-out,
we
have
to
be
a
little
bit
more
careful
than
that.
N
A
E
Though
we
were
talking
about
lines
and
how
important
they
are,
and
that-
and
these
are
the
call
lines
that
are
not
about
the
things
above
I
think
so
so
the
relying
party
is
relying
on
something
that
probably
is,
can
be
constrained
note
or
something
so
basically
incapable
of
doing
hard
work.
So
there's
the
attestation
server
I
guess
probably
this
is
the
verification,
server,
admins
yeah,
and
so
this
verification,
server
and
device
both
or
service
and
the
device
both
have
something
in
them.
E
The
route
of
trust
did
you
put
trust
and
then
there's
something
else
out
in
the
world
there
you
put
also
trust
and
that
some
some
chaining
into
the
rules
into
into
some
claims
and
to
include
some
values,
attestations
server
consumes
so
so
I
think
it's
important
to
say.
There
are
multiple
paths
here
that
we
have
want
to
actually
talk
about
right
now,
I
think,
and
they
are
not
in
this
picture.
So
can
you
quickly
summarize
which
boxes
are
missing?
There's.
E
E
B
V
All
right
so
I
do
think
interoperability
on
line
two
would
be
a
really
good
thing,
but
from
what
I
know
about
some
of
the
systems
I've
seen
deployed
the
it's
gonna
be
really
difficult
to
do
that
it
actually
has
what
happens
on
line.
Two
has
some
relationship
with
two?
What
happens
on
line
three?
How
do
you
identify
the
keys?
What
sorts
of
keys
are
there?
You
know
and
I've
named
symmetric,
there's
systems
that
you
are
using
symmetric
keys
for
at
a
station,
not
pretty,
but
it's
but
it's
doable.
V
There
are
systems
that
use
x.509
in
a
standard
kind
of
way.
There's
systems
that
use
public
key
in
a
non-standard
kind
of
way,
I've
seen
those
and
then
there's
things
like
ec
daa,
which
is
today
you
know-
and
you
know
until
in
a
bit,
so
it
seemed
pretty
difficult
to
try
to
tackle
that
problem.
At
the
same
time,
so
I
thought
tackling
number
one
would
be
the
right
thing
to
do
so.
I
think
it
is
important,
but
it
seems
a
really
difficult
thing
to
tackle.
V
Then
the
other
thing
on
privacy
to
respond
is
that
I
think
privacy
varies
tremendously
on
by
use
case,
like
on
an
Android
system,
where
you
have
a
device
that
talks
to
hundreds
of
relying
parties
and
preventing
tracking
for
on
those
ruling.
Parties
is,
is
critical
privacy
and
it
works
in
a
particular
way
for
a
light
bulb.
It's
really
different.
If
you're
using
a
banking,
app,
you've
already
signed
the
privacy
agreement
with
your
bank,
so
they
already
know
a
bunch
of
stuff.
So
that's
a
different
case.
R
R
Y
R
H
Dave
Taylor,
so
I
got
the
impression
that
different
people
have
different
opinions
as
to
what
line
two
might
be
and
I
started
off
this
discussion
when
I
came
up
like
before
by
not
having
mine
too
so
I
agree
with
this
comment.
That
said,
if
you
had
designed
a
system
that
the
attestation
server
gives
you
back
something
that
concludes
all
of
the
information
and
the
device
server
the
device
presents
it
across
line
number
one.
H
Then
two
may
not
be
necessary
in
there
and
I
think
Mac
said
the
same
thing
when
he
was
up
here
and
so
that's
how
I
started
off
Mike
and
thinking
and
then
this
other
line
says.
Would
you
do
this?
Okay
and
that's
where
I
think
that
the
that
one
possible
answer-
and
this
may
be
completely
different
from
the
case
where
somebody
lesson
you
I-
don't
know
if
that's
a
verification,
server
or
what
which
I
think
was
Hanks
boy,
but
one
case
for
line
two
might
be
because
we
talked
about
privacy.
That
says
well.
H
If
I
get
back
an
attestation
server
a
bunch
of
stuff
do
I
give
that
same
stuff.
Every
relying
party
answer-
probably
not
I-
want
to
give
different
things
to
different
people,
so
whether
you've
got
to
get
a
whole
bunch
of
different
things
back
from
the
attestation
server.
Alright
get
back.
One
thing
that
contains
no
information,
I
tell
they're
lying
party,
hey
use,
line,
two
to
go
and
ask
it
yourself,
and
it's
that
test
ation
servers
job
as
to
the
devices
job,
to
figure
out
what
that
relying
party
is
able
to
get
okay.
H
A
T
G
T
Know
has
talked
to
the
manufacturer
or
the
the
vendor
at
some
point,
maybe
just
provisioning
and
the
attestation
server
could
be
thought
of,
as
you
know,
also
controlled
by
the
owner
of
the
device
and
as
an
engine
that
applies
policy,
the
policy
being
determined
by
the
owner
and
so
you're.
Potentially,
the
station
server
could
be
accepting
a
lot
of
information
from
the
device
applying
policy
about
who
is
allowed
to
receive
what
information
potentially
could
be
condensing
down.
Some
of
that
information
produce
a
smaller
subset
for
output
to
different
relying
parties,
I'm
getting
nods
from
Dave.
T
D
D
A
Like
coming
out
of
the
problem
statement,
one
of
the
kind
of
the
key
issues
was:
where
do
we
need
interoperability?
So
what
the
line-
and
the
number
really
is
intended
to
talk
about
is
if
we
need
interoperable
to
work
on
Interop
between
you
know
in
the
case
of
device,
in
the
case
of
one
it's
device
and
relying
party
in
the
case
of
two,
it's
relying
party,
an
attestation
server
in
the
case
of
three:
it's
a
sensation,
server
and
kind
of
device
and
there's
a
whole
separate
conversation.
D
So
the
short
answer
is
all
these
things:
whatever
they
are
sign
something,
and
so
you
need
at
least
the
capability
to
actually
interpret
that
signature.
You
either
have
it
yourself
or
you
delegate
it
to
somebody
else
and
that's
the
second
problem
with
the
picture
it
has
one
box
on.
It
has
two
two
layers:
it
has
a
cat
layer
and
a
pet
layer,
so
the
the
cataleya
is
the
devices
and
the
relying
parties.
You
have
lots
of
these,
and
then
you
have
these.
D
This
powerful
closely-guarded
servers
down
there
and
the
problem
is
that
the
cattle
actually
need
to
talk
to
servers,
they
trust
and
the
device
in
the
relying
party
I
in
different
security
domains.
So
it's
absolutely
impossible
to
ever
have
this
situation
here
that
doesn't
work.
So
you
can.
You
can
always
include
some
of
the
the
pet
functionality
and
some
of
the
kettle's
so
have
a
relying
party
that
also
happens
to
understand
the
entire
world
and
and
throws
all
the
trust
relationships
and
so
on.
D
But
in
reality
you
need
more
than
three
boxes
and,
and
then
the
lines
also
start
to
make
sense
and
whether
the
the
pets
actually
need
to
talk
to
each
other.
That's
another
interesting
question,
but
really
the
interoperability
is
about
being
able
to
exchange
information
between
several
instances
here
and
not
trying
to
categorize
this
by
what
what
role
do
we
give
this
instance
in
this
picture,
because
the
pictures
Nina.
Z
Moriarty
I
think
the
claims
work
seems
like
an
interesting
starting
point
from
the
eat
right
because
it's
well
defined
they've
had
an
implementation
experience,
they've
played
with
it,
they
figured
out.
You
know
this
is
important
and
one
of
the
nice
things
about.
If
this
does
become
a
working
group,
you
can
expand
from
there
right.
So
what
makes
sense
after
that,
when
there's
more
implementation
experience,
so
just
my
two
sentences
that
might
be
a
really
nice
starting
point.
It's
well
defined
there's
experience
and
that
grow
from
there.
G
Eric
on
mark
yeah,
I
would
agree
with
that.
So
I
think
that,
in
terms
of
what
in
the
bigger
picture,
I
I
think
that
we
would
want
to
be
able
to
provide
here
something
where
there's
a
standard,
spaced
or
standard
set
of
api's
that
are
needed
to
go
after
the
use
cases
that
we
think
are
important,
all
right,
which
might
include
all
of
these
three
right
that
we
don't
have
to
start
doing
that.
The
based
on
the
discussion
I
hear
it
might
be
that
yeah
people
don't
necessarily
understand
what
these
things
actually
do.
N
G
The
information
that
flows
over
these
three
lines,
so
that
might
be
another
thing
that
a
working
group
could
do
is
I,
could
say,
pick
a
bunch
of
use
cases
and
draw
this
thing
and
actually
show
what
information
actually
flows
and
the
trust
relationships
or
whatever
right.
It
might
be
used
cases.
For
instance,
responding
to
Karsten
were
the
relying
party
and
the
device
or
a
key
under
the
same
ownership.
G
Might
there
might
be
interesting
and
you
could
have
different
things
in
that
case,
as
opposed
to
you
know
more
more
ad
hoc
relationships,
so
so
I
think
that
that,
if
you
could
start
with
the
the
sort
of
eight
piece
defining
that
format
and
then
in
parallel,
go
and
work
through
use
cases
and
actually
draw
a
bit
more
detail
about
information
for
incarceration
ships,
you
might
be
able
to
get
a
better
handle
of
the
stuff
going
forward
and
see.
What
are
the
next
set
of
things
to
Grafton.
P
Hi
Eliot
again
I
think
mostly
agreeing
with
Parker
with
what
Eric
said,
but
I
got
up
here
too,
because
Dave
seemed
confused
about
line
number
three
and
whether
there
needed
to
be
in
yeah
they
were
yeah.
Okay.
Well,
you
said
there
was
you
indicated
that
there
was
some
fuzziness
about
what
line
number
three
meant.
P
What
the
use
case
was
for
line
number
three,
and
maybe
it
was
my
own
confusion
as
to
what
those
components
are,
because
this
is
a
pretty
simple
diagram
to
be
fair,
but
I
want
to
just
state
out
write
a
clear
use
case
as
to
why
there
needs
to
be
interoperability
there
and
what
I
think
those
things
are,
so
the
device
is
the
device.
You
can
settle
on
that
part
very
good,
good
job
on
that
one.
P
The
attestation
server
is
the
thing
that
is
evaluating
the
claims
and
in
my
use
case,
that
thing
is
where
I
see
need
for
it.
It's
an
enterprise
element
in
which
it
is
attempting
to
determine
whether
device
is
safe
to
allow
onto
the
network,
okay,
so
the
device
and
the
attestation
server
are
at
least
likely
to
be
in
the
same
domain.
Not
a
hundred
percent
sure
right
all
right,
let's
say,
and
in
that
case
the
the
notion
that
there
would
be
that,
wouldn't
what
does
it
mean
for
there
not
to
be
interoperability?
P
V
So
here's
a
different
version
of
what
those
boxes
and
lines
mean
so
the
the
devices
there
is
a
chip
made
by
the
Qualcomm
or
an
in
tower
Infineon.
The
attestation
server
is
a
service
off
offered
by
the
chip
maker
and
line.
Three
is
an
internal
chip
manufacturer
step
so
and
then
the
relying
party
is
maybe
a
bank.
That's
actually
wanting
to
know
that
this
transaction,
that
they're
processing
originated
in
a
very
secure
part
of
the
chip.
V
So
the
chip
vendor
is
offering
an
open
attestation
service
to
thousands
and
thousands
of
relying
parties
and
similar
view,
and
this
is
Android
and
Google
with
its
service.
Where
line
three
are
the
attestation
server
is
operated
by
Google
line?
Three
is
Google,
supplying
buckets
of
keys
to
phone
vendors
and
line
two
is
again
like
banks
or
enterprises
asking
Google
what
you
think
of
this
device,
then
I
also
wanted
to
comment.
Ben
then
use
the
word
owner
to
me.
V
This
is
all
about
manufacturers
of
equipment
and
software
that
really
the
owner
of
the
device
in
terms
of
like
this
is
Lawrence's
phone,
or
that
is
that
that
phone
is
belong,
belongs
to
the
Marriott
Hotels
or
so
that
really
didn't
factor
into
this
very
much
at
all.
For
me,
owner
owner
ownership
was
not
a
thing,
so
we
would
just
ask
for.
B
E
I'm
rushing
so
this
is
Hank
on
the
floor
again.
So
I
think
the
discrepancy
between
Elliott's
use
case
and
Lauren's
use
case
shows
the
scope
of
the
thing
Carson
says
or
useful.
These
lines
can
be
interpreted
as
be
as
hard.
So,
yes
use
cases
will
define
a
good
understanding
of
what
actually
will
flow
in
these
lines
and
when
the
assertions
are
of
interests
to
be
secured
or
go,
they
internationally
are
just
other
a
relying
party
in
verify.
E
I
integrated,
isn't
there
actually
a
line
because
they're
the
same
system
component
and
and
with
respect
to
what
Kathleen
said
we
we
also
have
another
reference
protocol
implemented
because
yang
is
very
popular
and
challenge-response
remote
attestation
with
non
is
basically
the
old-school
way
of
doing
it,
though
there
is
a
draft
in
the
read
scope
that
is
implementing
Isaiah
exactly
that
already
so
there's
something
else
to
look
at:
it's
not
just
only
a
a
data
model.
That's
actually
it's
changed.
So
it's
a
model
data
opponent,
but
there's
something
else
look
at.
T
A
Okay,
so
we're
almost
out
of
time
when
we
open
this,
we
said
that
we
wanted
to
explore
kind
of
the
area
and
to
move
forward.
We
need
better
answers
to
those
questions
we
have.
We
have
kind
of
pop
up
there,
so
you
can
answer
kind
of
correct
me
here
where
you
disagree
to
the
question
of.
Do
we
think
we
sufficiently
understand
what
we're
working
on
I
think
there
is
significant
ambiguity,
kind
of
left.
A
You
know
some
of
the
questions
related
to
is
the
proper
tractable.
You
know,
since
we
can't
answer
number
one
we're
not
kind
of
there.
Yet
we
heard
we
heard
a
couple
folks
come
to
the
mic
to
say:
hey
they're
really
interested
in
their
work
and
they
want
to
contribute
and
they
saw
all
sorts
of
kind
of
applications.
A
So
that's
kind
of
nice
and
exciting,
which
seems
to
suggest
I
mean
there's
interest
in
doing
this,
but
there
really
is
some
problems
related
to
scope,
so
more
conversation
necessary,
and
we
would
point
you
to
the
draft
there
is
drafted.
I
was
gonna,
say,
there's
the
Charter
language,
so
there
is
kind
of
a
lot
more
description,
perhaps
kind
of
framing
about
what
is
on
deck
and
what
might
be
the
potential
work
in
that
kind
of
Charter
tax.
A
W
B
So
you
know
we
heard
that
there
is
interest.
We
heard
acknowledgement
that
there
is
a
problem
or
a
set
of
problems.
I
think
a
lot
of
the
ambiguity
is:
how
do
we
scope
it?
That's
something
that
we
can
succeed
as
an
initial
and
then
I
like
Kathleen's
suggestion
is
we
need
to
start
somewhere
and
then
we
can
grow
it
from
there.
So
would
really
encourage
everybody
to
participate
in
the
mail
so
that
we
can
shape
it
better
start
with
the
Charter.