►
From YouTube: RATS Architecture Design Team, 2020-06-09
Description
RATS Architecture Design Team, 2020-06-09
A
C
E
A
G
A
C
So
this
is
Hank
speaking
for
Thomas
and
Hank
I
think
we
agreed
to
create
something
based
on
your
comments
day
for
the
PR
90
and
blind,
that's
87
and
but
maybe
sure
it's
99.
So
many
freshness
thing
is
yeah,
but
sorry,
so
we
have
not
progressed
on
that.
So
we
can
skip
if
there's
no,
no
really
hard
I.
A
C
You
know
she
brought
two
emails
with
a
lot
of
issues
so
to
speak,
so
I
have
to
ask
in
this
group.
How
do
we
want
to
address
these
I've
wrote
a
preliminary
answer
that
was
just
Hank,
so
that's
not
a
normative
representative
answer
yeah,
and
so
we
have
to
either
I,
don't
know
a
segregates
editorials
from
content
and
then
create
issues
here
or
go
through
the
email.
Maybe
it's
a
redundant
work
to
create
separate
issues
for
what
she
has
issues
in
her
email.
That
might
just
be
a
waste
of
time.
C
A
I
will
suggest
two
things:
the
convention
that
I
have
followed
in
other
working
groups.
Let
t
pour
whatever
is
the
things
that
are
technical
I,
would
file
a
issue
on
the
things
that
are
editorial
either.
I
would
just
address
them
in
a
request
to
not
file
an
issue
or
if
we
think
it's
gonna
take
a
while.
C
A
A
A
C
C
C
A
A
Yeah
I
don't
know
yet
how
his
sir
actionable
at
all,
except
here
he
suggests
something
that
I
don't
think.
We
agree
in
I
think
it's
I
think
and
I
have
the
sense
based
on
our
decent
attendance
from
these
meetings
and
our
previous
presentations
to
rats
that
we
do
have
working
group
consensus
on
terms
like
you
know,
evident
at
the
stationers
olds
and
dot
dot.
So
on.
A
Suggests
is
one
that
would
go
against
what
we
believe
is
working
for
consensus.
Yes,
correct.
Certainly
the
design
team,
that's
consensus,
but
design
team
consensus
doesn't
matter
we're
working
group
consensus.
We
believe
it's
not
consistent
with
here's
a
unnecessarily
hard
to
read
and
understand
it
doesn't
make
any
actionable
ways
to
improve
that.
So.
D
So
I
mean
I,
I,
think
I
mean
I,
think
there's
a
few
areas.
I
would
like
to
see
simplified,
but
I
generally
agree
with
the
you
know,
evidence
and
verifier
and
result,
and
all
that
and
and
I
do
think
some
of
the
text
is
got
really
long
sentences
that
are
really
hard
to
come
to
to
read
and
understand
so
I
mean
I.
I.
Think
this
you
just
do
something
about
them
that
I
find
them.
You
know,
I,
don't
know
how
to
do
that.
But
that's
been
that's
been
an
issue
with
this
document.
All
along.
C
Has
to
be
applied
at
some
point
thoroughly
and
we
have
to
cut
complicated
sentence
up
and
make
it
very
more
readable
if
people
really
can
actually
not
who
can
have
multiple
interpretation
of
the
same
sex.
That
would
be
bad
so
and
convoluted
text
sometimes
I'm.
Writing
this
Roman
sentences.
I
know
some
somehow
I
am
pretty
sure
about
that.
So
yes,
but
that
isn't
it
it's
for
real
thing,
I
think
it's
not
like.
A
If
you,
if
you
mentioned
like
a
specific
paragraph
or
even
a
specific
section
or
something
or
rather
than
just
the
document,
it
would
be
easier,
so
I
guess
maybe
we
can
follow
up,
because
I
sounds
like
what
we're
summarizing
is
we
agree
that
we
believe
that
the
terms
are
important
and
that
the
work?
We
believe
that
the
working
group
thinks
so
too
and
if
he
can
call
out
any
specific
paragraphs
or
sections
that
he
thinks
are
hard
to
read,
then
we,
the
editors,
can
work
on
some
editorial
changes
to
try
to
clean
up
those
things.
C
G
A
A
A
This
one
might
have
come
from
me
too,
but
I
think
I
was
the
only
person.
I,
don't
know
if
this
one
was
actually
in
Michaels
document
before
I
provided
some
text
on
it,
but
I
think
I
provided
the
text
that's
in
there
right
now,
but
I
was
using
information
from
people
at
my
company,
but
also
I,
don't
think
I'd
heard
about
it.
First
from
them,
I
was
a
hired
about
it.
A
A
The
case
that
I'm
familiar
with
and
I
believe
it
was
a
company
called
sequitur
labs
that
has
ARM
based
products
and
they
use
at
EE
and
they
monitor
code
pages
in
the
rich
execution
side,
kernel
figures
and
data
pages,
and
if
they
see
a
change
in
those
pages
that
aren't
supposed
to
be
changed,
then
they
will
immediately
reboot
the
Machine
and
reflash
the
kernel
and
stuff.
So
basically
they
reject
the
te
is
watching
the
REE
for
sanity
checking
anything
that
should
get
that
could
go
wrong.
That's.
A
That's
I,
don't
remember
that
might
not
have
to
look
back
at
the
fish
in
this
section.
I'm
just
saying
this
term
Hardware
watchdog
is
where
I've
heard
them
and
they
maybe
there's
not
the
right
term
or
whatever
I
have
to
go
back
and
see
what
section
3.6
says
like
I
said
I'd,
it
might
be
combining
a
couple
concepts.
So
I,
don't
I,
don't
think
anything.
C
C
C
A
D
I'd
like
to
do
is
I'd
like
to
try
to
understand
what
everybody
thinks
endorsements
are
I,
don't
have
a
very
clear
picture.
What
the
consensus
are
on
endorsements,
so
I'd
like
to
ask
some
questions
and
get
some
answers
from
the
understand
the
consensus
here,
not
so
much
about
going
over
the
the
PR,
but
just
and
then
I'll
take
another
shot
at
the
PR.
D
Yeah
good,
thank
you,
so
I'm
gonna
jump
in
for
it
first
of
all
the
key
material.
So
my
understanding
is
that
verifier
has
to
have
key
material
to
verify
the
signature
or
somehow
verify
the
secure
conveyance
of
the
evidence
that
that
key
material
has
to
come
comes
through
an
endorsement
is.
A
It
typically
comes
from
endorsement,
but
it
does
not
need
you,
okay,
so
it
could
be.
It
could
be
individually
set
up
with
each
a
tester
to
the
verifier.
If
you
think
about
like
a
baker
right,
so
the
maker
doesn't
have
a
separate
manufacturer
right,
they
may
be
running
your
own
verifier
and
they
individually
pair
be
a
tester
and
the
verifier
at
the
time
they
put
the
little
gadget
together,
and
so
there's
not
a
many
separate
endorser
in
that
sense
and
or
smus
they're.
Just
you
know
optional.
That
is
a
particular
trivial
use
case.
A
D
D
I,
don't
want
to
ask
that
question
what
I,
what
I
believe
is
somehow
in
an
architecture
diagram
the
fact
that
key
material
goes
into
the
verifier
has
to
be
shown
in
the
architecture
diagram.
There
has
to
be
one
of
those
two
arrows
either
endorsements
or
phrasal
policy.
They
don't
those
the
only
two
arrows
that
go
into
the
verifier.
One
of
those
two
has
to
have
the
key
material.
Okay,.
A
C
C
A
Their
general
basin,
in
the
general
case
and
not
be
a
service,
absolutely
does
not
need
to
be.
It
is
typical
for
scalability,
where
it's
a
service,
but
that's
under
my
definition,
if
you
guys
have
different
affinities,
let
me
know
I'm
going
to
make
sure
that
we're
expensive
too
many
different
variations.
C
A
Like
the
text,
which
there's
no
an
endorser,
is
typically
a
manufacturer,
and
you
know
as
long
as
you
said,
where
typically
I
think
it's
true,
because
that
is
the
typical
case
right,
where
it's
a
service
and
it's
about
your
facture
and
so
on,
but
there's
other
ways
to
do
it,
and
so
we
don't
want
to
do
it.
My
way
of
constraint,
that's
my
opinion.
C
D
Yeah
I
mean
so
the
general
that
the
general
rule
is
that
that
key
material
has
to
get
into
the
verifier
in
how
does
the
key
material
get
into
the
verifier?
If
it's
not
an
endorsement
so
anyway,
that
key
material
going
going
into
the
verifier?
That's
an
endorsement.
So
we,
if
you
won't,
have
a
say
if
you
don't
like
it,
because
it
conflicts
with
the
TCG
definition
of
endorsement,
then
drawn
will
bite
in
and
say
yes
comes
in
there.
K
Isn't
there
isn't
a
TCG
definition
of
endorsement?
In
fact,
the
TCG
are
considering
using
the
term
endorsement
because
the
ITF
is
using
it
in
this
double
ground.
That's
really.
What
really
I
think
is
we're
trying
to
talk
about
is
how
did
the
trust
relationships
between
the
various
roles
get
set
up
and
an
endorser?
The
verifier
needs
to
trust
the
endorse,
or
it
needs
to
trust
the
verifier
owner.
The
relying
party
needs
to
trust
the
verifier
right.
D
K
You
you
allow
for
the
kids
with
no
certificate
right.
I,
understand
that
there's
the
case
for
the
certificate,
but
we're
talking
about
trust
and
I'm
using
okay
is
an
example
for
how
trust
relationships
get
established
using
asymmetric
cryptography
and
there
can
be
equivalent
to
that,
obviously
with
symmetric,
cryptography
and
whatever,
and
you
know
raw
Rockies
and
all
that
you
know.
If
you
want
to
enumerate
all
of
them.
K
C
Where
is
this
young
trust
anchor
ID
and
they
basically
highlight
a
lot
of
cases,
so
there
could
be
a
good
example
for
us
to
refer
to
because
the
PKI
certificate
the
same
as
blob
and
even
the
SSH,
a
public
key
is
referred
to
as
a
trust
anchor
there
and
therefore
it
is
a
little
bit
of
a
different
scope.
Maybe
we
don't
have
to
use
the
term
trust.
Actually,
Mike
can
refer
to
all
these
examples.
C
We
don't
have
to
restate
them
here,
but
I
think
it's
a
good
set
and
at
Laurence
I
think
it
addresses
your
concern
that
a
you
have
this
key.
That
is
you
that
we
have.
It
means
something,
and
that
is
a
cap
shot
in
the
a
truss
anchor
work
in
that
conf.
So
maybe
you
have
a
look
at
that
and
if
you
like
it,
maybe
you
can
just
refer
it
that
we
stayed
everything.
People
would
be
couple
four
years
so.
A
The
whole
point
is
the
channel
to
the
endorser,
or
typically
the
endorsement
itself
assigned
by
a
key
that
it
needs
to
trust
okay,
and
so
how
did
you
configure
that
thing?
That
is
the
trust
anchor
right.
It
would
be
the
key
of
the
you
know:
the
the
public
key
of
the
endorser,
for
example
right,
and
so
what
is
your
public
key
of
endorser?
Is
your
trust
anchor
there?
My
point
about
saying
the
endorser
may
not
exist
is
when
your
trust
anchor
is
just
your
entrust.
A
Anchor
and
list
is
just
a
set
of
the
keys
of
each
in
tester
individually.
That's
the
trivial
case
where,
like
a
maker
might
use,
but
for
scalability
you
want
an
extra
layer
of
indirection
there.
So
you
can
have
you
know
thousands
of
keys
of
testers
that
are
all
signed
by
the
same
manufacturer.
You
can
only
do
one
thing
in
my
trust
anchor
to
manage
right.
That's
a
scalability
point
that
was
making,
but
you're
still
gonna
trust
anchor.
How
do
I
configure
the
endorsers
key
right,
you're,
not
using
a
service
to
do
that?
A
Your
your
configuring,
it
somehow
whether
it's
a
manufacturing
time,
provisioning
time,
whatever
the
verifier
has
to
have-
has
to
have
a
way
of
managing
its
trust.
Anchors
being
you
know,
endorse
your
key,
its
verify
your
owner
key,
that
type
of
thing
or
a
set
of
them
and
the
ability
to
keep
them
up
to
date,
if
you
Rev
the
keys
and
so
on.
A
K
A
A
K
A
D
Sometimes
this
one
level
of
indirection
and
sometimes
and
could
be
all
kinds
of
combinations,
and
it
seems
in
an
architecture
in
architecture
I,
would
prefer
to
say
somehow
via
one
of
these
mechanisms
either
you
know
bare
keys
or
what's
complicated.
X.509
are
key.
You've
ever
seen,
somehow
the
key
material
gets
into
the
verifier
and
and
and
it
because
it's
so
fundamental
to
rats
architecture.
When.
A
D
D
H
J
A
F
Try
to
incorporate
all
these
different
kinds
of
ideas,
of
establishing
trust
on
it,
because
that
really
is
a
question
of
the
approach
and
what
mechanism
is
used
to
do
that
appraisal
for
whatever
particular
kind
of
evidence?
Is
there
whether
or
not
you
trust
that
evidence
through
some
other
claim,
or
some
implicit
claim
in
terms
of
an
encryption
is
really
in
the
eye
of
the
appraiser
itself
and
all
the
mechanisms
that
the
verifier
uses,
whether
it's
a
cryptographic
mechanism
or
an
actual
appraisal
method?
There
has
to
be
a
way
they
get
those
in
there,
but
I.
E
A
With
you,
Peter
I
think
we
don't
want
too
much
detail
there
because
it
could
be
heterogeneous
and
the
actual
details
of
those
lines
are
out
scope
for
arrest
right.
You
just
have
to
have
such
a
line.
I
think
it's
efficient
because
a
yeah,
so
whether
it's
symmetric
or
asymmetric
or
anything
else,
it
doesn't
matter
at
this
level
of
thing.
So
yeah
I
agree
with
your
point.
Peter
yeah
me
too
needs
to
allow
for
that
full
range
of
it
and
somehow
it
doesn't
have
to
go
in
any
details
about
it.
Yep.
Absolutely.
A
A
There's
some
border,
it's
like
if
you
find
some
Texas
stealable
out
of
a
yang
document
that
can
be
thrown
in
a
security
consideration
section
where
we
already
talked
about
how
the
verifier
trusts.
Other
things.
That's
fine,
if
not
my
opinion
is
the
current
Texas
efficient.
But
if
you
find
some
text
that
you
think
is
good,
then
I
have
no
objections.
If
we
want
to
discuss
bringing
something
else
into
so
a
point.
F
That
may
need
to
be
made,
though,
is
that
there
is
a
relationship
between
the
ax
tester
and
the
verifier
when
it
comes
to
the
mechanisms
being
used.
And
the
point
really
is
that
that
there
has
to
be
a
corresponding
set
of
mechanisms
on
both
sides
that
allow
to
identify
what
you
expect
out
of
that
particular
evidence
presentation
and
if
that's
cryptographic,
then
there
needs
to
be
a
means
to
establish
that
cryptographic,
relationship.
A
D
A
F
Is
just
this
kind
of
issue?
Is
that,
regardless
of
the
reason
why
your
policy,
whether
it's
in
a
testing
policy
or
an
appraisal
policy,
wants
to
choose
a
different
mechanism?
The
mechanism
has
to
be
actually
chosen
so
that
it
has
the
right,
semantics
and
syntax
to
present
evidence
and
then
interpret
it
properly.
A
Ok,
the
key
mature
used
to
authenticate
integrity
to
protect
the
conveyance
channel.
Okay,
this
is
the
unprotected
text.
That's
not
the
main
text.
I
guess
this
is
the
main
text
about
the
verifier
trusts,
the
manufacturer
or
the
manufactures
hardware.
So
this
could
be
more
clear
about
saying
trust.
The
endorser,
because
this
says
it's
a
manufacturer
and
the
endorser
is
only
typically
manufactured.
K
K
A
Manufacturer
I,
like
this
phrase
right
just
like
we
take
typically
typically,
that's
all
great.
So
yes,
the
term
endorser
is
there,
but
the
section
seven
go
back
to
section
seven
here,
I
think
section:
7
was
inconsistent
where
it
says
pretty
agree
where
it
says
here,
a
manufacturer.
They,
because
it's
a
it's
only
typically
manufacturer
so
I
believe
that
they
should
say
it
trusts
an
endorser,
yeah
and
yet
to
whoever
just
matter.
Whoever
just
said
yes,
endorsers,
a
okay,
so
yeah.
We
need
to
make
this
fix
here
for
consistency.
A
D
A
My
opinion
is
at
least
under
your
definition
of
key
material
I
think
you
talked
about
at
least
what
I
understand.
What
you
mean
by
keep
make
sure
it
always
has
endorsements,
always
have
key
material,
but
key
material
don't
have
to
come
through
an
endorsement.
Now
it
would
be
okay.
If
you
wanted
to
call
an
endorsement,
you
can
manually
configure
a
key.
Maybe
you
want
to
call
that
an
endorsement.
That's
okay
with
me
too!
So.
A
A
Is
so
I'm
gonna
repeat
back
what
I
think
is
your
position
right?
Your
position
is
okay,
let's
take
my
special
case
and
that
describe
how
I
think
that
you're
saying
that
you
want
at
the
language
to
apply
in
the
special
case
where
you
don't
have
a
separate,
endorser
right,
you're,
just
putting
each
of
your
three
attest,
errs
keys
in
your
trust,
anchor
list
right
then
you're
saying
the
ability
to
configure
the
ax
tester
is
key
into
the
trust
anchor
list.
You
would
call
the
endorsement
yeah.
A
D
K
K
But
we
did
sort
of
we
did
sort
of
say
that
early
on,
we
said
so
that
in
one
of
the
very
first
iterations
of
the
architecture,
we
had
a
whole
section
that
was
focused
on
managing
trust,
and
you
know
configuring
trust
anchored
over
well
back
from
the
root
was
no.
We
don't
need
to
put
all
that
in
an
architecture
spec.
We
can
good
enough
with
yeah.
We
all.
D
And
very
unique
to
do
to
rats
the
relationship
between
the
and
that
key
material,
and
all
that
is
it's
it's.
It's
like
the
absolute
core
of
rats,
so
I.
Don't
think
that
that's.
The
same
is
true
like
for
the
relationship
between
the
verifier
and
the
relying
party
or
the
verify
our
owner
and
the
and
the
verifier.
Those
are
just
standard,
IT
practices
and
they're
not
specific
to
rats
they,
but
that
key
key
relationship
between
the
ax
tester
and
the
verifier
I
think
is
and
and
I
think
it
needs
to
be
made
explicit.
I
still.
A
K
K
E
Can
I
check
one
one,
one
point:
if
we're,
if
we're
talking
about
like,
what's
specific
kind
of
to
a
remote
at
a
station
versus
kind
of
more
traditional
things
where
trust
anchors
are
used,
but
it
seems
both
the
line
of
evidence
in
and
at
the
station
results
out
of
the
verifier
are
in
that
space
and
and
the
issue
I
brought
up
filed
in
the
in
there
in
the
in
github,
is
there's
so
for
there's.
There's
trust
of
the
key
and
there's
trust
of
handling
of
the
key.
E
So,
for
example,
the
relying
party
may
say
gets
it
signed
at
the
station
results
and
its
trust
of
that
signing
key
may
be
both
a
combination
of
the
key
and
the
handling
of
the
key.
The
handling
of
the
key
may
be
verified
or
proven
by
yet
another
at
the
station
by
by
evidence
that,
from
from
the
attested
by
the
verifier
functioning
as
an
a
tester,
also
in
providing
evidence
as
to
its
handling
of
that
key
material.
E
K
So
there
has
been
discussion
about
the
idea
that
we
could
use
attestation
to
augment
trust
anchor
management,
automated
trust
anchor
management,
so
that
we
can
have
some
trust
context
for
for
that
management
and
that
attestation,
that
that
would
be
in
a
use
case
of
attestation.
I
agree
with
that.
Guy
green.
It.
A
15
minutes
left
in
the
call
and
there's
another
aspect,
I
think
of
what
Laurence's
PR
raise.
There's
a
second
part
and
a
second
question
that
I
think
would
be
useful
for
us
to
discuss
right
because
Laurent,
you
start
off
by
saying:
hey
what
do
people
think
an
endorsement
is
and
West's
relationship
for
the
key
material.
There's
another
part
of
that
discussion,
which
I
think
we
did
have
before
and
we
might
be
revisiting
it.
A
A
D
Me,
let
me
say
what
I
was
what
I
was
after,
so
no
good
values
can
come
through
endorsements
or
through
appraisal
policy
and
either
one
that's
all
fine,
and
all
that,
but
I
believe
there's
another
case
going
on
here.
Where
things
come
into
the
verifier
from
the
endorser.
Probably
an
endorsement
and
they're
not
known
good
values,
they
are
implied
or
implicit
claims
that
are
just
stuck
into
the
attestation
result:
they've
their
pipe
piped
through
the
verifier.
D
The
the
verifier
knows
that
the
it
can
do
that
because
the
it
established
the
trust
relationship
with
the
adjuster
and
knows
the
identity
of
the
attest
ur.
So
these
are
just
in
this,
and
these
are
claims
that
are
passed
on
to
the
relying
party
for
the
relying
party
to
make
the
decision.
So
relying
party
may
decide
to
like
the
the
identity
of
the
manufacturer,
may
come
through
an
endorsement,
and
the
relying
party
wants
to
make
a
decision
based
on
the
identity
of
the
manufacturer.
D
C
Something
about
this,
it's
like
the
on
behalf
its
texts
it
was
scrapped
already
there
was
on
claims
on
behalf
of
the
attesa,
so
the
attesa
doesn't
bring
them
with
it
in
evidence,
but
because
there
are
some
now
a
trust
relationship
with
the
ax
tester,
you
can
have
some
implied
claims
on
behalf
of
the
others
that
come
from
the
outside
I
think
that
text
was
scrapped.
What
I
think
that
is
something
you
are
referring
to
right
now
allowance
is
that
correct,
yeah.
K
K
In
other
words,
the
a
tester
doesn't
have
to
say
the
same
thing,
because
it
never
changes
in
the
endorser
can
say
it
directly
to
the
verifier
and
because
of
the
trust
establishment
between
the
endorsement
verify
they'e
verifier
accepts
that
without
having
to
cross-check
it
with
evidence
and
there's
really
no
point
in
doing
that,
because
it's
invariant,
and
so
it's
never
gonna
change.
So
there's
really
no
point
in
it.
It.
A
Could
change
III
want
to
give
my
answer,
but
first
I'm
gonna
get
the
rationale
for
my
answer
and
then
I'll
get
to
my
answer.
If
and
the
analogy
that
I'm
gonna
give
us
two
layered
attestation
right
and
so
we're
at
the
station,
then
at
the
root
of
the
ax
tester,
you
have
an
attesting
and
pyramid
right.
You
have
a
testing
environment
and
a
target
environment
right
and
all
an
endorser
is,
is
it's
analogous
to
being
in
a
testing
environment
for
the
bottom
of
the
attest
er
as
the
target
environment?
A
And
so,
if
I
go
back
to
this
picture
here
and
because
we
said
these
environments
in
some
senses
could
even
be
on
different
chips
or
devices
right.
So
all
the
differences
pretend
that
this
box
in
the
middle
here
is
the
ax
tester,
or
at
least
the
bottom
of
the
attest
er
right.
So
if
this
and
up
was
the
attest
er,
this
right
here
is
equivalent
to
an
endorser
right,
and
this
piece
coming
up
was
actually
an
endorsement
right.
A
It's
the
thing
that
signs
claims
about
the
target
environment,
which
is
the
attesting
environment,
enya,
texture,
right,
and
so
in
that
sense,
these
claims
are
just
the
same
as
just
an
evidence
in
any
other,
a
testing
environment
right.
The
endorser
is
just
a
testing
environment
who
did
the
attesting
and
manufacture
time
and
in
one
example
it
right
if
they
never
changed
and,
of
course
you
can
keep
resupplying
the
evidence
and
it
never
expires
because
it
burned
into
hardware
ROM
or
whatever.
It
is
right.
A
That's
just
a
special
case
right,
but
to
me
claims
in
a
in
an
endorsement
is
no
different
from
these
claims.
Here,
it's
just
claiming
information
like
oh,
the
the
manufacturer
value
of
the
target
environment,
which
is
the
testing
environment,
is
such-and-such
right.
The
model
number
is
whatever
those
are
perfectly
valid,
because
they
would
have
been
valid
in
iniative.
You
look
in
the
if
I
forget
the
endorsement
for
a
second
I'm
looking
at
layered
attestation
and
a
testing
environment
could
have
similar
claims
about
any
target
environments
right.
The
evidence
for
P
could
include
things
like
that.
A
Right
who
wrote
the
software
for
target
environment
B
could
be
a
claim
in
here,
as
measured
by
a
testing
environment
a
that
would
be
possible
to
me
an
endorsement
is
no
different
than
an
evidence.
The
only
difference
is
the
attesting
environment
here
happens
to
typically
be
a
manufacturer
way
off
somewhere.
I
can
a
service,
and
this
first
leg
here
is
across
a
protocol
rather
than
inside
of
a
device
right.
But
that's
how
I
look
at
claims
in
the
endorsement
and
that's.
D
A
A
So,
and
you
said
this,
when
you
introduce
this
Lawrence
is
it
is
possible
for
known
good
values
to
come
from
an
endorser?
Sorry
from
a
manufacturer?
Let
me
put
it
that
way:
we're
endorsements
come
and
reference
values.
Nobody
values
come
in
addition
to
the
things
that
are
called
endorsements
being
acclaim,
so
that's
provided
separately
even
in
the
same
conveyance
protocol,
and
that
just
comes
in
gets
union
with
the
appraisal
policy
for
evidence,
and
you
kind
of
mentioned
that
coming
and
it
says,
okay,
the
approach
of
policy
for
evidence
could
come
across
multiple
sources
right.
A
K
And
I
think
I
just
wanted.
You
know
I
think
that
the
the
term
reference
value
is
implying
that
there
is
some
sort
of
a
check
between
two
values:
referenced
about
human,
an
actual
value,
that's
different
from
a
set
of
endorsements
that
wouldn't
fit
as
where
the
term
reference
wouldn't
necessarily
fit,
because
the
there
isn't
a
corresponding
actual
value
versus
airily
right.
Okay,.
A
Give
an
example
personally,
when
it
yeah
try,
say
two
things.
One
example
is
where
appraisal
policy,
comparing
a
value
of
claim,
a
against
value
of
claim.
That's
an
example.
There's
no
reference
value.
Another
example.
Sort
of
in-between
is
where
you're
comparing
it
for
it's,
not
a
known
good
value,
it's
a
known,
bad
value,
so,
for
example,
an
expiration
time
right
when
the
time
stamp
equals
this.
A
K
A
Me
when
I
use
the
term
endorsements
I
so
far
in
the
working
group
in
the
past,
I
have
typically
used
the
term
endorsement
to
refer
to
data
that
is
specific
to
an
ax
tester,
and
so
it
could
be
multiple
as
testers
have
the
same
data
like
what's
the
manufacturer
name
and
so
on.
But
it
is
specifically
saying
this
key.
You
know
this.
A
tester
key
has
this
particular
annular,
and
so,
if
this
model
number
has
a
known
good
value
for
property,
X
of
1
2
3
right,
that's
not
something
specific!
A
K
D
A
D
A
C
A
F
That
would
be
that,
and
that
goes
from
everything
from
a
key
that
can
be
used
to
verify
the
claims
of
a
unencrypted
evidence
from
the
tester
other
testing
things
from
other
environments
or
things
like
the
the
values
that
were
put
in
and
and
that,
in
my
mind,
takes
care
of
that
whole
endorsement
line.
It
doesn't
quite
get
everything,
and
some
of
you
have
to
look
over
to
that
appraisal
policy
line,
and
there
are
some
things
like
known:
good
values
that
are
really
particular
to
the
appraisal
policy,
for
instance,
that
PCR
value.