►
From YouTube: RATS Architecture Design Team, 2020-10-23
Description
RATS Architecture Design Team, 2020-10-23
A
B
Hi,
so
we
have
had
another
eight
or
nine
meetings
since
itf
108,
and
I
guess
we
spent
a
reasonable
amount
of
time
quibbling
over
words
and
exactly
what
do
they
mean.
B
So
some
of
the
changes
may
seem
very
trivial,
but
there
may
be
actually
more
than
an
hour
behind
some
things
going
back
and
forth.
We
have
two
issues
that
are
still
kind
of
open,
one
that
we've
said
we
won't
fix.
We
think
that
it
belongs
in
a
new
document
and
we've
encouraged
another
document
to
be
created
for
this
104
pull
requests
closed
and
we
had
a
couple
of
other
new
people
drop
into
some
of
the
calls,
but
most
of
the
calls
have
been
a
fairly
core
group
of
eight
or
nine
people.
B
Next
slide.
We
think
we're
done
posted
the
document
07
last
friday.
After
our
call,
we
don't
have
any
more
calls
scheduled
at
this
point
because
we
think
we're
really
done
so.
The
major
changes
in
07
is
we've
added.
This
section
called
reference
values
and.
B
And
this
is
the
sort
of
major
changes
we
had.
Two
new
definitions
make
it
bigger
on
your
screen.
If
you
can,
I
guess,
and-
and
we
changed
this
core
diagram-
this
kind
of
the
first
conceptual
the
first
diagram
in
the
whole
bloody
document-
we've
added
this
reference
values
provider
to
kind
of
really
make
it
clear.
What's
happening
just
to
some
some
comment
about
the
the
diagram
there's
in
the
the
things
with
boss.
The
boxes
with
stars
are
not
normatively
standardized
in
this
document
that
we
assume
they
exist
in
some
fashion.
B
But
we
don't
assume
that
this
working
group
at
this
time
will
necessarily
standardize
those
in
those
interactions,
the
boxes
with
the
dashes,
the
solid
lines
around
them
and
there's
arrows
that
connecting
them.
Those
are
the
pieces
that
we
think
that
this
architecture
normatively
standardizes,
and
that
this
working
group
is
attempting
to
standardize.
So
the
the
arc
marked
evidence
and
the
arc
mark
as
testation
results
are
the
parts
that
we
think
are
the
major
major
outputs
of
this
working
group.
B
At
this
time
there
and
the
other
parts
could
be
subject
to
standardization
at
a
future
time
or
in
a
particular
venue
or
other
things
like
this.
We're
not
saying
they're,
not
important.
What
we're
saying
is
that
they're
just
they
don't?
B
We
don't
think
that
we
can
get
consensus
on
that
kind
of
stuff
next
slide,
please
so
a
whole
bunch
of
new
text
about
the
verifier
about
how
does
it
acquire
all
of
the
things
that
it
needs
to
do
to
verify
things
about
things
like
whether
the
device
is
physically
in
possession
of
people
or
not
or
is
specifically
not
in
possession
and
there's
interesting
cases
where
physical
possession
adds
to
its
trustworthiness
in
cases
where
it
removes
from
its
trustworthiness?
B
And
that's
about
kind
of
this,
the
the
the
circle
of
trust,
which
is
in
some
sense
those
are
those
non-standardized
arrows
where
the
manufacturer
has
to
put
something
into
the
attester
and
then
provide
the
verifier
with
a
thing
that
it
allows
to
verify
that
it's
the
thing
that
it
put
in
so
typically,
these
are
provisioned
key
symmetric,
asymmetric
keys.
B
Although
the
case
has
been
made
that
in
some
cases
in
some
scenarios,
they
may
be
symmetric
keys
with
particular
constraints
put
on
them
and
that's
partly
the
place
where
we
said
well,
you
know
what
we
just
we
don't
want
to.
We
don't
want
to
say
one
or
the
other
that
a
specific
environment
is
going
to
make
this
the
case
next
slide.
Please.
B
We
had
some
edits
about
the
freshness.
This
link
in
the
slides
will
take
you
to
the
full
diff
and
I'm
not
gonna,
really
gonna
go
through
that.
There's
there's
a
lot
of
small
little
changes
that
I
would
encourage
you
to
review,
and
essentially
we
think
that
this
document
is
ready
for
working
group.
Last
call
last
slide.
C
I
just
want
to
summarize
the
main
addition
here
since
the
last
interim
meeting
was
the
addition
of
using
handles
for
freshness,
rather
than
because
before
we
had
two
possibilities
that
we
walked
through,
one
was
using
time
stamps
which
require
synchronized
clocks
and
one
that
uses
nonces,
which
of
course,
has
an
extra.
You
know
round
trip
to
send
the
nods.
C
You
know
with
the
challenge,
and
then
you
know
include
that
in
the
evidence,
but
you
got
to
have
an
extra
round
trip
to
go
and
fetch
the
nons
to
put
including
your
evidence
and
then
the
addition.
This
time
it
was
adding
the
handle
stuff
that
pink
had
originally
proposed
in
a
different
draft,
and
we
incorporated
that
into
the
into
the
main
set
of
possibilities
here.
So
now,
there's
three
different
possibilities
to
walk
through,
which
are
for
different
use.
C
Cases
like
you
actually
have
a
source
of
time
and
so
on,
and
so
we
talk
about
that.
So
that's
the
the
main
change
on
this
one
is
just
adding
a
third
set
of
example.
Type
and
hank
did
summarize
that
to
the
to
the
list
in
between
last
intervening
in
the
situation.
B
Yeah
and
actually
some
of
that
was
actually
done
in
0.506,
but
but
thank
you
for.
B
Way
we
actually
have
added
the
handles
and
thank
you
for
catching
that
that
that
point,
so
you
may
want
to
look
at
05
to
07.
If
you
haven't
read
the
document
for
a
while.
A
D
E
So
this
is
this
is
to
talk
about
how
the
verification
key
is
identified.
So
when
a
verifier,
you
know
receives
attestation,
evidence
like
an
eat
token
need
to
verify
the
signature
on
it.
E
So,
in
order
to
verify
the
signature,
they
need
to
know
what
key
to
use
symmetric
or
asymmetric,
so
there's
got
to
be
some
way
that
they
figure
out
which
key
it
is.
You
can
so
so.
This
is
the
main
point
here.
Is
you
know
what
goes
into
eat
that
identifies
the
key,
so
this
is
kind
of
a
follow-on
to
what
I
discussed.
I
think
in
the
last
time
I
presented,
which
I
think
was
was
the
last
ietf
and
you
know
about
how
the
how
the
keys
work
for
for
verification.
E
The
other
thing
that's
important
here
is
you
know
I
I'm
looking
ahead
here.
The
idea
that
someday
there
should
be
interoperation
between
different
vendors
of
different
attesters
and
different
vendors
of
different
verifiers
kind
of
like
there
is
interoperation
with
tls.
You
know
in
web
browsers,
I
mean
there's
lots
of
different
vendors,
a
lot
lots
of
different
cas
lots
of
different
websites
and
lots
of
different
web
browser.
Vendors
and
they
all
interoperate,
I'm
hoping
that
we
have
some
sort
of
interoperation
like
that
for
at
a
station.
E
That
seems
like
a
long
ways
to
go,
but
that's
kind
of
what
I'm
thinking
about
here.
E
E
Slide
so
this
was
the
slide
from
last
time
I
presented,
you
know
showing
that
you
can
have
public
keys
or
symmetric
keys
for
or
verification
service,
and
you
might
have
the
transfer
of
the
the
key
from
the
manufacturer
to
the
verifier
might
be
infrequent
or
it
might
happen
on
every
verification.
E
So
I
won't
go
over
this
in
any
detail
today.
So
let's
go
to
the
next
slide.
E
Okay,
so
this
was,
this
is
a
a
taxonomy.
I
came
up
with
of
how
the
verifier
finds
out
about
what
key
to
use.
So
I
got
four
different
ways
that
a
verifier
can
find
out
what
key
they're
using
so
I'm
gonna,
I'm
gonna
go
over
these
in
some
detail,
and
I
I
wanna
have
some
discussion
on
some
on
these.
E
I'm
getting
to
get
some
feedback
and
the
the
proposal
is
to
add
text
describing
this
or
maybe
maybe
this
table
or
something
like
this
to
the
e
document,
so
I'm
gonna
so
to
start
with
the
key
id.
So
the
first
thing
you
can
do
is
just
have
a
key
id
and
the
example
here
is
the
cose
key
id
header
parameter
and
in
fact
the
proposal
would
be
just
to
reuse
the
cose
key
id
header
parameter.
E
So
the
in
this
case,
all
you're
doing
is
identifying
key
with
a
a
byte
string
with
no
internal
structure,
and
you
know
that
works
for
symmetric
keys
or
asymmetric
keys
or
or
all
kinds
of
different
algorithms
or
whatever.
So
this
is
basically
just
this
option.
E
E
E
So
the
the
I
think
there's
a
lot
of
overlap
with
the
the
cose
x
509
draft,
when
the
key
is
an
x
509
certificate,
because
it's
a
public
key.
So
that's
one
reason:
I've
been.
I
got
much
more
involved
in
detail
in
cosex
509
in
the
last
couple
of
weeks.
E
So
the
main
proposal
there
would
be
to
reuse
cosex
509,
but
if
it's
once
the
the
one
step
further,
if
it's
not
a
a
a
x
509
certificate,
then
we
have
to
to
have
a
different
kind
of
uri
for
something
that's
a
little
different.
E
E
So
this
is
actually
what
arm
psa
is
using.
They
base
it
off
of
the
device
id
or
uid.
So
you
just
look
inside
the
the
the
payload
parts,
the
payload
you
get
the
ueid
out,
and
then
you
use
that
as
a
key
id.
E
E
And
you
know
it
kind
of
parallels
to
the
the
key
idea
in
a
lot
of
ways.
E
It
also
makes
the
software
stack
messy,
because
now
you've
got
a
you
know:
decode
the
payload
before
signature
verification,
and
then
you
got
to
decode
the
you
got
to
decode
the
cose
without
verifying
the
signature,
because
you
don't
have
the
key
to
cook
the
payload
the
eat
payload,
then
you
end
up
with
the
key
id
and
then
you
have
to
go
back
and
redo
all
that
so
and
some
of
the
software
stacks
are
a
little
bit.
E
You
know
you
have
to
have
a
way
to
decode,
coset
and
heat
without
signature
verification
to
to
make
that
work,
then
the
final.
The
fourth
option
is
to
put
the
verification
key
in
the
attestation
evidence
evidence
inside
the
heat
token.
So
this
is
basically
attaching
a
nx
509
certificate
to
your
to
eat.
You
can
do
this
with
cos.
Ax
509,
then,
since
it's
a
you,
you
will
have
to
do
the
the
chain
formation
or
and
the
chain
verification
up
to
a
trusted
route
that
the.
E
But
that's
kind
of
a
known
way
of
doing
this.
I
mean
that's,
you
know,
cms
works
this
way.
You
know
our
s.
Mine
works
this
way,
typically
and
all
that
so
that's
kind
of
well
understood.
So
in
that
case,
there's
no
key
id
there's
a
key
and
fido
android,
datastation
and-
and
I
believe,
tpm
all
work
this
way
so,
but
this
is
the
worst
in
terms
of
the
number
of
bytes
on
the
wire
because
you're
putting
a
whole
x59
servicer
inside
the
attestation,
which
might
be
bigger
than
the
outer
station.
C
This
is
dave
thayer
first
well,
I
have
a
comment
and
a
clarifying
question.
So
let
me
ask
my
clarifying
question.
First,
you
talked
about
the
the
potential
disadvantage
of
the
third
row
having
to
decode
before
verification
clarifying
question.
I
just
want
to
verify
that
that
does
not
apply
to
the
fourth
row
or
does
it.
E
C
C
All
right,
gotcha,
all
right
now.
I
can
make
my
comment
between
these
my
right
now
I
don't
have
a
strong
preference,
but
my
preference
would
be
to
support
both
the
second
and
the
fourth
row,
meaning
for
different
use
cases,
because,
especially
if
they're,
both
using
the
same
normative
reference
to
allow
both
of
those.
But
let
me
explain
why
I
think
it
is
important
to
allow
for
the
case
where
the
trust
anchor
configured
in
the
verifier,
like
the
public
key
configuring.
C
The
verifier
that
has
to
chain
up
to
is
not
only
one
step
above
the
a
tester's
signing
key.
In
other
words,
there's
not
just
one
layer
that
there
may
be
a
certificate
chain
that
there
may
be.
You
know
two
layers
or
something
where
the
trust
anchor
assigns
the
key
that
then
signs
the
tester
sign-in
key,
and
so,
whenever
we
say
verification
key,
I
think
we
should
be
allowing
that
to
be
a
certificate
chain.
C
I
think
that
the
first
and
the
third
one
have
a
harder
problem
harder
time
dealing
with
certificate
chains
with
the
second
and
fourth
row,
the
uri
and
the
when
it
says,
typically
an
x509
certificate
or
equivalent.
My
belief
is
that
can
be
a
chain,
and
so
I
don't
think
there's
a
lot
of
work
necessary,
just
referencing
the
normative
reference
and
making
sure
it's
usable.
So.
E
Yep
yep
totally
great
so,
but
but
in
a
way,
dave
you're
skipping
ahead
that
that's
fine,
but
the
the
the
thought
here
is
not
to
standardize
this.
It's
just
to
say:
here's
some
ways
you
can
do
it
and
I
believe
that.
C
Doesn't
the
oh
never
mind
because
the
the
first
one
you're
saying
there's
already
a
cos
a
field
for
yeah?
Second,
one,
there's
already
a
reference
for
that.
We
can
just
reference
the
fourth
same
thing.
The
third
one
would
require
additional
claims
that
might
be
standardizable
and
that's
the
one
I
don't
see
a
case
for
yet.
E
Yeah
that
my
my
experience
with
eat
is
everybody
really
likes
the
third
one,
and
I
have
to
talk.
F
E
Out
of
it,
and
I
haven't
succeeded,
I
don't
think
I've
succeeded
once
yet,
because
the
logic
is,
you
got
a
ue
idea.
Why
shouldn't
we
just
use
that
so
anyway,
that's
I
mean
I
and-
and
I
wanted
to
have
a
reasonably
complete
taxonomy
as
well
with.
B
C
Instance
of
that
model
has
a
different
key,
and
so
this
is
the
way
that
I
look
at
this
is
this
was
this
is
what
you're
using
to
say
take
evidence
and
I've
got
a
set
of
trust
anchors
configured
and,
if
there's
more
than
one,
how
do
I
know
the
right
one
and
how
to
map
the
evidence
to
that
trust,
trust
anchor,
so
the
uri
might
be
there's
additional
stuff.
I
have
to
go
and
fetch
in
order
to
provide
that
connection.
E
Yeah
I
mean
there
could
be
a
a
giant
mapping
table.
You
know
these
ue
ideas
map
to
that
that
one
or
the
and
those
uids
map
to
the
other
one.
The
other
thing,
that's
that's
possible,
with
the
with
tid
and
based
on
claims,
is
kdfs
of
symmetric
keys,
so
the
ueid
goes
into
a
kdf
against
a
master
key
to
produce
the
the
verification
key.
E
So
we
and
we
have
to
we-
have
to
accommodate
that
that
kdf
scenario,
so
so
so
to
get
to
my
my
goal
of
inter
operation
in
that
that
loop,
you
know,
then
we
we
do
have
to
pick
some
of
these
things
and
say
yeah.
This
is
the
way
it
should
be
done
and
but
that
will
be
you
know,
I
think,
eat
and
like
kose
like
and
like
cwt
they've,
provided
a
a
large
palette
of
options
and
they're,
not
really
trying
to
lock
down
to
a
specific
end
and
interoperating
system.
G
So
so
this
is
hank.
First
of
all,
thank
you
for
the
summary
here,
I'm
a
little
bit
torn
by
the
notion
that
this
is
informational,
because
it's
very
useful
and
we
have
for
interoperability,
probably
to
I
don't
know,
find
a
common
denominator
and
then
the
yeah,
the
the
open
frenzy,
that
is,
this
is
not
locked
down.
So
so
how
do
you
want
to
proceed
with?
This
would
be
my
first
question.
Let
me
add
some
note
here
I
was
q.
G
C
C
You
have
a
pure
data
uri
or
something
like
that.
You
could
do
it
in
the
uri,
but
the
second
row
is
specifically
around
the
url
when
it's
referencing
the
cozy
x519,
it's
similar
since
I
know
hank,
you
know
suit
right.
It's
similar
to
a
several
part
of
the
manifest
where
you
can
point
to
where
you
can
get
it
right.
G
F
G
Okay,
yeah.
G
Okay,
okay,
okay,
yeah,
okay,
sorry
so
so
my
my
question
would
be
remain
to
be
you
you,
you
illustrated
the
conundrum
here
there.
There
are
a
lot
of
non,
not
nailed
down
parts
here.
How
do
we
enable
interoperability?
Then.
H
E
C
I
think
overall,
I
would
just
observe
that
there's
really
nothing
on
the
slide,
that's
specific
to
rats.
Everything
in
the
slide
is
really
about.
You
know
use
of
cosa
and
protocols
in
general,
and
so
I
think.
C
For
interoperability
is
just
how
do
you
interoperate
with
cose
in
general?
There's
nothing
really
specific
on
this
slide,
so
it's
great
to
reference
and
eat.
But
let's
try
not
to
I
guess
my
preference
would
be:
let's
try
not
to
over
specify
it
in
the
eat
document,
because
it's
actually
not
eat
specific.
E
E
I
don't
want
to
run
out
of
time
and
I
have
a
little
a
little
bit
more
so
can
I
go
to
the
next
slide.
E
Okay,
so
this
was
this
is
my
understanding
of
an
endorsement,
as
far
as
I
know,
there's
no
formal
definition
of
an
endorsement.
So
this
is
just
my
assumption.
E
E
It
may
also
contain
some
other
information
like
attribute
value
pairs
that
are
implicit
claims
like
the
model
and
manufacturer
or
the
certifications
received
by
that
a
tester,
some
description
of
the
security
that
that
a
tester
offers
I'm
a
little
unclear
about
reference
values,
whether
it
includes
reference
values
or
not
at
this
point,
but
let's
just
say
it
does
there
could
be
other
ways
you
you
know
you
could
the
reference
value
is
going
to
get
to
the
verifier,
but
it
is
possible
to
do
it
through
an
endorsement.
E
I
think
the
endorsements
are
usually
signed
by
the
the
manufacturer
of
the
attester
so
that
that
sort
of
ensures
that
they're
transferred
to
the
verifier
in
a
secure
way-
and
you
know
we
have
examples-
we
can
do
x,
509
based
perhaps
with
some
extensions,
or
we
could
have
some
new
sebor
cose
based
format
or
something
else
I
mean
I
just
those
are
just
examples.
E
What
I
just
described
previously
was
more
of
an
identifier
of
keys,
not
of
endorsements,
so
my
proposal
here
is
to
add
an
endorsement
id
and
an
endorsement
url
and
I'm
using
url
in
the
correct
way.
I
think
here
to
e,
so
there
would
be
new
cose
headers
header
parameters
that
one
for
endorsement
id
and
one
for
endorsement
url.
E
So
you
could
use
the
endorsement
id
if
you
wanted
to,
or
you
could
use
endorsement
url
if
you
wanted
to.
Probably
you
wouldn't
use
both
and
since
an
endorsement
contains
a
key.
This
is
an
alternative
to
key
identification
right
now.
Eat.
Has
this
origination
claim?
I
think
this
is
a
replacement
for
it.
I
I
don't
think
the
origination
claim.
E
I
mean
that
was
a
kind
of
an
attempt
to
go
down
this
path
before
I
understood
much
about
endorsements,
so
this
we
would
throw
out
the
origination
plan
and
instead
it
would
be
basically
replaced
by
an
endorsement
url.
E
Have
information
in
them
that
you
might
not
expect
to
have
an
nx
509
certificate.
So
if
you
get
something
that-
and
you
know
it's
an
endorsement-
you
know
you
look
in
it
and
you,
you
know
you
look
for
things
like
implicit
claims.
So
when
you're
to
process
in
the
in
the
verification
process-
or
you
know
you
look
for
reference
values,
so
you
you
know
that
this
is
supposed
to
have
those
things
and
it
might
might
be,
the
the
processing
might
be
different.
E
I
I
have
a
comment:
this
is
ned
smith.
Is
there
anything
fundamental
about
the
x
509
format
that
prevents
it
from
carrying
a
implicit
claim.
C
So
I
don't
know
who's
next.
I,
since
it
got
quiet
my
hand,
is
up
I'll
go
next,
I
would
propose
a
slightly
alternative
approach,
or
maybe
it's
a
wording
modification.
If
you
we
think
about
that
diagram.
That
michael
showed,
with
the
endorser,
the
reference
value
provider,
the
you
know,
policy
provider
and
so
on.
The
there's,
as
michael
mentioned,
all
of
those
are
technically.
C
You
know
out
of
scope
for
the
working
group
at
this
time
for
standardization,
and
that
just
means
that
there
may
be
a
lot
of
different
variations
of
how
people
do
that,
and
so
we
need
to
so.
Flexibility
is
important
at
this
point
because
we
can't
mandate
any
particular
thing
up
there,
because
mandating
it
would
be
would
would
have
something
being
in
scope
for
normative,
which
we
said
is
not
in
scope
for
normative.
C
So
all
that
is
a
justification
for
saying,
because
there's
different
ways
that
endorsements
can
work
and
reference
value
providers,
and
so
on
that
we
need
to
accommodate
multiple
models.
The
use
of
how
do
you
get
the
key
material
overlaps
with
the
uri
discussion
we
were
having
on
that
table
that
we
had.
C
What
is
what
is
not
covered
in?
That
is
how
you
might
have
a
uri
for,
say
somebody
that
you
get
reference
values
from
which
may
or
may
not
be
the
same
entity
as
who
you
get
the
verification
key
searching
from.
If
you
were
to
rename
this
as
the
reference
values
url.
I
would
be
completely
happy
with
this
slide,
but
right
now
saying
endorsements
says:
well,
some
people
put
those
in
the
same
place.
Some
people
put
them
in
different
in
some
cases,
one
or
the
other
of
those
could
be
the
manufacturer.
C
In
other
cases,
neither
of
them
is
the
manufacturer,
and
so
it
might
be
different
from
you
know
each
or
I
don't
know
each
origination
claim.
I
can't
remember
how
that
was
defined
and
so
right
now
I
would
propose
adding
a
reference
value
provider
uri
to
eat.
If
people
want
to
use
that,
I
think
that
would
be
great.
I
think
any
other
approach
I
would
be
confused
at
so
are.
C
One
thing
I
think
is
problematic,
and
so
the
I
have
no
problem
with
the
key
id
stuff
that
you
had
before,
which,
in
my
personal
definition
of
endorsement,
which
I
think
is
consistent
with
what's
in
the
architecture
document,
the
endorsement
your
uri
would
be
the
it
would
be
equivalent
to
the
second
row
of
that
table
before,
but
that's
different
from
lawrence's
assumption
of
what
endorsement
means,
and
for
that
I
think
you're
trying
to
provide
things
like
reference
values
and
my
by
the
way
ned.
My
answer
does
not
change.
I
C
I
know
your
definition
of
endorsement
is
different
from
mine
and
there's
different
architecture
document.
But
that's
not
the
point
here.
The
point
is:
what
is
the
information
you're
trying
to
get
okay
you're
trying
to
get
some
key
stuff,
but
that's
covered
by
the
other
uri
you're
trying
to
get
some
reference
value
stuff
and
that
I'm
fully
on
board
with
saying
I
agree,
you
may
want
to
have
a
url
for
that
if
the
if
the
verifier
doesn't
have
another
way
of
getting
that
information
allowing
it
as
optionally
to
be
in
the
eat.
E
C
E
That's
okay!
Let
me
let
me
give
you
the
the
the
two
views
on
that,
so
so
an
endorsement
is
different
than
a
key
in
that
an
endorsement
may
have
other
other
data
in
it
like
implicit,
implicit.
C
Claims
so
any
time
that
you
have
an
x59
search-
and
this
is
what
I
would
say
it
doesn't
change
the
answer
to
net.
If
you
have
an
x59
search
chain
that
you're
going
and
fetching
that's
the
ri
pointed
to
by
the
ex
by
the
cosa
x
509
document,
there
can
be
lid
extensions
in
there
that
have
implicit
claims.
There's
nothing
to
prevent
that.
That
was
the
question
that
ned
was
asking
yeah
yeah.
So
so
you
can
absolutely
do
implicit
claims
in
the
previous
slide.
E
C
If
you
don't
already
have
them,
that's
why
you
know
the
difference
between
the
second
row
and
the
fourth
row
is
whether
the
result
of
what
you
would
have
fetched
is
already
cached
and
provided
to
you
by
the
by
the
attester
encapsulated
into
each
right,
if
the
manufacturer
or
the
endorser
or
whatever,
pre-provided
all
that
information
such
that
the
verifier
just
includes
it
in
the
heat.
That's
fine
that
may
reduce
a
round
trip
from
the
verifiers
there's
cases
where
you
might
want
to
do
that.
C
Yes,
it
makes
your
ep
huge,
but
it's
the
same
amount
of
data
that
comes
into
the
verifier
as
if
you
would
have
had
to
fetch
the
extra
stuff
via
https
and
it
reduces
around
trip
in
some
cases.
So
that's
why
I
want
to
allow
as
an
option,
but
yes,
it
can
have
implicit
claims
in
there.
If
it
wants,
I
mean
that's
what
x59
extensions
are
for
to
provide
additional
information.
Besides
just
the
c
key,
that's
signing.
E
Yeah,
okay-
and
I
mean
I'm
not
saying
that
all
implicit
claims.
C
C
Yeah
right
and
so
that's
why
I
said
the
the
case
that
the
previous
slide
did
not
cover
is
where,
as
the
diagram
that
michael
showed
implies,
the
reference
value
provider
might
be
different
from
the
endorser
meaning.
The
thing
that's
signing
the
keys
might
be.
F
C
F
C
Figure
that
out
and
so
that
one,
I
would
think,
would
be
normally.
You
know
well
known
implied
in
the
verifier,
but
if
you
need
a
uri
to
look
it
up,
I'm
all
on
board
with
making
that
be
optional,
and
that's
where
I
think
that
this
slide
does
have
some
things.
I
would
find
valuable
as
an
option
to
add
a
reference
values
uri
to
eat.
If
you
need
that.
C
A
So
I
think
hank
you
had
a
comment
but
lawrence,
I'm
letting
you
run
over
I'll.
Give
you
another
four
more
minutes
just
because
there's
three
other
presentations
to
go
after
yeah.
E
G
Yeah,
so
if
you
are
doing
the
referral
to
a
reference
value
thing,
then
I
think
the
matthew,
whether
the
mutt's
draft
that
was
started
in
red
is,
would
be
a
good
pointer
about
that.
That's
just
a
general
comic,
because,
because
that's
literally
a
url
pointing
to
to
reference
values-
and
also
I
just
by
adding
the
a
pointer
here-
and
I
think
the
reference
value
pointer
would
be
a
different
pointer
than
that
is
an
endorsement.
G
Id
and
doris
mendy
is
a
little
bit
on
the
fringe
of
things,
because
because
I
think
that
it
is
mixing
endorsement
claims
a
little
bit
with
evidence
claims.
So
it's
on
the
fringe,
basically,
and
and
that's
a
little
bit
difficult-
also
the
slide
before
this.
That's
just
all
the
assumptions
I
would.
I
would
make
these
assumptions
not
assumptions
anymore
before
proceeding
with
a
plan,
so
they
will
so
they
are
not
yeah.
G
So
because
you
can,
I
think
some
of
these
assumptions
do
not
apply
due
to
text
that
is
already
well
defined
in
the
architecture
today
and-
and
we
just
have
to
make
sure
that
we
are
starting
from
a
well-founded
starting
point
here.
That
is
a
little
bit
more
stable
than
an
assumption,
so
this
would
be
my
two
general
comments:
saving
some
time
just
going
into
details.
D
G
Yeah
yeah,
unfortunately,
both
interesting
drafts
to
this
like
the
endorsement
eat
and
the
mutt
draft.
I
let
expires
because
I
had
to
make
a
prioritization
on
what
to
work
on
next,
but
okay,
we'll
revive
them
in
the
in
the
moratorium
after
the
moratorium.
Basically
work
on
them,
and
we
can
talk
about
this
in
between
when
there
is
cut
off
after
cut
off.
A
A
I
think
you
have
some
guidance
on
this.
Did
you
want
to
do
the
other
slides
or
are
you
done.
E
J
Yeah,
I'm
sorry
yeah.
No,
I
don't
have
a
question.
I
don't
have
any
comments
from
these
slides.
I
just
have
a
couple
of
general
comments
to
the
group
first
off
from
an
implement
from
an
implementer's
perspective,
we're
really
relying
on
heat
to
get
finalized
and
mainly
so
that
we
can
nail
down
the
claims
registry.
J
There
are
some
other
issues
that
are
a
little
vexing
lawrence,
actually
posted
an
issue
on
on
the
on
how
nested
sub
mods
nested
eats
could
be
conveyed,
and
these
are,
these
are
actually
eats
that
are
particularly
signed
tokens.
I'm
going
to
post
that
in
that
issue
in
the
in
the
chat
room,
please
everyone
take
a
look
at
it
and
see
because
we've
got
you
know.
J
I
know
internally,
we've
gone
through
the
cos,
a
specs
and
we
know
what's
permitted
there,
but
we
know
what's
implementable
and
lawrence
kind
of
done,
a
good
job
of
capturing
that
in
the
github
issue.
The
second
thing-
and
this
may
also
be
to
the
chairs-
is
we
need
a
we
also
from
an
implementer's
perspective,
need
a
a
need,
an
approach
to
unsigned
tokens.
J
We've
had
a
utcs
draft
that
didn't
seem
to
really
get
moved
to
the
next
next
stage
in
the
work
in
the
working
group,
and
I'm
wondering
if
there
was
ever
an
expression
of
interest
in
this
or
not.
I
know
that
there
was
some
debate
back
and
forth
as
to
whether
this
was
necessary.
Now
the
draft
has
expired.
J
You
know
I'm
not
endorsing
one
way
or
another
I
just
need
to.
We
just
need
to
know
what
do
we?
You
know
what
is
the
proper
approach
for
onsite
tokens
from
an
implemented
perspective,
so
if
that
needs
to
be
filed
as
an
issue
in
the
heat
graph,
that's
fine,
but
I
don't,
but
I
think
it's
broader
than
eat.
A
Okay,
so
I
I
have
to
speak
as
an
individual,
because
I'm
an
author
and
an
endorsed
token,
I
thought
we
had
taken
some
feedback,
so
my
interpretation
as
an
individual,
not
the
chair-
is
that,
given
the
feedback,
there
was
some
interest
that
we
needed.
There
were
some
comments
that
we
need
to
address
on
the
draft
and
we
are
looking
to
update
it,
but
then
it's
up
to,
as
you
said,
the
chairs,
to
put
that
that
called
for
interest
and
adoption
for
that
draft.
J
J
G
So
this
is
hank
in
order
to
make
that
call.
I
have
to
poke
jeremy
again.
Jeremy
was
a
very
quite
a
sparse
resource
in
last
month,
and
that
is
basically
the
reason
why
there
is
no
progress
that
is
not
due
to
lack
of
feedback.
This
is
most
certainly
not
due
to
lack
of
interest.
It
is
due
to
lack
of
author's
time
to
work
on
this.
Unfortunately,
so
I'm
I'm
poking,
and
I
spoke
with
jeremy
last
week
and
we
are
working
on
this
there's
a
plan
before
cut
off.
A
Okay,
so
gary
this
is
good
to
hear,
because
now
I'm
I'm
back
as
chair,
I
was
gonna,
ask
the
question
of
the
interest
and
intent
for
any
implementations
to
come
up
to
help
boost
up
and
raise
the
issues
on
on
the
edge.
So
I
hear
that
at
least
you
are
showing
interest
to
implement
this
and
vet
out.
The
draft
right
is
that
correct.
J
Yeah
and
we've
also
we've
we've
also
gotten,
like
we've,
also
gotten
contact
on
the
eat,
rats
author's
voice
from
the
android
group.
So
we
know
that
that's.
A
K
Yes,
yep
hi
nancy
skye
yeah,
so
I
have
a
just
a
short
short
summary
of
the
riv
progress
we
next
slide.
Please.
K
There
was
a
last
call
which
ended
october,
the
12th
I
should
say
at
this
point
thanks
to
hank
and
weipan,
and
mark
boschke
and
bill
sultan
and
dave
thaler
and
ira,
and
a
few
other
people
for.
K
For
returning
comments,
so
let's
move
on
I'll
review
what
we
did.
This
is
eric's
slide
again,
just
to
reiterate
where
this
fits
into
the
into
the
overall
rats
architecture.
K
Activities
next
slide,
please,
okay.
So
the
comments
actually
added
up
to
almost
700
lines
of
material,
not
700
comments,
but
quite
a
bit
of
material.
I've
worked
through
all
of
them
now
for
first
pass
and
I
think
they're
mostly
pretty
easy
to
address
wording
and
so
on.
I
will
check
in
a
new
version
of
the
draft
to
the
github
today.
K
Yes,
so
there
was
mention
of
this
earlier:
the
definition
oops
endorser,
oh
well,
yeah,
the
the
definitions-
have
shifted
a
little
bit
with
the
split
of
endorsements
into
endorsements
and
reference
values.
K
If
it's
refers
to
signatures
on
reference
values,
coupled
with
that,
as
hank
has
pointed
out,
we
haven't
been
terribly
careful
about
what
we
actually
call
the
reference
values
so
various
documents.
I
don't
think
this
one
has
all
of
them,
but
various
documents
have
referred
to
reference,
integrity,
measurements,
golden
values,
golden
measurements,
known
good
values
and
a
few
other
things.
So
I
will
attempt
to
get
at
least
all
of
the
capitalized
ones
changed
to
reference
values,
which
would
be
signed
by
a
reference
value
provider.
K
That
change
is
yet
to
be
done,
but
when
I,
when
we
get
through
that
one
then
I'll
be
able
to
check
it
in
for
as
version
five
and
I
understand
at
that
point,
then
I
will
poll
the
pull
the
working
group
again
and
the
and
the
commenters
to
ask
if
their
comments
have
been
addressed
adequately.
A
Yeah
and
if
you
can
do
that
and
on
the
list
that
way,
I
can
see
the
confirmation
and
then
we
can
move
forward
to
publication.
K
A
Yeah
so
guy
just
well
you're
gonna,
post
the
draft
and
then
just
send
out
to
the
list
that
you've
updated
and.
A
Poke
the
the
folks
that
you
know,
provided
you
the
the
comments
and
make
sure
that
they
have
been
oppressed.
And
I
will
keep
an
eye
on
that.
To
make
sure.
K
A
G
Hi
everyone
is
my
audio
fine,
yes,
excellent,
so
yeah.
This
is
an
report
on
the
status
of
the
reference
interaction
model
id
also
with
the
extension
of
course
to
the
co-authors,
liquidating
pip
so
far,
which
are
not
here
today.
Next
slide,
please
so
there's
just
a
tiny
recap.
G
So
we
have
three
interaction
models
and
this
now
suddenly
aligns
relatively
well
with
the
examples
that
dave
was
talking
about
beforehand,
because
somehow
the
the
protocols
that,
in
the
end
in
solutions,
will
ensure
some
of
the
freshness
characteristics
that
they've
elaborated
on
before
are
captured
here.
In
this
document,
they
are
more
detailed.
They
are
provide
a
small
information
model
about
the
things
that
I
conveyed
over
the
wire
virtual
wire
and
and
also
some
prerequisites
to
the
entities
that
want
to
implement
protocols.
G
So
the
things
that
are
transmitted
here
are
not
necessarily
parts
of
the
conception
messages
defined
in
the
architecture.
G
These
things
can
be
part
of
the
protocol
itself,
so
so
this
demarcation
line
is
therefore
dissolved
here
a
little
bit,
and
it
is
talking
about
what
information
elements
have
to
be
conveyed
in
the
protocol
level.
Again,
extending
the
scope
exceeding
the
scope
of
conceptual
messages
by
principle
next
slide.
Please.
G
This
is
again
a
small
recap,
as
this
is
has
an
impact
on
all
the
information
conveyed
and
available
to
attest
to
some
verifiers
with
respect
to
evidence.
For
example,
direct
anonymous
attestation
is
covered
in
this
document,
specifically
because
it
can
be
easily
described
here.
It
is
implementation,
detail
and
therefore
not
suited
for
the
architecture,
and
it
can
be
used
by
multiple
solutions
and
therefore
would
have
would
be
reiterated
there
as
well.
G
So
the
the
intent
of
the
reference
document
is
again
to
provide
references
and
therefore
dea
is
on
the
same
semantic
level
and
included
here
next
slide.
G
Please
so
what
has
happened?
Well?
The
document
was
adopted.
It
is
now
a
working
group
item.
It
also
also
updated
quite
recently,
aka
in
the
last
three
hours.
What
has
happened
there
is
that
now,
as
there
was
changes
to
the
architecture
specifically
to
the
reference
values
and
the
reference
value
provider
role,
there
was
changes
in
inverting
here
correspondingly
also
some
other
things
like.
G
We
are
talking
now
always
consistently
of
the
generation
of
evidence
that
has
happened
here
and
we
have
a
strong
relationship
to
the
testing
and
target
environment
here,
because
the
evidence
created
is
about
the
target
environment
and
in
order
to
scope
that
with
not
a
lot
of
words,
it
is
assumed
that
the
reader
is
familiar
with
section
4.3
of
the
architecture
which
is
highlighted
in
the
beginning
of
the
document.
That,
of
course,
is
not
entirely
necessary.
G
G
Please
so
that's
actually
the
gist
of
what
what
this
talk
is
about.
Next
to
the
report
that
I
just
stormed
through,
there
are
two
interesting
sections
with
normative
language.
In
this
document,
one
of
them
is
called
relatively
obviously
normative
prerequisites
which
is
about
the
non-architectural,
but
somehow
always
useful
concept
that
has
to
be
enabled
for
protocol
use.
G
This
is
primarily
about
the
attester,
with
everybody
who
has
skimmed
the
architecture
in
the
last
year
should
probably
be
if
somehow
we
recognize
and
be
familiar
with
the
concepts
in
section
six-
and
my
first
ask
for
review-
would
be
about
that.
That
is
the
first
place
where
normative
language
really
becomes
relevant
in
this
in
this
in
this
document-
and
it
is
the
question
of
course
is:
is
it
applicable
to
the
things
that
you
envision
for
your
implementation?
G
If
you
are,
if
you're
following
that,
so
so,
if
you
are
interested
in
in
creating
a
solutions,
have
a
solution
review
would
be
very,
very
appreciated.
The
the
focus
here
is,
does
this
match
or
is
something
mandatory
here
or
something
required
here
that
is
never
ever
to
be
be
realized
in
a
solution
that
you
think
of
that,
of
course,
would
be
somehow
has
to
be
taken
into
account.
G
The
normative
language
would
change,
probably
or
or
maybe
there
is
an
interesting
inconsistency
for
a
from
point
of
view.
So
that
is
the
first
ask,
and
the
second
ask
is
pretty
much
similar.
I
was
talking
about
the
most
essential
items
that
are
conveyed
via
protocols
here
again
exceeding
the
scope
of
the
conceptual
messages,
as
defined
in
the
architecture.
Maybe
and
again,
there's
some
normative
language
here
and
it
may.
G
It
is
very
important
that
we
are
not
being
arbitrarily
exclusive
here
and
somehow
pushing
out
very
meaningful
and
useful
concepts
by
mandating
something
that
would
be
absolutely
beside
the
point
again.
The
intent
was
not
to
do
that
and
be
very
careful
and
minimal,
but
nobody
knows
there
can
be
a
fringe
cases
that
are
more
important
than
you
thought
of
something,
and
maybe
we
have
a
generic
discrepancy
in
general.
G
C
C
Meeting
started,
as
you
know,
at
pacific
time,
7
30.
No,
I
did
not
spend
time
reading
the
three
hours
old
document
right
before
the
meeting.
Sorry
I
apologize.
C
My
comments,
I
called
it
up
on
the
screen
when
hank
had
this
put
the
slide
up
and
that's
the
extent
to
which
I
looked
at
it.
Yeah,
okay,.
A
G
Structural
changes
to
the
content,
so
it
doesn't
hurt
especially,
but
that
I
don't
think
there's
anything
semantically
changed
to
the
to
the
concept
at
all.
So
so
this
was
all
alignment
of
terminology
and
alignment
of
structure.
So
that
is
everything
I
did.
A
Okay,
so
hank
you
should
put
out
the
you
know.
I
haven't
checked
my
mail,
so
I
didn't
see
the
update
go
through
on
on
the
mail.
Usually
you
get
the
new
draft
announcements,
but.
C
A
A
All
right
so
hank,
let's
continue
the
discussions
and
then
hopefully
by
you'll,
get
some
comments
by
the
itf
109.
And
then
we
configure
direction
and
readiness.
F
G
Exactly
so,
I
was
targeting
for
feedback
phase
starting
now,
so
I
will
issue
the
official
request
on
the
list.
We
have
time
before
the
cut
off
and
then
even
still
so
I
think
that's
a
good
time
frame
for
feedback
and
yeah.
I
will
do
accordingly,
so
good.
A
L
Yes,
I
am
on
behalf
of
the
other
authors.
Yes,
we
have
update
three
to
chara
next
slide.
L
The
big
thing
that's
happened
in
the
latest
incarnation
is
that
we
passed
our
most
recent
copy
of
the
yang
model
to
the
yang
doctors
and
the
draft
of
the
yang
doctors.
They
should
be
coming
back
any
day.
They
should
have
been
here
yesterday,
but
that's
again,
a
little
early,
we're
waiting
to
see
what
their
comments
are
to
see
how
to
progress,
hopefully
towards
working
group.
Last
call
next
slide.
L
Now
there
were
a
number
of
issues
addressed
first
in
the
overall
document
there
is
text
added
to
describe
the
purpose
and
the
content
and
context
of
this
particular
yang
model.
There
are
people
who
can
read
yang
models,
know
what's
going
on.
Most
people
are
not
like
that,
so
just
trying
to
identify
what
is
in
the
yang
model
and
being
able
to
break
it
out
was
a
big
change
to
the
last
draft
within
the
yang
model.
L
L
We
also
refine
the
model
to
in
eliminate
many
types
of
redundancies
and
sources
of
configuration
error.
That's
the
biggest
change
that
has
occurred
is
just
trying
to
get
away
from
strings
and
make
them
enumerations
and
other
kinds
of
types.
Additionally,
there
were
redundant
elements
that
probably
weren't
needed
in
the
rpcs
and
allowing
them
to
be
pulled
out
by
yang
fetch,
rather
than
being
sent
on
every
rpc
seemed
as
a
way
to
just
simplify
the
amount
of
development
needed
for
somebody
on
the
development
side.
L
Also,
along
that
line,
we
remove
the
key
establishment
rpc,
since
people
can
establish
keys
in
other
ways.
There's
descriptive
text
added
in
the
model
and
we
also
added
a
bunch
of
high
level
containers
just
to
make
sure
things
grouped
a
little
bit
more
cleanly
by
people
doing
read
and
write.
That's
the
main
issues
addressed
next
slide.
L
There's
a
number
of
open
issues,
and
these
are
the
ones
that
I
think
are
gating
working
group
last
call.
First,
one
is
some
of
the
expressions
to
do
configuration,
validation
before
writing
to
a
data
store,
have
to
be
reviewed
and
added
to
a
couple
of
us
made
some
guesses
but
the
xpath
for
those
of
you
used.
It
is
fairly
abstruse,
I'll
use
that
word
and
trying
to
get
somebody
who
really
knows
xpath
to
see
if
we
got
it
right
is
something
that
we're
looking
to
do
so.
L
L
Second
thing
is
we
want
to
make
sure
that
any
young
doctor
comments
we
get
are
addressed.
I've
been
on
the
other
end
of
young
doctor
comments
before,
and
there
will
be
some
and
we're
going
to
have
to
wait
till
they
come
in
before
we
do
that.
So
that's
an
open
issue.
L
L
We
haven't
actually
been
able
to
track
down
the
person
who
built
the
original
code
for
the
1.2
rpc
and
we're
trying
to
simplify
away
things
that
we
don't
believe,
are
necessary
or
been
making
some
requests
for
people
who
would
be
able
to
verify
for
using
1.2
that
we've
got
the
minimum
set
of
fields
requiring
standardization,
and
I
think
that
making
sure
the
quotes
are
as
close
as
possible
would
be
positive.
We
just
got
to
make
sure
that
whoever
wants
this
has
their
experts
review
the
model
now.
L
L
L
L
So
the
certificate
name
is
a
requirement
for
understanding
what
is
coming
back
from
the
rpc
and
it
is
assumed
to
be
unique,
and
you
know
you
only
will
change
and
add
this
to
the
rpc
when
you
have
a
subset
of
tpms
that
you
want
to
get
information
from.
If
you
just
query
the
rpc,
it's
going
to
assume
give
me
everything.
It's
the
only
time
in
the
rpc.
You
want
to
actually
indicate
that
you
need
a
subset
of
the
tpms
to
attest.
L
Is
when
you
list,
let's
say
the
certificates
to
say,
give
me
information
relating
to
this
certificate.
So
the
alternative
which
has
been
discussed
and
we're
still
awaiting
comments,
is
instead
of
identifying
the
certificate.
What
if
we
identify
the
tpm
name
and
the
node
id
you
know,
this
is
an
alternative
which
could
work.
The
con
to
this
there's
a
few
con
is
that
you
have
to
identify
node
ids
and
you
don't
have
to
know
node
ids
on
a
device,
but
you
definitely
still
have
to
know
the
certificates
that
are
there.
L
So
perhaps
that
might
be
additional
and
then
the
tpm
names
again,
you
might
not
know
need
the
tpm
names,
because
if
you
know
the
certificate
names
you
can
get
to
them
by
reference,
as
is
shown
in
the
top
on
the
output
side.
Again,
do
you
want
to
repeat
all
the
information
along
with
tpm
and
node
id?
We
could
add
these
things.
It
would
just
mean
that
you
are
providing
output,
which
you
could
also
get
from
the
from
the
rpc.
L
L
My
preference
is
option,
one,
that's
what's
in
the
current
model,
but
I
want
to
make
sure
that
everybody
who
has
said
that
they
are
interested
in
having
additional
information
with
our
pc
has
a
chance
to
to
chime
in
before
before
we
close
this.
So
that's
the
big
question.
That
is
the
open
question
and
I
want
to
see
if
anybody
on
the
call
has
any
comments
on
it
again.
The
recommendation
I
have
is
one
just
because
it's
simpler
and
easier
for
the
operator.
F
Hi
eric
this
is
weipan
and
I
think
the
option
one
is
a
current
design
of
the
current
version
and
have
you
note,
I
noticed
that
even
in
the
option,
one
in
the
output
part,
there
is
still
a
node
id
and.
F
Is
that
have
some
does
that
have
some
specific
purpose
to
have
that
in
the
output?
Because
you
know
if
you
can
use
certificate
name
to
to
to
to
get
the
tpm
name
and
the
note
id
why
you
still
leave
the
node
id
in
the
output.
L
I
think
that
was
just
a
the
latest
version.
It
hasn't
been
updated.
I
was
planning
on
pulling
node
id
out.
I
just
haven't
yet
so
whatever
people
decide,
I'm
happy
to
have
it
being
redundant,
but
my
expectation
is
that
it
is
not
required.
F
Okay
and
actually,
in
my
assumption
or
imagination,
I
think
both
options
are.
F
Are
not
very,
how
do
you
say
both
have
their
prongs
and
cons
and
option?
One
may
be
more
more,
maybe
better
for
for
people
to
read
and
option
two
may
be
more
easy
for
the
machines
to
process,
but
but
I
don't
think
they
are.
They
are
have
many
huge
disadvantages
for
both
options
and
I'm
fine
with
both
and
and
that's
my
opinion.
Yeah.
L
F
Maybe
for
about
option
two,
maybe
in
such
a
case
in
the
composite
device
scenario,
when
the
leader
tester,
doesn't
you
know
when
the
leader
test
only
has
doesn't
have
the
capability
of
handling
the
young
data
stores?
Maybe
it's.
There
is
another
component
to
do
the
to
handle
the
young
data
stores
and
in
such
case
the
option
option
two
option.
One
may
have
more
process
required
between
the
leader,
tester
and
the
young
components,
and
in
this
case
I
think
option.
One
may
option
two
may
be
easier.
L
The
that
is
a
possibility.
In
that
case,
you
still
have
to
know
what
tpm
names
are
from
the
yang
model,
so
they're
not
an
id
which
you
would
understand
the
node
id
and
the
tpm
name.
If
you
don't
know
them,
they're
not
going
to
prove
or
you
can't
get
access
to
yang,
you
still
would
have
to
understand
what
they're
for
so
they'd
still
be
requiring
extra
external
coordination.
L
If
you
don't
know
yang,
you
will
have
to
get
unique
identifiers
for
your
line
cards
and
that
could
come
just
as
well
from
certificate
name
anyway.
So
again,
if
people
or
if
you
want
to
add
more
to
the
list,
we
can
see
if
we
can
close
things
out.
There
is
an
open
thread
on
this
and
be
happy
to
chase
that
particular
one
down.
A
L
Yep
there
is
a
current
discussion
on
this
with
it
was
bing
chao.
I
I
tried
to
pull
his
name
up.
Okay,
sorry!
So
let's
go
to
that
discussion.
L
G
I
have
a
this
thing.
I
have
a
clarifying
question
for
slide.
Six
sure
are
both
options
of
option
one
and
option
two
mutual
exclusive,
or
can
one
option
be
somehow
tinkered
as
a
redundant
thing
under
the
other
option,
because
to
me
it
doesn't
look
that
way,
but
I
think
I
heard
that
as
a
possibility.
L
Well,
the
question
of
how
much
redundancy
do
you
want
to
have?
Is
there
if
you
added
all
the
objects,
you
could
do
it,
but
the
thing
is,
then:
you
have
a
lot
more
errors
to
check
because
there's
a
certificate
name
matching
the
tpm
name.
What,
if
they're
different
what
if
the
node
id
is
different,
so
you
just
have
much
more
complexity.
L
A
Thanks
so
I
think
that
was
our
last
presentation.
So
unless
there's
any
other
issues
or
comments
to
be
raised,
we
can
finish
five
minutes
early.
A
Going
once
going
twice
all
right,
thank
you
all
and
don't
forget
if
you
haven't
put
your
name
on
on
the
cody
md
for
the
attendance
all
right.
So
with
that
I'll
see
you
guys
in
ietf,
109.