►
From YouTube: TEEP WG Virtual Interim Meeting, 2020-02-10
Description
TEEP WG Virtual Interim Meeting, 2020-02-10
A
A
Alright,
good
morning
and
good
evening
to
those
joining
the
session,
this
is
the
trusted
execution,
environment
and
provisioning
working
group.
Virtual
interim
with
you,
we've
got
the
two
chairs
studio
and
myself
the
note
well
because
it
is
a
nineteen
effort.
Oratory
still
stands.
Hopefully
your
pair
of
the
rules
and
I
just
wanted
to
do
a
quick
agenda
bash
as
I.
Don't
see
Hannes
I
guess
we
won't
have
any
updates
as
to
the
hackathon
that's
coming
up
in
a
week
or
so.
A
The
only
thing
we
have
for
the
agenda
today
is
the
update.
There
has
been
a
lot
of
activity
to
the
architecture
document
and
David
I
put
you
in
the
main
presenters,
so
anybody
yep
not
all
right.
So
if
I
could
help,
we
need
at
least
one
note-taker,
I'm
posted
the
etherpad
in
here
and
I.
Haven't
volunteered
please
so
that
we
can
start.
C
C
Momentarily
Libby
cover
0.3
verbally,
so
there's
a
technical
issue
or
two
that
overlaps
with
the
architecture
ones.
That's
why
we
rolled
that
one
into
the
architecture
document,
but
the
status
that
I
wanted
to
give
is
the
at
last
IETF
106.
We
had
some
discussion
of
what
direction
we
should
go
with
respect
to
supporting
the
old
ot
RP
stuff
when
we
gave
direction
to
the
editor
and
said
well,
you
know
once
this
is
done
and
the
draft
and
we
would
be
ready
to
start
working.
C
C
Because
I
just
basically
removed
some
information
and
did
a
couple
minor
Corrections,
and
so
my
belief
is
unless
the
things
that
come
up
on
the
architecture
that
do
affect
teep
over
HTTP
document,
then
it
would
be
ready
for
working
request,
call,
which
is
what
we
said,
that
IETF
106,
that
we
would
started
after
that.
And
so,
as
we
go
through
the
architecture
and
we
hit
the
one
or
two
items,
then
the
question
we
should
keep
in
mind
is:
is
this
anything
that
requires
an
update,
the
document
or
not?
C
C
C
Here
is
the
timeline
so
IETF
106
we
had
a
discussion.
We
then
posted
draft
o-5
based
on
the
discussion,
IETF
106,
that's
what
went
through
working
group
last
call
which
lasted
for
about
four
weeks,
completing
the
union
of
January.
After
the
working
of
last
call
completed,
we
had
a
bunch
of
issues
that
we've
been
working
on
and
then
we
just
posted
draft.
C
Oh
six
on
Saturday-
and
that
brings
us
to
you
today
and
so
our
goal
is
to
go
over
what
we
did
and
see
if
there's
any
additional
changes,
because
we
still
have
time
to
post
another
version
before
the
next
ID
cutoff,
and
so
we
will
do
that.
That's
where
we're
at
we've
addressed
all
of
the
issues
we
think
raised
in
working
group
last
call,
except
for
maybe
one
or
two
that
we'll
start
with
here.
So
during
working
or
blessed
call,
there
was
19
issues
filed
in
github.
C
Some
of
those
were
open
by
the
person
did
their
review.
If
they
were
only
posted
to
the
list,
then
Ming
went
and
added
those
issues
into
github.
So
we
think
all
the
points
that
were
raised
are
covering
github.
Let
us
know
if
we
missed
anything
of
those
19
17
of
those
are
addressed
in
draft.
Oh
6,
plus
some
additional
minor
editorial
notes.
C
There
weren't
worth
filing
github
issues
for
and
so
I'm
gonna
walk
through
those
starting
from
the
ones
that
were
not
addressed
and
then
ending
with
the
things
that
are
kind
of
you
know
trivial
or
whatever.
So
if
we
have
time,
then
we'll
get
to
the
trivial
ones.
If
we
don't
have
time,
then
gosh
we'll
skip
the
trivial
ones,
because
it's
not
necessary
to
take
over
themselves
alright.
So
we
start
with
the
two
issues
that
are
not
done
in
draft.
Oh
six,
because
we
wanted
more
guidance
with
the
editors.
C
Didn't
they
at
least
me
and
I
didn't
know
what
to
do
so
here
we
go.
Here's
the
first
one.
So
this
is
one
that
was
actually
filed.
I,
don't
know
like
in
December
or
something
and
I
think
it
was
a
Honda
settlement.
This
has
to
do
with
the
discussion
on
personalization
data,
and
so
there
was
some
discussion
in
the
github
issue
itself.
C
So
it
meant
that
everything
there
was
only
two
categories
of
stuff.
There
was
things
that
were
could
be
sent
like
every
device.
It's
out
there
and
we're
not
considered
part
of
personalization
data
and
things
that
were
specific
individual
devices
that
didn't
go
everywhere.
I
went
to
specific
devices
and
those
got
encrypted
with
that
devices
key
that
only
that
device
could
decrypted.
That
was
what
commercialization
data
was,
and
so
Hana
said.
Well,
you
actually
need
to
encrypt
everything,
or
could
you
have
stuff
that's
device
specific
that
actually
doesn't
need
to
be
encrypted.
C
Networks
is
that
must
early
must
and
so
Hannes,
and
this
PR
suggested
tech.
The
personalization
data
may
need
to
be
encrypted
and
deleting
the
other
phrase
in
bull
was
there.
So
in
other
words
he
replied
he
proposed
replacing
the
above
with
the
below,
and
then
this
short
discussion
stood
between
Ming
Hannes
and
me
trying
to
debate
as
to
whether
this
was
a
must
or
a
should,
or
you
know,
a
conditional
must
right
and
so
I
think
I
don't
feel
strongly
either
way.
C
D
Dave
this
is
Russ,
can
I
ask
a
question:
do
we
believe
there
will
always
be
personalization
data?
In
other
words,
if
the
end
implementation
is
required
to
do
to
support
encryption,
because
there
is
routinely
personalization
data,
then
it
kind
of
the
top
encourages
that
approach.
The
bottom
leads
you
to
the
place.
Well,
hey,
maybe
I
don't
need
to
implement
that
because
that's
not
the
normal
case.
Okay,.
C
C
C
Would
say
that
was
briefly
discussed
between
Ming,
Hannes
and
I,
and
so
I
would
say
that
between
the
three
of
us
and
I
suspect
the
that
all
three
of
us
would
say
that
it
is
not
necessarily
the
case
that
there
will
always
be
personalization
data
for
a
specific
device,
meaning
there
may
be
specific
cases
where
a
particular
device
does
not
need
personalization
data.
That
said
even
Hannes
when
suggestion
the
bottom
one
Hannes
believes
that
it
should
be
mandatory
to
support
encryption,
although
that
does
seem
like
it
might
not
be.
C
E
Kathleen,
I
have
a
question,
and
maybe
I
missed
this,
so
I
apologize
if
I
missed
it
with
the
personalization
data.
Are
you
considering
things
like
the
standardized
random
format
for
mac
addresses
because
they're
unique,
but
following
the
I
Triple
E
work
for
randomization,
so
that
no
one
vendor
had
a
unique
randomization
pattern?
You
know:
is
that
considered
in
scope
of
this
or
out
of
scope,
these?
That
might
be
guys
I.
C
E
E
So
essentially,
they
worked
across
vendors
because
everyone
was
moving
towards
MAC
addresses
becoming
randomized,
but
you
could
identify
which
vendors
randomization
pattern
was
in
use
when
they
all
had
their
own.
So
I,
Triple
E
has
a
standard
which
is
I
believe
pretty
well
adopted.
Now,
because
this
is
when
I
was
an
ad
and
we
had
the
meetings
between
the
I,
Triple,
E
and
I
ESG.
E
So
that's
more
than
a
year
and
a
half
ago,
everyone's
using
middle
is
you
know,
could
that
be
an
exception
to
this,
because
it
does
uniquely
identify
a
device
potentially
right,
the
the
identifier
and
that
could
be
device.
Personalization
data,
but
maybe
that's
okay-
do
not
have
to
only
have
integrity
protection
in
some
cases.
F
E
F
The
application,
so
that
might
be
a
username
password
email
registered
email
address
it
could
be
signing
key,
that's
associated
with
the
application.
That's
now
been
registered
with
the
service
provider,
so
it's
typically
persons,
ation
information,
very
specific
to
the
application
being
loaded
and
I.
Don't
think
it
would
be
MAC
addresses
which
would
be
more
system
oriented.
Okay,.
E
G
G
E
Hank
Hank,
so
what
I
described
some
people
would
consider
personalization
data,
even
though
it's
a
randomized
MAC
address
for
a
device,
and
the
reason
is
that
you
can
pattern
what
that
device
does
and
track
the
behavior
of
the
person
with
that
device
right.
But
some
people
might
not
consider
that
personalization
data
because
it
doesn't
fit
into
the
bucket
that
Dave
just
described
it's,
not
an
email
address
password
or
an
account.
This.
C
E
G
E
F
An
example
would
be
a
list
of
server
address
to
contact
the
service
provider
with
times
of
operation
or
things
like
that.
They,
it
would
be
personalizing
the
application,
but
it
wouldn't
be
specific
to
one
specific
instance:
it
would
be
more
of
a
service
provider
general
type
of
information
that
would
normally
change
perhaps
over
time.
So
you
almost
might
say
it's
configuration
data.
C
Minging
isn't
here
unless
he,
unless
you
guys
tameka's
joined
but
I,
think
Meg
would
say
something
very
similar
to
what
he
said
and
so
I'm
going
to
try
to
channel
being
here.
The
personalization
data
is
meant
to
be
specific
to
a
device,
and
so
how
do
you
know
that
it
gets
to
that
device
and
not
something
else?
Well,
one
of
the
mitigations
one
of
the
layers
of
the
security
bear
is
to
say
well
if
encrypted
by
that
that
device
is
key.
C
Then
you
know
that
it's
going
to
that
device
in
some
other
device,
and
so
you
have
a
very
strong
guarantee
that
you're
configuring,
the
correct
device
with
it,
and
it's
not
you
know
and
you'll-
have
some
man-in-the-middle
redirecting
and
or
something
like
that.
There's
other
ways
to
solve
that
potentially.
But
this
is
a
strong
way
to
do
that.
Even
if
you
done
even
if
you
don't
need
confidentiality
you're
using
it
to
verify
that
it's
going
to
the
correct
device.
C
C
C
Okay,
then,
all
right
so
just
to
repeat
back
what
I
think
you
said
that
personalization
most
other
three
pieces,
all
of
which
are
true
and
that
the
wording
can
be
more
concise
in
this.
But
in
that
proposal,
device
must
be
able
to
support
personalization
data.
It
must
be
able
to
support
encryption
and
it
must
be
able
to
support
encrypted
personalization
data.
All
three
of
those
sentences
are
true.
C
C
B
I
didn't
get
your
three
sentences.
Unfortunately,
I
got
Ross's
statement.
I
think
I
changed.
The
word
slightly,
which
was
implementations,
must
report
encryption
to
allow
for
loading
of
sensitive
personal
data,
but
I
swapped
a
word
in
there
for
what
you
said.
No
I
think
that's
close
enough.
You
don't
know
what
the
other
two
sentences
are,
that
they
went
by
quickly
and
I
was
typing.
C
That's
going
to
widen
as
an
editor.
If
this
is
the
consensus
of
the
working
group,
I
know
how
to
do
text
to
do
this.
I
think
there's
enough
and
that
you've
captured
enough
to
have
a
trigger
that
discussion.
So
anybody
else
want
to
weigh
in
because
otherwise
that
sounds
like
what
I'm
hearing
is
as
the
direction
of
the
editor
so
far,.
C
All
right,
so
that's
one
of
the
two
issues
there
was
not
done.
This
is
the
other
one
that
we
didn't
do
anything
about
and
so
I
copied
the
complete
text
of
the
issue
onto
the
screen.
Now,
because
this
is
all
the
information
we
have,
you
can
see
the
title
filer
and
this
one
is
about
stuff.
That
I
am
certainly
not
qualified
to
answer
here:
UICC
useful
to
provide
embedded
designs
with
IOT
device
services
management,
as
long
as
the
MCU
can
mutually
authenticate
with
the
EU
ICC.
Where
does
he
fit
into
this
picture?
C
And
so
when
I
read
this
not
know
anything
about
the
technical
details
of
EU
SEC
I,
wonder
if
this
is
more
like
a
question
to
the
mailing
list,
for
somebody
to
answer
than
it
is
for
a
request
for
the
architecture
document
to
be
discussing.
Eu
ICC,
but
I
wanted
to
throw
this
out
to
see.
If
somebody
more
experienced
more
knowledgeable
can
help
me
figure
out
what
the
right
thing
to
do
is
here.
F
C
Oh
as
an
editor,
the
main
question
that
I
have
for
the
working
group
is
the
bottom
question
on
this
slide,
which
is,
would
it
be
sufficient
to
just
have
someone
answer
on
the
list
or
is
there
anybody
in
the
working
group?
That
believes
is
some
change
to
the
architecture.
Document
itself
was
needed.
In
other
words,
can
we
assign
it
to
somebody
else
other
than
Ming
or
me,
or
is
it
something
that
we
need
to
work
upon?
Drafting
text
for.
F
C
C
So
the
next
section
are
things
that
we
think
are
addressed
and
I've
tried
to
front-load
the
ones
that
wanted
to
census,
because
editorial
okay,
and
so
there
may
be
discussion
of
some
of
these,
which
is
what
we
want.
So
that's
the
question
mark
on
they
are
they
addressed?
Okay,
so
here's
the
first
one.
C
This
one
was
a
contradiction
about
whether
a
device
must
have
a
rich
execution
environment
to
use
teeth
or
not.
So
the
issue
was
there
was
text
about
the
t,
pagent
that
implied
that
there
must
be
a
t
broker.
The
text
about
the
teet
broker
says
that
the
t
broker
runs
in
a
rejection
environment
and
the
introduction
talked
about
there
being
two
E's
and
an
ree
if
present,
and
so
in
other
words,
the
introduction
covered.
C
The
case
where,
like
the
entire
microcontroller,
is
just
a
T
and
there's
no
REE
within
all
the
text
around
teeth
agent
and
the
T
protocol
imply
that
there
had
to
be
an
REE,
and
that
was
the
contradiction.
So
the
question
was
and
that
this
issue
is
about
is:
can
you
have
a
teep
agent
and
the
tip
over
HB
transport
they're,
both
just
in
a
device
like
an
MCU?
That's
entirely
at
EEE
we
did
some
changes
for
which
the,
which
would
be
that
the
fur.
If
the
answer
is
yes,
then
the
draft
ov6
was
updated
accordingly.
C
Assuming
that
the
answer
should
be
yes,
which
is
what
the
introduction
implied
and
so
the
actions
that
we
did
was
we
updated
the
text
about
the
T
pagent
not
imply
that
there
has
to
be
a
cheap
broker.
There's
always
an
eight
tip
over
HTTP
transport
right,
but
didn't
imply
that
there
must
be
a
t
broker.
Just
the
word
typically
is
used
in
at
least
two
or
three
places.
C
C
H
H
C
Next
section
was
another
place
where
text
in
one
section
apparently
contradicted
another
section.
This
had
to
do
with
the
case
where
you
have
multiple
te
E's
in
the
same
device,
and
so
if
you
have
multiple
T's
in
a
device-
and
we
even
have
you
know
a
picture
that
they
were
put
in
a
while
back
that
actually
shows
this
when
you
have
multiple
T's
in
a
device
and
there
could
be
one
common
teat
broker
that
talks
to
multiple
T's
or
there
could
be
a
T,
procorp,
/,
T
or
anywhere
in
between.
That's
that's.
C
What
the
the
draft
O
six
is
now
consistent
in
basically
saying
that
the
issue
before
was
that
one
section
implied
that
there
was
always
one
common
and
one
implies.
There
was
always
one
per
te
e
and
those
were
different
answers,
and
so
now
we
just
updated
them
to
be
consistent
to
say
that
both
are
possible.
C
All
right
the
there
was
a
pull
request
that
did
this
and
in
some
of
the
comments
on
the
poor
recruit.
So
of
course,
the
the
process
that
we've
been
following
is
at
least
two
editors
agree
on
the
pleura
quest
before
we
merge
the
per
request,
and
so
that's
why
we
often
see
these
comments
between
the
editors
and
anybody
else
is
welcome
to,
and
so
in
those
comments
on
the
text
here,
there
was
also
some
discussion
of
exactly
how
the
TAM
selection
is
done.
C
I
knows
who
does
the
TAM
selection
and
so
on,
which
was
not
directly
about
this.
That
was
more
about
the
relationship,
the
chief
over
HTTP
transport,
spec,
so
I
guess
Ming
is
still
not
on
the
call
right
because
he
was
the
one
that
raised
this
comment
and
I
just
wanted
to
confirm
with
everybody
else
that
we're
still
what
we
did
and
I
what
we
talked
about
f-106.
C
So
what
we
talked
about
it,
ITF,
106
and
maybe
before
that
too,
but
the
teepo
grace
to
be
transport
set
spec
says
that
the
selection
of
which
came
to
communicate
with
this
is
the
quote
from
l6,
not
the
quote.
For
the
transport
spec,
the
selection
of
which
Tam
to
communicate
with,
might
be
made
with
or
without
input
from
an
untrusted
application,
but
ultimately
to
the
decision
of
a
teep
agent
right.
C
What
the
transport
spec
talks
about
is
is
that
an
untrusted
application
or
its
manifest
right
can
provide
input.
So
let's
say
you
have
an
untrusted
application
that
depends
on
a
particular
ta
right,
so
the
untrusted
applications
at
manifest
can
say:
I
have
a
defi
of
this
particular
dependency
and
here's
a
URL
that
I
that's
in
the
manifest
for
the
Tam
for
which
that
ta
from
which
that
ta
can
be
determined
right.
C
The
application
or
the
app
installer
can
look
at
that
to
say:
oh
I
need
to
distance
all
some
dependencies,
and
so
I
have
this
Tam
URI.
What
happens
in
the
transport
spec
is
that
Tim
URI
and
the
tin,
the
TA
identifier,
you
know
the
gooood
or
whatever
are
passed
into
the
t.
P--
agent,
they
say,
hey,
there's
a
request
to
install
this
ta
and
here's
a
cam,
your
eyes,
a
hint
right.
C
So
that's
what
it
means
by
ultimately
the
decision
of
the
teeth
agent,
where
whatever
comes
to
the
trusted
application,
untrusted
application
is
just
a
hit.
I
just
wanted
to
confirm.
So
this
has
been
merged
and
it's
no.6
and
want
to
confirm
that
nobody
objects
to
the
the
discussion
of
what
I've
summarized
because,
like
I
said,
this
was
discussed
at
in
the
transport
spec
discussion
at
IETF
106
and
before
any
questions
or
comments
on
this
issue.
C
So
I
don't
remember
if
this
is.
This
is
a
slide
one
up
two,
so,
okay,
I
guess
I've
been
talking
about
stuff.
That's
on
this
slide.
So
let
me
just
briefly
go
through
this
one.
Since
I've
now
said
pretty
much
everything.
That's
on
the
slide
right
you
can
see.
This
is
the
coming
in
the
middle
of
the
discussion
we
were
having
on
the
github
issue
and
the
current
transport
spec
I
was
just
summarizing
what
it
says.
C
Those
are
three
bullets
in
the
bottom,
which
says
what
the
transport
spec
says:
I'll
leave
this
one
up
there
just
for
a
second
here.
It
doesn't
say
anything
that
I
would
already
say:
hey
if
I
don't
hear
any
comments.
I
am
going
to
move
on
to
the
next
one
and
assume
that
there's
mMmmm
that
we're
on
the
right
track
and
that
there's
no
necessarily
no
need
for
a
change
to
transport.
Spec,
I
think
I'm,
not
sure
what
the
action
to
record
on
this
issue.
C
H
So
yes,
I
mean
I,
just
trying
to
say
was
some
still
irises
is
this
common
here
was
that
it
tip
broken,
may
initiate
a
caught
time,
first,
I'm,
not
always
from
T
pages,
but
as
I
said
you
said,
the
first
one
is
always
from
T
pager.
Be
patient
may
not
at
another
time
yet
right,
so
we
could
time
certificate
it.
If
ten,
thousands
something
tip
agent
done
note,
she
was
trusted
yet
so
the
other
ways
I
thought
it
was
a
min.
C
Have
the
Ted
it
may
or
may
not
have
the
Tam's
cert
at
that
time?
That's
what
happened!
That's
what
it
gets
back
inside
that
connection
right!
Well,
it
still
does
the
selection
of
which
you
are
I
to
use
and
says,
hey
t
procure
please
connected
the
following
URI
now,
of
course,
assuming
these
are
all
HTTP.
Uri
is
right.
Then
implicitly
the
HTTP
stack
is
going
to
do
some
authentication
there
right
I.
H
Remember
with
the
first
one:
okay,
that's
a
little
clarified
a
little
bit.
Okay,
so
TV
broker
person
to
T
page-
and
you
say:
okay
optional,
over
itit,
okay
and
they
say
it's
a
ton,
not
overwrite
it
in
Japan.
So
if
I,
then
we've
attended
over
to
connect
to
time
it's
KT
per
agent.
The
tip
agent
constructs
a
request
message
or
not
indication
now,
because
the
window
pass
through
it
done,
it
doesn't
know
what
to
do
and
they
in
turn
not
general
requests.
It
will
be
just
a
contact
connection
from
TV
partner.
H
C
The
HTTP
nice
BEC
that
had
the
line
diagram
with
the
you
know
the
arrows
going
back
and
forth
I'm,
just
explaining
what
was
on
the
one
with
the
arrows
and
all
we've
done
to
change
the
labels
on
the
arrows
like
from
OTR,
p2t,
pand
and
so
on.
But
the
arrows
go
all
the
way
back
for
a
year
or
more
to
the
first
hackathon.
So
roaming
and
I
were
doing
the
transport.
C
C
Okay,
this
one
that
should
be
not
controversial
but
I
want
to
go
through
this
one
before
the
next
one.
That
is
slightly
more
technical.
So
this
one
Interiors
review
right.
There
was
a
discussion
of
threats
on
the
mailing
list,
and
so
there
was
three
or
four
threats
that
were
discussed
in
the
mailing
list,
and
so
mink
did
the
right
and
put
these
in
its
security
consideration
section.
So
the
top
two
are
ones
that
are
specifically
really
related
to
DOS.
C
One
is
das:
by
the
rich
execution
environment
and
the
other
one
is
dosed
by
the
teeth
broker
or
in
theory
it
would
be
attempting
to
do
attacks
more
than
just
das
and
the
discrete
discussion
talks
about
how
the
other
attacks
are
mitigated
and
everything
is
reduced
to
das.
But
this
architecture
does
not
prevent
a
dos
attack
by
a
compromised,
reee
or
broker.
That's
roughly
what
the
security
considerations
section
does
is
everything
else
is
reduced
to
dos,
so.
E
E
C
E
I'll
have
to
go
over
current
version.
I'm
sorry
I
haven't
done
that
yet,
but
yeah
essentially
I
just
want
to
make
sure
that
we're
not
painting
too
rosy
a
picture.
That
I
mean
I
think
it
is
a
much
much
better
picture
when
all
of
this
is
done,
but
I
mean
with
nation-state
threat
actors
and
what
they
accomplished
today.
That's
what
they
will
be
doing
right,
they're,
going
to
target
the
people
responsible
for
these
things
or
become
one
of
the
people
responsible
and
alter
something
where
it's.
C
B
I
was
going
to
say
this
that
what
happens
asking
for
I
agree
maybe
belongs
in
rap,
but
I'm
catching
space.
Maybe
it
maybe
there
needs
to
be
a
net
portability
that
says
which
part
this
can
this
protects
and
they
could
simply
say
this.
Other
stocking
is
a
problem.
G
Yeah
I,
don't
think
the
Texas
to
reflect
that
it's
security
conservation,
apparently
so
yeah.
It
has
to
be
trust,
model
specific
specific
takes
again,
and
we
can
have
a
discussion
on
this
this
tomorrow.
I
actually
hope
I
can
make
it.
I
might
have
a
conflict
because
I'm
face-to-face
on
the
East
Coast
right
now
and
I
might
have
a
conflict
meeting.
I
still
don't
know,
I
just
arrived.
C
One
case
was
where
there's
a
TA,
that's
actually
buggy
and
you
didn't
know
about
it
before,
and
so
suddenly
a
vulnerability
was
found,
and
so
that
ta
is
now
sort
of
accidentally
malicious.
It
could
be
used
for
malicious
purposes,
not
that
the
developers
were
pad
just
had
bugs
in
it
or
something
like
that.
The
other
case
is
where
you
had
a
good
TA,
and
maybe
the
provider
updated
it
legitimately
in
a
way
where
it
now
turned
bad
right.
C
Exactly
and
so
the
point
is,
you
now
have
a
malicious
ta.
Well,
you
did
it
before
is
aroma,
but
you've
got
into
a
case.
You
have
a
malicious
ta
inside
your
TV.
What
happens?
Okay,
there's
text,
that's
on
that
that
was
issued
123
and
what
the
discussion
is
right
now
is.
It
has
two
things
it
talks
about
how
the
Camas
responsible
for
uninstalling
things
and
I
saw
Eko.
C
So
somebody
commented
as
a
github
issue
like
last
night
with
questions
further
about
this,
so
there
may
be
additional
text
we
may
want
to
do
here.
But
the
fourth
point
is
that
the
TAM
can
uninstall,
the
ta
has
gone
bad
and
the
question
that
was
raised
I
think
by
Nico
was
so.
Does
that
mean
that
TAS
can
continue?
C
H
One
atom
one
here
that
the
removal
may
not
be
immediate.
Just
that
we're
not
good
ta
goes
bad.
You
get
at
rimoni
to
be
initiated
from
device
to
contact
I'm,
so
not
be
able
to
always
reach
it
device
right.
So
that's
always
had
someone
deal
and
then
that
to
us
always
suggests
you're
more
of
a
suggestion
or
a
permutation
choice.
They
may
have
some
it
devices
that
you
can
scamp.
Your
article
looks
at
what
hurts
bad
then.
H
Maybe
some
blacklist
or
some
report
lists
the
gate
for
a
clinician
at
one
or
your
next
contact
time,
but
when
one
ta
start
to
use
in
Minar
contact
time
for
long
alright,
it
may
not
have
the
need
to
do
that.
So
that
way
they
need
some
additional
additional
mechanis
to
scan
at
the
least
to
check
what,
whether
or
third-tier,
still
good.
So
that's
an
out
of
school.
But
it's
a
protocol
definition,
but
for
the
security
consideration
it's
a
recommendation.
Additional
Sugano
check
may
be
needed
to.
C
Does
that
which
is
so?
This
comes
back
to
you
and
we
want
to
talk
about
this
and
the
rats
architecture
is
when
you
say,
hit
a
verifier
hitting
attestation
result.
How
long
is
that
attestation
result
then
good
for,
in
other
words,
what's
the
reliance
part
of
gonna?
Do
that
a
cessation
result
they're
gonna,
keep
it
and
let
you
keep
doing
operations
for
the
lifetime
of
a
connection
that
could
be
hours
or
days
or
is
it
something
that
comes
with
some
lifetime?
C
That
says
your
attestation
says
you're
good
during
this
connection,
but
for
no
more
than
you
know
at
an
hour
or
something
like
that,
because
what
happens
if
you
go
bad
within
the
lifetime
of
that
connection,
what
happens?
Because
if
you
go
bad,
then
what
happens
is
red
tie
station
fails
and
that
then
causes.
G
D
E
B
H
That's
a
good
equation.
I
think
I'd
like
to
come
and
actually
I'm
thinking
about,
because
the
comments
think
about
who
define
the
policy
all
right.
If,
if
they
say
how
long
and
who
controls
that
at
time,
T
agent
who
write
I
think
it
may
be
a
little
bit.
Thinking
fall
off
of
that
one.
I'm
thinking
now
say
who
who
comes
a
lifetime
of
TA?
It
may
be
time
I
sent
to
me
as
a
Tam.
Initially,
you
start.
If
you
find
something
wrong.
Maybe
each
was
set
that
time
limit
at
the
most
a
decision.
H
C
H
H
C
There
is
one
yeah
and
github
if
you
look
there
and
we
didn't
used
to
sign
that
one
to
you,
I,
don't
know
what
the
number
is,
but
it's
there
any
objection.
No
okay,
I
skipped
over
issue
number
120,
because
Kathleen
was
asking
questions
that
were
very
relevant
to
123.
So
120
was
a
type
of
das,
where
the
top
two
is
about.
You
know
dossing
different
actions
on
the
device.
This
one
is
about
an
additional
point
that
says:
okay.
C
Well,
if
I
keep
asking
to
uninstall
or
install
a
TA,
so
I
like
I'm,
trying
to
install
an
untrusted
application
and
uninstall'
the
entrance
application,
one,
the
other
that
depends
on
a
particular
TA.
Let's
say
I
say:
hey,
I
wonder
once
I
want
to
install
this
untrusted
app
and
it
depends
on
this
TA
and
you
don't
have
permission.
That's
all
that
ta.
You
know
the
Tam
says
nope
that
one's
not
authorized
that
one's
a
malicious
one
or
whatever,
and
so
you
could
say
well,
I
still
want
to
install
it.
I
still
want
to
install
it.
C
C
C
A
A
C
So
the
next
one
also
teary
raised
in
his
review,
clarify
the
code
signing
certificate
type,
and
so
this
is
discussion
of
things
like
self
sign
and
CA,
issued
spirits,
right
and
so
I'm
doing
serve
a
Leticia
that
assert
validation.
Just
says:
hey!
Does
the
following
sir
chain
up
to
something
in
the
trust:
anchor
store
right?
Well,
the
thing
in
the
trust
anchor
store
could
be
the
search
itself,
and
so
it
it
might
not
be
a
signing,
sir.
C
It
might
be
the
search
itself,
and
so
in
that
sense,
that
certs
are
legal
hunting,
no
matter
how
many
levels
up
they
are
in
the
in
a
search,
a
NAND,
so
you
could
use
a
set
of
some
insert.
Yes,
they
should
search
just
whether
you
have
to
traverse
your
or
more
levels
up
the
search
chain
before
you
find
a
match
in
the
trust
bank
restore,
and
so
we
tried
to
clarify
that
that
that
text,
as
opposed
to
things
that
we're
saying
you
know
it
must
be
self
signed
or
it
must
be.
C
You
know
some
CA
issued
thing
because
it,
the
trust,
anchor
store,
is
agnostic
as
to
you
know
where
you
got
it
from
the
this
generated
and
I
think
this
let
over
under
the
list,
not
just
github,
but
is
the
code
signature
checked
at
the
Tang,
and
so
it
was
a
discussion
between
unlist
between
Peru
and
Ming
and
me
and
I
forget,
who
else
it
says?
Does
the
Tam
need
to
verify
the
T
signature
on
binaries
submitted
to
the
town
and
minge
answer
on
that
which
was
two
considerations?
C
Well,
you
know
the
TA
might
not
be
distributed
via
the
time
to
begin
with,
and
so
it
can't
check
a
signature
on
something
he
doesn't
have
right.
Well,
if
it
does
have,
but
then
the
TA
might
be
encrypted,
and
so
what
does
the
Tam
do
with
something
that's
encrypted?
I
then
added
that
the
Tama
and
just
authenticate
the
entity,
because
really
the
ability
to
upload
binaries
to
the
Tam
is
largely
out
of
school.
It
just
says
that
that
has
to
happen,
but
the
details
for
doing
that.
C
There's
no
protocol,
or
whatever
for
the
protocol
within
scope
for
the
working
group,
is
between
the
Tam
and
the
device
not
between
the
developer
and
the
team.
You
just
gotta
have
some
way
to
do
it
and
so
a
points
out
that
the
Tam
could
just
authenticate
the
entity
uploading
the
TA
and
not
check
the
signature
on
the
TA
just
make
sure
it
comes
from
a
valid
source,
and
so
but
mechanisms
to
do
so
are
out
of
scope,
and
that
point
has
not
currently
discussed
in
the
document,
and
the
question
is:
should
it
be
right
now?
C
H
That's
it
that's
all.
I
was
thinking
about
right,
I
want,
because
we,
when
we
looked
at
security
consideration,
you
know
with
service
to
Tammy
tributed,
so
now
we're
how
to
where
to
distributed
tea
right.
Ta
partner
can't
be
bundled
inside
our
trust.
After
self,
you
had
a
case
warning
in
store.
How
do
we
know
it's
malicious?
Not
so
there
was
assumes
trust
there
when
that
yeah.
H
I
think
you
need
to
discuss
this
I
feel
filming.
It
said
your
second
bullet
single
bullet
first
one
became
if
it
is
distributed
from
trust.
I
have
the
self
Colonel
Locke
I
need
some
system
of
air.
If
you
need
somewhere
to
be
checked,
I've
had
a
tea,
a
tea
Beijing.
No,
this
was
good.
Why
some
way
need
to
check
the.
C
Interest
of
time,
I
think
what
I'm
hearing
so
far
is
that,
yes,
it
would
be
good
to
discuss
this
in
the
document
without
necessarily
specifying
mechanisms,
but
I'm
discussing
the
issues
would
be
good,
so
we
should
do
that.
No7
is
what
I'm
hearing
I
think
that
was
the
last
question
in
my
deck,
that
was
a
we
think.
There's
any
gaps
paid,
hey
editors,
we
don't
know
you
know
today,
working
Europe.
The
editors
need
some
direction
on
what
to
do.
I
think
everything
else
is
just
us
reporting
out
what
to
do
so.
C
C
These
are
the
two
that
were
just
filed
only
a
couple
hours
ago,
so
the
malicious
ta
removal
is
the
one
that
we
were
just
talking
about
and
cracking
the
new
stuff
there
and
this
one
I
haven't
read
yet,
and
so
this
is
how
a
that's
left
but
will
be
closed,
and
so
I'd
say
all
these
than
this
one.
These
would
be
possible
to
do
very
soon
and
do
a
new
rev
and
then
started
working
with
West
call
and
still
finish
before
next
IQ.