►
From YouTube: RATS Architecture Design Team, 2020-06-26
Description
RATS Architecture Design Team, 2020-06-26
A
B
A
E
A
Dave
yet
and
there's
a
couple
other
regular
suspects,
ned
that
I
don't
see
yet
so
I'm
not
jumping
up
and
down
to
start,
but
let's,
let's,
let's,
let's,
let's
start
on
some
stuff.
So
one
of
the
items
that
I
think
was
open
last
time
was
the
hardware
watchdog,
we're
gonna
we're
gonna,
give
people
a
chance
to
read
it.
A
A
A
F
A
F
F
So
I
think,
of
course,
yes,
it
is.
This
is
a
little
bit
aligned
with
hannes's
comment.
Do
we
really
need
all
this
and
I
think
dave
and
some
other
participants
established
last
time?
Yes,
that
we
need
that,
but
this
is
a
comment
because
it
was
in
kathleen's
list
of
first
batch
of
yeah
basically
feedback,
so
it's
here,
but
if
it's
not
contested,
I
would
still
assume
that
this
is
needed
and
therefore
the
answer
is
yes.
A
F
F
F
F
So
the
thing
is
that
he
said
that
everything
that
is
associated
with
the
timestamp
here
is
at
some
point
conveyed
over
the
wire
or
the
internet
or
whatever,
and
that
is
effectively
not
the
case
because
at
the
very
least
value
generation
is
not,
and
so
because
only
it
processed
internally,
it's
also
only
processed
internally,
but
without
him
I'm
not
sure
we
can
move
this
forward.
Actually.
E
Oh
yeah
yeah,
absolutely
you
know
when
you
have
a
central
time
generation
or
a
key
that
can't
be
distributed
until
a
certain
time.
So
this
is
similar
to
tuta,
but
just
the
idea
that
the
attester
can't
become
aware
of
something
because
they
don't
have
any
possible
way
to
get
the
nonce
until
a
certain
date
or
a
certain
time.
F
F
F
Seems
weird
yeah,
so
I
think
I
think
that
is
something
yeah.
So,
for
example,
I
think
also
evidence
relate
is
not
the
terminology
we
use.
I
think
it's
evidence
conveyed,
but
these
are
myths.
These
are
other.
I
think
there
should
be
another
editorial
pass
over
the
table
that
fixes
the
description
language
by
not
altering
its
meaning
and
also
the
names
here
event
names.
That
is
all
not
to
the
point
here
right
now.
I
think
it
is
more
about
the
contested
contentious
content.
F
A
A
A
F
A
F
A
F
F
A
H
G
A
I
I
really
don't
quite
understand
the
problem
in
the
first
place,
so
I
think
that
the
point
was
that
the
attester
can't
cover
the
case
where
the
relying
party
sends
the
nods-
and
he
says
you're
right-
it's
not
limited
to
the
attester,
but
the
solution
doesn't
seem
to
be
right,
so
he's
offering
us
two
solutions
and
might
be
suitable.
For
example,
in
the
case
the
attester
does
not
have
does
not
have.
I
guess,
then
it
goes
to
relying
have
a
reliable
clock.
H
F
A
Most
right,
so
so
it's
just
puts
in
the
the
the
first
point
is
we
just
put
in,
for
example,
I
I
understand
that
now
it's
very
hard
for
me
to
see
that
that's
all
he
did
on
there.
The
second
phrase
where
it
says
solely
on
the
praising
it
either
verifier
or
evidence
solely
on
the
remote
attestation
protocol
initiator,
so
he's
suggesting
that
instead
of
saying
the
the
verifier
that
we
have
to
say
this,
and
I
think
it's
not
an
improvement.
A
F
H
F
G
F
A
A
A
A
A
B
A
I
A
I
I
guess
I
get
confused
by
this.
My
michael,
why
are
these?
If
so,
would
is
so?
Would
the
verifier
create
an
attestation
on
behalf
of
its
own
security
state
and
just
happened
to
append
the
attestation
evidence,
along
with
it
or
just
be
carrying
devastation
evidence,
as
kind
of
like
a
a
blob,
a
an
opaque
payload,
fully
signed
and
on
to
the
relying
party
you
know,
for
you
know
as
part
of
this,
it
wasn't
really
clear
to
me:
what
was
the
intention?
B
D
B
I
I
was
looking.
I
was
essentially
looking
for
a
little
more
ammunition
before
I
went
to
eat
I
wanted.
I
was
looking
for
the
architecture
spec
to
clearly
state
that,
if
appropriate,
right,
you
know
that
verifiers
may
have
to
act
as
attesters
to
relying
parties
and
once
that
was
clearly
stated,
then
go
to
eat
and
say
you
know:
do
you
have
any
guidance
on
on
how
we
want
this
to
kind
of
be
standardized
or
not?
I
mean
that's
a
very
real
thing
that
we
do
in
that.
A
I
Yeah
and
so
okay,
so
just
kind
of
as
a
meta
comment,
you
know
it's
one
thing
where
they,
where
the
attester
communicates
and
attestation.
Sorry,
not
the
the
verifier,
communicates
an
out
of
state
station
token
on
its
own
behalf
to
the
relying
party
and
that's
fine,
I
think,
that's
a
perfect
legitimate
use
case.
The
verifier
is
basically
verified,
confirming
its
security
state
to
the
relying
party,
so
the
lying
party
can
trust
it.
I
It's
another
thing
when
the
test
of
when
the
verifier
conveys
the
attestation
evidence
from
whatever
the
remote
device
is
in
the
context
of
an
eat
into
to
the
relying
party
that
almost
seems
like
embedding
a
protocol
on
top
of
the
within
the
attestation.
Token,
that's
not
that's,
maybe
a
little
bit
beyond
scope,
I
would
say:
yeah
go
ahead.
E
E
I
All
right,
I
mean
I'll,
take
a
look
at
that
error.
I
think
that
I
think
the
thing
you
know
I'm
like
I
I
assume
one
model
would
be
that
the
verifier
would
first
convey
its
security
state
to
the
relying
party
and
then
the
verifying
relying
party
would
establish
a
secure
channel
between
the
between
each
other.
Then,
after
that,
the
verifier
would
just
send
out
a
station
evidence
by
itself
over
to
the
over
to
the
lying
party,
but
yeah.
E
There
could
be
other
ones
yeah,
there
are
other
models,
and
one
of
the
reasons
you
might
do
this
is
the
attestation
results
might
be
a
one-time
event
which
gets
signed
and
then
stored
on
the
attester
to
be
forwarded
over
later
to
the
to
the
relying
party.
So
the
idea
of
having
to
build
a
secure
channel
later
either
might
not
be
an
option
or
it
might
not
be
scalable
for
the
solution.
I
B
Yeah,
I
I
think
from
my
perspective,
the
the
the
first
part
was.
I
was
just
looking
for
text
and
I
still
haven't
seen
it
in
the
doc
that
basically
use
the
word.
You
know
when
talking
about
establishing
trust
with
the
relying
party
you
know
use
the
verbiage
of
of
of
giving
it
no
I'll
miss
my
terms
here,
the
the
let
me
find
my
architecture,
diagram.
B
The
evidence
right
the
that
attempt
that
a
tester
would
give
and
yeah.
Thank
you,
the
so.
The
the
the
text
in
the
in
the
trust
bottle
section
of
the
dock
when
it's
talking
about
establishing
trust
between
the
verifier
and
the
relying
party
never
uses
that
term
acting
as
an
attester
or
providing
evidence.
It
talks
in
more
vague
terms.
Yet
when
it's
talking
about
establishing
trust
between
the
verifier
and
the
endorser
or
verifier
owner,
it
does
speak
in
those
very
specific
terms.
A
A
C
I
A
A
A
F
A
A
We
ned
did
drop
out
of
the
call
didn't
he
yeah
okay,
so
we
can't
bother
him
to.
I
know
what
he
just
said:
there
not
a
very
successful
grouping
here:
security
considerations
for
implicit
trust
model.
I
wrote
that
note
to
myself.
I
haven't
done
anything
with
it
that
was
greg's
confusing.
That
was
a
question
or
responding
with
question.
Freshness
may
not
be
inclusive
enough.
That's
the
one!
I
just
opened!
Okay!
Well,
that's
about
it!
I
would
say
three
days
ago,
open
three
days
ago:
oh
wait
a
minute.
Okay,.
F
F
F
F
F
F
F
A
F
F
No,
not
no,
no,
no,
no,
not
in
all
cases,
because
if
it's
just
asserting
it,
I'm
not
sure
what
what
powerfulness
means,
maybe
maybe
the
maybe
the
relying
party
has
to
be
an
attacher
here
and
it
creates
evidence
about
it.
So,
but
I
assume
that
this
is
correct.
I
don't
have
to
have
another
look
at
this
means
literally
to
correct
evidence
about
this
as
a
relying
party
which
would
make
render
the
blind
party
also
taking
on
role
of
a
tester
here,
which
we
already
had
as
another
topic
here
today.