►
From YouTube: IETF114 TEEP 20220728 1400
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Welcome
to
the
trusted
execution
and
environment
provisioning
working
group,
if
you
are
not
expecting
to
hear
teep
you're
in
the
wrong
room,
let's
see
thursday.
So
by
now.
You
should
be
well
aware
of
the
note.
Well,
so
I'm
not
going
to
go
through
the
standard
practices
for
the
ietf.
You
can
read
them
on
your
own.
A
I
have
been
asked
to
reiterate
the
meeting
tips
so
make
sure
for
those,
especially
who
are
here
in
person
to
sign
in
through
the
meet
echo.
A
So
you
can
either
use
the
on-site
tool
or
the
little
video
icon,
and
that
will
give
you
the
ability
to
to
get
the
blue
sheet
sign
in
if
you
will
do
get
on
the
queue
and
meet
echo,
because
that's
the
way
we
can
respect
those
who
are
remote
as
well,
and
I
can
honor
people
on
the
queue
that
way
keep
your
audio
and
video
off
so
that
we
don't
get
double
double
audio
and
then
make
sure
that
you're
wearing
your
masks.
A
Even
if
you
come
up
to
the
mic,
so
the
only
ones
that
can
choose
to
take
their
mask
off
is
those
that
are
coming
up
to
present
for
the
remote
participants
make
sure
that
your
audio
and
video
are
off
unless
you
are
in
the
queue
and
you're
recognized
to
speak,
and
it's
recommended
that
you
use
a
headset
just
to
allow
for
the
audio
to
work
better.
A
Okay,
so
quick
review,
I
don't
know
why
the
pdf
next
time
I'll
I'll
turn
the
powerpoint
to
pdf,
so
it
formats
properly
key
points
of
the
code
of
conduct.
I
mean
we're
a
small
group,
we're
all
friendly
here,
but
this
is
just
to
say
treat
each
other
with
respect
and
courtesy
while
we're
in
the
room
keep
the
discussions
professional
okay.
So
with
that,
thank
you
to
our
ad
and
tinnette
for
helping
take
notes.
A
I
do
encourage
others
also
to
look
at
the
hedgehog
and
and
doc
and
help
us
if
you
see
that
our
our
helpers
can
cannot
keep
up
with
the
discussions
and
and
to
capture
it.
Okay,
so
for
the
agenda
today
we're
in
the
agenda
bashing
portion
so
dave
are
you
going
to
cover
for
ming?
If
he's.
B
A
Then
akira
you'll
present
the
updates
on
the
hackathon
and
then
dave
you're
back
on
to
discuss
issues
on
the
well,
not
really
well,
issues
but
also
progression
on
the
protocol
specification
and
then
pengling.
I
think
you
are
remote,
gave
you
some
time
to
provide
the
use
case.
That's
coming
from
confidential
computing.
A
A
Okay.
So
with
that,
if
there
are
no
comments,
dave
you
want
to
come
in
and.
A
D
Okay,
go
ahead
next,
this
is
the
architecture
document
all
right.
So
as
a
reminder
of
the
timeline
right,
we've
gone
through
working
group
last
call:
we've
had
ad
feedback
from
ben
that
was
then
updated
in
draft
16
and
17
and
18.,
and
you
can
see
various
other
reviews
that
have
happened.
Thank
you
to
all
those
who
have
submitted
reviews
next
slide.
D
All
right
so
section
3.3
was
one
that
had
a
comment
in
it
that
we
made
a
change
to
since
working
with
last
call
that
one
said:
weak
security
has
been
proposing.
Threats
to
critical
infrastructure.
Russ
had
a
comment
about
suggesting
minor
edits
to
help
the
reader
understand.
D
This
is
not
talking
about
network
infrastructure,
so
you
can
see
draft
17
since
last
ietf
was
updated
with
the
wording
on
the
bottom,
which
talks
about
proposing
infrastructure,
I.e,
assets
that
are
essential
for
the
functioning
of
a
society
and
economy,
and
I
think
russ
act
that
that
was
acceptable,
so
yeah
nodding,
okay,
great
next.
D
D
It
said
it
compromised,
might
drop
or
delay
messages
and
russ
pointed
out
that
it
should
also
mention
replay,
and
so
we
add
that
in
there
so
it
says,
drop,
replay
or
delay
messages.
Next,
roop,
ca
versus
trust,
anchor.
Okay,
so
9.4
said
a
root.
Ca
for
tam
certificates
might
get
compromised
or
a
certificate
might
expire
or
a
trust
anchor
other
than
a
root.
Ca
certificate
may
also
expire
or
be
compromised.
Okay,
russ
said:
what's
the
difference
between
a
root,
ca
and
a
trust?
Anchor
they're
usually
synonyms.
D
Explain
if
there's
a
difference
here
right,
and
so
you
see
a
little
clarification
exchange
between
ming
and
russ
there.
When
it's
a
certificate,
it
doesn't
have
to
be
a
root
certificate.
It
could
be
an
issuing
ca
while
it
isn't
common
practice
and
russ
pointed
out.
I
think
the
point
of
a
root
certificate
in
all
situations
is
not
very
helpful.
Please
add
that
to
the
document,
and
so
the
text
now
says
adding
the
point
in
bold.
It
can
be
a
non-root
certificate
when
it's
a
certificate
right.
D
So
it's
a
certificate
if
it's
a
certificate,
but
if
it
is,
it
doesn't
have
to
be
a
root
certificate.
Okay,
so
rest
nodded.
Okay,
next
yeah
yeah,
so
raw
public
keys
or
certificates,
when
they're
certificates,
they
could
be
a
root
certificate
or
an
intermediate
certificate.
Yeah
all
those
are
legal
ways
as
long
as
you
have
something
in
your
trust,
anchor
store
that
you
can
chain
up
to
okay.
Next,
okay,.
D
All
right
trust,
anchor
definition.
Trust
anchor
represents
an
authoritative
entity
via
public
key
and
associated
data.
The
trust
anchor
may
be
a
certificate
or
it
may
be
a
raw
public
key
okay.
So
we're
just
talking
about
carl
commented
and
the
main
part
is
in
bold
there,
where
he
actually
suggests
alternate
text
right
where
the
trust
anchor
may
be
a
certificate.
A
raw
public,
key
or
other
structure
as
appropriate
might
be
better
to
leave
open
the
possibility
of
contain
of
constraining
a
trust
anchor
right.
D
It
can
be
a
non-root
certificate
when
it's
a
certificate
right,
and
so,
if
you
have
something
else
that
fits
into
the
same
overall
bucket
as
a
trust
anchor
that
you
can
chain
it
up
to
that,
has
some
security
principle
associated
with
it.
Then
that's,
okay,
you're,
not
constraining
trust
anchor
to
it
must
be
a
certificate
or
a
public
key,
even
if
those
are
the
only
things
that
we
actually
use
right
now.
D
So,
okay,
all
right,
4.4,
personalization
data
old
text
implementations
must
support
encryption
of
such
personalization
data
to
preserve
the
confidentiality
of
potentially
sensitive
data
contained
within
it
and
must
support
integrity,
protection
of
the
personalization
data.
Okay,
now
talks
about
integrity
protection.
Why
not
say
that
an
implementation
must
support
mechanisms
for
the
confidentiality
and
integrity
protection
also,
it
seems
like
the
suit
firmware
encryption
document.
It
actually
talks
about
that,
and
should
you
just
reference
that
okay
ben
rad
commented
on
the
draft
17
version?
D
We
may
want
to
split
the
confidentiality
integrity,
protection
guidance
into
separate
clauses
or
even
separate
sentences
to
be
clear
about
what
behavior
is
required,
and
so
we
did
that,
and
so
18
actually
has
two
separate
sentences.
Implementations
must
support
encryption
to
preserve
confidentiality
of
such
partialization
data,
which
may
contain
potentially
contained
sensitive
data.
Implementations
must
also
support
mechanisms
for
integrity.
Protection
of
such
personalization
did
it
right.
So
the
addition
of
the
first
sentence
was
in
response
to
russ.
The
splitting
into
two
sentences
for
clarity
was
in
response
to
ben.
D
Okay,
keep
going
okay,
other
knits
rests
into
a
bunch
of
other
great
knits
that
we
incorporated
some
of
those
are
covered
here.
I
don't
know
that
all
of
them
are,
and
I
think
we
covered
typos
and
stuff.
So
we
broke
up
a
long
sentence
into
two
sentences:
the
need
to
address
okay,
so
I
guess
you
can
read
the
wall
of
text.
Russ
has
already
done
this,
but
these
are
at
least
the
first
one
was
just
purely
editorial.
D
You
can
see
the
fixed
in
17
there's
the
new
text
there.
The
problems
in
the
bullets,
above
the
other
hand,
require
a
new
protocol.
The
t
protocol.
This
is
the
motivation
text
in
the
in
the
introduction
right.
The
key
protocol
is
a
solution
for
dees
that
can
install
and
enumerate
tas
in
a
tee
secured
location
where
another
domain
specific
protocol
standard
that
meets
the
needs
is
not
already
in
use
right.
So
that's
the
the
updated
version
there
russ
had
a
comment
about
app
store
versus
trust
anchor
store.
D
The
term
seems
to
be
used
both
ways
and
in
one
place,
the
document's
very
general,
by
saying
an
app
store
or
other
app
repository
and
elsewhere.
The
term
trust
anchor
store
is
clearly
a
place
for
storage
of
trust
anchors.
So
we
added
in
the
glossary
an
actual
definition
of
app
store,
which
is
an
online
location
from
which
untrusted
applications
can
be
downloaded,
meaning
it's
not
the
purchased
definition
in
addresses
it's
the
storage
example
right,
so
in
that
sense,
the
term
store
is
the
same
meaning
as
trust
anchor
store.
D
Right
now
you
may
also
be
able
to
purchase
stuff
must
store,
but
that's
not
the
definition.
So
all
right
threat
modality
section.
One
said:
tes
are
typically
used
in
cases
where
a
software
data
asset
needs
to
be
protected
from
unauthorized
entities
that
may
include
the
owner
or
opponent
or
possessor
of
a
device.
D
Now
just
some
history
behind
that
sentence
right
there.
That
sentence
originally
appeared
in
a
confidential
computing
consortium
white
paper
and
actually
had
extremely
positive
feedback
from
people,
including
say
gartner
and
stuff
that
just
loved
that
sentence
that
how
that
one
was
phrased,
and
so
we
said:
okay,
great,
we'll,
we'll
reuse,
that
same
sentence
in
the
teap
architecture
document,
but
then
brendan
didn't
like
that
comment
and
and
freight
and
suggest
a
different
way
to
phrase
it.
D
D
Teas
are
typically
used
in
cases
where
software
data
assets
need
to
be
protected
from
unauthorized
access,
where
threat
actors
may
have
physical
or
administrative
access
to
a
device.
So
you
can
argue
his
definition
is
actually
more
precise,
and
so
that's
why
we
accepted
brandon's
proposal.
Okay,
next.
A
D
Don't
think
that's
the
last
slide,
I
think.
Okay,
maybe
this
is
the
last
slide.
Okay,
those
are
all
the
changes
to
the
architecture
document.
We
believe
we
have
completed
ad
review
and
everything
and
that
there
are
no
remaining
issues
on
the
document,
including
from
ads
or
ietf
or
anything
else,
and
so
we
believe
it's
ready
to
advance
to
the
next
stage.
If
you
go
all
the
way
back
to
the
timeline
slide,
I
forget
which
stage
it's
currently
sitting
in
the
data
tracker.
Maybe
nancy
remembers.
E
Paula,
so
I
will
just
look
over
what
ben
did
but
like.
If
you
resolved
all
of
ben's
issues,
then
I'm
assuming
we'll
just
move
the
document
forward.
So,
okay,
so
please
throw
it
in
my
queue.
Okay,.
F
G
G
G
So
the
first
one
was
many
of
the
discussion
from
the
update
from
the
last
iedf10113
was
related
to
corset
or
eat,
and
this
is
the
cypher
suit
how
to
handle
cypher
suit
between
the
tab
and
device.
G
By
reading
the
draft
and
the
first
one
was
if
the
site
query
response,
have
a
selected
cipher
suit,
but
it
it
was,
it's
it's
option,
member,
so
it
could
be
empty
and
then
what
the
time
could
think
about
it,
and
yes,
this
is-
was
updated
to
the
pull
request.
G
So
the
conclusion
was
with
the
four
or
five
people
in
the
hackathon
by
or
who
were
implementing
the
tip
was
just
tam
will
have
us
able
to
select
one
of
one
of
them.
The
times
have
sent
in
the
credit
request,
and
next
please,
the
technical
details
will
be
repeated
in
the
david's
slide.
G
G
The
draft
until
one
iedf113
was
explicitly
was
saying
the
in
the
text
of
the
query
response
as
a
evidence,
but
in
the
use
case
it
could
we
we
have
a
passport
model
and
we
also
have
a
back
background
check
model
to
support
at
the
station
and
we
wanted
to
accommodate
both
so
change
the
evidence
to
more
generic
name
as
a
attestation
payload
and
then
up
the
another
member
adding
at
the
station
payload
format
to
have
what
kind
of
attestation
payload
will
be
inside
of
at
the
station.
G
Payload
could
be
evidence
or
it
could
be
at
the
station
result.
G
G
G
G
G
Yes-
and
oh,
I
think
I
said
a
little
bit
too
much,
but
about
it
but
yeah
it
will
be.
Please
cover,
let's
go
through
it
in
the
davis
slides
and
this
one
is
yeah.
We
we
we
wanted
to
make
a
cypress
a
more
generic
way
and
was
keeping
from
the
last
time
the
discussion
was
getting
more
precise
and
then,
at
the
end
of
the
discussion,
the
two
days
was
getting
more
generic,
but
only
end
up
specifying
how
to
sign
on
the
cose.
G
Yes,
this
is
the
place
I
need
help
so
suit
manifest
github
and
also
in
the
tip
protocol.
I
copy
the
way
how
the
suit
manifests
suit,
manifest
github
splitting
the
cddr
format
in
the
draft
in
a
different
file
from
the
markdown,
because
that
will
be
easier
to
run
it
with
the
cddo
tools
and
and
and
then
it
was.
G
It
helped
a
lot
to
catch
many
of
the
cdo
for
format
or
for
cdd
grammar
era,
with
the
cddo
tools,
and
I
put
the
how
my
way
of
the
running
the
cdtl
and
appendix
I
think
it's
page
13
or
14
in
the
slide.
But
I'm
not
really
sure
what
is
the
right
way
to
use
the
cddo
tools,
but
at
least
the
my
way
of
using
it.
What
did
catch
few
things
in
the
cd
of
in
the
deep
draft
and
also
the
suit
manifest
draft?
And
I
we
made
a
pull
request.
G
A
Do
you
want
to
take
brendan
is
in
the
queue.
H
H
There
is
actually
a
note
in
the
suit
draft,
which
explains
that
you
need
to
concatenate
the
suit
or
sorry
the
cozy
cddl
to
the
end
of
the
suit
cddl,
in
order
to
make
it
a
valid
grammar.
I'm
not
sure
if
this
is
the
right
way
to
do
things,
but
that's
the
approach
that
we've
taken
so
far.
If
you've
got
any
feedback
on
on
that
approach
or
you'd
prefer
a
different
way
to
do
it,
then
please
do.
Let
me
know.
G
Hello,
yes,
so
I'm
concatenating
with
the
corsair
cdl
at
end
of
the
either
of
the
suit
manifest
cdd
or
two
protocol
cdo.
It
should
work.
I
I
have
tried
it
on
both
and
it
works
and
also
another
c
file.
Everything
is
dependent
in
these
two
many
cdfi
for
the
suit
report.
Cdl
and
some
other
one
had
to
be
concatenated
and,
for
example,
suit
report
is,
does
not
have
a
github
repository
containing
cddo
files,
so
I
had
to
make
it
manually.
G
So
I
really
don't
know
what
will
be
the
right
way,
but
for
the
suit
manifest
just
the
kose
tags
was
only
required
for
line
which
is
used
in
the
suit
manifest.
So
I
just
added
manually
so
about
it.
Yeah
concatenating
entire
courses,
cdd,
is
also
fine,
but
I
oh
yes,
but
I
I
think
it
would
be
nice
to
put
it
in
the
somewhere
in
the
read
me
or
somewhere,
so
that
people
could
reproduce
the
procedure
I'm
using
or
brandon
using
it.
H
Okay,
I
guess
I
should
mention
as
well
that
the
the
cozy
draft
does
actually
have
instructions
for
how
to
extract
the
cddl
from
it,
though
it
is
a
little
unusual.
I
haven't
seen
that
approach
in
any
other
draft.
C
G
C
A
B
Michael
richardson,
so
what
I'm
hearing
is
a
couple
of
things,
one
of
which
is
that
we're
lacking
a
clear
include
mechanism
in
the
cddl,
and
I
think
that
that's
you're,
not
the
only
one,
I
think
that's
well
known
in
other
places.
The
way
that
I've
dealt
with
this
is
that
yes
put
the
cddl
file
as
a
separate
file
include
it
from
the
markdown
there's
a
markdown
mechanism
to
include
put
the
generation
of
your
complete
cddl
in
your
make
file
from
the
markdown
you
can
append
to
that.
E
B
It
in
your
own
thing,
concatenate
it
together
that
that
records
all
the
process,
and
then
you
may
want
to
check
them
in
because
you
might
not
want
to
depend
upon
suit.
Having
not
changed.
You
might
want
to
explicitly
update
it
or
the
way
around
up
to
you,
but
that's
what
I've
done
in
the
past
and
so
far,
it's
better
than
trying
to
pull
it
out
of
the
file
just
leave
it
on
the
disk
and
there's
also
some
cddl
tools
that
will
produce
c
header
files,
for
instance,
which
I
found
really
really
useful.
G
Yes,
for
the
procedure:
what
do
you
just
describe?
Some
of
the
cdd
of
our
is
not
on
the
github
or
any
places
so
just
to
go
after
the
data
tracker
and
read
the
draft
and
then
extract
inside
the
cdl
definition
from
the
draft
so
and
that's
what
so.
B
So,
michael
again,
what
I'm
actually
suggesting
is
that,
when
that
happens,
that
you
go
and
poke
the
people
in
the
other
place
to
do
the
same
thing
right.
So
that
said,
everyone
back
has
a
cd
dfl
that
you
can
pull
out
of.
You
know,
get
raw
user
pages
or
something
yes
and
you'll
get
the
right
thing,
and
I
don't
think
that's
a
terrible
thing
and
everyone
will
be
like.
Oh
yeah,
that's
a
good
idea.
Yeah.
G
And
then
everybody
will
be
happy
yes,
and
also
when
the
con,
when
before
running
in
the
c
cdo
tools
need
to
concatenate
all
the
cddf
file
and
how
to
order
the
cdda
file
file
in
the
order.
It
changes
how
to
catch.
The
grammar
mistake
too.
So
that's
something
I
I
I
need
to
yeah.
We
need
to
think
talk
with
the
people
in
the
cdto2.
G
That's
my
impression,
and
so
the
summary
is
yes.
We
really
got
a
lot
of
changes
in
first,
two
days,
saturday,
sunday,
this
idf114
so
great
progress.
Many
issues,
11
issues
was
improved,
nine
pull
requests
was
made
and
and
as
far
as
we
know,
we
haven't
tried
all
the
implementation.
Yet,
but
probably
it's
okay
like
at
the
moment,
I
could
see
corsair
supporting
course
and
e
and
t
protocol
is
pretty
much
should
be.
Okay,
yes,.
G
And
the
appendix
has
some
few
things
I
did.
You
want
to
cover
the
now
to
go
through
just
showing.
What's
in
it's
in
the
page
yeah.
This
is
the
my
my
this
was
my
my
procedure
was
running
during
the
hackathon,
so
it's
yes,
probably
need
to
explain,
do
have
some
of
the
explanation
and
somewhere
in
the
documentation
in
the
future.
D
We
go
oh.
D
Don't
confuse
me
with
that
other
guy
named
ming,
who
looks
a
lot
like
me.
I
will
say
at
the
hackathon
I
I
think
we
have
six
known
implementations
from
six
different
implementers.
D
Five
of
them
were
sitting
at
the
table,
ming
being
the
sixth
one
who
is
not
at
the
table
that
we
know
of,
and
so
that
means
that
we
spent
a
lot
of
time
talking
about
what
we
want
to
do,
and
we
even
made
a
breaking
change
here,
because
we
all
agreed
to
break
our
stuff
right,
that
we
would
all
change
our
implementations,
and
so
it
was
very
productive,
and
I
think,
for
the
first
time
when
I
posted
this
the
list,
it
usually
what
happens
at
a
hackathon
is
we
come
out
of
the
hackathon
with
a
bunch
of
issues
to
discuss
and
try
to
figure
out
what
to
do,
given
that
we
had
all
the
implementers
there
at
least
one
of
them
there.
D
We
actually
spent
a
lot
more
time
talking
about
what
the
fix
and
the
spec
would
be
and
generating
the
pro
requests
against
the
spec.
So,
for
the
first
time
ever,
we
walked
out
of
the
hackathon
with
zero
open
issues
that
didn't
already
have
text
in
the
spec
in
the
github
copy.
Okay,
never
happened
before
the
disadvantage.
D
Is
we
spent
less
time
on
doing
the
actual
code
for
the
what
we
did
in
the
put
request,
but
it
does
mean
that
we
actually
now,
of
course
that
was
a
statement
in
time,
because
since
then,
we've
had
three
issues
come
up
right
and
so
we'll
talk
about
those
two.
But
I
just
want.
D
That
we
had,
we
felt
like
we
accomplished
stuff
and
we
felt
like
we
were
gonna
make
progress
and
we
felt
like
this
deck
was
stuck
with.
The
spec
was
becoming
a
lot
more
stable
because
we
were
able
to
walk
out
of
the
room,
saying
I
don't
know
any
open
issues
right
now
and
then
we
filed
three
later
okay.
So
anyway,
the
hackathon
was
a
great
hackathon
all
right.
It.
A
A
Yeah,
so
send
them
to
if
you
have
an
implementation
that
you
want
to
share,
send
them
to
my
brain's,
not
working
keep
chairs
at
iutf.com
yeah.
D
Since
some
are
implementations
of
the
tams,
some
are
implementations,
the
tp
agent
and
so
on.
Since
there's
multiple
roles
right.
Okay,
this
slide
is
the
things
that
I
am
not
going
to
talk
about.
Although
akira
talked
about
some
of
them
in
the
hackathon
stuff.
These
are
things
that
were
already
discussed
last
meeting
that
we
had
resolutions
that
we
agreed
on
during
the
last
teep
meeting,
and
we
did
those.
D
So
I'm
not
going
to
repeat
those
in
the
interest
of
time
we're
going
to
talk
about
the
things
that
we
didn't
already
have
agreement
on
as
of
last
meeting.
So,
but
if
you
have
any
questions
on
these,
that
was
in
the
hackathon,
where
akira
talked
about
at
least
three
of
the
ones
that
are
on
here,
so
okay,
so
next
slide
now
we're
going
to
get
to
the
ones
that
are
the
new
issues
since
last
meeting,
some
of
which
came
up
during
the
hackathon.
Some
were
previous
to
the
hackathon.
D
The
first
one
was
ayanna
did
the
early
review
and
his
earlier
view
said:
hey
we
see
the
the
audit
consideration
section
has
a
section
that
proposes
a
freshness
mechanism
registry
which
protocol
page
on
the
internet
site
has
a
list
of
registries
right,
a
list
of
pages
where
each
page
can
have
multiple
registries
on
the
same
page
and
they
say
which
page
should
this
go
on?
D
I
said:
well,
there's
not
currently
a
tea
parameters
page,
although
they
probably
will
be
because
we're
asking
another
one,
but
it's
at
the
right
page.
So
before
responding
to
ayanna,
we
discussed
as
the
table-
and
I
discussed
it
with
one
or
two
other
folks
in
the
rats,
but
not
in
the
rats
working
group
so
far,
which
is,
should
this
be
a
teep
page
or
is
the
freshness
mechanism
actually
more
of
a
rat's
thing
of
which
teep
uses
a
couple
values
out
of
it?
D
Okay,
this
notion
of
fractions
mechanisms
we
said-
may
not
actually
be
a
t
protocol
specific
thing,
and
should
we
have
a
common
registry
and
t
can
just
use
values
out
of
that
registry
just
like
we
do
for
say,
cose
types
and
algorithms
and
things
like
that
where
we
use
values
out
of
another
registry
and
so
option,
one
is
to
respond
to
iana
and
keep
the
text
the
document,
as
is
to
say
this,
goes
on
a
new
page
for
t
parameters
and
we've
got
more
than
one
registry
there
anyway
and
option
two
is
to
say:
let's
move
that,
and
so
the
proposal
that
hank
made
was:
let's
move
that
to
the
reference
interaction
models
and
then
in
the
brett's
working
group
meeting
on
what
was
it
tuesday
or
whatever?
D
We
covered
this
in
the
open
mic
section
of
the
rat's
working
group,
okay,
and
so
what
we
did
is
we
posted
a
per
request
that
removes
this
freshness
mechanism
registry
from
the
t
protocol
and
instead
adds
a
reference
to
that
draft
that
it
doesn't
yet
appear
in
okay.
So
that's
in
the
github
copy,
okay,
which
is
kind
of
a
dangling
reference
waiting
for
the
same
text
to
be
added
into
the
reference
interaction
models
in
rats.
To
then
make
it
be
complete,
so
the
information
isn't
lost.
So
that
is
the
proposal.
The
draft
isn't
posted.
D
D
So
the
proposal
here
is
to
move
it
to
the
reference
interaction
models
document.
Oh
crap,
okay,
unless
we
hear
objections
since
we
had
all
but
one
of
the
implementers
at
the
table
and
the
implementers
thought
this
was
a
good
idea,
then,
as
well
as
the
author
of
the
reference
interaction
models,
which
is
the
same
table.
Thank
you.
Hank.
D
So
we'll
go
on
to
the
next
slide,
then
I'm
not
hearing
any
objections
there.
Next
one
should
be
on
okay,
so
now
we're
going
to
get
into
the
attestation
category
of
stuff,
since
a
bunch
of
the
implementers
were
starting
to
work
on
actual
attestation.
So
one
of
those
issues
is
this:
one,
that's
caught
in
the
in
the
github
repository
the
issue
was
labeled
may
require
one
more
message
for
attestation
and
to
explain
this
one.
D
I
want
to
go
back
to
a
slide
from
ietf105,
so
the
little
thing
in
the
box
is
the
actual
slide
from
that
presentation,
and
so
you'll
see
some
old
old
labels
where
it
says
otrp
right
here
right,
that's
way
back
in
the
day
where
we're
using
that
acronym.
That's
now
deep
here,
okay,
but
this
was
a
example
flow
that
is
not
a
by
constraint.
This
is
to
say
here
is
a
way
to
compose
people
with
other
things
right
as
an
example.
D
Okay,
and
this
way
of
composing
stuff
right,
you
attest
so
in
between
the
verifier
and
the
tester.
So
this
part
right
here
is
a
passport
model
right.
Sorry,
this
part
right
here
you
send
it.
This
is
a
background
check
model.
I
misspoke
right.
It
says
the
tester
sends
evidence
through
the
relying
party
which
is
the
tam
off
to
a
verifier.
The
verifier
sends
back
an
attestation
result
which
says
yep,
you're,
good
or
you're,
not
good.
D
If
you're
not
good,
then
of
course
the
tam
kicks
off
remediation
steps
to
go
and
do
appropriate,
installs
or
updates,
or
whatever
okay.
But
in
the
case
that
says
yes,
you're
already
good,
there's
nothing
for
you
to
do
what
happens?
Okay
here,
we
said
since
you're
using
this
in
the
in
in
this
mode
here,
if
you
can
pass
back
the
attestation
result
that
says
you're
good.
D
You
can
then
present
that
as
the
passport
model
to
other
aligned
parties,
that's
what
this
example
is
showing:
okay,
just
a
way
of
getting
the
passport
model
for
this
one
with
the
tam
as
being
an
intermediary
in
one
leg,
it's
just
a
way
of
composing
a
hybrid
and
using
two
different
protocols
together.
If
you
wanted
to
do
this,
okay,
you
need
a
way
of
carrying
this
attestation
result
back,
okay,
and
what
we
observed
is
that
there's
no
messaging
to
do
that.
Okay,
even
though
we
talked
about
that,
we
could
do
this
in
iutf105
right.
D
Okay,
so
what
did
we
do
to
fix
this
because
we
all
agreed
gosh?
This
would
be
possible.
This
would
be
a
good
thing
to
do.
This
originally
came
up
in
the
context
of
somebody
implementing
local
attestation
with
sgx,
but
we
decided
it's
not
specific
to
local
attestation,
there's
a
slide
that
had
exactly
the
same
problem
at
105
right.
So
so
here's
what
we
did
so
this
is
in
the
update
message.
D
Okay,
normally
the
update
message,
saying:
here's
something
to
install
or
uninstall
okay,
but
you'll
notice
that
the
manifest
list
here
is
optional,
which
means
you
can
send
an
update
message
with
no
manifest
list.
What
does
that
mean?
They
said?
Well,
we
can
just
use
the
update
message
to
say.
Well,
then,
you
can
just
include
the
attestation
payload
and
use
the
existing
message.
D
Okay,
just
put
this
instead,
so
you
can
do
this,
you
can
do
them
both
okay,
you
say
you're
good,
but
then
here's
something
else
to
install
too
right,
and
so
this
seemed
to
be
the
natural
way
to
do
it,
and
so
we
added
these
fields
here
which
match
how
it
appears
in
the
query
response
message
when
you're
sending
stuff
to
the
tam
okay,
and
so
we
took
the
same
definitions
for
these
and
copied
them
into
this
message,
and
we
said
yep.
This
seems
to
be
the
nice
simple
way
to
do
it.
D
That
does
not
require
adding
any
new
messages.
You're
just
now
able
to
send
a
message
that
you
couldn't
send
before
right.
Okay,
so
that's
what
we
did
in
the
github
copy
of
the
spec.
If
you
look
there,
so
I
just
showed
you
what
the
main
difference
was:
okay,
next
one
and
akira,
I
talked
about
this
one
a
little
bit
as
far
as
what
the
problem
was,
which
is:
can
you
go
back
for
just
a
second
to
the
ietf
105
slide?
Just
because
I
can
point
to
the
diagram
there
for
a
second.
D
So
that's
two
slides
back
in
there.
The
thing
that
goes
back
and
forth
between
the
teep
and
the
tam
and
stuff
was
either
okay.
I
guess
you
don't
have
to
was
either
attestation
result
or
evidence
depending
on
whether
you're
using
at
that
station,
I'm
afraid
it's
going
to
crash
again.
Okay,
don't
worry
about
it!
D
You
can
use
the
there
we
go.
You
can
use
the
background
check
model
through
here,
in
which
case
you're
passing
evidence
through
okay.
You
can
also
use
it
in
a
background
check
model
right,
just
pretend
that
this
was
a
tam
over
here
and
you're
passing
an
attestation
result
to
it,
and
so
how
do
you?
How
do
you
specify,
which
is
the
case?
Okay,
you
can
go
forward
now
back
to
the
slide
that
we're
on
slide,
eight
yeah,
okay,
so
and
the
spec
didn't
actually
say
right.
You
can
kind
of
infer
right,
but
it
wasn't
explicit.
D
So
we
added
this
text
and
so
here's
the
rule
that
we
agreed
on
that
says:
okay,
there's
the
attestation
payload
format
and
attestation
payload
payload
format
is
a
media
type
plus
parameters
right.
It's
like
a
content
type
in
http,
for
example,
right.
Okay,
so
you
can
look
at
that
and
if
it
contains
something
you
recognize
and
as
an
assassination
result,
then
it's
an
attestation
result.
D
If
it's
anything
else,
it's
evidence
to
pass
on
to
a
verifier
okay
and
that's
because
the
tam
is
going
to
get
attestation
results
at
the
end
of
the
day
either
he
gets
it
directly
from
the
heap
agent
or
it
gets
it
from
the
verifier.
So
he's
looking
for
an
active
station
result
in
a
particular
format.
Okay,
so
he
says:
if
I've
already
got
what
I
need,
I'm
done.
D
If
I
don't
have
what
I
need
I'll
ship
it
off
to
a
verifier
and
ask
them
hey,
can
you
translate
this
in
the
thing
that
I
need
an
attestation
or
something?
So
that's
what
the
text
now
says?
Okay,
so
once
you
get
the
attestation
result,
okay,
then
we
added
in
more
explicit
text
as
to
what
to
do
about
that.
Okay,
when
you
get
the
attestation
result
response
from
the
verifier
there's
three
things:
there's
three
states
you
could
be
in
okay.
If
the
attestation
result
response
on
the
verifier
says,
the
guy
is
bad.
D
Okay,
in
which
case
you
can't
trust.
The
rest
of
the
query
response
right
because
it
came
from
a
cheap
agent
that
could
be
compromised
or
could
be
out
of
date.
Okay,
so
that
means
you
can't
trust
the
list
of
trusted
components.
That's
in
the
teat
message:
you
can
only
trust.
What's
in
the
attestation
results?
Okay,
so
in
this
case
well,
you
could
try
to
trust
it,
but
there's
not
good
security
considerations
and
accepting
something
they
just
failed
attestation
right.
So
you
can't
believe
it
okay.
D
So
in
that
case
you
can
try
to
update
the
teep
agent
and
all
the
dependencies,
even
if
the
deep
agent
claims
to
be
up
to
date.
Okay,
if
there's
information
inside
the
attestation
result,
that
tells
you
which
pieces
are
good
and
which
pieces
are
bad.
You
can
use
that
okay,
but
you
can't
use
it
just
because
it
appeared
in
the
deep
message.
Okay,
so
that's
case,
one
case
two
is
where
the
verifier
said:
the
type
agent
is
good.
D
You
can
trust
them,
meaning
you
that,
according
to
the
verifiers
policy,
he's
good
and
trustable,
and
you
can
then
choose
what
to
do
with
that
information
right.
You
can
choose
to
trust
him.
Okay,
but
the
information,
the
teat
message
says
that
he's
out
of
date,
like
he's
missing
some
things,
he
should
have
or
he's
saying
I'm
done
with
this
thing
that
I
was
using
before
and
so
then
I
can
just
accept
the
stuff,
that's
in
the
team
message
and
do
updates
according
to
that.
D
Okay-
and
the
third
case
is
where
attestation
succeeded
and
the
t
message
also
just
passes
policy
nothing
to
do.
Okay,
so
in
both
of
the
first
two
cases,
you're
going
to
send
an
update
message,
but
what
you
put
in
there
is
based
on
different
pieces
of
information.
This
one
is
based
on
the
attestation
results
this
and
it's
based
on
the
cheap
message.
D
Number
three:
there's
no
update
message
necessary:
it's
nothing
to
do
other
than
perhaps
pass
back
that
attestation
result,
as
shown
in
the
previous
slide.
Okay,
if
you're
in
that
mode,
make
sense.
Okay,
that's
that
was
issue
224
next,
so
we
had
this
discussion
and
I
think
we
even
pinged
brandon
brendan
during
the.
I
think
it
was
during
the
hackathon
who
was
online.
The
suit
component,
identifier,
isn't
unique
is
what
the
label
of
the
issue
was.
Okay,
I
forgot
daniel's
on
the
queue
the
q.
D
The
specific
media
type
will
say
that
it's
an
attestation
result,
so
in
this
case
the
specific
media
type,
the
there's
a
media
type
and
parameters
the
and
this
references
in
rats.
There's
a
document.
That's
proposed,
as
a
working
group
document
that
I,
on
behalf
of
the
t
protocol
implementers,
said:
please
adopt
this
in
rats
right.
It's
lawrence,
lundblade's
document
about
eat,
media
types,
and
so
the
media
type
itself
is,
you
know,
e
cwt
or
whatever,
okay
and
then
there's
a
parameter
that
says
which
profile
it
is
okay
and
cheap
document.
D
We
specify
any
profile,
and
so
the
full
attestation
payload
format
is,
you
know,
application
slash,
eat,
dash,
dot,
cbt,
semicolon
profile
equals
the
name
of
the
e
profile,
and
that
means
it's
an
e
profile
for
attestation
results
right.
So
that's
the
one
that's
well
known,
you
could
define
another
well-known
one
in
addition
to
that,
but
that's
at
least
one
example,
and
so
in
the
implementation
we
said,
if
it's
equal
to
exactly
that
string,
then
call
our
e-code
else
ship
it
off
to
a
verifier.
D
Okay,
all
right.
So
let's
go
forward.
Okay.
So
in
here
what
was
in
the
t
protocol?
Well,
you
can
see
the
old
right.
There
was
a
list
of
components
which
each
had
a
tc
info
structure.
The
tc
infrastructure
is
here
in
the
lower
left
corner
of
the
slide,
which
says:
here's
a
suit
component
identifier
and
a
management
sequence
number
okay,
and
so
we
said
well
consider
the
case
where
somebody
gets
a
new
component
on
the
device
such
as
via
sneakernet.
D
It
didn't
come
through
the
tam
right,
okay,
and
so
it
replaces
a
previous
implementation.
One
example
of
a
suit
component
identifier
is
a
file
system
path.
Okay,
so
let's
say
you
replace
the
component
sitting
in
a
file
system
path
with
an
alternate
implementation,
say
you
replace
my
implementation
with
a
curious
okay,
it's
a
different
component
right.
It
may
have
the
same
manifest
sequence
number
out
of
the
other
numbering
space
right
as
the
other,
manifest
sequence
number
or
whatever.
D
So
if
it
goes
in
the
same
file
system
path-
and
it
has
the
same
version
number
of
the
other
manifest-
then
of
course,
if
all
you
do
is
report
this
combination
here,
the
tam
can't
actually
distinguish
between
the
case
that
it
still
has
the
thing
that
input
there
versus
been
replaced
by
something
else
that
happens
to
have
the
same
values.
As
we
said,
that's
bad,
okay.
D
We
need
to
fix
that
okay,
and
so,
instead
we
said
well,
we
looked
at
the
suit
report
document
which
we
already
referenced
and
it
has
system
property
claims
with
the
stuff
on
the
right
there:
okay,
which
has
a
system
suit
component
identifier
and
a
set
of
suit
parameters,
okay,
which
includes
the
ability
to
have
things
like
a
digest,
but
rather
than
us,
defining
our
own
thing.
Let's
just
do
what
we're
already
doing
in
this
in
the
seat.
Reports
draft,
which
we're
already
using
anyway
right
less
code
copy
code
from
here,
call
that
same
thing.
D
Okay,
so
that's
why
we
replace
tc
info
with
system
property
claims
here
and
when
you're
reporting
in
the
teep
message.
Here's
all
the
other
tas
that
are
installed
on
my
box.
Okay,
nobody
in
queue,
okay,
I'll
keep
going
issue.
189
akira
mentioned
reliably
getting
te
hardware
properties.
This
is
the
way
it's
called
in
the
github
issue,
and
so
to
summarize
what
this
one
is.
There
are
four
different
ways
to
get
that
you
could
possibly
maybe
get
properties
of
the
te
and
a
career
response,
and
so
properties
of
a
tv
mean
things
like.
D
D
First,
one
is
you
could
get
it
from
attestation
results?
Okay,
if
there's
actually
e
claims
or,
if
you're
not
using
eat,
if
you're
using
say
sgx
reports
as
a
custom
format,
you
could
get
it
in
there
if
it's
in
there,
okay
and,
of
course,
that
answer
for
the
tam
to
get
it
means
it
has
to
be
in
the
attestation
results:
okay,
not
just
the
evidence.
So
it
means
the
verifier
has
to
be
responsible
for
copying
the
information
out
of
the
evidence
into
the
attestation
result.
Just
so,
the
time
can
get
it.
D
Okay,
that's
absolutely
possible,
but
it
places
this
extra
dependency
on
the
tam
doing
things
that
may
cause
interoperability
issues
if
you're
trying
to
use
a
tan
that
doesn't
do
that,
okay
or
perhaps
on
on
a
different
administrator
of
the
the
one.
That's
administrated,
the
verifier
versus
the
administrator,
the
tam
okay.
D
So
that's
possible
right,
but
it's
this
extra
burden
says
this
case
there
way
to
get
around
that
second
possibility
is
you
could
get
it
out
of
suit
reports
right,
because
you
can
pass
that
in
you
know
when
I
boot
up
and
I
pass
stuff
to
the
to
the
tam.
As
you
know,
here's
my
current
state
and
so
on.
I
could
put
in
the
suit
report.
Okay.
D
Well,
this
is
great,
if
you're,
generating
suit
reports
as
part
of
your
boot
sequence
right,
which
a
lot
of
suit
implementations
do
that,
especially
in
iot
space
right,
brenda's
design
and
the
suit
reports
is
to
accommodate
people
who
do
explicitly
that,
right
as
to
say
if
I
had
an
error,
booting
or
whatever,
I
can
generate
your
suit
report.
That
says
that
okay,
but
doing
it
here
says
well
now
I've
got
to
require
that
all
te
implementations
generates
your
reports
at
t
at
boot
time
or
you
know,
launch
time.
D
Okay,
boot
is
not
necessarily
the
right
term
for
like
sgx
right
at
launch
time
load
time,
and
so
that
may
be
too
burdensome
for
some
teas,
like
sgx,
for
example,
and
by
the
way
draft
009
of
the
heat
protocol
actually
said
to
do
this
one,
and
we
said
maybe
that's
too
burdensome,
especially
as
we
had
sgx
implementers
at
the
table.
That
said
gosh.
This
is
really
hard
for
me
to
implement.
So
we
said:
okay,
maybe
that's
not
the
right
one
either.
D
The
third
possibility
is
neither
of
those
but
there's
a
different
field.
That's
the
tc
list,
that's
the
one
I
showed
on
the
previous
slide,
but
that's
meant
for
components
that
can
be
updated
by
via
teep
right.
That's
trusted
components,
it's
not
for
the
hardware
right,
so
it'd
be
kind
of,
maybe
arguably
a
misuse
of
that
field,
because
if
you
can't
update
it,
then
maybe
it's
not
a
trusted
component.
We
didn't
define
trusted
component
as
being
something
that
was
hardware.
We
said
it's
something
that
can
be
updated.
D
Okay,
so
that's
probably
not
the
right
place
either.
So
that
left
us
with
some
new
field.
Okay,
and
so
that's
as
the
implementer.
As
we
said,
this
is
going
to
be
the
easiest
one,
that's
the
most
extensible,
because
it
doesn't
have
these
other
dependencies.
It
works
in
all
these
other
cases,
and
so
we
came
up
with
this
one
and
it
reuses
that
system
property
claims
that
we
just
showed
in
the
previous
slides.
We
had
a
new
field.
D
That
said,
you
can
do
this
directly
and
put
it
in
the
system
property
claims,
even
if
you're
not
doing
a
full
suit
report.
You
just
have
that
one
little
snippet
that
was
defined
by
the
suit
report
spec,
but
it's
not
really
specific
to
suit
reports.
So
that's
what
we
did
and
the
implementers
other
than
all
the
implementers
who
were
at
the
table
anyway
said
yeah.
Let's
do
it
this
way.
D
The
system
property
claims
we're
saying
is
technically
not
really
specific
to
suit
reports.
Okay,.
B
B
Else
I'll
ask
on
the
list
then,
but
I'm
just
I
just.
I
think
that
there's
some
valuable
insight
into
what's
going
on
that
might
be
it's
worth
worth
worth,
having
a
deeper
understanding
behind
this
decision
for
later
on,
because
I'm
sure
we'll
have
someone
that
goes,
you
know
from
risk
five
or
something.
Well,
that's
silly!
We
just
do
it.
That
way
I
mean
you
know,
but
but
but
there's
probably
something
deeper
there,
as
I
just
think
we
need
to
capture
it.
D
Yes,
the
suit
working
group
is
later
today.
There
is
a
suit
hackathon
report
on
the
agenda.
I
don't
know
that
this
point
is
on
there,
but
probably
should
be
to
your
point,
michael
so
because
I'm
sure
the
suit
working
group
would
love
to
hear
that
feedback
to
say.
Is
there
something
we
should
do
in
the
shoot
reports
document
right?
D
H
So
generating
a
suit
report,
as
as
the
first
thing
essentially
implies
two
pieces
of
information.
The
first
is
that
you
are
booting
your
device
use
or
or
invoking
an
image
using
suit,
using
a
suit
manifest.
If
you're
not
invoking
your
image
using
a
suit
manifest,
then
it's
probably
not
the
right
answer
and
that
that
would
be
a
good,
probably
argument
to
to
look
somewhere
else.
H
That
said,
I
would
hope
that,
if
you're
not
using
a
suit
manifest
that
you
can
get
attestation
results
because
I'm
not
being
able
to
get
the
this
information
and
attestation
revolt
results
is
a
bit
surprising
to
me
now
to
the
other
point
about
using
system
property
claims.
That
also
seems
to
be
a
slightly
strange
choice
to
me,
because
those
system
property
claims
are
they're
they're.
H
The
direct
result
of
the
suit
reporting
policy,
that's
exactly
the
reason
that
they
exist
and-
and
so
I'm
not
certain
that
that
is
quite
what
you're
looking
for.
I
wonder
if
maybe
I'm
just
borrowing
attestation
claims
from
rats,
even
if
you're
not
using
the
attestation
results,
might
be
the
right
answer.
H
D
Okay,
I
I
I
agree
with
the
first
thing
that
brennan
said
that
makes
sense
about.
You
know
that
if
you're
not
using
the
suit
directives
to
do
the
load
or
whatever,
then
it
doesn't
make
sense
to
have
a
suit
report
to
report
which
which
directive
was
an
error?
So,
but
why
you're
not
using
the
suit
report
to
put
as
more
interesting
questions?
So
all
right,
so
I
see
the
queue
is
empty,
so
I'm
going
to
go
on
to
the
next
one,
which
is
very
similar,
except
for
this
one.
D
Unlike
hardware,
this
one
is
reliably
getting
to
e
firmware
properties.
So
this
one
is
an
updatable
component,
okay,
but
otherwise
it's
very
similar
that
you
have
the
same
four
possible
answers
of
agitation
results,
your
reports,
tc
list
and
some
new
field
to
get
firmware
properties.
Okay,
because
often
you
have
a
trusted
application
that
depends
on
you
know
particular
version
of
firmware
being
installed
either
for
security
purposes
or
for
functionality
purposes
that
add
some
capability
that
you
need.
Okay,
so
the
same
four
things
exist.
D
D
During
the
hackathon
we
observed
that
those
strings
are
defined
as
being
human,
readable,
strings,
right,
they're
meant
for
human
display
and
therefore
they
may
not
be
reliable
enough
for
machine
processing
to
say
is
this
thing
up
to
date,
or
not
I
mean
you
can
certainly
do
a
byte
for
a
byte
comparison
or
something
like
that,
but
even
that
could
be
error
prone.
If
say
you
patch
something
and
the
human
doesn't
actually
change
the
version
string.
D
So
it's
not
like
it's
a
digest
or
whatever.
So
if
they
don't
change
it
or
whatever,
then
it's
not
reliable.
So
we
said
if
it's
not
really
designed
for
human
processing,
that's
probably
not
the
right
claim
and
we
had
hank
at
our
table
and
he
suggested
the
manifest
claire.
Sorry
lawrence
was
at
the
table
and
he
said
yes,
the
manifest
claim
was
the
right
one.
So
we
said
hey
that
one
looks
great,
so
the
manifest
claim
is
great
for
machine
processing.
D
So
if
you
have
questions
on
that,
make
sure
you're
at
the
suit
working
group,
other
possibilities
are
the
suit
reports
for
getting
the
firmware
properties.
This
does
have
the
same
constraint
that
says
you
can.
That
requires
a
generating
suit
reports
at
say
firmware.
You
know
start
time
that
could
be
too
burdensome
for
some
tes,
like
you
know,
sgx,
which
does
have
firmware,
but
but
draft209
allowed
this
too
right
and
of
course
we
didn't
remove
the
stuff
that
was
allowed
right,
so
he
could
still
do
that,
but
maybe
not
saying
that.
D
That's
the
only
way
to
do
it.
So
the
tc
list-
okay,
unlike
the
hardware
properties
right
that
didn't
apply
to
there
because
tc
list
was
for
things
that
could
be
updated
and
firmware
can
be
updated
so
that
one
you
can
do,
but
only
if
the
cheap
agent
is
healthy,
because
otherwise
you
can't
trust
that
list
right,
and
so,
if
the
firmware
is
out
of
date,
then
you
can't
look
at
that
list
to
tell
whether
you
need
to
update
the
firmware
right,
because
you
can't
trust
it.
D
So
really
the
manifest
part
here
inside
the
attestation
results
seem
to
be
the
best
answer
out
of
all
those,
and
so
that's
what
we
changed
the
document
to
do
so
next
slide.
You'll
see
the
details
there.
Okay
in
the
eat,
claims.
Okay.
This
is
the
the
teep
profile
for
attestation
results
using
eat
in
cwt
format,
okay,
so
this
is
the
set
of
claims
that
are
talked
about
in
the
eat
profile,
so
draft
08.
This
is
as
of
last
ietf
meeting
right.
D
It
looked
this
way
and
we
still
had
one
reference
to
an
in
into
an
individual
document:
okay,
because
there's
nothing
to
point
to
in
the
eat
spec
at
that
time.
Okay
draft:
oh
nine
references,
the
last
eat
document
as
of
the
internet
draft
deadline,
where
a
couple
changes
were
done.
There's
now
hw
model
claim
in
draft
09..
Well
I'll
talk
about
that
in
a
second
here
that
actually
does
put
in
what
we
need.
Okay,
so
that
means
we
could
get
rid
of
the
individual
draft
reference
and
reference
the
working
group
document.
D
Okay,
so
that
one
is
a
different
claim.
It's
the
now
the
one
in
the
document
that
didn't
exist
before
and
then
you
can
see.
That's
the
really
the
only
change
between
node,
8
and
09.
The
changes
between
09
and
the
github
copy.
Okay,
well,
hw
model
is
the
label
in
the
json
okay,
which
we
don't
use
json
at
cbor
right.
So
we
fixed
that
to
be
the
longer
version
guys.
The
json
is
off
an
abbreviation
for
the
real.
You
know
claim
name
if
you
will
so
the
claim
name.
D
We
use
like
the
the
seabor
label
right,
which
is
hardware
model,
so
that
one
is
just
a
simple.
You
know.
Text
change
in
the
document
doesn't
affect
implementations,
okay
chip
version
and
hardware
version.
Okay,
the
eat
document
since
changed
to
have
hardware
version.
The
chip
version
was
now
that
that
label
was
gone.
It
still
has
the
same
meaning
right,
but
that
changed
in
the
document.
D
Since
you
know
the
the
since
we
wrote
draft
09,
so
we
just
updated
that
one
to
retain
consistency
with
the
change
in
the
document
and
the
last
one
is
the
actual
semantic
change.
Okay,
where
we
change
the
software
name
and
version
to
the
manifest
one
right
and
that's
what
I
covered
in
the
previous
slide
right.
So
the
github
copy
we
think
is
now
the
correct
list
and
09
is
now
the
incorrect,
or
at
least
out
of
date,
list
of
the
labels.
D
So,
okay
next
slide,
which
is
the
last
one
on
the
same
topic
inside
the
profile.
Okay,
it
has
it
every
profile
can
specify.
What's
the
required
claims,
prohibited
claims
and
additional
claims
or
optional
claims.
Okay,
as
a
reminder
today,
there
are
no
required
claims.
Okay,
meaning
you're,
allowed
to
say
attestation
results
are
good
or
bad.
You
know
you
can
use.
You
know
the
air
for
si
and
just
say
you're
good,
you're,
not
good,
and
if
you're
good,
that
means
your
teep
agent
is
healthy
and
you
can
trust
it's
it's
it's
it's
information
messages.
D
You
know,
it's
query,
results,
curry
response,
okay,
and
if
it
says
no,
that
means
you
can't
trust
anything
in
the
core
response.
You
can
do
that.
Okay,
that's
why
required
claims
is
none!
Okay,
if
you
want
to
be
more
detailed,
though
there
might
be
some
reasons
to
do
that.
Okay,
and
so
that's
why
these
optional
claims
are
in
here
and
the
text.
D
That's
in
the
architecture
document
that
we
have
consensus
on
talks
about
what
types
of
information
should
be
in
there
and
that's
where
the
list
of
optional
claims
comes
from,
because
if
you
want
to
be
more
efficient
okay,
so
these
are
for
efficiency,
not
correctness,
okay,
so
the
claims
in
the
previous
slide.
Everything
on
that
whole
table
is
for
efficiency,
okay,
and
so
that,
as
a
tam
you
can
do.
You
can
not
update
things
that
don't
need
to
be
updated.
Okay,
so
the
attraction
result
says
you
are
bad.
D
Do
you
have
to
touch
the
teep
agent
and
the
you
know
the
secure
world
operating
system
and
the
trusted
firmware,
or
only
some
subset
of
those?
That's
where
you
can
use
these
informations
that
we're
talking
about
here?
Okay-
and
so
this
is
just
to
say,
and
so
these
are
text
that
was
added
to
actually
say
that
into
the
spec
okay.
D
That
says,
if
you
have
these
and
then
attempt
to
update
the
keep
agent
and
all
of
this
dependencies
or
only
update
the
specific
components
that
are
out
of
date,
okay,
so
the
optional
claims,
let
you
do
the
bottom
part
here,
the
absence
of
them
forces
you
into
the
top
one
okay,
so
just
explaining
that
wasn't
explained
before
as
to
as
to
why
they
were
optional,
and
this
actually
says
what
you
do
in
implementing
a
tp
and
when
what
you
do
when
implementing
a
tam
with
that
information.
D
So
we
put
this
explicit
into
the
ten
behavior
section.
Okay
next
slide-
and
this
is
you're
trying
this
isn't
coming
by.
Okay,
go
ahead:
okay,
cipher,
sweet
negotiation.
This
was
actually
one
of
the
large
topics
that
we
had,
because
we
were
all
implementing
cipher
suite
negotiation
at
the
table
once
we
ended
up
with
a
whole
bunch
of
things,
and
so
this
one
is
kind
of
the
laundry
list
of
everything
that
we
hit
in
implementing
exactly
that
same
functionality.
D
D
D
It
was
unclear
which
cipher
suite
combinations
were
mandatory
for
the
dam.
It
was
clear
which
algorithms
were
mandatory
but,
like
you
know,
the
suite
is
a
set
of
operations,
and
so
that's
on
the
next
slide
here.
D
There
was
a
couple
cases
that
akira
pointed
out
that
had
incorrect
cddl,
we
had
errors
in
the
in
the
cdl
tool
and
there
was
no
defined
way
to
specify
the
order
of
operations.
So
let's
say
you
wanted
to
have
two
cypher
suites
one
that
did
you
know,
sign
and
then
encrypt
and
one
that
had
encrypted
and
signed
or
some
other
you
know
signed
twice
whatever.
There
was
nothing
that
said
how
you
specify
the
order
right.
D
You
could
specify
the
algorithms,
but
you
couldn't
specify
what
order
they
went
in
and
if
order
mattered,
okay,
so
there
was
no
way
to
do
that.
At
least
there
wasn't
a
written
down
way
to
do
that.
So
this
is
the
list
of
the
problems.
Okay,
next
slide,
all
right.
So
here's
what
we
did
to
fix
those
things.
Okay,
first,
we
made
cipher
suite,
be
a
socket
meaning
you
put
the
dollar
in
front
of
it,
which
means
it's
okay
for
other
specs
to
extend
it.
D
Take
other
specs
or
other
implementations,
it's
extensible
fields,
so
we
fixed
that
part
to
just
to
make
it
be
explicit
that
that's
intended
to
be
extensible.
D
We
removed
the
mac
and
encrypt
algorithms
from
the
body
of
the
document,
given
that
it's
extensible,
since
you
can
define
a
type
extension
that
puts
them
back
in
okay,
we're
trying
to
say
how
can
we
scope
down
the
document
of
the
main
thing
to
make
it
go
to
rfc
faster,
just
like
we
did
for
the
suit
manifest?
We
took
a
bunch
of
optional
stuff
and
moved
it
off
to
different
extensions
without
saying
it's
bad
to
do.
We
just
said:
that's
a
different
document.
Do
the
same
thing
with
mac
and
encrypt.
D
We
say
we're
going
to
move
that
out
of
the
main
document
into
future
extension
documents,
same
thing
with
cos:
a
sine
okay,
we
said
we're
at
the
simplest
form.
It's
just
sine
one,
there's
only
one
signature,
and
so
we
only
talk
about
sine
one
in
here
without
precluding
the
use
of
sine,
because
you
can
do
that
in
extension,
by
adding
another
cipher
suite
it
uses
sign,
we
fixed
the
cdl
contradiction
by
saying
the
appendix
was
correct.
D
The
body
was
wrong
and,
lastly,
we
specify
that
the
order
of
operations
within
a
cipher
suite
is
meaningful
and
so
you'll
see
that
on
the
next
slide,
okay
go
ahead
next
slide;
okay,
so
there
are
two
mandatory
cipher
suites.
They
happen
to
use
the
two
mandatory
algorithms
for
the
tam
okay.
So
the
way
that
it
works
on
the
tam
is
that
the
tam
must
implement
both
cyprus,
both
cypher
suites,
these,
the
two
algorithms,
the
type
agent,
gets
to
pick
any
one
of
the
mandatory
set
that
it
wants.
D
So
you
have
guaranteed
interoperability,
but
the
constrained
node
only
needs
to
do
one
so,
for
example,
the
one
that
he
might
have
say
hardware
offload
for,
for
example,
okay,
but
the
tam
has
to
support
both
so
that
it
works
with
all
of
the
different
agents
that
might
exist
at
least
right
now.
So
these
are
two
cipher
suites,
you
can
say
each
cipher
suite
is
a
set
of
operations.
D
The
two
mandatory
cipher
suites
only
have
a
single
operation
each,
but
there
could
be
other
ones
that
have
multiple
like
sign
and
then
decrypt
or
encrypt,
and
then
sign
or
whatever.
So
this
one
is
just
sign
and
so
in
the
two
mandatory
ones
we
happen
to
have
cases,
there's
only
one
entry
in
the
array
of
operations.
Okay-
and
this
is
an
ordered
array
of
operations.
D
D
D
The
operation
only
has
two
values
in
the
in
the
internal
array,
but
in
general
it
can
be
more
than
two
right,
because
you
know
sign
one
means
exactly:
one
right
or
side
means
you
can
have
a
variable
number
right,
and
so
that's
where
these
two
came
in
there,
and
so
we
said
these
two
are
both
mandatory
implementation.
Detail.
D
Eddsa
is
not
yet
in
lawrence's
t
cosi
implementation,
so
I
couldn't
implement
the
second
one
yet,
but
I
think
I
wasn't
the
only
person
asking
lawrence
for
that
so
where
so
right
now,
the
first
one
is
implemented
in
a
couple
of
the
implementations,
but
I
don't
think
the
second
one
is
yet
out
of
the
implementation
table.
So,
okay,
just
I
want
to
mention
the
bottom
point
on
there
just
to
reiterate,
go
back
one.
D
The
last
point
was
that,
just
as
a
note,
okay,
these
two
do
not
do
encryption,
and
so
that
means
security
considerations.
We
have
to
say
something
about
that,
especially
since
we
already
had
text
that
says
anybody
defining
a
cipher
suite.
You
need
to
explain
why
you
don't
have
encryption,
so
we
need
to
make
sure
that
was
in
there.
D
So
here's
what
we
said-
okay,
we
said
we
don't
do
encryption
of
the
t
player
okay,
but
you
do
encryption
at
the
suit
payload
layer
and
we
now
reference
the
suit
firmware
encryption
document
in
in
the
security
considerations.
Section
saying:
if
you
want
to
try
to
protect
the
payload,
you
don't
have
to
you,
don't
have
to
encrypt
the
team
message,
but
you
better
be
encrypting
the
payload
and
here's
the
document
that
says
to
do
that.
D
Okay
yeah
same
thing
with
dependencies
right
yeah,
you
can
encrypt
dependencies
too.
So
personalization
data
is
the
most
obvious
case
of
using
firmware
encryption,
but
it's
not
the
only
one.
Okay,
so
that's
what
we
did
for
the
mandatory
cipher
suite
section:
okay,
222
we're
still
in
the
cypher
sweet
section
of
stuff.
A
bunch
of
these
are
related,
so
this
one
said
supported:
cipher
suites
was
previously
an
optional
field.
You
can
see
in
the
red
blob
there.
D
It
was
previously
in
there,
which
meant
that
it
could
be
absent,
and
so
the
tam
could
send
a
message
that
did
not
include
which
cipher
suites
it
supported.
Now
what
the
text
used
to
say
is
if
it's
not
there,
it
means
that
it
supports
the
two
on
the
previous
slide.
Okay,
that's
what
it
previously
said,
and
but
that
means
that
on
the
deep
asian,
the
constrained
node,
you
had
that
code
to
deal
with
both
cases.
D
Okay
and
you
had
to
hard
code,
the
fact
that
the
absence
meant
those
two
things
he
said
well,
what
happens?
You
know
five
six
years
from
now,
where
there's
a
weakness
in
one
of
those
you
know,
let's
say
es
256,
has
a
weakness
and
we
need
to
move
it
to
what
you
know:
es
384
or
something
like
that:
okay,
and
that
means
that
you
still
have
to
have
code
in
the
constrained
devices
that
have
the
old,
obsolete
thing.
Okay,
and
so
how
do
we
make
it
be
more
robust
to
the
future?
D
And
ken
was
the
one
that
pointed
out
that
you
know
five
six
years
from
now,
you
might
have
other
ones
that
become
mandatory
by
then
too
right
and
so
at
some
point
in
the
future.
You're
gonna
have
to
deal
with
the
case
where
there
really
is
no
useful
default
right,
so
let's
just
make
it
mandatory
now
and
all
the
implementers
said
yeah
sure,
let's
just
go
ahead
and
make
it
be
mandatory
now,
because
this
one
is
a
breaking
change.
Okay,
so
we
went
around
the
table
saying
anybody
got
a
problem
with
this.
D
Nobody
got
a
problem
with
this.
Nobody
had
a
problem
with
it.
Everybody
said:
let's
do
us,
we
did
it
as
implementers.
We
said
okay,
because
the
only
people
are
going
to
object
to
breaking
changes
of
the
implementers
and
we
had
five
six
of
them
at
the
table.
So
so
this
one
we
made
a
breaking
change.
This
one
is
a
major
breaking
change,
but
we
did
it
and
this
makes
it
be
mandatory
and
we
think
it
actually
simplifies
the
code
in
the
cheap
agent
and
makes
it
be
more
future-proof.
So,
okay,
next.
D
So
it
so
we
updated
that
and
here's
the
example
in
the
in
the
appendix
with
the
examples,
and
so
you
can
say,
here's
a
particular
message
of
supported,
cipher
suites
and
you
can
see
it
looks
like
this
when
it
comes
across
the
wire,
at
least
in
the
diagnostic
form,
and
you
can
see
the
18,
minus
7
and
18.
Minus
eight
is
what
the
tam
fills
in,
because
that's
the
two
cypher
suites
that
we
have
the
previous
slide
sign.
D
One
with
the
s256
and
sign
one
using
edgsa
is
what
the
tam
should
be,
including
in
all
this
message.
This
is
mandatory
currently
so
so
it
means
that
your
query
request
gets
a
couple
bytes
longer
and
your
agent
implementation
gets
a
little
simpler,
okay,
next,
so
there's
a
question
about
so
which
cheap
messages
are
protected
with
which
cipher
suite.
So
here's
what
the
text
says
in
the
internet
draft
posted
version
after
a
query
response
is
received.
The
selected
cipher
suite
is
used
in
subsequent
messages,
install
success
and
error.
D
That
means
you
can't
protect
this
career
response.
That's
what
that
text
said.
We
said:
that's
probably
not
right,
okay,
because
by
the
time
you're
sending
the
query
response,
you've
already
finished,
negotiating
the
cipher
suite
so
shouldn't
you
be
able
to
protect
the
correct
response
too.
Okay,
and
it's
also
ambiguous,
it
says:
does
that
mean
that
you
have
to
use
the
same?
Cipher
suite
in
both
directions?
Right
is
selected
means
selected
that
what
the
type
agent
does
for
its
operations
when
composing
always
has
to
be
the
same
as
what
the
tam
agent
is
doing.
D
So,
if
it's
doing
sign
but
not
encrypt,
does
that
mean
the
other
side
has
to
sign,
but
not
decrypt,
okay
and
so
right
now
we
said
the
answer
is
we
couldn't
think
of
a
case
for
in
the
short
term
or
saying
it
was
bidirectional
was
a
problem
that
was
kind
of
already
implied,
but
it
wasn't
explicitly
stated
so
we
said
the
least
change
was
to
just
explicitly
state
the
fact
that
yes,
it's
bidirectional,
and
if
you
need
to
do
different
than
that,
then
leave
that
to
a
deep
extension
document.
D
D
Second
related
question.
I
just
mentioned
about
the
query
response.
Okay,
so
the
query
response
it
could
be
protected
because
you're
just
you're
going
to
send
back
in
there
which
cypher
suite
you
selected.
Okay.
Now
this
is
a
question
that
I
need
somebody
that
is
more
of
a
cozy
etc
expert
than
I
am
the
selected
cipher
suite
is
inside
the
teat
message.
The
teat
message
is
meaning
it's
inside
the
cose
blob,
okay,
which
means
you
can't
get
to
the
selected
part
without
having
to
parse
the
coset
blob
to
begin
with.
D
So
as
cozy
blob
is
itself
described
that
you
know
it's
safe
or
sweet,
it
was
the
time
you're
decoding
the
cipher
without
the
blob
without
having
to
look
inside
it.
I'm
hoping
the
answer
is
yes.
Can
somebody
tell
me
is
that
this
case
I've
seen
hannah's
nodding?
Okay,
good,
good,
okay,
good.
So
that
was
the
question
here:
can
a
receiver
figure
it
out
from
a
cozy
object
and
parse
correctly?
As
long
as
the
answer
is
yes
and
there's
no
problem
with
what
we
did,
can
the
attestation
payload
be
encrypted?
D
F
A
D
H
I
mean
it
doesn't
say
no,
but
there's
no
explicit
mechanism
enabling
that
yet
I
think.
G
H
To
be
authenticated
because
that's
kind
of
important,
but
I
don't
think,
there's
anything
that
says
anything
about
encryption
so
far.
D
Okay,
so
I
guess
the
teep
feedback
would
be.
It
might
be
nice
for
the
student
reports
document
to
say
something,
and
this
gets
back
to
the
question
of.
If
you
cannot
via
the
spec,
then
it
means
the
teep
cipher
suite
might
need
to
do
encryption.
Assuming
that
there's
sensitive
data
in
the
suit
reports
right,
I
can
easily
imagine
that
there
is
sensitive
data
in
a
suit
report.
H
I'm
just
curious
as
to
what
the
what
the
key
exchange
mechanism
would
look
like
in
that
scenario,
that
seems
like
a
really
challenging
environment
for
a
key
exchange.
D
I
agree,
I
don't
know
the
answer,
that's
why
I
came
up
as
a
question.
So
so
what
we're
saying
in
teep
right
now
is
that
teep
does
not
solve
the
transport
layer
without
an
extension,
and
it
leaves
it
up
to
the
payload
and
it
could
just
be
don't
put
sensitive
information
in
the
suit
report.
If
you're
not
going
to
encrypt
it
right,
just
put
non-sensitive
information
in
there.
H
J
D
Okay,
okay,
thank
you
again.
Those
were
questions
that
are,
I
think,
are
more.
I
hope,
are
more
questions
for
the
suit
reports
document
and
not
for
the
t
protocol
document
but
happy
to
be
wrong.
So
all
right
last
question:
does
it
mean
that
an
error
sent
in
response
to
a
query
request
cannot
be
protected?
Okay,
because
if
you
had
a
query
request
that
was
malformed
and
I'm
saying,
or
for
example,
it
was
saying
a
set
of
supported.
D
Cypher
suicide
did
not
include
one
that
the
teap
agent
supports,
okay,
which
technically
that
should
never
happen
with
a
compliant
tam,
but
you
got
to
be
robust
to
non-compliant
tams
or
maybe
future
tams,
that,
within
with
a
current
agent
right
a
future
one
that
changes
the
set
of
which
ones
are.
Are
you
know
more
secure
or
whatever?
So?
Could
you
send
an
error
message
in
response
to
that?
And
the
answer
is
yes
right
now
we
did
that.
But
could
you
protect
it
with
anything?
D
Okay,
and
in
some
cases
you
know
the
suit
reports
could
be
considered
sensitive.
So
here's
an
example
of
what
we
might
say
this
one,
I
don't
think
is
in
the
github
copy
right
now
it
says
here's
an
example
of
what
I
thought
we
might
say
if
the
teep
agent
was
able
to
select
a
cipher
suite
from
among
the
tim's
supported
cypher
suites,
and
that
wasn't
the
problem
in
the
in
the
in
the
query.
D
Response
right
then
use
that
to
protect
the
error
message
right,
because
you
can
get
to
a
key,
then
right
you
can
get
to
a
set
of
operations.
You
know
the
other
guy
can't
you're
going
to
plan
about
something
else
like
wrong
version.
Right
would
be
an
example
right,
say:
here's
the
seriously
requested
version,
and
I
don't
support
that
version
or
any
other
things.
D
You
know
unsupported
extension,
that
type
of
thing
okay,
so
if
you
can
go
ahead
and
protect
that
otherwise
protect
the
error
with
a
mandatory
cipher
suite
that
the
tp
agent
supports
okay
and
if
the
tam
can
support
it
great,
if
not
well,
you
weren't
going
to
get
communication
anyway.
So,
but
specifically,
don't
include
sensitive
information
with
a
cypher
suite
that
doesn't
encrypt
okay.
So
my
proposal
is,
we
put
those
three
sentences
in
there
and
call
that
good
enough.
I
see
a
nod
from
russ
and
akira
is
getting
a
cue.
G
No
no
go
ahead,
yeah.
We!
We
also
talked
about
this
in
the
during
the
hackathon
and
probably
talked
in
japanese.
There
was
one
more
one
more
choice
we
had.
It
was
not
responding.
The
any
error
message,
because
the
error
message
with
some
anything
could
be
used
for
the
attacker
to
sense.
The.
D
Yeah
there's
a
complicated
issue
there
that
actually
overlaps
the
meeting
I
just
came
out
of
which
was
me
right
before
this
was
the
the
edm
program
of
the
iab,
which
is
the
the
contentious
document
about
the
robustus
principle,
considered
harmful,
and
this
was
actually
one
of
the
topics
so
yeah.
So
there
are
considerations
there,
meaning
there
are
arguments
to
do
both
my
personal
opinion
is.
You
should
send
an
error
message
when
you
can-
and
I
can
tell
you
the
authors
of
that
document-
have
reasons
why
that
is.
D
But
it
may
not
be
100
applicable
to
your
point.
So
so
maybe
there's
another
sentence
we
should
add
to
clarify
or
whatever,
but
in
most
cases
sending
the
error
actually
is
helps
to
tell
the
other
side
the
fact
that
it's
doing
something
wrong,
because
otherwise
it
will
keep
doing
the
wrong
thing.
If
you
don't
tell
them
at
least
that's.
That's
probably
the
argument
so.
D
Yeah,
okay,
so
oh
this
is
the
slide
deck
that
doesn't
have
the
last
slide
in
it.
So
I'm
going
to
do
that
verbally,
which
is
the.
B
Can
push
the
button?
Finally,
michael
richardson,
so
just
about
the
last
point,
I
think
we
have
enough
enough
enough
bad
experiences
from
ikev1.
For
instance,
where
you
know
the
error
about
not
being
able
to
select
the
cipher
suites
was
on
on,
was
never
transmitted
and
you
never
could
fix
problems.
B
And-
and
you
know
you
know
what
it
telling
telling
telling
the
attacker
the
list
of
cipher
suites
that
you
might
support,
is
just
not
that
big
a
deal,
they
can
enumerate
them
and-
and
we
were
really
anal
about
that
at
the
time-
and
it
did
not
contribute
to
interoperability
or
debug
ability.
So
if
that's
the
reason
for
not
sending
an
error,
don't
do
that.
Please.
B
I
don't
have
an
issue
with
there
yeah
I
don't
have
an
issue
and
if
someone
thinks
what
I'm
saying
is,
I
think
we
should
be
really
clear
about
that
and
not
not
accept
any.
You
know
I
don't
disclose
my
policy
because
it's
a
security
problem,
because
I
think
that
just
leads
to
people
turning
all
the
off.
A
A
D
Yeah,
if
you
want
to
try
to
reload,
because
I
added
one
more
slide
so
the
other
day,
ken
posted
the
message
to
the
suit
list-
that
I
then
responded
to
and
added
the
teep
list
onto
there,
because
it's
a
cross
type
suit
issue
that
we
both
ran
into
in
our
implementations.
But
we
didn't
explicitly
discuss.
I
think
we
came
up
with
the
hackathon,
but
then
we
kind
of
forgot
about
it
until
afterwards,
until
this
message
came
up
there,
so
let's
see
if
it's
in
here,
so
it
should
be
the
last
slide.
I'm.
A
D
D
D
So
I'll
start
introducing
it
to
distract
from
the
the
the
man
behind
the
curtain
over
there,
the
the
question
that
came
up
and
sorry
for
those
that
are
remote,
I'm
not
on
mike
right
now
or
not
on
camera.
Right
now
you
can
watch
the
tech
crew
over
there
and
just
listen.
The
question
comes
up
when
you
have
a
number
of
different
keep
agents
that
are
being
managed
by
the
same
tab.
Okay
and
let's
say
one
of
them
no
longer
needs
a
particular
trusted
component.
D
D
Not
there
all
right,
what's.
D
D
Right
I'll
just
talk
to
it,
if
I
can
remember
it
and
then
somebody
else
can
call
it
up
and
and
tell
me
if
I'm
missing
a
point.
Okay,
so
all
right
back
up,
repeat
all
right,
so
you
have
a
bunch
of
different
type
agents.
Some
of
them
need
a
contrasting
component.
Some
of
them
no
longer
need
it.
It's
one
of
the
optional
ones
that
says
the
teep
agents
can
have
it
in
this
example.
The
t
pages
can
have
it
when
they
have
something
that
depends
on
it
right.
D
It
may
vary
right,
so,
whether
think
of
it
as
phones
and
sometimes
the
user
has
an
app
installed,
and
sometimes
it
doesn't
all
the
phones
are
authorized
too.
If
they
want
it
right.
So
cam
is
perfectly
fine
as
long
as
as
long
as
the
tp
agent
would
want
it
that
it
could
have
it.
So
this
means
it
says.
Okay,
one
of
those
devices
says
I
don't
need
it
anymore:
the
user
uninstalled
it
okay.
So
here's
this
just
example.
Okay!
D
D
D
He
has
a
set
of
teeth,
manifest
of
suit
manifests,
or
perhaps
references
to
suit
manifest
stored
in
other
repositories,
okay,
and
so
what
we
did
in
a
previous
version,
the
teep
protocol
is,
we
removed
like
a
delete
message
and
we
said
we're
just
going
to
use
the
update
message
to
do
all
types
of
updates.
Okay,
the
update
message
today
allows
you
to
specify
a
list
of
suit
manifests.
We
showed
that
on
a
previous
slide
here,
okay,
that
means
to
do
a
deletion.
D
That
means
I
have
to
either
construct
one
or
get
one
from
the
author,
depending
on
who
the
sign
or
the
suit
manifest
is
okay,
so
either
I
have
to
construct
one
where,
like
I'm
the
signer,
and
I
resign
it
to
whatever
and
so
there's
an
extra
burden
here,
okay,
it
says
well
what
ver,
what
manifest?
No,
what
manifest
sequence
number
do
I
put
in
the
deletion
manifest
okay
right,
but
what's
one
plus
because
you
know
the
the
the
manifest
that
I
sent
to
you
and
to
hanus
would
be
different
ones.
D
They
both
have
the
same
sequence
number
right,
not
that
you
know
that
that's
fine
right,
but
that
means
I
have
two
different
versions
and
who's
incrementing.
That,
and
is
it
the
tam
or
is
it
the
manifest
author
or
is
the
tam
a
new
manifest
author
that
wraps
the
original
one
or
whatever?
So
that's
the
kind
of
questions
that
come
up.
Okay,
second
problem
with
that
with
that
thing
is
to
say
what
happens
if
there's
a
component,
that's
on
there.
D
Okay
yeah,
so
here's
the
manifest
list
that
exists
right
now.
Okay,
in
the
update
message:
okay
and
I've
just
been
talking
about
what,
if
the
tam
has
it
manifested
a
third
party,
do
you
like
encapsulate
it
and
resign
it
as
a
new
signer,
whatever?
D
D
D
You're
not
authorized
to
have
this
right,
so
you
gotta
have
a
way
to
delete
that,
and
so
ken
proposed,
let's
have
when
we
install
with
a
suit,
manifest
right
whether
it
comes
to
the
tam
or
not.
Okay.
What?
D
If,
because
you
have
installed
directives
and
says
here's
the
suit
manifest
and
here's
the
steps
to
to
install
or
to
boot
or
whatever,
right,
ken's
proposal
is
well,
let's
also
add,
when
installing
whatever
and
by
the
way
for
future
reference,
here's
the
uninstall,
here's
the
opposites,
here's
how
to
clean
the
stuff
up,
okay,
and
so
that
gets
packaged
in
the
original
install
one.
So
I'd
have
to
bump
the
version
number
all
the
uninstall
directives
are
in
the
original
one.
D
So,
however,
you
got
the
original
one,
you
have
the
uninstall
directives
around
and
by
the
way,
both
software
packages
that
you
installed
today
on
platforms
already
have
the
uninstall
mechanism
in
the
installer
package
right.
So
it's
kind
of
consistent
with
that
mechanism,
that's
kind
of
where
the
idea
comes
from
so
this
idea
that
says
what,
if
the
suit
manifest
had
uninstalled
directives,
so
you
don't
bump
the
version
number
if
you
just
want
to
say,
delete
that
thing.
I've
never
heard
of.
He
said
you
know
that
thing.
D
D
Then
we
could
go
back
to
this
update
message
right,
which
right
now
is
a
manifest
list,
and
we
could
put
back
in
here
a
way
to
say
just
delete
by
id
right.
Here's
the
id,
I'm
not
going
to
give
you
the
full
suit
manifest
because
I
may
not
have
it
right.
You
have
it
or
you
would
have
told
me
about
it.
Just
follow
the
uninstall
procedures
you
already
have.
D
Okay,
so
that's
kind
of
the
summary
of
this
thread
that
kev
and
I
were
starting
on
the
list
here
and
we
wanted
feedback
from
the
working
groups
on
this,
because
we're
not
going
to
have
time
in
suit
to
talk
about
this
because
we're
already
you
know
at
the
hour
or
whatever.
So
this
is
the
only
time
we
have.
If
you
have
comments.
D
H
Now,
here's
the
second
question:
what
exactly
do
you,
okay,
I'll,
come
back?
Sorry,
no!
I
need
to
finish
that
that
thread
right,
so
how
many
tams
can
one
device
have
and
how
do
you
divide
up
their
areas?
What
happens
when
there
is
a
mutual
dependency
between
two
tams?
How
do
you
make
sure
that
one
doesn't
forcibly
uninstall
something
that
the
other
has
is
depending
on.
D
Yeah,
the
answer
to
that
is,
if
we
go
all
the
way
back
to
the
otrp
document,
it
used
the
term
trust
domain
which
came
out
of
global
platform,
world,
meaning
the
meaning
that
global
platform
defines
for
trust
domain
and
that
there's
one
ham
per
trust
domain
and
that's
why
ken's
proposal
is
to
talk
about
this
in
suits
trust
domains
document,
because
the
assumption
that
there
is
one
tam
per
crest
domain
unless
a
tam
explicitly
delegates
another
one
like
personalization
data,
or
something
like
that.
D
There
are
cases
on
a
particular
suit
manifest
there
exists
only
one.
You
know
thing
that
would
be
the
the
controller
of
it.
D
Yes,
well,
I
don't
know
what
dependencies
I
would
say
on
non-explicit
dependencies
across
trust,
domains.
D
I
understand
what
you're
saying
and
I
I
think
that
you
can
do
that,
and
so
yes,
if
you're
delegating
to
say
tam
one
has
a
dependency
on
something
for
which
tam
two
is
authoritative,
then,
and
you
consider
that
to
be
acceptable
when
defining
you
know,
tam
one's
the
manifesto
is
pushing
out
and
tam
one
is
saying:
yes,
I'm
agreeing
that
tam
two
can
always
yank
one
of
my
dependencies
and
kind
of
override
my
ability
to
work
right.
Yes,.
H
D
I
I
think
I
don't
know
candace
and
coming
up
to
the
mic,
so
I'll
attempt
to
channel
what
I
think
that
we
would
say
is
the
the
installed
directives
are
an
explicit
set
of
steps
that
you
follow
in
order
to
do
the
install
right
you
copy
this
component
into
this.
You
know
disk
space
or
whatever
it
is,
and
it
should
in
lowercase
should
be
the
exact
opposite
of
those
now
you're
pointing
out
what
happens
if
it's
not,
and
that
is
dangerous
right,
and
I
get
your
point
brendan.
H
D
The
obvious
ones
that
I
can
think
of
is
because,
if
I
look
at
uninstall
equipment
directives
in
other
formats,
not
not
t,
but
you
know
what
msis
on
or
inf
files
on
windows
and
similar
things,
and
you
know
apt
or
pip
or
whatever.
It's
like
delete
the
following
component
from
the
following
from
the
following
directory
or
repository
for
some
definition.
So
like
in
windows,
you
have
a
registry
or
a
file
system.
D
You
have
a
file
system
directory
for
holding
libraries
or
includes
or
executing
you
know
your
bin
directory
or
whatever
your
install
direct.
Your
install
directive
say
copy
this
thing
into
the
bin
directory
and
then
delete,
says,
delete
uninstall
says,
delete
it
from
the
bin
directory
the
same
thing,
but
it
better
be
the
same
thing
or
you've
got
a
security
problem.
So
but
yes
deleting
things
from
specific
repositories,
whether
those
are
disk
space
or
some
other
database.
That's
resident
on
the
system.
H
Okay,
I
think
any
further
should
probably
go
to
the
list.
I
think
I've
got
a
good
overview.
Thank
you.
D
Yeah,
but
that
was
why
we
started
this
thread
on
the
list.
Thank
you,
ken
for
kicking
off
this
thread,
because
it
really
is
a
cross-deep
suit
discussion,
although
my
belief
is
a
lot
of
the
answer
is
in
suit
and
the
t-pass
to
follow
whatever
suit
directs.
But
suit
only
has
an
hour,
and
this
can't
be
on
the
agenda
because
we've
got
a
full
hour
or
so.
A
B
Michael
richardson,
so
I
had
two
things.
I
have
two
things
to
say
now.
I
have
to
listen
to
brendan
the
one
that
I
almost
forgot
was.
Why
do
we
wind
up
in
the
case
where
we
have
something
that
the
tam
doesn't
know
about,
and
actually
I
think,
a
very
reasonable
situation
is.
There
is
a
problem
and
with
the
components
and
the
user
has
been
given
a
adequately
signed,
debug
version
that
the
tam
is
willing
to
to
accept,
but
you
don't
normally
give
this
out.
B
It
runs
for
a
while
and
and
then
later
on.
When
you
know
the
bug
is
actually
found
and
fixed
and
things
need
to
be
upgraded,
then
you
know
what
some
component
now
gets
deleted.
That
was
the
debug
version
of
it
and
that's
why
the
tam
doesn't
know
about
it
because
it
arrived
through.
You
know
other
other
means,
and
I
think
that's
a
really.
I
think
that's
a
really
good
thing,
because
it
means
that
we
can
both
debug
but
then
remove
the
user
from
the
debug
situation
later
on.
So
I
think
that's
really
good.
B
F
B
As
for
the
other
concern
about
trust
about
different
domains
and
whatever
the
only
reason
why
domain
a
with
tam
a
would
ever
be,
sharing
any
component
with
domain
b
with
tam
b
is
because
you
are
seriously
limited
on
space.
Okay,
that's
to
me
the
only
reason
you're
another
reason:
they're
not
delegating
to
each
other.
They
don't
know
about
each
other.
First
of
all,.
D
There's
an
example:
it's
in
the
architecture,
spec,
okay
and
the
example
is
the
code
comes
from
one
tam
and
the
personalization
data
comes
from
another
tam.
D
B
It
doesn't
change
my
subsequent
comments,
which
were
essentially
that
well,
if
the
reason
was
disk
space
but
you've,
just
given
me
a
different
reason.
Okay,
then
you
know
reference
counted.
Hard
links
are
50
year
old
technology,
okay,
and
we
that's
to
me
just
one
of
them,
unlinks
it
and
the
other
one
says.
Well,
I
still
have
a
copy
because
underlying
I
still
have
it.
Okay,
I
just
don't
think
that's
fundamentally
an
argument
against
this.
Okay.
D
C
Okay,
so,
okay,
so
sorry,
I
have
to
join
this
meeting
remotely.
So
is
my
audio
on
the
video
clear?
Yes,
okay,
so
this
is
the
draft
about
the
tip
tip
use
case.
Oh
sorry,
I
lost
oh
here
it
is
here,
is
the
tv
use
kits
for
computational
computing
network,
and
I
also
shared
these
drafts
in
the
competition
computing
consortium.
C
So
next
slide.
Please
now
here's
a
motivation-
and
we
all
know
that
the
computational
computing
is
the
protection
of
data
in
use
by
hardware-based
trust
execution
environment,
but
when
using
this
computational
computing
in
network
or
in
a
remote
environment,
so
I
think
there
are
some
issues
that
need
to
be
clarified.
So
first
is
that
what
is
the
architecture
of
what
is
the
instance
of
competition
computing
in
a
network?
And
the
second
one?
Is
that
what
kind
of
oh
sorry
I
lost
the.
A
A
C
I
can
see
them
looks
good
here:
okay,
okay,
thank
you.
So
the
second
question
is
what
kind
of
application
package
a
network
user
should
use?
Would
it
be
a
trust,
application
and
personalization
data
are
banned
together
or
not?
The
third
question
is:
what
kind
of
steps
a
network
should
we
follow
to
deploy
application
packages?
I
think
that
the
tip
architecture
has
defined
a
lot
of
components
like
the
active
agency
broker
and
etc,
but
I
think
these
questions,
especially
from
the
perspective
of
a
user
or
network
user.
C
C
Okay,
here's
the
I
think
in
general,
this
there
are
three
kinds
of
competition
computing
instance
that
could
exist
in
the
network.
The
first
one
is
a
trusted
process
which
could
be
in
a
virtual
machine
or
could
be
in
operating
system,
and
the
second
one
is
the
trusted
vm,
which
is
based
on
a
hypervisor
and
the
processor
process
process,
and
the
containers
in
this
trusted.
C
Virtual
machine
are
also
confidential
and
third
one
is
the
container,
so
the
container
could
be
in
a
container
engine,
including
a
virtual
machine,
and
this
container
is
also
protected
by
the
te
also
so
in
general,
these
are
three
instances
that
the
network
user
could
use
when
they
want
to
say
that
I
want
a
te
and
which
kind
of
key
is
it
so
it
me
it
may
be
a
process,
a
work,
machine
or
container.
So
next
slide.
Please
now
here's
the
notional
architecture
of
the
of
this
draft,
so
we
added
the
two
components.
C
First,
one
is
the
network
moc,
which
is
network
management
and
orchestration
center,
and
the
trusted
application
manager
is
inside
the
network
moc
and
the
second
is
a
data
owner
or
the
network
user.
As
a
network
user
who
also
owns
the
personalization
data
and
the
trust,
replication
and
also
the
unfaster
application,
there
are
also
some
components
like
the
trust,
application
and
fast
application
and
tip
broker
tip
agent.
This
has
been
defined
in
the
chip
architecture.
So
next
slide.
Please.
C
Here
is
the
application
package
and
the
deploy
steps.
So
I
think
there
are
two
principles
to
deploy
packages
in
the
confidential
computing
environment.
First,
one
is
that
the
personalization
data
can
only
be
processed
by
time
after
remote
attestation
and
principle.
Two
is
that
the
personalized
data
must
be
transferred
securely,
and
I
mean
security
is
that
this
package
could
be
encrypted
or
during
some
secure
channel
like
a
remote
addition,
tls
or
just
the
way
it
talked
before
the
course
formula
or
some
some
other
formats,
so
the
table
shows
is
one
example.
C
One
case
case
one
in
this
case.
The
uata
and
pa
and
pd
are
valued
as
one
package
and
in
the
second
column,
shows
that
the
process
in
a
physical
or
virtual
machine
this
could
be
supported
by
the
chat
zone
or
sjx,
and
in
in
this
scenario,
the
steps
should
follow
in
like
in
the
table.
C
C
There
are
some
other
different
packages
like
this
package
mode
is
the
ua
tier
one
package
and
the
personalization
data
is
one
package.
All
the
uata
and
pd
are
separate
packages,
and
in
this
scenario
the
ua
should
be
deployed
to
the
reforest,
and
then
the
ta
is
loaded
to
the
trusted
process
of
trusted
container
or
cluster
vm.
Then
will
the
network
user
will
will
test
the
tip
agent
after
verification?
The
network
user
will
trust
the
te.
Then
it
will
transfer
its
personalized
data
to
the
test.
C
Application
in
the
process
or
container
of
virtual
machine
and
the
lower
table
shows
that
oh
some
forms
mistake.
I
think
this
scenario.
I
think
it
is
that
the
ta
and
pd
are
one
package
and
the
ua
is
another
package,
and
so
the
steps
should
be
the
ua
first
load
to
the
re
and
the
zone.
There
is
a
network,
remote
attestation
and
then
the
t
and
pd
will
be
loaded
to
the
trust
process
or
container
or
virtual
machine.
C
So
next
slide
please
these
these
tables.
They
are
also
also
different
cases.
This
one
is
the
upper
one
is
that
pa
and
pd
are
separate
packages
and
the
lower
one
is
that
the
ta
and
pd
are
the
same
package.
So
they
also
have
steps
to
deploy
this
package,
and
they
may
be
a
little
bit
different,
so
yeah.
These
are
all
the
cases
I
think
involved.
C
Then
the
collector
will
decrypt
all
these
information
until
it
gets
the
correct
query.
Information
result.
So
when
we
use
computer
computing
and
combined
with
ot
algorithm,
I
think
things
will
be
more
easy.
First,
we
deploy
the
ot
algorithm,
which
is
also
the
trust
application
to
the
data
center
and
then
we'll
transfer
the
personalization
data,
which
is
also
the
query
information
to
that
ot
algorithm.
Then
the
result
is
that
it
could
replace
the
network
overhead
by
memory,
access
and
only
transfer.
C
The
correct
query
result
to
collector
because
that
the
company
computing
could
protect
the
information
inside
its
environment,
so
the
it
the
the
ot
algorithm
could
process
all
the
information
and
until
it
gets
the
correct
query,
information
and
just
to
transfer
the
10
bits
of
information
to
the
collector.
So
this
is
just
one
very
interesting
scenario
scenario
next
slide,
please,
I
think
that's
it.
C
Yeah,
here's
a
summary
this
use
case
is
trying
to
use
a
tip
architecture,
architecture
and
protocol
to
illustrate
how
to
use
computer
computing
in
the
network
and
list
out
the
relevant
steps
and
the
package
mode,
and
since
this
could
get
the
network
user
a
remote
user
to
use
this
technology
and
then
there
are,
there
are
some
issues
that
remain
open
or
not
in
this
draft
scope.
I
think,
for
example,
how
to
process
remote
attestation
and
how
to
create
a
secure
channel.
C
I
think
there
has
been
a
lot
of
discussion
in
these
issues,
so
I'm
not
sure
if
this
is
a
unicorn,
I
think
they
may
be
covered
by
other
groups
like
the
right
group
or
the
how
to
create
a
motivation.
I
think
it's
based
on
the
hardware
architecture
like
use
the
quote
enclave
or
secure
process
processor.
C
In
the
end,
I
we
would
like
that
this
draft
to
be
adopted
as
a
working
group
product.
I
think
that
would
be
very,
very
appreciate.
Oh,
I
have
a
highness
on
the
cube.
Yes,.
F
Yeah,
I
think
the
work
that
bingling
is
doing
is
is
quite
important
because
in
in
the
way
we
described
the
terminology
and
the
architecture
was
course
predates
sort
of
all
the
excitement
on
confidential
computing.
But
it
still
has
the
ingredients
in
there
like
what
we
refer
to
as
personalization
data
is
often
for
some
people
working
in
a
confidential
computing
space,
difficult
to
associate
with
some
of
their
confidential
workloads,
because
the
names
are
so
different
and
some
of
the
others.
F
So
I
I
personally
see
that
there's
a
possibility
for
us
to
sort
of
describes
on
how
to
map
some
of
the
confidential
computing
use
cases,
and
there
are
different
sort
of
models
that
springling
was
just
talking
about
to
the
the
deep
architecture,
and
I
think
explaining
that
and
potentially
motivating
with
some
examples
on
how
you
do
that.
How
how
what
that
means
like
with
applying
deep
protocol
and
and
its
subcomponents.
F
I
think
that
could
be
quite
helpful
for
readers
who
stumble
over
the
work,
or
I
want
to
come
up
with
a
standardized
way
in
in
supporting
some
of
the
confidential
computing
use
cases.
C
D
Dave
famer,
so
I
think
there's
two
things
that
are
in
penguins
presentation
and
draft
that
I
hadn't
seen
in
any
other
draft
or
presentation
and,
I
think,
are
valuable
contributions
to
the
t
discussion.
D
One
of
them
was
in
the
use
case,
form
of
where
is
the
tp
the
device,
the
cheap
agent
right,
because
the
cases
that
we've
talked
about
in
you
know,
architecture
and
other
drafts,
and
things
were
the
type
agents
in
some
device
like
an
iot
device
or
something
like
that
or
a
phone
or
a
laptop
or
whatever,
and
the
case
where
it's
in
the
cloud.
D
Okay,
this
is
a
use
case
where
it's
neither
of
those
okay,
it's
some
middle
box
in
the
network,
such
as
you
know,
the
network
operators,
you
know
router
or
switch
or
something
like
that,
and
so
it's
like
a
cloud
except
for
it's
actually
in
the
local
network.
Okay,
so
it's
just
a
variation
of
like
a
local
cloud,
whatever
it's
just
another
use
case
that
says
you
can
use
the
same
technology
to
do
with
the
cloud
you
can
do
that
with
the
device
here.
Okay,
and
so
that
part
is
just
an
interesting
yeah.
D
This
too,
okay,
but
the
other
thing
that
that
this
talked
about
that
applies
to
the
cloud
as
well
that
we
didn't
explicitly
cover
was
in
the
architecture
document.
We
talk
about
the
bundling
where
we
have
like
the
untrusted
app
the
trusted
app
and
the
personalization
data,
and
that's
where
you
cover
all
those
like
different
cases
and
stuff
right
in
the
cloud
and
in
this
case
right
there
doesn't
have
to
be
an
untrusted
app.
D
Okay,
if
you
think
about
the
the
trend
towards
you,
know
confidential
vms
and
combination
containers
and
so
on,
there's
only
a
trusted
app,
there's,
no
untrusted
app
on
the
whole
device
right,
and
so
that's
something
that
that
I
think
does
come
up
and
was
talked
about
in
penguin's
draft.
That
didn't
wasn't
mentioned
in
any
other
thing.
Unless
you
know
the
absence
of
an
untrusted
application
is
also
an
interesting
contribution
to
the
discussion.
So
thanks
penguin
for
bringing
up
both
of
those
cases.
D
I
think
they're
both
worth
making
sure
that
we're
thinking
about
when
we're
doing
drafts
and
implementations
and
stuff
is
to
say
what.
If
what
if
there
is
no
untrusted
app,
it's
just
the
trusted
app
running
inside
of
a
tee
and
the
only
thing
that's
using
it
is
something
across
the
network
right
and
you
have
some
network
path,
whatever
that's
provided
by
the
tee.
That's
not
the
untrusted
app
per
se
is
not
involved,
so
there
is
no
such
thing.
D
So
I
think
that
part
is
a
useful
contribution
and
the
oh
yeah
when
talking
about
things
without
a
user
interface
right,
it's
not
just
the
cloud,
as
we
classically
think
about
it
with
cloud
confidential
computing
with,
like
you
know,
azure
and
aws
and
gcp,
and
so
on.
It's
also
things
like
network
operators
is
an
interesting
use
case.
We
want
to
consider
too,
I
don't
know
that
chain
may
has
any
changes.
The
protocol,
okay,
but
I
think
it's
an
interesting
use
case.
In
particular,
the
lack
of
a
ua,
I
think,
is
a
good
contribution.
So
thanks.
J
J
One
thing:
I
have
the
impression
that
we
should
not
try
to
be
to
provide
a
complete
description
of
everything
that
can
be
done.
So
if
we
can
target
that
just
as
an
open,
illustrative
discussion,
I
think
it's
it's
reasonable,
but
we
don't
want
to
end
up
with
a
book
at
the
end.
J
A
The
architecture
as
well
right,
so
what
I'm
hearing
is
that
this
is
a
useful
addition
for
another
model
right.
I
guess
the
question
that
I
have
is
I
see
that
as
a
standards
track
document,
although
I
don't
see
it
making
any
changes.
So
my
question
as
a
chair
is:
does
it
need?
I
see
it
more
as
an
informational
as
opposed
to
standards
right.
So
as
a
chair
that
would
be
my
recommendation.
D
Yes,
I'm
trying
to
think
what
I
think
might
be
useful.
I
I'll
think
on
the
fly
about
nancy.
Your
question
informational,
not
standard,
track
to
that
question,
because
this
is
about
use
cases.
D
I'm
thinking
that
it
may
be
useful
if
we
can
combine
both
the
cloud
case
and
the
network
case
into
a
single
use
case
document
that
covers
both,
because
I
think
this
notion
that
says
there
are
use
cases
that
don't
have
an
untrusted
application
and
here's
two
of
them
they're
very
similar,
there's
different
types
of
operators,
but
the
technology
wise
right,
they're,
almost
identical
other
than
that.
You
know
the
things
that
go
around
tea
brightens,
but
a
lot
of
the
same
considerations.
D
I
think
it
might
be
useful
to
have
a
working
group
documents,
informational
use
case
that
covers
both
cloud
and
network,
which
are
cases
that
don't
have
a
ua
okay,.
D
This
draft
that
penguin
is
presenting
is
called
confidence
for
the
network.
F
D
D
A
document
that
says
you
can
have
cloud
confidential
computing
cases
without
a
ua
just
like
you
can
have
never
accomplished
your
committee
cases
out
of
ua.
It
would
be
useful
to
put
that
in
one
document
and
not
try
to
just
try
to
say
we
don't
need
a
whole
bunch
of
documents.
Right.
Combine
them
into
one
document
says:
use
cases
without
a
t
without
a
ua
and
penguin's
case,
and
the
cloud
cases
have
a
lot
of
the
same
text
that
you'd
want,
and
so
just
put
it
in
the
comment
section.
D
A
D
A
A
C
F
A
D
All
I
was
going
to
say
is
I
I
I'm
looking
at
our
a.d
and
stuff,
but
I
I
think
it's
within
the
realm
of
the
working
group
decide
how
many
documents
a
milestone,
gets
split
into
and
if
you
consider
this
to
be
like
an
a
a
separate
thing
that
we
didn't
cover
in
the
architecture
document,
because
it's
not
core,
it's
like
an
addendum
and
we
could
use
that
without
having
a
new
any
charter
updates.
D
C
A
I
What
I
would
like
to
help
here
is
that,
in
my
opinion,
there
are
two
interesting
use
cases
that
I
hope
they
are
included
in
this
targeted
that
one,
the
the
first
one
is
the
the
fact
that
we
will
use
containers.
I
It
could
be
a
problem
for
the
container
security
and
that
that's
why
I
think
that
it
should
be
a
different
use
case
or
the
normal
use
case.
I'm
looking
to
the
clouds,
mostly
right,
that's
the
current
direction
for
my
thinking,
so
I'm
I'm
worried
about
the
security
issues
of
that
a
little
bit.
So
can
you
hear
me?
I
K
Hi,
so
I'm
I'm
reacting
to
soren
and
I'm
kind
of
curious
about
what
he
means
by
kind
of
container
security
and
complications,
and
so
I
mean
I
I
understand
a
little
bit
and
and
I'll
give
you
a
little
bit
of
background
in
that
you
know
carnegie
mellon
university.
We
have
some
research
project
going
on.
That's
actually
rewriting
kind
of
the
c
groups
of
linux
in
with
formal
analysis
tied
into
secure
hardware.
You
know
root
of
trust
with
a
hypervisor,
that's
already
written
in
formal
language,
so
it
would
have
formal.
D
K
A
Right
so,
in
the
interest
of
time,
we've
got
two
minutes
left
what
I'm
trying
to
assess
his
readiness
of
adoption
for
this
particular
document
versus
waiting
to
get
inclusion
at
least
dave.
You
made
it
clear
if
the
applicability
of
the
network
use
case
and
the
pure
cloud
use
case,
and
so
I
would
I
was
trying
to
craft
a
poll.
It
really
sucks
to
do
everything
parallel.
So
I
was
trying
to
craft
a
poll
to
see
if
there
was
interest
in
waiting
for
the
inclusion
of
both
or
so.
A
Let
me
just
start
the
session
and
I
may
not
have
worded
it
perfectly,
but
let
me
just
move
it
forward
as
a
poll
and
it's
basically
I'm
asking
the
question:
do
you
want
both
use
cases
included
before
we
adopt
the
document,
or
can
I
ask
the
question
to
just
adopt
this
document
as
a
seed
and
we
elaborate
moving
forward?
So
the
first
question
is:
do
you
want
to
wait
for
everything?
A
E
A
A
Reason
yeah
I
mean
there
there's
the
consensus
of
leaning
towards.
Let's
just
do
the
call.
So
let
me
start
the
poll.
A
A
A
You
support
adoption
the
and
peng
help
me
in
real
life
time.
The
name
of
your
draft
again
use
cases
for.
C
A
I
have
started
a
poll
to
support
adoption
for
the
draft
that
peng
just
presented
since
we're
out
of
time
and
then
we'll
confirm
it
on
the
mail
list.
So,
okay,
so
we
pretty
much
have
unanimous
consent
here,
which
is
good.
We
have
strong
support,
so
ping
ling.
What
I'm
going
to
ask
you
to
do
is
change
it,
and
I
can,
if
I
forget
just
remind
me,
change
the
draft
to
informational
and
make
it
a.
C
A
So
with
that
see,
this
is
why
I
always
leave
a
few
minutes
buffer,
because
we're
two
minutes
over
with
that.
Thank
you
to
the
authors
and
presenters
ping
ling
we're
making
good
progress.
I
didn't
get
to
ask
the
question
so
I'll.
Ask
it
on
the
list
whether
we
can
do
an
early
review
for
the
protocol
draft
and
readiness
working
working
group
last
call
so
I'll.
Do
that
on
the
mail
list.
D
Dave
right
now,
my
plan
is
to
go
ahead
and
post
the
github
copy
and
then
keep
working
on
the
issues
just
because
that
gets
a
whole
bunch
of
them
out
of
the
way
and
now
we're
down
to
like
the
three
that
we've
been
talking
about
recently
and
not
have
to
wait
for
those
of
the
three
just.
So
we
get
an
update
so
that
any.
A
D
We
know
that
there's
three
open
issues,
and
so
that's
up
to
you.
I
guess
so
I
mean
there's
three
issues.
We
discussed
that
don't
have
github
pull
requests
already
merged
right,
so
all
but
three
of
them,
meaning
ken's,
which
doesn't
have
a
number-
and
I
think,
there's
two
other
ones
that
we
discussed
the
last
three
slides
or
the
last
three
topics
for
ones
that
don't
already
have
text
merge
into
the
github
copy.
D
I'll
just
take
a
snapshot
of
what's
in
github
right
now,
push
it
up
there
and
that
will
allow
us
to
close
all
the
other
issues
and
only
have
the
ones
that
were
in
the
middle
of
discussion
here
that
we
talked
about
proposals
for
I'd
like
to
do
that
before
it
gets
too
long.
Just
so
that
all
the
implementers
are
using
the
same
copy.