►
From YouTube: IETF108-RATS-20200728-1300
Description
RATS meeting session at IETF108
2020/07/28 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
A
A
Yes,
that's
what
he
mentioned,
which
is
why
I
told
him
to
join
10
minutes
before.
Okay,
we're
now
eating
a
minute
into
the
agenda,
so
thank
you
for
all
those
who've
joined.
This
is
the
remote
attestation
procedures
working
group
session
welcome.
This
is
our
second
day
for
rats.
We
have
two
sessions.
This
is
the
first
and
the
shorter
session
of
the
two.
A
A
I
noted
that
I
can
do
the
jabber,
since
I
will
be
watching
the
chat
as
well,
so
I
can
be
noted
as
a
jabra
scribe,
but
we
do
need
note
takers
so
ned
if
you
can
help
watch
the
codium
d
and
help
with
the
notes.
I
would
like
to
see
a
couple
more
people
volunteer
and
note.
I
can't
move
forward
unless
we
get
volunteers.
A
Can
I
get
one
more
okay,
thank
you.
So
we've
got
we've
got
robin
chris
will
help,
as
so
will
michael
excellent.
Thank
you
okay.
So
we
also
because
we
need
to
do
a
couple
of
consensus-
calls
wanted
to
do
a
a
hum
test.
A
A
C
A
All
right,
okay,
so
so
I
am
running
out
of
time.
So
let
me
run
this
agenda
bash.
Really
quick!
We've
already
gone
through
the
administrative
tasks.
A
Today,
we're
focused
on
a
cluster
of
presentations
revolving
around
the
network
device
at
the
stations
focused
on
the
tpm,
with
the
pub
sub
models
leading
to
the
the
general
description
of
the
different
interaction
models.
If
you
will
for
how
you
carry
out
the
attestations.
G
Okay,
thank
you.
So
my
name
is
guy
fedorko
I've
been
working
on
this
remote
integrity,
verification
work
with
with
jessica
and
eric
we've
presented
this
work
a
couple
of
times
in
previous
meetings
and
there's
only
a
small
update
this
time,
so
I
will
try
and
get
through
the
material
fairly
quickly.
Next,
please.
G
Thank
you
right,
so
as
a
reminder,
the
objective
is
to
standardize
the
technique
for
using
trusted
platform,
module
tpms
to
report
on
the
state
of
the
state
of
integrity
of
low-level
software
on
devices
we're
focusing
on
network
devices
at
the
moment,
but
this
is
applicable
to
other
kinds
of
things,
industrial,
iot
and
so
on,
and
the
point,
of
course,
is
to
give
network
operators
an
opportunity
to
determine
whether
their
devices
are
out
in
the
network
are
healthy.
G
This
is
based
on
the
background
check
model
that
is
described
in
the
in
the
architecture
document.
This
flowchart
shows
the
the
challenge
response,
as
described
in
hank's
interaction
model
and
again
that
is
more
or
less
the
same
as
the
previous
incarnations
of
this
next.
G
Release
our
goal,
you
know,
there's
in
the
topic
of
attestation,
there
are
a
lot
of
different
things
that
one
can
attest.
What
we
wanted
to
do
here
was
to
focus
a
little
bit
on
what
it
is
that
riv
does
a
phrase
or
a
test,
and
and
and
of
course,
by
extension,
what
it
doesn't.
G
G
Next,
please,
and
the
goal
of
that
appraisal,
of
course,
is
to
ensure
that
the
higher
level
software
stack
is
in
good
enough
shape
to
trust
it
for
other
kinds
of
assertions
and
attestations
using
using
a
pc.
G
A
tpm,
of
course,
is
often
focused
around
these
so-called
platform
configuration
registers,
pcrs,
which
are
used
to
record
the
hashes
of
attested
objects,
it's
natural
to
tend
to
focus
on
the
pcrs
themselves,
but
it's
useful
to
remember
that
the
pcrs,
while
sometimes
the
value
in
the
pcr
may
itself
be
sufficient
to
determine
at
a
station
or
not.
It's
it's
helpful
to
remember
that
the
pcr,
in
fact,
is
a
hash
of
a
bunch
of
entries
that
are
individually
specified
in
the
accompanying
log
file.
G
So
it's
it's.
Usually
the
log
file
that
you're
at
that
you're,
using
for
verification
and
the
pcr
itself,
is
just
there
to
to
check
it
to
ensure
that
the
log
file
has
not
been
tampered.
That's
a
kind
of
a
fine
distinction,
but
in
some
cases
we'll
see
later,
it's
actually
helpful.
G
There's
there's
careful.
G
Specification
of
some
of
the
pcrs
by
tcg,
specifically
for
uefi
bios,
there's
a
specification
for
that
which
has
been
reviewed
quite
carefully
and
is
very
tightly
specced,
but
that
covers
only
one
case:
the
uefi
bios,
and
there
are
a
lot
other.
There
are
a
lot
of
other
operating
environments
out
there,
so
there's
room
for
additional
work
on
on
narrowing
the
scope
of
what
is
measured
into
which
pcr.
G
This
outlines
the
conventional
allocation
of
pcrs
at
the
high
level.
There
are
16
of
them
in
the
minimal
dpm.
G
G
G
We
should
note,
as
eric
may
say
later,
that
other
pcrs
may
need
to
be
allocated
for
specific
tasks
if
you
want
to
do
a
streaming
streaming
events
since,
if
you
stream
apcr
you'll,
need
to
get
every
log
entry
that
goes
along
with
it
in
order
to
make
sure
you
understand,
what's
going
into
the
thing
so
again,
the
message
simply
is
that
there
are.
G
G
Finally,
this
this
picture
still
shows
again
the
relationship
between
this
draft
and
the
some
of
the
other
work
and
rats.
Obviously,
it
depends
on
the
on
the
architecture.
Document
for
terminology
and
hank
has
been
maintaining
the
the
charts
of
who
who
sends
what
to
whom,
in
the
interaction
model
which
is
referenced
in
this
document
and,
of
course,
coming
out
the
other
end.
G
The
chara
is
the
yang
implementation
of
how
to
do
this,
tpm
based
attestation
and
the
subscription
model
as
well
and
and
that
forms
the
basis
of
trust
trusted
path.
Routing
next,
please.
G
So
to
finish,
we
do
need
in
the
riv
document
another
round
to
line
up
the
nomenclature
with
the
architecture.
I
think
we're
pretty
close,
but
the
you
know,
architecture
has
evolved
a
little
bit
and
when
it's
stabilized
and
it's
and
we're
all
ready,
then
I'll
I'll
go
through.
We
will
go
through
again
and
and
make
sure
that
the
nomenclature
is
exactly
in
line.
G
Some
of
the
tcg
specifications
have
moved
forward
and
I'll
update
the
notes
for
that
as
well,
so
some
have
changed
from
draft
to
to
a
full
release,
but
at
this
point
we're
not
planning
any
further
substantial
content.
There
are
lots
of
other
things.
One
could
do,
but
I
think
for
this
for
this
round
of
the
document
we're
going
to
at
the
moment,
we're
inclined
to
call
it
call
it
complete.
A
Well,
yeah
yeah,
so
so
guy
you
have
there's
about
80
participants
here,
including
the
chair,
so
we
could
ask
here
now.
Could
we
ask
volunteers?
A
Well
let
me
ask
first
the
question:
has
anybody
read
this
draft
who's,
not
an
author
and
you
can
go
ahead
and
just
send
audio.
I
A
Work
got
it
so
if
you've
read
the
draft
just
request
to
send
audio,
I
guess.
A
Yeah
I
mean
I've
skimmed
through
it.
I
don't
count
okay,
what
we're
up
to
six
six
or
seven
okay,
so
that's
great!
It
would
be
good
to
get
feedback.
A
I
H
H
So
it's
really
just
trying
to
make
sure
that
we
have
the
right
context,
a
lot
of
which
has
been
described
by
a
guy
next
slide.
H
There's
a
lot
of
drafts
that
are
involved,
as
was
mentioned
before
in
the
whole
chain
of
giraffes,
from
the
language
that's
being
developed
with
the
architecture
team
through
what
guy
described
in
the
profile
and
over
to
the
right
side,
which
is
starting
to
get
to
interface.
Specification
chira
is
an
interface
specification
and
there
are
other
interface
specifications
which
we're
going
to
be
talking
about
in
upcoming
presentations,
but
this
just
tries
to
show
the
the
flow
of
documents
across
the
working
group.
H
H
There
were
issues
about
getting
rid
of
identity
or
getting
rid
of
strings
for
different
types
of
cryptos
and
trying
to
really
reduce
the
number
of
possible
errors
that
can
be
induced
by
allowing
anybody
to
input
any
string
for
known
crypto,
algorithm
types
and
we'll
talk
more
about
that
in
a
second,
I'm
not
going
to
talk
through
all
the
issues
addressed,
but
I'm
going
to
highlight
a
few
of
them
and
they
were
sent
to
the
list,
and
hopefully
people
have
also
seen
the
items.
H
If
they've
checked
out
the
github
repository
a
couple
of
the
big
issues
that
we
did,
where
we
simplified
the
access
for
devices
that
don't
have
multi-line
cards,
we
got
the
draft
ready
for
last
call
when
we
started
to
get
tpm
name
of
all
and
other
things
removed.
So
we
didn't
have
catch-all
items
in
the
yang
model
and
there
was
a
request
out
before
for
things
like
making
sure
that
the
features
for
tpm
1.2
only
appeared
in
tpm
1.2
devices
and
features
for
tpm
2.0
only
appeared
for
tpm
2.0
devices.
H
H
One
of
the
issues
I'm
going
to
be
talking
about
is
in
a
second
is
issue
8.
One
of
the
questions
that
came
up
on
the
mailing
list
is:
why
are
we
using
certificate
name
as
an
identifier
for
a
tpm
that
really
has
to
do
with
the
keying
and
improving
the
improving
the
ability
to
find
when
keys,
change
and
be
able
to
get
the
information
securely
off
the
device
we've
used
now
use
certificate
name
as
a
way
of
validating
what
tpm
is
doing.
H
H
The
yang
model
tree
has
a
couple
benefits
that
were
not
there
before.
As
I
mentioned,
we
now
don't
require
a
compute
node
in
order
to
identify
tpm.
This
means
that
we've
simplified
access
for
single
tpm
devices
and,
as
I
mentioned
below,
there's
a
new
certificate
name
that
is
going
to
come
from
challenge
response
rpcs
and
that
certificate
name
allows
you
to
check
into
the
config
tree
right
here
to
find
out
what
tpm
name
is
the
owner
of
a
particular
certificate
which
is
doing
signing.
H
Now.
We
have
two
questions
to
ask
today
and
I'm
going
to
go
to
the
next
slide.
For
that
first
question
that
comes
up
is
instead
of
strings.
We
now
have
yang
identities
to
identify
asymmetric
algorithms,
and
if
we
look
at
the
asymmetric
algorithms
there's
a
whole
set
that
we
could
include
in
the
draft.
They
include
algorithms,
which
are
itf
definitions
from
other
places
that
you
can
see
in
orange,
on
the
left
and
since
they're,
not
in
tpms.
H
I
don't
think
there's
a
lot
of
reason
to
include
them
as
a
viable
algorithms
for
our
models,
there's
also
algorithms
in
red,
which
are
non-symmetric
algorithms
and
it's
probably
not
worth
showing
algorithms
that
are
asymmetric
in
the
in
this
particular
yang
model.
So
I
guess
one
of
the
questions
that
I
want
to
bring
to
the
list
is:
should
we
just
reduce
the
set
of
algorithms
supported
in
this
draft
to
just
those
tpm
asymmetric
algorithms
that
are
currently
exposed
in
the
existing
tpm,
1.2
and
2.0
standards?
H
Now
we
are
able
to
extend
this,
but
I
do
think
that
that
we
want
to
get
feedback
on
the
list
of
should
we
trim
the
list
of
algorithms
just
to
those
which
could
be
hit
on
these
chips,
and
I
do
think
that's
best
for
the
for
the
list
rather
than
a
hum
question.
H
There's
also
a
another
question
question
two
on
the
next
slide
and
there
is,
I
think
it
was
way
pan
or
somebody
from
huawei
who
asked
for
a
new
log
type
for
network
device
boot
and
we
haven't
gotten
any
feedback
yet
where
people
do
want
to
have
the
network
device
equipped
boot.
But
I
think
that
we
need
to
have
some
support
for
that
from
different
people
in
the
working
group
before
we
add
it
into
the
model.
H
So,
yes,.
A
Might
audio
drop
there
for
a
second?
So
on
the
previous
slide,
when
you
were
asking
the
question,
you
should
take
it
up
to
the
list,
but
just
so
you
note
on
the
chat.
There
were
a
couple
of
comments
there.
So
michael
richardson
was
asking
whether
the
list
of
algorithms
were
from
the
yang
algorithm
types.
Draft
and
ira
was
suggesting
to
delete
xiaomi,
which
I
think
we
should,
because
it's
been
deprecated
already.
H
That
works
for
me,
one
goes
out
in
terms
of
the
listing
of
algorithms.
The
listing
of
algorithms
came
from
the
tcg
algorithm
types
that
are
supported
from
tpms
for
anything
in
that
points
up
to
those
in
terms
of
the
itf
ones.
There
was
a
contribution
from
somebody
earlier
saying
these
are
some
of
the
algorithm
types,
so
each
one
had
a
different
source
for
where
it
came
in,
and
so
I'm
trying
to
cull
from
multiple
sources,
and
my
assertion
is
that
is
what
it
is.
So
we
can
continue
that
on
the
list.
K
H
All
right
so
question
two
was
a
new
log
type
and
again
I
think
we
need
to
keep
that
and
then
last
slide
is.
Are
there
any
other
questions?
Do
you
guys
have
anything
else?
One
thing
I
think
we're
ready
for
if
people
are
okay
after
this
is
I
want
to
submit
this
for
the
yang
doctors
review
prior
to
going
to
last
call,
the
young
doctor
should
start
to
engage
on
the
draft
and
I
think
it's
ready
for
that
request.
If
other
people
agree
june
q.
I
Yep
I'll
let
mike
through
okay
mike
you
can
speak
hi
mike
jones
from
microsoft.
I'd.
C
A
question
about
rsa
with
sha1:
I
will
point
out
just
for
reference
that
for
the
w3c
web
authentication
work
where
there's
tpm
attestations,
they
did
choose
to
list
the
rsa
sha-1
algorithm
and
in
fact
the
cose
working
group
is
just
finishing.
A
draft
that
registers
that
now
it's
a
deprecated
algorithm
but
because
particularly
tpm
1.2
uses
it.
C
C
H
J
I
I
don't
think
it
matters,
an
algorithm
is
deprecated.
I
think
you
should
you
know
if
there's
a
device
out
there
that
can
support
md4,
then
by
golly.
I
think
we
want
to
know
that
it's
using
md4
so
that
we
can
declare
it
as
not
sufficiently
tall
enough
to
play
right.
So
I
think
it's
really
important
that
that
anything,
that's
reportable
by
the
real
device
that
was
ever
made
should
be
in
the
list
of
things
there.
That
doesn't
mean
that
the
appraisal
policy
has
to
accept
it.
H
So
there's
the
identities
in
the
gang
models
that
are
viable,
there's
also
the
list
that
are
allowed
for
a
particular
device.
So
just
because
we
allow
it
doesn't
mean
the
customer
cannot
shut
it
down
by
including
not
including
an
algorithm
under
supported
algos,
which
is
the
specific
list
of
what
are
viable
on
a
particular
platform.
A
So
it
may
be
useful
for
you
to
clarify
allowable
from
from
the
notion
of
a
control.
That's
where
I'm
getting
confused,
which
is
why
I
was
saying
well:
xiaowan
is
deprecated
versus
reporting,
so
I
can
see
the
argument
for
including,
if
that
you
want
to
report
anything,
that's
being
used
or
capable,
but
from
the
controls.
A
H
All
right,
so,
I
think
a
good
way
to
do.
It
would
just
be
to
put
under
supported
algorithms
that
we
recommend
not
allowing
sha1
to
be
configured
as
allowed,
but
that's
up
to
the
user.
So
there's
a
difference
between
the
identity
list
and
which
ones
we
want
to
support,
which
is
that
second
line,
and
that
I
can
cover
it
in
the
yang
model
by
just
adding
that
clarification.
But
it's
not
recommended
in
the
description.
I
E
Hi
eric,
I
just
wanted
to
clarify
what
you
just
said
to
kind
of
nancy,
but
because
I
think
where
we
were,
I
was
going
to
make
the
same
point.
The
idea
is
that
we
want
to
potentially
encode
the
insecure
algorithms,
because
some
version
of
tpm
in
the
past
supports
it,
and
we
want
to
be
able
to
expose
that,
but
we
would
provide
appropriate
language
in
the
security
considerations
or
other
kind
of
processing
guidance
to
suggest
that
this
should
be
a
low
confidence.
E
H
And
we
also
have
the
ability
to
allow
a
customer
has
the
ability
to
allow
or
not
allow
which
algorithms
from
the
chip
are
there.
So
we
have
a
couple
different
ways
of
doing
both
protections
in
the
text,
as
well
as
the
list
of
supported
algorithms
for
a
platform
being
configured
in
that
list.
I
pointed
to
earlier.
E
K
L
Okay,
I
have
two
comments.
First,
it's
about
the
issue.
Eight.
I
I
think
I
strong
suggest
you
to
consider
to
use
a
tpm
as
tbm
name
as
the
identifier,
because
if
you
use
the
certificate
name
as
the
identify,
but
when
the
tester
presents
a
new
certificate
name
and
the
verifier
doesn't
doesn't
know
this
certificate
certificate
name,
the
verify
needs
to
do
our
full
query
to
the
a
tester
to
to
query
all
the
certificates
of
all
the
tpms.
L
So
I
think
this
can
be
solved
by
using
the
tpm
name
as
a
identified
and
further
discussion
can
be
taken
to
the
list
and
the
next
is
about
the
issue.
14
and
also
is
a
question
two.
I
I
like
the
way
to
use
to
use
the
this.
The
the
new
log
type
is
based
on
ima
and
it's
it's.
How
do
you
say
it
can
be
seen
as
a
and
the
fashion
of
ema
to
measure
the
boot
progress?
L
So
this
is
a
neural
log
type,
but
it
it's
not
the
same
with
the
email
log
type,
and
I
I
like
to
the
working
group
to
consider
move
forward
this
one
yeah.
H
All
right
two
real
quick
answers
and
then
I
can.
I
can
wrap
up
on
the
certificate
type.
We
can
continue
on
the
list,
but
if
you
get
a
new
certificate,
you're
going
to
have
to
go
to
the
yang
model
tree
anyway
to
prove
that
it's
the
right
one.
So
we
don't
save
anything
on
the
log
one.
If
anybody
else
wants
it,
you
know
yeah.
Definitely,
let's
add
it
all
right.
I
think
that's
it.
I'm
just
trying
to
wrap
up
here.
H
H
H
This
draft
is
the
result
of
the
integration
of
draft
ixia,
as
well
as
as
section
5
from
the
trusted
path,
routing
document
from
last
time,
and
so
the
entire
purpose
is
to
allow
you
to
go
ahead
and
get
challenge
response
information
get
rid
of
it
by
having
a
telemetry
stream
of
security
information
next
slide.
H
This
is
just
showing
before
that.
We
have
the
same
inputs
to
this
draft
as
before.
It
is
very
much
based
on
the
charge
raft
we're
just
extending
the
charge
raft
in
a
couple
key
ways.
H
Next
slide,
as
I
mentioned
before,
we're
trying
to
move
from
a
periodic
polling
or
or
a
model
where,
when
we
extend
a
pcr
in
a
tester
that
we
have
the
information
acquired
for
your
challenge
response
and
we're
trying
to
move
to
streaming.
Events
as
they
are
pushed
off
the
system,
and
this
allows
you
to
do
new
things
such
as
when
there's
new
software
installed,
see
the
information
from
the
pcrs
right
away.
H
H
Next
slide
is
just
a
mapping
of
the
notifications
that
are
coming
out
of
what
we're
calling
an
attestation
event
stream.
You
subscribe
via
rfc
8639,
which
is
yang's
subscription
to
an
event
stream.
That
is
meant
just
for
attestation.
Events
and
what
happens?
Is
you
get
the
results
of
the
pcr
extensions,
as
well
as
the
attested
information
as
it
occurs?
H
One
of
the
things
that's
neat
with
a
tpm2
is
you
can
use
a
difference
in
the
timers
from
when
the
evidence
was
generated
at
the
first
query
and
the
difference
from
the
second
push
and
be
able
to
prove
that
the
evidence
is
fresh,
even
without
the
sending
of
a
new
nonce
for
each
challenge
response.
So
I
see
a
question
from
dave.
D
Hi
eric
yeah,
my
question
is
the
first
line
that
show
is
shown
as
originating
going
to
the
tester,
and
the
question
is:
how
does
it
know
who
to
subscribe
to?
Is
there
some
line,
that's
missing,
or
how
does
that
work?.
H
We're
taking
chara
as
the
starting
point,
so
you
still
have
to
go
and
understand
from
chara
who
you're
subscribing
to
there's
no
discovery
mechanisms
defined
here
you're.
It
starts
from
the
point
of
view
as
if
ciara
knows
who
to
go
to
the
subscriber
knows
who
to
go
to.
H
All
right
there's
a
couple
ways
to
handle
that
one
of
the
ways
is
that,
with
a
subscription,
there
is
keep
a
lives
based
on
the
type
of
transport,
both
with
net
conf
and
hdp.
H
H
As
I
note
the
there's
a
number
of
notifications
which
are
just
pushing
in
a
notification
what
you'd
normally
get
out
of
a
challenge
response
and
you
were
able
to
replay
notifications
so
that
when
you
come
online,
you
can
get
all
the
events
automatically
that
occurred
since
boot.
Next
slide,.
H
Basically,
what
we
have
is
extending
chara
to
figure
out
what
attestation
key
should
be
used.
What
pcrs
are
subscribable
the
maximum
delay
to
bundle
evidence
and
a
heartbeat,
as
was
mentioned
before
you
want
to
have
a
heartbeat
for
what
your
keep
alive
state
is
to
prove
your
pcrs
are
in.
You
know
an
expected
state,
because
you
don't
want
to
to
miss
events
being
pushed
and
last
slide.
H
I
guess
the
question
is:
is
there
interest,
please
let
the
mailing
list
know
and
I
don't
think
we're
ready
for
an
adoption
call
yet,
but
I'm
hoping
that
people
will
be
interested
in
adoption
call
at
or
before
ietf109.
So
any
other
final
questions.
I
know
I'm
low
on
time.
A
B
No,
I
can
all
other
meetings
had
them
foster
fabulous,
sorry
yeah.
So
this
is
about
the
aforementioned
reference
interaction
models.
These
are
currently
not
part
of
the
architecture.
I
issued
an
email
beforehand
and
we
have
new
authors,
so
that
is
the
summary
of
the
introduction
slide
next
slide.
Please.
B
So
we
now
enhanced
the
interaction
model
draft
with
the
three
typically
used
interaction
models
we
find
in
rats
and
outside
of
the
ietf.
Actually,
today,
chara
has
been
mentioned
a
lot.
It's
an
acronym
for
challenge,
response,
remote
attestation,
that's
the
thing
typically
initiated
by
the
verifier
using
enuncia.
You
know
about
that.
I
think
I
would
just
reiterate
it.
This
is
used
by
the
before
mentioned,
highlighted
drafts,
but
there
is
also
a
tiny,
easy
to
understand
and
quick
to
implement
proof-of-conception
for
generous
response
using
co-app
and
cbor.
B
Look
at
that
it
is
using
the
relatively
cool,
I
have
to
say,
a
library
from
lawrence,
a
civil
library
that
is
a
qc
board,
and
it
is
at
the
moment
only
based
on
tpm
implementations.
We
are
really
looking
forward
for
a
tee
and
create
some
eats
at
some
point.
Then
the
second
one
there
is
edition,
which
is
the
general
model
of
time
based
remote
station.
There
are
examples
for
that
in
the
architecture
appendix
it's
relatively
straightforward.
B
Once
you
got
it,
there
was
a
significant
update
to
the
text
that
your
users,
the
for
the
two
implementation,
for
example-
it
uses
now
architectural
language.
So
that's
the
one
where
you
can
simply
send
unsolicited
evidence
to
a
verifier,
and
that
will
be
okay,
no
nonsense
required
at
all.
You
can
also
simply
get
them
via
restful
operations
and
again
you
don't
have
to
convey
a
nonce
in
the
request
and
then
there's
a
hybrid
about
this.
Basically,
if
you
want
to
have
this
point
in
time,
that
is
basically
time
based.
B
You
do
sorry
that
you
established
this
this
epoch,
especially
it's
basically
a
request
response,
it's
a
subscription
and
then
everything
gets
pushed
to
you.
So
no
nonsense
in
after
that,
but
the
the
thing
that
you
get
is
a
reused
point
of
time.
There
are
also
things
that
are
using
this
right
now.
I
think
the
one
by
frank
is
timing
out,
so
that
is
being
replaced
by
the
subscription
to
network
devices
draft
that
just
was
presented
by
eric.
B
So
these
three
things
are
now
illustrated
sorry
for
beginning
here
in
the
mod
and
the
id
itself,
they
all
come
with
really
fancy
and
human
readable
sequence
diagrams,
like
there
you've
seen
those
before
I
think
by
by
guy's
presentation.
There
was
a
derivative
of
it
using
timestamps
and
a
specialization
of
that
other
drafts
do
it's
the
same
way,
and
that
is
why
this
id
exists.
B
It
is
because
all
the
other
solution
drafts
and
even
the
profile
drafts
use
the
same
way
to
do
interactions,
and
there
was
a
lot
of
hands
and
forth
how
this
really
looks
like
and
how
this
works,
and
now
we
came
to
the
conclusion
that
it
is
really
beneficial
to
have
a
single
point
to
highlight
the
fundamental
basics,
how
protocols
or
profiles
or
approaches
even
are
defined
by
this
next
slide.
Please.
B
And
then
there
is
a
new
addition
to
this
id
some
thing
called
direct
anonymous
attestation
and
peer
reviews
of
the
slides,
told
me
wow.
This
is
way
too
complicated
to
explain
it
in
a
single
slide.
I'm
sorry,
I
kept
the
slide
because
we
have
now
two
authors.
This
is
liquid
and
chris
from
surya
university.
Basically,
I
would
like
to
say
the
inventors
of
direct
anonymous
attestation.
B
It
is
basically
at
the
station
not
by
a
single
a
tester
but
by
a
group
of
attesters,
and
you
cannot
distinguish
who
will
sense
so
there's
a
k
anonymity
here
you
need
a
enough
large
group
of
attachers
to
be
anonymous
in
that
group,
but
there
are
procedures
to
do
that,
and
this
is
basically
using
group
signatures
and
a
joint
procedure
and
and
all
small
little
additions
that
can-
and
that
is
the
important
thing-
reuse,
the
current
architecture.
It's
absolutely
fitting
into
the
architecture.
B
Point
of
view,
no
new
roles,
no
new
conceptual
messages
or
such
there
is
but
a
single
new
duty
to
the
endorser,
and
that
is
a
daa
issuer,
because
you
cannot
use
the
credential
of
a
single
tester
because
that's
not
anonymous.
You
have
to
have
a
new
thing
that
is
a
daa
credential
that
is
issued
by
this
dia
sutra.
B
That's
an
only
new
duty
defined
in
this
scope,
otherwise
it's
directly
comparable
to
the
architecture
or
it's
fitting
the
mapping
to
the
architecture
and,
most
importantly,
it
can
reuse
the
existing
interaction
models
and
that's
basically
a
amplifier
to
see
how
these
interaction
models
actually
are
universal,
even
with
different
concepts
than
the
classic
attestation,
where
you
can
at
the
first
step,
always
identify
their
tester
quite
well,
and
that
is
not
so
good
for
privacy
in
some
some
scenarios,
please
read
the
content
here.
B
I
could
go
through
the
slides,
but
again
it
is
a
little
bit
complicated
to
read
the
first
time.
I
think
the
most
important
labels
here
I
have
to
reiterate,
are
group
signatures.
It's
about
classes
of
devices
and
the
group
has
to
be
big
enough
for
in
order
for
it
to
work.
I
can
have
any
kind
of
questions
about
this
later.
I
am
not
looking
at
the
chat
right
now.
It's
because
of
a
time
I
think
running
a
little
bit
through
these
slides
next
slide.
Please.
B
So
this
was
the
question
I
finally
restated
on
the
email
list.
We
had
a
rather
good
understanding
that
these
are
good
questions.
I
was
posting
them
in
the
moratorium
time
to
see
how
should
this
content
be
covered.
There
were
this.
Hopefully,
there
are
now
well
known
options
of
each
model
in
in
own
draft,
all
models
in
a
single
draft,
all
models
being
added
to
the
architecture
or
going
to
an
appropriate
solution
id.
B
B
A
Think
you're
asking
us
as
chairs
or
as
individuals,
so
we
started
the
discussion
on
the
previous
session.
I
recall
to
see
if
there
was
interest
on
this.
We
had
discussions
in
that
as
you've
already
noted
hank,
there
are
a
couple
of
drafts
that
are
already
defining
instances
of
these
models.
So
it's
fine.
A
I
just
want
to
make
sure
we
don't
get
cut
off
from
neat
echo
because
our
time
is
about
to
expire.
I
think
the
first
question
is:
is
there
merit
in
having
a
general
discussion
of
the
model
or
models
defined
based
and
and
so
I
would
ask
that
first
question
and
then
from
there
it's
the
question
of
the
options
as
as
you've
listed,
and
so
I
haven't
looked
at
the
responses
since
yesterday.
A
I
know
that
there
was
some
preference
to
the
others,
but
in
the
interest
of
time.
Let's
take
these
questions
to
the
list
to
confirm,
and
so
I
guess
as
chairs,
not
I
guess,
as
chairs
we
can
formalize
the
questions
so
to
help
you
move
forward,
how's
that.
B
Yeah,
that
would
be
excellent.
I
think
we
can
build
on
the
existing
question.
I
recapped
context
and
everything
so
maybe
deriving
now
procedural
questions
from
that
would
be,
I
think,
in
order.
J
A
Okay,
okay,
so
before
we
get
cut
off,
I
think
that
was
all
of
the
agenda
that
we
wanted
to
cover
today.
Unless
there's
anything,
that's
really
quick.
We
again
have
a
full
agenda
tomorrow.
A
Okay,
I
think
michael
just
expressed
his
opinion
of,
cannot
live
with
option
three
okay,
so
with
that
before
we
get
cut
off.
Thank
you,
everyone
for
participating,
and
we
will
continue
tomorrow,
bright
and
early
for
me
anyway.