►
From YouTube: IETF110-RATS-20210309-1200
Description
RATS meeting session at IETF110
2021/03/09 1200
https://datatracker.ietf.org/meeting/110/proceedings/
B
Let's
jump
into
the
agenda
anything
we
need
to
say
about
noteworld.
I
think
everybody
understands
the
ip
rules
here.
B
So
this
is
what
we
have
for
an
agenda
today.
It's
actually
two
slides
kind
of
busy.
B
Let's
take
a
few
minutes
and
see
if
we
want
to
make
any
changes
to
the
agenda,
so
we've
got
nancy's
gonna,
do
a
status
update
for
riv,
kathleen's
gonna
talk
about
attestation
sets
and
then
dave
sailor.
We'll
we'll
talk
about
rats,
architecture
hank.
That
is,
that
up
with
interaction
models,
tuda.
B
And
then
ada
station
results
claims
for
suit
and
then
jeremy's
going
to
take
us
through
seaboard
tags
from
protected
cwt
claims
and
then
eric's
going
to
take
a
few
minutes
on
yang
and
add
a
station
event
stream
subscription,
and
then
we
have
10
minutes
for
use
cases
and
then
essentially
and
then
25
minutes
for
open
mic.
So
if
there's
some
other
topics
that
we
know
we
want
to
talk
about,
we
could
throw
those
out
now
or
otherwise
that
that's
gonna
be
our
our
overflow
time
for
today.
Giving
this
is
such
a
full
agenda.
B
If
not,
then,
let's
move
on
to
the
first
topic,
which
is
the.
F
Me
to
share
well,
I
I
don't
have
any
slides,
it's
just
more,
it's
more
a
question
and
discussion
and
direction
from
roman
our
ad,
so
the
rib
draft
has
gone
through
working
group.
Last
call
I
did
the
final
review
as
I
was
writing
up
the
the
shepherd
write-up
and
I
noticed,
there's
quite
a
few
drafts
that
are
being
referenced
like
the
architecture
like
the
chara
draft,
which
makes
sense
it
also
references,
interaction
models
and
tuda
interaction
models.
F
We
adopted
a
couple
of
sessions
ago,
but
the
tuda
is
yet
to
be
a
working
group
draft.
That
said,
the
references
to
several
drafts
that
are
still
under
work
or
not
adopted
yet
and
so
roma
and
I
didn't
know
whether
you
wanted
us
to
wait
until
we
got
a
little
further
with
the
drafts
and
packaged
them
together
or
whether
we
can
start
going
through
the
isg
publication
review
now,
knowing
that
it's
got
some
dependencies
on
on
drafts
that
are
not
done
yet.
E
Right
that
that
that's
a
great
great
question,
I
mean
worst
case
scenario.
If
we
push
that
document
document
through
you'd
be
sitting
in
miss
ref
for
a
while
on
the
back
end
waiting
for
the
other
ones
to
catch
up
process-wise.
E
So
let
me
take
a
look
and
I'll
have
an
answer
tomorrow
when
we
meet
again
because
the
the
concern
might
be
and
I've
I've
had
that
concern
myself
on
other
documents
and
I've
seen
the
other
ads
do
as
well,
where
if
they
see
the
reference
to
something
that
looks
very
immature
and
it's
fairly
crucial,
because
it's
a
normative
reference
to
a
key
part
of
that
architecture.
They
might
have
the
inclination
to
send
the
document
back
because
they
said
they
can't
judge
this
one
without
being
able
to
read
the
other
one
in
details.
E
If
the
working
group
isn't
close,
so
it's
a
bit
of
a
judgment
call
and
let
me
kind
of
poke
at
it
a
little
bit
but
based
on
all
the
links
you
you
kind
of
talked
about,
and
especially
since
some
of
the
normative
dependencies
aren't
even
adopted
in
the
working
group,
it
might
seem
like
we
want
to
wait.
A
little
longer,
not
necessarily
for
the
others
to
be
done,
but
you
know
for
it
to
be
fleshed
out
a
little
bit
more
in
the
working
group.
F
Okay,
I
can
forward
you
the
list
because,
as
I
was
doing
the
write
up,
I
had
the
list
which
I
think
I
sent
you
in
an
email.
But
let
me
dig
it
up
again
and
I'll
send
them
for
when.
F
Yeah,
that's
all
right!
This
is
why
we're
we're
doing
the
update
here.
So
if
you
can,
let
us
know
right
I'll
know
which
way
to
take
action.
Yep,
we'll
do
that's
it
thanks
in
the
queue.
C
C
E
B
Eric
okay,
any
other
comments.
If
not,
let's
move
on
to
yeah
attestation
sets
kathleen.
D
Good
morning,
okay,
so
this
is
it's
a
pretty
simple
draft
and
the
reason
for
it
is
over
the
past
few
years
I've
been
really
focused
on.
How
do
we
scale
security
better?
And
you
know
just
thinking
about
those
bigger
problems
that
we
have
a
3.5
million
person
deficit
in
security
professionals.
D
I
don't
think
training
is
what's
going
to
get
us
through
that
deficit.
I
think
we
have
to
start
thinking
about
how
we
do
things
and
doing
them
differently,
so
that
we
scale
better,
and
so
one
of
the
small
pieces
of
that
is
when
I've
been
reviewing
the
architecture,
documents
and
eat
and
documents
and
attestation
even
outside
of
the
ietf.
D
I
was
I've
been
thinking
about.
You
know
how
do
we
scale
better
and
I
did
a
little
work
while
I
was
at
dell,
so
you'll
see
that
there
are
dell
reviewers
on
this,
and
so,
if
this
goes
forward,
I'll
I'll
likely
add
one
of
them
as
a
co-editor.
D
So
essentially
you
know
we
have
so
anyone
who's
been
in
the
sac
working
group
who
has
worked
on
scap
knows
that
there's
a
lot
of
challenges
still
for
posture
assessment,
there's
a
number
of
organizations
who
are
able
to
do
it,
but
they
typically
are
ones
that
have
good
resources
on
site.
So
smaller
organizations
who
don't
have
that
level
of
skill
just
aren't
able
to
deploy
and
have
their
systems
assessed
on
a
regular
basis.
D
So
some
of
the
challenges
with
the
current
models
is
that
every
organization
requires
an
expert.
So
how
do
we
get
rid
of
that
demand
for
an
expert
at
each
location
and
it's
shifting
it
back?
Because
if
we
do
attestation
and
set
that
up
at
the
vendor,
which
could
be
an
application
provider,
it
could
be
a
container.
It
could
be.
D
You
know
anything
in
the
stack,
the
operating
system,
parts
of
the
operating
system.
You
know
noting
some
of
the
challenges
michael
had
posted
in
response
to
reading
the
draft
and
for
those
who
who
didn't
read
that
message.
Essentially
just
you
know,
if
you
have
one
component
relying
on
the
validation
of
a
prior
component
before
attestation
can
happen,
the
system
can
hang
or
the
application
can
hang
until
that's
corrected,
and
so
you
know
there
are
obviously
challenges
still
using
attestation,
but
having
those
attestations
set
by
the
vendor
with
you
know,
measurement
ranges
that
could
work.
D
Policy
configurations
to
different
levels
is
one
way
where
we
might
be
able
to
get
to
a
point
where
people
could
just
have
an
easy
button
and
select
I'm
going
to
implement
the
cis
benchmark
for
kubernetes
and
let's
say
it's
even
at
different
levels,
because
you
have
different
requirements,
you
could
just
click
that
button
and
have
that
attested
configuration
and
then
over
time
you
can
still
do
at
runtime
attestations
to
have
assurance
of
that
state
being
continued,
and
so
the
idea
here
is:
how
can
we
push
this
type
of
you
know
built-in
security
model
and
attestation
being
provided
continuously
to
businesses
of
any
size,
regardless
of
resources.
D
Now
I
was
at
dell
for
13
years
before
I
made
my
recent
move,
so
my
exposure
was,
you
know
in
terms
of
implementations.
D
Was
you
know
what
happens
with
the
the
tpm
and
the
firmware
and
the
boot
cycles,
and
so
with
that
they
are
systems
are
booted
up
and
they
largely
match
to
nist
800
or
they
match
to
nist
800
193
and
that's
been
further
instantiated
in
a
tcg
document
for
reference
integrity,
measurements
right,
so
they
are
going
against
a
set
of
items
as
they
go
up
the
stack
and
it
happens,
the
verification
happens
at
boot
and
also
at
run
time.
D
They
also
happen
locally.
If
something
doesn't
quite
match
it.
Can
the
system
can
wait
for
that
to
match
or
restart
a
process
to
ensure
that
the
system's
integrity
is
as
expected,
and
so,
if
you
consider
that
a
set,
then
what
if
we
just
provided
an
attestation
over,
let's
say
the
evidence
of
that
entire
set,
completing
which
could
be
in
this
case
the
the
tpm
logs.
D
And
then
that
could
be
put
into
an
eat,
and
you
know
I
I
don't
know
how
we
want.
We
would
want
to
do
that
if
it's
just
a
uri
to
logs
or
the
actual
log
file
which
might
be
big,
but
then
just
that
complete
set
would
be
provided
in
a
remote
attestation
as
opposed
to
each
individual
attestation,
because
if
you're
thinking
about
managing
thousands
of
systems,
how
would
you
pull
in
all
of
the
attestations
for
an
entire
set?
D
D
D
So
what
does
that
look
like
this
picture
is?
Is
from
the
the
nist
800
193
document,
just
because
it
provides
a
nice
overview
of
the
full
operating
system
and
it's
a
bit
generic.
So
it
covers.
You
know
like
if
this
was
using
open,
titan
or
you
know
something
else
for
the
security
board
like
like
nitro
for
aws
or
tpm.
D
And
goes
up
the
stack,
and
so
you
might
have
different
attestation
sets,
and
so
you
know
so
you
might
have
the
riv
one
from
the
ccg
and
then
you
might
have
one
on
the
operating
system.
D
And
so
what
this
draft
does
is
it
establishes
that
as
a
pattern
to
get
people
to
think
about
you
know?
How
do
we
do
this
at
scale
and
how
do
we
look
at
remote
attestation-
and
you
know
I'm
just
trying
to
to
do
this
before
we
get
too
far
down
this
path?
So
people
could
start
thinking
in
this
way
and
and
maybe
even
make
an
improvement
upon.
D
You
know
what
I've
suggested
and
with
that
you
know,
I
think
we're
going
to
need
to
define
some
claims,
and
I
you
know
I
put
together
an
early
table
just
to
suggest
some
ideas
and
I'm
hoping
with
collaboration.
We
can
build
that
out
and
make
this
something
very
useful
and
make
it
so
that
we
can
get
to
that
easy
button
for
customers
or,
for
you
know,
all
organizations
of
all
sizes
really.
H
H
Okay,
I
had
a
question
about
attesting
to
configuration
states
and
just
in
my
experience
with
s-cap,
I
know
the
amount
of
information
they
collect
is
huge
and
I'm
not
certain
how
that
would
work
in
an
attestation
environment.
Unless
you
were
thinking
maybe
of
having
a
like
a
on
the
box
comparison
to
policy,
and
then
you
you
get,
you
attest
to
either.
Yes,
you
conform
to
the
policy
or
know
you're,
not
conforming.
D
I
there
has
been
some
testing
of
this
and
it
may
just
be
a
yes
or
no,
but
you
know
I
I
I
want
to
figure
out
how
we
can
do
this
at
scale,
and
you
know,
while
s-cap
serves
a
purpose,
it's
it's
not
accessible
to
everyone.
So,
oh
yeah!
This
is
an
effort
to
think
about
how
do
we?
How
do
we
go
forward
and
improve
things?
So
if
I
got
some
details
wrong
and
something
should
be
remote.
H
D
H
I
Can
you
hear
me
okay?
Yes,
so
I
just
want
to
reply
to
jessica.
I
think
there's
at
least
two
different
categories
of
policy
settings.
One
type
of
setting
is
things
that
might
show
up
directly
in
claims
an
example
of
that
would
be
in
eat.
There's
your
debug
posture
and
some
variate.
Some
types
of
debug
posture
are
configuration
right,
they're,
not
just
hardware
settings,
otherwise,
hardware
settings
right,
so
some
might
appear
directly
in
claims.
I
Okay,
there's
another
category
of
things
that
if
all
of
your
configuration
for
a
particular
category
of
stuff
is
in
a
config
file,
then
you
could
do
something
like
just
sending
the
hash
of
the
file
and
if
for
hash
matches,
you
know
that
all
those
settings
are
at
the
latest
version
of
that
of
those
configuration
settings.
So
you
could
say
all
my
configuration
settings
for
category
foo
is
in
one
claim,
with
a
hash
value
in
it
and
that's
sufficient
and
remediation
is
just
pushing
out
the
new
policy
file
yeah.
H
I
H
I
H
D
Yep,
that
makes
sense,
so
I
think
what
we
could
start
is
by
adding
in
a
section
you
know
that
talks
about
this,
that
you
know
using
a
hash
to
dave's
point
and
then
leave
this
as
an
open
question
to
work
through
and
figure
out
what
options
do
we
have,
and
how
can
we
do
this
in
a
way
that
scales
to
justice
point?
So
thank
you.
I
appreciate
the
feedback.
J
Guy
hi
kathleen.
I
wondered
if
you
have
looked
at
how
this
idea,
intersects
with
with
some
of
the
material
in
eric's,
trusted
path.
Routing
document,
I
know
the
title
would
imply
that
eric's
document
is
about
is
about
routing,
but
it
actually
includes
a
proposal
for
the
his
so-called
trust
vector.
D
J
J
Eric's
suggestion
is
that
you
know
not
that
this
is
wired
into
spec
language,
but
that
the
vendor
is
likely
to
be
able
to
do
the
best
job
of
a
testing,
a
particular
vendor's
device.
J
J
D
Okay,
so
I'll
have
to
take
a
look.
It
might
make
sense
to
merge
these
ideas.
You
know
I
I
would
have
to
see
a
title
change
too
because
of
all
of
the
assumptions
we
made
and
then
also
your
focus
just
on
devices.
D
So
people
with
you
know
who
are
doing
client
and
server
systems,
wouldn't
necessarily
go
to
a
document
focused
on
devices
and
think
it's
appropriate
for
them
right.
So
I
think
that's
what
led
me
to
believe.
D
It
would
be
a
good
idea
to
present
this,
and
even
if
this
doesn't
go
forward
as
a
draft
I'd
like
the
idea
to
go
forward
and
then
have
you
know,
have
having
had
the
opportunity
to
present
it
to
just
get
this
thought
put
forward
for
client
systems
and
servers,
and
not
just
the
device
focus
right,
and
I
think
some
of
that
is
devices
are
a
little
simpler.
So
we're
seeing
more
work
come
forward
with
attestation
on
devices
and
and
looking
at
you
know,
how
do
you
secure
the
entire
device?
D
C
Eric,
yes,
I'm
very
happy
to
see
your
draft.
I
read
it
and
I
had
the
same
thought:
guy
did
the
trustworthiness
vector
does
apply
also
to
systems.
The
goal
is
to
have
independent
of
routers,
just
a
statement
of
claims
that
could
be
made
about
conclusions
out
of
the
attestation
results
and
sort
of
summarize
them
happy
to
talk
with
you
and
others
offline,
because
we
have
been
thinking
about
turning
them
into
eat
claims
as
well.
So
we
can
chat
about
that
when
you're
ready.
D
Okay,
great
and
then
this
would
also
consider
levels.
So
you
might,
if
you
look
at,
let's
say
the
cis
controls.
D
You
might
only
attest
to
the
implementation
group
1,
where
you
get
85
risk
reduction
or
you
might
attest
to
implementation
group
2,
which
improves
your
risk
reduction
or
implementation
group.
Three,
if
you're
looking
for
you,
know
a
really
secure
system.
C
Yep
the
goal
I
hope
is
to
ensure
that
we
have
a
set
of
claims
that
can
be
defined
per
device
and
then
or
per
system
and
you'll
know
what
types
of
claims
are
allowable
for
that
system
type
and
what
the
valid
values
would
be
for
that
system
type.
So
you
have
standardized
claims
and
then
you'd
be
able
to
say
for
this
type
of
system.
This
is
the
kind
of
expected
values
that
which
might
be
allowed.
D
Okay,
so
we'll
have
to
look
at
this
and
also
consider
the
differences
between
devices
and
systems
and
figure
out.
If
that
means
the
same
draft
or
if
it
means
you
know
with
just
separate
sections
or
if
it's
too
complex
and
and
just
because
devices
and
systems
are
so
different,
you
know,
does
it
mean
two
drafts
and
and
I'm
open
to
whatever.
C
D
B
Thank
you,
so
rats
architecture
is
up
next
dave.
Are
you
there.
I
All
right,
I
do
have
an
update
on
one
slide,
which
will
appear
in
the
proceedings,
but
I'm
just
going
to
talk
to
it
verbally
when
I
get
there,
which
is
feedback
from
michael
michael,
is
actually,
I
think,
presenting
in
another
session
right
now,
so
I'm
presenting
this
one.
This
is
a
discussion
on
draft
10
of
the
architecture
document
next
slide.
I
So
we
had
working
group
last
call
that
was
started
after
iota
ietf
109,
and
we
had
a
bunch
of
reviews
from
eric
and
guy
and
thomas
and
probably
some
others,
I'm
forgetting
and
all
of
those
comments
were
addressed
in
10..
Kathleen
moriarty
did
a
document
shepard
review
just
after
the
document
deadlines.
So
kathleen's
comments
are
not
gone
as
fun.
I
This
meeting
we
have
a
github
repo
if
you're,
new
and
we've
had
roughly
weekly
design
team
meetings,
although
like
holidays
off,
but
I
had
roughly
weekly
design
team
meetings
never
sent
f109
and
we
had
a
large
number
of
github
issues
and
I'm
happy
to
report
that
we've
had
71
github
issues
closed
since
the
last
meeting,
and
so
the
only
ones
left
is
the
one
that
is
kathleen's
new
feedback.
And
so
we
made
lots
of
great
progress
in
the
weekly
meetings
since
last.
Iatf
next
slide.
I
Now
here's
a
summary
of
of
the
things
that
change
there's
many
editorial,
I'm
not
going
to
go
through,
but
those
were
non-technical
changes,
but
significant
number
of
editorial
improvements
to
clarify
what
was
meant
along
and
and
or
things
better
and
so
on.
One
structural
change
that
you
might
immediately
notice.
If
you
try
to
do
a
diff
between
07,
which
is
the
draft
as
it
appeared
at
109
and
10.
I
The
current
one
is
that
the
use
cases
move
before
the
terminology
section,
and
this
was
in
response
to
some
reviews
that
I
think
hank
solicited
in
terms
of
what
was
readable
and
understandable
by
people
that
had
not
been
involved
in
the
rat
stuff,
and
so
the
use
cases
now
try
not
to
use
the
terminology
as
much
as
possible
and
just
use
layman's
speak
and
then
the
terminology
comes
in
after
that
and
covers.
I
You
know
the
the
rest
of
the
architecture
using
the
terminology,
so
that
was
a
structural
change
in
response
to
actually
usability
or
readability
reviews.
One
of
the
technical
addition
additions
had
to
do
with
more
exposition
of
reference
values
and
reference
value
providers
right.
So
back
yet
before
ietf109
we'd
already
introduced
the
distinction
between
an
endorser
and
a
reference
value
provider,
that
distinction
may
or
may
not
exist
in
an
actual
implementation,
meaning
those
could
be
combined
into
one
implementation
or
could
be
two
separate
implementations
or
even
two
separate
services
you
might
subscribe
to.
I
I
If
you
were
to
look
in
there
between
ned
and
me-
and
the
summary
is
that
this
has
to
do
in
the
layered
attestation
section
where
it
it
previously
incorrectly
showed
that
you
had
a
an
endorser
for
every
layer
in
a
layered
attestation
and
the
pull
request
tries
to
fix
that
to
say:
okay,
only
the
hardware
needs
an
endorser,
but
all
the
layers
in
a
layered
attestation
may
need
reference
values
in
order
to
appraise
them,
and
so
you
may
have
a
reference
value
provider
or
at
least
a
set
of
reference
values
per
layer,
but
really
only
an
endorser.
I
I
and
then
the
other
thing
that's
actually
the
majority
of
the
diffs
between
7
and
10
is
the
expanded
freshness
section
and
the
details
of
the
handles
approach,
which
started
to
appear
before
109,
but
a
lot
more
information
was
added
between
between
draft
07
and
now.
So
that's
what
I
want
to
spend
some
time
on
on
one
slide.
So
next
slide,
and
so
this
is
actually
most
of
my
presentation
here.
Is
this
slide?
I
I
think
I've
only
got
maybe
one
more
after
this,
so
for
freshness,
there's
really
three
styles
of
approach
and
again
rats
does
not
constrain,
which
protocol
that
you're,
using
or
even
which
style
you're
using
for
freshness,
and
so
we
say
when
you're
going
to
use
something
in
the
rat's
architecture,
you're
going
to
have
some
protocol
and
it's
going
to
have
some
mechanism
all
right
and
there's
some.
You
know
reference
interaction
models
that
we
have
in
other
documents
and
so
on.
I
So,
let's
walk
through
what
the
trade-offs
are
and
the
primary
additions
are
in
that
third
category
at
the
bottom
here
under
handles,
but
it's
useful
to
compare
against
the
other
two.
So
let's
walk
through
them
here,
as
you
can
do
that
comparison.
The
first
approach
is
to
use
synchronized,
clocks
and
so
freshness.
How
do
you
know
that
something
hasn't
been
replayed?
How
do
you
know
that
the
evidence
is
something
that
was
generated
fairly
recently
and
not
you
know
three
weeks
ago,
under
a
different
boot
cycle
or
whatever
so
where
things
have
changed.
So
how
does?
I
How
does
the
the
entity
appraising
evidence
or
the
entity
appraising
attestation
results?
No
that
evidence
or
attestation
is
results
are
fresh
okay,
so
the
first
one
is
synchronized
clocks,
okay
and
so
of
course,
that
means
that
you'd
have
to
have
clocks
right
where
some
iot
devices
may
not
even
have
clocks.
If
you're
a
sensor
mode,
you
have
to
have
some
means
of
synchronizing
them
that
secure
something
like
ntp
set,
for
example,
could
be
other
variations
based
on
other
layers
and
things,
but
that's
one
example
that
ietf
folks
might
be
familiar
with.
I
You
have
to
have
some
time
source
to
synchronize.
To
that
you
actually
trust,
so
you
have
a
dependency
on
some
other
party
and
then
finally,
you
need
to
have
typically
additional
claims
about
your
time.
Sync
in
your
evidence
like
you
need
to
be
able
to
claim
that
you
actually
got
them
from
a
particular
time
source
that
the
relying
party
or
the
receiver
of
that
evidence
that
verifier
might
trust
okay,
and
so
you
might
have
to
have
additional
claims
that
are
in
there.
So
your
set
of
claims
gets
slightly
bigger.
I
Okay,
then
not
having
synchronized
clocks.
Second
category
is
to
use
nonces.
Well
here
a
disadvantage.
Is
you
need
an
extra
round
trip
to
acquire
the
knowledge,
because
you
can't
generate
the
evidence
or
you
can't
generate
the
attestation
results
without
having
the
non-stick
in
it
right?
So
you
need
this
extra
round
trips.
There
might
be
higher
latency.
I
Okay,
if
you
generate
a
knowledge,
you
actually
have
to
store
that
nonce
so
that
when
the
evidence
of
the
or
the
attestation
results
arrives
to
see,
if
it
has
the
not
so
you've
got
a
state
requirement
for
every
attestation,
you
have
to
generate
a
nonce
and
store
it
for
some
period
of
time.
That
might
be
significant
in
some
in
some
use
cases,
and
so
there's
a
the
highest
state
requirement
is
here
and
the
highest
latency
requirement
is
here.
I
You
also
need
some
mechanism
on
the
nonce
generator,
such
as
a
local
clock,
but
only
on
whoever
generates
the
nonce
to
expire.
The
nonsense!
How
do
you
know
if
that
nonsense,
stale
right?
If
you
need
to
have
to
say
that
that
it's
fresh
within
a
particular
period
of
time
you
got
to
expire?
I
The
knots
right,
the
person
that
uses
the
knots
to
sign
stuff
and
includes
it
in
there
doesn't
need
a
clock,
but
whoever
generates
the
nonce
needs
a
way
to
expire
them
and
then,
finally,
if
you
in
some
cases,
you
might
need
the
ability
to
distinguish
the
age
of
a
claim
value
from
the
age
of
the
claim
in
the
message.
So,
for
example,
if
you
had
a,
I
don't
know
a
gps
location
that
was
acquired
on
boot
and
then
you
signed
the
evidence.
You
know
three
days
later
right.
I
Is
that
still
valid
because
there's
a
distinction
between
when
the
evidence
was
generated
at
attestation
time
and
when
the
gps
or
when
the
claim
value
was
first
measured
and
then
cached
or
something
like
that.
And
so,
if
you
need
to
know
the
difference,
then
you
need
to
design
some
way
to
distinguish
that,
because
you
can't
just
put
a
timestamp
in
there,
and
so
we
talk
about
exact
an
example
of
how
you
might
do
this
in
the
in
the
appendix
and
then
the
third
category
is
the
one.
I
That's
really
fleshed
out
contrast
with
the
other
two
there
handles
like
the
first
one.
We
need
some
third
party
to
synchronize
time
source
to
here.
You
need
some
third
party
to
distribute
the
handles.
Now
I
say
third
party,
but
in
theory
the
third
party
could
actually
be
combined
with
one
of
their
parties.
Just
like
your
trusted
time,
source
could,
in
theory,
be
combined
into
the
same
device
as
one
of
the
other
ones.
I
So
here
the
handle
distributor
needs
a
clock
because
it
has
to
send
them
periodically,
and
so
it
has
to
know
how
to
figure
out
a
period
right,
but
the
receivers
don't
have
to
have
clocks,
they
don't
have
to
have
state
like
nonces
and
stuff,
and
so
this
one
has
a
lot
of
nice
properties
compared
to
the
other
two,
because
the
disadvantages
aren't
there,
but
and
I'll
talk
about
secure
in
just
a
second,
because
that's
the
the
one
elaboration
point,
and
but
you
also
need
to
deal
with
some
mechanism
to
deal
with
the
loss
of
the
hanger
distributor
availability
right
because
you
don't
have.
I
If
you
don't
have
a
local
clock,
how
do
you
know
that
the
handle
distributor
is
still
reachable?
If
you
you
just
haven't
gotten
something
from
them?
Yet
how
do
you
know
whether
they're
still
there?
So
you
need
to
design
some
way
to
do
that?
So
let
me
say
what
the
elaboration
is.
It
would
appear
in
the
slides
the
proceedings-
it's
not
on
here.
So
first
point
michael
wanted
me
to
clarify
what
we
mean
by
a
secure
means
of
distributing
them,
because
we
do
spend
some
time
in
the
security
considerations
section
talking
about
this.
I
So
integrity
is
obviously
important
that
the
the
handle
is
the
correct
handle
that
the
origin
is
authenticated,
so
you
know
that
they
came
from
the
correct
handle
distributor
and
because
what
happens
here
is
the
handle
distributor
sends
the
same
handle
to
both
entities.
You
know
the
sender
and
receiver
of
the
evidence.
The
sender
of
the
evidence
includes
the
handle
and
they
receive
their
evidence,
checks
it
against
the
handle.
It
got
right
so
the
handles
work,
so
it
can't
be
spoofed
and
the
harder
part
is
it
can't
be.
I
It
can't
be
replayed
okay,
so
you
might
have
to
have
a
mechanism
that
distributes
them
that
takes
care
of
replay
protection,
but
the
one
thing
that
you
can't
easily
defend
against.
Unless
you
start
adding
additional
things
like
local
clocks
and
things
is
how
do
you
deal
with
delay
attacks?
And
so
let's
say
that
you
could
somehow
introduce
a
large
delay
between
the
handle,
distributor
and
the
handle
receivers.
I
Then
you
could
expand
the
freshness
window.
You
know
the
window
of
a
set
of
how
old
can
things
be
to
to
whatever
value
that
you
wanted,
and
so
you
could
do
replay
attacks
within
that.
If
you
could
do
delays
of
handles
on
both
sides,
and
so
you'd
have
to
have
and
design
some
way
of
dealing
with
that
that
we
don't
say
how
you
do
that,
but
you
could
potentially
do
it
with
local
clocks.
I
saw
brendan
jumped
in
queue
and
then
jumped
out.
L
About
to
put
it
on
the
chat
but
I'll
ask
anyway,
so
our
handles
ps
case,
because
that
that's
the
only
way
that
this
makes
sense
to
me.
So
I'm
just
curious
as
to
how
this
works.
I
You
can
think
of
it
as
a
psk.
Yes,
I
think
the
term
handle
I
think
came
from
hank,
and
so
I
don't
know
if
hank
wants
to
answer,
but
it
is
a
unpredictable
value
that
is
known
to
both
parties
and
to
most
people
that
is
synonymous
with
psk.
So.
A
Yeah,
okay,
but
maybe
I
can
answer
a
little
bit
of
about
tennis's
question
instead,
so
he's
asking
relative
time
or
absolute
time,
this
depends
on
the
on
the
provider.
You
typically
want
to
have
a
tie
into
a
global
time.
If
you
do
a
relative
time,
you
create
your
own
epochs
starting
by
zero
and
have
not
a
global
time
scale
here
in
theory,
that
is
possible
in
a
limited
domain.
Practically.
A
What
we
have
encountered
today
in
implementation
is
a
tie
ends
with
a
global
time
scale,
but
I
could
see
something
built
on
relative
time.
Only
in
a
certain
domain,
then
you
have
to
take
care
of
synchronizing
your
whole
domain
and
you
will
never
have
a
help
from
a
universal
time
scale
like
utc,
global.
I
Yeah
in
general,
the
only
category
that
requires
absolute
time
is
typically
the
synchronized
clocks,
one
unless
you're
trying
to
use
it
for
you
know
logs
or
something
like
that,
then
you
might
want
synchronized
clocks
anyway,
all
right
thanks,
hank
russ,
I
guess
you're
in
queue.
Next.
M
Hi
I
have
a
real
problem
with
the
name
handle
there
is
the
handle
system
from
you
know,
bobcon
fame
that
the
iatf
really
did
not
want
to
turn
into
a
standard.
So
there's
an
informational,
rc
3650.
I
think-
and
you
know
dois
and
things
like
that
are
all
based
on
it.
I
think
we
can
avoid
the
name
collision.
I
M
I
M
A
Yeah,
just
only
quickly
why
I
see
names
conflict
with
handles.
I
also
need
inconsistency
with
a
secret
that
is
not
secret,
so
psk
yeah
well,
it
is
distributed
as
such,
but
it
is
not
secret
necessarily
so
therefore
intrinsically
something
different
potentially,
but
we
can
do
the
name
roulette
offline.
I
So
one
of
the
questions
that
michael
had
asked
and
is
are:
do
you
actually
need
confidentiality
with
handles?
Okay,
and
the
document
right
now
does
not
say
that
you
need
confidentiality.
I
I
have
not
thought
of
any
reason
why
you
need
confidentiality,
and
I
think
one
of
hank's
original
use
cases
was
the
handles,
are
actually
broadcast
to
everybody
right.
You
can't
predict
them
until
the
time
until
the
epic
comes
so
they're
unpredictable,
but
what
once
you're
in
that
epic,
if
they're
public,
that's
okay
as
far
as
we
know
so,
confidentiality
is
not
needed,
and
that's
why
probably
the
term
secret
is
not
is
not
required
here.
All
that's
needed
is
that
you
can't
predict
it
until
the
epic
comes.
L
I
A
And
there
might
be
some
other
opaque
content
in
that
that
could
handle
for
now
that's
more
than
an
id.
I
Yeah,
but
by
the
way,
this
is
the
real
content
of
the
presentation.
It's
this
one
slide.
So
even
if
we
don't
get
past
this
slide,
then
we're
okay.
So
I
see
because
I
see
michael-
has
actually
made
it
to
this
meeting.
So
do
you
have
a
comment
in
this
michael.
K
Yeah,
I'm
just
I'm
not
actually
I'm
just
tied
into
like
three
or
four
meetings.
That's
my
problem,
so
I
I'm
actually
not
even
convinced
that
the
epic
id
or
whatever
we're
gonna
call
it.
I'm
not
actually
convinced
that
we
have
a
way
of
of
the
recipient,
validating
the
the
integrity
of
it.
K
So
I
I
really
imagining
when
I
heard
about
handles
as
a
distinct
from
nonces,
I
was
really
imagining
something
like
you
know:
yeah
a
gps
satellite,
you
know,
tells
everybody
in
the
world
it
and
I
can't
see
how
we
would
validate
that
as
being
the
legitimate
gps
satellite,
except
that
if
you
use
the
wrong
one
from
the
wrong
guy,
I
guess
you
have
to
retry.
I
So
one
of
the
things
that's
in
the
draft
right
now,
michael,
is
that
you
require
origin
authentication
and
so,
whatever
your
distribution
mechanism,
whether
it's
broadcast
or
unicast
right,
has
to
be
signed
by
the
handle,
distributor
or
the
you
know,
epic
id
distributor.
If
you
want
to
use
that
term
right,
so
origin
authentication
is
required
and
integrity
is
required,
and
so,
if
it's
signed
with
his
key
for
example-
and
everybody
else,
has
the
public
key
of
that
handle
distributor,
then
you
have
integrity
and
anti-spoofing.
K
Okay,
I
mean
I,
I
think
I
understood
that
at
some
point
and-
and
I
I
guess,
I'm
looking
forward
to
an
implementation
draft
of
some
kind
to
explain
how
we
do
this
and
I
think,
there's
there's
there's
major.
K
How
do
devices
get
this
kind
of
thing,
given
that
they
may
not
yet
be
on
a
network
where
they
can
actually
download?
I
guess
a
public
key.
It's
got
to
be
to
validate
this,
although
I
could
imagine
some
symmetric
key
mechanism
like
s
key
or
I
guess
the
other
word
is
it's
a
not
merkle
tree,
but
there's
another
variation
of
that
where
you
like
hash
based
signatures.
I.
F
K
I
So
the
point
is
the
point
of
putting
this
that
all
three
in
the
document-
and
I
know
michael's
been
in
these
meetings,
but
this
is
partly
kind
of
a
panel
between
the
editors
here
between
michael
and
me
and
hank,
that
are
talking
to
just
share
our
thoughts
to
everybody
else
here
that
part
of
the
architecture
documents
point
is
to
share
that
there
are
these
three
styles
of
approach.
When
you're
designing
a
solution,
you
got
to
pick
one
or
more,
but
typically
one
and
flesh
it
out
and
say
how
it
works.
I
But
if
you're
going
to
design
something
to
work
with
attestation,
then
you
should
be
aware
that
there's
these
different
styles
of
approach
and
different
solutions
that
you
might
have
to
be
sort
of
agnostic
as
to
which
one
of
these
are
because
there's
different
tradeoffs
here,
right,
you're
trying
to
optimize
for
state
or
latency
or
minimize
dependencies
or
whatever.
You
pick
a
different
approach
here
in
any
particular
solution.
This
is
just
the
architecture,
not
the
solution
document,
so
yeah
everything.
K
You
said
michael
is
right
and
dave
I'll
I'll
just
add
for
the
rest
of
the
group.
K
So
in
the
six
dish
space
we
actually
have
a
beacon,
extendable
beacon
that
actually
would
handle
this
thing
very
well
and
even
has
pretty
all
the
properties
that
you
can
use
it
and
you
can
use
it
without
knowing
how
to
authenticate
it,
because
you
authenticate
it
later
afterwards,
when
you
succeeded
that
you
actually
succeeded
with
the
correct
thing,
but
you
kind
of
have
to
do
a
little
bit
of
a
leap
of
faith
initially
to
get
there,
but
then
you
validate
afterwards,
so
I
don't
think
it's
crazy
russ.
K
C
A
pointer
to
s
key
cool
one
thing
on
the
handle:
it
does
have
some
different
properties
than
nonces
if
you're
with
routers,
and
you
have
thousands
of
people
trying
to
connect
the
handle
scales,
a
lot
better
with
the
hardware.
And
then
I
wouldn't
say
that
they're
equivalent
in
terms
of
scalability.
I
Yeah,
that's
my
whole
point
that
nonsense
have
a
huge
stake
requirement
handles.
You
might
only
be
storing
one
or
typically,
two
potentially
three
but
normally
you'd
be
storing
two
handles
total,
not
doesn't
independent
of
the
number
of
people
that
you
talk
to
and
so
handle
skill
far
better
in
state
right
nonsense:
the
disadvantage
of
state
and
latency
synchronized
clocks
and
handles
at
disadvantages.
Relying
on
the
third
party
and
synchronized
clocks
disadvantages.
You
got
to
have
clocks
and
all
the
entities,
all
right.
I
That
looks
like
a
hint
from
ned
that
he
wants
me
to
move
on
so
brandon.
I
guess
you
get
the
last
comment
here,
but
well.
F
Good
yeah,
I
was
gonna
say,
given
that
we,
you
know,
have
25
minutes
of
the
open
mic.
I
was
letting
it
run.
Oh
okay,
all
right
cool!
Thank
you.
I
was
just
gonna.
Give
you
a
couple
more
minutes
all
right,
because
let
me
there
are
more
presentations.
Yeah
go.
I
Ahead,
let
me
spend
my
30
seconds
right
now
and
then
we
can
just
use
any
queue
time
for
it
for
for
until
you
want
to
cut
us
off.
So
the
30
seconds
on
this
one
was
all
of
our
normative
references
are
to
rfcs,
hey,
roman.
Nothing
is
depending
on
informative
references.
We
added
a
bunch
of
informative
references.
The
one
of
note
is
that
the
confidential
computing
consortium
has
a
deep
dive
white
paper
that
references,
our
architecture
document
and
our
architecture
document
references,
the
deep
dive
white
paper
in
the
use
cases
section.
I
So
it's
nice
that
we
have
parity
or
you
know,
symmetry
between
the
two
documents
that
the
two
organizations
are
in
sync.
Yes,
I
had
something
to
do
with
that:
full
disclosure.
I
chair,
the
technical
advisory
council
and
people
like
thomas
wassati
and
eric
voight
who've,
also
been
part
of
all.
The
weekly
design
meetings
are
also
part
of
the
ccc
discussions.
So
that's
my
30
seconds
all
right
now.
We
can
go
back
to
the
previous
slide
if
brennan
has
other
comments
so.
L
Yeah,
so
I'm
trying
to
understand
the
use
cases
for
handles
now.
In
particular,
I
know
you've
just
gone
through
the
trade-offs,
but
I
I
want
to
just
sort
of
take
a
step
back
for
a
moment.
Synchronized
clocks
versus
handles,
I
think,
are
probably
the
most
relevant
thing,
because
your
handles
as
near
as
I
can
tell
are
a
synchronized
clock.
It's
just
a
question
of
how
synchronized
and
how
precise
your
synchronization
is.
If
you're
distributing
handles.
I
I
It's
also
a
handles
are
also
less
precise
than
synchronized
clocks,
so
with
synchronized
clocks
you
can
say
I
have
a
reason
to
believe
that
the
evidence
is
exactly
you
know:
five
minutes
old,
plus
or
minus
the
drift
in
the
synchronized
clocks.
Right
as.
H
G
I
L
I
L
L
L
I
I
L
L
I
Completing
our
agenda,
thank
you,
brandon.
Let's
continue
this
discussion
and
I'm
sure
hank
has
views
because
the
handle
stuff
came
from
hank,
so
I
want
to
make
sure
hank
is
involved
in
these
discussions.
So
all
right
thanks
nancy.
A
Render
my
hair
gray
in
this
light,
so
hi
there's
the
thing
I'm
going
to
present
about
three
ids
we
have
here
in
reds.
Every
presentation
will
be
a
single
content
slide,
so
expect
this
to
be
a
discussion
or
a
time.
Saver,
mostly
so
first
slide
is
about
the
reference
interaction
models
id
that
was
adopted
by
the
working
group
last
after
last
meeting
next
slide.
Please.
A
I
won't
have
to
somehow
remove
most
too
many
messages.
They
clutter
the
desk
at
some
point,
so
yeah
there's
an
update
here
with
respect
to
I
can.
I
can
use
the
next
slide.
Thank
you
running
cold.
A
Could
you
please
thank
you?
What
I
was
about
to
say
was:
oh
yeah.
There
is
a
new
implementation
here
available
on
github
version.
I
don't
speak
french
very
well,
so
I
guess
that's
similar
to
a
verizon.
That's
the
color
of
grapes
during
the
ripening
from
green
to
red.
A
So
it's
it's
go,
implementations
and
other
items
there
on
that
repository.
It's
an
organization
actually
with
multiple
repositories
and
one
hackathon
demo,
which
provides
containers-
and
we
have
to
think
I
think
thomas
is
here
in
yorkish,
for
example,
arm
employees
who
are
doing
this.
So
thank
you
a
lot
for
for
hacking
at
this.
A
This
complements
basically
the
both
are
using
the
challenge
response
interaction
model
from
this
document
here
and
also
again,
there
was
feedback
coming
from
preliminary
implementation
from
that
domain,
so
to
speak,
and
we
got
a
few
good
results
here.
There
were
no
conceptual
issues
with
the
draft.
It
was
actually
helpful
during
implementation
as
the
middle
piece
of
the
abstract
thing.
That's
the
architecture
and
well
the
the
implementation
itself.
So
so
it's
a
good
middle
ground
as
we
intended
it
to
be.
A
There
are
now
20
as
a
working
group
item.
There
are
now
20
open,
github
issues
thanks
for
way
for
them.
This
is
a
barrage
of
super
useful
points
to
talk
about.
Some
of
them
actually
not
easy
to
reply
ad
hoc.
So
please
have
a
look
at
this,
and
this
oil
tends
to
somehow
prepare
for
working
group
call,
of
course,
so
as
the
conceptual
parts
are
relatively
stable,
I
think
from
what
feedback
we
already
got.
A
These
are
mostly
editorial
or
if
it's
just
confusing
content-
and
the
question
is,
does
that
belong
to
this
document?
So
please
have
a
check
for
the
issues,
and
reviews
of
the
whole
document
are
of
course
welcome.
I
know
that
there
had
to
be
some
privatization
here
before
itf
and
other
ids
one
here
in
this
group,
so
maybe
in
the
next
round
there
will
be
room
for
this
id
and
yeah.
That's
basically
my
report.
If
there
are
any
questions
about
this,
I
will
wait
a
few
secs.
A
Otherwise,
we
can
move
on
to
the
next
presentation,
which
is
toda,
so
you
heard
you
probably
in
the
past
meetings
and
sessions
and
interests,
you've
heard
two
dimensions
as
a
reference.
Tuda
is
an
implementation
as
a
specification
of
story
and
an
implementation
with
respect
to
the
unidirectional
remote
attestation,
as
depicted
as
one
of
the
interaction
models
and
the
previous
id
next
slide.
Please.
A
And
the
latest
updates
to
this
id
includes
alignment
with
the
maturing
documents
here
in
this
working
group,
primarily
the
architecture,
riv
and,
of
course,
the
interaction
model.
It's
now
all
aligned,
all
terminology
was
thrown
out.
Actually
there
was
some
really
really
old
terminology
in
the
let's
say
last
third
of
the
id
that
was
not
touched
recently.
A
There
are
two
major
open
questions.
We
provide
a
exemplary
interface
reference
interface
for
a
tpm
1.2,
that's
an
old
thing,
but
it's
deployed
in
millions
of
devices.
Today,
still
so
we
are
considering.
Maybe
opening
up
the
questions.
Do
we
want
to
keep
that
personally,
I'm
leaning
a
little
bit
towards
yeah,
because
people
need
it,
but
that
would
be
a
interesting
question
to
be
answered.
As
a
working
group
item,
then
again
we
have
two
types
of
reference
interfaces
here:
one
of
them
snmp,
thanks
to
iron
macdonald
and
a
yang
module.
A
Also
yang,
is
the
more
cool
kid
on
the
block
here
in
the
iitf.
So
second
question
would
be:
do
we
need
snmp
again
personally,
I
have
a
slight
preference
towards
including
both,
but
this
could
also
be
another
item
for
working
group
discussion.
So,
as
the
content
seems
rather
complete,
and
it
just
has
to
be
pruned
more
and
put
into
shape
for
an
isd
process
here,
I
would
like
to
ask
or
formally
request
basically
the
chairs
to
do
a
working
group.
A
Adoption
call-
maybe
if
that's
even
I
think
the
item
is
okay
and
and
then
we
can
go
from
there,
maybe
as
a
working
group
adopted
item
now.
So
that's
this
slide
here.
Any
questions
or
feedback
on
that.
A
F
Well,
I
suppose
we
can
run
a
quick
poll
to
see
how
many
people
have
read
the
draft.
So
let
me
put
on
the
poll,
have
you
read
this
draft?
F
I
F
I
don't
know
if
I
can
edit
the
poll
now.
I
can
start
a
new
one.
F
F
I
see
four
people
have
raised
their
hands.
17
did
not
read
the
draft
explicitly
said
they.
They
didn't
raise
their
hands.
I
guess
of
the
four
people
who
raised
their
hands.
F
I
should
have
clarified
the
question
of
the
four
people,
since
there
were
only
four
that
raised
their
hands.
I'm
presuming
the
four
were
not
one
of
the
authors.
F
F
Okay,
I'd
like
to
get
a
couple
more
people
to
read
the
draft.
What
we
can
do
is
take
it
on
the
list
and
see
if.
F
Let's
see
what
honestly
said
so,
let
let's
take
it
up
to
the
list
and
see
if
we
can
get
a
couple
more
people
and
get
discussions
going
so
that
we
can
make
the
call
for
adoption.
A
A
So
this
might
be
the
item
that
is,
this
might
be
the
item.
That
is
a
little
bit
more
to
the
discussion
point
here
for
today,
hastily
prepared
this
the
slide
deck
it
is
about.
The
claim
sets
that
we
fleshed
out
based
on
the
working
items
in
the
suit
working
group,
which
are
the
manifest
and
corresponding
architecture
and
information
model.
A
So
the
the
fundamental
idea
here
is
that
software
updates
to
the
internet
things
are
vital
to
the
trustworthiness
of
things
and
might
be.
Services
might
be
devices
and
all
the
things,
and
so
there
are
now.
This
idea
includes,
I
think,
a
very
a
proficient
set
of
claims
derived
from
these
booting
devices,
with
new
or
old
firmware
components
and
then
reporting
also
about
the
update
procedures
during
runtime
before
a
reboot
and
a
boot
of
a
new
firm
was
conducted.
A
There
were
some
inconsistencies
here
on
the
zero
zero.
As
it
sometimes
happens.
These
are
fixed
now
brandon
and
I
are
relatively
confident
that
the
naming
and
the
descriptions
of
all
claims
are
quite
okay
right
now.
That
said,
the
some
of
the
items
described
here
in
the
claims
set
for
attestation
results
and
evidence
for
reds
will
become
a
new
id
in
the
suits
working
group,
because
the
actual
manifest
that
steers
and
executes
the
update
and
the
resulting
report
will
be
separated.
A
The
reports
will
become
a
new
standalone
id
just
as
an
fyi.
So
not
all
of
this
will
be
in
the
items
that
are
recently
and
will
at
the
moment
be
moved
to
the
isg.
A
We
also
have
realized
and
came
to
the
understanding
the
course
of
the
last
half
year
that
the
claims
here
are
very,
very
fitted
to
fit
into
the
same
scope
as
the
trustworthiness
vectors
that
are
defined
in
the
trustworthy
path,
routing
id
from
eric.
So
we
were
talking
about
that
and
and
like
like
designing
and
modeling
how
this
fits
for.
Quite
a
while.
Now
and
now,
the
authors
decided
of
both
drafts
decided
that
we
will
create
and
break
out
a
certain
id
that
is
new.
A
That
will
only
encompass
the
trustworthiness,
vectors
and
those
corresponding
claims,
as
described
in
the
trustee
path
routing
id
today,
and
we
will
bucket
the
suit
claims
also
into
that
draft,
which
probably
means
that
we
will
abandon
this
claims
draft,
as
it
is
right
now
and
we
will
recombine
it
into
an
information
model
about
claims
for
trustworthiness
about
trustworthy
can
be
used
primarily
in
attestation
results,
but
also
in
evidence.
We
think,
depending
on
the
refinement
of
events
created
by
the
tester.
A
So
we
assume
that,
on
both
sets
of
conceptual
messages,
these
claims
could
be
it
could
be
appearing
or
could
be
used
in
and
well.
Our
plan
is
well
after
fleshing
out
the
content
today
to
start
a
new
and
and
increase
the
scope
here,
a
little
bit.
A
This
addresses,
I
think,
some
of
the
questions
raised
by
kathleen
very
early
on
about
this
could
be
just
device.
Centric
people
might
not
be
looking
at
this.
I
accidentally
share
the
same
sentiment
and
so
but
from
I
guess,
a
different
point
of
view
at
a
different
angle,
but
I
think
maybe
we
are
converging
towards
a
a
two
draft
system
here.
One
is
the
the
sets
and
then
the
usage
of
the
sets,
and
one
is
the
claims
set
that
will
be
made
use
of
inside
of
these
sets.
A
This
might
make
a
lot
of
sense.
Maybe
not
a
little
bit
of
more
discussion
might
be
interesting
here,
but
I'm
relatively
optimistic
that
this
is
the
right
way
to
go
so
for
now
and
now
our
next
step
is
to
to
combine
the
portions
of
the
trp
id
and
the
claims
id
for
suit
into
a
new
iim
and
lets
go
from
there.
So
are
there
any
comments
and
or
questions
about
this.
N
N
Yeah
hi
yeah,
can
you
hear
me
yeah?
We
can
hear
you
so
I
was
looking
to
draft
real,
quick
and
I
trying
to
understand
the
relationship
to
like
eat.
Cwt
or
jwd.
I
mean
it
seems
like
you
can't
just
or
it
doesn't
doesn't
seem
right
to
define
claims
in
a
in
a
vacuum
without
kind
of
saying
what
the
framework
for
conveying
the
claims
are.
So
is
this
intended
to
be
cwt
claims
gw
jwt
claims
eat
claims.
A
I
think
that
eat
is
a
very
direct
candidate
for
a
actual
representation
of
these
claims
to
instantiate
them
in
a
format
conveyed
via
protocol.
They
we
are
calling
them
claims
already
adhering
to
the
architecture
and
therefore
also
to
the
eat
terminology.
A
And
yes,
I
think
we
could
highlight
at
the
very
early
beginning
of
the
new
idea
that
we
are
planning
here,
that
these
can
be,
for
example,
instantiated
by
an
eat.
That's
absolutely,
I
think,
in
scope.
Luckily,
because
both
conceptual
messages,
evidence
and
attestation
results
are
in
scope
of
the
current
charter
and
therefore
also
are
covered
by
eat.
I
think
maybe
eid
is
more
on
the
evidence
side,
but
that
is
something
we
could
flesh
out
along
the
way
how
eat
and
attestation
results
relates.
N
A
No,
I
don't
think
it's
necessary.
This
is
basically
about
the
assessment
of
the
the
the
item
in
hand
as
also
basically
it's
it's,
the
attestation
result
set.
So
initially
we
thought
it's
actually
not
the
core
scope
of
each
first
of
all,
but
also
then
in
the
past,
like
four
months,
we
realized
some
of
these
could
be
directly
created
as
evidence
claims
by
a
tester,
so
they
could
fall
in
the
scope
of
each
and
then
for
now
our
working
thesis
says
yeah.
A
A
Without
a
tie
into
a
format
we
can,
we
could
extend
the
information
model
part
and
it's
a
little
bit
data
model-esque
in
it
at
the
moment,
but
we
could
tie
into
that.
I
actually
included
cdda
that
is
based
on
the
each
id.
So
I
think
the
the
threshold
of
saying
somehow
this
is
this-
can
be
used
by
each
is
very
low.
N
And
then
we
will
be
putting
text
into
eat.
That
says
it
can
be
used
for
attestation
results.
A
Yeah-
and
we
have
to
really
think
a
little
bit
about
that-
I
think
that
is
fine,
but
we
also
have
to
make
clear.
Do
we
really
want
that?
So
that
is
another
decision
made
lightly?
I
think,
but
I
also
I'm
optimistic
that
we
will
find
a
good
way
to
phrase
this.
I
I
The
cheap
protocol
has
a
normative
dependency
currently
on
having
the
claims
that
are
in
the
draft
that
I
just
mentioned,
which
I
assume
is
the
one
that
hank
is
referring
to,
in
which
case
yes,
what's
blocking,
the
implementation
is
actually
getting
values
assigned
in
for
using
your
teeth,
needs
to
use
it
neat
so
to
lawrence's
comment.
Teep
is
expecting
those
claims
to
appear
in
eats
and
it
needs
values
assigned
sooner
than
later,
and
so
we
hope
that
the
rats
working
group
will
do
something
with
this
to
unblock
repeat
thanks.
A
Okay,
thank
you
for
that
input,
so
yeah.
We
will
not
rush
this,
but
we
will
expedite
a
clear
statement
how
claims
in
it
could
look
like
if
you
are
really
have
a
hard
dependency
here.
I
When
I
got
when
I
present
the
tea
protocol
in
the
teach
session
I'll
talk
about
teeps
use,
so
if
anybody
also
wants
to
discuss
this
more,
we
have
a
little
bit
of
time
in
teeth.
O
Can
you
hear
me?
Yes,
we
can
good
okay,
so
I'd
like
to
talk
about
uccs.
So
if
we
can
move
on
to
the
next
slide.
O
So
the
use
case
for
uccs
is
the
is
to
convey
a
token,
typically
an
eat
or
something
like
it
over
a
secure
channel
that
already
authenticates
both
endpoints
and
provides
integrity,
protection
and
may
optionally
provide
confidentiality.
O
The
essential
idea
behind
this
is
that
in
many
use
cases,
if
you
already
have
a
secure
channel,
the
battery
overhead
or
the
radio
bandwidth
overhead
of
further
signing
and
or
encrypting
in
the
cose
form,
is
essentially
unnecessary
from
a
security
perspective.
So
in
this
case
we
are
assuming
that
the
two
endpoints,
the
tester
and
the
verifier
are
trusted
in
some
sense,
so
examples
might
be
a
te
conveying
attestation
evidence
to
a
service
provider
using
tls
or
a
global
platform,
secure
element
using
scp-03
or
scp-11.
O
These
are
secure
channel
protocols
that
provide
essentially
provide
authentication
and
integrity
protection
and
usually
also
confidentiality.
We
can
also
consider
that
jwt
already
supports
the
algorithm.
None
from
the
perspective
of
security.
We
have
limitations
that
we
like
to
discuss
and
that
are
discussed
in
more
detail
in
the
draft,
but
essentially
the
security
properties
of
attestation.
Evidence
are
only
guaranteed
when
they're
within
the
secure
channel.
O
So
can
we
so
the
document
was
published
in
a
zero
one
and
zero.
Two
draft.
Most
of
the
comments
were
made
on
the
zero
two
draft.
So
if
we
move
to
the
next
slide,
I've
tried
to
go
quickly
through
the
comments
that
we've
received
and
how
they
have
been
addressed.
O
So
the
comments
from
rus
most
the
the
must
requirements
have
been
rewritten
both
to
clarify
them
and
to
reduce
the
strength,
and
we
note
that
integrity
protection
is
only
provided
in
both
directions
where
confidentiality
is
needed,
from
jessica,
fitzgerald,
mckay
and
mike
jenkins.
We
had
essentially
four
comments,
three
of
which
have
been
addressed
and
one
which
was
the
comment
that
a
static
symmetric
key
can
only
authenticate
a
net,
not
an
entity.
O
I
haven't
been
able
to
come
up
with
a
a
good
answer
to
that
other
than
to
say
I
don't
think
it's
important
in
respect
of
of
of
this
specification.
It
applies
in
many
other
scenarios
where
cryptography
is
used
and
we
we
don't
address
quite
that
nuanced
distinction.
O
Others
seemed
to
agree
in
the
discussion
on
mailing
lists.
So
next
slide,
so
we
had
from
lawrence.
There
should
be
a
minimal
discussion
of
security
and
I'm
afraid
lawrence
that
the
coverage
in
draft
3,
which
hank
put
out,
I
think
yesterday,
is
actually
fairly
extensive,
largely
because
of
the
feedback
that
we
received
from
others.
O
So
we
can
move
on
to
the
next
slide,
and
this
is
really
the
the
the
meat
of
of
what
I'm
asking.
We
need
to
find
an
appropriate
working
group
for
uccs
draft
to
be
completed.
O
We
believe
that
it
is
in
scope,
because
the
main
use
case
that
is
driving
the
specification
arises
within
rats
and,
in
particular,
the
the
driver
for
creating
the
specification,
came
from
work
that
I
am
doing,
based
on
the
rat's
work
inside
global
platform,
and
that
I
am
doing
equally
in
insider
a
collaboration
that
involves
a
trusted
computing
group
and
so
that's
sort
of
from.
O
From
my
perspective,
it
seems
like
the
right
place
to
do
this
and
to
ensure
that
we
remain
aligned
with
with
rats
fully
in
terms
of
the
the
entire
model.
Other
proposals,
so
jessica,
proposed
kozai
jim
shad,
was
quite
strongly
opposed
to
that.
His
feeling
was
that
within
the
kosai
working
group,
the
correct
answer
to
uccs
would
be
you
should
use.
Kosai
ira
also
was
against
and
both
jim
and
ira
suggested
as
an
alternative
ace.
O
I
would,
as
I
say
myself
and
I
think
on
behalf
of
the
authors,
we
feel
that
rats
is
more
appropriate,
given
that
it
ties
very
specifically
to
work,
that's
being
done
in
other
bodies
based
on
the
open
standardization
work
that
rats
is
doing.
So
I
guess,
if
we
move
on
to
the
next
page,.
G
G
L
I
guess
that
makes
it
me.
We
considered
doing
something
very
similar
to
this
in
suit
and
we
eventually
got
a
security
review
which
told
us
that
this
was
a
bad
idea
for
suit,
and
I'm
just
gonna
give
you
the
the
the
sort
of
the
rundown
of
why
that
was.
I
I'm
not
exactly
sure
if
it
applies
equally
in
this
context,
so
the
concern
was
that
in
in
suit
specifically,
the
idea
was
that
a
a
document
that
describes
only
channel
information
could
be
authenticated
by
an
existing
secure
channel.
L
Not
anything
else.
So
things
like
signing
off
on
exact
firmware
content
wasn't
allowed,
but
exact,
but
just
channel
information
and
the
feedback
that
we
were
given
was
that
this
would
allow
an
attacker
that
successfully
compromises
the
channel
security
to
pivot
very
quickly
through
your
network
and
then
take
over
other
things,
because
it
would
allow
them
to
issue
requests
through
that
channel
and
so,
in
the
end,
we
actually
removed
that
because
it
removed
some
defense
in
depth
and
introduced
a
new
possibility
of
an
attacker
pivoting
rapidly.
L
And
so
I
I
guess
this
come
came
back
to
the
the
standard
cryptographic
doctrine
of
using
one
key
for
one
purpose,
so
I
I
guess
I
would
ask
you
to
consider
whether
that
applies
to
this
scenario
as
well.
O
So
we've
certainly
done
a
reasonable
amount
of
analysis
ourselves.
I
I
think
that
it's
something
that
is
perhaps
open
for
further
discussion
within
within
this
use
case,
because
it
is
for
the
conveyance
only
of
attestation
evidence.
O
I
think
there
is
a
a
question
as
to
what
the
as
to
what
an
attacker
could
do
if
they
took
control
of
the
secure
channel
other
than
to
tamper
with
the
attestation
evidence
itself.
I
think
that
any
any
any
attack
then
becomes
a
little
bit
second
order,
but
I
I
so
I
think
the
use
case
here
is
slightly
different
in
that
there's.
No
direct
control
of
system
behavior,
but
clearly
there
is
likely
to
be
an
indirect
control
aspect,
but
the
the
the
whole
option
that
the
whole
approach
is
optional
and
it
does.
O
L
O
Now,
in
in
this
case,
and
within
all
the
scenarios
that
we're
considering,
essentially
the
key
material
is
used
only
to
secure
the
to
secure
the
the
the
transport.
N
N
Hank
yeah,
so
this
is
an
example
of
one
of
the
reasons
why
I
think
there
should
be
less
discussion
about
security.
I
know
the
horse
is
kind
of
dead
and
I
don't
want
to
beat
it
anymore,
but
this
is
just
an
example
of
you
know.
This
is
not
a
protocol
that
has
any
keys
in
it.
This
is
just
saying
we're
not
using
keys,
so
you
know
it
seems
like
brendan's.
Discussion
should
be
in
the
document
that
describes
the
protocol.
N
That
has
the
keys
it
shouldn't
be
in
this
uccs
document,
and
that
was
that
was
why
I
was
going
out
saying
there
should
be
less
coverage
about
security
anyway,
that
just
that's
kind
of
informative.
A
second
comment
is
quite
happy
to
see
this
adopted
in
rats
and
their
comment
is,
I
have
done
an
implementation
of
this.
A
Yeah,
so
this
is
hank
not
trying
to
again
also
beat
the
dead
horse.
Sorry,
this
is,
I
think,
it's
a
good
reason
to
tie
this
tourette's
then
first,
and
if
some
other
application
like
suits,
would
do
this
and
they
won't,
as
we
just
heard,
they
would
write
their
own
id
and
tell
people
how
to
use
it
or
in
this
case,
basically
not
use
it.
A
E
Okay,
so
if
hank
has
done,
let
me
go
so.
I
I
think,
blending
what
what
got
said
by
the
previous
speakers
and
I
haven't
scrubbed
the
document
itself.
It
seems
like
we
have
a
couple
of
different
options.
It
sounds
like
we
can
come
up
with
a
general
purpose
claim
and
if
we
have
a
general
purpose
claim,
we
would
need
to
cover
all
of
the
dimensionality
of
the
attack
surface
to
include
what
came
up
ensued.
E
What
potentially
could
come
up
with
rats
and
to
future
proof,
people
misusing
it
in
some
other
way
and
that's,
I
think,
a
very
different
document.
The
alternative
here
is,
we
could
say,
hey.
We
want
to
leverage
kind
of
cbor
for
a
very
specific
application,
application
specific
way
it
will
preclude
uses
outside
of
the
rats
use
case
the
way
it
is
documented,
but
it
will
work
with
the
assumptions
of
the
deployment
environment,
kind
of
in
rats
and
that's
another
document.
I
think
the
latter
clearly
fits
into
into
rats.
E
It
makes
a
lot
of
sense
from
my
view.
We
might
need
to
talk
a
little
bit
more
about
where
the
general
purpose
one
would
go.
If
that's
the
route
we
wanted
to
take
and
how,
to
appropriately
document
all
the
caveats
with
that
particular
claim
from
my
kind
of
squint
at
that
document,
it
feels
like
you're
leaning
towards
this
idea
of
a
narrow
use
case,
specific
claim,
where
you
would
caveat
that
you
can't
use
it
outside
of
outside
of
the
deployment
environments
that
we
have
here
in
rats
right,
that's
more
or
less.
What.
O
E
D
So
thank
you.
I'd
like
to
just
get
a
show
of
hands
on
interest
of
this
draft,
and
so
I
just
started
a
quick
poll
and
then,
if
you
have
reasons
against,
please
put
that
in
the
chat,
so
we
can
collect
that
quickly.
We're
running
short
on
time.
D
I
would
like
to
see
a
threat
model
for
this
document.
Is
there
one
already
was
a
question
asked
and
somebody
else
told
them
to
do
it.
F
F
D
D
Support
and
three
do
not,
so
that's
pretty
good.
We
can
take
this
to
the
list,
especially
since
we're
running
short
on
time,
and
we
can
do
it
more
formally
there.
Okay,
thank
you.
C
All
right,
this
is
eric.
I'm
going
to
talk
about
the
threat
model.
Sorry,
the
chira
model.
We
have
done
a
number
of
updates
since
the
last
ietf.
The
biggest
change
has
been
getting
the
first
set
of
yang
doctor
reviews
and
I'm
going
to
do
an
update
on
where
we're
at
next
slide.
C
C
There's
a
relationship
to
a
number
of
other
drafts.
It
inherits
all
the
rats
language
from
the
architecture
doc.
It
inherits
the
context
from
the
draft
that
nancy
talked
about
earlier
on
the
network
device
at
the
station,
and
it
has
some
drafts
which
are
also
inputs
like
the
reference
interactions.
So
there
is
a
whole
bunch
of
context
prior
to
the
yang
model.
That's
embedded,
that's
why
the
text
is
fairly
small.
C
We
tried
to
limit
as
to
the
degree
possible
the
draft
just
to
that
yang
model.
There
are
a
couple
drafts
that
are
follow-ons
to
this,
for
example,
is
there
a
device
subscription
model
I'll
talk
briefly
about
after
this,
and
there's
been
already
several
discussions
today
about
the
trusted
path?
Routing
as
it
relates
to
the
trustworthiness
vector
next
slide,.
C
C
C
C
Within
the
yang
model,
there
really
aren't
any
open
issues
that
I
know
of
other
than
one
we
were
talking
about
on
the
list.
Just
the
last
couple
days
saying
do
we
need
to
add
some
definitions
to
the
yang
tree
as
it
relates
to
where
the
binary
sources
of
information
are
being
defined?
In
other
words,
we
need
better
references
in
a
couple
places
to
the
source
documents
from
the
from
the
trusted.
C
Computing
group
there's
also
a
fairly
technical
thing
on
xpath
to
make
sure
that
the
data
validations
are
being
done
appropriately
and
the
first
yang
dr
review
didn't
actually
get
to
that.
So
we
need
a
better
yang
doctor
review
that
will
be
done
during
working
group
last
call,
and
that's
all
the
open
issues
that
at
least
I
know
of
at
this
point
next
slide.
C
C
The
one
thing
that
is,
I
guess
interesting
is
that
these
are
mostly
people
who
cares
about
routers
and
switches,
and
the
people
dumb,
routers
and
switches
have
done
a
review
so
getting
a
sufficient
group
of
people
saying
yes,
we
care
to
go
to
work
in
group.
Less
calls
interesting
question,
but
that's
where
we
are
right
now
with
this
document.
If
we're
going
to
close
it,
we
might
as
well
close
it
because
it
seems
fairly
stable.
I
don't
know
how
we
can
progress
it
beyond
where
we're
at
without
going
there.
F
So
so
eric
did
you
update
the
draft,
along
with
your
authors,
to
include
the
feedback
from
the
yang
doctors
review
and
I
thought
you
had
mentioned
some
other
comment
with
one
more
issue.
Did
I
miss
that
or.
C
Oh,
no,
no,
the
young
doctors
updates
are
all
in
there.
They
were
posted
quite
a
while
ago
when
the
young
doctors
came
in,
so
those
those
are
all
in
there.
There
was
one
comment
just
in
the
last
few
days
from
jurgen
and
as
far
as
I
think
you
know,
sometimes
it's
a
little
hard
to
know
what
jurgen's
saying
I
think
it's
actually
covered
in
the
text.
C
The
one
comment:
that's
still
open
is
make
references
to
some
of
the
binary
formats,
and
so,
as
far
as
I
can
tell,
the
only
thing
that's
needed
is
to
get
the
references
included
for
what
some
of
the
binary
formats
are.
Some
of
them
are
inherited
and
that
we
can
make
it
a
little
bit
more
explicit.
It
really
isn't
a
big
deal
and
then
the
xpath
validations
from
the
young
doctors.
C
F
F
C
C
F
F
C
Yeah
and
we
could
also
do
them,
have
their
working
group
last
call
and
then,
after
the
response
come
back,
I
mean
this,
I'm
just
trying
to
close
out
our
our
timeline.
It's
not
like
I'm
rushing
to
have
this
complete,
but
I
just
want
to
make
sure
if
it's
stable,
we
complete
it.
Whether
you
want
to
write,
have
them
get
their
answers
and
come
back
to
working
group.
It
doesn't
matter
to
me.
C
F
Yeah
yeah
carson
highlighted
and
thank
you
hank
for
making
me
look
at
the
chat,
given
that
that
there
are
eight
authors
in
the
draft
plus
four
that
raised
their
hands.
I
I
think
I
think
we're
ready
to
do
the
last
call
and
I
I
will
explicitly
solicit
feedback
from
from
the
young
doctors
too,
for
the
last
call
so
sounds
great.
Okay,.
C
C
There's
a
bunch
of
drafts
over
netconf
on
how
to
subscribe
to
the
information
in
the
yang
model,
and
all
this
would
be
would
be
once
we've
gotten
the
chara
model
complete.
We
might
as
well
adopt
something
on
yang's
stream
subscription.
C
Now
there
is
a
possibility
of
also
including
other
types
of
things
beyond
yang
models
in
the
event
stream
subscription
and
we're
just
getting
some
interest
outside
of
this,
which
is
why
I
don't
have
any
slides
or
hank
doesn't
have
any
slides.
It
is
possible.
The
scope
is
going
to
include
more
than
yang
subscriptions.
C
We're
gonna
have
to
wait
and
see
how
that
plays
out,
but
this
is
more
of
a
once.
We
have
charade
done
and
locked.
We
might
as
well
think
about
whether
to
adopt
this
as
well.
I
didn't
want
to
do
any
new
information
or
adoption
requests
until
we
closed
out
the
other,
and
that's
just
a
simple
update
on
where
we
are
with
this.
F
C
P
P
Hello,
everyone
can
you
help
me?
Yes,
we
can
hear
you,
okay,
thank
you,
nancy.
Okay,
I'm
melinda.
This
drifter
was
first
permitted
in
march
last
year.
So
far
we
have
updated
it
to
version
three,
so
we
have
one
chance
to
this
presentation
in
our
draft
open.
Consider
it
next
slide.
Thank
you.
P
P
F
P
Think
there
will
be
authentication
centers
with
different
mechanisms,
for
example,
psk
based
authentication
center
and
ibc
based
awesome
authentication
center.
So
when
a
psk
center
and
ibc
center,
they
cannot
communicate
diff
directory.
P
The
second
consideration
is
from
the
application
level.
As
we
all
know,
the
limitation
of
this
resource
many
applications
need
operators
to
provide
business
authentication
service.
We
simply
divide
them
into
certificate
based
and
non-certificate
based.
So
when
class
business
authentication
is
required,
can
we
use
rest
to
prove
one's
identity
to
the
other?
P
And
the
third
consideration
point
is
about
virtualization
based
system.
Virtualization
system
also
use
ras
based
on
vtpn,
but
I
I
haven't
seen
the
what
group
dress
jeffs
have
mentioned
it,
so
I
so
I
have
a
question.
P
P
P
P
The
first
step
is
to
the
new
router
provides
evidence
to
the
verifier.
Maybe
the
oscillator
can
shorten
for
the
row
of
verifier
and
the
second
step
is
the
verifier
feedback.
The
result
and
the
step
three
is
trustworthy
assessment.
P
The
other
scenario
is
how
to
update
the
routine
devices
status,
can
collect
rooting.
Information
in
real
time
or
particularly
the
information
collected,
maybe
include
device
information,
log
information.
Fourth,
information
trustee
trustee
merger
renders
and
then
forms
a
trusted
link
based
on
users,
trustworthiness,
requirements.
F
P
Q
C
On
the
on
the
use
cases,
there
are
drafts
that
are
identifying
the
use
cases
inside,
for
example,
the
trusted
path.
Routing
defines
the
previous
use
case,
as
well
as
a
potential
solution
to
it.
Have
you
looked
at
these
drafts
and
do
you
have
any
thoughts
on
how
those
drafts
might
accomplish
the
use
case
that
you're
identifying.
P
Here,
I'm
sorry,
I
I
don't
get
your
point
exactly.
Can
you.
C
Example,
the
routing
use
case
there
is
a
draft
on
the
routing
use
case
that
defines
both
the
use
case
as
well
as
how
to
solve
it.
With
network
protocols.
Have
you
had
a
chance
to
read
the
draft
on
the
routing
use
case.
P
Do
you
mean
the
draft
for
the
trusted?
What's
the
vendor,
that
draft.
C
P
In
the
chapter
we'll
see
vendor
this,
we
keep
same
with
you
with
your
ideas.
C
C
So
I
guess
my
question
is:
is
how
are
you
trying
to
add
new
use
cases
to
michael's
use
case
draft?
Are
you
trying
to
define
additional
use
cases,
I'm
just
trying
to
understand
what
you're
trying
to
do
with
this
draft.
P
Okay,
my
title
is
about
use
case,
but
maybe
it's
it
is
not
so
exactly.
We
just
give
our
consideration
for
from
our
perspective,.
P
Your
advice,
our
use
case,
to
be
refined
in
the
in
your
draft,
is
the
right.
C
Q
P
Understand
your,
maybe
it's
a
good
advice,
because
I
do
not
know
how
this
next
step
of
my
draft.
E
I
was
just
going
to
hop
in
I
mean
I'm.
I
wanted
to
reiterate
kind
of
from
a
procedural
procedural
kind
of
process,
I'm
thrilled.
We
have
concrete
text
in
writing
that
couches
use
cases.
We
have
a
couple
of
them
and
we
have
a
new
document
here.
Thank
you
for
bringing
it
that
tries
to
discuss
potentially
additional
use
cases.
P
Maybe
we
can
deter
it
together
because
the
draft
is
not
so
perfect.
Now
we
have
many
things
to
do.
Oh.
F
No
so
mailing,
I,
I
would
suggest
that
you
take
this
up
to
the
mail
list
and
if,
if
you
can
clarify
the
purpose
of
the
draft,
as
roman
just
stated
right,
the
use
cases
are
to
instill
the
discussion
for
the
solutions
that
are
being
put
forward.
The
intent
is
for
not
to
have
that
the
use
case
documents
to
actually
be
published
as
rfcs,
so
if
you
can
make
the
purpose
of
what
you're
trying
to
achieve
more
clear
and
do
it
through
the
mail
list,
I
think
that
will
help
us
right.
P
Yes,
maybe
your
use
case
is
the
started
point
we
come
to
the
rest,
but
we
also
want
to
do
their
deep
research
on
the
trustee
link.
I
Maybe
I
need
to
ask
a
couple
questions
about
whether
stuff
was
in
rats
in
the
first
couple
of
slides-
and
I
couldn't
tell
for
sure,
but
I
think
the
answer
is
yes
to
the
various
questions
that
you
asked
about,
whether
something
was
appropriate
for
rats.
I
think
I
understood
the
first
diagram.
I
didn't
understand
the
second
one,
but
out
of
the
first
three
or
four
questions
you
asked,
I
think
the
answer
is
going
to
be.
I
Yes,
yes
and
yes,
but
the
questions
you'd
ask
me
like
looked
like,
you
were
looking
for
an
answer
from
the
rats
working
group.
I
just
wanted
to
give
an
answer
on
behalf
of
at
least
one
of
the
rats
architecture
authors.
But
yes,
I
think
that
rats
can
be
used
for
at
least
some
of
the
scenarios
that
you
mentioned.
Eric
commented
on
the
latter
ones,
but
I
just
wanted
to
help
answer
it
for
the
former
ones.
F
F
F
Okay
may
lane
michael
richardson
who's,
one
of
the
main
editors
for
the
use
case
draft
said
he
he's
happy
to
to
collaborate
with
you
vis-a-vis
the
use
case
draft
that's
currently
running,
but
noting
roman's
comment
on
publication.
So
so,
if
we
can
take
that
to
the
mail
list,
I
think
that
would
be
good.
F
A
Yeah,
sorry,
I
was
so
it
was
late.
I
was
a
little
bit
distracted
with
the
millings
questions,
so
I
think
the
very
first
diagram,
so
I
also
have
to
agree
with
dave.
First,
I
think
that's
the
easiest
part
and
then
then
the
the
first
scenario
very
much
looks
like
the
composite
device
scenario,
so
I
think
it's
an
extension
to
the
composite
device,
multi-chest
eye
section
in
the
architecture
and-
and
maybe
you
can
start
from
that
for
the
first
scenario.
A
The
second
scenario
with
the
two
relying
parties-
one
of
them-
is
a
certificate
and
one
non-certificate.
I
might
need
a
use
case
like
like
your
user
story,
like
like
what
what
messages
actually
involved
here,
what
what?
What's
the
problem
in
the
production
environment
that
is
solved,
because
I
I
could
see,
of
course,
a
attestation
result
to
some
extent
if
it's
science
could
substitute
a
certificate
somehow.
A
But
I
I
don't
know
all
the
moving
parts
here,
so
I
think
the
second
scenario
would
benefit
from
a
fleshed
out
use
case
scenario
and
I
unfortunately
forgot
the
third
item.
But
I
will
come
back
to
this.
F
Later,
okay
open
make
time
dave
thaler
you're
on
the
queue
thanks
for
that
hank.
I
All
right
open
white
question,
so
I
mentioned
that
the
cheap
working
group
has
a
dependency
on
rats
right,
which
was
kind
of
the
first
best
customer
for
rats
where
another
working
group
was
taking
dependency
on
it.
I
think
you
know,
jeremy
had
talked
about.
You
know
global
platform
and
things,
but
my
question
for
open
mic
time
is
are
folks
aware
of
other
ietf
working
groups
that
are
looking
at
taking
a
dependency
on
rats.
Some
of
you
may
remember.
I
During
the
buff
time
I
had
given
a
conjecture
that
every
authentication
use
case
was
an
attestation
use
case,
and
so
there
might
be
a
large
number
of
things
that
are
potential
customers.
I
just
wonder:
are
there
other
things
that
might
be
normative
dependencies
coming
in
from
other
working
groups
right
now?
So
there
you
go.
K
Can
I
answer
the
question
michael
richardson,
one
thing
which
is
not
adopted
and
not
well
understood
or
accepted,
is
in
the
reprise.
K
Excuse
me,
the
add
working
group
is
that
here
already
and
I
have
a
document
on
especially
an
attestation
as
to
the
quality
and
privacy
of
the
dns
server
that
you
are
going
to
talk
to,
and
I've
tried
to
make
it
clear
that
we
should
not
be
reinventing
rat
here,
and
the
working
group
doesn't
really
understand
why
it's
an
aspiration
and
hasn't
accepted
the
document
at
all.
Yet
so
I,
if
anything,
we
have
some
explanations
and
evangelizing
to
do
elsewhere.
F
I
think
you
raise
a
a
good
point,
michael,
I
guess
I'm
kind
of
scratching
my
head.
I
guess
I'm
not
fully
awake
yet
in
how
we
could
raise
that
awareness,
because
I
think
you're
right.
The
question
to
you
would
be
that
if
you
need
help
with
the
add
working
group,
how
we
could
in
threat
participation,
help
raise
that
awareness.
K
I
would
say
that
primitively,
the
simplest
is,
we
should
get
our
documents
published.
That's
the
probably
one
of
the
simplest
ways
to
be
able
to
do
this
and
go
read
this
done,
but
I
I
think
that
that
that
perhaps
it's
just
a
question
of.
K
Making
our
use
pieces
more
easy
to
comprehend
and
that
that
may
just
mean
we
have
some
better
fly,
that
more
people
are
using
more
commonly
so
there's
some
value.
I
think
in
common
messaging
here.
F
F
F
Okay,
so
with
that
we're
out
of
time,
thank
you,
everyone
and
we
will
meet
again.