►
From YouTube: IETF110-RATS-20210310-1430
Description
RATS meeting session at IETF110
2021/03/10 1430
https://datatracker.ietf.org/meeting/110/proceedings/
D
D
D
Topic
lawrence
is
also
on
tap
for
that
one
and
then
third
is
a
discussion
about
how
coswood
and
eat
go
together,
and
so
we
have.
We
have
plenty
of
time
allocated
for
that,
so
it
really.
If
there's
if,
if
there's
time,
I
think
we
will
try
and
the
trails
will
will
do
an
update,
a
brief
update
on
the
milestones
progress,
any
other
topics
we
need
to
consider.
D
D
E
Please
so
this
is
the
same
slide
from
last
time,
just
a
list
of
the
things
that
that
I'm,
I
think,
should
be
in
eat
the
the
the
set
of
claims
that
we
should
be
having
you
eat
that
that's
kind
of
the
in
the
eat
draft.
That's
the
ones
we
want
to
standardize
for
the
the
e
draft
can
be
lots
of
claims
after
this
you
know
in
the
registry,
but
this
is
the
the
plan.
What
I'm
planning
for
to
complete
the
draft
next
slide.
E
So
this
is
the
status
of
and
progress
on.
All
of
those,
so
we've
had
a
little
bit
of
progress
on
the
hardware
identification,
the
then
and
it's
it's
nearly
done.
I've
had
a
little
bit
of
progress
on
gps
location.
There
was
some
refinement
there
and
I
think
it's
nearly
done.
E
In
some
detail,
then
there
was
a
bit
of
a
few
little
modifications
to
sub
modules
and
nested
eats,
and
I
think
those
are
in
pretty
good
shape.
I
have
an
implementation
of
of
of
that
and
I
think
thomas
was
working
on
an
implementation
of
that.
Then.
Last
time
we
talked
about
public
keys
and
that
was
that's
been
added
to
the
draft.
E
So
the
the
big
areas
where
we
have
work
to
be
there's
where
there's
work
to
be
done
is
coast,
wood
measurements
and
then
the
identifying
the
verifier
input,
which
is
endorsements
and
key
ids.
So
we
talked
about
go
to
next
slide,
oh
yeah,
and
then
there's
other
than
work
on
specific
claims.
I
need.
I
still
need
to
do
a
substantial
rework
in
relation
to
the
rats
architecture,
so
it
uses
the
terminology.
E
E
So,
just
just
a
short
change:
a
list
of
changes
the
ue
ids
are
now
based
on
the
imei
based
ueids
are
now
14
byte
strings
the
sub
modules.
Now
a
cwt
sub
module
is
allowed
in
a
jwt
and
vice
versa
and
the
the
how
seaboard
tags
are
to
be
used
in
a
like
when
you
put
a
cwt
module
inside
a
cwt
module
how
the
tagging
works
added
that
we
added
the
cryptographic
keys
in
claims
added.
The
hardware
version
claims
some
some
tweaks
for
debug
status.
E
Added
the
intended
use
claim.
There's
improvements
on
the
location
claim
added
the
boot
seed
claim.
Then
there
was
a
bunch
of
rework
on
the
seaboard,
interoperability
section
and
then
added
profiles.
E
So
the
a
lot
of
the
work
to
be
done
is,
as
I
said,
on
swids
coast,
widths
and
measurements
and
we'll
get
into
that
later,
and
then
there's
also
a
fair
bit
of
work
to
be
done
on
endorsements
and
key
ids,
and
most
of
that
is
going
to
be
just
frame
up.
I
have
a
pull
request
on
that.
I
don't
intend
to
actually
define
an
endorsement
format
next
slide.
E
Yeah
so
we
talked
about
verifier
input
at
109,
but
nothing
has
happened
since
and
then
nothing
on
attestation
results
and
measurements
not
really
either.
I
think
I
think
I
did
put
a
pull
request
out
there,
but
it's
not
very
developed.
E
E
Okay,
if
not,
then
let's
keep
going
next
slide,
so
this
is
about
the
profile
claim
next
slide.
E
So
this
is
to
me
this
is
about
actually
getting
to
interoperating
implementations
of
eat,
so
the
eat
protocol,
or
he
describes
it's
got
a
lot
of
options.
I
mean
you
know,
and
these
it
has
all
these
options
to
work
in
lots
of
different
environments
and
lots
of
different
use
cases.
Some
of
them
have
to
do
with.
You
know
whether
it's
constrained
device.
E
Are
you
using
this
on
a
constrained
device
or
are
using
this
to
report
results
between
cloud
services,
for
example,
for
the
two
extremes,
something
and
two
things
that
are
very
different,
so
constraining
device?
You
want
very
few
claims,
very
small
representation,
moving
data
between
cloud
services.
You
probably
are
happy
with
that
json
and
you
might
have
lots
and
lots
of
claims.
E
Some
of
this
optionality
is
inherited
from
cos
a
and
from
cwt.
You
know,
for
example,
kosei
supports
lots
of
algorithms
and
you
need
to
narrow
down
to
pick.
You
know
one
or
two
algorithms
or
a
set
of
algorithms.
Somehow
so
you
actually
have
interoperability
in
cwt
claims
are
all
the
claims
are
optional.
E
So
we
have
this
this
setup
so
that
that
two
implementations
of
e
may
not
necessarily
interoperate
one
one
could
be
using
json
with
the
other
seaboard.
They
could
have
different
means
of
identifying
the
the
verification
key
signing
algorithm.
E
Could
they
could
choose
different
signing
algorithms?
They
could
in
choose
different
variants
of
sibor
encoding
format
like
a
definite
length
versus
indefinite
length,
so
yeah
next
slide.
E
E
It
kind
of
surprises
me
that
we
don't
do
more
of
this,
particularly
around
kozai
and
sibor,
because,
like
a
lot,
this
the
characteristics
of
the
issues
here
would
arise
for
any
protocol
using
cos
a
and
seabor,
and
this
is
itf.
So
I
think
we
are
after
interoperability,.
E
So
I've
gone
a
gone,
a
fair
ways
down
the
path
here
to
recommend
what
should
be
in
the
neat
profile.
We
don't
have
any
example
lead
profiles
yet,
but
so
what
what
the
the
text
in
the
document
does
is
list
all
the
things
that
an
eat
profile
should
specify.
E
It's
not
anything
machine,
readable
or
anything
like
that.
It
narrows
the
cwt
cos
a
and
jwt
options
to
result
in
an
interoperable
protocol.
The
document
may
be
either
an
iets
standard
or
ietf
informational
or
such
it
could
be
some
other
standard
like
fido
or
vp.
It
could
be
vendor
proprietary.
E
It
could
be
private
just
being
completely
open
here
about
what
any
profile
document
could
be.
I
mean
it
could
be
in
the
set
of
documents
or
you
could
even
a
hierarchy
of
documents.
E
That
that
that
claim
is
not
required.
It's
just
to
help
a
helpful
hint
for
parties
to
know
which
profile
is
in
use
and
the
format
of
the
name
document
is
text.
It's
not
standardized
for
machine
processing,
so
the
profile
addresses
four
major
things:
serialization
format
protection
I
like
whether
the
the
the
eat
is
signed
or
encrypted
or
signed
and
encrypted
or
not
protected.
It
addresses
key
identification
and
it
addresses
what
what
claims
are
required
and
prohibited.
E
And
after
yesterday's
discussion,
I'm
actually
thinking,
freshness
and
replay
protection
need
to
be
added.
E
E
So
the
serialization,
so
it
says
whether
you
could
use
sibor
or
json
or
both
and
how
the
nesting
can
work
like
if
you're
you
know,
your
main
format
is
seaborg.
Is
it
okay
to
nest
a
jwt
adjacent
token
in
in
the
seaboard?
Vice
versa
for
seabor,
it
narrows
whether
you're
using
a
definite
and
indefinite
length
for
maps
and
arrays
and
strings,
and
it
says
how
to
use
seymour
tags.
E
E
Your
profile
should
should
say
what
kind
of
protection
you're
you're
you're
requiring
whether
it
is
you
know,
signing
encryption
mac
and
then
there
are
the
unsecured
options
for
use,
uccs
and
then
unsecured
jwds
profile
should
indicate
yeah.
So.
E
That
sentence
is
not
very
good
there:
integrity
protection,
privacy
protection,
you
know,
do
you
assign
do
you
encrypt?
Is
it
symmetric,
encryption
or
public
key
based?
It
should
list
algorithms,
probably
the
right
way
to
do.
E
That
is
the
list,
the
a
list
that
the
test
or
the
verifier
must
implement
and
a
and
then
the
tester
can
pick
one
of
those
or
one
or
more
of
those
okay
screen
share
is
back,
so
the
profile
should
be
tight
enough
that
there's
an
interoperability
guaranteed
when
both
the
tester
and
verifier
implement
the
implement
next
slide.
E
E
Perhaps
it's
through
an
endorsement.
Perhaps
it's
not.
There
are
a
number
of
ways
to
identify
a
key,
so
you
could
do
coset
key
id
in
an
endorsement
by
a
claim
like
the
ue
id,
perhaps
something
else.
E
And
then
last,
since
the
claims
are
optional,
a
profile
probably
is
going
to
require
some
claims
to
be
present
and
say
verification
verification
can
fail
if
not
profile
might
prohibit
some
claims,
probably
because
of
privacy
reasons.
E
And
add
them
add
them
to
the
registry
or
not,
and
a
profile
may
allow
optional
claims
and
in
that
case
verification
wouldn't
fail
if
they're
present,
I
also
should
have
added
here
a
profile
can
narrow
a
claim.
So
you
know
you
might
say
or
refine
a
claim.
So,
for
example,
in
the
location
claim,
some
things
like
accuracy
are
optional,
so
a
profile
could
say
that
they
are
not
optional.
E
Most
claims
right
now
are
really
simple.
I
think
when
we
get
to
the
coast
with
that's,
that's
a
much
more
complicated
thing,
so
I
believe
that
is
all
I
had.
Let's
see,
go
for
next
slide.
Please.
E
Okay,
so
that's
all
I
had
for
profiles
before
going
to
coast,
wed
dave.
F
Yeah,
I
just
want
to
say
that
that's
a
great
list.
I
think
that
the
keep
working
group
was
the
first.
You
know
customer
of
rats
and
so
the
t
protocol
spec
itself
is
kind
of
the
first
candidate
profile.
As
I
understand
it,
and
so
this
is
a
great
list
of
requirements
that
the
cheap
protocol
spec
should
cover,
of
which
it
covers
some.
But
not
all
of
these.
That's
why
I
thought
this
was
a
great
list.
F
I
guess
there's
a
medic
question
is:
do
you
think
that
a
profile
that
would
that,
as
you
start
to
have
other
other
using
protocols
and
things,
do
you
think
that
a
protocol
would
typically
itself
specify
what
profile
it
is
or
do
you
envision
there
be
that
profiles
be
something
that
that
protocols
would
negotiate
to
say
which
profile?
Is
it
I'm
asking?
What
you
think
is
the
more
typical
use
case?
F
I
think
in
teep
we
probably
just
want
to
nail
the
teat
protocol
itself
is
a
profile
there's
only
one
set
of
things
and
the
t
protocol
itself
specifies
it.
But
do
you
have
any
guesses
as
to
what
you
think
is
typical
for
what
documents
might
use
profiles
and
how
many.
E
Not
I
don't,
I
don't
have
much
to
say
about
that.
Actually
I
mean
it
seems
like
it
could
be.
Could
could
very
well.
G
Hey
it's
gary
here.
Sorry,
I
missed
c
it
it
couldn't.
Do
the
raise
hand
raise
hand
feature
so
dave,
I
I
can
say
at
least
in
our
internal
production,
we're
running
into
situations
where
it
has
to
be
essentially
some
sort
of
declarative
measure.
It
can't
be
negotiable,
and
so
that's
particularly
the
case
where,
indeed,
is
being
used
in
the
context
of
a
device
that
lacks
ip
connectivity.
G
So
you
can
think
of
maybe
a
device,
that's
listening
on
the
bluetooth
low
energy
advertising
channel,
but
it
is
requested
to
send
back
up
a
up
and
at
a
station
through
a
hit
through
a
unicast
connection.
So
in
that
case
we
just
don't
negotiate.
We
need
to
get
that
out
of
station
up
right
away.
It's
assumed
that
they
will
that
the
relying
party
would
be
able
to
process
whatever
whatever
profile
would
be
declared
inside
of
the
inside.
F
Of
the
payload
gotcha
yeah,
that's
actually
yeah
you're.
Getting
to
the
point
of
my
question
because
lawrence
you'd
mentioned
that
you
know
a
claim
can
specify
in
the
eat
which
produ,
which
profile
the
eat
was
generated
by
right.
E
Okay,
I
mean,
I
would
imagine
all
those
things
are
possible,
depending
on
you
know,
like
the
fido
protocol
or
the
whatever.
C
F
I
will
take
this
as
a
to
file
an
issue
against
the
tea
protocol
spec
to
put
in
text
to
make
sure
we
match
all
of
the
set
of
requirements
for
each
profile.
That's
what
I'm
going
to
take
away
from
this,
which
is
why
I
thought
it
was
a
great
list.
So
thanks.
E
Yeah,
what
makes
me
think,
maybe
we
should
add
some
text
that
says
you
know,
protocols
that
carrie
eats
you
know,
can
choose
between
locking
down
to
one
profile
having
a
profile
negotiation.
If
the
protocol
can
support
it,
I
mean
I'll,
probably
propose
some
text
for
that
and
see
how
it
flies.
E
Okay,
hank.
H
Hi
laurence,
this
is
hank.
Quick
question
is
the
first
question.
Basically,
how
do
you
want
to
express
profiles.
H
Yeah,
if
I,
if
I
want
to
create
a
profile,
you
say,
for
example,
I
said
you
could
make
a
a
map
member,
more
narrow
and
therefore
mandate
its
existence
instead
of
absolute
existence.
So
so
I'm
gonna
do
that
now.
How
do
I
express
that.
E
Well,
right
now
any
way
you
want,
I
mean
you
could
do
it
in
chinese.
You
could
do
it
in.
You
know
a
rust
program.
It's
completely
open
ended.
I
haven't.
I
haven't
really
tried
to
narrow
that
at
all.
H
Okay,
sorry,
sorry,
then
I'm
specified
a
little
bit.
I
I'm
an
itf
id
author
and
I
want
to
create
profile
text
on
my
id.
B
E
I
I
didn't
I
mean
I
I'm
open
to
some
other
suggestions
here,
but
I
didn't
didn't.
I
didn't
want
to
narrow
it
at
all
I
mean
we,
I
mean,
I
suppose
we
could
come
up
with
some
sort
of
a
convention
for
doing
it,
but
I
I
didn't
have
any
particular
thoughts
on
how
to
do
that.
H
So
I'm
bringing
up
this
question
because
this
reminds
me
of
that
I
think
that's.
A
subset
of
your
problem
statement
is
that
we
have
this
very
versatile
cozy
envelope
and
and
you,
if
you
mandate
that
is
implemented,
you
have
to
implement
that
jana
algorithm
list
and
that's
probably
not
always
going
to
happen.
So
what
we're
doing
right
now
for
cozy
is
actually
to
rewrite
the
whole
cozy
spec
and
just
cherry
pick,
what
we
want
from
that.
So
like
there's,
always
of
course,
the
the
central
envelope.
H
There
is
the
tag,
for
example,
messages
or
keys,
or
something
in
cozy,
and
then
the
cherry
pick
the
unprotected
and
protected
stuff
and
and
put
them
in
to
our
like
and
rewrite
the
old
cdl
and-
and
if
I
look
at
this
like
from
your
point
of
view
now
I
would
say
that's
a
profile
for
cosy
use
edge.
You
could
restrict
the
number
of
the
the
the
accepted
values
for
algorithm
ids.
You
could
say
I
only
want
these
two
optional
and
that
were
mandatory
and
nothing
else
and
such
so.
H
E
Yeah,
I
suppose
you
could
do
it
that
way.
I
I
was
not
the
way
I
and
I
think
I've
seen
that
in
the
coastwood
draft.
I
thought
I
thought
that
was
a
little.
I
mean
that
wasn't
my
origin
initial
thought
to
do
it.
My
initial
thought
was
just
to
say:
you
know
he
used
text
to
describe
how
you
want
cos
a
to
be
used,
and
I
mean
my
thought
also
is
you
know.
Kose
should
be
for
a
lot
of
these
things.
E
You
should
allow
this
variety
of
signing
and
encryption
I
mean
like
cwt.
Does.
H
Maybe
there's
some
middle
grounds
here.
Sorry,
sorry
so
step
in
here
just
for
a
second,
so
I
I
think
writing
something
in
english
text
when
you
can
have
a
formal
language
is
not
a
good
idea
anymore,
because
then
imposition
kicks
in
and
interoperability
lacks
and
suffers
at
some
point,
maybe
and
and
if
you're
very
precise,
and
what
you
expect
to
be
in
the
message.
C
You
know
just
just
to
think
of
what's
what
hank
was
saying.
I
think
we
could
so
your
list
of
requirements
is
so
precise
that
we
could
come
up
with.
You
know,
for
example,
a
a
draft
template
in
markdown
or
in
xml
rfc,
with
with
all
the
sections
pre-populated,
and
you
just
fill
in
the
blanks
and
stuff
like
that.
C
That
might
be
an
option
to
semi-automate
the
thing,
because
if
you're
talking
to
ctdl
hank,
then
you
know
constraining
a
type
is
not
that
easy?
I
mean
it's
not
like
json
schema
where
you
can
override
the
type
and
apply
more
constraint
on
that,
and
then
ctm
doesn't
seem
to
be
prone
to
that
manipulation.
H
No,
that
is
that
I
think
the
profile
is
restating
your
subset
in
cdl
is
how
can
you
not
restrict
the
type
there.
H
Yeah:
okay!
Well:
how?
If
you
write
it
in
english
text,
you
would
end
up
with
the
same
content
as
you
would
do
in
a
complete
rewrite
right,
because
everything
you
touch
and
you
have
to
mention
the
you
have
to
write
and-
and
I
think
that
that
in
the
content
of
the
english
text,
you
would
find
the
exact
same
thing.
When
would
you
write
it
in
the
cdn
that.
C
Is
true,
but
that
doesn't
apply
to
every
single
dimension
of
the
profiling
right.
It
does
apply
to
the
constraining
of
types,
and
I
agree
with
you,
but
other
other
dimensions
are
not
are
not
covered
by
ctl,
so
there
still
need
to
be
some
english
text
somewhere
and
that's
what
I'm
trying
to
say.
H
I
I
I
would
like
to
disagree
with
hank
here,
because,
having
looked
at
this
from
a
deep
point
of
view,
as
we
discussed
in
the
earlier
session
today
like
it's,
these
simple
things
of
saying
something
like
we
don't
use
encrypt
zero,
but
only
encrypt
and
use
encrypt,
I
don't
think
it
needs
any
cddl
to
do
that.
I
think
we
are
sort
of
doing
overkill
here.
I
It's
just
like
I
had
to
realize
working
on
the
course
you
spec
and-
and
the
same
applies
to
what
lauren
said
to
other
specs
as
well-
is
that
some
were
not
meant
to
be
limited
in
any
in
any
shape
or
form.
They
just
specified
everything
that
came
to
the
to
the
mind
of
the
author
or
the
working
group
at
that
time,
and
so,
instead
of
listing
these
20
options,
you
say
like
for
that
profile.
You
just
use
one.
H
So
sorry
to
kick
in
here
again,
but
but
yes
exactly,
you
say
that
you
say
your
start
message
is
just
one
type
and
you
write
cozy
and
then
you
go
from
there
cozy
zero,
for
example,
and
you
go
from
there
I
think,
even
in
cdl
it
is
like
25
number
of
characters
than
in
english
text,
because
you
have
to
write
and
in
your
message
you
must
and
then
you
can
also
write
in
cdda
start
messages
equals
cozy
zero
and
you
have
your
rule,
that's
done
so
I
I
I
still.
I.
B
B
I
I
think
what
lawrence
is
saying
that
hey
we
have
too
many
options.
We
somehow
need
to
sort
of
produces
and
if
you
write
the
profile
and
use
cdl
to
describe
what
you
want
an
implementer
to
do,
then
that's
fine,
maybe
for
you
and
and
maybe
not
for
someone
else.
I
don't
think
we
should
mandate.
It
has
to
be
done
in
cddl
like
or.
H
I
Having
having
now
spent
last
week
implementing
the
cozy
stuff
like
for
that
for
the
firmware
encryption,
I
can
tell
you
that,
like
it's
full
of
course
it's
full
of
cddl,
but
it's
it's
not
a
readable,
very
readable
document.
So.
H
Now
that
that
might
be
the
fact
that
the
cosi
has
this
extraction,
script
implied
that
provides
you
with
the
complete
full
cdl
vba
diverge
from
that
since
cosy
I.
I
was
not
a
big
fan
of
that.
We
always
have
a
redundant
block
of
the
full
cdta
for
implementers
and
and
then
the
the
fragments
broken
out
as
is
done.
It's
cozy
reassembling
them
is
a
little
bit
tricky
and
annoying.
H
I
think
personally,
but
I
think
jim
also
had
a
point
that
if
you
can't
expect
that,
maybe
you
shouldn't
implement
that,
but
that
was
another
I
think
approach
to
to
to
readability.
Okay,
have.
H
E
So
I
mean
my
takeaway
here
is
that
we
still
need
to
allow
open
description
of
english.
Some
people
just
may
not
want
to
do
it
in
cd
cdl,
some
people
may
be
very
json
oriented
or
something
and
jwt,
but
there's
definitely
opportunity
to
use
cdl
to
narrow
it
in
certain
certain.
E
Circumstances:
okay:
I
want
to
move
on
to
the
next
here.
Any
last
comments.
E
Okay
on
to
coast,
woods-
and
I
I
framed
the
this
up
as
a
discussion,
because
I'm
I'm
kind
of
sort
of
figuring
this
out
stuff
myself,
so
my
slides
are
mostly
framing
and
I
haven't
written
any
text
yet
or
anything.
E
So
my
first
thought
here
is
that
there's
actually
kind
of
two
forms
of
of
of
descriptions
of
software
that
we're
talking
about
so
there's
descriptions
of
software
that
were
created
outside
the
the
the
device
and
then
there's
descriptions
of
software
that
were
created
on
the
device,
so
the
the
ones
created
outside
the
device
are
likely
signed
by
the
manufacturer,
they're
they
are
put
on
the
device
during
software
installation.
E
E
What
was
installed
copying
it
into
a
claim
and
sitting
it
to
the
verifier,
and
you
know
it
may
contain
references
for
measurements
where,
as
a
description
of
of
software
created
on
the
device
is
it's
run
by
we're
made
by
a
code
running
on
the
device
it's
going
to
be
signed
as
part
of
the
attestation.
E
It
might
contain
measurements,
it's
kind
of
a
an
on-the-fly
inventory
of
software
on
the
device
so
and-
and-
and
this
is
you
know,
my
interest
here
is
in
you
know
what
claims
go
in
and
eat
so
there's
there's
uses
for
swedes
and
coast
widths
and
lists
of
software
outside
of
these
two,
but
I'm
I'm
just
focused
on
what's
going
on
into
an
eat,
that's
going
from
an
attester
to
a
verifier.
E
And
I've
started
looking
at
coast,
woods
and
sweds
and-
and
I
haven't
looked
at
suit-
manifests
or
comeds
yet.
But
my
initial
thought
right
now
is
that
it
should
support
coast
widths
and
possibly
with
some
extensions,
or
you
know,
allowing
extensions
and
perhaps
some
others-
I
mean
we
don't
have
to
just
pick
one
official
format
and
only
support
it,
although
it
would
be
nice
to
pick
one
that
is
widely
used,
so
we
don't
want
having
a
thousand
flowers
blooming
here,
doesn't
help
interoperability.
E
Next
slide,
can
you
still
hear
me:
okay,
reconnecting
all
right,
so
here's
what
I'm
proposing
oh
go
back.
Please.
E
There
we
go.
Thank
you
is
that
eat
must
be
able
to
carry
coast
woods.
E
E
E
I
would
hope
that
the
signing
and
encryption
format
for
coast
widths
is
cose
basically
done
the
same
way
that
it's
done
for
cwt
and
the
the
cool
thing
there
would
be
to
be
able
to
reuse
the
code
that
that
processes
signing
in
and
encryption
of,
of,
cwts
for
processing,
signing
and
encryption
of
coswoods,
and
then
this,
whether
they're,
a
payload
coast
width
or
an
evidence
cost
which,
which
I
believe
is
my
understanding,
is
that
that
that
the
two
things
I
distinguished
at
the
beginning,
whether
it
was
created
by
the
software
creator,
that's
a
payload
coswood
if
it's
created
on
the
device.
E
My
understanding
is,
there
are
booleans
inside
the
coast
with
that.
Can
let
tell
you
which
one
that
is
so
then
I've
got
three
options
for
how
to
put
coast
woods
into
eat.
E
We
know
we
have
to
carry
more
than
one
coast:
wood,
because
there's
two
different
types
and
if
you're
putting
coast
woods
on
that
represent
installed
software,
there
could
be
many
software
packages
installed.
So
you
can't
just
have
one
coast
wood
to
describe
it
all,
because
those
were
created
independently
and
signed
independently.
So
you
have
to
carry
it,
you
have
to
relay
all
of
them.
E
E
E
A
third
option
would
be
to
have
a
single
claim
for
the
evidence.
Coswood.
E
E
Okay
yeah,
so
you
know
go
back
back.
Please.
I've
also
been
having
a
side
discussion
about
coast
with
you
know,
there's
some
they're,
they're,
somewhat
file
system,
oriented
and
seems
like
you
could
that
doesn't
work
for
all
all
devices.
It
seems
like
you
could
work
around
that
by
extensions
another
thing.
I
thought
that
you
know
in
the
phone
world
a
lot
of
the
software
is
in
form
of
applications,
so
coswood
doesn't
have
anything
that
describes
an
application.
E
E
Tees
also
have
a
strong
notion
of
applications
for
installed
trusted
apps.
Okay,
so
that's
that's
about
all.
I
had
to
say.
E
F
Yeah,
just
making
sure
you
can
hear
me,
my
question
is:
there's
you
have
three
options
on
the
slide.
Are
you
saying
that
all
three
options
are
supported
or
is
there
a
question
to
the
working
group
about
which
option
should
be
allowed,
or
I
couldn't
understand
what
the
three
options
were?
Who
is
the
chooser
of
the
option?
F
Yes,
it's
a
question
to
the
working
group.
Okay,
in
that
case,
to
the
extent
that
I
understand
is
there
may
be
things
that
I
didn't
quite
follow,
but
I
think
option
number
three
is
probably
the
cleanest
option.
Number
two
is
the
next
cleanest
and
I
don't
like
option
one.
E
E
H
H
I
guess
that's
fine,
but
my
question
is:
why
can't
you
do
the
array
thing
from
option
one
with
these
two
claims
in
option
three:
why
do
you
have
to
wear
to
do
the
sub
modules?
That's
a
little
bit
confusing
to
me.
E
I
I'm
I'm
pretty
open
to
all
this.
I
don't
I
mean
I,
if
there's
an
option
for
four
five,
six,
seven,
eight
sure
let's
go.
F
F
Hank,
let
me
elaborate
on
why
I
said
the
preference
and
that's
I
hypothesize.
It
will
be
common
in
protocols
that
you'll
want
to
have
some
information
about
some
additional
information
about
each
cause.
Word,
that's
not
beyond
that
which
is
embedded
in
the
coswood
itself,
okay
and
so,
and
option
number
one.
You
can't
do
that
without
having
something
like
a
parallel
array
or
duplicating
the
causewood
into
some
other
structure
too.
So
that's
why
I
don't
like
option.
One
is
if
you
need
to
pass
anything,
that's
on
a
per
coswood
basis.
F
You
can't
do
it
in
option
number
one
without
doing
option
number
two
or
three.
So
that's
why
I
said
I
didn't
like
number
one:
okay,
if
you
only
have
the
list
of
causewoods,
then
it's
all
the
same
right.
It
doesn't
matter
which
option
you
choose
option.
One
is
fine,
but
I
hypothesize
that
it
is
common
to
have
additional
information.
F
That's
what
I
think
is
the
cleanest
way
to
do
it.
I
think
that
matches
well
things
like
layered
attestation,
where
you
have
a
wood
per
layer,
for
example,
and
you
have
a
set
of
claims
about
each
layer
and
you
can
reuse
the
same
claim
ids
about
you
know
like
I
don't
know
time
stamp
or
time
sense,
boot
or
time
sense
that
that
software
has
been
running
things
like
that,
you
could
reuse
the
same
thing
in
each
sub
module.
I
think
that
would
be
fine.
That's
why
I
think
three
is
the
cleanest.
F
So
that's
why
I
said
my
preference
is
to
say
you
can
have
multiple
of
them
and
with
each
coswood
you
can
have
another
set
of
eight
claims,
including
standard
ones,
your
private
ones
or
whatever
else,
and
my
understanding
is
sub
modules.
Let
you
do
that
already
and
so
that's
the
long
reason
for
my
preference
for
three.
Hopefully
I
got
my
assumptions
right
and
but
if
not,
then
you
can
at
least
understand
what
my
preference
is
and
map
them
to
something
else.
If
that's
option
four
or
something
so.
E
Just
just
one
more
comment:
I
don't
think
putting
the
text
in
for
option.
Three
precludes
people
from
doing
option
two.
H
H
H
I
guess
that's
okay,
but
that
is
an
another
threshold
where
you
have
to
can
make
mistakes.
So
that's
my
only
small
issue
with
three
I'm
still,
okay,
with
the
with
the
evidence
payload
claim,
because
I
think
it's
fine,
because
payload
apparently
is
more
on
the
rim.
Stuff
that
we
are
building
with
here
with
with
thomas
and
co
and
and
evidence
is
more
on
the
the
eat
stuff,
and
it
makes
a
lot
of
sense
to
to
say
yeah.
This
is
not
evidence
when
you
put
it
into
a
heat.
H
D
Ned
yeah,
so
kosovo
has
a
you
know,
a
signature
is
attached
to
it.
It
has
a
signature
attached
to
it.
We
have
a
draft
that
describes
how
to
do
an
unsigned
eat.
Is
this
as
option
are
any
of
these
options?
Are
all
these
options,
this
asserting
or
assuming
that
the
signature
component
of
coast
wood
goes
away,
or
are
we
saying.
E
Yeah
either
way,
so
in
all
of
these
options
the
coast
would
could
be
signed
or
unsigned.
E
I
mean
the
evidence.
One
is
a
little
weird
to
sign
separately.
I
don't
know
what
who
would
be
signing
that
and
the
payload
one
is
presumably
signed.
So
most
cases
I
would
assume
evidence,
ones
are
unsigned
and
payload
ones
are
signed,
but
I
wasn't
thinking
to
require
it
either
way.
H
Yeah
quick
bonus,
question
and
and
same
with
sibo
attacks,
so
sibo
attacks
outside
of
the
envelope
are
an
end
or
inside
of
the
envelope
for
coast.
Is
that
fine
for
you
also,
because
that's
how
we
designed
it
at
the
moment.
E
So
there's
seems
like
there's
general
consensus
that
using
coast
woods
is
a
good
thing
that
we
should
proceed
with
ghost
waves.
We,
like
you,
know
comeds
or
cobrams,
or
I'm
not
sure
what
all
they
they
are
at.
This
point
are
not
going
to
replace
coast
weds
in
the
long
run
is,
is
that
is
that
right.
H
Yeah,
this
is
saying
speaking
to
that
yeah.
That
is
correct.
They
are
not
altering
them.
The
the
the
co-rim
part
extends
a
single
item
into
a
coast
wood,
but
leaves
it
a
coast
bed.
So
so,
of
course,
we
can
better
reference
commits
that
they
can't
do
this
natively.
We
would
have
a
clunky
structure.
We
want
to
do
it
with
the
neat,
orderly
structure,
so
there's
a
tiny
extension
to
close
with
this
rim
stuff,
but
that's
it.
It's
the
same
as
before,.
E
So
I
think
the
next
step
is
for
me
to
take
what
I
heard
here
and
and
work
on
some
text.
So
I'll
go.
Do
that
thomas.
C
Hi
laurence,
sorry,
thomas
here,
so
your
suggestion
would
be
for
a
situation
where
you
don't
have
a
file
system
where
to
anchor
your
core
suites
to
to
define
a
cost
with
extension,
to
handle
that
or.
E
I
I
think,
that's
one
possibility,
if
that's
you
know
unworkable,
or
somebody
comes
up
with
you
know
some
brilliant
alternative
to
ghostwoods.
For
that
that
could
also
be
an
option.
I
don't
think
just
because
we
picked
coast
woods,
we're
picking
the
the
one
and
only
format
for
for
carrying.
You
know
software
descriptions
and
measurements.
C
Okay,
because
for
our
use
case,
the
pc1,
as
you
know,
going
for
crossfit
is
a
bit
overkill,
because
the
overhead
of
the
encoding
and
the
fact
that
we
need
to
please
the
cosmic
format
in
many
respects
that
are
not
essential
to
us.
You
know
creates
this
multiple
bytes
of
rubbish,
basically
that
we
just
need
to
put
there
in
order
to
to
please
the
the
format
so
yeah.
For
the
time
being,
we
have
defined
our
own
software
measurement
claim
right.
C
We
wanted
to
have
something
that
is,
you
know,
on
the
standard
side,
but
going
coursework
at
this
point
in
time.
Doesn't
look
like
a
an
excellent
choice
from
our
point
of
view,
so
we
will
need
to
you
know,
figure
out
something
here.
E
Yeah
I
mean
I
I
we
don't
have
time
for
that
discussion
now,
but
I
think
it
would
be
really
good
to
see
if
we
could
tweak
coast
woods
to
make
them
fit
your
your
uses
better.
So
we
have.
B
E
E
E
Okay,
thank
you
for
all
that
discussion
and
any
other
quick
comments
on
on
cuz.
G
Yeah
thanks
lawrence
sorry
to
insert
this
in
here,
but
just
as
a
disclaimer,
I'm
the
co-chair
of
the
fido
alliance,
iot
working
group,
and
we
we're
developing
a
well
we're
pretty
far
along
in
developing
a
device.
Onboarding
spec,
it's
available
on
our
website
and
and
we
do
have
a
normative
dependency
on
feet.
G
One
of
the
things
that's
been
discovered
is
that
the
way
we
are
using
juice
is
we're.
Taking
our
ueid
is
we're
using
a
we're,
calling
it
something
called
the
guide
in
the
spec
global.
You
you
globally
universal
id,
and
our
reading
was
that
that
maps
directly
to
the
ueid.
So
we
said
that
for
any
payload
we
can
go
ahead
and
transmit
what
we,
what
the
spec
calls
as
a
guide
in
the
ueid
field.
G
Now
one
of
the
things,
though,
with
guide
and
I'll
apologize
for
using
good
and
ueid
interchangeably,
because
I'm
going
to
get
to
a
reason
why
it
may
not
they
may
not
be
used
interchangeably,
is
that
in
the
fido
spec,
a
manufacturer
guide,
which
is
which
is
potentially
provisioned
at
the
factory,
can
be
replaced
by
the
device
owner
after
onboarding.
G
The
current
text
states
that
the
ueid
quote
should
be
permanent,
so
I've
given
so
I've,
given
some
guidance
to
the
fido
working
group
that
we
can
live
with
that
language,
because
it's
a
should
requirement
and
and
just
move
on.
But
the
issue
is
you
know,
the
issue
is
what
it
you
know
is
does
does
the
rats
working
group
feel
similarly
on
this,
and
it
would
be
something
that
I
think
we
need
to
get
resolved
before
last
week
we
may
want
to
resolve
before
last
call.
G
The
issue
has
been
posted.
The
fido
iot
working
group
has
proposed
text
where
we,
where
we,
where
we
just
we're
summarizing
we
describe
where
ueid
could
it
could
be
replaced
during
a
device
life
cycle,
so
this
is
kind
of
so
this
is
kind
of
a
pesky
issue.
I
think
what
lawrence
lawrence
may
have
some
words
on
this
on
privacy,
preservation
and
ueid,
as
well
so
I'll
kind
of
give
the
floor
back
over
to
lawrence
yeah
we're
taking
questions
lawrence.
Did
you
want
to
comment
on
this.
E
Yeah
so
I
mean
my
my
intention:
was
you
know
that
uids
should
be
permanent,
that
they,
maybe
I
should
even
say,
must
be
permanent,
that
this
shouldn't
be
changing.
The
uid
shouldn't
be
allowed
and
then,
in
the
discussion
on
the
on
the
github
issue,
I
proposed
an
s-u-ue
id,
which
is
a
semi-permanent
ueid
which
can
be
changed
on
change
of
ownership
and
and
factory
reset
and
stuff.
Like
that,
I
also
think
there's
other
possibilities
for
addressing
privacy
preservation
for
ueids.
E
So
I
think
there's
some
variety
of
solutions
here,
so
my
my
thought
is
to
try
to
find
you
know
maybe
define
a
couple
of
these
solutions,
but
I
think
this
is
still
open
discussion
right
now
and
I
think
we
should
have
the
discussion
guy.
J
Hi
lawrence
skye,
I
I
I
I
know,
there's
a
lot
of
complexity
when
it
comes
to
identification
of
devices,
but
I
I
assume
you
have
followed
the
ieee
802.1
ar
spec,
which
explicitly
separates
the
manufacturer
id
from
an
id
that
might
be
supplied
by
a
device
owner
and
if,
if
there's
anything
there,
that's
applicable
that
might
help
to.
E
Yeah,
if
you,
if
you
would
just
email
me,
the
reference
that'd
be
great.
Thank
you.
D
Sure
so,
just
the
time
check
we're,
you
know
just
a
couple
minutes
before
we
run
out
of
nerdy
have
other
slides
or
other
topics.
G
Yeah
so
at
least
on
this
issue
98,
what
should
I
take
I'll
ask
cheers?
What
should
I
take
back
to
find
out?
Can
we
live
with
this
this
as
fast
as
back
as
it
stands,
or
does
the
or
or
do
we
or
do
we
need
to
go
offline,
and
we
visit
and
address
this
before
last
call.
E
G
Okay,
it's
holding
up
the
fido
spec
progress,
that's
what
I
mean.
I
should
have
probably
mentioned
that.
So
you
know
I
I
think
if
we're
saying
that
we
don't,
if
the
group
wants
us
to
go
and
revisit
this
and
I'll
say
that
the
fido
stack
has
to
you
know,
you
know
the
use
of
the
photo
spec
for
ueid
may.
It
may
have
to
be
revisited,
though,
because
the
rat's
document
may
evolve.
G
Well,
it's
essentially
both
yeah,
but
yeah
yeah.
I
mean
I've
been
through
this
before,
where
we've
in
other
standard
bodies,
where
we
referred
to
an
id
and
the
it
made
it
normative,
and
then
the
and
then
the
rfc
ended
up
with
substantial.
B
G
So
I
think,
at
least
for
friday
we'd
like
to
avoid
that
so
because
then
we.
G
B
Okay,
guys
we're
we're
out
of
time,
so
my
suggestion
would
be
to
to
take
this
issue
on
the
mail
list
lawrence
right,
because
minimally,
at
least
there
needs
to
be
clarification
on
how
and
the
intent
of
the
ids
that
we're
specifying
in
the
e-draft.
B
But
given
that
we're
out
of
time,
it'd
be
good
to
just
continue.
The
discussion
on
the
main
list.
Yeah.
A
And
milestones
we
did
not
cover
those
it
I'd,
love
to
get
an
estimate
from
you
and
I'll
bring
it
to
the
list
lawrence.
In
terms
of
where
you
think
eid
is
at,
I
don't
think
you're
going
to
make
the
milestone
and
tuda,
and
some
of
the
other
drafts
won't
make
your
milestones
either
some
of
the
other
ones
that
are
earlier
on
the
milestones,
I
think
look
fine,
so
we'll
do
that
on
list.
Thank
you.