►
From YouTube: IETF108-RATS-20200729-1100
Description
RATS meeting session at IETF108
2020/07/29 1100
https://datatracker.ietf.org/meeting/108/proceedings/
A
A
A
I
don't
see
lawrence
on
the
call,
but
hopefully
he
will
join
eric
awesome
you're
on
you'll
be
going
through
the
trusted
path.
Routing
hank
will
go
through
the
suit
evidence
and
attestation
claims
followed
by
the
unprotected
seabot
claims
and
then
thomas
you're
on
to
present
your
new
draft
on
restful,
attested
resources
and
then,
given
that
we've
got
new
drafts,
one
of
them
dropped
off.
I
thought
it
was
important
for
us
to
go
through
the
milestones,
as
we
also
need
to
update
them.
A
A
B
B
B
No
problem,
so
there
were
only
five
names
on
the
title
slide,
but
effectively
we
have
a
a
lot
of
people
that
are
weighing
in
on
creating
consensus
here
on
the
regular
basis.
So
this
is
a
big
list,
as
you
can
see.
Most
of
these
listed
here
are
joining
on
a
regular
basis
on
tuesdays.
10
a.m.
Est
luckily
not
4
a.m.
Pst
is
right
now,
I'm
very
sorry
nc,
and
so
so
we
had
24
meetings
since
the
it106.
B
B
So
this
is
actually
the
list
of
everything
that
is
still
open.
Issues
and
pull
requests
are
merged
here.
At
some
point,
you
see
it's
suddenly
triple
digit
thingies
again,
these
are
the
four
pull
requests.
They
range
from
very
contested
items
that
are
really
under
discussion,
which
will
I
come
back
to
with
other
slides
today
and
end
up
with
things
that
are
open
only
for
logistic
reasons.
Like
72,
what
are
role
compositions,
these
terms,
don't
even
exist
anymore.
B
B
So
we
did
actually
text
molding
and
and
crunching
and
smithing
and
and
effectively.
When
you
look
at
the
diffs
between
the
versions,
the
amount
of
changes
reduces
effectively
the
volume
that
is
due
to
the
fact
that
we
are
going
to
details
now
and
are
now
in
the
polish
phase.
I
think
there
are
only
a
few
big
items
open
again.
I
will
come
to
this
later
the
address
and
thank
you
kathleen
for
extensive
comments.
B
You
made
the
biggest
list
of
comments
we
have
received
so
far
in
the
existence
of
this
document.
Yet
we
tried
to
address
all
of
them.
Some
of
them
were
discarded,
it's
all
captured
in
the
issues.
Most
of
them
were
addressed,
not
all
of
them
completely,
so
everything
that
was
not
contentious
was
addressed
as
a
pull
request
immediately
and
we
went
through
all
of
our
stuff
with
issues
here.
B
B
So
we
have
a
standing
on
the
point
of
view
that
that
we
minimize
terms
already,
we
are
still
bickering,
so
to
speak
on
a
few
terms
that
are
still
open,
but
I
think
this
is
the
minimal
set
everything
the
ad
now
is
convenience,
or
maybe
highlighting
some
caveats
still
that
you
might
run
into
if
you
create
protocols
here,
but
I
think
we
arrived
at
a
rather
stable.
That's
the
first
point
and
minimal
set
of
items.
There
is
a
new
section
on
the
trust
model.
B
I
would
everybody,
of
course,
if
we
draft
the
case
recommend
to
read
that
one,
but
trust
is
a
very
essential
piece
here,
not
only
in
the
security
area,
but
also
in
the
rats
working
group.
Hand
in
hand
with
trust
cause,
the
significant
improvement
of
freshness.
These
two
sections,
I
think
of
most
importance
here
that
are
undergoing
biggest
changes,
we're
currently
working
on,
as
always
in
the
end
with
privacy
and
considerations
for
the
moment.
Are
there
any
questions
about
this?
B
I
do
not
assume
I'm
looking
at
the
chat,
but
that
doesn't
seem
to
be
the
case
and
then
I
think
we
can
go
back
to
the
next
slide
please.
This
is
now
getting
into
the
meat
of
it.
We
have
two
bigger
topics.
Here's
part
one-
and
that
is,
I
was
thinking
thinking
initiated
by
lawrence,
who,
unfortunately,
is
not
with
us
at
the
moment.
B
Oh
well,
okay,
there
is
the
notion
that
we
have
phasing
here
in
the
red's
charter.
The
things
we
are
focusing
on
today
is
the
live
data
flow
between
the
active
actors
that
are
relying
parties
that
want
to
establish
some
soft
stress
decision.
There
are
testers
the
target
of
aviation
that
has
to
create
all
this
evidence
and
the
verifier
that
takes
care
of
the
burden
of
the
appraisal
of
the
biggest
chunks
of
it
if
it's
too
complicated
for
a
simple
cell
phone,
for
example.
B
So
all
of
these
flows
are
very
established
and
defined
at
the
charter,
but
there
is
a
very
important
bureaucracy
upstairs.
That
is
the
endorser
role.
The
endorser
role
basically
could
be
something
in
a
supply
chain.
It
could
be
the
vendor
that
creates
the
a
tester
in
the
first
place
and
also
that
a
testing
service
need
information
from
in
the
end,
the
verifier
in
this
case,
so
there
were
attempts
to
simplify
this
and
also
say
yeah.
B
B
That
is
the
things
that
the
attester
cannot
create
evidence
about,
because
at
some
point
you
have
this
roots
of
trust
they're
there.
You
cannot
create
evidence
about
us.
This
has
to
be
taken
on
by
another
role.
That's
external!
That's
the
endorser!
This
is
basically,
I
don't
want
to
call
it
evidence,
but
it's
like
evidence,
but
about
the
things
inside
the
tester.
The
tester
itself
cannot
talk
about,
and
so
that's
the
open
topic
we
are
currently
discussing.
If
you
are
interested
in
this
either
join
or
if
you
are
and
again
lawrence
would
have
had
something
here.
B
B
And
yes,
dave
it's
in
the
next
presentations
a
little
bit,
but
I
didn't
see
that
one
coming
first,
okay,
this
might
be
quicker
than
I
thought
so,
please
there
is
this
opportunity
to
join
in
the
calls
on
tuesday.
So
if
you
are
integrator,
if
you
are
a
service
provider
domain
of
point
of
view,
this
might
be
of
interest
to
you.
B
Yeah
and
that's
the
time
keeping
so
maybe
I
have
a
little
more
time
to
talk
about
time.
At
the
moment,
coincidentally,
hannes
wrote
an
email
to
the
list
asking
about
the
age
claim
and
eat,
which
is
a
good
hook
to
get
something.
So
this
is
a
current
topic
apparently,
and
so
at
the
moment
we
define
in
an
appendix
of
the
architecture,
a
set
of
quite
important
points
in
time.
B
They
call
them
events,
and
this
is
captured
in
the
section
called
time
considerations
and
just
to
give
you
an
example
here,
it's
about
time
spans
between
generations
of
values,
for
example.
So
you
generate
a
value
on
a
target
environment
of
a
tester,
that's
important
because
it
has
to
go
into
evidence,
but
the
spawning
of
a
byte
value
in
some
register,
for
example,
does
not
make
evidence.
Yet
you
have
to
generate
the
evidence
from
that
and
there
is
an
interval
between
that
spawning
the
value
generation
and
the
effective
re.
B
Let's
call
it
reporting
the
evidence
generation
in
the
assumption,
under
the
assumption,
you
will
send
it
out
quite
in
time,
so
that
is,
of
course,
okay,
but
there
are
intermediate
steps
there,
and
there
is
discussion
going
on
so
hannah's
question
was
what
about
the
collection
and
what
we
could
refer
to
and
then
reply
was
yeah.
Well,
we
have
better
value
generation,
but
you
might
not
always
get
a
explicit
time
stamp
from
that.
B
Sometimes
things
spawn
in
your
system
and
the
system
that
creates
it
or
the
software
component
does
not
always
provide
a
timestamp
for
that,
so
it's
just
there
and
then
collection
or
awareness
or
something
that's
all
the
topics
we
are
talking
about
and
won't
want
to
go
into
details.
This
is
something
we
are
currently
addressing
as
a
final
part
of
the
yeah,
basically
finalization
of
the
architecture.
That
is
the
biggest
next
chunk
we
have.
There
are
pull
requests
about
this
and
a
lot
of
comments.
B
If
you
are
interested
in
how
to
create
protocols
and
solutions
in
the
end
or
are
planning
for
a
solution
in
your
domain
again,
it
might
be
a
good
point
of
time
to
join
the
calls
on
tuesdays.
At
the
moment
there
are
interested
parties.
I
think
there
are
issues
on
the
list.
This
all
can
be
looked
up.
Is
anybody
here
in
this
group
or
in
this
session
right
now?
That
has
a
question
about
time,
keeping
or
the
time
tables
that
might
have
been
already
reviewed
by
someone
here.
B
Okay,
nancy:
I
can
maybe
save
you
some
time
here.
So
these
are
the
big
two
things
again.
This
document
is
now
internally,
as
you
saw
the
list
of
names
with
the
who
and
when-
and
there
is
an
informal.
Let's
call
it
trend
that
we
try
not
to
open
more
can
of
worms
here
right
now.
We
want
to
carry
this
document
to
the
finish
line,
and
so
we
have
the
two
items
here,
part
one
and
part,
two
that
I
highlighted
a
small
nits.
Probably
reviews
are
always
upcoming.
B
Welcome,
so
we
will
open
new
issues
when
reviews
are
coming
in.
But
aside
of
that,
we
are
pretty
in
a
pretty
good
shape
to
to
put
a
lid
on
the
document
effectively,
which
also
means
that
we
have
we
that
there
might
be
a
light
at
the
end
of
the
tunnel
for
a
group
last
call
and
okay,
something
dave
is
on
the
queue.
Oh
yeah,
I'm
not
seeing
the
queue.
Sorry
dave,
I'm
talking
on
and
on
yeah.
C
B
On
this
slide
here
right
now,
okay,
the
second
question
is
sometimes
you're,
not
sending
yeah.
So,
okay,
there
are
examples
in
the
appendix
next
to
this
event
thing.
So
we
have
this
time
cut
so
for
everybody
that
we
have
this
time
points
of
time.
This
events
defined
and
the
examples
elaborate
on
them.
So
you
can
understand
how
and
in
which
context
these
events
timestamps
are
important
to
you
when
are
they
going
over
the
wire
and
when
they
are
just
times
on
a
entity,
for
example
that
triggers
something?
B
C
C
C
You
can
still
build
a
solution
right
and
it
shows
how
you
can
construct
a
protocol
using
nonces
that
does
not
require
even
having
any
type
of
real-time
clock
in
your
device.
There's
another
section
that
says:
oh
well,
if
you
have
say
time
synchronization,
then
you
can
do
things
without
having
to
exchange
without
a
without
a
nonce
challenge
right.
You
can
construct
a
protocol
that
assumes
synchronized
clocks
and
you
get
a
much
simpler
protocol
in
the
in
this
layer
at
the
expense
of
having
a
different
protocol
for
time
synchronization.
C
So
it
just
covers
that
you
could
do
it
with
nonces.
You
can
do
with
time
stamps
and
so
there's
multiple
ways
to
accomplish
freshness
and
it's
giving
multiple
sort
of
independent
examples
of
ways
that
you
can
have
solutions
that
that
solve
freshness,
while
still
highlighting
here's
the
freshness
problem
to
be
solved
without
trying
to
dictate
which
way
you
solve
it,
because
it
shows
multiple
in
subsequent
sections.
Here's
a
here's,
an
example
that
only
uses
nonsense
and
no
clocks.
B
Well,
that
actually
sounds
excellent,
so
the
the
subset
of
the
question
that
now
remains
is:
is
this
a
set
of
examples?
Good
enough?
I
think
there
are
four
right
now.
So
four
examples
are
there
and
they
they
they
apparently
not
all
based
on
nonsense.
Sorry
about
that.
So
that's
that's
already
a
big
improvement,
and
so
the
the
final
question
is:
do
you
find
something
as
in
this
group
or
basically
on
the
list
extension?
B
C
Yeah
my
personal
opinion
is
that
I
don't
think
that
the
architecture
document
needs
to
be
complete
with
all
possible
ways
of
doing
it.
It
has
four
in
there
right
now,
as
you
mentioned
right,
which
is
a
two
by
two
matrix
right.
One
is
a
because
we
said
there's
two
classic
models
between
passport
and
background
check
right.
C
If
one
of
those
is
more
along
your
way
of
thinking,
then
there's
two
examples
of
each
so
one
one
axis
is
background
check
versus
passport,
and
the
other
axis
is
using
time
stamps
for
synchronized
clocks
versus
using
nonces
without
any
requirement
for
having
a
clock
in
the
first
place
right.
So
that's
the
two
by
two
matrix,
but
that
is
not,
of
course,
the
only
possible
ways
of
doing
it.
My
opinion
is,
we
don't
have
to
enumerate,
or
we
shouldn't
try
to
enumerate
all
possible
ways
of
doing
it.
B
B
Exactly
exactly
so,
but
I
also
don't
want
to
I
like
the
idea
of
this.
This
is
tetra
lemma,
like
2x2.
It
has
a
certain
elegance
to
it,
but
I
would
not
make
this
the
reason
to
to
constrain
somebody
to
to
point
out
something
that
might
be
of
interest.
Maybe
it's
good
enough
so
to
speak,
and
I'm
just
mentioning
this
because
we're
closing
this
soon
so
speak
up
now
or
be
happy
with
it.
So
these
are
the
two
alternatives
effectively
and
yeah.
B
C
So
I
guess
the
one
thing
and
I'm
trying
to
be
fair
to
your
opinions,
because,
on
the
on
the
design
team
meetings
right,
there's
been
one
of
the
open,
plural
requests.
Hank
said
was
contentious
and
I
just
want
to
highlight
that
what
the
ongoing
discussion
is
since
tuda
is
not
on
the
agenda
right
now
and
so
I'll
give
hank
a
free
shout
out
here.
One
of
the
open
questions
has
to
do
with
the
extent
to
which
handle
distribution
should
appear
in
the
architecture.
C
Document
right
handle
distribution
is
discussed
in
things
like.
I
think
it's
roughly
mentioned
in
the
interaction
models
document
that
hank
talked
about
yesterday,
but
it
didn't
come
up
in
the
discussion
yesterday.
It's
in
the
document,
although
my
reading
of
that
document
is,
is
a
little
bit
confusing,
although
it
just
refers
to
the
tuta
document
for
more
details,
I
think
that's
what
the
more
details
are,
but
that
was
not
a
working
group
document
yet
and
so
to
what
extent
should
this
other
discussion
be
part
of
it?
C
I'm
personally
I
I
was
arguing
that
discussion
just
to
be
transparent
to
all
the
rest
of
the
working
group
that
wasn't
there.
I
was
arguing
that
the
architecture
document
shouldn't
put
in
concepts
that
don't
appear
in
working
group
documents,
and
so,
if
trudeau
were
to
be
adopted
as
a
working
group
document,
we
could
have
that
discussion,
but
otherwise
I
was
arguing
to
keep
with
the
current
2x2,
although
other
people
might
like
to
have
them
be
in
there
and
that's
kind
of
blocked
on
that
larger
issue.
A
E
F
A
G
G
G
G
So
we
start
out
really
with
the
relying
party
has
to
trust
the
verifier,
and
you
know
we
don't
specify
in
the
architecture
or
you
know
how
that
that
trust
is
established,
but
there's
basically
a
direct
trust
relationship
between
the
relying
party
and
the
verifier.
For
example,
it
could
be
the
same
role
or
they
could
be
an
https
connection
or
something
like
that.
They
could
be
the
same
entity.
G
G
G
So
this
this
diagram,
you
know
is,
is
I
I
consider
this
the
basic
trust
flow
of
in
attestation
and
kind
of
to
a
large
degree,
the
core
of
attestation
there's
a
secondary
trust
flow.
I
believe,
which
is-
I
don't
want
to
go
into
here,
but
but
that's
got
more
to
do
with
privacy
and
pii,
which
is
kind
of
the
reverse
of
this,
because
but
that's
and
that's
discussion
in
the
architecture
document,
but
I'm
not
going
to
that
here,
I'm
focusing
on
the
the
main
primary
trust
flow.
G
E
G
G
G
A
G
Yeah,
okay,
okay,
so
this
is
looks
a
lot
more
like
the
kind
of
mapping
to
the
the
the
standard
diagram
in
the
architecture
which
shows
the
attestation
result,
attestation,
evidence
and,
and
all
that
this.
So
this
is
now
similar
to
the
previous
diagram,
showing
the
different
messages
and
I'm
picking
this
to
highlight
where
the
attestation
key
material
is
and
how
that
works.
G
G
G
The
only
way
you
can
prove
that
you're
in
a
tester
is
with
cryptography,
so
the
attester
has
to
have
a
some
sort
of
a
secret
in
it
that
it
can
use
to
sign
something
or
authenticate
something
to
prove
it
is
this
particular
tester.
You
know
to
prove
it's
the
you
know
the
device
made
by
acme
corporation
version
2.0
or
something
or
to
prove
it's
a
a
tpm
chip
or
to
prove
it.
It's
this
particular
te
or
it's
this.
This
particular
chip,
if
you
just
it,
has
the
secret
that
proves
it's
that
particular
chip.
G
C
C
C
C
C
G
Right
so
so
yeah
yeah,
so
that
verification
key,
I
mean
the
verification
key
that
still
hauls,
even
in
that
scenario,
so
there's
still
some
sort
of
some
verification
care
material.
That's
transferred
from
the
manufacturer,
endorser
supply
chain
to
the
verifier
and
the
verifier
cannot
do
its
job.
Absolutely,
it
cannot
do
its
job
without
that
key
material.
G
G
G
Another
option
is
that
the
manufacturer,
endorser
supply
chain
runs
a
verification
service
and
doesn't
actually
transfer
key
material,
so
I'll
go
into
that
a
little
more
then.
So,
that's
one
axis
of
the
taxonomy
another
axis
of
the
taxonomy
is
how
frequent
this
interaction
happens.
So
the
interaction
could
happen
between
this
is
between
the
manufacturer
and
the
verifier
could
be
infrequent,
such
as
the
transfer
of
a
a
route
of
trust,
or
they
could
be
done
in
batches
or
quarterly,
or
something
like
that
or
the
interaction
could
be
per
verification.
G
G
G
G
They
do
this,
perhaps
periodically
quarterly
or
annually
or
once
or
something
like
that,
and
there's
a
look
up
by
key
id,
so
the
there's
no
certificates
involved,
you
just
you
just
take
the
key
id
out
of
the
the
eat
message,
some
some
sort
of
a
identifier
and
then
look
up
the
public
key
and
use
that
to
verify
this
is
real.
Two
fortune
500
companies
interact
this
way
today.
I
know
of
an
implementation
that
actually
does
this
for
for
a
firmware,
tpm
implementation.
This
is
not.
This
is
not
a
hypothetical.
G
Down
on
per
verification,
the
manufacturer
in
this
case
maintains
the
key
database,
but
it
never
sends
all
the
keys,
which
is
what
happens.
Every
is
every
time
the
verifier
wants
to
verify
something
the
manufacturer
or
the
the
verifier
asks
the
manufacturer
for
a
key
by
key
id.
Of
course,
there
has
to
be
a
trust
relationship
there.
So
perhaps
it's
over
tls,
you
know.
Trust
has
been
established
over
tls
so
that
it
knows
that
the
keys
it's
getting
are
trustworthy
keys.
G
You
can
do
this
all
with
kdfs,
so
the
transfer
from
the
manufacturer
to
the
verifier
is
a
master
symmetric
key
and
the
per
device
keys
are
derived
using
a
kdf
perfectly
reasonable
thing
to
do.
Of
course,
in
this
case,
the
transfer
of
the
key
material
to
the
verifier
has
to
be
done
with
confidentiality.
G
That's
not
the
case
with
public
keys,
it
is
with
symmetric
keys,
so
you,
but
you
don't
have
to
with
a
master
key.
Instead
again,
there
could
be
a
database
of
keys,
and
so,
if
there's
a
million
devices,
there's
a
million
keys,
the
manufacturer
sends
the
entire
database
of
symmetric
keys
to
the
verifier,
maybe
quarterly
or
periodically,
or
something
like
that.
It's
infrequent
and
there's
a
lookup
by
key
id
and
then
similarly,
you
can
do
symmetric
heat
lookup,
where
the
manufacturer
retains
the
database
doesn't
give
it
out
to
anybody.
G
The
verifier
asks
the
every
time
it
does
a
verification.
It
asks
the
manufacturer
for
a
key
by
by
some
key
id
again,
the
point
of
symmetric
keys
is
low
cost.
I
know
of
implementations
at
a
couple.
Different
companies
that
are
doing
this
for
real,
so
symmetric
keys
are
a
real
thing,
so
you
know
it's
you
know.
Symmetric
planning
is
supported
by
cose,
you
know
with
hmac
and
all
that,
so
I
think
this
has
to
be
part
of
rats.
G
G
So
I
think
the
one
other
thing
I
want
to
mention
here
is
ecdaa
or
some
sort
of
a
daa
architecture.
In
that
case,
I
think
that
basically
fits
into
the
public
key
category.
It's
it's
similar.
It's
not
just
a
key.
It's
the
it's,
the
the
basis
for
the
the
daa,
which
is
a
little
more
complicated
than
a
key,
but
essentially
boils
down
to
something
similar
dave
go
ahead.
Dave.
C
We're
just
having
a
quick
conversation
in
the
chat
room,
we're
just
going
to
report
it
out
here.
This
is
a
great
slide.
Thank
you.
My
since
we've
already
discussed
that
the
term
manufacturer
could
mean
a
whole
bunch
of
different
things.
My
take
is
that
this
slide
is
actually
not
specific
to
rats.
This.
This
slide
is
actually
more
generally
useful.
C
It
surveys
a
bunch
of
techniques
that
be
used
for
any
time
that
you
need
to
configure
or
use
keys
between
any
two
entities,
given
the
manufacturer
could
be
anything
right:
the
the
provider
and
the
consumer
of
that
key
configuration
and
trust
model,
and
so
the
suggestion
would
be
because
I
think
this
slide
is
quite
useful.
I
like
this
one
other
than
maybe
we
changed
the
term
manufacturer
or
clarified,
or
something
like
that,
but
this
taxonomy
is
great.
C
I'm
suggesting
that
this
be
in
a
maybe
a
general
security
area
document
that
could
be
referenced
from
multiple
working
groups,
because
I
don't
think
this
is
just
useful
for
rats.
I
think
it's
useful
for
just
about
any
working
group
that
uses
keys.
You
know
teep
and
rats
and
other
ones,
so
I
would
love
to
see
this
particular
slide
expanded
into
a
draft
that
can
be
put
into
a
general
security
area
document
that
can
be
consumed
by
multiple
working
groups.
So
thanks
for
putting
this
together
and
we
have
russ
hasley.
A
I
You
have
to
have
integrity
on
the
communications
channel
when
you
get
that
dna
back,
otherwise,
you
can
be
spoofed
and
in
the
middle
you're,
actually
getting
the
keying
material
necessary
to
pretend
to
be
the
a
tester.
So
you
know
these
kind
of
consequences
need
to
also
be
discussed,
but
I
I
think
this
is
a
great
taxonomy.
G
A
G
A
A
G
A
G
So
I'm
going
to
take
a
few
just
a
minute
or
two
on
this
slide
and
then
we'll
call
it.
So
next
is
how
do
you
identify
the
key
this,
and
this
is
to
try
and
figure
out
what
goes
into
eat
or
similar,
so
we
can
do
it
by
key
id,
which
is
standard,
cos
a
key
id
and
that
that
that
works
and
that's
all
fairly
well
understood
pretty
good
size
efficiency
works
with
heat.
You
could
do
it
by
a
uri.
G
G
You
can
do
it
based
on
claims,
so
you
you,
you
unpack
the
the
the
eat
message,
look
at
all
the
different
claims
and
somewhere
some
combination
of
claims
in
there
tells
you
what
the
key
id
is.
So
you
ue
id
or
serial
number
is
a
is
a
really
good
one
to
do
that.
This
thing
is
great
because
it
has
no
additional
bytes
added
to
the
size
of
the
attestation
evidence.
G
The
the
the
one
thing
I
wonder
about
it
is:
you
have
to
decode
unverified
data
that
you
have
to
decode
the
payload
to
get
at
it.
The
the
the
last
thing
is,
you
can
just
put
the
the
key
if
it's
a
public
key
in
the
attestation
evidence
itself.
So
this
is
like
the
you
know,
including
the
the
certificate,
and
then
you
of
course,
have
to
walk
it
up
in
the
chain
and
verify
it.
G
You
know,
ask
questions
and
information
about
how
we
you
know
what
kids
belong
in
eat
and
suggest
that
we
expand
into
not
just
key
ids,
but
also
endorsement
ids,
because
endorsements
carry
keys,
so
you
can
identify
the
endorsement,
and
then
you
get
a
lot
of
information
in
addition
to
the
key,
so
these
kind
of
kind
of
mechanisms
for
endorsements,
so
all
right
I'll
end.
There.
A
J
Hear
me
today:
yes,
we
can
all
right,
I'm
going
to
talk
about
trusted
path,
routing.
This
is
a
follow-on
to
a
previous
set
of
drafts,
which
was
actually
trusted
path.
Routing
was
really
trustworthy
because
we
split
out
a
number
of
things
and
put
them
in
a
different
draft
that
we
talked
about
yesterday.
Next
slide.
J
J
Now
this
draft
follows
on
to
some
of
the
other
drafts
we
talked
about
yesterday
and
today,
with
the
architecture,
the
yang
models,
the
profiles
for
routers,
all
of
them
feed
down
and
the
mechanisms,
including
the
yang
models,
are
used
for
the
definition
of
this
draft
and
the
solution.
It's
based
on
next
slide.
J
One
of
the
key
things
that
this
document
defines
are
yang
identities
for
trustworthiness
levels.
These
effectively
are
claims
and
they
could
also
be
encoded
as
ease,
but
we
used
yang
here
because
we're
talking
to
routers
and
those
claims
can
be
made
about
from
a
verifier
about
a
router
about
a
testing
router.
These
include
things
like
hardware,
authenticity
or
failures,
identities,
unique
identities,
boot
integrities
file,
system
integrities.
J
E
J
Absolutely
and
there's
other
people
who
are
on
this
rat's
call
who
have
means
of
trying
to
find
ways
of
proving
various
levels.
So
I
think
that
we
need
some
kind
of
stake
in
the
ground
personally.
That
allows
us
to
kind
of
link
claims
to
prove
abilities.
There's
a
lot
of
potential
here
and
again,
I'm
trying
to
raise
the
question
to
see
if
it
has
applicability
beyond
rallying
next
slide.
J
So,
in
the
end,
what
we
have
here,
we
have
a
trust
vector
which
is
returned
and
maintained
on
routers,
and
you
can
have
different
policies
for
different
topologies,
such
as
a
validated
boot
integrity
across
a
set
of
devices
or
a
validated
boot
integrity,
and
I'm
not
taking
any
other
level
of
failure
that
I've
found
in
the
claim.
And
so
you
can
do
grades
of
trust
across
a
network
based
on
at
least
a
standardization
to
some
degree
of
the
attestation
results
which
come
back
down
to
the
network
next
slide
and
that's
pretty
much
it.
J
The
open
questions
that
I
see
are:
does
the
working
group
want
to
generalize
and
standardize
appraisal
results
and
encodings?
That's
something,
I'm
hoping
that
either
people
have
comments
now
or
have
them
on
the
list.
We
do
have
another
thing
that
we're
trying
to
do
with
defining
the
payload
to
get
the
information
of
appraisal
results
over
existing
things
like
802.1x
or
maxsec,
and
I
guess
the
open
question
beyond
the
appraisal.
Results
is.
J
I
J
Okay,
we
have
done
some
of
this
in
the
lab.
We've
done
it
with
isis
flex
algo,
so
that
in
igb
community
you
pass
it
around.
We
have
tests
underway
to
do
it
with
bgp,
so
you
can
pass
this
across
inner
domain
boundaries.
That
means
that
you
can
pass
the
information
from
one
carry
to
another
without
ever
actually
connecting
to
the
verifier,
and
it
will
allow
you
to
assert
the
trustworthiness
of
a
link
based
on
that,
so
so
igp
and
bgp
both
can
be
supported.
C
Oh
day,
taylor,
so
I
don't
know
whether
I
understand
the
trustworthiness
vectors
enough,
but
from
what
I
do
understand
is
that,
in
the
context
of
trusted
path,
routing
you're
using
it
as
a
way
to
provide
finer,
grained
error
cases
right.
If
everything
was
green,
then
just
you
don't
need
them
per
se,
because
it's
equivalent
to
saying
your
attestation
result
is
okay
right,
you're,
using
that
to
provide
finer
grains
of
failure
that
may
be
soft
fill
your
feeds
of.
That
is
what
I'm
understanding
my
opinion
on
the
standardization
question
is.
C
I
am
not
yet
convinced
that
there's
anything
that's
generalizable
outside
the
scope
of
trusted
path,
routing,
I
don't
have
any
opinion
as
to
whether
it's
useful
to
standardize
in
routing
the
answer
might
be.
Maybe
I
don't
have
enough
knowledge
there,
but
outside
of
that,
I
think
there's
too
much
heterogeneity
to
to
at
least
from
what
I
can
tell
so
far
to
say
what
types
of
soft
failures
are
interesting
in
general
and
that's
because
you
have
composite
devices,
you
have
layered
attestation.
C
You
have
different
types
of
attestation
that
have
different
leafs.
So,
for
example,
it
goes
all
the
way,
an
application
that
starts
long
after
boot.
So
it's
not
boot
integrity.
It's
you
know
what
is
the
leaf
of
your
chain.
Is
that
data?
Is
it
an
application
so
on
so
across
different
use
cases?
I
think
there's
enough
heterogeneity
that
the
set
of
interesting
soft
failures
may
vary
too
much
and
so
right
now.
I
don't
think
that
it's
useful
to
standardize
outside
of
a
very
limited
use
case,
and
so
I
don't
have
any
opinions.
C
J
All
right,
I
think
those
are
very
legitimate.
We
have
a
general
cases
which
are
hardware
software
fail.
You
know
those
kind
of
things,
the
specifics
and
the
details.
You
know
the
legitimate
question:
is
it
reasonable
enough
to
have
general
categories
when
we
have
specifics
also
needed
yeah?
Definitely
an
open
question.
A
J
What's
your
question
well
I'll
insert
first
I
mean
it
could
be
adopted
here
because
we're
really
just
using
the
yang
yang
chera
model
and
the
you
know
as
definitions
and
extending
it,
the
question
of,
is
it
general
for
a
attestation
language
spanning
beyond
routers,
I
heard
dave
say
not
beyond
routers,
but
adopting
four
routers
could
be
here.
We
have
other
stuff
adopted
four
routers.
I
don't
know
where
else
it
would
go
if
it
you
know,
if
it
wasn't
here.
C
H
C
A
Great,
so
let
me
ask
okay,
sorry
eric
we're
out
of
time,
I'm
already
eight
minutes
over
from
the
agenda.
So
why
don't
we
post
this
in
the
group?
I
was
going
to
ask
if
there
were
people
on
the
call
who
have
read
the
draft,
because
we
need
to
have
at
least
a
few
people
before
we
can
put
the
question,
but
I
can
just
put
the
question,
or
one
of
the
chairs
can
put
the
question
in
the
mail
list
or
interest
for
adoption.
A
B
I
can
just
talk
faster
okay
now
I
can
do
this,
so
that
was
an
interesting
discussion,
because
yeah
this
presentation
is
called
trustworthiness
vectors,
because
I
stole
that
term
from
from
eric's
initial
draft
and
we
apply
it
to
the
to
the
world
of
suit
and
we'll
talk
about
how
suit
can
be
the
source
for
evidence
and
attestation
results
in
the
end
also
for
rats
brandon
will
present
something
complementary
and
suit.
I
am
doing
this
here
so
next
slide.
Please.
B
B
B
B
Next
slide,
please
so
there
are
so
called.
I
would
call
them
on
the
easy
side
of
the
suit
claims
we
talked
about
here,
a
suit
manifest
naturally
brings
with
you
gripping
so
that
claims
about
hardware
and
software,
because
an
update
only
applies
to
a
certain.
I
don't
know
vendor
model
type
conglomerates
and
there's
probably
some
software
already
installed,
maybe
at
the
factory
default.
So
these
are
the
system
property
claims.
They
are
very,
very
similar
to
the
claims
in
it.
They
are
only
relatively
specific
in
suit.
B
So
that's
an
interesting
thing
to
highlight
here.
Maybe
we
should
map
that
at
some
point,
because
each,
for
example,
has
the
vendor
claim
in
an
oem
id
claim
and
such-
and
this
is
closely
related
to
similar
values
defined
in
a
suit
manifest.
So
a
mapping
here
would
be
an
order.
The
id
that
I'm
talking
about
here
this
is
about
the
claims
coming
from
to
be
consumed
in
reds
or
to
be
used
and
reds
is
talking
not
at
all
about
the
existing
claims,
yet
just
list
them
to
have
a
starting
point.
B
It's
a
zero,
zero
draft,
but
now
next
to
that,
that's
the
other
would
call
them
like
the
more
well-known
sets
of
claims
that
we
create
in
evidence.
We
now
have
this
update
procedure
and
this
actually
looks
quite
like
the
flow
chart
I
eric
presented.
So
so
there
are
now
command
sequence
in
the
manifest
how
a
receiver
of
the
manifest
manifests.
B
Sorry
recipient
of
the
manifest
should
should
process
the
update,
and
some
of
these
things
are
conditions
they
may
fail,
but
it's
not
it's
not
harmful,
necessarily,
and
then
there
are
so-called
directions.
I
think-
and
these
are
a
hard
failure.
So
if
these
fail,
probably
you
cannot
proceed
with
the
update,
so
this
is
again
a
chain
of
trustworthiness
levels.
B
So
that's
the
thing
I
stole
first
terminology-wise
here
and
you
you
chain
them
in
a
sequence
and
even
if
some
of
them
fail
because
they're
conditions,
they
are
still
being
like
a
red
x
in
your
trust
within
this
vector
here,
and
that
is
basically
the
same
thing
as
in
the
other
slide.
We
just
saw
next
step.
Please.
B
Yeah
so-
and
these
vectors
are
now
interesting
because
I
heard
a
lot
of
people
always
say:
why
do
you
need
verifier
and
harness
put
it
very
very,
very
in
a
nutshell,
I
think
you
only
need
a
verifier
when
the
output
that
is
in
the
evidence
is
too
complex
for
hidden
party.
So
in
this
case
the
output
is
already
very
much
refined.
It's
like
a
gps
card.
In
it
I
mean
you,
don't
tinker
with
the
values
there.
It's
it's
a
gps
card.
What
you're
going
to
do
with
it?
B
They
are
either
in
scope
or
out
of
scope,
but
you
don't
have
a
complicated
appraisal
procedure
that
is
the
taking
ton
of
memory
to
understand
that
like
like,
for
example,
the
contour
example
would
be
a
secure
boot
where
I
don't
know
hundreds
of
measurements.
If
you
have
to
appraise
very
carefully
in
order
to
access,
if
this
is
an
authenticated
device,
so
here's
the
same
thing.
G
B
Yeah,
absolutely
okay:
I
was
oversimplifying
you're,
absolutely
correct.
All
of
your
cases
are
applicable
here
and
these
from
from
case
to
case
basis.
Whatever
factors
are
relevant
to
you,
you
can.
You
can
create
subsets
from
these
evidences
and
now
my
dear
expert
is
on
the
queue
and
I
would
like
to
talk.
K
Hi
yeah,
as
as
this
is
brendan
on
the
mic,
as
hank
pointed
out,
there
are
essentially
two
channels
here.
The
the
first
channel
is
system
properties,
and
that's
something
that
I
would
expect
a
relying
party
to
be
able
to
comprehend
without
too
much
difficulty
and
the
second
sort
of
channel
that
comes
out
of
suit
is
the
the
suit
reports.
B
Thank
you,
brandon
yeah.
I
could
put
it
better
for
it.
So
yes,
there's
this.
This
new
part
here
is
the
output
that
are
the
interpreter
record
claims
and
and
that
that's
that's
also
probably
can
be
associated
with
this
binary
pass
and
fail.
It
might
be
scopes
again,
like
gps
coordinates,
might
be
a
volume
not
just
a
inside
outside.
B
We
can
talk
about
that.
It's
a
zero,
zero
draft
right
now
and
it
lists
all
the
things
that
can
be
potentially
produced
by
a
suit
report
today
and
I
think
that's
relevant
to
to
rats
most
certainly,
and
as
I
realize
now,
it
is
relevant
to
dave's
question.
I
think,
maybe
even
because
he
was
asking
well,
I
don't
know
if
this
valid
outside
the
scope
of
routers
and
by
accident.
B
Yes,
I
think,
there's
at
least
one
other
domain,
and
and
probably
there
are
more
if
this
is
worth
being
generalized
or
has
this
just
be
two
sets
of
drafts
that
define
additional
claims?
I
don't
know
yet,
but
maybe
that
is
over
time
worth
actually
the
discussion
here
and
I
think
that's
the
last
slide
here,
I'm
relatively
sure,
oh
and
dave
is
also
on
the
queue.
So
then
I
would
open
up
the
line
for
follow-up
questions.
Dave.
C
Dave
time
for
a
comment,
I
think,
in
the
context
of
suit
trump
trustworthiness
may
be
the
wrong
term
right.
If
the
point
is
to
say
that
failure
of
particular
suit
commands,
you
want
to
be
able
to
report
failures
and
act
on
failures
in
different
ways.
There
are
some
directives
that
might
not
affect
trustworthiness
in
the
classic
sense.
That
may
still
be
interesting,
and
so
maybe
it's
the
wrong
term,
and
so
that
is
my
comment
on
eric's,
where
it
is
specific
to
trustworthiness.
C
B
B
So
if
you
look
at
the
suit
manifest
draft
closely,
there's
a
boot
procedure
section
there,
but
also
would
fall
under
the
system,
property
claim
section
and
that
most
certainly
is
about
trustworthiness
and
transitioning.
These
would
be
a
violation
of
trustworthiness
into
a
state
of
not
being
trustworthy
anymore,
so
the
update
might
improve
being
neutral
on
or
even
we
have
a
detriment
on
on
the
trustworthiness
of
a
device
being
it
consciously
like
like
a
deliberate
purpose
or
like
an
attack.
B
You
don't
know
updates
are
a
remediation
procedure,
but
they
are
also
sometimes
the
first
time
without
rats
that
you
realize
that
something
is
wrong.
So
I
would
not
say
it's
not
about
trustworthiness
per
se,
always
maybe
we
have
to
deliberately
especially
highlight
which
subsets
of
this
suit
report
generated
is
about
trustworthiness
and
which
might
not
be
reliably
about
trustworthiness,
an
association
I
guess,
but
maybe
that's
up
to
future
work.
A
A
B
B
B
The
thing
that
you
put
in
place
of
the
now
omitted
signature
has
to
be
as
good
as
the
signature
and
as
you
are
conveying
stuff
in
this
ide,
and
this
is
therefore
always.
The
omission
therefore,
is
always
is
application
specific,
never
just
stand
alone
without
context,
you
cannot
just
generately
omit
a
signature.
Our
omission
of
signature
with
using
uccs
has
an
initial
use
case
that
is
important
to
understand
why
it's
like
the
perception
prescription
of
a
medicine.
We
do
this
next
slide.
B
B
In
other
scopes,
the
omission
of
a
signature
might
have
totally
different
implications,
so
every
use
of
a
uccs
has
to
come
with
a
description
and
and
as
a
security
consideration
that
is
very
specific
to
the
application
of
omitting
a
signature
and
creating
a
uccs,
and
in
this
case,
as
we're
doing
this
here.
First,
our
selection
was
tech
creation
specification.
B
Then
the
red's
user
scenario
for
conveyance
of
conceptual
messages
and
creating
required
text
about
recreating
the
climates
of
the
secure
channels
conveys
that
this
is
basically
a
reasoning.
Why
the
document
looks
like
it
does
now.
We
are
doing
this
not
in
the
pull
from
thin
air,
so
to
speak,
all
the
involved
parties
from
global
partners
that
were
working
working
on
endorsed,
unendorsed,
sorry,
tokens
of
course
involved,
and
we
had
some
some
improvement.
B
That's
basically
what
this
slide
is
effectively
about
on
the
privacy
preserving
part
here,
because
of
course,
authenticity
of
one
party
is
very
relevant.
For
example,
if
you're
talking
about
endorsements
like
in
reds,
probably
the
party
that
sends
you
something
unsigned-
we
are
a
tls
channel,
I'm
not
pulling
stuff
from
thin
air
should
be
authenticated
you.
On
the
other
hand,
the
receiver
might
not
always
have
to
be,
and
so
this
this
is
the
scope
of
questions.
We
are
elaborating
on
the
text
right
now.
If
you're
interested,
please
have
a
look.
B
G
I'm
a
fan
of
the
very
short
uccs
without
the
the
extensive
discussion
of
sort
of
rats
attestation
evidence
to
me
that
the
security
considerations
for
rat
statistician
evidence
should
be
a
rats
document.
Uccs
has
used
use
far
beyond
rats,
it's
just
a
general
data
format,
so
I
mean
I've
written
extensively
on
this
and
and
kind
of
been
voted
down,
but
I
thought
I
would
just
mention
it.
B
G
So
so
uccs
gets
used
for
as
annotation
evidence
attestation
results
probably
for
endorsements.
You
can.
I
don't
think
you
want
to
write
the
security
considerations
for
all
of
those
in
the
uccs
document,
but
they
have
to
be
written
somewhere.
That's
what
that's
it
seems
like.
It
gets
too
tweaked
and
torqued.
If
you
go
down
the
path
and
then
you
know
you
could
be
using
tpm
signatures,
you
might
be
using
tls
for
securing
uccs.
It
just
seems
like
it
snowballs.
If
you
really
do
a
thorough
job
of
it
and
it
gets
very
context,
sensitive.
B
Yeah,
but
that
is
security
unfortunately
is
that
is
our
problem.
We
were
talking
about
what
would
happen
if
we're
not
doing
this
and
we
could
imagine
catastrophe
so
to
speak.
So
so
we
are
very,
very
very
careful
here.
If
you
can
play
out,
there
is
have
to
be
multiple
documents
in
in
reds,
for
example,
due
to
the
rechartering
when
we
go
from
from
attestation
evidence
workflows
to
education,
provisioning
workflows,
maybe
actually,
yes,
we
might
have
to
write
a
second
document,
maybe
align
with
your
very
nice
taxonomy.
There,
probably.
K
E
E
A
E
E
E
E
Okay,
we'd
like
to
figure
out
if
this
is
ready
for
working
group
adoption
we've
had
five
people
read
it
so
of
those
that
have
read
it.
I
I'm
debating.
If
the
hum
tool
is
well,
I
guess
for
those
who
have
read
it,
can
you
just
make
a
comment
in
the
chat
if
you
think
it's
ready
for
adoption,
just
since
we're
short
on
time.
E
E
All
right,
so
we
have
a
few
saying
so
far.
We
have
all
yeses
saying
it's
ready
for
adoption,
we'll
take
it
to
the
list,
I'll
just
check
with
russ
and
jess
to
see
how
much
time
they
need
to
read
the
draft
and
have
that
time
period
extended
so
that
they
have
enough
time
to
read
it
to
weigh
in
on
whether
it's
ready
for
adoption
and
provide
their
feedback
to
help
improve
it.
Thank
you.
Everyone.
L
Can
you
hear
me?
Yes,
okay,
cool,
thank
you,
okay,
so
maybe
next
I'm
gonna
next
slice,
please
gonna,
try
and
present
the
main
ideas
in
in
draft
to
show
raspberry,
because
the
feedback
we
received
was
the
documents
not
super
easy
to
parse,
so
I'll,
try
and
click
and
clarify
at
least
the
main
points.
The
hope
is
that
the
the
ideas
may
be
useful
to
others
who
are
looking
at
the
same
problem
space
looking
at
how
to
instantiate
the
rats
architecture
using
some
well-known
two
in
the
atf
toolbox.
L
It
is
critically
important
to
to
evaluate
the
security
state
of
the
operators
before
you
can
act
upon
its
stimulus,
and
typically
this
is
the
case
in
critical
infrastructure,
say
the
dam
railway
power
plant
et
cetera,
but
it
could,
but
it
could
also
be
the
case
in
in
some
industrial
iot
scenarios.
Okay,
so
for
the
sake
of
argument,
let's
take
the
example
of
a
dam
and
see
how
the
tested
resource
concept
would
fit
in
there.
L
So
so
the
idea
in
this
scenario
is
that
the
water
level
sensor
would
be
exposed
as
an
untested
resource
that
the
spirit
controller
can
create
regular
intervals
or
maybe
subscribe
and
and
decide
whether
anything
needs
to
be
done
to
keep
the
watering
and
outflows
in
balance
and
clearly
and
clearly
the
spillway
controller
needs
to
trust
the
water
level
sensor.
Otherwise,
you
know
horrible
things
may
happen
downstream
and
that's
where
the
a
tested
part
of
an
attested
resource
comes
in
handy
yeah.
L
Next,
please
next
piece,
okay,
so
what
is
the
value
proposition
here?
What
doesn't
a
tested
resource
provide?
First,
obviously,
the
resource
representation
in
the
use
case
we
are
discussing
here.
This
would
be
your
water
level
reading
and
second,
the
evidence
about
the
security
state
of
yosting
platform
in
the
form
of
an
attestation
report
of
evidence,
as
the
architecture
draft
calls
it
and
third
a
freshness
indicator
either
from
the
color
or
the
colleen.
L
And,
lastly,
and
more
critically,
I
would
say
we
want
a
secure
mixing
function.
That
meshes
is
meshes
the
the
inputs
together
in
a
way
that
cannot
be
subverted
by
an
active
attacker.
So
someone
who
could
play
cut
and
paste
or
other
kinds
of
manipulation
tricks
on
the
exchange
of
payloads
needs
to
be
detected
next,
please
and
so
okay.
So
our
draft
defines
what
and
tested
resources
and
together
with
that,
it
describes
a
basic
restful
interface
to
access
it.
L
We
go
a
bit
further
than
that
and
and
also
provide
an
interface
to
the
verifier
that
is
very
similar
to
the
tested
resource
as
it's
built
on
the
same
principles
in
particular.
The
mixing
function
is
the
same
same
thing.
There
same
construct,
and
we
do
so
mainly
because
it's
critical
to
have
that
in
the
password
topology
where,
where,
where
get
tested
forwards,
data
produced
by
the
verifier,
and
so
we
need
some
sort
of
common
format
there.
So
it's
not
required
in
background
check
topology,
where
you
don't
need
that
level
of
interac
internal
coherence.
L
So
there
you
could
have
completed
a
couple
interfaces
but
but
for
passport
is
absolutely
needed.
Next,
please,
okay!
So
this
is
the
implementation
model
we
envisage.
The
hosting
platform
has
a
rich
execution
environment
based
on,
say,
linux
or
zephyr,
or
embed
os,
and
a
trusted
execution
environment
parallel
to
death,
say
tfm
on
top
of
trust
zone
and
the
ree
hosts
the
rest
front
end
so
either
an
hdp
or
a
clap
server,
or
maybe
a
dual
stack
app.
L
Next,
please,
okay!
So
before
we
hinted
at
this
combining
function
and
its
security,
critical
job,
so
the
mixing
function
is
is
a
core
component
in
the
tested
resource
game
because
it
provides
a
fundamental
security
guarantee,
which
is
that
the
resource
and
the
platform
security
state
for
for
a
given
transaction
cannot
be
separated
without
breaking
the
verification
process.
So
this
is
what
prevents
an
attacker
to
splice
together
at
the
station
and
and
the
resource
representation
from
different
transactions
into
something
that
becomes
acceptable
to
to
the
verifier
and
the
ingredients.
L
For
this
are
three
n
and
an
optional
challenge
provided
by
the
protocol
initiator
by
the
client
t
an
optional
time
stamp
that
is
provided
by
the
protocol.
Responder.
The
server
and
r,
which
is
the
naked
resource,
representation
and
and
the
mixing,
is
simply
the
hash
of
the
concatenation
of
the
three
right
with
length
indicators
to
for
robustness
and
and
and
and
the
result
of
this
competition
is
then
assigned
to
the
norm's
claim
in
the
associated
attestation
report
and
therefore
it
gets
signed
by
the
platform
attestation
key
okay.
L
So,
basically
you
take
this
blob
out
of
the
mixing
function
that
captures
the
current
resource
state,
plus
the
transaction,
identifiers
or
freshness
indicators.
However,
you
want
to
call
them
and
make
it
a
piece
of
the
attestation
report,
so
this
is
this
is
how
the
chaining
between
the
resource
and
data
station
works,
so
so
this
is
how
the
tested
resource
is
built
and
note
that
in
this
process
we
stressed
about
the
semantics
of
the
nodes
of
the
noun's
claim
that
is
described
in
in
the
x-back.
L
A
L
A
L
Okay,
thank
you.
No
worries,
okay,
so
the
absolute
interfaces
first,
the
tester
so
x
here
is
typically
the
relying
party
which
initiates
the
transaction
and
supplies
the
optional
challenge.
Nx,
the
tester
answers
with
the
tested
resource
that
is
composed
of
r
the
resource
representation
itself
and
the
optional
test.
Mta
is
a
snapshot
of
the
local
clock
and
the
attestation
report.
Capital
e,
which,
by
means
of
the
mixing
function
that
we
discussed
just
two
slides
above,
depends
on
the
freshness
indicators
and
the
current
resource
state
optionally.
L
If,
if
a
previously
computed
station
result,
capital
r
over
capital
e
is
available,
for
example,
this
is
the
case
in
passport
topologies
that
can
also
be
attached
to
the
reply.
Next,
please
another
the
verifier.
Why
is
the
client?
It
can
be
the
relying
party
in
background
check
or
in
a
tester
in
passport
mode?
Why
sends
the
evidence
to
be
verified
and
an
optional
nonce,
and
why
the
verifier
does
you
know
the
verification
and
responds
with
an
optional
stamp
tv
again,
a
snapshot
of
the
local
clock
and
capital
r.
L
So
this
is
background
check
with
norms-based
freshness,
drp
requests
the
attested
resource,
sending
a
challenge
nx
the
tester
provides
the
compound
resource
imagination.
Evidence
drp
can
check
at
this
point
in
time
whether
the
attested
resource
has
been
manipulated
in
transit,
if
not
a
drp
strips
the
resource,
representation
and
and
and
just
forwards.
The
evidence
to
the
verifier,
the
verifier
returns
the
decision
results,
which
depends
on
e
by
means
of
the
mixing
function.
At
this
point,
the
rp
has
all
the
elements
to
decide
whether
to
trust
a
or
not.
L
Okay,
this
so
that
that
thing
maps
into
this
following
instantiation
on
the
rpa
tester
lag.
You
have
the
rp,
sending
a
co-op
post
to
the
tested
resource
uri
on
on
device.example,
the
the
the
tester
node
with
the
nodes
encoded
with
the
right
mime
type
and
carried
in
the
code.
Payload
and
and
quantum
negotiation
done
by
via
the
accept
option
as
usual
and
assuming
everything
is,
is
all
right.
And
then
then
the
attester
replies
with
a
co-app
to
one
response
with
the
tested
resource
that
is
wrapped
up
in
the
right
content.
L
L
This
one
instead
is
a
passport,
a
topology
with
freshness
based
on
time
stamps.
Here
the
tester
snapshots
that
tested
resource
at
the
time
ta
sends
the
computed
evidence
to
the
verifier,
which
provides
an
attestation
result-
capital
r,
when
us
at
a
subsequent
point
in
time,
the
relying
party
requests
the
attested
resource,
the
tester
replies
with
the
tested
resource
previously
computed
and
the
attestation
results
that
he
got
from
the
verifier.
L
L
Okay,
so
we
can
skip
over
this.
This
is
very
similar
to
the
previous
acceptors
read
more
stuff
in
the
response
from
your
tester
skip.
Keep
this
please
last
thing
is
discovery.
I
think
one
can
discover
whether
I
know
the
hosts
in
a
tested
resource
using
the
core
resource
directory.
Okay,
in
this
completely
made
up
example,
node
one
is
a
hurt.
A
heart
rate
monitor
that
advertises
in
an
in
a
tested
resource
with
a
uri
path
that
is
slash,
sensors,
leisure,
tested,
heart
rate.
L
The
fact
it
is
in
a
it's
a
tested
resource
is
indicated
by
the
content
type
ct
equals
rather
tested
resource,
while
the
interface
iaf
equals
rats.
If
timestamp
says
that
the
tester
will
provide
a
timestamp,
so
if
you
happen
to
trust
its
clock,
you
may
as
well
decide
not
to
supply
unknowns
in
the
initial
query,
of
course,
you
may
expect
an
attestation
report
too
using
this
interface.
L
This
also
says
that
the
inner
content
ibc
ict
is
zero,
which
is
the
co-op
code
point
for
the
text,
content
format
and
as
long
as
soon
as
the
tool
one
is
received.
So
the
the
the
registration
was
successful.
The
any
client
of
the
rd
can
discover
the
tested
resource
and
its
properties
by
firing.
You
know
the
appropriate
queries
to
drd
interface.
L
Couple
of
discussion
points:
is
there
an
appetite
for
a
generic
substrate
either
this
thing
or
something
similar?
Should
we
go
forward
with
this
effort?
I
mean
with
the
conceptual
thing
it
seems
to
be,
you
know
baked,
but
but
there's
a
ton
of
things
in
terms
of
you
know,
registering
code
points
and
and
and
and
defining
a
bit
of
more
of
the
machinery
that
okay,
if
needed,
I
mean.
A
H
A
You're
welcome
to
come
back
at
the
next
session
and
you
know
present
an
update
and
findings.
Okay,
sure,
okay,
thank
you.
Thank
you
all
right,
so
I
have
three
minutes
left,
I'm
hoping
meet,
echo
won't
cut
my
time
or
that
we
can
cover
this
quickly.
So
we
need
to
update
our
milestones,
so
this
is
literally
a
cut
and
paste
for
what
we
submitted
and
updated
many
months
ago.
A
Oh
thanks
roman.
So
hopefully
I
have
seven
or
eight
minutes.
So
what
I
did
thank
you.
So
what
I
did
was
I
put
this
on
the
spreadsheet
to
cover
just
given
that
there's
more
drafts
for
those
who
who
have
drafts,
who
are
you're
not
seeing
this
here,
don't
panic!
Yet
what
I
wanted
to
do
was
at
least
first
update
what
we
currently
have
and
reflect
that
so
going
through
this,
I
think,
we've
we've,
we've
gotten
good
use
out
of
the
use
case.
Documentation
fed
that
into
the
architecture
draft.
A
A
B
A
B
A
A
G
G
I
think
it
also
should
should
discuss
attestation
results
and
there's
there's
some
still,
I'm
still
trying
to
get
some
stuff
sorted
out
with
architecture
and
like
what's
in
eat
and
what's
in
architecture,
still
is
still
up
in
the
air
in
some
ways
in
my
mind,
and
so
I'm
trying
to
get
some
things
into
the
architecture
document
about
endorsements
clarified.
So
I
know
what
to
put
in
eat.
A
A
Let's,
let's
update
it
for
december
and
then
I'll
tack
on
six
months,
which
may
put
it
to
the
july
21
for
isg,
submission
and
roman
did
correct
me.
Yes,
roman,
I
didn't
mean
for
and
I'll
update
it,
not
necessarily
for
publication,
but
just
submitting
it
to
to
iesg
okay,
so
that
takes
care
of
the
eat.
B
Okay,
excellent
because
it
doesn't
show
micro,
my
as
well,
so
I
think
this
is
the
list
here
shows
that
the
sequence
better,
I
think
interaction
model
should
go
first.
Riv
and
yangchara
rely
on
it,
so
that
should
be
the
focus
on
adoption.
Tudor
also
relies
on
the
interx
model,
of
course,
but
I
think
if
you
go
in
sequence,
we
should
focus
on
interaction
model.
First,
we
can
do
interaction,
model
and
tudor
in
a
bundle.
I
guess
I'm
not
I'm
not
against
that,
but
we
should
adopt
yeah
because.
A
C
Yeah
so
remember
on
the
interaction
models.
There
was
the
pull
on
the
list.
There
was
the
you
know,
options
one
two,
three
and
four,
and
so
far
the
presumed
answer
that
I've
seen
anyway
is
there's
more
people
for
option
two,
which
is
all
interaction
models
in
the
same
document.
One
could
argue
that
tuta
is
elaboration
of
a
particular
type
of
interaction
model,
and
so
there's
the
open
question
is:
should
those
two
things
be
combined
or
not?
And
so
this
is
a
long
way
of
saying.
C
I
think
you
should
remove
the
two
to
milestone,
because
you
can
always
have
a
working
group
choose
to
take
a
particular
milestone
and
meet
it
with
multiple
documents.
And
so,
if
you
remove
the
two
to
draft
and
just
say
interaction
models,
and
you
know,
adopt
a
draft
or
drop
one
or
more
drafts
on
interaction
models.
I
think
that's
a
better
way
to
craft
the
milestones
like.
A
C
A
Yes,
okay,
so
the
if
we
can
move
on
from
from
two
to
an
interaction
models.
I
think
I've
got
that
one
covered
with
the
architecture
draft.
We
didn't.
I
need
to
add
another
milestone
for
iesg
before
I.
I
am
not
awake.
My
apologies
for
the
architecture
draft.
We
need
to
do
a
working
group
last
call
hank
in
your
presentation.
It
seemed
like
you
still
had
some
issues
to
discuss.
I
I,
as
I
was
tracking
all
of
the
issues.
I
thought
you
guys
were
getting
close.
B
A
Well,
I
mean
I
I'm
not
opposed
to
doing
multiple
working
group
last
calls
just
to
shake
out
more
more
feedback
too.
So,
let's
for
september,
just
let
me
know
let
the
chairs
know
sorry,
so
that
we
can.
We
can
start
that
last
call,
and
then
the
question
is
whether
we
think
three
months
is
too
aggressive
for
iesg
publication.
A
A
Okay,
so
what
I'm
going
to
do
is
in
the
next
few
days,
I'm
going
to
send
a
request
to
make
sure
that
we're
ready-
because
I
haven't
seen
in
the
mail
list
some
of
those
comments.
So
I
will
do
that
barring
that
then
we
can
issue
a
working
group
last
call
in
august
and
then
the
question
is
whether
you'll
be
able
to
react
to
all
the
feedback
so
that
we
can
submit
it
for
publication
in
december,
because
that
was
the
proposal.
So.
A
A
With
that.
We
are
well
over
time
and,
as
kathleen
said,
the
next
sessions
will
be
starting
soon.
So
thank
you.
Everyone
for
the
participation
one
last
piece
of
administrative
is
that
we'd
like
to
hold
two
interim
meetings
between
now
and
the
november
and
again
in
the
interest
of
time
we
can
post
that
in
the
list
and
if
there's
approval
we
can,
we
can
set
up
doodle
polls
on
timing.
For
that.