►
From YouTube: RATS WG Interim Meeting, 2020-03-31
Description
RATS WG Interim Meeting, 2020-03-31
A
And
let
me
just
go
through
the
note.
Well
so
I'm
looking
at
list
list,
everybody
has
been
here
so
and
participated
in
the
ITF,
so
I'm
consuming
you're
well
aware
of
I,
know
well
and
IETF
policies
with
respect
to
participation
with
that
with
the
agenda.
I
wanted
to
take
five
minutes
to
do
the
bashing
and
to
remind
everyone
that
we
are
recording
the
session.
There
is
a
jabber
room,
given
that
we
do
have
a
jamboree.
Is
there
anybody,
that's
willing
to
help
us
monitor
that
and
Channel
Webber's
and
the
jabber
room
if
they
have
questions.
A
A
And,
given
that
we
do
get
into
discussions,
I
thought
I
would
ask
if
I
think
it
worked
really
well
during
the
virtual
sessions
last
week,
where
we
had
a
running
queue
for
those
who
may
not
be
familiar.
What
happened
last
week
was
anybody
who
wanted
to
speak
during
each
of
the
presentations
rather
than
speaking,
would
put
themselves
in
the
queue
in
the
chat
room
by
doing
a
plus
Q?
If
they
didn't
want
to
be
in
the
queue
or
be
removed
from
the
queue
they
would
put
a
minus
P.
A
A
A
Michael
and
then
anybody
who's
overlooking
the
ether
pad.
Please
feel
free
to
also
help
and
annotate
with
that.
The
other
process
that
we're
following
is
please
look
at
the
ether
pad
we're
running
the
blue
sheets
in
the
ether
pad.
So
add
your
name
there
to
make
sure
that
we
capture
everybody
who's,
participating
any
comments
or
issues
on
the
agenda.
A
A
E
E
Trick
maybe
that
was
hi.
This
is
Michael
Richardson,
so
there
has
been
a
approximately
weekly
or
more
often
design
team
meeting
for
the
architecture
draft,
and
we
have
mostly
met
on
Tuesday
mornings
at
10:00
a.m.
est
with
a
couple
other
fridays
and
had
some
other
ad
hoc
meetings
that
were
added
to
get
work
finished.
E
E
So
I'm
going
to
go
through
the
walk
through
the
architecture,
talk
a
little
bit
able
contents,
the
open
issues,
which
is,
of
course
changing.
It's
changed
since
I
made
the
slide
and
basically
the
what
we've
done
since
last
meeting
and
what
it
looks
like
next
slide.
Please
and
I'd
be
very
happy
to
take
questions
as
we
go,
but
I
have
left
a
junk
of
time
at
the
end
to
deal
with
questions
of
a
more
general
nature.
So
this
is
the
table
contents.
As
it
looks
now,
you
can
see
we
have
added
six
major
use
cases.
E
We
still
think
that
there
are
details
of
this
and
one
of
the
things
these
net
and
some
other
people
have
suggested
different
terms.
One
of
them
is
protocol,
who
is
when
you
describe
a
particular
use
case
and
how
it's
used
that
it's
actually
a
particular
protocol,
because
there's
a
conveyance
and
a
whole
bunch
of
other
things
that
are
involved
and
the
architecture
doesn't
deal
with
that.
E
So
number
nine
freshness
is
a
subject
of
a
discussion
with
Lawrence
and
Eric.
This
is
what's
become
timing,
and
how
do
we
measure
freshness
so
I'm
not
going
to
delve
into
that?
A
great
deal
in
that
part
and
I,
don't
think
there
should.
There
will
be
a
major
change
in
in
a
table
of
contents
as
we
go
forward,
but
if
there
is
some
particular
thing
that
you
want
to
discuss
in
there,
both
are
Cataldi
overview,
the
architecture,
the
architecture,
the
architecture.
That
would
be
a
reasonable
question
next
slide.
E
Thank
you
just
there's
a
delay,
so
these
are
some
links
to
the
open
issues,
at
least
as
of
Friday
morning
ish.
There
have
been
some
one
or
two
closed
since
and
one
or
two
open
in
general.
We
try
to
collect
concerns
that
we
may
have
as
issues
which
we
then
wind
up.
Having
pull
requests
to
change
the
text
or
sometimes
is
just
a
pull
request.
Here's
some
text.
E
Anyone
is
welcome
to
comment
to
review
and
we'd,
be
very
much
interested
in.
What's
going
on,
you
can
see
the
numbers
are
up
in
the
60s.
We've
closed,
quite
a
number
of
issues
as
we
go
on
forward
and
there's
maybe
one
or
two
issues
that
we
will
perhaps
never
agree
on
and
there
may
be.
There
are
some
issues
that
you
know
should
we
have
a
claims
terminology
which
is
almost
a
bike
shed
next
slide.
E
Since
last
time
you
may
have
seen
the
slide
from
before.
We
have
extensively
argued
and
created
an
introduction,
we've
reworked
the
terminology
discussion,
and
it's
pretty
much
done.
We
realized
that
the
word
claim
was
not
in
it
and
then
wondered
whether
we
needed
to
define
it,
and
we
actually
did
some
research
and
other
RFC's
that
do
need
to
find
the
word
claim
thinking.
None
of
them
actually
did
claim,
none
of
them
actually
defined
it.
E
E
So
ception
we
drew
this
three
box,
a
tester
verifier
and
relying
party
flow.
This
is
generically
what
happens.
There's
evidence
that
moves
from
the
it's
fester
to
the
verifier
and
there's
attestation
results
that
move
to
the
relying
party
and
then
having
written
that
flow.
We
realized
that
there
was
a
bunch
of
things
we
needed
also
we're
important
that
we
needed
to
define,
which
is
the
endorsements
from
the
endorser,
an
appraisal
policy
and
an
appraisal
policy
for
the
attestation
results
for
the
relying
party.
E
So
those
are
in
the
blue,
pink
and
purple
boxes
if
you're,
not
colorblind,
and
the
important
thing
to
realizes
that
these
are
none
of
these
are
currently
in
the
Charter.
For
the
current
IETF
rats
working
group,
it's
possible
that
they
are
not
in,
they
will
never
be
in
scope
for
the
Charter
or
it's
possible.
They
will
get.
The
working
group
will
get
reach
harder
to
include
one
of
the
or
more
of
these
items,
but
at
present
these
are
external
things
and
well.
E
We
can
discuss
the
properties,
we're
not
talking
about
how
to
standardize
those
the
way,
specifically
that
the
tests
are
verifying
relying
party
operate
and
the
things
that
they
omit
being
evidence
and
attestation
results
are
directly
within
the
rats
charter
and
the
architecture
speaks
about
the
properties
and
the
activities
of
each
next
slide.
Please
so.
E
E
E
So
some
people
ask
the
question:
can
any
object
be
trusted
properly
to
measure
itself?
Can
those
measurements
be
trusted
if
you
in
doing
that
self
next
slide,
and
so
we
have
agreed
to
the
statement
that,
yes,
this
is
possible
for
them
to
be
in
a
single
environment,
but
it's
up
to
the
verifier
to
decide
if
this
makes
sense,
and
so,
while
there's
a
lot
of
environments
where
this
would
be
an
untrustworthy
kind
of
thing.
Ultimately,
the
verifier
is:
what
decides
this
all
right
next
slide,
there's
a
question.
E
We
have
this
concept
called
layered
attestation
on
money
of
you
are
familiar
with
us
in
the
form
of
trusted
boot,
where
there
is
a
one
piece
of
code
which
runs
which
measures
the
next
piece
of
code
provides
evidence
for
it,
and
this
goes
on
and
we've
Illustrated
three
layers
in
this
case
next
slide,
please,
and
so,
for
instance,
the
first
layer
is
often
the
UEFI
BIOS
firmware
next
slide.
Please.
E
The
next
environment,
often
some
rich
execution
environment
as
that
the
tea
people
call
it.
You
know
some
operating
system,
something
else.
Some
kernel
and
pieces
like
that
next
slide.
Please
and
an
example
of
a
third
layer
is
maybe
there's
some
applicator
'get
applications
that
are
measured
or
configuration
or
set
of
processes.
These
layers
are
not
strictest.
You
could
have
two
or
seven
that's
irrelevant
to
the
thing
and
you
can
throw
them
in
different
ways.
These
are
just
examples
of
some
things
and
finally,
the
next
slide.
E
E
Along
the
way
we
have
come
across
the
defined
the
concept
of
a
composite
device.
A
composite
device
contains
a
lead,
a
tester,
which
is
the
term
that
we
decided
to.
We
settled
on
in
the
end,
and
the
leader.
Tester,
is
that
the
environment,
which
has
a
connection
to
the
verifier
and
is
going
to
accept
evidence
from
other,
a
testers
being
seen,
which
could
be,
for
instance,
line
cards
and
a
chassis
they
could
be.
E
The
example
of
a
smartphone,
where
there's
a
main
CPU
and
a
broadband
CPU
which
doesn't
have
internet
connectivity
and
therefore
doesn't
do
the
attesting
and
other
devices
where
there's
some
devices
attached
to
a
system.
Bus
of
some
kind
that
we're
not
all
devices
have
external
connectivity
in.
In
particular.
E
One
thing
I'll
note,
and
we
spent
a
long
time
talking
about
it's
entirely
possible,
that
a
test
or
B
or
C
provides
its
evidence
to
lead
a
tester,
a
who
then
goes
to
verifier
B
and
takes
an
ax
test
and
test
and
attestation
results
back
acts
as
the
relying
party
and
provides
that,
as
part
of
its
evidence
to
its
verifier
a
and
while
we
have
some
text.
That
explains
a
little
bit
of
that,
and
it's
a
third
dimension
to
this
diagram
that
this
is
not.
This
doesn't
really
change
the
architecture
in
any
way.
E
It
just
changes
the
nature
of
exactly
what
is
evidence
and
and
that's
fine.
What
matters
in
this
context
is
that
we
may
have
to
deal
with
the
fact
that
we
have
evidence
of
composite
devices,
and
this
evidence
may
be
may
be
signed
in
different
ways
by
different
things
by
different
testers
and
that's
the
critical
part
about
the
thing
next
slide.
E
So
the
topology
models
we
talked
with
them
way
back
in
the
the
first
IETF
we
came
up
with
this
concept
of
passport
and
background
models,
background
check
model,
someone
does
animation,
I,
would
sure
love
to
have
an
animation
where
the
top
diagram
mutates
into
the
left
diagram
or
the
right
diagram.
That
would
be
very
pretty
and
very
instructive.
The
the
important
thing
is
that,
logically,
the
evidence
always
goes
from
the
ax
tester
to
the
verifier,
and
you
can
see
on
the
bottom
left.
That
is
the
case.
E
It
goes
directly
from
there,
but
the
attestation
results
comes
back
through
the
attest,
a
tester
and
then
goes
to
relying
party
that
a
tester.
Well,
you
could
audit,
or
possibly
even
look
at
them
that
results
essentially
is
not
contributing
to
them
in
any
significant
way.
It
passes
them
on
through
a
different
kind,
another
conveyance.
Similarly,
in
the
background
check
model,
the
ax
tester
passes
as
evidence
for
the
relying
party
which
more
or
less
passes
that
directly
to
the
verifier.
E
Without
changing
it,
we
have
a
discussions
about
whether
there
could
be
additional
signatures
or
other
session
layer.
Conveyance
issues
between
the
relying
party
and
the
verifier
and
that's
entirely
possible,
but
fundamentally
there's
a
sign
to
artifact
that
goes
from
the
ax
tester
to
the
verifier
and
that's
the
thing
called
evidence
in
the
in
the
background
check
model.
E
Of
course,
the
attestation
results
come
back
directly
and
people
have
described
also
degenerate
cases
where
the
verifier
is
part
of
the
relying
party,
in
which
case
there's
no
conveyance,
no,
no
protocol,
it's
all
internal,
but
from
a
role
point
of
view.
We
see
the
three
pieces
and
three
colors
for
colorblind
people
next
slide.
E
We
expect
that
there
will
be
verifiers
that
can
deal
with
multiple
relying
parties
providing
some
commonality
and
therefore
may
have
to
speak
with
different
kinds
of
evidence.
Excuse
me
different
formats,
and
they
will
likely
speak
to
a
variety
of
different
kinds
of
a
testers,
different
products,
different
kinds
of
products,
different
revisions
of
those
products.
E
They
may
move
from
x.509
and
an
old
version
and
or
some
TPM
PT
CG
based
thing
to
see
WT
in
a
future
version,
and
so,
even
though
the
model
may
not
change
the
firmware,
could
change
in
the
verifier
therefore
may
be
accepting
evidence
in
multiple
different
kinds
of
formats,
but
in
general
the
thing
to
emphasize
is
that
the
evidence
of
a
particular
flow
for
particular
devices
in
one
format
and
the
attestation
results
come
out
in
one
format,
there's
no
requirement
that
the
results
be
produced
in
multiple
formats.
At
the
same
time,
next
slide.
Please.
H
E
A
F
G
F
G
G
They
should
be
designed
for
interoperability,
so
you
know
one:
relying
party
can
understand
what
they
mean.
You
know
so
that
that's
difficult
goal,
because
a
lot
of
times
people
want
to
do
proprietary
claims,
but
there's
value
in
getting
a
claim
design
that
can
be
understood
by
multiple
or
aligned
parties,
there's
trying
to
be
neutral
for
the
OS
or
the
technology.
So
you
know
it's
not
about
a
particular
offering
system.
It's
not
particularly
about
tes
or
tpms
or
javascript,
or
mobile
phones,
or
trying
to
be
neutral
about.
G
You
know
in
that
way
trying
also
to
be
neutral
about
security
levels,
so
we're
not
just
focused
on
on
high
security
environments
like
TPMS
and
secure
elements.
They
also
consider
load
security
environments
like
user
mode
apps
and
another
characteristic
in
was
the
want
to
try
to
reuse
extant
data
formats,
and
you
know
not
reinventing
things.
So,
for
example,
we
try
to
reuse
the
the
format
for
GPS
from
another
working
group
so
and
then
I
think
one
go
neck
to
the
next
slide.
Please.
G
Say
which
claims
are
used
in
which
use
cases
maybe
prohibit
some
others,
maybe
narrow
the
definition
of
existing
claims,
all
that
so
trying
to
manage
interoperability
of
claims.
So
the
real
question
here
and
and
is:
where
does
this
text
go
and
how
does
it
kind
of
fit
into
the
the
fit
into
everything
so
they
were
proposed
was
so
so
this
text,
you
know
a
lot
of
it-
could
be
I
guidelines
for
Ayane.
G
So
it's
more
of
a
I
think
the
question
here
is
not
so
much
about
agreement
or
disagreement
about
these
characters
takes
at
least
so
far.
There
hasn't
been
too
many
objections
to,
or
just
much
discussion
about
these
characteristics.
The
discussion
is:
where
do
they
go
so
one
you
know
I've
proposed
putting
them
in
the
8
document
at
first
they
were
just
generic
parts
of
the
document.
Now
I
think
they
might
be
Ayana
guidance.
I
My
comment
is
on
the
previous
slide
actually
have
AZ
on
your
letter,
question
I,
think
I.
Any
considerations
of
the
eat
document
for
anything
that
is
rest
specific,
is
great
and
anything
that
is
not
read.
Specific
is
more
for
the
you
know,
C
of
UT.
That's
to
answer
your
question,
but
the
reason
I
got
in
the
queue
was
to
say
that
there's
think
there's
another
characteristic.
That
would
be
good
to
add
to
the
list
and
I'm
not
sure
how
to
label
it.
Let
me
just
describe
what
I
mean
by
it
has
to
do
with
it.
I
It
occurred
to
me
when
you
talked
about
don't
reinvent
when
you
don't
reinvent
exec,
you
know
youth,
existing
structures
and
stuff,
but
it's
also
important
to
talk
about
when
inventing
claims
to
say.
Is
it
okay
to
reuse,
an
existing
claim
or
to
actually
need
to
have
a
new
claim
from
my
own
purpose,
and
so
this
might
be.
This
entails
one
piece
of
that
has
to
do
with
the
fact
that
you
can
get
a
a
name
such
as,
if
you're
doing
a
proprietary
extension,
you
can
get
a
new
name
or
something
that's
the
hollow.
I
I
generate
the
ID'd
question.
Well,
the
other
part
of
it
is
when
is
it
appropriate
to
say,
can
I
have
a
claim
that
can
appear
multiple
times
with
the
same
name
in
the
same
claim
set
or
do
I
need
to
have
different
values
for
it
or
if
I
had
different
values
for
it?
What
I
instead
put
a
list
of
things
inside
the
claim,
as
opposed
to
having
multiple
occurrences
of
the
claim
and
so
I
think
there's
needs
to
be
something
around
as
to
how
do
I
design
things
that
are
multivalued.
I
You
give
an
example,
and
one
of
the
piece
of
that
before
I,
give
an
example
is
also
what
happens
if
you
have
some
proprietary
things
and
some
standard
things
you
know.
Do
you
don't
mix
the
streams
you
put,
those
in
separate
claims
or
whatever?
So,
let's
say
what
example
is
in
teep.
We
have
a
use
case
that
says:
I
need
to
pass
it.
The
claims,
the
set
of
TAS
that
are
instan,
the
set
of
applications
are
installed
elsewhere.
I
Those
into
the
same
claims
are
those
two
different
claims,
because
those
are
two
semantic
meanings
right
and
so
here,
I
might
say
as
an
example
of
a
guidance
to
say
you
know,
don't
mix
those
two
keep
those
two
separate
but
have
the
claim
have
a
list
rather
than
having
claims
have
multiple
occurrences.
But
the
real
point
is
the
design.
Consideration
should
bring
this
up
and
have
some
recommendations,
regardless
of
whether
you
agree
with
my
intuition
or
not
yeah,.
G
H
C
I
just
want
to
return
back
to
the
question
you
had
learns
about.
Where
do
you
put
this
text?
I
mean
I
mean
some
ideas.
Is
that
if
we're
sharing
the
same
registries
with
CWT,
we
can't
say
anything
that
has
let
that
is
more
permissive
than
what's
in
there,
because
that'll
create
conflicts,
and
it
occurs
to
me
that
the
place
if
we
want
to
talk
about
how
claims
should
manifest
in
the
rats
architecture,
irrespective
of
how
they're
registered
in
the
CWT
it
seems
like
that,
should
be
covered
in
a
profile
document.
F
C
And
so
I
guess
they
might
had.
Let
me
kind
of
think
through
this
meet
the
e
draft,
it
numerate
s--.
What
the
claims
would
be
I
saw
in
the
slide
after
this
one
that
were
displaying.
We
were
talking
about
profiles.
It
would
seem
that
at
some
point
we
might
want
to
talk
about
how
they
made
manifest
themselves
in,
in
kind
of
the
real
in
the
real
world
kind
of
in
the
rats
architecture.
I
I
don't
mean
to
presuppose
where
it
goes.
Maybe
it's
an
appendix
in
the
e
trap.
G
So
I
think
I'm
a
little
confused
about
your
comment.
Roman
because
my
thought
would
have
you
know.
One
of
the
proposals
was
actually
a
revision
of
CWT
say
you
know
revising
the
guidelines
for
AI
an
enough
for
of
C
WTS,
because
a
lot
of
these
characteristics-
probably
most
of
them
by
just
fine
CWT.
They
were
not
really
rats.
Specific
I
mean.
C
That's
a
I
I,
wouldn't
I,
wouldn't
have
any
disagreement
with
that
option.
To
I
mean
to
me
that's
consistent
with
us
saying,
since
we
share
the
registry
with
CWT,
we
need
to
be.
We
need
at
least
kind
of
share
some
behavior
then,
and
we
can't
be
I
mean
we
can't
be
like
s
more
permissive,
then
that's
all
so.
H
This
is
Hank
so
for
my
breaking
ticket
before
I
think
if
you're
using
CD
ncwt
in
general,
we
are
stuck
with
in
keys
being
unique
and
therefore
we
would
I
think
there's
no
decision,
because
it's
clear
that
we
have
multi
value
here
now
and
I.
Think
that's
fine,
because
semantically,
it's
easier
to
this
I
assume
also
with
physical
characteristics,
s
I.
Think
that's!
A
very
meta
topic
here
is:
how
do
we
differentiate
attestation
results
and
evidence
sets
even
in
such
claim
sets
from
standard,
CWT
I?
Think
at
the
moment
we
cannot.
H
F
Okay,
two
things:
one
I
actually
read
this
the
set
of
guidelines
and
as
a
a
CWT
person,
I
did
not
think
that
they
were
necessarily
appropriate
for
CW
T's
I
think
that
CW
T's
have
very
very
different
guidelines
that
they
should
have.
The
second
thing
is
I
will
say
something
that
I
said
eons
ago
at
IEP
have
meeting
and
being
a
bit,
but
not
I.
Don't
think
I
actually
set
it
up
in
the
room.
D
A
Heard
the
guidance
from
Jim
as
to
creating
our
own
Rats
registry.
If
you
will
for
these
claims
and
then
from
Rome
and
I
heard
that
for
the
proprietary
ones
or
for
the
flow
that
we
could
not
good,
he
was
suggesting.
Then
we
have
separate
documents
and
I
may
be
stating
that
more
strongly
to
describe
them
as
profiles.
C
Yeah
I
mean
I,
think
that's
a
conversation.
We
should
have
yeah
I'm,
not
suggesting
we
need
those
profiles.
It's
separating,
registering
the
claims
and
describing
the
clings
to
me
is
different
than
then
describing.
What
set
of
claims
are
required
for
a
particular
profile,
a
use
case,
the
way
we're
talking
in
jabber.
H
Yes,
sorry
about-
and
this
is
addressed
to
Jim
and
the
group
of
course,
how,
where
to
register
and
registry,
we
talked
about
a
lot
about
having
our
separate
registry
and
then
we
would
have
a
semantic
input
and
mismatch,
because
we
would
define
same
claims
and
two
registries,
and
we
don't
want
to
do
that.
That
was
a
fundamental
decision.
H
I
think
we
made-
and
maybe
Jim
has
some
additional
feedback
about
that,
because
we
were
using
all
the
good
stuff
that
is
already
in
there
without
creating
semantically
well
slightly
different
things
with
the
same
keys,
but
at
the
different
tag
at
the
map.
I
don't
know
so.
The
the
idea
was
to
deliberately
use
this
WG
registry
and
I.
Think
Carson
Bowman
highlighted
that
we
could
maybe
add
a
row
through
this
sorry
column,
a
column
to
this
list
and
indicate
what
types
here
are
for
agitation,
remoter
decision
purposes.
D
D
G
F
Clear
I
am
advertising
a
sub
registry.
I
am
NOT
advertising
that
you
create
a
second
CWD
registry.
I
am
saying
you're
gonna
create
a
CW
t
claim
which
says
this
is
rats
information
that
is
a
sub
registry,
which
is
its
own
map.
You
can
go
to
town
in
that
registry
with
whatever
you
want,
they
are
separate
namespaces
and
they
are
easily
identifiable
as
separate,
namespaces
and
and.
F
I
Dave
Taylor
question
for
Jim
I'm
trying
to
understand
your
proposal.
If
you
have
a
rats
claim
with
if
I
understand
right,
are
you
saying
that
there
would
be
inside
of
a
rats
map?
There
would
be
claims
inside
there
separate
from
claims
outside
of
the
rats
claims
in
the
same
CWT?
And
if
yes,
then,
are
you
saying
that
inside
the
rats
set
of
claims
that
you
could
reuse
non
rat
specific
values?
Those
would
be
outside
of
that
particular
map.
I'm,
just
trying
to
understand
your
proposal,
follow-up
question
based
on
answer
the.
F
Answer
the
first
question,
I
believe
is
yes,
the
answer.
The
second
question
is:
if
you
wanted,
for
example,
to
use
the
expiration
time
element
which
comes
as
a
standard
zwt
registry
receive
WT
claim,
you
would
use
that
expiration
time
claim
outside,
so
the
CWT
claims
would
be
expiration
at
food
at
tomorrow.
I
You
have
to
carefully
write
the
correlation
rules
between
things
that
are
inside
and
things
that
are
outside
you
know
say
which
R
at
specific
P
skills
with
which
non
R
at
specific
piece
and
the
claims,
and
so,
if
they
were
in
the
same
one,
you
could
do
in
a
one
type
of
nested
structure.
If
they're
in
two
separate
places,
you
have
to
do
a
different
nesting
structure
and
I'm,
not
saying
it's
not
insurmountable,
it's
just
more
complicated
than
having
one
nesting
structure.
You.
I
We've
talked
about
cases
where
you
have
multiple
claim
sets
inside
the
same
CWT,
and
some
of
those
are
cases
where
they're
nested,
where
you
know
like
in
the
layered
attestation
example
that
Michael
showed
you
have
one
that
references.
The
second
one
that
references
the
third
one
inside
each
claim
said:
there's
both
potentially
standard
ones
and
R
at
specific
ones.
So
trying
to
just
show
the
nesting
relationship
between
the
first
set,
the
second
set
and
the
third
set
I'm
just
saying-
gets
tricky.
It's
absolutely
doable.
You
just
have
to
do
it
more
carefully.
Don't.
D
J
In
pepper,
I
just
created
a
simple
example
of
how
such
a
nested
CWT
could
look
like
and
I
just
copied
that
over
text
chat
and
basically
fundamentally,
there
is
no
difference
between
having
this
nested
namespace
and
putting
it
into
the
top-level
a
beauty
using
some
other
namespace
mechanism.
You
have
to
define
the
interactions
between
these
claims
in
all
cases,
so
I
don't
think
that
actually
nesting
the
thing
is
creating
additional
problems,
but
we
are
still
stuck
with
you
reading
a
problem
which
is,
we
have
to
define
all
the
interactions
between
claims
that
we
think
interacting.
D
K
Alright
I'm
going
to
be
talking
about
some
of
the
events
that
we've
been
talking
about
in
the
architecture
meetings
I
want
to
give
thanks
to
Dave
and
to
Lawrence
for
doing
some
help
in
describing
them
as
well
as
way
who
talked
about
some
of
the
architecture
diagrams
and
the
flow
diagrams
and
some
of
the
early
threads.
The
basic
concept
of
what
we're
trying
to
do
here
really
builds
off
of
off
of
the
use
cases.
K
We
have
use
cases
that
are
built
out
and
in
the
use
case
document,
but
we
need
ways
of
relating
the
use
cases
together.
What
makes
them
common
and
the
goal
is
to
define
event,
definitions
which
span
these
different
use
cases
and
if
we're
able
to
define
these
event
definitions,
the
hope
is
that,
by
including
the
definitions
in
the
architecture
document,
we
have
a
language
which
can
help
us
more
formally
frame
characteristics
between
the
use
cases
such
as.
K
When
do
you
send
a
nuts,
or
when
do
you
drive
and
create
results,
and
with
that
we
can
build
call
flows
or
timing
diagrams,
whatever
you
want
to
call
them
which
expose
the
similarities
that
we
all
know
exists
between
the
various
use
cases
that
are
in
the
use
case
document.
So
in
this
meeting
and
in
my
session,
what
I
got
to
do
is
two
things:
I'm
going
to
go
through
the
nine
event
types
which
a
number
of
us
have
seen
as
reusable
across
different
use
cases
and
as
I
review.
K
Beyond
that
there
is
the
possibility.
There
are
other
common
event,
definitions
which
we
have
not
exposed.
Yet
in
some
dialogues
in
some
other
drafts,
I've
seen
the
hints
that
there
might
be
some
other
timing,
events
which
could
be
common
across
the
architecture,
but
it'll
be
up
to
the
members
of
this
group
to
go
ahead
and
do
what
it
takes
to
assert
that
you
have
an
event
which
you
believe
is
common
enough
to
go
ahead
and
include
in
the
overall
set
in
the
architecture
document.
K
If
it
doesn't
make
the
architecture
document,
that's
fine,
because
you
can
always
define
them
in
your
specific
use,
case
documents
or
your
specific
technology
documents.
But
if
you
really
want
them
to
be
considered
as
reusable
events,
the
best
place
for
them,
of
course,
is
the
architecture
document.
So
two
asks
review
the
definitions
and
to
see
if
you
have
additional
asks.
I
did
just
send
out
an
email
that
is
a
pretty
much
summarizes
everything
I
just
said
and
provides
the
event
definitions
to
the
alias.
K
K
So
what
are
the
nine
event
types
which
are
contained
in
the
current
architecture
or
pull
requests
which
Dave
Taylor
has
posted?
You
can
see
a
number
of
different
things
from
the
value
generation
when
a
claim
was
created
to
when
you'd
sending
nonce
to
everything
to
when
you
generate
evidence
and
others
I
mean
we
could
review
these
one
by
one
on
the
call.
K
But
again
the
ultimate
arbiter
of
rightness
is
going
to
be
the
document
so
rather
than
read
any
of
these,
and
since
many
of
these
were
actually
on
the
alias
previously
in
earlier
threads,
perhaps
there
are
people
who
have
questions
now
on
any
of
these
nine
I'll
just
leave
it
out
there
to
see.
If
anybody
has
any
initial
questions
on
some
of
these
potential
claims-
and
they
see
one
from.
I
I
just
wanted
to
clarify
one
statement
that
you
made
there's
actually
10
in
the
pull
request.
The
10th
one
is
not
on
this
table,
obviously,
and
the
justification
for
the
10th
one
is
in
the
document,
for
the
caveat
is
that
the
10th
one
depending
on
the
protocol?
It
might
not
actually
be
in
a
claim,
and
so
it's
certainly
an
event
type.
That's
the
requests
aside.
I
The
attestation
results
are
relayed,
and
so
it
doesn't
list
that
in
the
ProQuest
as
being
in
a
claim,
because
it
could
be
passed
in
the
transfer
protocol
or
it
could
be
in
a
claim,
depending
on
how
you
define
the
protocol.
That
might
be
why
it
might
not
be
the
9
that
might
appear
in
the
eat
document,
for
example,
or
you
know
it
claims
it
would
be
usable
in
eat,
for
example,
but
it's
certainly
an
event
type
that
there's
a
security
check.
That
needs
to
be
done.
Let's
explain
that
for
request.
K
K
Make
sense
again
it'll
be
up
to
you
guys
to
determine
whether
the
definitions
are
right
and
I
expect
a
question
for
him
Hank
in
a
couple
slides.
But
these
are
not
all
the
possible
timings,
we're
really
just
trying
to
nail
down
the
commonly
used
timings
or
the
most
commonly
used
timings
all
right.
Next,
one
they're
going
to
see
in
this
slide
in
the
next
one,
as
well
as
what
Lawrence
is
going
to
do.
In
a
few
minutes.
K
So
this
is
an
example
flow
and,
of
course,
the
relying
party
then
will
only
have
to
have
the
values
acceptable
for
a
certain
amount
of
time.
This
is
the
way
the
information
is
supposed
to
be
used
and
I
do
expect
to
work
with
guy
and
have
text
that
shows
this
as
an
appendix
in
his
excellent
document.
In
order
to
to
show
again
a
way
to
allow
this
use
case
and
the
timings
between
them
to
be
correlated
between
different
different
dress,.
K
What
this
slide
does
is.
It
shows
something
I'm
going
to
talk
a
little
bit
later
in
the
session
when
I
get
to
to
my
individual
draft.
This
is
a
generation
of
composite
evidence
within
the
ax
tester.
In
this
flow
we
have
again
the
same
way.
We
started
the
last
flow,
the
generation
of
a
claim
within
a
TPM
and
the
extraction
of
the
set
of
claims
from
the
TPM
with
another
evidence
generation
in
evidence,
one
being
passed
up
to
a
verifier.
At
that
point,
we
go
ahead
and
send
attestation
results
back
down
to
the
attest
ur.
K
But
then
we
start
another
another
attestation
process.
Verifier
B
has
a
new
nonce
and
that
nonce
is
identified
with
NS
prime
and
that's
how
we're
thinking
we
should
identify
the
reuse
of
event
types
in
a
diagram.
You
pass
event
two
across
and
then
various
composite
elements
within
the
ax
tester.
Take
the
original
attestation
result
and
multiple
evidence
from
eg
and
eg
provide
to
send
the
result
over
to
the
verifier
and
the
verifier
B
that
looks
at
that
information
and
we'll
do
its
own
assessment
of
the
evidence
appraisal
of
the
evidence.
I
Here
I
was
just
comparing
this
diagram
to
the
one.
That's
currently
the
pull
request
and
I
had
the
observation
on
this
diagram
that
I
think
it's
a
couple
things
that
are
either
missing
from
this
or
perhaps
she
needs
something
other
than
the
non-space
background
check,
and
so
in
particular,
if
you
look
at
the
bottom,
half
you
see,
time
are
X's
on
the
bottom.
Back
in
the
table
are
X
was
defined
by
the
verifier,
and
so,
unless
you
have
synchronized
clocks
that
time,
rx
is
not
known
by
the
relying
party
in
any
comparable
way.
I
So
you
need
nonce
checks
over
there
between
the
ruling
party
in
the
verifier.
That's
not
shown
here,
I'll
go.
This
is
only
showing
the
danse
check
between
the
attest
during
the
I
party.
So
what
that
means
is
that
this
diagram
is
not
showing
how
the
relying
party
knows
that
the
attestation
results
are
no
longer
fresh.
You
need
more
than
what's
on
the
slide
in
order
to
determine
that.
K
Basically,
in
a
question
for
any
diagram
is
how
much
do
you
expose
in
the
diagram
and
how
much
you
expose
in
the
other
line
text
with
the
diagram
and
at
least
for
this
version
I
was
trying
to
simplify
the
event
times
rather
than
talk
about
the
deriving
and
the
carriage
of
some
of
those
times
with
another
element.
So
the
diagram
is
a
is
a
tool.
The
definitions
are
eventually
going
to
be
have
to
be
included
in
a
combination
of
the
diagrams,
so.
I
People
want
to
see
a
longer
example.
They
can
look
in
the
per
request,
which
does
have
a
non
spaced
background
check
that
has
more
than
what's
on.
Here
has
other
extra
stuff
on
the
bottom
right
side,
with
the
explanation
of
it,
and
so
if
people
want
to
see
that
feel
free
to
compare,
if
we
know
if
they're
finding
issues
in
the
poker
class,
let
me
know.
K
Absolutely
and
one
of
the
fun
things
that
this
does
is,
if
you
go
back
to
the
very
first
thread
that
we
put
together
on
this,
there
are
a
lot
of
discussions
on
how
many
knots
are
sent,
whether
they
sent
or
they
showed
or
not
shown.
The
tool
of
these
diagrams
is
quite
effective
in
exposing
things
which
people
take
for
granted.
For
example,
some
people
want
a
separate
verifier
to
send
a
separate
nuts
to
the
relying
party
in
order
to
gather
the
evidence.
Is
that
required?
K
D
H
This
is
because,
at
the
end,
as
always,
this
at
the
station
resides
no
longer
fresh,
so
we're
talking
about
freshness,
yeah,
apparently
because
nonsense
also
and
I-
think
that
is
an
efference
frame
here
for
talking
about
freshness
versus
recentness,
which
we
are
planning
to
add
to
the
architecture.
I
think
and
another
good
reason,
because
this
just
types
of
points
in
time
are
basically
relevant
for
the
freshness
recentness
discussion.
I
think
they've
can
relate.
I
Yeah,
the
section
nine
on
freshness
in
the
document
already
does
contain
a
brief
discussion
of
the
difference
between
recency
inference.
Although
I
don't
remember,
uses
those
terms
but
the
concept
it
completely
explains,
but
it
doesn't
go
through
the
examples.
And
so
that's
what
we're
talking
about
adding
is
the
examples
and
for
everybody
else
that
hasn't
looked
at
the
per
request,
necessarily
all
the
examples
and
stuff
or
be
in
an
appendix
that's
referred
to
from
the
the
freshness
section,
because
it
just
adds
in
learning
and
has
references
to
things
that
might
be
used
in.
K
A
K
One
that
came
from
to
DES
is
we
want
to
have
centralized
nuts
or
handle
distribution
across
multiple
devices,
or
it's
a
possibility,
so
the
less
I
have
for
you
is,
if
you
have
other
times
that
you
want
to
include
the
architecture
document.
Now
is
the
time
to
propose
them.
I
don't
have
a
need
for
these
times,
but
others
do
and
I
didn't
want
to
hide
the
potential
times
which
I've
heard
in
previous
discussions.
So
this
is
just
a
kind
of
like
a
a
mind
reminder
to
say
you
want
this
time.
E
G
So
this
first
time
time,
VG
value
generation,
I,
believe
that
was
time
a
in
the
whole
diagram,
so
that
there's
the
idea
that
a
data
item
might
be
generated
at
some
time.
Long
before
attestation
is,
you
know,
in
the
picture
long
before
announced
was
received,
maybe
even
outside
of
the
attestation
outside
of
the
attest
ur,
and
so
that
that
time,
that
data
might
be
long
precede.
The
attestation,
so
example
here
I'm
giving
here
is
a
GPS
position,
location
acquirement
that
happens
in
the
GPS
subsystem.
G
You
know
you
know,
maybe
the
GPS
subsystem
is
monitoring
position
and
then
you
go
into
a
basement
and
you
don't
get
GPS
anymore
and
the
and
the
GPS
subsystem
is
recording
the
times
at
which
it
you
know,
last
new
or
good
location.
That's
all
done
outside
of
attestation.
So
now
this
comes
into
a
into
the
tester
you're
generating
a
claim.
How
do
you
deal
with
that?
G
So
one
approach
could
be
that
every
possible
claim
that
we
can
define
can
have
a
timestamp
associated
with
it
I'm
saying
I,
don't
think
we
should
do
that
because
they
don't
think
most
claims
are
of
this
nature.
Many
claims
are,
but
not
most,
so.
The
puzzle
here
is
that
each
claim
that
has
the
possibility
of
being
cashed
or
generated.
G
I
So
the
question
here
that
I
don't
know
the
answer
to,
and
this
actually
harkens
back
to
that
discussion.
We
are
having
about
guidance
for
people
defining
new
claims,
because
we
probably
want
some
guidance
in
there
to
you,
and
the
question
is:
do
we
think
that
it
will
always
be
the
case,
as
some
of
you
defining
a
new
claim?
Well
know
whether
time
stamp
would
make
sense
for
it
or
not?
Is
that
it
because
it
seems
to
me
that
there's
an
assumption.
G
D
So
this
is
one
of
the
ways
to
think
about.
This
is
that
policies
can
decide
or
determine
what
the
requirements
are.
Whether
or
not
a
timing
or
timestamp
is
is
needed.
The
challenges
is
coordinating
that
the
policy
requirement
with
the
tester
who's,
doing
the
collection
to
know
that
they're
trying
to
meet
that
policy
and
I,
don't
think
that's
the
topic.
That's
been
discussed,
I.
G
Mean
you
have
to
have
data
structures
or
data
items
to
you
know
to
be
able
to
have
policy,
so
I
just
was
trying
to
think
about
the
data
items
first
and
then
sure
lots
of
policy
can
have
do
lots
of
stuff
with
different
things,
but,
as
you
can
see
from
the
CDD
out
there,
the
time
stamp
and
HR
optional.
So
also
you
could
reject.
If
you're
you
know
if
it's
missing,
but
just
the
question
is,
can
you.
D
Think
my
point
is:
is
that
there's
there's
potentially
two
entities
at
play
here?
One
is
the
policy
owner
who's
who's
setting
requirements
for
what
they
expect
and
then
there's
the
test
or
the
implementer
of
the
tester
who's
trying
to
satisfy
that
policy
and
unless
there's
some
mechanism
for
coordinating
those
requirements,
maybe
it's
captured
in
in
a
in
a
protocol
somewhere.
D
G
So
I
mean
I.
Think
Dave's
question
about
that.
Do
they
know
is
that
that's
probably
a
key
question.
I
went
through
the
claims
that
are
defined
in
eat
today
and
seem
like
most
of
them.
It
was
clear,
and
most
of
them
were
pretty
pretty
clear
that
you
would
pick
them
up
right
away.
There
wouldn't
be
any
caching
or
you
know
older
values
for
them.
So
that's
one
of
the
reasons
I
went
this
way.
G
I
think
would
be
good
for
everybody
to
think
about
this,
maybe
I'll
post
an
email
to
ask
for
know
if
they
would
know
the
the
other
claim
that
we
haven't
gotten
yet
is
anything
to
do
with
measurement.
Clearly
measurement
would
would
matter,
especially
with
something
like
runtime
integrity
check,
the
that
really
the
age
of
that
or
the
time
stuff.
That
really
matters
has
a
follow-up
question.
D
I
I'm
thinking
that
time
stamp
was
not
the
only
type
of
claim
about
a
claim
you
think
about
another
claim.
We
have
I
mean
you
had
discussions,
I,
don't
know
what
it's
called
I'm
sure
you
remember
that
the
notion
of
you
know
how
was
it
connected?
Is
it
you
know
on
chip
or
unbossed,
or
something
else
is
a
claim
about
a
claim
or
whatever,
and
so
what
the
ya
jabbar
checker
got
put
an
example
of
a
way
that
we
could
do
it.
I
If
we
do
it
generically
and
again,
I
haven't
decided
yet
whether
we
need
to
or
not
I
think
it's
Dominus,
extensible
and
I
suspect.
We
will
find
other
reasons
why
we
might
want
to
do
something
like
that
to
you
or
you
define
it,
a
a
claim.
That's
a
map
of
other
claims
that
contains
one
and
in
the
set
of
metadata
about
that
claim.
I
G
So
some
devices
have
clocks
and
some
devices
have
don't,
and
some
devices
have
clocks
and
their
clocks
are
unset
at
some
times
so
to
deal
with
that,
the
idea
is
to
have
two
different
ways
to
represent
here.
You
know
one
is
a
time
stamp.
That's
just
you
know,
standard
Seaboard
tag,
one
epic
time,
that's
preferred!
You
know
if
your
clock
is
set,
use
that
and
that's
that's
all,
that's
all
good.
G
G
E
G
G
G
I
I,
just
inserted
myself
into
the
queue
into
the
WebEx
and
the
timestamp
is
clear,
and
what
I'm
undecided
about
is
whether
an
aged
claim
that
by
itself
is
you
know
medically
if
you
will
earning
a
lifetime,
Stan's
claim
upon
another
claim,
whether
that
by
itself
is
the
right
way
to
express
things.
That's
certainly
one
possibility.
I
Another
possibility
is
where
you
only
have
say:
deltas
between
particular
events,
so
I'm
just
going
to
make
something
up,
because
I
can't
pick
something
on
the
slide
here
at
this
relevant.
So
let's
just
pretend
that
the
time
EG
minus
VG
was
interesting
on
the
left
here
in
the
tester.
I
think
it
was
in
some
in
whatever
diagrams,
but
none
other
one.
That's
on
the
screen,
and
so
let's
say
the
evidence
needed
to
include.
Maybe
it
isn't
this
one.
I
If,
if
the
evidence
needed
to
include
a
time,
you
need
to
include
information
I'll,
let
the
relying
party
determine
time
eg
time,
VG
right,
one
way
to
encode.
That
would
be
to
have
two
different
claims,
one
that
is
age
VG
and
one
that
is
age
of
eg
and
have
the
relying
party
do
this
attraction.
Another
way
to
do
it
is
to
have
one
claim:
that's
just
the
Delta
that
the
attest
er
puts
in
between
those
two
approaches.
The
second
one
is
obviously
more
compact,
because
there's
only
one
claim
instead
of
two.
G
So
on
this
this
year
on
the
nonce,
the
the
you
know
in
Eric's,
tired
timing,
diagram,
the
the
time
of
the
nonce
is
noted,
but
I
don't
think,
there's
any
reason
to
put
it
in
the
attestation
evidence
or
the
attestation
result.
So
there's
no
field
for
recording
that
time
of
the
knots
and
I
think
some
some
other
a
couple
other
times
are
of
that
character.
G
D
F
G
G
This
is
the
time
all
the
claims
are
formatted
and
the
signature
is
applied.
I
didn't
see
any
reason
to
be
more
fine-grained
than
that
like
say
well,
this
is
the
time
we
collected
this
claim
innocent
I'm.
We
signed
it
and
this
the
time
we
sent
it.
It
just
seemed
like
it's
all
kind
of
happens
pretty
quickly
and
there
wouldn't
be
any
reason
to
be
more
fine-grained
than
that.
So
it's
there's
just
the
one
time
issue
that
just
just
like
a
CWT
and
AJ
did.
He
have.
This
time
is
always
announced
a
time.
G
It's
never
an
age.
And
basically,
if
the
clock
has
no,
if
the
device
is
no
clock
or
the
clock
isn't
set,
then
you
just
leave
this
claim
off
and
the
bear
verifier
has
to
go
by
the
you
know
straight:
it's
either.
You
know
after
NS
and
the
for
ER,
okay.
So
now
I
hain't
go
for
your
question
and
and
dave.
Maybe
then
answer
some
comments
for
from
what
you
were
saying.
H
With
respect
to
true
de
the
line
based
stuff,
so
it's
not
using
the
non
non
skin'
veins
method
or
one
of
them
ties
relative
time,
always
cryptographically
to
absolute
time.
That
is
trusted
to
mitigating
that
sabot.
So
in
mathura,
for
example,
is
aged
semantics
is
not
captured
in
evidence,
but
in
a
separate
protocol,
specific
channel,
which
is
the
synchronization
message
which
guarantee
is
a
trusted
closeness
of
the
relative
to
absolute
time
association,
and
that
is
therefore
not
a
claim
per
se.
H
But
a
protocol
header
item,
but
you
could
say
always
depends
on
all
you
work
this
so
defining
the
claim
inside.
So
if
I
think
this
is
useful,
h
little
bits,
that's
nice,
but
it's
a
little
bit
generic!
So
have
you
really
always
have
to
read
the
text?
It's
not
so
intuitive
like
issue
that
no,
so
maybe
there's
a
better
name
for
that.
But
that's
the
tiny
nets.
I
think
in
general
is
a
good
way
to
approach
this,
not
necessarily
in.
H
So
we
have
two
clocks,
the
relative
clock
and
the,
and
then
we
have
a
external
source
that
you
can
reference.
You
can
get
a
totem
from.
There
is
a
handshake
and
then
have
a
trusted
reference
for
time.
So
and
this
unfortunate
clocks
are
not
very
accurate,
of
course
berries,
so
they
have
a
jitter
and
they
are
drifting
and
therefore
you
have
to
resync
and
set
new
points
of
time
by
you
start
this
trust
relationship
of
synchronization.
Again,
actually
it's
three
clocks
with
you
talked
about
the
external
clock.
Also.
G
H
G
H
To
tell
you
you
create
evidence,
but
it
only
includes
text.
You
have
to
couple
it
to
a
trusted,
you
third
time
in
order
to
make
the
relative
use
food
in
a
global
scale
and
I
thought
you
were
talking
about
take
somewhere
and
said
that
age
is
ticks
and
therefore
relative.
So
that
way,
I
was
picking
up
on
that
yeah.
L
H
I
Further
comment:
I
haven't
changed
what
my
original
question
was.
So
I
am
still
wondering
right
now,
I'd
be
inclined
to
say
sure,
go
ahead
and
define
an
age
lame
in
a
but
I,
don't
know
if
there's
a
strict
need
for
it,
but
I
don't
have
any
objection
to
adding
it.
As
I
mentioned
before
that
on
the
last
point
about,
should
you
have
the
ability
to
group
metadata
about
claims?
I
said
times
that
was
just
the
first
one
of
a
set,
and
it
could
be
that
age
is
another
one.
I
G
E
D
G
G
G
You
could
read
to
find
the
claim
to
be
an
array
of
things,
but
to
achieve
that,
if
you
wanted
to
so
seems
like
there's
two
options
that
I
could
think
of.
One
is
that
you,
you
start,
including
the
full
attestation
evidence
as
a
sub
part
of
the
attestation
result,
so
that
would
be
an
interesting
change
to
eat,
to
allow
that
it
generally
hasn't
been
too
much.
Work
has
been
done
on
eat
for
it
to
carry
adverse
Asian
results.
G
Another
would
be
to
define
a
results
issued
at
claim
so
that
they
can
coexist.
Maybe
there's
others,
but
this
I
think
this
opens
an
interesting
question
about
formats
of
attestation.
Results,
I
didn't
have
anything
other
than
these
two
proposals.
They
don't
have
a
you
know
answer
yet.
I
might
lean
towards
a
you're
putting
all
of
attestation
evidence
in
the
attestation
result,
because
there
are
fires
and
relying
parties,
especially
with
big
data
and
machine
learning,
on
that
they
they
live
off
of
data,
the
more
data
better,
so
comments
or
questions
on
that.
J
I
This
is
Dave
I,
certainly
wouldn't
want
a
to
be
mandatory
for,
say
teep,
for
example,
so
I
don't
think
that
that's
necessarily
I
think
that
would
be
something
that
would
be
up
to
a
particular
profile
or
a
use
case.
Your
protocol
to
define,
but
I,
certainly
don't
think
it
should
be
mandatory
for
all
of
them.
In
other
words,
especially
if
you
have
say
a
relying
party
who's,
a
constrained
device,
shipping
them
a
whole
bunch
of
evidence
that
they
don't
want,
doesn't
actually
help
the
constrain
device.
I
So
that's
why
I
would
argue
against
a
for
being
a
inherent
part,
although
I
have
no
problem
with
a
in
a
particular
profile.
For
example,
if
somebody
wants
to
do
that,
the
other
question
I
was
going
to
ask
is-
and
you
said
that
you
thought
that
the
relying
party
might
want
to
know
time.
Eg
and
I
am
Not.
I
The
values
appear
in
the
attestation
results,
and
certainly
there
should
be
many
cases
use
cases
for
which
the
attestation
result
is
leaving
me,
and
you
know
the
verifier
vouches
that
the
evidence
looked
good.
The
end,
you
just
trust
the
verifier,
if
you're
a
tiny
constrained
device
that
may
be
exactly
what
you
want.
Don't
have
the
code
size
to
do
any
other
checks,
then,
does
it
come
with
a
verifier
that
I
trust
right
and
so
keeping
that
to
be
small
is
great.
I
K
Initially,
the
slides
I
put
together
were
for
the
interim.
That's
why
it
shows
Rhett's
interim,
but
it's
actually
the
virtual
rather
the
interim.
This
is
talking
about
a
use
case,
which
is
a
new
one
that
was
introduced
at
the
interim,
and
the
use
case
is
one
that
depends
on
things
like
draft
fedora
and
has
implications
to
other
drafts
like
the
drafts
pub/sub.
So
I
thought
it
would
be
good
to
give
a
high-level
overview
of
the
draft,
as
well
as
the
current
questions
that
are
open.
I.
K
K
Now
there
is
a
use
case:
that's
interesting
for
finance
military
government,
medical
types
of
the
users,
where
you
want
to
make
sure
that
traffic
in
a
network
flows
only
on
devices
that
are
recently
attested
and
their
attestation
results
come
back
as
that
they
are
trusted.
The
goal
here
is
to
have
sensitive
flows
bypass
devices
which
are
not
currently
verified
to
be
secured.
K
K
There
are
to
do
this.
We
could
get
at
the
station
through
the
background
check
model
much
as
draft
Fodor
ku
talks
about
by
having
the
attestation
information
passed
up
to
the
verifier
in
something
I'm
calling
an
attestation
event
stream,
which
I'll
chat
about
more
in
a
second
and
with
the
information
being
streamed
from
each
of
the
devices.
You
can
go
ahead
and
push
a
to
get
to
the
target
resource
at
the
either
end
of
the
network.
To
make
sure
you
choose
a
trustworthy
path.
Next
slide.
K
The
other
option
is
one
that
is
about
composite
evidence.
In
this
case,
you
get
your
information
from
the
attestation
event
stream
up
to
the
verify
there
and
at
the
attestation
in
processing
the
attestation
event
stream.
You
then
send
attestation
results
back
down
to
the
router
when
the
link
comes
up
or
periodically
with
protocols
like
no.2,
an
X
or
mexic,
you
can
go
ahead
and
do
a
new
quote
from
your
from
your
tester
include
that
information
that
returned
from
the
verifier
and
at
each
peer
device
decide
if
your
peer
device
is
currently
trustworthy.
K
K
There
are
three
major
elements
that
are
interesting
here:
the
first
one
is
an
attestation
event
stream,
which
builds
on
the
yang
model.
That's
already
been
adapted
by
the
workgroup,
as
well
as
some
subscription
work
over
in
the
networking
group,
and
we
take
notifications
that
include
evidence
and
pass
them
up
to
the
verifier,
and
this
is
a
link
to
the
yang
models
that
allow
pretty
much
real-time
information
be
pushed
up
to
an
a
tester
and
processed.
So
that's
the
first
main
element
of
the
draft
next
slide.
K
Second
main
element
of
the
draft
is
something
that
we
haven't
talked
much
about
yet
in
the
in
the
group,
but
I
think
it's
going
to
become
a
big
thing
over
time,
and
that
is
identification
of
levels
of
trustworthiness
or
even
levels
of
results
that
are
passed
down
to
a
device.
For
example,
do
we
need
things
that
are
claims
and
identify
whether
the
device
is
compromised,
its
unverified?
If
it's
a
boot
verified
at
some
point?
K
K
In
the
last
slide,
this
really
just
goes
back
to
the
timing
diagrams.
That
I
showed
in
my
last
presentation
to
show
that,
as
part
of
the
timing
of
the
flows,
we're
going
to
be
passing
composite
evidence
at
various
times
between
various
devices
and
again,
this
is
just
showing
the
importance
of
composite
evidence
and
the
ability
to
take
multiple
things
at
the
tester
and
be
able
to
send
them
to
a
relying
party
and
verifier
to
go
ahead
and
process
things.
We
don't
assume
necessarily
that
the
verifier
is
the
source
of
all
information.
K
I
K
One
thing
that
is
worth
highlighting:
we
have
two.
If
you
look
at
the
composite
evidence,
you're
gonna
see
that
there
is
a
signature
that
is
included
in
one
bit
of
evidence
to
another.
One
thing
that
you
have
to
consider
is
the
timing
of
these.
Things
have
to
be
bound
together,
so
you
do
have
some
binding
between
these
claims
and
including
information,
for
example,
the
it
step
one,
the
signature
of
the
information
from
the
ax
tester
in
the
results
that
are
sent
back
in
step
two.
K
K
Review
especially
start
thinking
about
where
different
levels
of
trustworthiness
are
being
encoded,
as
well
as
the
importance
of
composite
evidence
and
the
fact
that
some
people
have
talked
about
passports
or
passport
models.
At
this
point,
this
is
a
combination
of
a
passport
model
and
the
background
check
model,
but
I
was
initially
using
the
word
passport
for
what
is
being
sent
across
I.
Do
think
that
the
word
passport
has
to
be
used
very
very
carefully,
as
I.
Certainly
I'm
not
willing
to
have
the
word
passport
be
used
only
for
unmodified
information
going
between
devices.
A
G
Thank
you,
sorry
yeah,
if
you're,
calling
something
it
passport
it
should
be
signed,
it
should
be,
is
stick
to
it
at
the
analogy
of
a
rail
passport,
which
means
it's
it's
something
that's
been
probably
been
signed
by
somebody
like
a
verifier
and
that
the
the
holder
of
the
passport
doesn't
modify
it
so
I
think
you're.
Moving
away
from
the
the
term
passport
words
composite
evidence
is
probably
it
seems
in
line
with
that
for.
K
G
K
K
Why
I'm
telling
me
here
is
that
we
have
to
there's
actually
the
word
passport
is
not
used
in
the
architecture
document.
Only
the
passport
model-
that's
why
I
brought
it
up
is
that
we
just
don't
want
to
use
the
word
passport
unless
the
definition
allows
both
stamped
and
on
stamp
things.
Okay,
thanks!
K
D
K
That's
why
I
brought
it
up
this
composite
evidence
we
had
in
early
discussions.
I
would
love
to
identify,
but
actually,
if
you
put
the
word
passport
in
I,
think
it
has
to
be
identified
right
now.
The
architecture
document
doesn't
include.
The
word.
Passport
includes
a
passport
model,
so
I
think
it
should
be
included
and
my
only
requirement.
M
M
First
thing
is
a
quick
Rick
Rick
over
the
drafter.
What
we
want
to
do,
we
want
to
use
them
that
come
have
some
mechanism.
In
brief,
it's
it
can
be
is
shown
in
the
picture
that,
as
a
tester
receives
us,
the
verifies
a
subscriber
to
the
to
an
you
might
and
that
tester
is
where
records
happened.
Events
and
them
publishes
a
you
meant
record
with
a
verifier.
So
it's
different
from
the
traditional
challenge/response
interaction
model.
M
Is
it's
different
and
it's
suitable
for
the
use
cases
where
you
want
to
use
unchanged,
remote
attestation,
and
they,
when
you,
when
you
use
it
in
our
lab,
Jill
or
work.
It
may
well
be
more
flexible
and
Eric's
draft
also
described
to
use
this
mechanism
so
I
think
it's
also
a
suitable
use
case
for
routers,
and
the
benefits
are
obviously
inherited
from
the
young
pops
up
and
jam
push
mechanism
and
like
flexibility,
efficiency,
etc.
M
Based
on
this
scope,
we
will
define
further
define
detailed
models,
including
the
human
streams
and
subscription,
like
all
this
kind
of
stuff,
and
we
have
planned
some.
We
have
planned
a
detailed
llamado
and
we
are
preparing
preparing
our
new
update
soon
and
in
the
new
draft
version
we
will
detail,
describe
the.
How
do
you
solve
the
freshness
problem?
Mostly,
we
you.
I
This
is
Dave
I'm
gonna
ask
the
same
question
that
we
talked
about
last
ye.
F
I
didn't
see
the
answer
in
the
document
yet,
and
so
this
is
a
reminder
to
cover
stuff
in
the
document
which
is
in
your
sequencing
diagram.
The
first
line
was
that
the
verifier
doesn't
subscribe
at
the
attest
ER,
and
the
original
question
was:
how
does
the
verifier
know
when
to
subscribe
right?
The
attest
romão
may
not
be
up
at
the
time
it
may
be
the
middle
be
rebooting.
So
how
does
it
decide
when
and
who
to
subscribe
to
and
I?
K
One
follow-up
to
that
to
consider
one
of
the
things
about
the
yang
subscription
drafts
is
that
they
depend
on
transport
if
your
router
reboots
or
something
goes
away
and
comes
back,
the
subscription
is
recreated.
So
the
underlying
transport
will
solve
part
of
the
problem
that
you're
describing
Dave
and
then
that
could
be
including
the
document
as
well.
So
look
at
the
transport
dress
and
some
of
the
replay
mechanisms
they
do
have
tools
for
solving
this
yeah.
I
Eric
and
if
I
remember
right,
that
particular
transport,
so
it
looks
that
we
had
this
discussion
at
the
hackathon
at
the
last
physical
IETF
or
at
least
Frank
and
I
and
I'd.
Remember
who
else
was
part
of
that
discussion,
but
I,
don't
think
it's
in
the
document
since
when
you
win
the
attach
to
reboots,
if
it
has
a
cache
subscription,
then
it
proactively
reaches
out
to
the
verifier
as
opposed
to
verify
reaching
out
via
tester,
and
that's
not
shown
the
sequence
diagram.
But
that's
what
my
recollection
is
from
memory.
I
I
If
the
tester
doesn't
proactively
reach
out
to
the
verifier
and
a
reboot
right,
which
is
what
I
think
Eric
you
are
saying,
does
happen
in
the
transport
right.
If
it
didn't
do
that,
then
it
couldn't
talk
to
a
relying
party
that
relied
on
say
a
new
attestation
result
until
after
it
waited
around
for
the
for
the
verifier
to
reach
out
to
the
ax
tester.
Absolutely.
A
A
Okay,
thank
you
all
right
with
that.
I
think
we've
completed
the
agenda,
any
other
comments
or
questions
we
we
are.
So
let
me
just
do
a
reminder
for
those
I
do
see
most
everybody
signed
up
on
the
blue
sheets
or
Tom.
Thank
you
for
for
adding
them.
It
would
be
good
for
common
use
or
foreign
colonies,
or
eight
to
identify
themselves
on
the
blue
sheet
would
be
great
I.
G
C
C
Know
so
so
I
think
the
outliers
are
the
calling
users.
So
if
you,
if
you
participated
in
the
in
the
working
group
meeting
by
just
calling
a
phone
bridge
or
a
sip
bridge
and
did
not
use
the
WebEx
kind
of
client,
if
you
speak
now,
we
can
make
sure
that
you're
in
the
blue
sheet,
because
everyone
we
know
because
they're
listed
in
the
in
the
participant
list,
my
name
so.