►
From YouTube: RATS Architecture Design Team, 2020-09-25
Description
RATS Architecture Design Team, 2020-09-25
D
B
D
B
D
So
I'm
gonna
suggest
we
go
to
150
first,
since
we
had
two
approvals
and
two
comments,
and
I
think
I
just
addressed
the
comments,
and
so
we
had
comments
from
lawrence
and
hank
and
then
I
just
pushed
an
update,
and
so
you,
I
moved
your
request.
Changes
back
to
please
review
again.
D
So
I
can
highlight
what
I
just
changed:
okay,
so
the
that's
one.
Please
look
at
the
second
sentence.
There
is
brand
new,
that's
and
so
lawrence
had
asked
for
one
thing
and
then
hank
you'd
ask
for
a
longer
list,
and
so
this
is
the
longer
list
that
I
tried
to
keep
the
wording
not
inconsistent
with
a
later
section
right.
Not
all
reference
values
are
known,
good
values.
We
already
had
text
later
on
about
that,
and
so
I
tried
to
both
incorporate
hank
your
text
plus
the
last
phrase.
D
No,
I
just
known
bad
values.
That's
all
right!
Well,
I'd
be
it
talks
about
examples
of
within
a
particular
range,
and
so
it
would
be.
You
know.
A
A
D
And
then
the
other
thing
he
wanted
was
in
the
I
think
in
the
trust
model
section.
So
there's
a
couple
of
deletions,
you
can
say,
stop
right
there.
The
you
want
to.
I
think
lawrence
wanted
known
good,
remove
from
both
of
those,
because
it
was
incorporated
up
above
in
841
and
869,
and
it's
not
showing
me
the
last
one
that
I
just
pushed
so
either
I
didn't
push
it
correctly.
D
B
D
It
shows
as
push,
let
me
see
if
it
actually
made
the
change
in
here
somehow
lost
the
change.
No,
it
should
be,
it
should
be
in
there.
So
let
me
see
what
line
number,
because
it
shows
that
is
it
matches
the
remote
branch
number.
D
Yes,
that's
it
okay,
so
it
looked
to
me
like
the
so
the
I
think
it
was
hank.
You
would
see
their
once.
I
think
it
was
you
hank
that
you
said
we
need
to,
since
we
added
a
new
role
per
se,
that
the
trust
model
section
needed
to
mention
that
role
as
well-
and
it
looked
to
me
like
the
text
that
covered
endorser
and
verifier
owner,
that
same
text
was
applied
to
reference
value
provider
two.
So
I
just
added
an
and
into
the
two
places
the
other
two
are
listed.
D
A
Yeah,
I
have
to
check
that
again,
so
my
assumption
is
from
the
top
of
that.
Yes,
but
I
I
just
perceived
this
as
yeah.
I
I
didn't
understand
what
you
were
doing
so
basically,
so
I
we
have
to
check
the
semantics
again.
My
assumption
is
go
ahead.
Please
I
will.
I
will
come
back
to
this,
as
I
think
this
is
unexpectedly
not
correct,
but
for
now
I
would
even
say
we
can
accept
this
because
it
would
make
it
would
make
a
lot
of
sense.
Yeah.
D
And
lauren's
just
to
answer
your
question
on
the
call
last
time
peter
and
I
were
saying
the
same
thing
and
so
that
this
change
was
me
attempting
to
put
in
what
peter-
and
I
were
saying-
and
one
of
the
main
points
was
that
typically,
the
reference
value
provider
is
either
the
endorser
or
the
appraisal
policy
provider,
which
is
the
verifier
owner.
But
in
theory
it
could
be
a
third
party
and
a
third
entity.
D
That's
neither
of
those
that
that
it's
obtained
from,
and
so
this
is
flexible
enough
to
handle
all
three
models
where
it's
exactly
the
same
as
the
endorser
and
you
get
it
as
part
of
the
endorsements
or
it's
exactly
the
same
as
the
verifier
owner,
and
you
get
it
as
part
of
the
policy
or
the
policy
references
both
the
endorsements
and
the
reference
values
from
some
third
party.
All
those
are
possible,
and
so
the
new
text
tries
to
encompass
that.
D
So
that's
the
only
difference
from
what
you
might
have
expected
is
that
it
could
in
theory,
be
yet
a
third
entity.
It
might
not
be
very
common,
but
it's
possible.
So
that
was
the
summary
from
last
time.
D
C
That's
why
yeah
that's
right
and
you
put
it
in
a
better
place,
okay,
so
what
next
then.
G
The
top
of
my
list
is
149,
okay
or
yeah
pr
149.
A
C
D
D
D
H
A
Let's
wait
for
it,
wait
for
it,
wait
for
it.
Are
you
doing
the
review?
Are
they
except
oh
yeah,
just.
I
D
D
All
right
here,
here's
the
only
concern
that
I
have
when
I'm
reading
through
this.
The
green
is
not
incorrect,
it
is
correct
and
it
is
actually
more
precise.
I
think
the
wording
in
the
red
and
look
at
the
ending
part
right,
the
changing
and
a
tester
to
a
testing
environment.
Okay,
we've
already
defined
a
tester
in
the
terminology,
and
so
that
part,
the
red
part,
is
understandable.
The
ending
half
of
the
sentence,
the
testing
environment,
is
not
defined
until
way
down
in
the
two
types
of
environment
thing,
and
so
because.
A
D
F
D
G
So
I
went
through
all
of
the
paragraphs
in
section
seven
and
labeled
them
whether
they
were
primary
trust
flow
or
secondary
trust
flow.
Primary
being
you
know
about
establishing
trust
in
the
attester
secondary
being
about
confidentiality
or
privacy.
There
was
no
discussion
at
all
of
primary
trust
flow
under
a
tester.
So
I
added
one.
H
B
H
G
I
think
it
would
be
okay
to
to
use
those
in
the
text,
but
no
we
haven't
defined
them
yet
and
no
we're
not
using
them
in
the
text
yet.
But
I
just
did
it
because
you
know,
like
I
said,
I
went
through
every
paragraph
in
section
seven
to
to
understand
whether
it
was
primary
trust,
flow
or
secondary
trust
flow.
G
G
Yeah,
I'm
just
describing
it
just
so
you
understand
where
I'm
coming
from,
but
yeah
it's
not
mentioned
in
the
text
anywhere
so,
and
what
I
wanted
to
make
sure
is
that
every
subsection
mentioned
discussed
both
the
primary
trust
flow
and
the
secondary
trust
fall.
Make
sure
that
that
was
there
in
both
places.
So
in
the
section
on
the
attester,
there
was
no
discussion,
a
primary
trust
flow,
so
I
added
one
so
that
was
that
was
one
one
change.
D
I'm
just
going
to
translate
what
you're
saying
into
layman's
speech,
because
I
I
understand
you're
saying
what
did
not
have
a
discussion
of
is
the
trust
between
the
verifier
and
the
lying
party.
It
only
sorry
the
the
tester
in
the
relying
party.
It
only
talked
about
a
tester
to
verifier
and
when
you
say
primary,
you
just
mean
a
tester
to
relying
party
and
when
you
say
secondary,
you
mean
a
tester
to
verify
or
verify
derailing
party.
D
C
G
G
Because
I
mean
to
me
it
doesn't
it's
a
process,
it's
a
process.
It's
like.
D
G
And
privacy
of
the
data-
so
that's
all
about-
does
the
tester
trust
the
verifier
enough
to
give
it
the
data
that
might
be
you
know
privacy
sensitive
or
might
reveal
something
about
vulnerabilities,
so
it's
basically
a
flow
in
the
opposite
direction
and
it's
a
flow
through
all
of
the
entities
in
in
the
in
the
in
the
system.
G
So
if
you-
and
if
you
look
at
like
the
the
paragraphs,
the
current
paragraphs
in.
G
G
D
D
D
It's
it's
all
over
the
place.
Go
back,
go
back
to
the
tester.
That's
the
section
right
there!
That's
the
text
that
talks
about.
They
need
to
trust
the
verifier
before
giving
the
endorsement
reference
values
or
appraisal
palsy
to
it.
That's
what
you
just
defined
as
being
your
secondary
one.
That's
covered
in
that
sentence.
G
No,
it's
other
places
too.
Can
you
go
back
to
where
you
were
michael
and
and
scroll
up
to
a
tester.
G
So
right
there,
those
two
paragraphs
right
there
are
all
about
privacy
and
confidentiality
as
well.
So
in
that
testimony
yes,.
A
Yeah,
that
is
the
intent
of
this
section,
is
exactly,
I
think,
what
you
are
calling
the
secondary
flows,
yes
correct,
because
we
cannot
talk
about
them
in
entirely
because
it's
all
about
evidence
and
and
and
reference
various
flows,
but
there
has
to
be
some
trust
beforehand,
and
that
is
the
model
that
is
explained
here.
I
think
that
is
the
intent
of
the
section.
Actually,
your
secondary
flow
of
scope.
D
G
D
What
your
what
every
subsection
is
is
for
any
entity,
anything
that
it
has
to
trust
in
that
it
had
any
other
any
other
entity
that
has
to
any
other,
for
each
role
for
every
other
role,
that
it
has
to
trust
that
it
needs
a
statement
about
needing
to
trust
that
particular
role.
D
G
D
Yeah,
the
intent
is,
there's
one
little
paragraph
or
something
for
within
each
role,
one
sentence
or
paragraph
or
whatever
for
each
other
role
that
it
needs
to
trust
yeah.
So
in
this
case
the
attester
needs
to
trust
the
verifier.
So
there's
a
there's
a
paragraph
about
that
right.
The
the
endorser
may
need
to
trust
the
verifier
there's
a
paragraph
about
that.
The
verifier
needs
to
trust
the
endorser.
There's
a
paragraph
about
that
right,
so
yeah.
I
agree
with.
G
H
G
I
believe
there
is
information
that
is
incorrect.
That's
in
the
verifier
section,
that's
that
is
partially
shown
right
now
by
michael.
G
G
The
I
believe
the
the
verifier
only
comes
to
trust
the
attester
through
key
material.
It's
it
can't
there's
no
implicit
trust.
You
can't
have
a
trust
in
the
firmware
or
software
that
that
that
trust
always
comes
through
the
attester
signing
evidence
with
the
nonce.
Typically,
I
mean
there
may
be
some
cases
where
the
the
verifier
and
the
tester
are
co-located
on
the
same
bus,
but
that's
not
very
interesting.
The
interesting
case
is
when
the
verifier
and
the
tester
are
far
apart.
G
So
so.
H
G
H
G
H
Yeah,
a
classic
one
use
case
with
the
the
the
what
we
would
call
the
attester
right.
The
device
has
verifier
capabilities
integrated
into
it,
and
so,
as
part
of
the
boot
process,
it
you
know,
verifies
that
it's
booting
the
right
code
before
it
transfers
execution
to
the
next
bit
of
code,
and
it's
the
connectivity,
is
it's
all
running
within
the
same
execution,
environment.
G
H
But
there's
some
implicit
trust
there.
H
Someone
could
drill
down
into
that.
You
know
for
any.
For
any
of
these
cases,
you
could
drill
down
into
it
and
identify
something
that
is
a
is
local
and
something
that
is
remote.
With
respect
to
some
some
idea
of
a
domain,
a
domain
boundary,
so
it
gets,
it
gets
really
difficult
to
try
and
find
the
words
to
be
concise,
but
still
not
disallow.
H
You
know
some
of
these
other
approaches,
and
so
I
mean
I
get
where
you're
coming
from,
and
I
get
that
the
the
name
of
the
rats
working
group
is
remote
attestation
procedures,
but
you
know
we
haven't
really
defined
what
we
mean
by
remote.
You
know
who
you
are
and
what
you're
building
you
know
frame
of
references
remote
could
be
lots
of
things.
H
Maybe
if,
if
what
you're
pointing
at
is
it
isn't
clear
that
the
case
that
you're
describing
is,
you
know,
isn't
isn't
you
know
described
and
we
we
could
add
that,
but
I
I
don't
think
we
need
to
remove.
What's
these
other,
you
know
cases
that
are
viable
only
because
we
think
they're,
not
common,
because
we
don't
know
what's
going
to.
G
Yeah,
I
think
you
would
there's
some
text
definitely
needs
to
be
added.
That
describes
the
remote
case,
because,
what's
really
described
here
under
verifier
is
only
the
the
non-remote
case.
D
Maybe
the
language
could
be
better.
I
saw
I'm
just
listening
and
thinking
about
this,
I
think
the
my
interpretation
of
implicit
trust
is
when
you
put
trust
in
something
that
is
not
voted
for
by
anything
else,
so,
for
example,
by
votes
for
by
any
other.
You
know
any
other
key
material
whatever
so,
let's
say
you're
endorser
or
perhaps
the
endorsers
as
certificate
authority
would
be
an
implicit
trust
because
nothing
is
vouching
for
the
the
root
of
the
certificate
chain.
H
Yes,
so
so
some
folks
have
a
different
use
of
implicit
in
the
context
of
attestation,
which
is
to
say
that
the
assertion,
the
claim
that
you're
making
won't
exist
if
it
isn't
true
and
the
reason
is
because
the
key
can't
exist
because
of
the
way
the
keys
are
derived
that
you
know
the
you
can.
You
know
the
key
exists,
and
so
you
turn
that
around
the
other
way.
H
D
Let's
see
I'm
looking
at
the
there's
two
uses
of
implicit
in
the
text
that
launches
for
referring
to
one
is
in
the
third
line
down
from
verifier,
where
it
says
a
verifier
might
be
configured
to
implicitly
trust
firmware
or
even
software,
not
the
the
third
line
down
from
the
heading
and
then
the
second
one
is
the
last
sentence
of
that
one.
The
component
that
is
implicitly
trusted
is
often
referred
to
as
root
of
trust.
D
Right
in
between
there
is
the
opposite
side
right,
because
a
verifier
might
be
configured
to
implicitly
trust
foreign
software
and
then
the
next
sentence
says
a
stronger
level
of
assurance
comes
when
information
can
be
vouched
for
by
security
by
hardware
or
by
ram
code.
So
that
tells
me
the
meaning
of
implicitly
trust
is
a
firmware
software
that
is
not
vouched
for
by
hardware
or
by
rom
code,
and
so
that's
what
I'm
really
reading
in
here
is
the
definition
of
implicit
trust.
In
this
context,.
D
G
H
I
think
it's
useful
to
be
able
to
have
words
for
the
the
attestation
process,
which
we're
right
now
we're
using
the
word
vouched
for
to
be
that
term,
which
is
which
is,
and
maybe
that's
fine,
but
at
least
maybe
to
maybe
be
more
more
direct
in
the
paragraph
to
say
this
is
what
we
mean
by
that
term,
and
then
you
can
use
it
to
describe
the
properties
here.
It's
sent
at
the
end,
so
the
definition
is
as
at
the
end,
trailing
the
conversation
about
trust.
A
H
D
G
So
I
mean
the
the
chorus.
D
Missing
or
broken
as
far
as
what's
missing
or
broken,
is
this
the
paragraph
that
you
said?
Okay,
we
need
to
fix
this,
then
maybe
there's
some
other
stuff
too,
or
is
there
something
else?
That's
that's
missing
or
broken.
Besides
this
paragraph.
G
A
H
G
Yeah,
because
you
start
discussing
hardware,
physical
tampering,
resistance
and.
H
H
D
G
The
verifier
only
ever
trusts
the
the
endorser
well.
D
The
verifier
trusts,
whoever
signs
things.
This
is
saying:
if
the
hardware
assigns
things,
then
it's
the
hardware
and
or
the
hardware
manufacturer,
meaning
your
endorser
is
endorsing
the
hardware
and
the
other
case
is
the
firmware
software
and
maybe
who
endorses
the
firmware
software
independent
of
the
hardware.
G
G
D
That
that
is
one
case.
It
is
certainly
not
the
only
case
in
this.
In
this
document
yeah
yeah,
I
agreed
right.
There
are
cases
where
they,
where
there
is
no
endorser,
it's
as
we've
talked
about
before.
It's
it's,
not
scalable,
but
if
you
have
a
very
small
deployment
or
very
small
affinities,
then
you
actually
don't
need
an
endorser.
G
So
describe
that
that
that
that's
probably
a
disconnect
here
for
me.
So
if
the
say
it's
a
remote
attack
station,
how
do
you
have
a
remote
attestation
without
key
material?
You
have.
D
It
with
material
the
key
material
so
as
I've
mentioned
it
before
in
the
comments
on
pull
request,
because
I
don't
think
you
were
in
the
meeting
then,
but
I've
explained
in
the
comments
here,
so
I'm
just
going
to
repeat
what's
in
there,
because
you
have
to
trust
key
material.
Okay,
so
there's
a
key.
Let
me
back
up
for
a
second
there's,
a
key,
that's
in
the
tester.
D
Okay,
in
the
case
where
you
have
an
endorser
what's
happening,
is
you
have
the
endorsers
key
that
signs
the
a
tester's
key
and
that's
what
we
call
an
endorsement
right?
It's
one
key
signing
another
key
or
in
the
verifier
you
have
a
trust
anchor
store.
So
when
you
have
a
set
of
evidence
that
comes
in
you
say,
hey
is
this
signed
by
something
I
can
chain
up
to
a
key.
That's
in
my
trust,
anchor
store
when
you
have
an
endorsement
you're
saying:
oh,
let's
take
the
tester's
key.
D
Let's
see
if
I
can
get
an
endorsement
signed
by
some
endorser
great,
it
is
that's
valid,
and
now
I
can
see
if
the
endorser's
key
is,
in
my
trust,
anchor
store
right.
That's
the
case.
We're
using
an
endorser-
or
perhaps
you
might
even
have
a
case
where
you
say
the
endorser's
key-
is
not
in
the
trust
anchor
store,
but
the
endorser's
key
has
its
own
search
chain.
That
chains
do
some
pki
up
to
some
certificate
authority.
The
cervican
authority
is
in
the
trust,
anchor
store.
D
That's
the
case,
then
there's
a
case
that
is
much
less
scalable
that
says:
okay,
when
the
evidence
comes
in
it's
signed
by
the
attesters
key.
If
the
testers
key
itself
is
in
the
verifiers
trust
anchor
store,
you
don't
need
the
endorsement
right
because
it's
already
chained
to
a
key,
because
it
was
right
there
in
the
evidence.
D
It's
not
scalable
as
much,
because
now
you
have
to
have
some
way
of
getting
the
tester's
key
itself
into
the
verifiers
trust
anchor
store
for
every
tester
that
uses
that
verifier
it
can
be
done,
but
only
if
you
have
a
very
small
number
of
things
and
maybe
the
verifier
and
the
tester
are
created
by
the
same
entity,
and
so
it's
really
easy.
You
don't
need
an
extra
roll
in
there,
an
extra
step
of
keys,
but
it's
possible
and
the.
D
Yeah
yeah
yeah,
when
the
marathon,
the
manufacturer,
does
the
verifier
the
tester.
You
have
a
total
of
20
devices.
That's
in
your
you
know
special
high
military
grade
deployment
and
you
don't
need
an
extra
key
in
there.
You
just
stick
the
20
devices
keys
and
the
trust
anchor
store
the
verifier
and
you
call
it
good
and
you
don't
need
anything
else.
That's
an
endorsement
in
that
case
it's
kind
of
a
trivial
special
case,
but
it's
absolutely
possible
and
there
are
at
least
demo
deployments.
D
I
can't
say
for
sure
whether
they're
in
use
and
say
military
grade
stuff,
because
I
wouldn't
know
that,
but
I
can
say
certainly
in
demos
and
research
and
things
it's
absolutely
possible
to
do
it.
That
way,
and
so
the.
D
Is
flexible
enough
that
all
the
models
I
just
mentioned
all
apply,
meaning
that
all
the
text
is
carefully
worded
such
that
all
those
models?
None
of
those
are
precluded
in
any
detection
document.
G
Right
so
so,
there's
a
real
use
case,
where
one
that
I
I
know
of
in
detail
where
one
fortune
500
company,
a
manufacturer
of
kind
of
a
tester
of
sorts
ships,
shipped
monthly,
a
database
of
millions
of
seeds
for
keys
to
the
verifier.
C
G
G
From
the
endorser
by
some
undocumented,
on
non-explicit
path,
it's
not
in
the
diagram
by
that.
The
definition
of
endorser
of
endorsement
that
that
dave
is
using
the
key
material
can
flow
into
the
the
verifier
from
you
know,
by
a
path,
that's
not
on
the
system
diagram
and
to
me,
that's
really
weird
and
confusing
for
something
as
important
as
the
key
material,
the
verification,
key
material.
That's
that's!
That
is
very
strange
and
weird
to
me.
G
The
system
diagram
should
show
all
of
the
really
important
critical
things
that
are
necessary
for
an
endorsement
and
the
the
and
necessary
for
an
attestation,
and
I
think.
D
What
you're
talking
about?
If
I
understand
right,
I
think
you're
talking
about
how
do
you
configure
the
verifiers
trust
anchor
store?
And
I
would
say
and
there's
you
know:
how
do
you
configure
their
their
lying
party's
trust
anchor
store?
And
so
on
that?
I
don't
think
in
configuring.
Trust
anchor
stores,
in
my
opinion,
is
not
specific
attestation.
D
It's
a
general
problem,
and
I,
if
I'm
remembering
it,
wasn't
that
the
topic
of
michael's
document
that
was
a
separate
document
which
is
not
a
working
group
document
right
now,
but
it
was
presented
and
a
lot
of
people
liked
it
and
said
hey.
This
is
bigger
than
just
rats.
It's
a
cool
problem.
D
To
attestation,
but
there
is
the
problem:
how
do
you
configure
the
trust
anchor
store?
And
you
say
how
do
you
get
the
key
material
into
there?
That's
the
conflict,
that's
provisioning,
a
trust
anchor.
How
do
you
get
somebody
else's
public
key
into
your
trust,
anchor
store
if
you're
using
public
key.
G
And
to
me,
this
is
because
it's
attestation
and
that
the
trust
is
transitive
through
this
through
the
endorser.
To
me,
that
should
be
explicit.
A
It's
not
in
the
scope
of
this
document
to
define
solutions
that
not
red
specific.
A
We
have
to
say,
though-
and
I
think
that's
a
good
point-
that
all
of
these
roles
can
have
trust
anchor
stores
and
those
should
have
to
be
managed
in
a
feasible
way,
and
maybe
we
could
even
elaborate
on
a
few
example
ways
to
do
that,
but
that
is
an
over
describing
overprescriptive
thing.
I
think
yeah.
D
I
was
gonna
say
the
same
thing
as
hank,
although
I
wasn't
gonna
say
to
put
it
into
here,
but
I
would
be
fine
with
saying
trust:
anchor
store
provisioning
at
these
different
roles
for
more
discussion
of
that
see,
michael's
document
and
for
informational
reference.
Then,
if
it's
informational,
it
doesn't
have
to
be
an
rfc
and
we
can
just
reference
that.
C
E
E
I
agree
that
we
should
not
go
into
a
lot
of
detail
on
how
that
is
done,
because
there's
so
much
variation
on
how
that
might
be
done
and
different
use
cases
are
gonna
have
different
ways.
So,
if
the
concern
really
is
that
the
diagram
doesn't
have
a
explicit
path
of
how
that
that
trust
is
established,
maybe
it
would
suffice
just
to
put
a
little
note
with
the
diagram
that
says
that
here
that
that
this
relies
on
a
means
that
trust
is
established
here,
because
we're
putting
trust
in
things
like
keys.
D
H
D
A
D
It
in
a
different
section,
because
it
has
more
details
to
talk
about,
but
it's
not
in
the
equivalent
of
this
picture
right
here.
In
other
words,
it's
treated
as
a
separate
topic,
but
it's
covered
in
the
document
because
it
says
here's
what
the
trust
anchor
stories
are
and
who
trusts
who
so
it
has
kind
of
a
equivalent
section
of
trust
model
with
a
table
in
it
in
their
case,
which
may
not
be
necessary
here.
But
it
didn't
update
the
system
diagram
to
answer
your
question.
C
So
if
I
may
go
back
a
moment-
and
we
have
only
10
minutes
left-
I
I
think
lawrence
and
we've
kind
of
been
down
this
road
a
couple
times
together.
I
think
that
that
the
the
pushback
you're
getting
is
because
not
that
this
is
not
an
important
activity,
but
that
the
the
variety
of
different
ways
of
doing
it
is
means
that
it's
very
hard
for
us
to
in
a
reasonable
document,
say
anything
useful
about
it.
Okay,
we
certainly
can't
say
anything
normative
forget
whether
the
architecture
is
normative
or
non-normative.
C
Okay.
The
point
is
that
that
it's
outside
of
the
normative
parts
of
the
architecture,
the
part
that
we're
really
trying
to
get
commonality
on,
and
so
how
can
we
say
something
about
something
that
has
a
wide
variety
of
different
things
and
is
very
specific
to
specific
verticals,
and
that's
why
we're
reluctant
to
say
something
because
anything
we
say
someone
will
say
it's
wrong-
doesn't
apply
to
my
situation
right
or
I'm
doing
it
differently.
Is
that
okay
and
we
get
regularly
do
get
this
this
problem?
C
C
I
I
I
don't
understand
your
proposed
text
addressing
this
issue
at
all,
so
so
that
was
even
part
of
it.
I
don't
know
what
you're
trying
to
say,
but
I
understand
again
what
you're
trying
to
say
what
you're
you've
explained
to
us
is
that
you
feel
that
the
way
in
which
the
anchors
and
endorsements
and
reference
values
get
into
the
verifier
is
of
critical
importance.
It
needs
to
be
explained.
C
Okay,
well,
I
I
I
think
that
is
a.
It
is
a
really
important
thing.
It's
so
important
that
I
just
don't
think
it
fits
in
this
document
in
a
way
that
we
can
reasonably
say
something
that
is
inclusive
enough,
so
that
people
don't
go.
Oh
well,
that
doesn't
apply
to
me.
I'm
not
going
to
use
this
architecture
at
all.
Yeah.
G
Right,
I'm
not
buying
that
argument
at
all.
We
go
on
for
paragraphs
and
pages
about
nonsense
and
freshness.
So
it's.
C
Because
that's
because
that's
a
part,
a
normative
part
that
we
want
to
standardize
right.
We
want
people
to
do
this
in
one
of
four
ways:
okay,
and
we
want
the
protocols
to
actually
be
interoperable
at
that
level.
And
what
we're
saying
is
we
don't
even
think
we
have
no
hope
of
of
standardizing
the
way
in
which
key
material
gets
into
the
verifier
and
I'm
not.
C
G
A
A
I'm
sorry,
sorry,
I
would
come
back
to
dave's
proposal
that
was
very,
very
similar.
It
says
all
of
these
roles
rely
on
a
trust,
anchor
trust,
sorry,
sorry
and
they
have
trust
the
keys
or
whatever
the
key
material
has
to
be
managed,
has
to
be
carefully
established
and
also
there's
a
comment
from
you
how
to
establish
stuff,
but
we
didn't
come
to
this
today
and-
and
maybe
maybe
that
is
the
thing
that
we
have
to
prefix
this
chapter
with
that.
A
G
Well,
it
doesn't
really
get
it
because
to
me,
the
attestation
key
material
is
really
special.
It
is,
it
has
to
be
cared
for
by
the
root
of
trust
in
a
way
and
that
anastasia
key
material
really
the
whole
all
of
attestation
hinges
on
it
in
a
fundamental
way.
I
mean.
C
I
I
agree
with
you,
but
but
but
the
key
material
you
now
you
talk
jumped
into
the
private
key
material,
which
I
agree
has
a
very,
very
specific
care,
but
you
were
talking
before
about
the
public
key
material
getting
into
the
verifier,
which
has
a
different
thing.
So
actually
let
me
jump
back
here,
so
this
initial
green,
that
you
have
where
you
added
this
four
lines
of
thing.
I
I
don't
know
I
don't
have
a
big
objection
to.
C
Although
I
I
understand
the
discussion
about
dave
dave
had
what
I
really
don't
understand
is
actually
the
next
part
where
you
removed
a
bunch
of
of
of
content
or
rewrote
it
in
a
way
that
I
didn't
understand.
Okay
and
and
that's
where
I
think
we're
getting
actually
getting
into
also
problems.
People
do.
G
I'm
actually
I'm
okay
with
I'm.
Okay,
with
with
putting
that
back,
I
mean
I
was
somewhat
confused
about
it
and
some
of
the
wording
about
implicit,
trust
and
and
kind
of
I
don't
know
lack
of
examples
or
something
like
that.
But
the
the
important
thing
is
to
me
is
the
you
know
the
the
attestation
key
material,
the
sort
of
the
cycle
of
the
attestation
key
material
of
how
it
flows
between
the
attester,
the
verifier
and
the
endorser,
or
the
the
the
non-endorser
that
sometimes
exists.
G
C
D
H
We
could
use
terminal,
you
know
to
avoid
talking
about
things
in
the
negative.
You
know
the
you
know,
musician,
formerly
known,
as
you
know,
whatever
we
could,
you
can
say
that
you
know
the
verifier
is
owned
by
the
endorser
and
the
tester
is
owned
by
the
endorser
and
they
the
endorser
provision.
You
know
the
trust
anchors
in
such
a
way
that
there
isn't
a
question
about
who
trusts
who
so.
D
J
D
C
So
so
it
isn't,
it
isn't.
Okay,
actually,
so.
C
So
so
I
I
want
to
quibble
about
your
comment
about
provision
in
the
endorsers,
not
in
two
in
general,
in
the
case
where
the
iot
device
generated
its
own
key
pair
at
the
factory.
I
still
think
of
that
as
provisioning,
a
key
in
my
mind
because
it
has
to
communicate
securely.
The
public
key
is
extracted
still
a
protective
process.
So
so
that's
a
quibble
about
the
terminology
where
I
actually
think
provision
is
actually
the
right
word
and
and
lawrence
is
used.
Okay,
but
I
want
to.
C
C
It
I
actually
I'm
agreeing
with
you,
okay,
so
the
process,
the
the
process
of
of
provisioning,
private
key
material,
and
I'm
I'm
going
to
stick
with
that
term,
whether
it's
self-generated
or
or
factory
generated
or
whatever,
that
process
of
provisioning,
the
private
key
material
into
the
device
is,
is
some
is
conceptually
different
than
the
process
of
provisioning
trust
anchors
into
whatever
okay
and
the
trust
anchor
store
and
and
and-
and
it
has
to
do
with
the
fact
that
it's
okay,
if
the
trust
anchor
store
is
is
is,
is
revealed
all
along
its
process.
C
It
doesn't
break
the
security,
it
may
break
the
privacy,
but
it
doesn't
break
the
security
right
and
and-
and
I
think,
of
the
verifier
and
the
specifically
the
verifier
as
something
that's
probably
provisioned
by
downloading
a
signed
blob
from
something
or
uploading,
a
floppy
disk
or
whatever
kind
of
thing,
whereas
it
it's
it's,
it's
a
different
skill
set
and
different
environment
for
the
tester.
C
It's
something
that
that
you
know
you,
like
literally
may
be
blowing
fuses
on
the
device,
and-
and
that's
it's
just
it's
just
it's
just
because
it's
it-
it
is
a
different
process.
We
can
do
many
different
things
in
a
different
way
and
it
could
have
different
security
considerations
to
it.
So
that's
all
I'm
trying
to
say
so.
C
So
I
I
guess
I
understand
that
I
I
think
that
that
lawrence
is
trying
to
to
to
bring
the
circle
all
the
way
around,
so
that
we
can
see
that
the
trust
relationship
starts
with
the
manufacturer
and
ends
with
the
manufacturer,
because
everyone
else
has
a
circle
to
it.
That's
what
I
think
he's
trying
to
do.
Yes,.
A
C
With
you
that
the
text
is
not
working
for
this
and
and
and
maybe
the
word
provision
is
totally
wrong.
So
the
word.
D
C
Into
is
provisioned,
and
just
you
know
so
it's
provisioned
by
the
endorser.
That's
enough
right.
You
remove
that
and
you're.
Maybe
everyone's
happy.
Would
that
actually
make
you
happy
dave?
No.
D
No,
no,
because
in
the
definition
of
the
attesture
I
mentioned
there
might
not
be
an
endorser
so
by
the
endorser
is
also
wrong.
C
Okay,
we're
trying
to
cover
so
many
different
permutations
of
this
that
we
wind
up
having
slashes
and
blah
blah
blah
all
over
the
place
and.
C
D
A
C
Yeah-
and
I
actually
think
that
that
we're
wasting
our
time
quibbling
over
this,
because
one
of
the
isg
reviewers
will
tell
us
that
we
have
to
write
it
differently
and
because
something
or
other,
so
I
just
think
we
should
just
say
we
should
just
say
we're
it's
good
enough
for
the
moment
and
ship
it
and
and
come
back
to
it
in
three
months,
because
that's
what's
going
to
happen
anyway.
H
H
C
I'm
lawrence,
I
will
try
to
write
something
different,
okay
and
I'll,
see
what
you
like:
okay,
okay,.
G
The
system
examples
is
also
really
helps
remedy
this
for
me,
and
I
I
wanted
to
get
some
consensus
of
you
know
whether
you're,
but
whether
we're
okay
with
adding
those
or
not
I
mean
the
the
stuff
I
put
in
there
was.
There
was
just
a
rough
example
or
a
rough
first
set
of
examples.
I
think
more
can
be
added
and
they
can
be
improved
a
lot,
but
it
was
really
intended
to
to
help
make
it
make
the
make
it.
G
G
C
C
Here's,
how
the
rats
architecture
is
applied
to
the
case
of
blah
blah
blah.
Okay,
and
I
would
go
you
know
it's
it's
it's
where
I
thought
the
use
case
document
might
go,
but
I
don't
actually
have
probably
the
knowledge
to
to
write
that
for
a
number
of
cases.
I
think
you
should
be
as
specific
as
you
can
in
the
system.
In
the
examples,
don't
call
them
examples,
call
them
applicability
statements,
ietf,
loves
to
publish
applicability
statements
but
hates
probably
to
publish
use
cases.
C
So
that's
where
I
would
go
with
this
lawrence
and
given
that
it's
non-normative
text
in
the
architecture,
I
actually
think
that
that
would
have
a
bigger
impact
as
a
separate
document.
G
G
I
I
just
find
the
architecture
document
really
really
hard
to
understand
for
the
for
the
true
remote
cases
because
of
the
wording
and
the
way,
the
key
flows
and
all
I
find
that
really
the
architecture
document
really
hard
to
understand,
because
it's
so
abstract
and
yeah.
That's.
C
Right,
it's
it's
abstract
and
that's
that's
the
that's!
The
problem
we're
dealing
with
is
that
we're
trying
to
write
a
document
that
covers
a
whole
bunch
of
cases,
and
so
we
can't
every
time
we
get
specific
we
get
into
oh,
but
no
that
doesn't
apply
to
that
case.
Well,
let's
write
out
that
case.
Yeah.
G
Okay,
I
think
the
big
problem
here
is
is
the
preconceived
notion
of
an
endorsement
that
everybody
thinks
an
endorsement
is
something
and
and
that
that
doesn't
fit,
that
that's
where
the
the
big
problem
is
for
me.
But
anyway,
let's
I'll
think
about
it
as
a
separate
document.
But.
A
Okay,
you're
not
alone
in
this.
We
can
help
you
with
this
and
there's
something
that
a
lot
of
people
are
motivated
to
help
you
here
and
do
you
just
want
to
do
one
of
our
reasons
yeah?
We
have
to
we
get
this
out
to
the
isc
at
some
point,
and
I
think
this
is
a
bigger
construction
site
that
we
can
take
on
at
the
moment,
and
there
is,
but
I'm
not,
I'm
not
neutral
on
the
separation,
but
I'm
I'm
very
positive
on
the.
We
will
help
you
with
this
and
we
make
this
good.