►
From YouTube: IETF115-RATS-20221107-1530
Description
RATS meeting session at IETF115
2022/11/07 1530
https://datatracker.ietf.org/meeting/115/proceedings/
A
B
A
A
A
B
B
Well,
that
quieted
the
room
so
I
will
take
that
as
a
sign
that
we
can
go
ahead
and
get
started,
at
least
with
some
of
the
logistics
so
good
afternoon,
good
morning
and
good
evening
to
all
of
those
who
are
here
present
and
participating
remotely,
you
are
in
the
remote
attestations
and
procedures
working
group.
So
if
you
join
remotely
or
in
this
room
and
are
not
expecting
to
talk
about
rats,
you
may
be
in
the
wrong
place.
B
B
B
Yeah
he's
just
referencing
his
the
the
first
deck
so
anyway.
These
are
all
of
the
links
that
you
can
reach
out
to
for
for
the
proceedings
for
this
session
next
slide.
B
Okay,
so
reminder
to
reiterate:
we
do
have
ietf
procedures,
we
also
have
a
code
of
conduct,
so
please
keep
the
conversations,
professional
and
so
again
I'll.
Let
you
read
through
this,
but
just
be
courteous
when
you
open
up
for
discussion,
whether
on
the
chat
in
the
mail
or
here
in
person
next
slide,
please.
B
Okay,
so
we
are
now
in
the
agenda
bashing.
So
please
look
over
the
agenda
and
I
am
now
going
to
speak
as
an
individual
contributor,
because
I
am
an
author
of
The
unencrypted
CCS
draft
and
we
did
an
update
that
Karsten
I
think
you're
going
to
report
on.
B
A
I
at
least
have
no
chat,
Echo
interface
I
will
take
backup
notes,
but
not
having
chat
means.
It's
probably.
B
I
think
yeah
I
mean
I
I,
put
a
hello
there
and
I
saw
it.
But
thanks
for
noting
that
and
given
that
we
don't
have
chat.
A
B
Okay,
is
somebody
willing
to
be
job
or
scribe.
B
D
Yeah
I
sent
some
slides
in
very
very
late.
It's
just
a
update
on
what's
going
on
with
suit
reports,
which
is
sort
of
tangentially
related
to
rats.
So
I
thought
I'd
bring
an
update
if
that's
helpful.
How.
B
Brendan
we
can
just
have
Brendan
project
the
slides,
okay.
E
D
G
B
And
he's
he's
not
commenting
okay,
so
let's
go
ahead
and
move
it
to
Lawrence
on
the
eat,
update.
H
Hello,
so
draft
17
was
published
just
at
the
cutoff
date.
Draft
17.
really
has
no
open
issues
or
the
eat.
Authors
do
not
believe
any
further
changes
are
needed
as
a
draft
17..
So
a
few
comments
on
that.
So
next
slide.
Please.
H
Next
slide,
so
the
this.
This
is
a
I'm
going
to
take
a
few
minutes
and
discuss
the
the
the
major
changes
in
draft
17,
just
in
case
to
point
them
out.
So
one
of
them
is
that
the
nonce
was
made
optional
and
that's
so
you
can
use
time
based.
There
were
some
general
improvements
around
yeah,
so
we
lost
the
slides
here.
Some
general
improvements
around
freshness
in
the
nonsense.
I
E
B
H
So
back
back
one
slide,
please
so
the
the
other
thing
that
was
a
change.
This
is
these
are
the
semantic
changes
you
know
that
would
affect
actually
actually
affect
the
code.
You
write
as
an
implementation,
so
another
change
was
the
the
input
to
the
digests
for
a
sub
module
detached
Digest.
H
So
the
there
was
a
more
more
clear
specification
on
that.
We
also
changed
the
way
that
sub
module
digests
are
identified,
I
mean
this
has
got
to
do
with
the
how
things
are
in
seabor
and
Json,
and
the
fact
that
Json
doesn't
have
tags.
So
that's
another.
The
implementation
is
a
lot
cleaner.
Now
there
was
some
overloading
before
and
then
the
security
level
claim
was
removed.
So
these
are
the
major
implementation
changes
next
slide.
H
Then
there
were
lots
of
wording,
changes
just
clarifications.
We
describe
eat
as
a
framework
right
up
front.
You
know
that
that
uses
profiles.
It's
kind
of
you
know
that
came
a
lot
a
lot
from
the
comments
from
Elliott.
We
need
to
redirect
to
the
right
security
model
right
away,
so
we're
not
trying
to
describe
the
security
model
in
eat.
H
The
sub
module
section
was
Rewritten
for
clarity
and
brevity
there
was
a
couple
sections
removed
that
were,
you
know
not
necessarily
essential
like
describing
how
you
how
to
include
public
public
keys
and
claims
mentioned
of
the
CTI
and
jti
claims.
It
was
just
advice
that
was
removed,
there's
a
clarification
that
submods
can
be
used
for
both
evidence
and
results,
and
then
we
added
non-normative
reference
to
UCCS.
H
So
we,
you
know
we
had
UCCS
in
there
as
a
kind
of
a
normative
reference
that
it
was
gone
and
now
it's
back
as
non-mormative,
that's
and
then
next
slide,
which
is
security,
considerations
and
privacy
considerations
were
updated.
So
there's
a
section
on
freshness
and
security
considerations,
there's
a
section
on
claim
trustworthiness
and
then
there's
also
some
discussion
about
CTI
and
GTI
that
was
removed.
H
So
the
eat
authors
believe
no
changes
are
needed
to
resolve
any
of
the
issues.
The
following
issues.
H
You
know,
that's
not
to
say
there
will
never
be
another
change
to
eat,
of
course,
but
so
next
slide
and
I
believe
we're
now
into
the
lots
of
slides,
individual
slides
one
per
issue.
H
H
H
So
we
hopefully
can
close
it
out
here,
at
least
in
the
room,
and
then
you
know
I,
guess
we
wait
a
little
bit
for
comments
on
the
list.
So
it's
also
there.
But
these
these
also.
This
basically
parallels
the
email
I
sent
about
a
week
ago
with
a
big
list
of
issues.
So,
okay,
so
Issue,
Number,
Eight
Elliot
in
his
review,
was
concerned
about
the
software
name
field
being
freeform.
H
It
doesn't
it's
just
a
text
field
where
you
put
whatever
you
want
in
we
after
Elliot's
comment,
we
improved
the
wording
in
draft
14
to
make
it
clear
that
this
is
definitely
a
free
form
field
and
don't
expect
it
to
be
structured
or
any
kind
of
rigorous
definition,
and
if
you
want
a
rigorous
definition
for
software
that
you
can
really
strong
identifiers
or
Clara
identifiers
use,
spdx,
Cyclone,
DX
or
ghost
with
their
art
lots
of
other
options
there.
H
So
this
is
probably
more
of
a
human
human,
readable
software
name
so
that
this
has
been
around.
There's
been
no
feedback
on
this
one
way
or
the
other.
So
no
objections,
no
comments,
no
nothing
back
from
Elia.
So
so,
let's
stop
for
comments
on
on
that.
H
I,
don't
remember
what
the
comment
was
on
number
nine,
but
it
was
about
security
level
and
security
level
has
been
removed.
So
I
think
that
settles
that.
E
K
H
So
in
the
in
this
one
Elliott
had
requested
improved
wording
on
the
dloa's
claim.
Just
clarifications:
I,
don't
think
it
was
anything
of
substance
so
that
that
wording
was
improved
in
draft
14,
which
was
published
in
July
and
so
no
comments
since
so
I'm.
B
E
H
Thanks,
so
we
consider
this
nothing,
no
further
action
needed
here,
so
comments.
H
H
So
and
then
back
around
I
think
Elliott
requested
the
edition
of
claims
that
these
are
actually
manifest.
Software
manifest
claims
for
spdx
and
Cyclone
DX.
Those
claims
were
added
in
draft
14.
Those
also
include
I
think
it's
Co-op
and
my
content
types
for
those
two.
So
the
E
document
registers
content
types
for
those
in
order
to
be
able
to
reference
them
in
manifests
so
no
comments
since
July
on
that.
So.
H
H
So
I'm
gonna
keep
talking
so
that
was
section
section.
9.2
was
a
bunch
of
information.
We
collected
very
early
on
I.
Remember
discussions
in
Montreal
about
what
characteristics
claims
should
have.
Should
we
reuse
old
formats
or
or
what
and
it
was.
It
was
a
good
discussion
so
that
was
captured
and,
and
that
text
was
all
put
in
section
9.2
in
the
Ina
section.
H
But
it's
not
really
expert
review
and
it's
not
setting
any
criteria.
It's
just
kind
of
advice
to
people
creating
claims,
so
the
I
believe
Elliott,
and
somebody
else
said
that
you
know
Ayanna
would
not
know
what
to
do
with
this.
I
think
Diana
looked
at
it
and
said
we
don't
know
what
to
do
with
this.
So
just
moved
all
of
that
text
to
an
appendix
that's,
not
normative.
That
was
done
in
draft
14..
H
H
Okay,
next.
H
You
should
be
back
so
Elliot
had
a
section
in
his
comments
that
he
titled
minor
issues
and
knits.
H
Most
of
them
were
directed
against
against
the
introduction
he
considered
the
minor,
but
we
did
do
major
work
on
the
introduction
in
drafts.
14,
15
and
17..
H
So
I
think
the
introduction
is
much
cleaner
now
and
you
know
orients
the
readers
more
now
that
this
is
a
framework
and
that
it's
we're
not
defining
the
security
model
here
that
the
security
model
is
elsewhere
and
you
know
expect
to
understand
profiles
and
and
that
profiles,
our
core
part
of
the
work
here
so
I
think
that
should
more
than
address
Elliot's
comment
comments.
H
So
spreadsheet
Issue
Number
14
to
number
15
we're
both
we're
comment
blocks
one
from
honest
and
one
from
Michael.
The
spreadsheet
didn't
list
them
all
out
individually
and
so,
but
there
were
lots
of
really
helpful
comments.
H
We
most
of
them
were
wording
clarifications
and
and
I
guess,
they've
led
to
some
other
other
changes
like
I,
think
the
public
key
removal
was
in
there
and
the
and
all
that,
all
that
anyway,
there's
dozens
of
changes
were
made
because
of
those
two
comment
blocks
and
the
remaining
issues
from
from
those
are
now
in
GitHub
and
I'll
present
them
later.
H
H
B
H
Okay,
so
this
was
I,
don't
think
this
yeah.
This
was
identified
in
the
spreadsheet.
It
was
a
discussion
topic
about
whether
you
know
message
types
this
had
had
to
do
with
the
fact
that
the
UCCS
was
is
defined
outside
the
document,
so
we
had
to
put
in
a
cddl
socket
so
that
the
the
top
level
message
types
of
cwt
JWT
UCCS,
are
in
in
the
cddl
definition
are
a
socket,
so
you
can
plug
other
message.
H
Types
in
there
was
concern
that
was
to
open
the
resolution
in
the
document
was
that
new
eat
message.
Types
must
be
ietf
standards
and
we
believe
that
closed
the
issue
out
on
the
mailing
list.
L
H
This
was
issue
number
18
in
the
spreadsheet.
This
referenced
some
messages
on
the
mailing
list,
I
think
I,
think
Hank
was
involved
in
the
discussion
on
this.
We
sought
clarification
for
what
the
issue
was
and,
and
there
was
never
never
became
clear
what
what
the
issue
is.
So
at
this
point,
oh,
we
can't
do
anything
until
some.
You
know
there's
some
clarification
of
what
the
issue
actually
is.
H
L
H
All
right,
I
think
next
slide.
Please.
B
H
We
hit
the
end
or
you
tell
me
to
stop
so
yep,
so
this
is
a
a
GitHub
issue.
Basically,
the
the
the
issue
requested
improved
text
for
nonce
and
freshness
so
they're.
There
were
changes,
mated
made
in
draft
14
and
I
believe
in
17.
Also
no
I
think
14..
So
because
freshness
and
nonsense
are
a
topic,
everybody
cares
dearly
about
and
we
really
want
to
make
sure
we
we
get
this
Clean
and
Clear.
H
We
have
been
leaving
the
issue
open
and
asking
for
comments
on
that,
and
if
you
want
to
review
what
it
says
about,
freshness
is
freshness
and
nonce,
just
search
for
freshness
and
knots.
In
the
document,
it's
probably
easier
than
trying
to
look
at
diffs.
Just
look
at
what
the
text
is
there
and
and
make
your
comment.
So
this
is
really
more
of
a
a
request
for
comments
at
this
point.
B
H
F
M
You
are
using
the
word
attestations,
which
is
not
indistinguishable
between
a
message
on
an
action.
Never
do
this
ever
in
the
document,
so
also
I
assume
that
some
of
the
claims
are
actually
endorsements
and
and
then
and
then
calling
them.
All
again,
attestations
is
like
hyperly
confusing
to
me,
so
that
is
was
my
initial
problem
with
it
going
for
a
unified
endorsement
at
a
station
design.
M
So
is
endorsement
an
action
or
a
message
is
attestation
a
message
or
an
activity,
and
what
does
the
design
here
makes
absolutely
no
sense
to
the
reader
for
me
I'm
as
the
reader
here
at
back
at
that
day,
I
have
not
checked.
To
be
honest,
the
current
ID
quality,
if
it
even
is
well
in
colloquial
language
distinguishable.
M
What
attestation
even
means-
and
so
my
assumption
is
that
it
is
often
confused
between
an
action
and
a
message
and
and
and
I
think
that
is
not
helpful.
When
you
talking
about
a
message
format
and
as
we
assume
that
you
always
mean
a
message
but
from
text
sometimes
it
feels
like
a
like
activity
to
me
and
I
can
never
really
tell
and
that
that
is
I.
M
M
Exactly
so,
it
should
be
very
clear
that
an
attestation
only
in
the
scope
of
this
document
means
messages
that
are
originating
from
my
testers
and,
if
they're
originating
from
other
rows
must
be
very
clear
which
role
from
the
Reds
architecture
is
emitting
that
message
and
that
it
has
nothing
to
do
with
an
activity.
M
I
think
that
is
something
very
fundamental
here,
and
that
is
what
was
very
confusing
in
the
email
coming
from
you
Lawrence
on
the
Junes,
the
6th
which
I
was
reacting
to
and
that's
why
that's
why
I
made
this
comment
on
the
role
18,
apparently.
H
Okay,
so
let's
let's
break
some
things
down
here,
to
try
to
clarify
so
endorsement
I
mean
and
and
sticking
to
the
what's
in
the
draft.
So
when
it,
the
the
eight
draft
doesn't
Define
anything
to
do
with
anything
to
do
with
endorsements.
It
mentions
them
a
couple
of
times
yeah
and
only
using
the
definition
that
is
in
rat's
architecture.
Okay,.
H
B
B
H
Copy
of,
what's
in
the
architecture,
draft
right
so
I
think
that's
pretty
clear.
Now
your
thing
about
attestation
as
an
activity
or
something
else
now
you're
talking
in
reference
to
an
email
I
sent,
which
is
not
the
draft
exactly
yeah.
H
So
I
mean
we
can't.
I
Dave
Taylor,
my
question
is
actually
for
Hank.
I
did
a
search
for
the
word
attestations
with
an
s
in
the
document.
It
occurs
exactly
once
in
the
each
spec
right
now
and
it's
not
in
the
context
of
endorsements,
so
I'm
going
to
read
it
to
you
and
the
question
is:
do
you
have
a
problem
with
this
text
and
if
so,
can
you
come
back
to
the
mic?
I
So
this
is
in
the
intended
use
claim,
and
it
says,
certificate
issuance
certificate
authorities
or
Cas
may
require
attestations
prior
to
the
issuances
of
certificates
related
to
key
Paris,
hosted
at
the
entity.
Yeah.
Do
you
need
that
word
change
and,
if
so,
raise
your
comment
in
context
of
that
sentence,
because
this
is
not
about
it.
It's
not
not
about
not
about
endorsement.
So
it's
probably
not
row
18.
E
I
M
H
O
I
wanted
to
come
back.
Oh
it's
basic
question
on
the
earlier
issue
about
the
nonsense
and
the
freshness
aspects.
O
H
Yeah
I
can't
remember,
okay,
what
what
text
you
proposed
or
and
what
we
used
but
I
I'd,
say
I'm,
a
double
check.
Do
you
know,
search
for
knots
and
search
for
freshness,
yeah
I,
don't
think
it's
more
than
10
sentences
altogether,
Okay
so
and
then
you'll
see
the
whole.
You
get
the
big
picture
and
and
know
if
it's
if.
C
H
C
H
Yeah,
there's
nothing
left
in
the
document,
so
this
issue,
18,
is
basically
turned
into
any
issue
about
the
intended
use
claim
and
the
its
use
of
the
word
attestations.
H
So,
okay,
next
I,
think
we're
jumping
ahead
to
now,
because
we
got
the
freshness
thing.
H
Secure
boot,
so
this
was
a
an
issue
filed
by
Honest.
The
current
text
requires
the
secure
boot.
The
definition
of
a
secure
claim
requires
that
the
booted
software
be
under
the
control
of
the
OEM.
H
H
F
I
I
I'm
trying
to
press
buttons
too
fast,
I,
don't
know
what
the
proposed
text
was
unless
it's
like
I,
don't
think
it's
on
the
screen
right
now,
although
I
think
there
is
a
valid
argument
here
that
some
secure
boot
is
not
necessarily
the
OEM.
I
If
you
think
of
a
case
where
say
an
Enterprise
buys
a
device
and
the
Enterprise
wants
to
be
the
one
that
actually
controls
the
secure
boot
process
rather
than
the
OEM
I,
think
that's
a
valid
scenario
and
so
I
think
I
probably
would
like,
but
I
can't
say
whether
I
like
the
proposed
X
better
without
it
being
on
the
screen.
Yeah.
K
I
I
H
I
H
I
So
and
I'm
a
huge
fan
of
the
approach.
It
says,
if
you
don't
have
consensus
on
it
like
yesterday,
then
leave
it
to
an
extension
document
open
the
base,
one
and
so
I
think
it's
perfectly
fine
for
you
to
respond,
saying
we're
not
going
to
put
the
more
generic
one
in
this
document.
That's
going
to
be
in
an
extension
that
can
add
that
I
love
that
style
of
answer.
We
did
the
same
thing
in
suits
so
I,
I,
I
I,
like
that
approach
and
so
I
think
the
rename
is
probably
the
simplest
least
effort.
F
O
Yeah,
so
what
the
document
says
is
secure.
Boot
is
considered
enabled
when
the
firmware
and
operating
system
are
under
the
control
of
the
manufacturer
of
the
entity
identified
in
the
OEM
ID
claim.
Okay
and
like
for
me,
secure
boot
is
a
it's
a
kind
of
a
more
technical
term
where
you
almost
always.
You
start
the
sun
non-mutable
immutable
code,
which
is
like
some
run
code
in
ROM,
and
then
you
and
also
have
some
keys
there,
and
then
you
verify
the
next
stage
and
then
that
verifies
then
the
next
stage.
O
So
this
whole
notion
of
controlling
something
is,
is
I.
Think
I
I
didn't
quite
understood
what
that
practically
means
like
when
do.
I
then
claim
that
I'm
using
secure
put
versus
not
because
even
with
mesh
output
you
could.
You
could
argue
that
you
are
controlling
the
other
things.
O
May
well
be,
but
it's
not
secure,
put
right
like
under
what
condition
can
I
can
I
say
that
I'm
really
controlling
the
other
software,
the
the
the
different
layers
of
software
that
comes
firmware
and,
and
maybe
there
might
be
bootloaders
as
it
is
used
in
practice
and
then,
like
that's
what
I?
That's
what
my
question
was
to
in
that
that
regard.
H
So
let
me
respond
to
that
a
bit.
So
you
know,
if
you
think,
of
something
as
complex
as
a
mobile
phone
with
an
app
download
system,
and
you
can,
you
know,
run
JavaScript
in
the
browser
and
all
that,
so
you
can't
say,
controls
all
the
software
stack
from
from
right.
H
So
the
so
the
words
chosen
I
think
are
firmware
and
operating
system
and
the
the
the
choice
was
also
to
use
the
word
control
here,
because
and
not
not
be
specific
to
something
that
use
uses
a
specific
mechanism
because
there's
a
lot
of
ways
the
OEM
can
control
it
right.
The
the
the
the
device
could
be
running
solely
out
of
ROM,
so
no
crypto
required
the
the
code
is
solely
out
of
ROM.
There's
no
there's
no
software,
that's
updated
or
uploaded,
or
anything
like
that.
H
That
isn't
a
valid
means
of
control
I
mean
you
could
even
put
the
put
the
device
in
a
you
know,
titanium,
Cube
or
something
like
that,
so
that
there's
no
no
way
for
them
to
change
it.
So
that
try
to
tried
to
avoid
that
definition
of
like
public
key
signing
and
or
Max
or
anything
like
that
quite
intentionally.
H
So
so
that's
why
you
know
the
OEM
control
under
under
OEM
control.
This
is
what
we
did
in
Fido
certification
is
really
the
definition
and
phytocertification
is
the
phyto
authenticator
needs
to
be
under
under
control
of
the
the
manufacturer
of
the
Fido
authenticator.
So
my
my
question
on
us
is:
if
we
change
it
to
OEM
authorized
boot,
or
something
like
that.
Does
that
address
your
question?
Your
your
concern.
H
D
Brenda
Brendan
at
the
mic,
so
for
me,
secure
boot
means
that
you
have
something
immutable
and
that's
all
it
means
and
what
you
do
with
that
something
immutable
is
up
to
you
for
the
conventional
meanings
of
secure
boot,
the
ones
that
I
would
go
with.
D
That
would
mean
that
there
is
a
public
key
that
has
verified
something
or
or
a
Mac
if
you
prefer,
and
indeed
the
key
identifier
defines
the
identity
of
whoever
controls
the
device
so
talking
about
it
being
the
OEM.
Well,
if
the
oem's
public
key
happens
to
match
the
key
identifier
that
authenticated
your
boot
code,
then
the
OEM
controls
it.
Otherwise
they
don't
I,
don't
see
why
we
need
to
make
a
distinction.
You
have
a
cluster
of
keys,
that's
who
controls
the
device,
the.
D
You're
talking
about
the
screw
in
the
in
the
bottom
of
the
laptop
that
you
take
out,
if
you
want
to
install
Linux,
yes,
I
understand
this.
H
D
H
M
Yeah
I'm
again
doing
the
time.
Trevor
thing
coming
back
to
the
issue
with
the
freshness
and
the
and
the
nuns
things
I.
M
I'm
sorry
you're
continues
so
I
have
a
comment
on
this.
The
immutable
the
secure
boot
means
evidence
until
boot.
Integrity
has
been
established
and
that
has
been
in
set
in
stone
as
evidence
until
the
next
boot
has.
H
Okay,
secure
boot
is
definitely
a
ambiguous
word
in
in
general.
Right
I
would
not
think
that
you
can't
look
up
secure
boot
in
Wikipedia,
I
didn't
get
it
or
TCG
documents,
or
something
like
that
and
get
a
definition.
Everybody
will
agree
on
that's
why
the
wording
in
in
eight
is
under
control
of
the
OEM.
H
J
K
M
Yes
and
I
don't
need
an
answer
and
that's
the
point.
That's
exactly
the
point.
I
don't
need
a
nons
to
be
fresh,
and
that
is
very.
F
M
M
M
B
M
Yeah
I'm
slow
I
have
a
latest
job.
It
is
refreshed,
you
know
auditable
after
the
fact
you
couple
in
8.4
replay
protection
privacy
and
say
that
it
defines
the
nons
claim
for
total
replay
protection,
yes
and
then
in
parenthesis,
also,
sometimes
known
as
token
freshness.
M
I
would
disagree
with
that
entirely
only
because
that
use
of
nuns
is,
by
by
circumstance,
a
way
to
established
freshness
the
ad
hoc
freshness,
because
you,
as
the
issue
of
the
nuns,
know
that
you
just
issued
it
is
making
you
the
only
viable
source
of
freshness
by
receiving
something,
including
your
non,
so
that
that's
all
the
nuns
is
about
our
freshness.
But
that's
not
the
problem.
M
You
don't
need
freshness
to
protection
from
replay
attacks
who
need
freshness
for
proofs
of
freshness
and
that's
all,
and
that
the
nuns
by
accident
does
both
as
a
lucky
coincidence.
That
is
not
relevant
to
the
concept.
Okay
and
I.
Think
that
has
to
be
really
kept
apart
and
and
that
that's,
why
I'm
a
little
bit
confused
by
that
all
the
time,
because
people
always
confuse
nons
as
a
freshness
mechanism.
M
M
G
Just
one
comment
on
the
secular
part:
so
would
it
help
to
rather
call
it
a
scope
of
the
keyboard
because
from
vendor
to
vendor
the
definition
of
the
stage
of
circuit
board
varies
like
UV
compliance?
Acute
boot
is
different
from
let's
say
what
some
other
vendors
do.
Would
it
help
to
Define
like
what's
the
scope
of
the
keyboard
in
here
or
the
type
or
what
you're
referring
to
for
me?
Would
that
help.
H
Yeah
I
think
we're
just
trying
to
I.
I
didn't
I,
couldn't
quite
hear
everything
you
said
there,
but.
G
Can
we
have
like,
as
what's
the
scope
of
secure
boot
in
the
context
of
attestation?
Like
do
we
look
at
ufe
compliance
in
cuboid
as
what
we
would
want
to
pick
up
where
you
start
from
the
bootloader
or
some
vendors?
Have
it
like
from
Hardware
Route
across
basic
reboot
versus
CPU,
basically
boot
so
do
we
have
something
like
a
scope
or
circuit
would
defined,
and
would
that
help
clarify
this.
H
So
I'm
yeah,
so
the
the
definition
currently
says
the
firmware
in
the
OS
and
you're,
maybe
trying
to
say
we
should
lock
that
down
more.
G
When
we
say
firmware
again,
it's
kind
of
it
becomes
a
bit
hazy,
because
again,
you
could
split
into
multiple
stages
before
you
actually
get
to
the
North
the
network
operating
system.
So
till
what
stage
do
we
expect
the
OEM
to
control
it
versus
what
could
I
like?
Let's
I'll,
give
an
example
of.
Let's
say
someone
wants
to
run
like
Sonic
on
a
box,
that's
sold
by
a
vendor.
What
would
be
the
scope
of
the
keyboard
in
that
context?.
H
Right
so
that
there's
there's
I
mean
there's
a
tricky
one,
because
yeah
like
I,
said
there's
we're
dealing
with.
You
know
a
device
that
could
be
as
simple
as
just
a
ROM
like
and
no
operating
system
at
all
right
yeah
to
a
mobile
phone
which
has
got
100
CPUs.
The
boot
I
mean
at
least
50.
I
mean,
and
they
all
have
boot
chains
and
and
then
they
have
downloadable
software
and
right.
H
I
Boot
authorized
boot.
There's
three
instances
of
the
word
secure
boot
one
is
in
the
title
and
do
is
in
the
sentences
whatever
as
long
as
you
rename
all
three
of
them,
then
people
stop
asking
you
any
questions
about
what
secure
boot
means.
B
Okay,
so
I
I
have
given
you
the
whole
open
make
time
so
I'm
going
to
give
you
nine
minutes
left
and
then
that
will
heat
up
the
whole
slot
just.
H
Yeah
good
morning,
okay,
so
this
is
PR
number
296..
This
relates
to
that
section.
9.2
about
claims
characteristics
that
I
mentioned
previously.
The
my
understanding
of
this
of
this
issue
is
that
it's
a
suggestion
for
separate
ex
expert
review
for
eat
claims,
so
we
would
somehow
have
to
distinguish
eat
claims
from
other
JWT
and
cwt
claims,
because
the
these
claims
would
be
eat.
Claims
would
be
subject
to
more
extra,
more
review
or
different
criteria,
or
something
like
that.
H
You
know,
I
I,
don't
think
this
is
a
question
that
we
want
to
separate
the
Registries
or
create
a
whole
new
eat
registry.
It
seems
like
it
does
beg
the
question
of
some
sort
of
a
bit
in
the
registry
that
tells
you
whether
this
is
an
eat
claim
or
not.
The
eat.
H
Authors
think
that
the
current
expert
review
is
fine
and
that
the
expert
review
that's
applied
to
cwt
and
GWT
is
sufficient
and
that
trying
to
create
a
separate
expert
review
would
cause
would
be
kind
of
a
big
step
to
take
so.
Q
Customer
I
don't
have
a
problem
with
using
the
same
expert
here,
but
the
question
really
is:
where
does
the
information
get
recorded,
whether
the
expert
used
the
JWT
yardstick
or
the
idiotic
I
think
that
needs
to
be
somewhere
after
the
review
is
done.
H
But
there
is
not
a
separate
eight
yardstick.
Is
there
I.
Q
Mean
an
expert
will
look
at
the
thing
to
think.
What
are
you
trying
to
use
this?
For
then
the
registrant
would
say:
I
will
use
it
for
each
and
then
an
expert
review
will
happen
and
then
the
information
is
lost.
So
people
who
consult
the
registry
will
not
be
able
to
find
out
whether
the
review
considered
this
or
not.
That's
a
mistake.
M
Sank-
and
we
were
talking
about
like
for
years
about
adding
a
column
to
the
to
the
Eid
registry.
That
says
this
is
about
eating
sorry,
sorry,
cwt
registry,
that
this
is
about
eat.
We
could
flag
that
yeah.
B
Q
N
Jones,
a
designated
expert
for
said
registry.
What
what
is
the
purpose
of
the
column.
M
So
the
purpose
of
the
touch
screen
is
that
cwts
should
be
protected
from
using
certain
semantics
by
accident,
because
every
cwt
claim
automatically
is
allowed
for
every
cwt.
Apparently
so
some
are
very
red,
specific
and,
and
someone
who
just
reads
a
claim
name
might
be
inclined
to
read
what
they
want
to
read,
but
not
what
it
actually
means,
and
that
does
not
actually
eat
read
to
eat
ideas.
Rfc
at
that
point,
so
I
would
give
that
as
a
pointer
through
the
semantics.
M
This
is
about
remote
attestation
and
and
if
by
accident,
this
can
also
be
used
for
cider
production.
That's
great,
but
you
should
be
very
aware
of
that.
I
think
it's
relatively
dangerous
to
to
to
go
for
some
UE
ID,
for
example,
which
is
useful
in
most
contexts,
but
I
think
you
really
have
to
be
understand
that
this
is
for
device
identification
in
the
context
of
remote
attestation.
M
N
Can
I
respond?
Yes,
go
ahead,
Hank
I,
don't
see
those
characteristics
as
unique
to
eat.
I,
don't
see
those
characteristics
as
you
need
to
eat.
For
instance,
Ace
registered
cwt
claims.
Some
of
them
are
general
purpose.
Some
of
them
are
very
specific.
The
same
could
be
said
of
the
Jose
algorithms
registry
and
or
the
Jose
claims
registries.
A
Yes,
that's
fine,
so
the
first
point
on
this
slide
was
never
the
point
of
the
of
the
pr
okay.
The
first
point,
the
point
of
the
pr.
The
issue
was
that
we
might
want
to
write
a
few,
a
qualifying
words
for
the
expert
reviewers
that
renders
the
so
that
eat
claims
actually
are
a
subset
of
what
cwts
could
make.
A
And
so
the
question
is
I,
don't
know
exactly
what
those
those
words
might
be
and
that
that
was
the
point
of
the
disc
was
to
have
a
discussion
that
can
you
do
anything?
Can
you
is?
It
is
the
whole
list
of
anything
that
you
could
do
as
an
eat
claim
sorry
as
a
cwt
cream,
a
caught
claim.
Does
that
all
apply
to
eat
or
are
there
some
subsets
and
there's
other
some
other
things
as
well?
A
I
think
we
just
had
a
conversation
about
the
OEM,
secure
boot
claim
right
and
mass
confusion,
and
it
sounded
to
me
actually
that
we
might
need
three
or
four
different
claims
right
for
that
and
when
those
claims,
when
those
requests
came
to
the
expert
reviewers,
then
one
of
the
things
I
I
think
it
would
be
reasonable
to
say
to
the
expert
reviewers
is.
It
is
reasonable
that
you
have
three
or
four
claims
that
appear
the
same
but
come
from
different
communities
because
they
have
different
semantics.
A
That
would
be
nonsense
in
a
caught
generic
cost
space.
That
would
be
stupid.
It's
the
whole
point
of
of
a
thing,
but
in
this
case
it
would
be
makes
sense.
We
might
like
to
say
that
now
that's
essentially
asking
the
expert
reviewers
not
to
change
how
they
review
it,
but
rather
to
actually
say:
oh,
this
might
actually
be
a
subset
of
the
things.
A
There
are
certain
criteria
that
you
need
to
apply
more
strenuously
or
a
little
bit
less
generously,
and
that's
where
it
all
came
down
to
okay,
so
I
asked
the
question
to
you:
Mike
is
is
right
now,
do
you
think
you
could
deal
with
that?
We
had
the
conversation
OEM
claim
versus
the
other
thing.
Do
you
think
you
could
sort
that
out
or
do
you
need
extra
guidance.
N
K
Roman,
do
you
need
to
do
so
to
close
that
thread
and
borrow
Hank's
time
machine
about
how
do
we
document
the
decision?
In
the
conversation?
It's
exactly
that
we
have
the
cwt
registration
registrants
whatever
that
mailing
list
is
where
we
documented
the
conversation
about
both
of
the
early
allocation
kind
of
requests
for
this
document.
So
if
we
need
a
place,
it
already
exists.
Now
it's
a
public
archive.
I
I
was
just
going
to
say
that
this
is
actually
related
to
the
conversation
that
was
closed
right,
which
is
I.
Agree.
That's
closed,
that
to
eat
by
itself
as
a
framework
right
eat
is
not
something
that
you
can
interoperate
with
right.
You
interoperate
with
any
profile.
Okay,
and
so
by
saying
that
we
should
not
say
the
following:
claims
are
not
eat
claims.
I
Think
it's
because
we
made
the
the
the
framework
resolution,
which
I
liked
I
think
that
actually
answers
this
question
too,
is
my
opinion.
So
thanks
Steve,
so.
H
So
the
the
last
comment
I
have
on
this
is
that
if
we,
if
we
take
this
on
and
and
try
to
figure
out
how
to
add
an
extra
column
and
have
context
sensitive
Ayana,
Registries
I
mean
that
seems
like
a
very
large
amount
of
work.
That's
going
to
delay
eat
for
months
to
me
because
I
I
mean
that's,
that's
I
I
mean
I,
don't
know.
Maybe
Ayanna
knows
how
to
do
this
already,
but
that
seems
like
a
new
thing
from
from
Ayana
point
of
view.
So
that's
definitely
demotivating
into
me.
B
L
So
Eric
can
can
talk
now
because
he's
gone
so
I
will
take
over
his
part,
which
was
talking
about
the
recently
published
R4,
which
is
zero.
Three
is
just
a
refresh
of
zero
two
and
we
did
it
not
for
that
not
to
expire
and
I.
L
Think
at
this
point
we
think
the
main
blocks
are
in
place
and
and
that's
why
basically
there's
no
further
content
that
we
had,
but
that
doesn't
mean
that
all
the
building
blocks
are
all
right
and,
in
particular,
I
think
what
the
document
very
much
needs
at
this
point
in
time
is
people
from
all
places,
verifiers
a
testers
and
and
relying
parties
to
take
a
look
at
the
internal
organization
of
the
trustworthiness
vector
and
try
to
match
it
against
their
use
cases,
and
that
would
be
immensely
useful
for
us
and
the
questions
you
answers
are,
you
know:
are
the
currently
defined
appraisal
categories?
L
What
I
really
want
to
have?
Is
there
any
Gap
in
what
we
have
at
the
moment?
And
and
what
do
we
need?
Right
being
you
know
up
front
and
telling
telling
us
I
need
this
category
and
and
this
other
category
that
are
not
there
at
this
point
in
time,
so
to
make
something
that
is
really
useful
for
everyone.
L
We
really
need
to
factor
in
as
wide
as
input
as
possible
and
so
I'm
I'm
asking
the
chairs
here.
What
would
be
a
a
good
way
to
organize
this
kind
of
feedback
cycle?
Well,.
B
Q
B
So
we
could
solicit
feedback
correct
right,
usually
when
I
do
the
calls
for
interest
I
put
the
questions
of.
Is
this
draft
right.
Q
B
M
So
this
is
Hank
from
from
implementation
point
of
view.
There's
the
there's
this
ACC,
the
confidential
Computing
Consortium
I,
did
the
right,
CCC
yeah,
exactly
okay.
So
there's
a
lot
of
discussion
about
this
packaging
of
capabilities
that
would
have
been
reflected
in
attestation.
Results.
Q
M
I
think
maybe
if
we
want
to
have
a
like
a
demonstration
of
Interest,
we
could
yield
some
of
these
implementers
that
are
actually
doing
the
stuff
into
this
discussion
once
they
don't
want
to
standardize
things.
They
just
want
to
implement
things,
but
maybe
for
in
this
case
it
might
be
a
good
to
have
a
like
a
like
a
shared
and
vote
of
a
demonstration
of
of
Interest
right.
L
B
F
L
B
Yeah
I
realize
that
okay
Roman
is
in
the
queue
too
don't
know.
K
A
suggestion
on
how
to
elicit
that
feedback
I
mean
schedule,
a
virtual
interim
like
yeah,
and
this
is
what's
on
the
agenda
and
if
there's
a
lot
of
iteration
kind
of
back
and
forth,
you
know
put
it
on
the
side
as
a
design
team
but
maybe
pin
a
date.
Everyone
brings
their
use
cases.
Then
we
figure
out
whether
you
know
the
the
overlap
with
yours
or
new
stuff
is
needed.
K
B
L
Very
much
and
and
the
this
this
presentation
here
is
we've
been
we've
been
working
on
a
civilization
of
our
foresee.
Obviously,
you
know
with
supporting
codes,
and
this
is
would
be
just
a
quick
report
for
for
sharing
you.
L
Enthusiasts
to
you
know
what
where
we
are-
and
you
know
to
stimulate
discussion
but
yeah,
so
the
goal
of
our
foresee
just
to
recap,
is
to
Define
an
information
model
for
conveying
a
normalized
set
of
Association
results
and
at
the
core
of
the
spec
there's
this
trustworthiness
Vector,
which
is
a
gigantic
Matrix
of
predefined
and
customizable
semantics,
and
on
top
of
that
we
have
a
set
of
rules
for
computing,
the
the
the
vectors
values
and
this
this
is
it
basically
next
slide.
Please.
L
L
Bottom
up
the
the
types
that
we're
using
is:
we
have
the
first
one
of
these
tiers,
which
is
the
basic
thing
it's
basically
a
a
bit
signed
in,
so
that
defines
a
256
code,
Point
space
and
it's
organized
in
four
horizontal
fears,
affirming
warning
contraindicated
and
one
meaning.
L
This
is
good,
and
this
is
definitely
dodgy
or
I
cannot
say,
and
this
base
here
is
also
segmented
vertically
in
two
subspaces
positive
is
standard,
so
we
Define
exactly
what
that
means,
except
we
do
that
sparsely
so
the
Matrix
is
bars
and
then
a
completely
private
thing
for
the
negative
numbers.
L
But
the
important
thing
to
understand
here
is
that,
even
if
you
don't
understand
so
we
didn't
the
understanding
needs
to
be
that
from
private
space.
You
very
Space
is
really
understandable
within
a
private
domain,
a
closed
domain,
and
so,
if
things
in
the
private
space
emerge
from
the
from
the
from
the
closed
domain,
then
the
the
downstream
relying
part
you
will
not
know
exactly
what.
L
That
means
the
thing
what
what
the
code
Point
means,
but
the
second,
the
horizontal
segmentation
allows
the
the
downstream
receiver
to
actually
Define
understand,
at
least
roughly
what
the
thing
means
using
the
four
categories.
Next,
please.
L
Okay,
so,
and
then
you
have
the
trustworthiness
claim,
which
is
a
thing
that
is
associated
with
a
an
appraisal
category.
So,
for
example,
you
have
executables,
you
want
to
measure.
You
want
to
understand
whether
the
running
code
is
in
in
in
the
expected
state
or
not.
You
have
say
other
categories
like
device,
identity,
memory
protection.
L
You
know
many
and
to
each
of
these
categories
you
have
the
trustworthiness
theater
associated
with
the
defined
set
of
semantic.
So,
for
example,
in
the
case
of
executable
number,
three
means
the
specific
things
in
the
case
of
memory.
Protection
number
three
would
mean
another
thing,
but
both
will
be
in
the
affirming
tier
next.
Please.
L
Yeah,
so
then
you
you
put
together
these
eight
categories
and
that's
that's
what
I
was
mentioning
before
this
is
what
we
have
predefined.
This
is
the
pre-canned
shape
of
the
the
trustworthiness
Vector.
These
are
the
eight
sort
of
appraisal
categories
that
we
we
pretty
fine
and
yeah.
This
is
this
is
the
core.
The
semantic
core
of
an
attestation
results
is
based
on
this
next,
please.
L
Compared
to
another
thing,
you
want
to
know
when
the
appraisal
happened,
you're
going
to
have
freshness
indications,
right,
connect
to
the
thing
so
roses
or
apoc
IDs
or
whatever.
L
You
want
to
have
an
identifier
of
the
principle
policies
that
we
used
for
computing,
the
r4c
vector,
maybe
if
the
verify
is
running
inside
and
executive
execution
environment.
You
also
want
to
have
evidence
about
that.
So
you
want
to
stash
evidence
together
with
with
the
the
the
the
the
appraisal
results,
and
so
you
need
to
have
these
contextual
stuff
that
are
forcing
doesn't
Define,
and
you
need
to
also
have
a
a
data,
a
data
model.
Please
you.
L
B
L
Yeah,
so
that
one
that
was
right
before
was
the
realization
on
cdbl
of
the
trustworth
inspector,
so
you
see
the
for
the
eight
categories,
the
the
thing
for
them
next
next.
L
Yeah,
that's
what
that's
the
thing
and
then
what
we've
done.
We
have
taken
that
and
associated
with
the
the
contextual
stuff
that
I
was
mentioning
before
in
terrain
a
year
for
for
lack
of
better
name
and
ethernet
station
results
clean
set,
and
this
has
got
the
you
know
the
status,
which
is
the
the
summary
of
the
appraisal,
the
profile,
because
it's
in
it
so
anyways
files,
and
we
use
that
for
versioning.
L
Also,
the
the
kind
of
content
of
this
stuff,
the
transformation
transport,
finesse
Vector
at
the
core
and
then
other
stuff
right
and
the
important
thing
there
is
obviously
wanted
him
to
discuss
and
it
would
have
some
some
feedback
is
the
is
the
socket
there
to
allow
it
extensions,
either
ear
extensions
on
the
clean
set.
Please
go
ahead.
L
L
L
And
here
what
we
have
done
for
the
replacement
review
as
a
vendor,
the
number
of
vendors.
L
In
the
open,
so
it's
not
a
very
specific
thing,
but
you
know
the
the
product.
Specific
thing
is
that
we've
added
two
kind
of
extensions
in
there
to
that
socket.
One
is
for
sort
of
taking
so
because,
because
we
take
different
kinds
of
evidence
with
a
in
a
different
formats,
we
want
to
give
back
and
normalize
the
view
of
the
claim
set.
That
was
received
independently
of
the
format
that
was
used
by
the
by
the
submitter,
and
this
is
what
we
we
use
there.
L
Basically,
you
have
this
associative
array
that
represents
the
claim
set
in
a
normalized
way,
and
the
other
thing
there
is
the
verifier
added
claims
is
a
bunch
of
claims
that
the
verifier
does
as
part
of
the
appraisal
right.
So
when
you're,
when
you
praise
the
thing,
you
also
realize
other
things
that
not
necessarily
are
in
evidence,
but
you
have
received
the
information
that
you've
received
from
supply
chain
or
other
things
like
say,
certification
body,
please
go
next.
Please.
B
I
No
problem,
my
question
is
on
something
that
you
and
I
have
not
already
talked
about.
Given
we've
already
talked
about
other
feedback
on
here
it
defines
space
for
standard
and
private,
in
other
words
out
of
those
numbers
there.
The
Anna
section
just
says
see:
body
I'm,
imagining
that
you'd
want
an
INR
registry
for
all
the
standard
ones
and
that
you'd
want
some
way
of
having
implementations
or
vendors
or
whatever
specify
what
they're
going
to
use
for
private
use.
I
Out
of
the
other
out
of
the
negative
numbers,
and
my
question:
is
you
haven't
really
specified
the
full
eat
profile
in
the
way
that
the
eat
document
requires
profiles
doesn't
be
specified,
and
so
my
question
is
for
the
private
space,
the
negative
numbers?
How
do
you
know
what
the
interpretation
is?
Are
you
planning
on
putting
like
OEM,
ID
or
something
into
the
e-profile,
or
how
would
you
actually
be
able
to
tell
on
receipt
what
the
negative
number
is
semantics.
L
I
Can
tell
what
the
tier
is,
but
you've
got
a
whole
bunch
of
ranges
and
it
says
well.
This
is
a
non-standard
reason.
How
do
I
know
what
the
non-standard
reason
is
unless
I
know
what
like
the
OEM
ID
or
whatever
the
the
vendor
ID
like
in
DHCP?
You
have
the
thing,
but
then
you
got
another
option
that
tells
you
how
to
identify
which
private
spaces
is
out
of
so.
L
I
B
L
L
In
your
types,
perfect,
next
next
I
think
these
are
just
nothing
but
okay
recap:
this
is
the
it
type
system,
six
production,
basically,
three,
the
the
downside,
the
signed
and
the
bundle
and
for
each
of
the
production
we
have
allocated
a
media
type.
Next,
please-
and
this
is
the
table-
should
be
the
table
of
the
of
the
all
the
media
types,
the
two
chord,
the
two
protected
one,
the
two
bundles
and
the
two
are
unprotected,
and
these
are
the
names
that
they
use.
L
Now
we
have
renamed
the
each
damper
to
each
one,
because
now
his
bundle
is
not
there
anymore.
Next,
please,
foreign.
L
Profile
to
it
profile
for
consistency
with
it
closed
four
eight
was
the
other
one
related
to
the
downstream
repercussions
of
the
change
in
naming
in
the
heat
spec
we've
done.
We
remove
the
dev
and
replace
with
bun,
and
then
we
had
a
couple
of
issues
associated
with
feedback,
the
tutorial
feedback
that
we
got
from
the
event
car.
Thank
you
very
much.
I
think
we
have
addressed
your
your
stuff,
but
if
you
want
to
double
check,
just
click
on
those
comments
and
see
whether
next
please
foreign.
L
Because
if
you
use
media
types
in
the
textual
form,
you
don't
need
to
any
to
do
anything
in
order
to
use
a
specific
profile,
because
you
just
tack
you
just
take
the
you
just
take
the
the
profile
ID
inside
the
media
type
parameter,
but
for
crop.
You
cannot
at
this
point
in
time
because,
because
the
content
formats
are
different
from
media
types,
basically
they
are
compressed
code
points
and
they
are
not
very
you
know
flexible.
L
So
there's
a
draft
that
I
have
proposed
in
court
is
probably
time
to
solve
a
sort
of
bigger
problem
here,
which
is
a
generic
transfer
of
media
type
parameters,
which
is
the
CF
parameterized.
Whatever,
and
we've
discussed
this
in
an
interim
I've
got
excellent
feedback,
I've
updated
it,
but
what
I'm?
What
I
want
to
say
here
is
that
this
black,
this
the
dependency
on
this
mechanism
is
not
blocking.
For
the
rest,
it's
just
not
ideal,
but
it's
okay.
L
We
can
go
on
without
we
will
return
that
was
raised
by
many
see
you
think
at
adoption
for
providing
a
better
use
case
in
Russia
now,
which
I
think
is
going
to
be.
You
know
a
few
lines
more
in
the
in
the
introduction
and
I'm
happy
to
do
that.
You
know
quickly
and.
J
L
L
We
have
a
standard
track
document
for
for
requesting
the
the
the
thank
you
types.
We
have
clear
rules
expressed
there,
I
think
and,
and
we
are
now
stable,
because
the
only
thing
that
was
a
bit
wobbly,
the
dev
thing
has
been
settled
and
so
the
last
point
before
we
can
request
an
early
location
which
I
think
we
want
to
have
at
least
from
my
perspective,
because
we
want
to
use
it
and
we'd
like
to
use
them.
L
B
L
B
I
think
it's
okay.
The
question
is
on
the
stability
and
changes
yeah.
Let
me
go
back
and
confer
with
the
other
chairs.
Roman
I
think
it
may
be
okay,
if,
if
we
think
it's
stable
enough.
B
K
L
No,
no
I
think
there's
none.
Oh
no
yeah,
it's
a
stupid
thing,
so
yeah
we're
gonna,
go
to
the
early
location
and
we'll
close
the
the
blocking
issues
and
and
then
we
can
submit
too
and
at
that
point
in
time,
I
think
we
are
ready
for
working
group.
Let's
go.
B
Okay,
thanks
all
right
everything
keeps
spilling
over
next
is
secure
routing
who
is
up.
R
R
J
R
R
Ip
network
is
to
try
to
deliver
at
the
same
time.
There
are
many
security
functions
in
the
network
to
ensure
the
availability
of
the
network
why
security
is
required
for
Network
operators
through
security
routine,
can
reduce
users
attacks
on
the
network
and,
on
the
other
hand,
due
to
the
Improvement
of
network
security,
we
can
provide
users
with
differentiated
security
service,
of
course,
with
the
frequent
occurrence
of
security
incidents.
Our
users
are
more
sensitive
to
security.
R
R
R
R
R
R
The
first
is
to
collect
the
nose
security
capabilities
to
the
controller
and
then
the
control
form
routine
paste
according
to
the
user's
security
requirements,
finder
issue,
the
routine
Pace.
This
may
be
implemented
through
routing
programming,
Technologies,
usually
distributed
to
tenure
entrance
nodes
when
using
segment
routine
V6.
Next.
R
Then
how
to
get
no
security
capabilities
such
informations,
we
propose
to
extend
the
protocol
bgpls
to
carry
the
security
capabilities
of
the
node.
It
is
defined
in
the
RC
Samsung
52
is
standards.
The
nosbond
distribution
of
Link
State
and
the
traffic
engineering
information
using
PCP
describes
a
mechanism
by
which
link
State
and
traffic
engineering
information
can
be
collected
from
networks
ensured,
with
external
components
using
the
P2P
routine
protocol.
R
This
protocol
defines
three
types
of
Network
layer,
reachability
information,
that
is,
that
are
note,
link
and
preface
on
inner
finger.
One
is
your
scaring
the
security
capability
of
the
local
node
through
their
hpls
type.
Note
next.
R
Yes-
and
the
last
finger
here
is
use
the
prefix
type
to
carry
the
optimal
systems
in
security
capabilities.
R
R
R
This
topic
needs
more
discussion.
This
is
the
first
presentation
in
a
rest,
work
group
and,
and
now
we
do
not
fight
and
shoot
for
Walker
in
the
security
area.
So
I
need
advice
to
apply
for
a
special
email
list
or
further
discussion
such
like
how
how
to
use
the
security
capabilities
except
from
secure
writing
pace
and
how
to
timely
and
efficient
schedule.
The
use
of
security
functions.
B
So
you're
out
of
time,
but
I'm
gonna,
let
Eric
one
question
but
I
will
to
your
questions
on
next
to
do
mingling.
B
B
Yeah
the
security
dispatch
because
you're
talking
about
the
general
routing
I'm,
not
sure
that
I
can
see
potential
connections
with
rats,
but
for
some
of
those
requests,
I
would
take
it
to
the
SEC
dispatch.
P
I
like
where
you're
going
with
this
in
terms
of
pulling
out
requirements,
I
do
think
that
there's
value
in
pulling
out
requirements
from
The
Trusted
path,
routing
work.
Do
you
see
anything,
that's
not
interested
path,
routing
functionally
that
you
need
or
see
covered
with
your
work.
R
Yes,
trust
the
rooting
and
secure
routine
I
I
do
not
get
the
clear
point
of
your
suggestions.
P
Really,
what
I
was
asking
is
the
functional
requirements
match
up
to
some
of
the
functional
requirements
that
are
part
of
the
trusted
path,
routing
document?
In
essence,
it
pulls
the
requirements
out
from
the
solution
and
that's
good.
Do
you
have
other
requirements
which
are
not
in
the
trusted
path?
Routing
draft
and
we
can
take
that
online.
If,
if
you
want
yeah.
O
O
Buying
that
token
also
do
a
key.
You
could
call
it
a
proof,
possession
token
and
there
are
use
cases
where
this
is
needed.
Specifically,
if
you
want
to
put
at
the
station
information
in
a
in
a
larger
context
when
you
actually
establish
a
secure
Channel
like
we
do
in
both
DLS
this
work,
we
started
it
by
using
it,
but
it
can
be
applied
more
generically
and
the
design
is
intentionally
made
so
that
you
can
also
use
other
attestation
Technologies
other
than
eat
next
one,
it's
actually
a
very
short
presentation.
O
This
is
what
you
find
in
the
document
which
is
shown
at
the
last
slide.
So
we
came
up
with
what
we
call
a
key
attestation
token,
which
is
the
there
are
lots
of
new
acronyms.
Of
course,
our
main
contribution
of
this
work,
because
this
is
the
idea
of
using
key
attestation-
is
not
something
we
came
up
with
that
exists
already
for
I.
O
Don't
know
how
many
years
this
key
attestation
token
and
the
path
which
is
called
the
platform
attestation
token
is
combined
together
in
a
bundle,
so
you
actually
convey
in
a
protocol
exchange
to
tokens
with
different
semantics.
O
The
platform
attestation
is
what
you,
what
we
also
use
today
with
the
the
e-token
to
make
an
assessment
about
what's
running
on
the
on
the
device,
what
Hardware
Etc
so
there's
nothing
new
here
and
we
want
to
reuse
the
existing
software,
because
that's
minimal
amount
of
software
on
the
device
and
then
augment
it
with
a
second
token
and
where
you
see
specifically
one
key
public
key
being
added
this
identity
key
and
that
key
is
one
that
is
used
in
a
TLS
handshake,
for
example.
O
Right
specifically
in
this
in
our
document,
in
depending
on
how
whether
the
client
is
the
test
or
the
server
side
is
the
adjuster
and
if,
let's
assume
for
examples,
we've
used
post
cases.
But
let's
assume
the
client
does
the
attestation
it
generates
and
that's
on
the
next
slide.
O
The
the
client
TLS
client
creates
this
identity
key
pair.
It
obtains
the
nonce
from
the
from
the
server
side
like
in
in
it.
You
would
do
to
do
the
freshness
the
client
would
create.
This
bundle
would
create
the
the
platform
attestation
and
then
also
the
key
at
the
station
token,
like
shown
on
the
previous
slide,
and
it
includes
the
identity,
key,
the
public
key
and
the
key
attestation
token,
and
also
as
a
mechanism
the
nuns
for
freshness.
O
It
then
transmits
that
bundle
in
a
30
in
a
certificate
message
to
the
server
instead
of
the
x509
certificate,
which
was
which
we
always
used,
but
then
it
also
has
to
prove
the
possession
of
the
private
key
corresponding
to
this
identity
key,
which
is
what
the
certificate
verify
message
does
so
on.
What
does
this
then
provide
the
the
server
side?
It
then
knows
based
on
the
platform.
At
the
station
token,
what
type
of
software
is
running
on
that?
O
Nothing
has
been
modified,
that
there's
specific
Fingerprints
of
the
firmware
and
and
potentially
software
on
high
up
on
the
stack,
and
it
also
knows
that
the
software
used
to
produce
this
key.
At
the
station
token
is
also
unmodified,
and
it
also
knows
that
the
the
private
key
corresponding
to
this
identity
key
is
stored
in
a
in
in
the
Hardware's
sort
of
security
boundary.
So
it's
not
cannot
be
exported
or
released,
and
and
thereby
it
knows
that
the
client,
the
TLs
client,
has
possession
of
that
private
key.
O
Thomas
has
another
document
the
the
message
wrapper
that
provides
this
generic
framing
to
also
include
other
attestation,
technology
like
dbm
based
stuff
and
so
on,
intra
TLS
exchange
and
it's
our
attempt
to
use
attestation
more
generically
in
in
sort
of
like
protocols
like
DLS
or
higher
layer
protocols.
F
O
Looks
like
this
code
from
the
hackathon
look
at
it.
Try
it
out
and
if
you're
interested
come
to
me,
I'll
show
you
how
the
code
Works
actually
in
the
in
the
subsequent
happy
hour.
We
actually
show
it
to
you
if
you
want.
Oh.
M
That's
the
future
so
yeah,
you
just
said
it
there's
a
lot
of
illustration:
Technologies
out
there
and
you're
inheriting
I,
don't
know
if
consciously
or
just
by
accident,
like
it's
75
of
TCG
terminology
and
your
things
there.
So
one
team
Wiseman
is
not
here,
unfortunately
due
to
a
certain
issue,
but
maybe
we
should
have
a
coordination
call
and
get
these
things
like
super
aligned.
Okay,
so
there
will
be
no
friction.
That
would
be
a.
F
O
D
B
Awesome
I
gave
you
five
minutes
for,
and
you
did
both
okay.
Then
we
have
conceptual
message
wrapper.
Q
L
O
B
L
Yeah
yeah
you're
right
yeah.
That's
why
I
thought,
but
is
these
in
the
same
bundle
as
as
the
one
is
the
basically
the
encapsulation
that
allows
these
agnosticism
about
the
the
the
attestation
messages
that
are
transported
in
the
protocol,
yeah,
not
just
in
TLS,
as
Hannah
said
in
different
high
level
protocols.
So
next,
please.
L
F
L
Csrs
extension
like
dice
TCG
dice
does,
then
you
can
use
this
TLS
tested.
Harris
was
presenting
is
another
use
case
for
this.
We
use
stash
that
in
the
in
the
end,
Shake
message
in
the
relevant
and
Sheet
messages,
you
have
a
use
case
for
this
phone
with
when
you
use
it
in
in
restful
apis
for
embedding
palers
inside
you
know
bigger
objects,
and
we
were
using
this
in
varies
in
the
verifier,
but
it
could
also
be
used
for
for
archival,
long-term
archival,
for
example,
of
Association
results.
You
know
spaces
and
objects
thanks,
please.
L
Increased
Ingenuity
in
the
in
the
ecosystem,
therefore
easier
consumption
by
all
the
actors,
all
the
roles
in
the
in
the
architecture
and
as
well
as
the
ability
to
compose
different
protocols
without
doing
the
in
Capital
Cap
right
multiple
times
it
just
extract
and
push
it
in
from
one
protocol
into
the
other,
as
is-
and
this
is
a
deeper
thing-
is
a
byproduct
of
the
aspect
that
we
can.
We
can
have
interfaces
to
a
testing
environments
that
can
become
more
uniform
in
the
long
term.
Next,
please.
L
L
L
So
we
have
this
to
to
buys
you
need,
or
you
have
the
long
string
depending
on
what
you
want
to
do,
then
what
you
have
next,
please.
L
P
L
Is
an
example
to
drive
it
through
the
whole
cycle?
You
won't
go
ahead
and
register
application.
Vendor
entails
sgx,
because
you
want
to
ship
a
Intel
sgx
evidence,
and
you
also
want
to
register
a
compressed
model
format
that
is
semantically
equivalent
with
that.
Let's
say
is
three
three:
thirty
thousand
one.
Next,
please.
L
So
the
first
vegetation
you
do,
you
do
an
email
to
the
Ina
expert
and
and
the
second
because
the
code
point
the
informative
you're
requesting
is
more
than
10
000.
You
go
fcfs
and
that's
another
email
through
Ayana.
This
time
you
don't
have
to
go
through
extra
review
altogether.
Next,
please.
L
And
then,
when
you've
done,
that
you
can
achieve
these
two
encoding
here,
the
example,
the
symbol,
type
event
on
the
Json
Temple
valve
thanks.
Please.
L
But
because
of
casting
and
Michael
I
think
you
know,
we
have
9277
and
that
thing
gives
us
a
fantastic
injection
which
is
a
TM
and
GM
function.
That
is
very
good
function
that
the
injects
the
whole
of
the
corrupt
qualiformal
space
into
a
bunch
of
little
segment
of
the
of
the
sibo
tank
space.
So
if
we
start
from
CF
3000
3001,
you
get
into
magic
receiver
and
you
can
use
it
in
in
this
other
encapsulation,
so
yeah-
and
this
is
the
the
alternative
encapsulation
that
based
on
support
tax.
L
So,
yes,
exactly
so
the
bureaucracy
is
quite
lightweight.
We
don't
have
to
Define
any
registration
inside
the
the
the
the
the
document,
because
everything
is
taken
care
of
by
existing
next
please-
and
it's
quite
simple
right
except
the
first
step
which,
as
an
extra
review
then
the
rest
should
be
really
automatic,
and
these
are
true
typical
simulation
about
the
overhead,
which
is
basically
say
they
are
the
same
next,
please.
Why
are
there
any
simple
tags
or
the
type
salary?
Next,
please,
and
in
summary,
we
have
a
simple
trivial
format.
L
We
have
a
very
simple
registration
mechanics.
This
is
useful
in
a
number
of
different
scenarios
that
I
could
have
effectively
done
just
that
because
that's
that's
the
whole
thing,
and
the
question
is
whether
we
want
to
whether
the
group
is
interested,
whether
we
want
to
adopt,
maybe
in
the
long.
B
L
Right,
we
have
two
I
think
we
have
zero
one
out,
so
we
have
it's.
L
B
B
Thank
you
all
right,
I
think
we
may
only
have
time
for
one
more
unless
Carson
you
can
speak
super
fast.
Q
Q
Yeah,
so
what
does
that
say?
Is
we
have
a
document
out
called
unprotected
cwt
claim
sets,
and
that
has
been
around
for
a
while.
It
has
been
in
a
kind
of
blocking
stage
for
the
last
four
months
or
so,
because
we
wanted
to
make
sure
that
we
fully
align
with
each
with
each
now
being
nearly
done.
B
So
I'm
going
to
speak
it
as
an
individual
contributor
since
I'm
a
co-author
for
this,
so
we
received
some
feedback
there's
like
a
year
ago,
which
we
finally
have
resolved.
We
haven't
heard
any
more
feedback
and
that's
why
Carson
is
reporting
that
we
believe
the
draft
is
stable.
But
the
question
is
for
the
other
chairs
to
respond.
M
So
this
is
Hank
a
fellow
co-author
I
think
working
Google,
Glass
called
with
nudges
into
the
right
way.
I
think
there
might
be
a
two
things
that
really
need
review.
I.
Think
the
working
Google
Glass
Cloud
process
is
the
exactly
correct
way
to
to
find
out
if
this
is
on
the
right
track
and
so
I
think,
even
without
being
entirely
sure
about
this
I
think
working
group
has
probably
will
show
that
that's
my
personal
point
of
view
and
there's
the
one
that
will
do
the
undenting
coming
up.
L
Comments
and
you
address
that
and
I
have
other
comments
which
I
shared
an
initial
bunch
of
them
and
I
want
to
discuss
them
more,
but
I
I
agree
with
the
I.
Think,
that's
you
know,
triggering
the
process
is
the
right
way
to
actually
make
the
discussion
happen
and
you
know
finalize
the
product
which
is.
Q
L
E
So,
to
recap
the
we
have
changes
that
are
pending
for
the
UCCS
draft
or
is
the
one:
that's
that's
uploaded
the
most
current
one
and
there
are
no
pending
changes.
Q
Q
E
Okay,
so
let's
so,
it
seems
like
we
want
to
let
everyone
take
a
look
at
the
the
the
recent
changes
to
read
through
them
and
so
I
think.
Based
on
that,
we
can
have
some
discussion
to
see
if
the
list
believes
that
we're
ready
for
last
call.
Q
E
So
how
many
I
think
I'll
use
the
show
of
hands
tool
to
see
how
many
in
the
room
are
I?
Think
that
it's
we're
ready
to
just
go
to.
J
B
E
So
if
you're
in
favor
of
UCCS
going
to
last
call
directly
show
of
hands
in
the
affirmative,.
J
K
E
Yep
I
think
that
makes
sense.
The
working
group
wants
to
do.
O
B
You
all
right
so
sorry
Brendan
we're
kind
of
out
of
time
unless
you
can
do
it
in
30
seconds.
I
Okay
for
remote,
the
point
was
this
will
be
in
the
suit
meeting,
and
so,
if
you're
interested
in
that
topic
come
to
the
soup
meeting
and
by
the
way
the
teeth
meeting
will
have
more
on
the
ar-4si
and
other
equator
topics,
so
come
to
a
tip
and
come
to
eat.
If
you
wanted
to
talk
about
any
of
those
things
that
we
didn't
get
to
today,.
B
Okay,
so
with
that,
we
are
actually
one
minute
over.
So
thank
you,
everyone,
productive
meeting,
and
we
will
continue
on
the
mail
list
and
we
might
do
a
doodle
Poll
for
another
virtual
meeting.
If
we
need
to
thank.