►
From YouTube: IETF111-TEEP-20210729-2330
Description
TEEP meeting session at IETF111
2021/07/29 2330
https://datatracker.ietf.org/meeting/111/proceedings/
A
Well,
I'm
I
have
to
turn
my
video
off
because
my
internet
is
being
a
little
challenging
today,
so
I
apologize
for
that.
That
said,
let's
go
ahead
and
get
started.
Welcome
to
the
first
teep
session
that
we're
meeting
in.
So
if
you're
expecting
some
other
topic,
you
may
be
in
the
wrong
session,
but
we
will
be
discussing
our
progress
for
the
trusted
execution,
environment
and
provisioning,
hopefully
by
now
you
are
all
familiar
with
the
note.
A
Well,
so,
in
the
interest
of
time
I
will
just
move
on
with
respect
to
the
meeting
tips
again,
I
think,
given
that
it's
late
in
the
day
for
most
of
you
on
thursday,
not
the
first
day,
I'm
presuming
you're
familiar
with
the
etiquette
and
some
of
the
tips
for
using
the
meat
echo
let's
get
to
the
agenda
bash.
So
thank
you,
hannes
and
mike
for
being
the
note
takers.
A
C
A
A
C
A
C
All
right,
so
first
up
is
architecture.
Let
me
turn
on
my
camera
here,
all
right,
so
architecture
document
next
slide.
Please
all
right.
So
just
as
a
reminder,
this
has
already
gone
through
working,
less
work,
working
group
last
call
and
previous
iets.
We
already
addressed
all
of
the
issues
from
a
working
group
last
call
and
then,
since
last
iatf
we've
had
four
simple
editorial
issues
that
got
raised,
and
so
I
will
talk
about
those
briefly
and
then
terror
did
a
doc
shepard
review
and
submitted
iesg.
C
C
So
the
next
one
was
the
change
shown
there
changing
from
red
to
green,
and
you
can
see
that
the
green
stuff
has
symmetry
between
the
top
two
lines.
You
can
see
authenticating
the
type
agent
from
the
tam
on
the
far
right
of
the
first
line,
and
the
second
line
is
authenticating
the
tam
from
the
teap
agent
right,
so
changing
that
provides
the
symmetry.
C
C
C
That's
the
one:
that's
actually
the
largest
number
of
changes
is
that
slide
right
there.
So,
but
we
don't
think,
there's
anything,
that's
not
simple
editorial!
That's
in
there
when
the
and
then
the
editors
reviewed
it.
So
it
looks
good
so
next-
and
this
is
the
last
one
that's
already
in
there
is
previously
the
document
used
the
term
significant
chain,
and
if
you
look
in
the
security
terminology,
rfc
4949,
it
says
you
shouldn't
use
the
terms
certificate
chain
anymore.
C
You
should
use
certificate
path
instead,
so
great,
we
just
did
the
search
and
replace
and
not
uses
the
term
certificate
path
instead,
every
place
so
just
simple
search
and
replace.
So
that's
it.
That's
the
set
of
changes
that
were
done
since
last
time
and
again,
these
four
changes
are
in
the
copy
that
was
submitted
to
the
iesg
next
slide.
C
Okay,
this
is
the
only
one
that
is
not
in
there
and
so
hanus
filed
this
one
and
so
I'll.
Let
you
speak
to
it
if
you
want,
but
the
issue
had
to
do
with,
should
we
define
the
term
software
update
in
the
terminology
section,
so
there
is
a
pull
request
that
does
this
and
so
on.
The
other
editors
have
decided
to
not
merge
this,
and
so
that's
the
proposed
resolution.
C
We
just
want
to
confirm
working
group
consensus
before
we
close
the
issue,
which
is
the
only
time
that
software
update
is
a
term
appears
anywhere
in
the
document.
It's
an
introduction
and
there's
the
quoted
part
in
the
introduction.
The
terminology
is
way
after
that.
Okay,
and
so
when
ming-
and
I
looked
at
this-
we
said:
okay,
the
term
software
update
and
bold
bear
is
clear
enough
in
context.
C
You
don't
need
to
find
to
define
it,
especially
defining
it
in
a
later
section,
doesn't
really
help
anything,
and
so
that
was
our
rationale
for
not
merging
this
per
request.
Just
the
only
one,
that's
sitting
there
is
open
and
ming,
and
I
would
propose
we
close
this
one
as
no
change
but
we're
willing
to
listen.
If
anybody
in
the
working
group
has
different
opinions,
so.
D
Text
based
on
the
discussion,
I
think
it
was
daniel
who
raised
some
of
the
questions.
That's
why
I
made
the
change
yeah.
It's
it's
borderline,
it's
not
really
necessary,
but
but
I
wanted
to
take
daniel's
comments
on
board.
So
of
course,
ultimately
it's
the
decision
of
the
group,
so
I
I
I
don't
care.
C
C
C
Okay-
and
I
only
have
one
slide
on
the
next
document,
which
is
a
transport
document-
oh
wait-
till
nancy
puts
that
one
up,
as
the
transport
document
was
also
submitted
to
the
iesg
on
monday.
I
think
this
one
also
went
through
working
group.
Last
call
then
went
through
additional
reviews
after
that,
and
the
only
changes
since
ietf
110,
okay,
which
is
when
things
are
already
ready
to
go
to
the
isg,
but
we
were
waiting
to
see
if
there
was
going
to
be
any
changes
based
on
implementation
experience.
C
There
has
not
been
a
review
caught
that
the
document
incorrectly
said
intended
said
it's
informational,
which
was
never
the
intent,
so
we
fixed
that
and
then
the
other
one
was
a
clarity
that
the
title
of
the
document
arguably
did
not
match
the
abstract
or
the
introduction
both
of
the
abstracts
and
introduction
are
clear
that
this
document
is
about
when
agents
initiate
communication
to
a
tam.
In
other
words,
the
hp
client
is
on
the
agent
side,
whereas
the
old
title
could
have
been
interpreted
as
being.
C
This
only
talks
about
messages
that
go
between
the
agent
and
the
tam,
regardless
of
who
initiated
them,
and
that's
certainly
the
wrong
interpretation
right.
So
we
just
updated
the
title
to
match
the
abstract
and
the
introduction
so
other
than
that
no
changes
to
the
document
and
it
was
submitted
so
now.
Of
course,
this
is
submitted,
but
it
has
internally
a
normative
reference
to
the
t
protocol,
which
is
not
so
eventually.
This
will
be
blocked
on
a
normative
dependency
until
t
protocol
is
submitted,
but
this
was
submitted
to
isgrtc.
C
C
A
G
G
Before
that,
we
only
had
deep
t
protocol
format
in
the
deep
message
and
we
we
just
wanted
to
proceed,
making
implementation
improvement
and
started
at
suit
manifest,
and
so
these
are
the
thing
we
did
did
it
for
the
hackathon
matching
terminology
between
keep
in
suit
draft
and
what
we
want
to
do
in
tip
use
cases
for
the
suit
manifest,
and
we
came
up
with
a
three
candidate
of
the
suit
manifest
and
then
from
the
candidate.
We
tried
to
create
the
format
of
the
suit
at
the
suit
manifest.
G
G
The
initial
suit
manifest
and
the
suit
manifest
and
including
trusted
application
or
firmware,
will
be
hosted
to
the
server
and
where
to
host
it
is
depend
on
the
use
cases,
but
in
not
in
this
use
cases
we
thought
is
uploaded
to
firmware
it.
Equal
is
tc
and
teep
is
at
the
app
store,
not
apps,
I'm
sorry
in
tam
and
untrusted
client
to
the
app
store
and
in
the
in
both
in
in
the
suit
terminologies
firmware
server.
G
G
G
G
But
if
it's,
if
the
device
started
to
parse
from
the
left
side
of
the
manifest
first
and
then,
then
it
will
finish
parsing
or
manifest,
but
it
will
it
won't.
It
won't
catch.
The
ur
is
specified
in
different
benefits
from
the
time.
So
it
will.
It
won't
be
it's
it's
it's
not
that
easy
for
the
implementing
device.
So
we
didn't
use
this,
and
this
is
the
number
two
is
the
one
we
used.
G
We
decided
to
use
is
having
integrated
dependency,
which
means
having
having
a
original
manifest
from
the
tc
developer
inside
that
manifest
develop
a
generated
time
emitted,
so
the
left,
then
this
will
have
only
one
manifest.
However,
it
will
be
original
manifests
from
the
dc
developer
will
be
encapsulated
inside
the
manifest
from
the
time.
G
G
And
then
this
is
the
requirements
for
making
the
format
from
this
for
the
number
two
design
so
suit,
manifest
generate
by
tc
developer.
This
is
the
initial
manifest
generated
generated
and
it
has
a
install
command
sequence
and
then
the
suit
manifest
will
be
encapsulating
the
first
manifest
and
and
with
the
different.
G
H
H
I
I
just
I'd
like
to
know
how
you
get
away
from
having
multiple
signatures,
and
secondly,
if
they're
using
different
metadata,
how
would
you
get
away
from
them
not
separately
authenticating
that
metadata
those
if
they're,
you
know
different
trust
domains
need
different
signatures
and
you
have
to
trust
the
origin
of
the
metadata.
So
I'm
just
curious
if
there's
a
way
that
you
have
to
get
around
that.
G
Not
at
the
moment
it's
my
answer,
but
yes,
so
yeah,
we
we
talk
about
the.
If
we
have
to
initially,
we
wasn't
sure
if
one
tc
or
firmware
should
have
two
different
manifests
and
from
the
comment
that
during
the
hackathon
from
from
brandon,
yes,
we
it
will,
it
might
be
not
the
best
way
to
have
two
separate
manifests
for
one
tc
or
one
firmware.
Oh.
G
H
Yes,
so
so
my
question
was:
it
was
a
clarifying
question
to
start
with.
You
said
that
there
was,
it
was
not
ideal
to
have
more
than
one
manifest,
and
so
my
question
was:
is
there
a
better
way
to
do
it,
given
that
you
have
two
different
trust
domains
and
you
have
to
separately
authenticate
two
different
pieces
of
metadata
from
those
two
different
trust
domains?
So
if
there
is
a
way
to
do
that
without
two
manifests,
I'd
love
to
hear
about
it.
G
G
G
The
than
the
initial
I
mean
initial,
manifest
from
tc,
so
initially
manifest
from
dc,
had
http,
slash,
example.com,
hello.txt
and
and
the
manage
and
from
the
manifest
from
the
timelines
have
a
url.
I
have
http.example.comhello.txt
and
and
the
way
we
just
in
this
for
the
draft
we
format
we
made
this
manifest
dc
com.
First
is
when
the
parsing
in
the
device
side,
when
the
manifest,
when
the
device
is
parsing
the
manifest
time
they
they
already
knew
they
have.
They
have.
G
D
I
have
a
q.
I
have
a
note
which
I'm
adding
to
the
meeting
minutes
is,
I
think
so.
I
was
obviously
in
the
discussion.
So
it's
a
little
bit
easier
for
me
to
understand,
but
for
some
of
you
who
may
not
have
been
involved
in
those
discussions,
the
starting
point
of
why
they
are
too
manifest
is
because
they
also
creates
the
original
version
and
then
later
on.
G
G
Okay:
okay,
there's
a
one
minute,
more
okay,
it's
a
summary!
So
we
mapped
the
terminology
during
this
hackathon
deep
in
draft,
which
is
was
which,
which
will
be
good
slide
for
the
implementing
in
the
future
and
and
came
up
with
three
different
format:
three
design
for
the
writing
suit
manifest,
and
we
we
decided
to
use
one
of
them
and
and
try
to
come
up
with
the
format
of
the
what
the
the
design
we
chose.
G
C
Thank
you
thanks
akira
for
walking
us
through
that
and
the
last
point
about
still
working
on
suit,
manifest
that's
brennan's
presentation
tomorrow
we
were
talking
about
so
we'll
come
back
to
this
manifesto.
After
so
I'm
going
to
talk
about
the
changes
in
the
t
protocol
and
then
walk
through
a
number
of
the
issues
that
were
filed
during
the
hackathon
last
week.
So
next
slide,
please.
C
So
next
slide,
let's
start
going
through
these,
so
the
first
ones
my
hope
is.
They
should
be
more
easy
than
the
open
questions,
so
the
first
one
in
previous
ietf.
I
think
it
was
last
ietf,
not
the
one
before
we
talked
about
dependency
resolution
being
done
by
the
deep
agent
in
at
least
in
some
cases,
and
so
this
is
just
a
note
that
the
sending
of
the
update
message
and
the
response
to
it,
which
is
a
success
or
an
error.
C
There
might
be
a
significant
time
delay
between
those
depending
on
how
long
the
update
process
actually
takes,
and
so
just
a
note
for,
say
those
doing
a
tim
implementation
that,
if
you're
using
nonces
right,
you
don't
have
to
use
nonsenses.
But
if
you're
using
a
non-spaced
freshness
mechanism,
you
might
have
to
store
that
nonce
for
some
period
of
time
until
you
could
actually
get
that.
Given
it's
not
going
to
be,
you
know,
immediate
necessarily
in
all
cases,
this
is
just
it's
important
to
note
that
it
might
be
delayed.
C
I
C
C
Go
ahead,
yep,
so
the
next
one
was.
We
did
talk
about
this
last
ietf,
where
we
talk
about
what
happens
when
you
parse
a
query
request,
and
it
doesn't
all
the
fields
aren't
quite
what
you
expect.
Can
you
send
an
error
message
and
we
all
agreed
that?
Yes,
we
should.
That
was
the
resolution
from
the
minutes
from
last
time
and
the
cur
the
previous
state
of
the
spec
was
that
it
was
a
contradictory
that
section
3
already
explicitly
allowed
that
case
and
section
6.1
and
6.2
were
the
parts
that
didn't
so.
C
In
other
words,
we
had
both
answers
before
they
contradict
each
other.
So,
based
on
the
past
resolution
that
says
yes,
you
can
send
an
error
in
response
to
any
query
request.
We
did
not
touch
section
3,
but
we
touched
section
6.1
and
6.2
to
clarify
that
it
was
now
allowed.
So
as
an
example,
the
part
in
bold
there
was
text
that
was
added
before
the
latest
draft.
C
The
part
in
bold
was
absent
that
you
stand
with
a
period
there
right
so
now,
courier
response,
if
all
were
understood
or
an
error,
if
any
was
encountered
so
that
sentence
then
a
similar
one
in
the
other
section.
So
we
think
we
got
that
that
one
was
pretty
easy
to
address
based
on
the
discussion
last
time.
So
unless
there's
any
questions,
let's
go
on
to
the
next
one
okay.
So
we
had
an
open
question
last
time
that
we
had
a
tentative
resolution,
a
court
of
the
minutes,
which
was
russ
had
asked.
C
Should
we
allow
or
disallow
future
cipher
suites
without
confidentiality?
In
other
words,
if
it's
going
to
be
say,
expert
review,
what
would
we
tell
the
expert
to
to
expect
here
and
so
last
time,
the
minutes?
Basically,
we
concluded
from
the
meeting
that,
if
you
do
it,
it
better
come
with
appropriate
use
case.
You
know
security
considerations
and
applicability,
but
maybe
we
don't
want
to
rule
it
out.
At
least
we
didn't
have
consensus
to
rule
it
out.
C
C
Protection
can
only
be
added
if
the
associated
specification
includes
a
discussion
of
security
considerations
and
applicability,
because
manifest
may
carry
a
sense
of
information,
and
then
we
have
an
example
of
a
case
where
you
know
to
make
it
clear
that
there
might
be
some
case
where
you
want
to
allow
it
because
you're
handling
it
differently,
you're,
not
passing
anything
or
whatever.
That's
just
up
to
the
specification
to
to
have
so.
The
main
change
is
the
main
answer
to
the
question
is
the
part
in
bold.
There.
C
Okay,
seeing
nobody
in
queue,
let's
go
on
to
the
next
slide,
I'm
not
watching
chat,
I'm
just
watching
the
queue,
and
I
see
russ
said
thanks.
I
just
checked
chat.
Okay,
all
right
next,
one
was
about
challenge
versus
token
in
the
query
request,
and
so
last
iatf
was
had
this
discussion
about
well.
Both
of
these
are
kind
of
providing
values
that
get
echoed
back
from
the
tp
from
the
device
in
different
messages.
C
That
has
neither
a
token
nor
a
challenge
and
of
course
this
would
be
the
case
if
the
attestation
bit
is
set
and
you're
using
some
mechanism.
That's
not
a
nonce
right,
so
you're
using
like
time
stamps
or
epic
ids,
or
something
and
there's
no
other
reason
that
the
challenge
is
needed
right.
This
just
illustrates
the
challenge
field.
C
There
is
not
just
for
carrying
a
nonce
to
be
put
into
say:
you
know
attestation
or
something
you
could
put
other
information
into
the
challenge
that
needs
to
be
used
to
generate
the
actual
evidence
right
if
you're
generating
evidence,
that's
meant
for
a
specific
entity
as
opposed
to
arbitrary
entities.
You
might
use
the
challenge
to
do
that.
C
Okay
and
so
it's
legal
to
have
neither
if
you
have
no
reason
to
have
a
challenge
and
you're
doing
attestation,
and
so
this
would
not
be
the
case
if
you're
using
nonces
but
might
be
the
case
if
you're
using
time
stamps
or
epic
ids
okay,
and
so
that's
just
a
long
explanation
as
to
why
the
text
that's
quoted
there
in
the
first
two
bullets
is
worded
the
way
it
is
okay
and
again,
my
belief
is
this-
reflects
working
group
consensus
from
last
meeting.
So
all
right
next
slide.
C
Okay,
to
say:
well,
that's
really
up
to
the
whatever
your
attestation
protocol
is
doing,
and
we
don't
want
to
force
you
to
use
a
particular
one
was
kind
of
how
it
was
phrased
last
time,
and
so
this
was
the
intent
and
so
the
this
one.
If
I
got
something
wrong,
it'd
be
somewhere
in
this
one
here
it
says
the
intent
is
to
add
a
freshness
mechanism
negotiation.
At
least
that
was
my
interpretation,
the
consensus,
and
so
what
I
did
here
is.
I
took
the
existing
negotiation
mechanism.
C
That's
used
for
cipher
suites,
okay,
where
that
is
basically
that
the
tam
can
put
a
list
of
supported
ones
in
the
query
request
and
the
device
can
then
choose
among
those
and
if
it
doesn't
support
any
of
those
and
it
can
send
an
error
with
the
ones
that
the
device
supports
right.
That's
what
we
do
for
cypher,
suites
right
now,
and
so
the
here
for
freshness
mechanisms.
C
We
tried
to
use
that
as
a
precedent
and
do
it
the
same
way,
and
so
we
already
had
an
iona
registry
section
for
a
creation
of
cypher
suites,
and
so
I
added
an
equivalent.
I
enter
registry
for
a
freshness
mechanisms,
and
here
there's
only
three
and
there
might
only
ever
be
three
but
just
in
case
there's
a
three
that's
here
and
being
nonces
time
stamps
and
ep
ids
and
the
the
table
isn't
in
there.
C
So
let's
say
you
have
a
device
that
was
a
constrained
device
and
it
only
implemented.
You
know
epic
ids
or
something
like
that
right.
So
the
query
request
comes
in
from
the
tam,
it
says
knots
and
it
says
no,
I
don't
I
can't
support
nods.
Can
you
give
me
epic
ids
and
the
tam
can
choose
to
log
that,
or
I
could
choose
to.
You,
know,
fill
over
and
say:
okay,
epic,
ids
or
whatever
else
it
wants
to
do
implementation
detail?
Okay,
the
main
point
is
you
can
at
least
log
it?
Okay.
C
C
What
it
currently
says
is
if
the
error
message
does
not
mention
what
supported
mecha
freshest
mechanisms
the
device
has,
and
that
also
means
that
it's
only
the
knots
okay,
there
is
a
problem
with
that
statement
that
I'll
come
back
to.
But
that's
what's
in
the
document.
Right
now
is
what
I've
just
I've
just
presented.
So
all
right,
let's
go
on
to
the
next
slide,
then
because
I
don't
see
anybody
in
queue,
and
so
that
covers
the
things
that
are
already
addressed
in
the
current
draft.
C
Now
we're
going
to
move
into
the
new
issues
filed-
and
I
think
all
of
these
are
ones
that
were
raised
during
the
hackathon
itself.
Okay,
so
that's
the
list
that
we're
going
to
walk
through
one
by
one,
I've
sorted
these,
so
I
can
talk
about
what
I
just
said.
I
was
going
to
come
back
to
first,
so
next.
C
See
hackathon
was
productive.
We
found
a
bunch
of
implementation
issues
all
right,
so
here's
the
issue
with
a
sentence
that
I
referred
to.
Okay,
so
you
send
off
a
query
request
and
you
get
back
an
error
and
the
error
has
nothing
about
freshness
mechanisms
in
it.
Okay,
and
so
what
do
you
conclude?
Okay,
that's.
The
second
bullet
on
here,
which
is
does
absent,
mean
that
it
only
supports
known
so
does
absent,
mean
that
well,
you
may
not
have
it
may
not
have
hit
a
freshness
mechanism
problem.
Okay.
C
The
issue
is
that
if
you
fail
due
to
there's
no
mechanism
in
common
what
error
code
you
include,
there
is
no
error
code.
We
had
an
error
code,
for
you
know
no
cipher,
sweet
and
common,
but
when
we
added
the
issue
142,
we
forgot
to
add
an
error
code
for
this.
So
I
said
we
tried
to
use
the
cipher
suite
stuff
as
a
precedent,
but
we
messed
it
up
because
we
didn't
put
in
an
equivalent
error
code
to
make
it
match,
and
so
that's
what
issue
143
is
is
oops.
We
forgot
the
error
code.
C
The
proposed
resolution
is
same
thing
for
cypher
suites.
We
add
an
error
code
that
says
unsupported
freshness
mechanisms
and
change.
The
statement
to
say
the
supported,
freshest
mechanisms
field
in
the
error
must
be
returned.
If
you
set
the
error
code
to
freshness
mechanisms
and
that's
the
type
of
statement
we
use
in
the
cipher
suite
negotiation
today.
So
this
was
an
intent
that
was
discovered
when
trying
to
implement
that
new
stuff
that
says
oops.
We
can't
implement
it.
C
A
D
D
I
C
Okay,
so
going
on
to
issue
144
use
of
the
challenge
when
the
freshness
mechanism
is
not
announced,
this
one
is
a
simple
editorial
oversight
that
was
discovered
during
implementation.
What
the
text
says
right
now
is
that
if
you
have
a
challenge
in
your
career
response,
then
you
must
copy
it
into
the
nonce
claim
found
in
the
eat.
C
Well,
of
course,
if
you've
just
negotiated
the
fact
that
you're
using
timestamps
or
or
epic
ids,
then
of
course
this
sentence
is
wrong,
and
so
the
proposed
resolution
is
to
just
update
the
text
to
match
the
stuff
we
already
covered,
which
is
as
phrased.
That
only
applies
if
you've
negotiated
nonces
right.
C
If
you've
negotiated
something
else,
then
you
might
use
the
challenge
for
whatever
the
attestation
protocol
uses
it
for
it's
not
for
nonsense,
but
it
might
be,
to
you
know,
identify
the
intended
destination
to
encrypt
with
or
whatever
it
is
that
the
that
the
attestation
mechanism
uses.
So
you
have
to
fix
that
text.
C
C
What's
gone
during
the
hackathon
when
trying
to
implement
that
sentence,
so
all
right
next
slide.
Unless
I
see
somebody
get
in
the
queue
all
right,
handling
of
the
suit
commands
bit
and
data
item
requested.
So
as
a
reminder,
the
query
request
can
come
with
this
set
of
bits
that
says:
here's
the
information
I
would
like
in
your
query
response.
Okay,
one
of
those
bits
is
the
suit
commands
bit
and
the
description
says:
the
tam
queries
the
teap
agent
for
supported
commands
offered
by
the
suit
manifest
implementation.
C
That
is
the
only
mention
of
suit
commands
in
the
entire
document.
There's
no
way
to
actually
report
that
information
in
the
query
response:
okay,
there's
a
way
to
request
it,
but
there's
no
way
to
implement
that
bit
to
do
anything
with
it.
Okay,
brendan
is
in
queue,
so
I
will
let
you
speak
up.
Go
ahead.
H
H
So
then,
there's
also
going
to
be
an
open
question
of
whether
for
some
devices
you
want
the
ability
to
report
which
component
identifiers
are
supported.
That's
that's
something
that
might
be,
yes
might
be,
no,
and
it
it's
gonna
depend
on
the
application
quite
a
lot.
I
think
that
there's
probably
a
need
for
a
document
that
explains
this
and
that's
probably
something
suit
should
do,
but
at
the
same
time
it's
going
to
be
pretty
trivial.
H
I
mean
the
cddl,
for
it
is
going
to
be
a
list
of
three
lists
of
integers
or
something
to
that
effect.
So
this
is
something
that
we
can
do.
We
can
do
it
pretty
quickly.
We
can
do
it
pretty
easily,
but
I
think
honestly,
that
that's
how
this
should
be
handled.
It
should
really
should
be
something
related
to
generic
capability.
Discovery
ensued.
C
C
Okay
now,
the
only
thing
I
could
imagine
you'd
use
it
for
is
if
somehow
the
tam
had
multiple
versions
of
the
suit
manifest
for
the
same
component,
and
it
would
use
it
to
decide
which
version
the
manifest
to
send
you.
I've
got
two
different
blobs
that
are
meant
for
two
different
things
right,
but
I
could
do
that
by
paying
attention
to
the
attestation
information
that
says:
okay,
well,
you're
out
of
compliance,
here's
the
different
types
of
binaries
that
you
need.
I
need
to
pass
down
the
trusted
component.
C
That's
the
correct
suit
parser
for
you
right,
because
you
don't
have
the
correct
one
for
me,
and
this
has
a
dependency
on
you
having
the
correct
suit
parser
as
an
implementation
in
your
tee,
and
so
I
can
do
that
with
the
tam
by
paying
attention
to
what
you
have
installed
with
what
versions.
So
I
don't
need
the
suit
commands
bit
to
do
that.
C
Yes,
exactly
and
I'm
saying
once
you
do,
that
you
no
longer
need
a
bit
in
the
data
item
requested
to
request
it
right
because
you're
handling
it
with
a
different
mechanism,
you're
doing
it
by
a
negotiation
based
on
what
suit
manifest
component
version
and
component
id.
Do
you
have
installed
not
based
on
your
reporting?
What's
the
set
of
suit
commands,
it
supports.
H
C
F
C
Yeah,
so
that's
why
I'm
gonna
argue
that
we
remove
the
bit
if
we
ever
have
a
case
that
something
breaks
that
you
can't
do
it.
We
can
always
add
it
in
a
future
extension.
Okay.
That
would
be
option
number
one
as
a
workaround
in
the
meantime,
if
somebody
runs
into
it
and
needs
it,
then
of
course,
when
a
failure
happens,
they're
gonna
get
suit
reports,
saying
unsupported
command
or
whatever,
and
so
you
can
always
get
out
of
the
suit
reports
in
the
meantime.
C
C
C
A
C
C
C
C
C
C
That's
it.
Okay,
doesn't
say
anything
about
else
about
ocsp
capability
discovery
anywhere
else
in
the
document.
Nothing
says
how
to
report
that,
in
the
query
response,
there's
not
even
any
bit
in
the
data
item
requested
to
query
for
it.
Unlike
the
other
ones,
there's
just
a
statement
that
says
you
can
do
it
and
then
there's
no
way
to
actually
query
it.
Let
alone
report
it
so
again
same
question
here.
Should
we
remove
the
sentence
or
do
we
need
to
specify
a
negotiation
mechanism?
C
E
Yeah,
hey
doesn't
mean,
I
I
think
we
all
along.
We
do
want
to
support
ossp
somewhere
right,
or
we
just
say
request,
because
because
the
device
has
no
way
we
don't
want
device
to
correct
whether
so
I
can
trust
right
then,
when
you
get
over,
it
should
have
capability
to
do
ocsb
check,
if
not,
there's
some
way
need
to
tell
right.
So
I
think
we
should
have
wait
to
do
this.
I
know
there's
a
limitation
for
the
moment,
but
as
a
protocol
functionality,
I
think
we
should
support
versus
pr,
if
not
need
to
tell.
B
C
A
E
So
yeah,
yes,
I
said
I
just
said
right.
I
said
that
as
a
mandatory.
Obviously
I
would
agree
with
that
one
it
couldn't
make
it
mandatory,
because
you
know
this
is
behind
your
arm
for
long
right.
Well,
it
could
be
really
wise
for
a
divide
to
support
unless
a
legacy
device.
I
think
it
may
not
be
really
such
a
strong
requirement
explore
that
option
straight
because
really
signature
check
stuff.
J
I
was
going
to
advocate
an
approach
similar
to
what
tls
is
doing
with
stapling.
Just
make
sure
it's
included
in
the
message
as
it
goes
across,
and
you
could
do
something
similar
to
cms,
which
allows
either
ocsp
or
crl,
but
there's
many
environments.
You
do
not
want
the
whole
crl
be
shuffed
across
there.