►
From YouTube: IETF111-RATS-20210729-1900
Description
RATS meeting session at IETF111
2021/07/29 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
Okay,
I
think
we
are
one
minute
in.
We
should
go
ahead
and
get
started
I'll.
Do
the
welcome
ned
and
then
you
can
take
over
since
you're
running
the
slides
as
well
welcome
everyone.
This
is
now
our
second
session
for
rats.
If
you're
expecting
some
other
work
group
you're
in
the
wrong
meet
echo
with
that.
Let
me
just
turn
it
over
to
ned
and
he
can
run
us
through
the
chair
session.
Thank
you.
B
So
let
me
go
through
the
boilerplate,
just
a
reminder,
you're
being
recorded.
B
The
also
reminder
to
look
at
the
note
well
be
aware
of
the
the
the.
C
B
Well,
topics:
I'm
not
going
to
go
through
them
in
detail.
I
think
everyone's
familiar
with
them
and
then
keep
in
mind
in
terms
of
you
know
this
meeting
that
we
are
encouraged
to
use
headsets
we're
encouraged
to
mute
microphones
when
not
speaking,
we
are
automatically
generating
the
blue
street
blue
sheets,
which
is
nice,
and
then
we
are
we're
basically
using
the
the
chat
rooms
in
meat
echo
for
the
for
the
jabber.
B
So
we
we
will
encourage
folks
to
to
participate
there,
and
then
we
are
also
needing
volunteers
for
minutes
to
take
notes.
So
if
we
can
get
a
couple
of
volunteers
for
that,
that
would
be
great.
D
B
Thomas
thank
you,
and,
while
eric
speaking,
we
should
have
somebody
else
lined
up.
B
Okay,
great,
thank
you
everybody.
So
with
that
we
will
move
forward
with
our
agenda,
so
we
have
today,
essentially
that's
the
old
one.
So
today
we
have,
we
moved
the
open
mic
time
that
was
originally
scheduled
for
the
end
of
the
session
to
the
beginning
of
the
session,
simply
because
we
want
to.
B
We
ran
out
of
time
on
session
one
on
monday
and
we
and
we
we
want.
We
want
to
spend
some
time
making
sure
that
we
covered
the
station
sets
call
for
adoption
properly,
so
we're
gonna
spend
some
time
doing
that,
after
which
we'll
have
a
talk
by
eric
on
attestation,
results
and
trusted
path,
routing
followed
by
attestation
event
stream
subscription
and
followed
by
trusted
identities
from
my
link.
So
that's
our
agenda.
Do
we
need
to
modify
this
agenda
at
all.
B
C
E
B
That
was
a
question,
so
I'm
looking
looking
for
feedback
from
the
from
the
working
group
and
kathleen.
Certainly
you
can
join
in
if
you
want
to
sort
of
summarize
where
you
think
it's
at.
C
There's
only
minor
updates
needed
for
the
next
version.
As
far
as
I'm
aware
so,
mostly
language
pieces.
To
date,
one
person
is
starting
to
look
at
it
and
at
least
one
in
terms
of
implementation
and
I've
added
a
second
author,
so
antonio
fontes
is,
has
agreed
to
be
an
author
and
had
provided
some
input
on
it
as
well.
E
C
C
E
Forgive
me,
it
sounds
to
me
like
we're,
trying
to
hit
the
same
a
similar
target
that
we
all
agree
that
having
everyone
assess
verification
from
a
device
with
the
broad
range
of
things
that
might
be
involved
is
not
something
that
you'd
want
to
distribute
across
an
entire
system
or
a
network,
but
that
there
would
likely
be
verifiers
that
produce
summary
results,
and
I
think
that's
what
eric
was
trying
to
get
at
in
in
his
draft,
and
I'm
not
sure
I
understand
yet
what
the
difference
is,
whether
it's
you
know
whether
you're
looking
at
it
as
a
system
view
or
well
I
mean
eric's
work
is
not
actually
a
device
view.
C
Yeah
so
he's
just
updated
it
to
align
it
to
the
executive
order.
I
I
probably
could
have
and
should
have
done
the
same
thing.
So
you
know
I'm
looking
at
a
moving
target.
C
C
C
C
Know
I'm
seeing
a
bunch
of
differences,
so
I
I
didn't
realize
he
had
just
done
an
update
too
so.
D
Yeah,
I'm
happy
to
talk
some
more.
It
might
be
good
after
we
go
through
the
attestation
results
in
terms
of
sets.
We
really
do
have
a
couple
different
sets
that
we've
proposed
and
are
trying
to
encode
specific
objects
on
they're,
broken
between
identity
and
verifier
at
the
station
results
and
and
also
freshness
indicators.
So
the
draft
that
we're
about
to
go
over
is
really
about
what
does
a
verifier
have
to
help
create
in
order
to
give
something
the
relying
party
can
consume?
C
Objectives
on
the
sets
is
I
mean
it
is
a
little
different
right.
It's
too,
it's
meant
to
be
a
small
draft.
As
a
former
ad,
I
really
liked
small
drafts
that
got
to
the
point.
C
So
if
we
merge
them
it
won't,
it
won't
be
that
so
I
think,
there's
still
a
distinct
point
in
my
opinion,
in
that
this
is
looking
at
existing
industry,
recognized
benchmarks
like
disa
stigs,
cis
benchmarks,
and
even
you
know
the
the
tcg
standards
that
get
published
and
so
you'd
be
able
to
align
your
set
that
gets
published
to
those,
and
it's
concisely
around
that
point.
So
I
think
there
are
enough
differences,
even
though
they'll
be
aligned
and
likely
be
used
together.
A
Okay,
so
I'm
gonna
call
time
right
now,
just
because
we
have
a
full
agenda
so
kathleen
it
seems
like
we
need
to
have
more
discussion
on
the
mail
list,
especially
to
the
rationale
of
where
these
two
drafts
are
different.
Complementary
or
not,
because
I
think
I'd
like
to
hear
eric's
presentation
on
the
attestation
and
maybe
that
will
help
clarify
or
not
to
the
rest
of
the
participants
as
well
before
we
can.
C
Issue
that
the
call
okay
and
if
there's
time
to
circle
back,
I
think
that
might
be
useful,
because
I
think
the
points
are
distinct
right
and
so
do
you
want
one
big
draft
and
to
merge
this,
or
can
we
keep
those
points
distinct?
I
I
personally
always
liked
the
distinct
points,
just
because
the
gra,
the
draft
is
clear.
It's
easier
to
update
it's
more
manageable,
so
I
you
know
the
point
in
it
is
different.
B
Okay,
so
we
may
have
time
at
the
end
of
the
third
session
if
today
we
run
short,
we
may
have
time
at
the
end
of
this
session,
but
we
won't
know
till
we
get
there.
B
Sure,
okay,
so
let's
jump
into
attestation
results
and
trusted
path;
routing
eric.
F
D
All
right
so
hi,
I'm
eric,
I'm
speaking
on
behalf
of
the
team
of
hank,
thomas
thomas
and
vincent,
and
this
draft
is
draft
version.
Zero.
One
of
active
station
results
for
secure
interactions.
D
It
was
originally
in
draft
zero
zero
at
the
station
results
for
connectivity,
which
says
how
do
I
make
a
connection
between
two
devices
and
know
that
that
connection
is
to
a
secure
element
on
the
other
side,
so
you're
effectively
a
testing
the
remote
device
on
the
connection,
as
some
people
pointed
out
after
the
first
version-
zero
zero?
This
really
wasn't
just
for
connections.
D
It
could
also
be
also
for
interactions
that
are
connectionless,
and
so,
if
you're
able
to
identify
it,
that's
a
good
thing.
As
a
result,
after
you
know
starting
the
interactions
we
had
people
who
are
chip
vendor
people
like
vincent
and
thomas,
as
well
as
academia,
security
and
vendor,
and
so
we
all
have
been
working
pretty
well
on
doing
this,
I'm
just
the
speaking
head
for
for
today.
D
There's
really
a
few
things
which
are
in
this
particular
draft.
The
things
that
are
in
the
draft
are
object,
definitions
and
soon
encodings
for
the
attestation
results
that
are
needed
effectively.
The
verifier
claims
that
are
being
made
to
support
secure
interactions
between
a
tester
and
relying
party
so
that
you
know
that
the
relying
party
knows
who
the
attester
is
and
what
kind
of
state
the
verifier
thinks
that
a
tester
is
in
there's
other
things
beyond
that
very
first
thing,
which
is
what?
How
do
you
encode?
Those
attestation
results
and
that's?
D
How
do
you
augment
the
attestation
results
to
improve
speed
and
scale,
we'll
talk
about
that,
as
well
as
a
state
machine,
a
generic
state
machine
on
the
relying
party
so
that
you
know
how
to
appraise
attestation
results
when
they
come
in
to
the
relying
party
and
that's
actually
a
little
bit
more
complicated
than
it
might
seem
at
first,
because
you've
got
to
be
able
to
verify
the
freshness
and
a
lot
of
other
things
as
well.
Now
there
are
two
implementations
of
this.
D
The
first
one
is
trusted
path,
routing
which,
as
a
proprietary
implementation,
if
I
have
enough
time
today,
I'll
show
it
running.
If
I
can
share
my
screen
at
the
end
of
the
second
session,
I'm
talking
about
there's
also
another
implementation
of
this
project,
verizon
which
thomas
facade
has
been
working,
and
while
this
is
an
older
version,
slide
he's
hoping
for
the
open
source
stuff
to
be
adopted
by
the
confidential
computing
consortium.
D
D
D
You
can
see
things
like
qualcomm
chips,
apple
chips,
intel
chips,
you
name
it
their
number
of
chips
out
there
that
can
do
at
the
station
is
large,
additionally,
as
you're
trying
to
get
to
a
relying
party
you're
going
to
find
that
there
are
different
applications
running
in
different
testing
environments
that
are
going
to
provide
their
attestation
results
or
try
to
prove
their
trustworthiness
to
a
relying
party,
and
a
of
relying
party
really
can't
understand
an
infinite
number
of
language
permutations.
D
There
really
have
to
normalize
the
definitions
of
certain
claims
so
that
you
can
figure
out,
as
you
go
from
chip
to
chip
to
chip,
what
you're
actually
asserting
as
the
trust
posture
of
that
ship,
and
that's
really
what
this
draft
is
about.
How
do
you
take
a
relying
party
and
deal
with
a
whole
different
set
of
attesting
types
and
not
have
to
translate
between
them?
This
becomes
very
important
when
you're
having
a
chain
of
attesting
environments.
D
Now,
what
might
be
trusted
by
the
relieding
party
really
falls
into
three
categories?
Is
the
identity
of
the
trying
of
the
relying
party
what
you
expect
and
that
identity
could
be
a
hardware
type,
a
software
build
we're
not
really
trying
to
do
anything
other
than
identify
the
types
of
identities
in
this
draft.
D
What
we
are
trying
to
do
is
identify
the
specific
verifier
appraisals
that
might
be
interesting
software
integrity
configuration
being
okay,
you
know,
did
you
recognize
the
identity
of
the
of
the
attester?
These
are
all
things
that
we're
trying
to
get
specific,
encodings
for
and
also
freshness
things
like
non
time.
Stamps,
there's
really
several
categories,
three
categories
of
things
that
we're
trying
to
get
trusted
at
least
three
and
then
we're
trying
to
find
out
what
do
we
do
to
encode
these
to
make
sure
there's
commonality
between
different
environment
types?
D
So
this
is
really
about
getting
shared
definitions
of
the
structures
coming
from
the
verifier
and
eventually
to
the
relying
party
that
will
allow
you
to
scale
up
at
the
station
in
a
heterogeneous
set
of
chips.
Doing
this
will
help
scale
and
interrupt
you.
Don't
have
to
worry
about
transcoding
between
different
language
types
and
the
encodings
can
be
a
whole
lot
of
things,
including
e
yang
ctdl.
If
we
get
the
generic
definitions
done
properly,
all
right
next
slide.
D
Now
the
verifier
itself
has
to
come
up
with
what
those
claims
are,
and
we've
talked
about
this
in
previous
rep
sessions.
You
want
to
be
able
to
identify
things
like
is
the
hardware
authentic
configuration
secure,
are
there
anomalies
in
the
verifier
and
make
them
an
attestation
results?
Those
are
then
returned
to
the
a
tester
and
signed
by
the
verifier
so
that
you
can
keep
a
running
list
of
the
current
state
of
attestation
from
an
external
device.
D
Now,
once
you
understand,
the
kind
of
trustworthiness
claims,
whether
it's
identifying
the
understanding,
the
identity
of
the
testing
environment,
whether
it's
identifying
that
the
hard
work
is
authentic,
whether
you
can
verify
the
executables.
There
are
different
capabilities
that
are
supportable
for
those
claims
out
of
different
compute
environments.
D
Process-Based
confidential
compute,
like
sgx,
will
do
very
easy
things
in
terms
of
identifying
the
instance
of
running
code.
It
might
be
a
little
different
on
an
hsm
or
tpm
type
device,
but
in
general
there
are
different
types
of
claims
that
you
want
to
support,
and
this
draft
has
a
starter
set
of
affirming
and
detracting
claims
and
what
and
how
they
might
be
accomplished
across
different
ships,
and
I
see
dave
in
the
queue.
G
D
All
right,
fair
enough,
we
could
we
could
do
that.
D
D
Now
it's
important
to
know
that
normalizing,
trustworthy
claims
does
not
mean
that
the
relying
party
has
to
handle
each
claim
the
same
way
from
the
different
types.
You
know
it's
just
the
kind
of
thing
where,
if
a
confidential
compute
environment,
like
trust
sooner
sgx,
is
asserting
confidentiality,
you
should
trust
that
a
lot
more
than
if
you're
setting
confidentiality
from
a
tpm
type
device.
So
each
of
the
relying
parties
out
there
have
to
understand
the
type
of
intestine
environment
as
they
digest.
D
These
claims
and
that's
important
to
know
that
you're
not
really
just
accepting
and
handling
what
the
verifier
says
in
the
relying
party
you've
got
to
understand
the
context
of
the
identities
in
which
it's
looked
at
and
so
for
each
verifier
or
a
verifier
version
or
an
appraisal
of
a
specific
type
of
a
test
device.
They
all
are
going
to
be
looking
at
the
claims
differently
on
how
to
process
the
information
coming
in
based
on
these
encodings
next
slide.
D
Now,
as
dave
correctly
mentioned
right
now,
we
believe
the
best,
or
at
least
the
best
model
that
is
relevant
in
the
space
is
the
passport
model.
D
The
trustworthiness
claims
themselves
are
not
specific
or
required
to
be
in
the
in
the
passport
model,
so
we
can
make
it
generic,
but
if
you
assume
a
passport
model
like
we've
done
in
much
of
the
document,
you
can
go
ahead
and
receive
attestation
results
in
step,
two
from
a
verifier
just
like
you'd,
see
in
the
draft
rats
architecture
and
then
add
additional
evidence
to
those
attestation
results
to
prove
that
the
relying
party
and
the
verifier
itself
is
getting
the
last
and
latest
bit
of
information
from
the
attester
to
show
I,
my
relying
party
is
providing
a
nonce
that
relying
parties
nonce
is
entangled
with
the
attestation
results,
providing
additional
evidence
that
can
be
evaluated
at
the
relying
party
itself,
and
so
what
you're
seeing
here
is
the
every
once
in
a
while
you'll
get
the
verifier
making
out
to
station
results
and
very
frequently
you
might
have
the
verifiers
connecting
to
the
attester
to
get
the
latest
attestation
results,
and
that's
really
what's
going
on
here.
D
What
we
expect
the
verifier
runs
far
less
frequently
than
the
relying
party
be
and
they're
going
ahead,
and
the
verifier
b
going
ahead
and
getting
the
latest
augmented
evidence.
David.
G
So
I
don't
think
this
affects
the
content
of
the
the
main
point
of
the
stuff,
but
in
terms
of
diagram,
I
don't
think
this
is
the
passport
model
you're
showing
at
all.
This
is
actually
a
hybrid
model,
and
that's
because
you
show
verifier
b
on
there
right
and
verifier
being
on
the
relying
party
side
means
this
is
by
definition,
a
hybrid
model,
there's
actually
a
passport
model
for
verifier,
a
and
a
background
check
model
for
verifier
b
and
you're
composing
those,
and
which
is
perfectly
fine
that
you
can't
do
that.
G
I'm
just
saying
the
label
on
the
slide
is
not
quite
correct
and
the
fact
that
you're
actually
sending
it
to
verifier
b
illustrates
my
point
as
to
why
it's
actually
not
passed
right
model
specific.
So
again,
this
is
just
an
edit
point.
I
think
the
technical
point
is,
I
think,
you're
you're
going
the
right
direction.
I
just
want
to
clarify
that
this
is
in
fact
not
a
password
about
what
you're
showing
yeah.
D
G
G
D
So
yes,
it's
based
on
on
the
architecture
and
hybrid.
If
you
want
to
call
it
that
I
think
we're
in
agreement
all
right
next
slide.
The
interesting
part
here
is
step
four
and
step
five.
When
you
receive
the
ar
augmented
evidence,
the
relying
party
also
has
a
verifier
b
function
as
david
was
pointing
out,
and
this
is
where
you
appraise
the
attestation
results
and
there's
certain
things
that
everybody
has
to
do
when
they're
appraising
them
in
this
kind
of
model,
and
that
includes
do
you
accept
that
the
original
verifier,
a
is
known
and
trusted?
D
Is
the
tester
itself
on
an
accept
list
for
the
relying
party?
What
are
the
conclusions?
What
did
the
verifier
a
conclude,
and
do
you
prove
that
this
is
a
recent
evidence
and
the
details
are
in
the
draft,
but
basically
there
is
a
state
machine
within
the
draft
and
that
state
machine
pretty
much
goes
down
how
to
look
at
various
object
types
and
eventually
make
conclusions
such
as
this,
so
you
can
determine
determine
whether
you're
a
tester
is
somebody
who
you're
accepting
these
trustworthiness
claims
about
next
slide.
D
Now
what
we
have
in
this
draft
on
the
left
side
in
green
and
red
are
the
claims
trustworthiness
claims
that
we've
identified
so
far.
We
hope
in
this
draft
to
have
encoded
these
explicitly,
so
they
can
be
carried
over
different
transports.
D
They
can
be
supported
by
eat,
they
can
be
supported
by
yang.
So
the
primary
goal
of
this
draft
is
to
come
up
with
these
definitions.
That
should
be
reusable
beyond
those
trustworthiness
claims.
You
also
define
categories
of
identity
such
as
the
chip
vendor
the
chip
type
target
environment.
These
will
look
very
familiar
to
people
who
are
looking
at
confidential
compute
things
like
testing
environment
instance.
This
will
look
very
familiar
to
people
who
know
things
like
tpms
and
they
need
a
idev
id
type
key
or
some
other
identity.
D
Key
that
is
hardware
based,
and
the
goal
here
really
is-
is
that
the
categories
of
identity
aren't
exposing
or
defining
the
explicit
identities
and
encodings.
Just
the
types
of
identities
that
can
be
used
in
processing
other
giraffes
will
go
ahead
and
determine
the
specific
identities.
Much
like
we
have.
Another
identity
is
talking
later
in
the
session
about
those
kind
of
identities.
D
Finally,
there's
also
verifiable
freshness,
nonces
timestamps
epochs,
and
these
are
the
categories
in
the
rats
section,
10
architecture,
section
10.-
and
this
is
really
the
things
that
we're
identifying
in
the
draft
with
the
main
objective
is
encoding.
The
things
in
red
and
green
on
the
left
next
slide.
D
D
H
Hi,
so
I
just
have
a
question
on
the
previous
slide.
I
was
wondering
if
there
is
any
link,
be
I
mean
the
relation
between
the
identity
in
the
trespassing
claims
and
the
verify
identity.
D
Yes,
there
are
some
of
them
in
the
previous
slide.
That
said
what
identities
are
relevant
across
different
types
of
environments?
It
really.
It
really
comes
down
to
the
use
case.
Specifically.
Actually
it's
one
more
slide
before
that
one
so
two
slides
ago,
and
one
more
before
that
I
I'm
missing
my
slide
sequence.
So
just
go
to
the
just
go
to
the
table
that
has
the
sgx
and
then
the
trusted.
So
that's
it.
D
Basically,
there
are
different
linkages
for
the
claims
across
types,
each
of
those
hardware
environments
are
going
to
have
different
identities
that
are
more
easily
or
harder
supported.
So
you
can
think
about
the
identities
that
would
fall
into
those
types
of
chip
types
and
then
you
can
start
to
extrapolate
what
might
be
trustworthy
about
those
things.
D
So
summary
on
this
section.
We
think
that
we've
defined
the
objects
in
a
good
enough
start
for
attestation
results.
D
G
I
I
This
is
lawrence
lundblade.
My
reaction
to
your
that
slide.
Attestation
results
for
energy,
heterogeneous
environments-
I
think,
was
the
title
that
slide
actually
describes
and
and
your
work
describing,
is
almost
some
of
the
exact
objectives
I've
had
for
the
eat
draft,
so.
I
D
D
Yes-
and
I
think
that's
a
good
thing-
I'm
certainly
hoping
these
can
be
encoded
and
eat.
So
I
I
don't
see
any
obvious
disconnects
we're
just
trying
to
say
here
are
new
objects
and
their
formatting
and
their
processing,
as
well
as
being
able
to
have
those
same
objects
encoded
in
other
environments.
If
you
remember
early
on,
we
had
some
discussions.
For
example,
how
do
we
make
sure
eat
and
yang
objects
are
the
same?
This
is
the
kind
of
definition
of
reusable
encodings.
I
Yeah,
to
get
one
more
comment
I
mean,
I
would
hope
that,
where
you
know
we
could
look
at
what
the
eat
objects
are
that
are
defined
currently
and
see.
If
we
can
get
some
line
up
with
what
you're
defining,
I
would
hope
they
would
all
go
into
the
cwt
registry.
Just
like
anything,
we've
done
for
eid.
D
D
D
A
There
are
a
couple
comments
in
the
chat
that
is
asking
us
to
defer
the
question
until
after
lawrence's
presentation.
I
I
think
it's
at
1
30
today
in
about.
J
I
A
A
B
A
Lovely,
if
you
guys
can't
hear
me,
I
will
put
it
in
the
chat.
D
We
hear
you
now.
A
My
comment
was
to
say:
we
we've
had
a
fair
number
of
reviews
for
this
draft,
so
my
suggestion
is:
there's
been
three
three
four
folks
that
will
that
have
asked
for
wanting
to
hear
lawrence's
presentation
before
we
do
the
call
for
adoption
for
this
draft
as
well.
So
it
sounds
like
that
will
happen
on
the
third
session.
B
20
minutes
we're
essentially
time
for
these
two
topics:
attestation
results
and
trusted
path,
routing.
A
B
Third
hour,
we
have
three
topics:
20
minutes
for
suv,
id
8,
20
minutes
for
four
claims
to
carry
out
a
station
results.
Those
are
both
lawrence
and
then
followed
by
10
or
15
minutes
for
cheap
requirements
for
eat.
A
Right
so
my
comment
went
to
question
bringing
in
lawrence's
presentation
right
now,
but
even
if
we
did
it
wouldn't
give
us
enough
time
to
have
the
discussions.
The
other
point
to
note
is
both
roman
and
I
will
not
be
present
and
I
would
like
roman
to
be
in
there,
so
I'm
leaning
towards.
A
Just
keeping
the
agenda,
but
I'm
bringing
back
the
agenda
bash
and
roman
as
our
ad
would
look
to
you
for
advice
too,
that
we
just
continue
with
the
agenda
and
then
have
the
discussion.
If
we
run
out
of
time
on
the
third
session,
we
need
to
confirm
this
anyway
on
the
email
list
that
we
start
the
conversation
on
the
third
session.
We
may
not
get
to
conclusion,
but
we
can
drive
to
conclusion
on
the
mail
list.
E
K
B
B
We
we
could,
you
know,
move
revisit
trusted
path,
routing
at
the
end
of
the
day
at
the
end
of
session
three
or
we
could
push
push
everything
down
and
take
five
minutes
for
trusted
path,
routing
right
now.
What
do
we
want
to
do?.
A
Well,
my
suggestion
was
just
to
keep
moving
with
the
agenda,
as
is
right
now,
lauren's,
because
we're
eating
into
the
presentations
and
then
at
the
third
session,
we'll
have
some
time
for
the
group
to
begin
the
discussion
on
these
two
drafts
kathleen's
and
eric's
and
lawrence's
not
sure
that
we
will
reach
a
conclusion,
which
is
why
I
said
we're
gonna
need
to
confirm
this
on
the
mail
list
anyway,.
B
Okay,
so
eric
can
we
cover
the
trusted
path,
routing
topic
in
five
minutes.
D
All
right
so
next
slide
trusted
path,
routing.
We
have
some
new
authors
since
last
time,
chenna
guy
and
hank
they've
all
joined
based
on
the
breakup
of
the
trusted
path.
Routing
stuff
from
the
attestation
results
that
we
just
saw
next
slide.
D
So,
basically,
what
we're
doing
is
we're
determining
whether
we
trust
the
remote
device
and
then
adding
the
links
to
a
topology,
a
routing,
topology
and
then
we're
passing
the
traffic
around
things
that
we
don't
trust
next
slide
here
are
three
custom:
topologies,
where
you
have
your
trustworthiness,
vector
or
trustworthiness
claims
understood
by
device,
and
when
you
have
a
device
that
isn't
trusted,
you
go
ahead
and
route
around
it.
D
D
Changes
the
version
last
version
is
that
we
really
just
broke
the
drafts
apart
and
we
aligned
with
working
last
group
last
calls
on
chara
and
updated
the
authorship
so
effectively.
We've
just
extracted
a
lot
of
the
old
tpr
stuff
into
the
last
draft.
You
saw
next
slide
and
that's
pretty
much
it.
We
don't
really
want
to
look
for
adoption
of
trusted
path
routing
until
at
attestation,
results
is
picked
up
because
it's
a
more
generic
version
of
it
and
hopefully
over
time
we
can
define
the
e
payload
and
that's
pretty
much
it.
B
Okay,
so
any
any
discussion
on
this
before
we
move
to
the
next
topic:
if
not,
then
we
will.
We
will
take
five
minutes
for
the
attestation
event
stream
subscription
topic.
I
don't
have
slides
we're
just
going
to
talk
to
this
so
yeah.
L
So
this
is
hank
I
can.
I
can
really
make
this
quick,
so
we
we
we
can
save
some
time.
L
I
hope
this
time,
so
the
attention
event
stream
subscription
is
an
augment
to
java
the
young
module
and
it
defines
yeah
well
for
young
push
divine
defines
this
uses
these
these
event
streams,
and
then
we
define
one
for
attestation
evidence
here,
and
that
is
relatively
straightforward,
but
we
realized-
hey,
that's
actually
also
conveying
log,
so
we
now
have
two
event
streams
and
when
you
really
look
hard
at
the
architecture,
evidence
is
not
the
only
interesting
conceptual
message
here.
L
There's
also,
of
course,
like
endorsements
reference
values,
maybe
even
policies,
and
so
the
the
current
steps
are
to
add
additional
stream
definitions
without
going
down
the
lane
of
trying
to
flesh
out
the
the
actual
yang
modules
that
would
represent
the
data
on
that
streams.
L
For
notifications,
for
example,
or
non
yang,
data
could
also
be
there,
but
we
are
providing
the
capability
in
this
id
to
to
allow
for
basically
all
conceptual
messages,
so
that
is
taking
it's
basically
a
little
scope
creep
so
to
speak,
but
I
think
just
limiting
this
to
to
evidence,
which
is
actually
the
most
complicated
case,
allows
for
other
ambassadors
also,
and
that's
our
next
step,
so
so.
That
is
why
we
are
not
asking
for
adoption
about
for
this
work
right
now,
because
we
add
a
chunk
of
flexibility.
L
J
B
J
Okay,
I'm
melinchan
from
china
mobile.
This
is
the
first
presentation
for
this
draft.
We
try
to
specify
the
architecture
of
t-e-e.
That's
trust,
trusted
execution,
environment,
identification
based
on
e-a-p-t-l-s
certificate
protection
and
handshaking's
generation
will
be
executed
in
the
te,
but
communication
is
establishment
will
be
done
in
rich
execution,
environment
next
slide
things.
J
Why
we
need
to
do
this?
No
matter
eipts
or
802.1x?
They
can
guarantee
their
procedure
or
communication,
but
there
are
two
strong
assumptions.
One
is
that
the
devices
are
secure
and
trusted.
The
other
is
the
implementation
of
the
channel
establishment
is
trusted,
but
in
fact,
security
is
the
result
of
multi-layer
composition,
which
could
affect
their
security,
both
in
protocol
level
and
equipment
level.
J
J
The
authentication
in
general
of
mobile's
device
cannot
be
the
same
as
the
authentication
of
sim
cards.
We
hope
to
design
an
area
with
separate
calculation
and
storage
security.
The
information
from
this
area
is
encrypted
and
does
not
interact
directly
without
outside
entity.
J
The
identity
start
in
the
in
this
area
cannot
be
tempered
and
not
visible
in
clear
text.
So
the
primary
goal
of
this
draft
is
to
provide
a
remote
identity
as
testation
method
which
use
eaptos
as
their
essential
authentication
protocol
and
just
executed
environment
as
the
security
store
and
skilled
certificate
and
the
private
king
derivation
eric.
J
J
What's
your
are,
do
you
have
any
supported
type
for
the
identity.
D
Yes,
I
think,
for
me,
identity
is
coming
down
to
who
can
protect
some
private
key
and
then
a
private
key
can
be
used
to
identify
a
chip,
type
or
a
vendor.
It
can
be
identifying
a
specific
instance,
a
certificate.
It
can
be
identifying,
let's
say,
a
a
testing
environment,
so
I
think
for
me,
the
more
I
I've
been
going
down
this
path.
The
identity
actually
is
the
owner
of
the
of
the
private
key.
That's
that's
at
least
where
I've
been
going
towards.
J
In
fact,
we
do
not
limit
it
to
just
x5
general
knight
identity
after
a
certificate.
If
there
is
the
with
raw
public
key
in
the
certificate,
we
can
also
cover
them
right.
J
The
architecture
of
the
trusted
in
execution
environment,
the
pair
that
communicate
with
ets
server,
is
divided
into
two
parts.
The
left
part
is
t
e
and
the
red
parts
is
the
aptl
as
client.
The
whole
is
called
ree,
rich
executive
executed
environment
trusted
executed,
environmental
disorder
for
certificates
and
the
king
derivation
between
t
e
e
and
the
kind
there
is
a
middle
layer
which
is
responsible
for
inner
interaction.
J
Middle
layer
is
separated
into
two
parts.
Inner
middle
layer
and
external
middle
layer
in
in
the
middle
layer
is
responsible
for
king
derivation
and
the
response
to
external
memory
about
fts
message.
Encryption
and
the
decryption
west
visa
external
middle
layer
take
the
shoulder
of
communicate
with
fts
server
and
recursed
encryption
and
display
encryption
message
from
in
the
middle
layer.
J
The
message
transmitted
between
in
the
middle
layer
and
the
standard
layer
will
follow
the
format
of
tis
1.3,
but
not
all
the
message
defined
in
the
tias
1.3
will
be
transmitted.
J
The
in
the
middle
layer
only
accept
the
message
relearned
to
encryption
and
decryption.
The
structure
of
middle
layer
message
is
sure,
like
the
diagram
total
have
9
parameters
from
a
random
kinship
extension
to
their
application,
nature
and
erat
next
slides.
Thank
you.
J
J
The
whole
procedure
between
t
e
in
the
middle
layer
and
external
middle
layer
under
a
ptr
server
is
sure,
like
the
diagram,
the
people
familiar
with
the
eft
as
well.
If
they
understand
this
procedure,
we
define
six
middle
layer
messages
from
message
1
to
message
6,
which
will
be
used
for
different
purpose
to
communicate
with
between,
in
the
middle
layer
and
the
eastern
middle
layer.
The
specific
steps
are
shown
in
below
next
slide.
Please.
J
In
order
to
complete
a
client,
hello
message,
the
king
sure
is
the
initial
message
is
needed.
This
message
involves
the
king
derivation
function,
which,
which
must
be
executed
in
t
e
for
the
security,
so
the
middle
layer
message,
one
is
key,
ensure
extension
and
request
from
external
to
in
extend
external
middle
layer
to
in
the
middle
layer,
middle
layer.
Message
2
from
in
the
middle
ear,
responds
to
message
1
and
the
reasons
taking
sure
extension
response
to
external
middle
layer
is
message.
J
Since
external
middle
layer,
its
external
middle
layer
does
not
carry
the
relievement
private
private
king,
which
is
derived
from
our
kinship
extension.
It
will
transfer
this
message
to
inner
middle
layer
to
decode
message.
3
also
includes
the
entire
handshake
context,
which
will
be
used
to
create
certificate,
verify
and
finish
the
context
next
slide.
J
J
In
message,
four
in
the
middle
layer
retains
the
kinship
extension
and
art
message
message
context
will
be
transferred
to
external
layer
as
print
text
message.
4
also
contains
context
that
atmack
of
the
comparation
of
finished
king
and
certificate
certificate
verify
which
can
only
be
generated
by
in
the
middle
layer
from
the
view
of
certification
from
the
wheel
of
security
message,
5
is
the
encrypted.
J
J
We
also
define
other
branch
branches
of
efts
procedure
like
ticket
establishment
in
message
5.
If
the
new
session
ticket
content
context
is
sent
by
the
server,
it
will
be
pocketed
in
the
middle
of
servers
tier
as
finished
the
message
and
the
ts
appreciation
date.
That
will
accept
the
message.
This
context
will
be
included
in
message:
5
by
external
middle
layer
and
convert
to
in
the
middle
layer
after
receive
this
message
in
the
middle
layer,
will
decrypt
and
return
this
ticket
the
establishment
context
for
resumption,
and
we
also
define
the
resumption
termination
and
hello.
J
J
The
next
frame
we
want
to
do
is
to
to
advance
the
draft,
for
the
part
of
prevent
or
mitigation,
is
positive,
attacked
from
rich
executive
executed
environment,
and
this
third
part
is
how
to
identify
if
the
device
enables
a
trusted
executed.
Environment
function.
G
Yeah
thanks
for
this
presentation,
I
will
just
observe
that
a
lot
of
the
or
at
least
some
of
the
things
you're
talking
about
overlap
a
little
bit
with
the
tpu's
case.
G
Now
it's
a
different
scenario
that
you're
using
it
for,
but
things
like
the
security
consideration
you
just
talked
about
and
the
distinction
between
the
what
iml
and
eml
sort
of
matches
the
deep
broker
architecture,
and
so
I
just
want
to
point
and
say:
hey,
you
know,
take
a
look
at
the
teep
architecture
and
see
if
there's
at
least
anything
in
the
security
considerations
you
might
not
might
be
able
to
reuse
just
because
I
see
some
overlap
there.
So
that's
all.
J
All
right,
thank
you
that
that's
a
good
consideration
for
your
will.
Laurence.
I
Yeah
for
one
comment
and
one
question:
the
comment
is
okay.
This
looks
very
similar
to
idev
id
from
ieee
sort
of
in,
in
the
use
of
you
know,
identity
and
x,
9
and
8.
So
the
comment
is
maybe
interesting
for
you
to
look
at
high
def
id.
I
The
second
quest
is
a
question,
and
that
is
when
you,
when
you
talk
about
identity,
does
that
cover
things
like
imei
mac
address
and
mz.
J
Okay
lawrence,
the
first
question:
I
I
don't
get
the
exactly
point
of
view.
Can
you
repeat
it
I?
I
will
try
to
answer
the
second
question
you
see.
The
authentication
to
to
prove
I
am
I
we
have
our
assumption
here.
Is
that
the
tee
the
environment
is
trusted
and
the
identity
stored
there
is
encrypted
all
around
the
procedure,
only
only
import
only
in
a
clear
text
in
the
in
the
trusted
trusted
part.
J
M
M
A
A
So
I'm
just
wondering
if,
if
we're
getting
cut
off,
hopefully
you
guys
can
hear
me
my
suggestion
for
this
is
that
we
continue.
A
We
continue
the
discussion
on
this
draft
so
for
the
authors,
thank
you
for
presenting.
If
you
can
lawrence,
if
you
can
echo
your
question
to
the
mail
list
and
then
the
authors,
if
you
can,
you
know,
respond
there
and
also
provide
us
on
your
expectations
for
this
draft.
That
way,
you
know
we
you
can
ask
for
reviewers.
A
So
I
think
ned
with
that,
we
should
probably
close
this
session
since
there's
a
third
one
coming
up.
B
Okay,
so
we
have
a
30
minute
break.
We
meet
back
here,
half
past
the
hour
and
we'll
continue
on.
Thank.