►
From YouTube: IETF113-TEEP-20220321-0900
Description
TEEP meeting session at IETF113
2022/03/21 0900
https://datatracker.ietf.org/meeting/113/proceedings/
A
A
C
B
And
you
are
sharing
your
slides
in
me
to
go.
Yes,
no,
I
see
them
in
the
data
tracker
but
they're.
Not.
Where
is
my.
D
D
A
D
B
B
B
Oh,
I
see
interesting.
B
B
B
B
It
should
be
basically
the
same
just
that.
B
I
know,
but
let's
see
if
you
do
somebody's
supposed
to
be
coming,
who
knows
more
than
me,
but
obviously
I
don't
know
anything,
but
you
know
we'll
figure
it
out.
So
if
you
were
to
go
to
that
that
again,
you're
really
just
in
the
data
center
that
doesn't
make
any
sense
right,
you're,
right,
yeah,
okay,
let's
go
back
to
teep
and
then
that's
how
you
share
screening.
D
B
B
A
B
C
B
A
B
D
E
B
B
The
scenes
was
there
something
actually
wrong.
I
don't
know
okay,
they
they
up
yeah
yeah.
Oh
they
do
too.
What's
that
over
there.
Maybe
we
collapse
that
yeah.
Okay.
So
now
you
can
okay.
A
A
Thanks
dave,
okay,
so
let's
go
ahead
and
get
started
and
we'll
kick
it
off
so
you're
also
remote.
A
G
A
So
the
notewell
still
applies,
I
believe,
most
of
you,
given
that
I'm
running
late,
I
won't
read
it
most
of
you
should
be
familiar
with
it
meeting
tips.
The
only
thing
that
I
thought
I
noted
was
to
ensure
that
you're
launching
the
meat
echo
and
for
the
the
meat
echo.
I
usually
launch
it
straight
from
the
website
agenda
and
that's
how
I've
gotten
it
to
work
for
those
that
are
here.
I
think
hopefully
you
all
have
turned
your
at
least
your
mech.
A
So
you
we
don't
get
the
double
echo
which
I'm
not
hearing
and
then
for
the
remote
participants
to
improve
your
bandwidth.
Keep
your
audio
and
video
off
until
you
are
ready
to
get
on
the
queue
and
one
of
the
chairs
either,
and
I
could
recognize
you,
okay,
so
code
of
conduct
still
applies.
We
went
through
that
last
time.
I
think
this
is
a
pretty
small
and
chill
group
we're
courteous
to
each
other
and
be
prepared
to
contribute
and
discuss
the
deep
work.
Okay,
so
jabber
is
now
attached
to
medeco.
A
We've
got
the
chat
going.
I
can
see
the
queue
on
this
other
screen.
If
you
can
help
me
with
the
queue
as
well,
we
can
go
ahead
and
get
going
okay.
So
for
the
agenda
bash,
I
believe
I
made
all
of
the
updates,
but
I
want
to
make
sure
we
got
them
all
straight.
A
So
dave
I've
allocated
15
minutes
for
the
architecture,
10
minutes
for
the
transport
one
and
then
I
was
going
to
have
akira
go
next
to
go
over
the
hackathon
report
and
then
give
you
as
much
time
and
unless
you
really
need
more
than
the
45
minutes.
What
I
was
trying
to
do
is
allocate
the
last
10
minutes
to
pengling
who
wanted
to
present
on
confidential
computing
aware
network,
so
any
any
changes
to
the
agenda.
A
A
A
H
G
A
I
D
H
All
right,
hopefully,
the
audio,
holds
out
throughout
this
session.
Hey
everyone
good
to
see
people
virtually,
so
I'm
gonna
be
talking
about
the
draft
16
of
the
architecture
document.
H
Just
as
a
reminder
in
our
timeline,
we
did
complete
working
group
last
call.
Some
time
ago
we
held
the
document
until
we
were
more
sure
that
there
were
not
going
to
be
changes
based
on
the
protocol
spec.
So
then
we
got
to
that
point.
In
july
of
2021
we
submitted
to
iesg
ben
recently
posted
some
feedback.
There's
the
link
there
that
we're
going
to
go
through
and
the
draft
was
then
updated
and
so
draft
16.
H
The
main
changes
are
to
address
ben's
feedback
all
right,
so
I'm
going
to
walk
through
ben's
comments
and
then
talk
about
what's
changed
in
the
spec,
and
so
this
is
literally
ben's
comments
on
the
slide
here
in
the
next
two
or
what
we
did
to
address
it.
So
I'm
going
to
call
out
some
main
points
here
that
ben
raised.
H
This
is
the
comment
that
I
call
the
double-edged
sword
in
the
first
line
comment
here,
and
so
he
talks
about
the
context
of
the
architecture
and
maybe
some
security
or
privacy
considerations
right
so
I'll
highlight
in
the
second
paragraph
he
talks
about
refers
to
rfc
8890,
which
is
entitled
the
internet
is
for
end
users
and
it
talks
about
in
a
te
type
of
situation.
H
Right
then,
the
risk
is
the
perception
of
the
conflict
where
the
user
doesn't
have
any
rights,
because
you
can't
see
what's
going
on
inside
the
dee,
and
he
says
it
might
be
good
to
have
the
to
acknowledge,
there's
cases
of
the
main
value
of
teeth,
and
this
is
ben's
wording
right.
It's
the
device
owners
potentially
at
risk
of
harm
to
users
and
discuss
the
trade-offs
involved,
and
then
the
last
point
that's
part
of
this
is
about
that.
The
tam
is
a
trusted
party
and
so
to
document
the
new
privacy
exposure.
H
Where
the
you
know,
cam
has
access
potentially
to
things
that
say
the
user
is
sitting
in
front
of
the
device.
If
there
is
one,
if
there
is
a
user
there,
that
there
may
be
some
privacy
exposure
there
right,
so
that's
kind
of
the
summary
of
this
old
of
this
one
here,
and
so
we
made
two
changes.
One
is
the
introduction
to
set
the
context
and
then
one
is
in
the
privacy
considerations
section.
So
this
is
is
formatted
with
bolding
and
things,
but
this
is.
The
text
was
added
into
the
introduction
section.
H
Okay,
so
there's
already
some
text
there,
and
so
this
is
just
the
new
text.
In
addition
to
all
the
other
text
that
was
already
there.
That
hinted
at
some
of
the
things
that
ben
is
pointing
out.
This
is
the
additional
text,
so
the
top
line
is
one
of
the
points
it
says.
Tes
are
typically
used
in
cases
where
a
software
or
data
asset
needs
to
be
protected
from
unauthorized
entities
that
may
include
the
owner
or
owner
or
possessor
of
a
device.
H
Okay,
that
phrase
is
roughly
taken
out
of
a
conference
computing
consortium
white
paper,
where
a
number
of
teat
participants
help
to
review
and
or
author
the
text
in
the
white
paper,
and
so
my
hope
is
that
the
ccc
white
paper,
which
we'll
see
link
to
the
references
from
the
bottom
of
the
slide
there
and
in
the
document
in
the
actual
references
section,
would
be
okay
with
this.
H
But
a
couple
of
common
examples
that
hopefully
people
can
understand
is
things
like
a
gaming
console
right
where
whoever
is
in
physical
possession
of
the
gaming
console
right
you're
trying
to
protect
the
game
against
somebody
cheating
simply
because
they
have
access
to
a
gaming
console
things
like
you
know,
an
atm.
What
the
user
standing
in
front
of
the
atm
is
not
the
one
that's
authorized
to
decide
how
much
money
comes
out
of
that
device.
H
Things
like
you
know:
cell
phones,
where
it's
used
by
mobile
payments,
hosted
cloud
environments
and
so
on.
All
these
are
very
common
use
cases
for
tes
in
general.
What
you'll
see
is
there's
nothing
in
this
text
here,
that's
actually
specific
to
t
right.
This
is
just
explaining
background
information
about
the
security
assumptions
and
usability
assumptions.
What
is
the
trust
model
around
common
te
cases
to
begin
with
right?
This
is
before
we
get
into
the
actual
protocol,
part
of
the
intro
and
so
to
combat
the
particular
risk
of
oh.
H
This
conflicts
with
the
internet
is
for
end
users,
rfc
right.
The
point
is
that
such
environments
can
be
thought
of
as
hybrid
devices,
where
one
user
right
or
administrator
controls,
the
rich
execution
environment,
where
a
different,
a
remote
user
administrator
controls
the
tee
in
the
same
physical
device
right.
So
the
pointers
are
two
different
types
of
users
right,
the
one
in
physical
possession
and
the
user.
That's
actually
authorized,
do
you
think,
but
both
of
them
are
users
right
and
so
to
try
to
put
forward
this
note.
H
That
says
it's
actually
for
young
users,
but
just
different
classes
of
end
users
that
control
different
things
right
and
so
then.
The
last
point
is
that
there's
also
cases
there
is
no
local
user,
there's
only
a
remote
user,
and
this
would
come
up.
Often
in
many.
You
know
iot
cases
with
headless
devices
where
the
only
user
is
the
remote
te
administrator
per
se,
and
then
we
refer
to
ccc
white
papers
that
provide
a
much
longer
analysis
because
again
this
point
that
then
raised
this
part
is
not
really
about
the
t
protocol.
H
This
is
just
about
setting
the
context
for
tes
in
general,
okay,
so
that's
why
we
thought
it
was
useful
to
reference
the
ccc
white
papers
about
use
about
usability,
sort
of
use,
use
cases
and
scenarios
for
confidential
computing
in
general
and
tes
in
general,
okay.
So
that
was
what
we
did
in
the
introduction
text
and
then
the
security
considerations
was
the
other
part
of
the
privacy
considerations
in
particular.
H
So
again,
this
is
the
actual
snippet
of
new
code.
This
was
a
new
little
section
that
was
added
to
the
privacy
considerations,
primarily
for
ben's
last
point
that
you
may
be
reviewing
information
to
the
tam,
including
information
about
a
particular
person,
that's
sitting
in
front
of
the
machine-
and
let
me
finish
this
slide-
I
see
brennan's
and
q.
So
as
soon
as
I
finish,
this
slide
I'll
go
back
to
whichever
spot
you
want
right
now.
So
in
the
privacy
considerations,
right
again,
it
starts
with
by
reminding
us
of
that
applicability
right.
H
This
goes
back
to
that
intro
text
devices
have
a
te
that
protects
data
encode
from
the
ree
administrator
right
is
one
of
the
cases
right
and
then
again,
there's
two
examples:
the
cloud
hoster
case
and
the
device
manufacturer
case-
and
this
is
where
the
privacy
risk
is
that
data
in
the
ree
might
be
susceptible
to
disclosure
to
the
te
administrator.
H
And
to
explicitly
choose
to
have
a
te,
that's
managed
by
another
party
and
so
just
to
take
those
two
particular
cases.
The
cloud
poster
example
right:
the
choice
to
say
the
re
administrator
is
explicitly
aware
of
the
tu
administrator.
It's
because
in
this
example,
the
cloud
hoster
is
offering
a
service
right.
Your
t
administrator
can
become
a
customer
of
the
cloud,
and
your
ge
administrator
can
then
manage
things
that
are
host
in
the
cloud.
So
that
is
the
business
model
right
in
the
device
manufacturer
case.
H
Like
a
you,
know,
gaming
console
or
something
like
that.
Then
it's
a
choice
made
by
the
person
that
purchases
the
device
that
you
know
that
you're
not
going
to
have
complete
control
over
the
gaming
console
right
here,
because
you're
trying
to
get
you
know
gaming
out
of
it
or
whatever.
So
there's
two
examples
right:
one,
because
a
service
is
offered
in
one
direction
and
the
other
one
is
because
you
know
you
make
a
purchasing
choice.
Those
are.
C
J
Hi
brendan
morin,
can
we
go
back
to
privacy
considerations,
one
please,
okay,
so
there's
this
question
here
about
the
double-edged
sword
and
proving
or
and
and
the
the
user
agreeing
or
accepting
that
the
tam
is
going
to
deliver
what
it
says
it
will
deliver.
That's
the
whole
point
of
of
attestation,
not
remote
attestation
in
this
case,
but
local
attestation
can't
we
fix
this
up
with
attestation.
H
You
can
fix
up
part
of
that
testation
attestation.
Certainly
half
of
that.
That's
how
you
know
the
tam
is,
who
you
think
it
is
right.
You.
J
Remote
attestation,
I'm
talking
about
local
attestation,
the
te
proving
to
the
user-
that
it
is
indeed
running
the
software.
It
said
it
would
run.
I
Yeah,
I
think,
if
I
can
jump
in
as
and
kdek
the
author
has
a
comment
now
the
local
attestation
can
be
useful
in
many
ways.
I
think
there's
still
sort
of
a
requirement
that
the
user
trusts
the
crypto.
I
That
provides
the
attestation,
which
is
probably
the
case,
but
we
don't
have
a
great
way
to
require
or
reinforce,
and
I
think
dave
really
sort
of
hit
it
on
the
nose.
This
is
not
specific
to
the
t
protocol.
This
is
just
setting
the
stage
for
general
concerns
in
the
area
of
teas
in
general,
and
we
are
building
a
technology
that
is
useful
in
some
cases
and
it
also
may
be.
I
H
J
H
So
the
comment
that
I
was
going
to
make
is
that,
especially
since
teep
has
some
use
cases
where
you
can
have
confidential
code,
and
so
when
we
talk
about
personalization
data,
we
said
the
personalization
did.
It
could
even
include
code,
and
we
have
some
text
about
that
in
various
places
as
to
how
you
could
enable
that
what
that
means
is
that
the
end
user,
meaning
like
the
ree
administrator
or
the
human
sitting
in
front
of
you,
know
the
the
device,
whether
it's
a
gaming
console
or
or
whatever
it
is.
H
That
has
a
te
in
it.
You
may
not
know
what
the
software
is
that's
running
inside
there,
so
you
can
have
attestation
that
attends
your
point.
You
know
local
attestation,
that's
your
point
brendan,
and
so
you
can
get
a
hash
that
says
here's
what's
running,
but
you
don't
have
a
way
to
tie
that
to
what
you
know
that
that
code
is
doing
right,
because
the
whole
point
is
to
keep
that
code
secret
from
you.
So
you
can't
actually
vet
it
yourself
right.
H
Only
the
tee
administrator
can
vet
that
code,
you,
the
end
user,
may
not
have
access
to
that.
You
don't
know
what's
running
inside
of
your
gaming
console,
that's
drn
protected,
for
example
right,
so
you
don't
have
necessarily
a
way
to
say
how
do
I
get
faith
if
that
code
is
running
and
doing
what?
I
think
it's
doing,
because
you
may
not
be
allowed
to
know
what
it's
doing
right.
J
I
don't
want
to
derail
this
too
much
more,
but
I
I
guess
the
the
point
I
I
want
to
make
is
that
that
strikes
me
as
an
exception,
not
a
rule.
I
would
argue
that
the
more
salient
point,
for
me
personally,
at
least,
would
be
that
I
want
to
know
that
my
banking
app
hasn't
had
its
tam
compromised
and
shipped
me
a
trojan
instead
of
the
tee
or
the
ta,
that's
supposed
to
be
delivered
by
my
bank.
J
So
what
I'd
really
like
to
know
is
whether
I
can
verify
that
yes,
indeed,
the
thing
that
it
has
been
shipped
to
me
by
the
bank's
tam
is
actually
the
ta
that
they've
got
published
on
their
website
somewhere.
So
they
have
a
mechanism
to
verify
it
locally.
On
my
system,
as
well
as
via
the
town,
you
know
it's
a
it's
a
defense,
in-depth
question,
and
if
you
don't,
if
you
have
the
capability
to
do
that,
but
aren't
describing
it,
I'm
I'm
kind
of
at
a
loss.
H
So
I
think
you're
talking
about
your
suggestion
that
there
could
be
an
additional
text
written
into
here,
because
I
think,
there's
a
I
think,
you're
addressing
something
that
should
be
mentioned
in
the
privacy
consideration
section,
and
so
I
think
your
comment
would
apply.
I'm
interpreting
it
as
saying
you're,
arguing
that
we
should
add
another
sentence
to
the
text.
That's
on
the
screen.
J
H
Okay,
if
you
would,
if
you
would
like
to
help
us
suggest
such
a
tax,
you
know
suggestions
gratefully
accepted.
I
think
would
be
my
quick
response.
J
The
only
other
comment
I
would
make
was
on
privacy
considerations
too,
arguing
that
the
the
end
arguing
that
the
local
user
is
not
the
end
user
sounds
to
me
like
an
attempt
to
escape
from
the
relevant
rfc
about
the
internet
is
for
end
users.
Frankly,.
H
H
J
I
I
don't
well,
you
know,
I,
I
guess
that's
a
question
that
the
group
needs
to
discuss,
but
I'm
going
to
disagree
with
you
on
that.
So
that's,
okay,.
H
H
H
E
J
H
A
Yeah,
if,
if
you
can
take
it
to
the
list
or
brennan
and
dave
brendan,
if
you
have
suggestions
on
how
to
update
the
text
that
might
help.
But
it
seems
like
there
may
be
some.
H
A
H
Yeah
yeah,
the
document
is
currently
in
ietf's
last
call
since
ben
did
initiate
that
and
so
any
comments
we
can
take
in
as
part
of
ietf
last
call
and
if
there's
wording
suggestions,
that's
normal
hearing,
ids
last
call
things
are
going
to
come
up
so
all
right,
so
I'm
going
to
keep
going.
Okay,
nancy.
A
H
Okay,
so
this
one
was
actually
the
other
main
comment
where
ben
originally
posted
this
and
the
comments
on
the
transport
document.
But
actually
it
applies
to
all
the
documents
and
so
really
the
architecture
documents.
That
is
the
one
that
it
really
applies
to
as
being
the
context.
H
One
okay,
and
so
this
one
is
talking
about
a
denial
of
service
where
the
ree
can
conduct
a
denial
of
service
attack
against
against
the
t
protocol,
and
so
a
compromised
area
can
cause
a
to
not
receive
policy
changes
and
must
be
out
of
date
with
respect
to
policy.
H
And
so
I
think
this
is
the
text
that
we
did
in
to
respond
to
this
notion
of
dos
attacks
right.
So
we
point
out
that
you
can
cause
a
t
to
not
receive
policy
changes.
You
can
cause
the
t
to
be
out
of
date
with
respect
to
policy
mention
that
the
way
to
address
that
is
by
using
attestation.
H
H
So,
in
other
words,
there's
no
real
elevation
of
privilege
per
se
that,
if
you
can
compromise,
say
a
broker
running
the
re,
you
can't
compromise
the
t
protocol
and
then
the
last
piece
of
text
is
that
if
you
can
compromise
the
rich
execution
environment,
then
one
thing
you
could
do,
for
example,
is
to
remove
a
valid
dependency
from
an
untrusted
application
on
a
ta.
So
in
other
words,
you've
got
some
application
running
the
te
that
depends
on
a
tea.
H
If
you
can
compromise
the
ree,
you
could
say
hey
that
untrusted
application
no
longer
needs
your
ta
okay
to
clean
it
up.
Okay,
but
errol.
There
you're
not
really
harming
the
perspe
per
say:
you're,
hiring,
the
untrusted
application,
and
so
the
mitigations.
There
is
just
normal
security
mechanisms
in
the
rich
execution
environment,
and
so
hopefully
this
addresses
all
those
things.
But
this
was
not
in
the
protocol
say
we
put
this
in
the
in
the
architecture
document.
H
Okay,
unless
I
see
somebody
in
the
queue
and
a
trial
to
finish
up
this
document
here
ben
also
raised
the
question
on
the
text
about
in
the
security
considerations
about
validating
hbs
certs,
and
so
we
asked
might
ocsp
or
some
other
crl
mechanism
via
scope
should
we
mention
these
other
rfcs,
and
so
currently
we
went
back
to
the
ietf
111
discussion
and
you
can
see
the
quotes
in
the
minutes
there
from
russ
and
ben
that's
where
we
agreed
to
not
reference
ocsp
in
the
t
protocol,
although
there
the
context
was
about
end-to-end
ocsp
and
not
necessarily
about
the
hbs
certificate,
but
about
their
certificates
in
the
teep
itself.
H
Right,
but
extending
from
that
we
said
since
it's,
it
would
be
nice
to
not
have
to
put
another
protocol
under
there,
but
I'm
open
to
suggestions
on
this
one.
So
what
we
did
do
is-
and
we
still
left
the
reference
just
52.80,
but
we
had
the
phrase
but
certificate
status
check.
Protocols
may
not
scale
down
to
constrained
devices
that
use
t,
but
this
is
why
we
do
end-to-end
keying
inside
peak
protocol,
even
if
it's
inside
https
right
so
https
just
goes
to
the
ree
in
general.
H
H
It
sounded
like
ben
took
this
and
put
it
up
for
atf
last
call,
so
I'm
going
to
keep
going.
We
just
want
to
raise
the
visibility
if
people
think
that
is
important,
please
let
us
know
during
this
ietf
last
call
period,
but
right
now
all
we've
done
is:
we've
kept
the
reference
to
5280,
but
not
required
ocsp
or
anything
for
hps
just
allow
it
to
scale
down
so.
H
I
think
this
is
the
yeah.
This
is
the
the
last
main
slide
on
this
one.
There
were
three
different
bundling
examples
between
you:
have
an
untrusted
app
a
trusted
app
and
some
personalization
data,
and
how
do
you
package
those
three
for
distribution?
We
have
three
cases
that
the
document
mentioned.
The
first
case
is
all
three
of
them
right.
The
brackets
say
those
two
are
packaged
together
and
distributed
via
one
protocol.
The
other
bracketed
sections
distributed,
save
you
a
different
protocol
or
mechanism,
and
so
we
had
three
of
those
and
then
pointed
out.
H
Well,
there's
other
ways
to
combine
those.
Why
did
you
not
mention
those?
And
so
that's
what
four
and
five
are
we
gonna
go
for
completeness
we
put
in
some
text
about.
You
know
why
they
may
be
less
applicable
in
some
cases,
and
so
we
updated
the
list
as
well
as
we
updated
the
description
of
sgx,
the
discussion
trust
zone,
so
it
mentions
which
of
all
five
of
them,
instead
of
which
all
three
of
them
are
most
applicable
to
sgx,
which
ones
are
applicable
to
trust
zone.
H
But
those
are,
of
course
not
intended
to
be
by
way
of
limitation.
Those
are
just
examples,
so
how
will
they
apply
to
say
you
know
risk
five,
as
the
japanese
folks
are
doing
or
for
other
intel
or
you
know,
amd
or
whatever
else.
The
intent
is
not
to
cover
all
those
just
to
pick
two
examples
that
are
sort
of
different
implementations
and
say
how
teeth
would
be
applicable
or
which
parts
of
tape
replica.
H
So
that
was,
I
think,
just
editorial,
but
it
was
important
because
there
may
be
cases
where
people
actually
want
four
and
five
so,
but
it's
maybe
difficult
in
certain
implementations
of
these
all
right
last
slide
on
architecture
before
we
move
on
is
just
a
couple
of
bullets
here
there
was
a
question
about:
what's
the
difference
between
protect
process,
connect
versus
process,
t
message
in
the
abstract
apis?
H
Why
were
there
two
and
the
answer
was
it's
purely
an
editorial
distinction
to
help
understand
things
where
process
connect
is
a
request
to
request
a
new
session
and
process.
Cheat
message
is
a
processing
message
in
an
existing
session,
so
since
they're
abstract
apis,
you
can
always
implement
them
as
combined
or
have
split
processed
messages
in
multiple
ones
whatever
it
is.
This
was
just
a
convenient
way
to
describe
things
that
to
keep
the
concepts
of
new
session
versus
existing
session
different.
H
There
was
a
comment
about
use
of
the
same
key
for
both
signing
and
encryption.
Where
ben's
point
was
that
using
the
same
key
for
both
of
those
is
an
academic,
open
question
as
to
whether
that
weakens
things
or
not,
and
so
we
put
that
point
into
text
and
basically
use
ben's
wording
in
two
different
places,
one
for
the
te
pair
and
one
for
the
tam
pair.
The
same
wording
was
in
there
and
then
ben
suggested
various
other
editorial
nets
that
were
just
accepted
as
proposed.
H
A
H
And
so
you
can
see
the
timeline
there.
So
same
thing
is
now
that
the
protocol
spec
is
stable
enough,
that
we
don't
think
that
there's
major
changes
to
transport,
we
don't
think
there's
any
changes
transported
than
editorial
ones,
so
we'll
go
ahead
and
submitting
that
the
main
comment
on
this
one
was
the
dos
that
was
possible
by
the
re.
As
I
mentioned,
that
one
was
addressed
in
the
architecture
document.
H
The
only
change
in
transport
was
we
added
the
sentence
to
c
section
on
the
architecture
document
for
security
considerations
specific
to
the
use
of
t.
We
didn't
actually
have
that
in
the
in
the
transport
track
before
we
referenced
other
things
like
you
know
things
around:
https
security
and
so
on,
but
we
didn't
reference
the
deep
architecture
document.
So
we
had
that
because
everything
else
is
addressed
in
the
air
dock.
H
The
main
topics
on
the
transport
spec
were
comments
about
the
http
references
and
then
a
couple
minor
points
about
the
actual
logic
so
for
references
we
replaced
rfc
6125
with
an
internet
draft
reference,
because
that
draft
is
already
in
the
rfc
editor's
queue,
meaning
it's
going
to
beat
us
anyway.
So
we
just
update
the
reference
there's
two
other
documents
actually
75
75
25
and
another
version
6125.
H
They
have
active
disk
documents
in
uta,
but
they
are
only
drafts
and
so
right
now
it
looks
like
they'll
be
lagging
us,
and
so
we
could
pull
them
in
later
if
they
happen
to
hit
if
they
happen
to
go
into
rfc
editor
queue.
But
right
now
we
are
just
referencing,
the
the
posted
internet
posted
rfc.
So
we
don't
have
down
level
references.
H
And
the
notable
feedback
there
was
text
in
there
that
had
been
obsoleted
by
later
t
protocol,
spec
ones,
which
was
long
ago.
We
had
more
than
one
media
type
when
we
supported
both
json
and
cbor.
Now
that
we
only
have
cbor,
there
is
only
one
media
type,
and
so
we
could
remove
text
that
implied
that
there
could
be
more
than
one
so
that
removes
several
sentences.
H
Let's
make
sure
the
working
group
is
okay
with
us
being
a
should,
and
so
we
left
that,
since
we
already
passed
working
group
last
call
as
it
should,
and
the
belief
is
that
having
the
tam
treat,
that
is
in
the
error,
actually
prevents
bugs
and
encourages
more
protocol
interoperability.
But
of
course
it's
not
a
must
it's
just
a
should.
So
we
left
as
I
should,
because
we
didn't
want
to
have
to
revisit
working
your
best
call.
H
The
unrequest
ta-
this
is
how
you
choose,
which
tam
to
send
I'm
done
with
this
ta.
Now
all
of
my
re
applications
on
my
untrusted
apps
that
depend
on
it
are
now
gone.
The
tam
uri
was
not
one
of
the
parameters
to
the
abstract
api
in
the
pro
in
the
transport
spec,
and
so
we
had
to
update
that
for
consistencies
and
then
all
the
specs
match
and
then
again
ben
suggested.
Some
word
smith
thing
that
was
just
accepted
because
they
were
just
editorialized.
So
that's
it
for
transport.
A
I
don't
remember
dave,
I
think
you
said
I
don't
know
if
I
saw
the
changes
on
the
transport
spec,
but
ben
was
good
with
all
the
comments.
Yeah.
H
I
Seeing
last
call
and
the
last
call
got
extended
a
week
because
it
overlaps
the
itf
meeting.
But
I
was
happy
with
everything.
I
Sorry
yeah
dave's
right,
I
put
them
out
for
last,
call
because
I
was
happy
with
all
the
changes.
A
Okay
appreciate
it
yeah.
For
some
reason
I
missed
the
transport
one,
but
I
did
see
your
call
for
for
the
architecture,
one
okay,
so
up
next
akira.
E
A
Can
you
share
your
slides
or
do
you
want
me
to
it's
coming
yeah.
K
K
Yes,
so
we
we
had
a
hackathon
in
japan
team,
so
I
in
this
slide
I
was
a
little
bit
hurry,
so
I
didn't
list
up
all
the
people
but
usual
from
second
iso,
and
it
and
and
also
tragio,
is.
K
And
in
in
in
zuzak
sign,
I
think
it
was
in
me
and
I
think
that's
all
and
obviously
was
go
through
the
implementation
for
the
what
was
added
from
the
last
ietf
and
the
first
one
was
suit.
But
the
other
one
added
to
the
draft
is
eat
and
courses
which
is
a
significant
updates.
K
So
that's
going
through
and
finding
any
point
to
yeah,
revise
or
update
on
the
draft.
K
And
this
is
the
two
to
eat
model
or
at
the
station
model
I
saw
it
frequently
in
dave's
slide
and
not
2019.,
so
one
is
passport
model
and
one
is
back
background
check
model
and
in
in
the
in
the
current
t
protocol
draft,
it's
supporting
us
assuming
it's
honestly,
it's
identical
as
a
background
check
model
and
yeah
we
thought
about.
K
Should
we
what
should
we
go
only
for
a
background
check
model
and
for
in
our
implementation?
It's
it's.
A
handling
talking
with
the
verifier
from
the
directly
from
the
device
is
a
bit
more
overhead
for
the
constraint
device,
so
tam
doing
on
their
side
instead
of
the
device
side
is
yes,
it's
it's
nice
for
the
implementation
friendly
for
the
device,
so
in
the,
however,
it
might
be
okay
to
make
way
the
discussion
was.
It
might
be
okay
to
make
the
draft
a
little
bit
more
generic.
K
So
yeah
the
in
the
in
the
well.
At
this
time
we
really
didn't
have
much
idea
what
to
do
to
make
it
generic.
So
one
one
of
the
idea
was
just
having
the
attestation
result
or
evidence.
Format
in
the
eat
profile
is
able
to
display
english,
whether
it's
receiving
attestation
result
or
evidence.
K
Yes,
but
yeah.
K
And
the
next
is
about
c4
format
and
cbor
and
json.
So
ee
is
going
to
have
json
and
cbor
format
supporting
both
and
the
currently.
K
But,
however,
the
discussion
was
making
evidence
to
have
both
b
string
or
t
text
will
have
both
type
and
able
to
displaying
is
whether
it's
evidence
going
to
have
a
b
string
or
text
is
from
the
evidence
format.
It
might
be
more
friendly,
easier
to
understand
so
evidence
format
having
indication
of
the
json
or
cyborg
or,
alternatively
was,
and
the
transport
layer
has
a
type
saying
application,
jwt
or
application
cwt.
A
E
E
Yeah,
okay,
hi,
hi,
akira,
that's
honest
here.
I
wonder
whether
we
should
just
say
that
the
eat
is
in
in
in
sibo
format,
rather
than
leaving
out
leaving
the
options
possible
for
having
both
encodings
like
we
made
at
some
point
in
time.
The
decision
that
the
deep
protocol
is
also
only
encoded
in
one
format-
and
I
think
that's
easier
to
do-
I
don't
think
we
should
support
all
sorts
of
different
formats
just
because
it's
possible.
D
H
Yep
just
finding
my
mute
button,
so
the
teep
protocol
itself
just
carries
eats
as
opaque
dated
right.
It
doesn't
actually
care
right,
there's
nothing
in
the
teep
implementation
itself
that
carries
about
this
because,
like
in
the
background
check
model,
all
you
do
is
you
take
the
blob
and
you
forward
it
on
to
a
a
verifier
right?
So
there's
no
hard
dependency
here.
So
that's
why?
I,
I
don't
think
it's
you
it's
necessary
to
do
any
hard
restrictions,
it's
because
it's
just
a
payload.
Think
of
this.
H
As
like
a
transport
for
a
higher
level
protocol,
you
need
some
end
to
end
agreement
or
whatever
sure,
but
the
t
protocol
itself
doesn't
actually
care
when
you're
doing
a
constrained
implementation.
I
agree
with
hanus,
but
there's
no
reason
that
cheap
protocol
should
be
constrained
to
that
that
I
know
of
right
now
I
mean
I'm
open
to
it,
but
I
think
what
I
originally
got
in
the
queue
to
say
was
that
for
media
types,
I
think
that
application,
jwt
and
application
cwp
are
too
generic.
They
don't
mean
that
they're
eat.
H
It
just
means
that
that's
a
jwt
or
cwt,
and
so
often
in
media
types.
You
have
more
specific
media
types
than
just
the
generic
ones,
and
so
here
I
think,
there's
an
argument
that
says
the
rats
working
group
should
have.
I
should
define
eat
specific,
I
don't
know
remember
it
already.
Does
I
just
can't
remember
if
it
does,
if
I've
seen
that
any
place,
it
should
have.
H
Eat
specific
media
types
for
jwt
and
ccop,
rather
than
the
than
the
suggestion
ones
there
there
should
just
be
more
specific
ones.
You
know
you
know
application,
slash,
eat,
plus
jwt,
something
like
that.
That
gives
you
a
more
constrained.
Media
type
is
kind
of
the
media
type
guidance,
but
otherwise
that
was
my
god.
So
thanks.
K
Yeah
thanks:
okay
yeah.
We
will
yes
well.
We
could
keep
keep
discussing
and
update
the
protocol
about
it
and.
K
Yes,
we
decided
to
have
used
corsair
for
the
signature
and
organism
for
the
seaboard,
the
same
way
as
a
slip,
handling
because
soothes
handling
corset
and
and
if,
if
we
decided
to
use
different
way,
other
than
seat
or
eat
for
the
teep,
then
they
are
implementing
for
different
yeah
implementation
will
be
difficult.
I
mean
it's
not
difficult,
but
it's
more
time
consuming
and
more
overhead
for
debugging.
K
So
so
we
would
like
to
have.
We
would
like
to
use
we're
going
to
use
cose
and
also
the
supported.
Cipher
suit,
which
is
required,
which
is
recommended
which
is
optional,
is
will
be
not
far
away
from
suit
and
eat,
and
the
easiest
one
came
up
as
going
to
be
required
to
implement
and
for
the
implement
implementation
is
have
shot
256.
K
because
that's
already
required
in
suit
and
in
the
on
the
device
side
required
to
implement
either
of
one
is
es,
256
or
eddsa
and
device
side.
Implementing
either
of
one
is
probably
okay
for
the
time
side
it
might
require.
It
might
be
better
to
write
it
here.
The
good
to
have
a
better
mandatory
to
implement
both.
K
And
inc
recommended
implementation.
Yes,
this
is
what
hannah's
have
been
talked
in
the
past
and
having
hss
lms
for
quantum
resistance
purpose
and
other
one
pretty
much
typically
used.
Rsa,
aes,
symmetric,
ga
is
and
and
rsa
is
still
widely
used
in
many
places
and
also
other
the
other
one
is
even
the
aes
is
the
aes
accm
and,
and
some
of
the
industry
domain
is
the
shifting
from
ccm
to
gcm.
So
I
yeah,
I
thought
it
would
be
nice
to
have
put
it
in
in
the
optional
list.
K
And
so
far,
I
I
couldn't
find
the
shot
three
in
the
yana
registration,
but
the
pro,
if,
if
that
is
going
in
then
probably
could
be
good
to
have
in
the
optional
list.
K
K
10
24
is
a
little
too
weak
and
probably
mostly
it's
recommended
to
have
over
20
48
and
many
of
them
now
I
have
is
using
40
yeah,
40
96,
so
how
yeah
we
would
like
to
have
a
how
to
specify
key
length
of
the
rsa,
and
I
wasn't
with
I
wasn't
in
the
export
in
this
iana-
was
experiencing
corsair
format.
So
I
I
really
would
like
to
have
a
help
on
this.
K
K
Well,
it's
still
I'm
my
my
point
of
view
is:
have
make
it
generic
as
possible,
so
many
of
the
or
many
of
the
company
or
many
of
the
entity
will
use
teeth
as
much
as
possible.
So
I'm
I'm
not
saying
I'm
not
I'm
not
saying
we
should,
or
it's
good
to
have,
rsa
or
not,
but
it
it
doesn't.
I
thought
it
won't
hurt
just
having
in
the
optional
list.
E
Okay,
optionally
yeah,
because
I
I
I
don't
see,
requests
for
rsa
these
days,
at
least
in
in
my
environment
anymore,
and
so
so
I'm
curious,
like
he's,
actually
still
someone
asking
for
it.
Oh
no!
It's.
K
Not
nobody
is
asking
for
it
just
so.
The
most
most
important
is
in
the
page,
six
six
and
the
size,
the
left
side
required
and
recommended
list,
and
the
right
side
is
all
optional.
So
yeah
it's
optional,
so
people
will
freak
out
if
it's
aes
is
not
in
the
list
or
512
is
not
in
the
list.
A
K
A
K
I
think
yeah,
that's
great,
and
one
thing
I
could.
I
would
like
to
mention
as
I'm
getting
a
permission
is
the
implementation
for
the
tip
is
going
to
be
publicly
available
as
open
source
before
the
next
idf
114,
yes,
engineering
side
technical
side
is
mostly
complete,
not
on
not
you
know
from
a
while
ago.
Only
thing
pending
is
other
ministers
and
administrating
point.
Yes,.
K
L
K
K
K
A
H
H
H
It's
still,
okay,
it's
still
going
to
do
a
remote
one.
So
that's
okay!
I'll!
Do
it
this
way,
but
it's
not
asking
not
a
lot
of
share
screens.
H
It
gave
me
the
drop
down
from
the
from
the
uploaded
slides,
so
I'll
just
do
it
this
way.
That's
just
fine!
This
is
no
changes.
C
H
I
just
got
to
get
used
to
this
interface,
so,
okay,
so
now
we're
under
the
t,
protocol,
spec
and
so
a
curious
presentation
will
also
affect
the
protocol.
Things
too,
and
so
one
of
those
points
is
kara
mentioned.
We'll
come
back
to
you,
so
I
got
this
organized
in
terms
of
general
stuff,
then
the
suit
related
section
and
then
the
rats
related
section
at
the
end
that
order
so,
okay,
so
first,
the
document
has
been
updated
with
things
that
we
already
agreed
at
ietf
112.
H
So
just
to
refresh
your
memory,
I'm
not
going
to
go
through
these
in
detail
because
they're
in
the
minutes-
and
we
just
tried
to
do
exactly
what
we
got
consensus
on
and
confirmed
on
the
list
back
at
112.,
and
so
you
can
see
40
had
to
do
with
an
efficiency
change
of
being
able
to
reuse
stuff.
As
long
as
all
these
constraints
are
true,
we
went
through
that
at
2012
and
then
we
updated
the
clarifications.
When
is
the
token
included
in
the
update
message?
H
H
We
said
that
they
were
going
to
be
suit,
manifests
and
cure
presented
at
112
the
different
examples
there,
and
so
we
took
the
details
of
the
presentation
at
112.
We
went
through
there
and
put
those
into
things
in
the
spec
that
I
think,
if
I
remember
right,
akira
had
posted
this
per
request,
but
it
wasn't
merged
part
of
the
id
deadline
before
and
then
we
presented
it
at
112
and
so
you've
all
seen
it
and
all
the
stuff
that
accurate
presented
has
merged.
H
So
all
right,
so
now
we're
going
to
go
into
suit
specific
stuff.
That
is
more
than
just
what
we
talked
about
at
112
things
that
have
come
up
in
discussion
or
implementation,
or
that
was
listed
as
open
issues
before,
because
our
goal
is
to
be
at
zero,
open
issues
and
so
we're
at
least
at
zero
that
were
filed
before
so
all
right.
H
So
back
at
ietf,
111,
meaning
two
ietf
meetings
ago.
Brennan
had
a
great
presentation
about
examples
not
of
manifest
but
of
suit
reports
right
and
so
here's
an
example
in
the
bottom
right
of
one
of
brennan's,
slides
from
111
and
so
there's
now
an
appendix
that
takes
the
content
of
those
slides
put
those
in
appendix's
example
suit
reports.
There
is
a
request
for
me
to
brendan
to
say:
hey.
Can
you
please
check
that?
Because
I'm
not
sure
I
got
the
text
right.
H
That
goes
with
it
and
I
want
it
to
be
as
close
as
possible.
The
way
that
bretton
would
have
presented
it
and
so
just
a
request.
Yeah,
I
see
brendan
saying
we'll
do
okay
great,
since
these
were
your
slides.
The
point
is
to
be
as
accurate
as
possible
as
to
what
your
recommendation
was
there,
and
this
is
just
an
appendix
just
because
it's
samples
right,
it's
not
normative.
H
So
all
right,
everybody
else
from
suit-
is
welcome
to
review
them
too,
but
I
consider
brendan
the
most
authoritative
because
they're
his
examples,
so
all
right,
the
next
one
that
we
had
some
discussion
about,
but
we
didn't
have
proposed
text
before,
but
we
didn't
discuss
it
last
iatf
was
about
removing
and
we
started
using
the
term
unlinking
a
a
trusted
component,
and
so
here
things
that
we
did
do
is
we
added
the
suit
manifest
example
that
we
walked
through
at
112?
H
Where
that
manifest
example
was
a
case
where
you
were
unlinking,
you
know
removing
a
ref
count
on
a
trust
component
that,
and
that
was
done
using
the
directive
unlink
to
decrement
the
ref
count
right.
So
we
talked
about
that
last
time,
but
there
was
no
per
request.
So
we
put
that
into
the
actual
document.
Then
we
left
the
details
of
how
to
do
that
to
suit.
So,
in
other
words,
we
didn't
go
through
lots
of
things,
because
that's
really
it's
a
normal
suit,
manifest
thing:
it's
not
really
a
teep
specific
thing.
H
So
the
details
we
said
we're
going
to
leave
the
details
to
suit
documents
and
just
cross
reference
them,
and
we
just
had
a
suit
manifest
examples.
Here's
how
you
would
apply
that
in
a
teak
case,
but
this
did
result
in
adding
a
reference
to
a
newly
adopted
suit
document,
which
was
sprit
split
out
of
the
suit
manifest
in
the
suit
working
group
we
had
in
order
to
get
the
suit
manifest
document
done
as
fast
as
possible.
H
Then
we
took
some
of
the
things
that
were
still
being
discussed,
split
those
in
separate
documents,
and
so
the
suit
trust
domains
is
one
part
of
that,
and
so
we
then
had
to
add
a
reference
to
the
split
out
document,
which
is
now
an
official
suit
document
that
will
be
discussed
in
the
suit
meeting
later
this
week.
So
take
people
you
know
please
come
soon,
all
right
167!
H
H
So
at
112
we
said
we
were
going
to
get
rid
of
the
teach
specific
stuff
in
terms
of
an
eye
on
our
registry
and
just
use
the
cozy
algorithms
registry
right
for
reasons
that
akira
explains
right
and
so
what's
here
is
a
table
that
reflects
what
the
text
in
the
document
says.
The
table
isn't
in
the
document,
but
it
matches
the
logic
in
there.
I
put
it
in
the
table
form
just
for
slide
viewing
here
and
so
in
the
new
teep
spec.
H
There
are
signing
algorithms,
encryption,
algorithms
and
mac
algorithms
and
there's
a
list
of
possibilities
in
there
and
in
the
past,
we'd
agreed
that
for
the
mandatory
ones
that
both
of
them
were
on
the
look
at
the
signing
algorithm
top
two
rows
there.
They
were
both
mandatory
at
the
tam
to
allow
the
team
agent
to
pick
either
one
okay.
So
that
was
the
previous
working
group
consensus
that
says:
there's
two
of
them.
Maybe
one
is
more
forward.
H
Looking
one
is
more
practical
right
now,
but
the
point
is
the
tam
must
do
two
of
them
and
neither
of
them
individually
is
mandatory
for
the
teep
agent
you're
just
required
to
pick
one
or
the
other,
and
since
the
tam
supports
both
you'll
always
get
interoperability
all
the
other
ones.
There
are
listed
as
maze
and
that's
the
stuff
you
guys
were
just
talking
about
and
honest
you're
asking:
do
we
really
need
rsa
and
so
on?
H
Those
are
all
maze
right
now
and
so
whether
we
list
these
or
don't
list
maze
because
technically
you
could
argue
that
everything
that
goes
the
algorithms
registry
is
in
may
right,
and
so
how
many
maze
do
we
need
to
call
out
versus
just
saying
everything
else
is
in?
H
May
I
don't
know
this
is
what
the
document
has
right
now,
because
this
is
the
least
change
from
previous,
and
so,
if
you
think
that
we
should
remove
maze
or
add
maze,
no
big
deal,
we
can
do
either
one
or
leave
it
as
is,
but
the
must
on
here
at
the
top.
H
It's
what
we'd
previously
said
just
translated
into
cozy
algorithms,
but
since
before,
did
not
make
a
distinction
in
the
document
before
this
version
between
encrypt
algorithms
and
mac
algorithms,
you
can
see
which
ones
are
currently
listed,
as
must
right
now
in
the
cosi,
algorithms
and
feedback
welcome
on
whether
that
is
the
right
set
of
musts.
So
I
will
pause
for
a
second
just
to
make
sure
nobody's
going
to
get
up
at
the
mic
line,
but
otherwise
this
is
what
the
document
says
right
now,.
H
All
right,
so
this
cara
was
alluding
to
this.
The
proposal
from
the
suit
112
meeting,
okay-
and
I
think
russ
was
part
of
this
discussion-
was
that
you
know
to
say
something
like
in
the
keep
context
must
implement
hss
lms,
which
is
now
rfc
8778,
because
it's
quantum
resistant
and
should
implement
ecdsa
and
may
implement
others
right.
This
is
from
the
slide
at
ietf112
suit.
Okay,
now
what
you'll
notice
is
that
hms
lms
is
not
on
the
previous
slide.
H
Okay,
and
so
the
question
for
the
working
group
is:
what
do
we
do
about
that
discussion
as
reflecting
the
previous
slide,
and
so,
for
example,
you
see,
should
we,
for
example,
add
hss
lms
to
the
to
the
table
and
dropped
es256
on
the
previous
slide.
You
can
see
es
256
is
up
here
as
a
must
for
the
tam
and
the
t
page.
You
can
choose
that
or
ec
dsa
or
edgsa,
and
so
do
we
drop
that
one?
Do
we
add
hss
lms?
So
this
is
what
the
editors
want
to
know.
H
C
The
argument
we
made
was
that
for
a
firmware
load,
you
could
amateurize
the
big
signature
there
across
a
lot
of
software,
but
here
we're
talking
about
a
environment
that
could
be
quite
small
where
the
the
update
is
not
necessarily
a
full
firmware
load.
So
the
other
thing
we
were
saying
is
this
allows
us
to
move
to
a
post-quantum
environment
once
we
know
what
those
algorithms
are
and
once
we
do
know
what
those
are.
We
could
push
that
new
algorithm
here,
which
is
most
likely
going
to
have
a
more
reasonable
signature
size
anyway.
H
You
for
repeating,
because
your
audio
wasn't
great
for
your
first
sentence,
but
the
takeaway
is
leave
the
table,
as
is
for
now,
as
is,
I
think,.
E
Yeah
dave,
if
you
swipe
swap
over
to
the
next
slide,
I
wasn't
quite
sure
on.
E
Could
you
go
oh
yeah,
so
is
for
the
first
proposal
from
idf
suit
meeting
was
that
on
the
server
side
or
on
the
client
side.
H
Russ
is
the
best
person
to
answer
that
since
it
was
actually
his
proposal.
So,
okay.
E
But
yeah.
E
So
I'm
good
with
the
suggestions
made.
A
H
Right,
so
what
I'm
hearing
is
that
it's
a?
Is
it
okay
to
enter?
May
I
think
just
so.
We
don't
forget
the
point,
I
think.
As
an
editor,
I
would
probably
open
up
a
request
to
just
add
it
to
the
main
list.
So
it's
it's.
So
it's
it
stays
as
a
reference
from
the
document
rather
than
oh.
Did
you
even
talk
about
it
right,
so
it's
at
least
an
intentional
day,
as
opposed
to
a
apparent
omission.
So.
K
Yes,
to
write
it
in
the
cddl
in
the
deep
protocol
format,
I
was
copying
the
description
from
the
suit
so
cdo.
It's
there's
three
words
used
instead
of
a
master
may
or
should
so
it's
required
and
recommended,
and
it
was
optional.
So
yeah,
probably
it's
pretty
much
the
same
with
the
muscle
going
to
be
required
and
may
is
optional
and
hsa.
It's
just
lms.
K
H
Yeah,
I
lost
you
guys,
but
as
long
as
I'm
back
as
long
as
I
can
keep
hearing
echo
for
myself
in
the
faint
I'll,
keep
going
so
all
right,
so
I'm
gonna
keep
moving
on.
Since
I
don't
think,
there's
anybody
else
in
the
cube,
but
tell
me
to
go
back
if
I
need
to
all
right
we're
now
going
to
move
into
the
eat
section
so
now
for
for
rat,
spokes
and
so
all.
But
the
last
summary
slide
left
is
about
attestation
claims
and
so
on.
Okay,
so
issue
171.
A
H
It
keeps
going
out
now,
yes,
but
you
know
yeah.
A
H
H
All
right
so
we're
saying
the
rats
working
group
defines
the
notion
of
an
eat
profile,
and
this
is
what
the
eat
document
says.
H
You
must
specify
when
doing
an
e
profile
right
and
we've
said
we
need
to
have
an
eat
profile,
for
how
does
cheap
use
eat
right,
and
so
that's
what
issue
171
is
so,
let's
listen,
there's
just
the
bullet
items
that
are
the
required
things
and
the
eat
spec
that
you
must
do
the
following:
okay,
so
that's
our
checklist,
so
we're
gonna
walk
through
that
checklist,
okay,
so
the
first
one,
and
by
the
way
there
could
be
errors
in
these,
but
our
our
intuition
was
it's
always
better
to
put
something,
even
if
it's
wrong,
because
people
tell
us
that
it's
wrong
right
and
so
there's
no
claim
that
these
are
necessarily
the
correct
answers.
H
But
these
are
answers
right.
So
people
can
tell
us,
oh
no!
No!
This
is
wrong.
You
should
do
x
instead.
So
that's
the
goal
here.
Keep
that
in
mind,
okay,
so
the
first
one
we
needed,
something
that
was
the
profile
label
and
so
right
now
and
so
the
profile
labels
are
encouraged
to
be
uris
and
so
right
now
for
that
uri,
since
we
just
need
something
as
a
placeholder
we're
using
the
draft
name.
H
So
here's
the
url
of
the
draft,
with
a
note
that
says
eventually
the
uri
will
be
the
rfc
number
right,
there's
nothing
in
the
each
spec
that
says:
there's
a
convention
to
use
for
the
uri.
So
I'm
making
one
up
that
says
the
rfc
uri
is
the
is
the
uri
to
use
their
rats.
Working
group
might
say
use
something
other
than
that,
but
since
there
may
be
changes
between
now
and
then
we
at
least
went
on
a
temporary
uri
and
certainly
the
draft
uri
is
going
to
be
a
temporary
one.
So.
E
Dave,
I
wonder
whether
that
profile
label
should
be
should
also
include
other
options,
because
it
looks
like
a
very
long
uri
for
each
at
the
station
right,
even
if
it's
only
the
rfc
number
attached
to
that
uri
to
that
to
the
data
tracker,
something
something
or
rfc
editor,
I
yeah.
So
maybe
maybe
we
there's
there
should
be
maybe
some
profile
labels
sort
of
registered
for
standards
track
or
something
like
this.
You
know
what
I
mean.
H
I'd
say:
that's
would
be
a
topic
for
the
rats
working
group
that
we
would
follow
whatever
convention
they
set
and
right
now
my
understanding
is,
there
is
no
convention,
and
so
I
had
to
please
pick
something,
but
I
think
your
comment
would
be
a
very
appropriate
comment
to
make
in
their
ass
working
group.
Okay,.
H
So
then
there's
a
the
next
section
is
just
about
not
keys
per
se,
but
just
use
of
seaborne
other
encodings,
and
so
we
already
agree
that
there's
only
cbor
we've
already
made
changes
in
the
protocol
spec
before
to
use
definite
length,
arrays
and
maps,
and
so
I've
extrapolated
from
there
only
definite
linked
strings
are
allowed.
H
There's
note
about
preferred
serialization
and
you
have
to
say
what
encoders
and
decoders
have
to
do,
and
so
right
now
the
proposal
is
encoders
must
use,
preferred
and
decoders
need
not
accept
non-preferred.
So
if
you
want
interoperability
use
the
preferred
serialization,
we
never
used
seaboard
tags.
We
had
an
issue
about
that.
I
think
two
ietfs
ago,
where
we
had
that
agreement,
there's
a
whole
section
on
freshness
and
detached
eat
bundles.
I
am
not
the
expert
on
so
we
arbitrarily
said
dib
use
is
permitted.
H
Okay,
hopefully
audio
just
came
back
yeah,
so
my
analogy
was
that
detached
bundles
as
long
as
we're
gonna
allow
severed
suit
manifest
then
maybe
detached
eat.
Bundles
are
similar
but
open
to
feedback
on
that
go
ahead.
A
Harness
harness
yeah,
almost
hey,
hey
you're,
about
to
start
with
h,
hey
hank,
is
on
the
queue
hi.
A
F
Which
is
a
problem
I
would
say
in
rats
again
because
most
of
these
decisions
here,
I
think,
are
very
good
demarcation
line
where
we
want
to
cut
maybe
things
off
and
do
into
other
ids,
and
this
looks
like
a
good
call
for
each.
So
while
you
are
bringing
this
up
here
as
a
profile
for
it
I'll
even
go
so
far
and
saying
this
could
be
the
core
eat,
not
not
talking
about
the
detached
eat,
bundle
because
that's
new
and
you
know
so,
but
the
rest
actually
I'd
say
that
could
be
eat.
A
A
F
H
H
F
It's
psas
or
psa
token
and
yeah.
So
no,
this
is
not
the
first
definitely
but,
but
I
think
it
also
overlaps
a
lot
so
honest.
If
you
can't
see
anything
here
that
wouldn't
align
with
c
and
so
this
could
be
eat
might
be
the
core
of
eat.
Okay,
I
will
bring
this
up
yeah,
I
volunteer,
so
to
say
I
would
be.
H
H
That
would
be
great
hank,
because
right
now
we
have
text
in
the
document,
for
this
and
it'd
be
great
to
remove
text
and
just
reference
in
each
section.
That
has
you
know
a
default
or
a
core
profile
or
whatever
you
want
to
call
it.
So
all
right,
so
I'm
going
to
keep
going
out
of
the
next
section
of
the
checklist.
H
So
now
we
get
into
algorithms
and
things,
and
so
for
coset
algorithms.
That
was
the
slide
that
we
just
walked
through.
That
was
that
table
and
that's
in
a
different
section,
so
that
checklist
is
see
previous
slide
right.
Well,
I
guess
I
had
detached
deep
bundle
on
this
slide.
That's
a
duplicate,
never
mind
and
then
for
a
verification,
kit,
identification.
H
I
tried
to
make
something
up
here
so
happy
for
somebody
to
tell
me
it's
wrong
or
what
I
should
say
instead
and
so
verification
key
identification
right
now
it
says
the
cosec
key
id
is
used
with
the
key
id
is
the
hash
of
a
public
key
or
the
public
key
may
be
used
as
a
raw
public
key
or
a
public
key
in
a
certificate,
but
it's
the
hash.
E
E
As
a
as
a
way
to
identify
the
key
and
that's
not
necessarily
the
hash
of
the
public
key-
it's,
for
example,
a
uuid
or
something
similar.
So
maybe
that's
more
recommended
one
recommended
approach,
but
there's
all
sorts
of
different
schemes
for
naming
sort
of,
like
the
the
the
specific
instance
of
of
the
device
or
the
chip
that
you
are
testing.
H
H
It
if
you'd
like
to
propose
specific
text
that
you
think
are
consistent
with
say,
other
eat,
profilers
or
whatever
I'd
be
happy
to
match
again.
This
is
the
case
where
I
was
trying
to
tease
out
suggestions,
so,
okay
cool,
but
you
know,
if
you're
doing
something
another
document.
We
then
there's
a
good
reason
to
say:
hey
in
a
constrained
implementation,
you
should
be
able
to
do
two
different
things
and
use
the
same
rule,
and
so
consistency
across
heat
profiles
is
great.
H
I
I
H
Okay,
so
claims
yeah,
let's
now
get
into
the
claims
part
and
we've
had
lots
of
discussion,
including
at
the
t,
suit
rats
interim
meeting
about
claims.
Okay,
so
right
now
on
the
eat
profile,
all
the
claims
relevant
are
in
the
optional
claims
section
right.
There's,
there's
no
single
case
where
a
particular
claim
is
is
actually
required
in
all
possible
deep
cases
right.
H
So
the
next
one
next
slide
actually
has
all
those
claims,
but
right
now,
they're
all
in
the
optional
section,
there's
nothing
in
the
required
or
are
prohibited
sections,
and
so,
when
we
get
to
the
next
slide,
keep
that
in
mind
in
case
you
think
there's
something
on
there
that
should
be
listed
as
required,
and
so
the
next
slides
cover
every
all
the
claims
that
are
relevant
for
the
profile
for
t,
but
none
of
them
are
individually
required
right.
H
H
The
last
point
is
worth
that
mentioning
here
for
suit
folks,
just
in
case
brendan
or
hank,
or
somebody
says
that
it's
wrong.
Please
review
this,
so
call
attention
to
it
for
manifest,
and
software
evidence
claims
okay.
So
right
now
the
software
name
claim
in
rats.
H
The
placeholder
is
that
the
software
and
in
claim
holds
the
uri
of
the
suit
manifest
for
that
component
right.
We
need
something:
that's
the
unique
identifier
for
that,
and
so
right
now
brennan
suggests
the
canonical
uri,
but
it's
still
the
canonical
uri
of
the
suit
manifest
right,
as
opposed
to
some
other
uri,
in
other
words,
we're
referencing
the
the
software
component
by
its
manifest
as
being
the
official
id
right.
So
that's
the
proposal
and
yeah
I
get.
We
can
add
the
word
canonical
in
front
of
uri.
If
that
makes
people
happier.
H
I
agree
with
brennan's
point
there,
but
since
this
is
a
point,
we've
never
discussed
before,
how
do
you
marry
the
the
e
requirements
with
the
suit
manifest?
And
so
the
proposal
is
oh
brandon.
Please
get
up
the
mic
and
tell
me
what
what
words
you'd
like
changed
or
whatever,
because
if
you
have
a
suggestion,
happy
to
accept.
H
J
H
Okay,
actually,
I
didn't
miss
a
slide
here.
This
is
the
next
one
yeah
okay,
so
I
just
wanted
to
so
this
issue.
165
was
the
one
that
was
discussed
at
the
intro
meeting
where
we
went
through
the
various
claims
that
were
in
the
draft
burke
hall's
rat
suit
claims.
That
document
defines
some
system
claims
and
some
suit
specific
claims,
and
so
the
the
the
relevant
discussion
for
teep
was
in
the
system
claims
section
of
that
document.
H
Now
this
gets
back
to
one
of
the
points
that
here
was
talking
about,
and
kira
talked
about
the
background
check,
model
and
passport
model
where
in
t
we've
said
the
background
check
model
is
the
one
that
is
the
more
typical
because
it
works
better
with
constrained
devices
for
for
a
team,
but
it
turns
out
that
the
passport
model
is
not
actually
precluded
in
teep.
H
If
somebody
wants
to
do
that-
and
that
gets
to
the
point
that
the
t
protocol
does
not
actually
have
a
hard
dependency
on
the
evidence,
format
of
the
e-format
or
whatever,
because
it's
just
a
pass-through
right,
so
it
turns
out-
you
could
actually
use
the
t
protocol
with
attestation
results
for
that
matter.
In
the
passport
model,
right
you'd,
stick
it
into
the
field,
that's
currently
labeled
evidence,
and
so
I'll,
probably
file
a
request
and
just
point
this
out.
Then
whether
it's
evidence
or
attestation
results
just
typically
evidence
right.
H
A
A
H
Now
often
the
claims
and
the
attestation
results
are
going
to
be
derived
from
claims
in
the
evidence,
so
the
claims
that
we're
talking
about
might
be
things
that
appear
in
the
evidence
for
a
purpose
of
being
copied
into
attestation
results,
but
the
end
of
the
day.
These
are
claims
that
the
relying
party
needs
to
be
able
to
get.
K
F
No
one,
so
this
is
hank.
I
want
to
take
make
a
comment
on
the
third
bullet
item
of
the
previous
slide.
We
have
seen
that
says
that
claims
in
the
testation
results
can
be
copied
over
from
evidence.
So
I
have
a
relatively
good
visual
memory,
and
that
is
a
big
problem.
F
F
So
so
I
think
the
problem
here
is
with
the
third
bullet
item
on
the
previously
shown
list.
Nancy
is
going
there.
F
F
It
is
very
important
to
add
to
the
definition
of
that
claim
that
when
it
appears
in
the
testation
result,
this
is
not
evidence,
but
this
is
the
output
of
a
policy
that
does
a
I
don't
know.
Bytes
copy
of
the
value
from
evidence
into
the
attestation
result,
one
by
one
there's
a
policy
that
says.
If
I
like
the
rest
of
the
evidence,
then
I
can
copy
this
as
complementary
information
into
an
attestation
result,
it's
very
different
to
the
fact
that
it
appears
in
evidence
that
has
a
different
meaning.
F
So
now
I
would
be
stuck
with
understanding
who
signed
that
conceptual
message
and
you
are
not
obligated
to
say
this
is
an
attestation
result
eat
it's
just
a
cwt.
Never
forget
that
now
you
have
to
understand
that
the
signature
is
doing
the
context
and
segment
x
and
that's
really
bad.
So
there
has
to
be
an
out
of
band
agreement
between
the
relying
party
and
the
verifier
that
this
is
a
copied
overvalue
from
evidence,
and
if
you
can't
establish
that
out-of-band
context
this
is
broken.
F
I
just
have
to
really
point
that
out:
okay,
unless
you're
doing
something
else
that
is
co-locating
another
verifier
on
the
entity,
that's
the
relying
party
and
then
say
sure
we
can
relay
that
evidence
actually
and
the
party
has
a
stop
verifier
that
can
make
sense
out
of
that
and
now
evidence,
but
that
is
co-located
with
attestation
results.
I
think
that's
that's
a
very
underestimated
problem
for
consistency
and
it
will
break
a
lot
of
levels
of
things
and,
if
not
done
right,
so
I
think
item
three
is
really
dangerous.
If
not
done
correctly.
A
F
Do
three
without
explicit
highlight
that
there's
policy
on
the
verifier
that
did
this
copying
always
imply
if
a
raw
value
from
evidence
appears
and
hit
the
station
results
with
this
name
same
claim,
type
claim
name
right,
make
sure
that
is
out-of-band
policy
established.
That's
then
you
are
jesus.
We
lost.
F
H
If
I
have
audio
right
now,
then
the
point
is
that
third
bullet
fair,
is
just
a
statement
about
what
a
verifier
could
have
policy
that
it
chooses
to
do.
There's
nothing
that
keep.
This
is
just
an
informational
note
to
the
reader
that
says
the
verifier
could
have
that
policy
from
the
parts
that
I
could
hear
what
hank
was
saying.
I
actually
agree
and
there's
nothing
in
team
that
actually
says
other.
H
So
I
think
what
hank
said
the
intent
is
that
the
draft
says
what
hank
said.
The
the
slide
is
just
an
fyi
by
the
way
your
verifier
could
choose
to
copy
stuff,
but
what
heap
actually
depends
on
is
having
some
claims
in
the
attestation
results,
whether
they
come
from
evidence
or
someplace
else.
It
does.
The
type
has
no
way
to
know
because
it
only
sees
the
the
the
attestation
results
at
their
lying
party
so
and.
H
F
H
H
F
H
F
F
F
H
H
All
right,
this
is
the
set
of
claims
we've
been
talking
about
all
along,
you
can
see.
Draft
07
is
the
middle
column.
That's
what
the
draft
used
to
say
what
the
graph
now
says
is
the
right
side.
So
you
can
see
all
of
those
are
now
referenced
again.
This
is
the
system
claims
category,
not
the
suit
claims
category,
all
these
reference
eat,
except
for
the
one
that
we
had
the
long
discussion
at
the
intro
meeting.
H
It's
just
highlighting
that
that
this
issue
isn't
it's
close
to
the
set,
to
the
extent
that
we
can
close
it
now,
but
it
does
still
have
what
do
we
do
for
the
class
of
device
in
the
t
context?
So
since
we
spent
all
the
intro
meeting
talking
about
that,
I
think
we
can
go
on
since
we've
had
lots
of
recent
discussion
all
right,
so
the
proposed
next
steps
are
to
update
the
document
with
feedback
from
the
hackathon
all
the
discussion
from
this
meeting.
H
The
hope
is
that
whatever
the
next
rev
is
we'll
be
ready
for
working
group
last
call
because,
hopefully
we're
teasing
out
all
the
last
issues
and
stuff
now
between
implementation
and
spec
review
that
the
implementations
are
complete
enough,
that
we
hope
all
the
issues
are
found
that
would
at
least
block
us
from
entering
working.
Your
blast
call
right.
H
A
Can
do
it
even
before
okay,
so
once
once
you
generate
a
new
version
dave,
let
me
know-
and
I
can
kick
off
the
early
reviews
how's-
that
okay.
H
Now
I
I
do
want
to
huddle
with
hank
to
see
if
we
can
work
out
what
the
right
thing
is
in
that
last
point.
So
that's
the
only
thing
that
really
worries
me
right
now
that
I
don't
have
a
good
understanding.
I
think
everything
else
we've
discussed.
I
have
a
good
understanding
of
what
the
editors
can
do.
Next,
I
think
hank's
point
we
want
to
follow
up
on
try
to
work
out
what
the
proposal
will
be
so.
A
F
This
is
hank,
so
so
so
the
thing
is
that
I
was
talking
about
exactly
that
point
with
lawrence
extensively
and
we
have
prepared
a
two
early
proposals:
how
to
deal
with
that.
Okay,.
A
F
A
very
new
pr
look
at
the
latest
pr,
the
youngest
pr
in
the
eat.
Repository
thing
lawrence
pushed
something
that's
based
on
the
discussion
from
the
hackathon
and
it's
about
exactly.
A
A
Sorry,
I'm
trying
to
bring
all
my
too
many
windows
this
one
nope.
N
Thank
you,
okay,
so
hello,
everyone
I
would
like
to
share.
Maybe
a
use
case
or
idea
about,
can.
N
Okay,
I
would
like
to
share
a
idea
about
computational
computing
in
the
computing
aware
network,
and
the
reason
I
would
like
to
share
in
the
tip
is
because
that
this
architecture
will
you
use
tip
protocol
to
implement
the
this
configuration
computing.
N
So
next
slide
is
about
the
so
first
we
need
to
figure
out
what
is
can
what
is
a
computing
aware
network
literally
it's
an
idea
about
the
which
is
computing
and
network
resource
joint,
optimization,
based
on
the
awareness,
control
and
management
over
network
and
computing
resource,
to
determine
the
appropriate
service,
node
and
dispatch
the
service
request
and
provide
a
better
use
experience.
N
N
N
So
the
red
side
of
the
picture
shows
that
the
logical
layer
of
the
can
and
the
first
layer
is
operation
layer,
it's
about
the
computing
resource,
transaction,
a
unified
operation
of
open
capability,
etc,
and
the
second
layer
is
orchestration
and
management
layer.
It's
about
the
computing
resource,
orchestration,
air
engine
and
this
item
it
should
be.
N
The
business
management
is
a
mystic,
I'm
sorry
and
the
third
layer
is
the
can
foundation
it's
about
the
edge
computing
resource
and
the
central
computer
resource,
and
this
resource
will
communicate
with
each
other
by
the
ip
network,
and
this
app
network
should
be
the
can
network,
and
this
protocol
has
haven't
been
decided
yet,
but
it
will
be
discarded
in
the
birth
of
can.
Can
I
think
it's
a
tuesday,
or
so
I'm
not
sure
so.
N
The
difference
between
between
the
care
and
the
cloud
computing
is
that
that
can
is
based
on
network
layer,
so
computing
task
requirement
and
scheduling
are
carried
by
protocols
in
app
network.
From
the
perspective
of
network
layer
cloud
computing
is
just
application
layer
data
which
cannot
be
aware
by
the
network.
N
So
the
advantage
of
the
account
is
that
the
network
latency
is
awareness
and
the
network.
Topology
is
awareness
and
the
convergence
with
network
source
and
the
computing
resource
is
available.
Think
about
that,
if
you
use
cloud
computing,
the
cloud
computing
data
flow
will
just
be
an
application
layer
in
the
network
and
there's
a
decouple
of
the
cloud
computing
and
the
network.
So
I
think
the
can
is
a
better
option
for
the
applications
that
have
the
latency
sensitive
and
some
requirements.
N
So
next
slide
is
that
why
we
need
confidential
computing?
You
can,
and
I
think
the
requirement
is
from
the
can
user.
If
the
computing
resource
is
a
third-party
resource
like
the
edge
computer
resource
which
both
they
can
and
the
network
user
cannot
trust
its
security,
then
we
need
the
confidential
computing
technology.
N
So
if
the
another
is
that,
if
the
network
user
cannot
trust
the
computing
resource
controlled
by
the
cadillac,
the
central
consumer
resource,
then
the
competition
computing
technology
also
is
also
needed.
So
when
we
introduce
the
computational
computing
to
the
network,
I
think
the
two
components
are
mostly
involved.
The
first
one
is
that
the
cpu
of
computing
resource
must
have
the
feature
like
the
computer
computing
like
the
sdx,
tdx,
etc,
and
the
second
is
that
the
execution
and
the
management
layer
must
have
the
confidential
computing
feature
which
supports
like
tip
and
rest.
N
So
so
next
slide
is
the
main
architecture.
So
I
think
lots
of
you
have
familiar
with
tip
and
rats,
but
in
this
architecture
we
added
two
components:
one
is
middleware
and
the
other
is
midway
repo,
and
the
reason
is
that
we
want
the
user
to
use
computational
computing
in
a
network
with
convenient,
which
means
that
if
network
want
to
use
the
computational
computing
resource,
it
doesn't
have
to
change.
I
have
to
change
any
of
its
source
code.
It
just
says
that,
well,
it's
a
computing
resource,
it's
a
competitive
computing
resource,
so
I
just
use
it.
N
I
don't
do
it
doesn't
have
to
change
anything
of
my
source
code,
so
another
function
of
the
middleware
is
that
it
can
provide
like
remote
attestation
and
provisioning
instead
of
let
the
application
itself
to
the
function.
I
think
this
is
much
more
convenient
than
the
traditional
t
or
red
architecture.
N
So
this
is
the
main
idea
of
this
draft
and
the
next
shows
that
how
how
this
works.
So,
if,
if,
if
a
application
owner
want
to
request
for
the
conversation
computer
resource,
it
first
will
connect
to
the
mlc
all
the
time,
then
the
second
step
is
that
the
time
it
will
establish
connections
to
the
broker
and
send
the
provisioning
information
like
the
middleware
to
the
t
broker
step
three
will
be
that
the
tip
broker
will
trigger
this.
N
Maybe
it's
a
hypervisor
to
establish,
establish
the
targeting
environment
with
tip
agent
and
middleware,
so
the
mapping
between
the
tip
concept
and
the
instantiation
is
that
the
left
side
is
the
concept
and
the
right
side
is
the
instantiation
in
the
engineering,
so
the
mlc
time
and
the
middleware
ripple
may
be
a
computing
resource
expression
in
in
can
and
the
pt
broker
may
be
a
function
of
stack
and
the
tip
agent
at
the
middleware.
Maybe
some
openstack
initiates
the
guest
vm,
which
includes
a
chip
agent
and
a
specific
middleware
like
a
anarchogram
and
or
clone.
N
So
next
slide
is
about
the
arrest
in
can
so
after
the
first
provisioning
of
the
middleware,
then
the
rats
will
will
work
on.
So
the
first
step
is
that
a
application
owner
may
ask
for
a
remote
attached
remote
attestation.
Then
the
second
step
is
that
the
middleware
triggers
a
attestation
environment
to
generate
remote
attestation.
Evidence
for
targeting
environment
and
step
three
is
that
the
application
owner
gets
the
reference
value
and
the
reference
value
may
be
maybe
could
generate
with
source
code
and
the
images
like
the
middleware
and
the
tip
agent.
N
Maybe
it's
a
could
query
from
the
third
third-party
authority
for
the
reference
value
and
the
step
four
is
that
the
middleware
will
return
the
evidence
to
a
picture
owner
and
the
owner
could
match
it
with
a
reference
reference
value
and
decide
if
it
will
trust
the
attacking
armament,
and
there
is
a
potential
step.
Five
is
that,
after
the
trusted
targeting
environment,
the
pledge
code
application
owner
will
provision
is
application
to
the
targeting
environment.
So
after
that
the
application
will
run
in
a
trusted
and
confidential
environment.
N
So
that's
a
basic
idea
of
the
rats
how
it
works
in
this
architecture
and
the
mapping
between
the
rights
concept
and
the
instantiation
is
that,
for
example,
the
attestation
environment
could
be
called
enclave,
an
sp
and
rmm
and
etc,
and
the
targeting
environment
could
be
a
guest
vm,
which
includes
the
tip,
middleware
and
application,
and
the
targeting
environment
may
also
be
a
process-based
environment
like
the
sgx,
so
that
in
that
way,
the
t4
agent
and
the
middleware
will
be
a
function
or
routine
in
a
process.
N
So
next
slide
slides
is
about
the
potential
next
step
about
this
confidential
computing
network.
N
Maybe
it
could
be
used
as
a
specified
tpu
use
case
about
the
conversational
computing
with
middleware
or
specify
the
right
use
case
about
the
computational
computing
under
its
middleware,
or
it
could
be
that
a
unified
tool
or
specification
for
appb
owner
to
execute
a
remote
edition
and
the
provisioning.
N
So
if
you
are
interested
in
this
idea,
maybe
we
could
discuss
more
about
that
and
see
how
we
can
move
forward
about
this
idea.
So
if
you
are
interested,
please,
let's
have
a
discussion.
Thank
you.
That's
that's.
It.
E
Hi
bing
hi.
Could
you
go
back
to
slides?
I
have
a
question
about
the
drawing
to
better
understand
sort
of
the
boxes
so.
E
Five
or
so
yeah,
so
this
one
so
on
the
on
the
right
hand,
side
with
the
diamond
the
middleware
repository
like
that's
on
the
server
side,
that's
the
box
for
the
server
side,
the
app
owner
is
obviously
well,
not
obviously,
but
the
app
owner
is.
That
would
be
a
different
server
before
with
the
owner
like
the
human.
Next
to
it,
the
errors.
What
do
the
errors
mean
in
your
drawing
because
they
are
not
necessarily
are
they
protocol
messages
or
are
they?
What
do
they
represent
or.
E
N
E
Right
so,
okay,
if
we
look
at
the
the
boxes
on
the
left-hand
side,
like
you
have
the
target
environment
and
then
the
hypervisor
and
cpu
firmware
below
is
that
that
is
that
supposed
to
be
in
one
device
or.
N
Because
there
are
separate
boxes,
yeah,
that's
that's
one
device!
That's
a
different
layer
of
of
a
confidential
computing
resource.
E
So
in
the
the
green
box
is
that
that's
in
the
in
the
normal
world
so
in
the
ree?
Is
that
true?
No,
no!
The
green.
N
So
what
I'm
trying
to
to
say
is
that
the
the
black
application
could
just
load
loaded
into
the
targeting
environment
and
wizard,
and
it
changed.
It
could
just
directly
run
the
application
without
any
change
of
the
source
code
to
fit
into
the
the
composition,
computing
cpu.
E
Okay,
yeah,
okay
and
the
deep
the
deep
broker
in
in
many
other
diagrams.
It
was
running
on
the
the
rich
execution
environment,
but
here
you
are
running
it
on
the
hypervisor
that
and
that
may
be
maybe
a
possibility
so
like,
for
example.
E
So
if
I
take,
for
example,
veracruz
this
one
possible
middleware,
so
the
deep
age
the
middleware
would
be
veracruz
and
the
deep
agent
would
be
somewhere.
Let's
say:
where
would
that
be?
That
would
probably
be
maybe
an
option
or
so,
and
the
application
would
be
vasom
running
on
veracruz.
E
Is
that
sort
of
roughly
how
I
I
I
should
understand
it,
or
I
think
it
would
be
good
to
have
an
example
on
how
this
is
instantiated,
to
have
a
a
good
understanding
on
how
you
would
actually
turn
this
into
a
working
system.
N
Here
I
think
the
next
slide
shows
that
the
concept
and
the
instantiation
and
how
they
mapping
with
each
other-
and
this
is
the
very
earlier
draft
of
this
idea
and
maybe
there's
something
incorrect,
and
this
is
just
the
meaning
of
it.
I
want
to
share
so
maybe
the
mapping
is
not
correct
and
we
can
discuss
it
more
about
that
after
the
meeting.
I
think.
G
Yes,
thank
you.
This
was
interesting.
I
I
can't
I
I
can't
claim
to
fully
understand
old
aspects
here.
I
think
we
need
to
read
the
draft
again,
maybe
or
or
have
more
discussions.
I
do
of
course
agree
that,
like
it's,
it's
super
useful
to
have
these
kinds
of
capabilities
that
you
could
provide
some
computing
facilities
for
applications
in
the
network
or
close
the
network
and
and
be
able
to
provide
at
the
stations
and
the
protections
that
tes
can
can
can
provide.
So
I
think
that's
good.
G
I
did
have
a
question
sort
of
one
detailed
question
on
the
record
draft
section.
Six
is
about
the
use
case,
examples
and
it
mentions
like
vr
ar
applications
and
it
it
does
say
that.
G
The
applications
don't
want
the
conversation
to
be
or
the
network
to
be
aware
of
their
conversations,
but
then
it
also
says
that
it's
hard
to
encrypt
all
the
vr
context
because
of
an
unacceptable
cost,
and
I
would
actually
argue
that
that's
not
exactly
what
I
would
expect
to
see.
I
would
expect
to
see
that
there's
both
protection
of
the
data
in
transit
so
and
that
that
we
can
do.
I
think
we
can
do
that
and
also
protection
of
the
data
in
you.
So
this
is
what
we
can
do
with
confidential
computing.
N
G
N
N
So
especially,
you
have
the
tdx
architecture
or
some
like
some
architecture
like
memory
encryption.
Then
you
can
run
your
code
in
an
encryption
type.
G
Right
yeah,
maybe
it
was
just
that's
the
way
that
it
was
written
that
led
me
to
be
confused
a
little
bit,
but
I,
of
course
I
agree
that
you
can't
always
process
only
encrypted
data.
You
have
to
have
these
situations
where,
where
you
get
get
to
process
the
actual
unencrypted
data,
and
in
order
to
do
that
safely,
we
wrap
it
inside
the
confidence,
a
computing
enclave
or
something
so
yeah.
I
I
think
I
agree
with
that.
J
A
You
know
it
may
be
interesting
for
you
to
share
those
thoughts
in
that
I
don't
know
if
there's
a
mail
list,
but
in
that
community,
as
well
in
that
group.
I
Material
yeah.
I
was
just
mentioning
that
the
specific
session
time
slot
for
the
canva
was
the
first
one
on
tuesday,
because
I
think
you
had
mentioned
it
was
either
tuesday
or
you
weren't
sure,
and
I
just
left.
I
think.
A
I
saw
yeah
ben,
I
was
looking
at
the
at
the
agenda.
I
think
it's
tomorrow.
N
N
E
A
I
still
would
encourage
you
if
there's
a
mail
list
for
the
can,
since
there's
a
buff,
that
you
might
solicit
feedback
from
that
group
as
well:
okay,
okay,
any
orders
of
business
comments;
feedback,
if
not
good
progress,
guys.
Thank
you
and.
E
A
A
Thank
goodness
yeah,
but
there
was
a
lot
of.
I
think
there
are
some
miss
well
dave,
couldn't
hear
hank's
comments
directly
right
and
I
think
hank
was
just
reacting
to
the
text
on
the
slide,
because
the
slide
said
something
might
copy
right.
The
attestation
results,
which
hank
is
right.
Unless
you
have
good
provenance,
then
how
do
you
know
whether
you're
getting
that
result,
the
original
or
a
copy,
and
that
the
copy
hasn't
been
fudged
right.
A
Well,
it's
a
question
of
context.
It's
question
of
policy
whether
the
copying
is
allowed
or
not,
but
I
don't
know
that
that's
in
scope
for
teep,
and
so
my
suggestion
is
in
that
scenario
it
should
be
listed
in
the
security
considerations
of
it
would
be
a
violation
of
the
design
if
that
were
to
be
allowed,
meaning
in
big
letters
policy
do
not
allow
this
to
happen
right,
but
if
you
are
going
to
let
it
happen,
then
we
need
to
change
the
schemas
to
allow
for
the
prominence
to
come
through.
I.
A
So
on
the
chat
brendan
and
dave
were
saying:
well
nowhere
in
the
draft
do
we
say
that
we,
you
know
that
a
copy
is
allowed
or
not.
Well,
now
that
you
let
the
cat
out
of
the
bag,
that's
what
I'm
saying
and
the
considerations
you
need
to
put
in
the
design.
The
intent
is
that
you
wouldn't
copy.