►
From YouTube: ACE WG Interim Meeting, 2020-02-25
Description
ACE WG Interim Meeting, 2020-02-25
A
Okay,
so
good
morning,
everyone,
let's
start
the
interview,
ace
intermitting
of
February,
25,
I'm,
sure
everyone
is
aware
of
the
note.
Well,
not
let
us
know
we
have
a
minute
taker.
A
C
Yes,
so
you
might
have
seen
the
very
extensive
review
from
then
I
was
hoping
he
would
be
able
to
join,
but
probably
not
so.
The
status
right
now
is
I
implemented.
Most
of
the
changes
from
Ben's
review.
There
is
a
pull
request,
which
is
still
open.
I
got
some
additional
minor
comments
this
morning
and
I
also
have
implemented
those,
so
this
is
basically
ready
to
be
merged
and
I,
don't
foresee
any
issue
with
that.
C
Yeah
and
issues
is
summarized
in
in
in
the
issue
26,
so
you
can
see
it's
like
89
out
of
100.
Five
comments
are
answered
right
now,
so
if
you
do
want
to
take
a
look
at
the
draft
right
now,
the
diff
with
the
latest
summation
is
here,
and
there
are
some
of
the
other
open
points
that
were
discussed
in
the
thread
waste
then,
and
that
I
would
like
to
bring
up
here.
So
everything
that
is
still
open.
It's
in
the
next
slides
next.
C
So
two
of
the
points
that
the
ban
had
was.
It
is
a
bit
of
one
second
mute
here.
Yes,
it's
a
shame
that
we
have
to
find
algorithm
based
on
annoyed
when
I
see
it
because
we
say
you
need
to
select
H,
mac-based,
HK,
D,
F,
algorithms
and
aad
algorithms,
from
the
cosy
algorithms
that
are
H,
Mac,
basic
or
aad.
C
A
So,
just
for
me
to
to
understand
that
Ben
is
asking
you
to
specify
that
explicitly.
B
C
C
B
C
C
So
next
comment
was
about
the
replay
window.
So
right
now
this
Oscar
security
context,
field
called
replay
window
or
in
the
last
submitted
version,
and
the
idea
was
that
the
AES
is
able
to
tell
the
resource
server
what
type
and
size
of
replay
window
to
use,
but
after
Dan's
comment,
I
do
not
see
a
reason
why
das
should
send
this
info
to
DRS,
and
these
are
implementation
related
details.
C
Each
RS
could
have
its
own
and
then
agreed
that
he
doesn't
see
the
point
of
having
this
field
in
the
Oscar
security
context
object
and
if
it's
needed
in
the
future
anyway,
we
can
add
it
as
there
is
a
registry
for
adding
parameters,
so
I
removed
it.
It's
now
done
in
the
PR
that
I
wanted
to
bring
this
up
in
case.
Anybody
had
objections.
B
C
So
then,
the
next
point,
so
this
is
yes,
so
the
profile
indicates
that
the
client,
a
s
and
or
resource
server,
a
s
you
saw
score
or
is
that
information
not
expected
to
be
encoded
in
any
protocol
element.
So
this
is
a
question
that
been
had
in
the
review,
because
in
the
Oscar
profile
we
specified
that
all
scores
is
used
between
client
and
resource
server.
That's
the
whole
point
of
the
profile
to
set
up
a
score
between
client
and
resource
server,
and
we
say
that
client
is
an
RSA.
S
is
optional.
C
Pasted
that
the
whole
section
of
let's
review
what
our
exchange
here.
So
my
answer
was
as
of
now
that
the
information
is
not
expected
to
be
encoded
in
any
protocol
element
and
I
wanted
to
also
then
want
to
hear
from
the
working
group.
If
there
are
other
known
uses
like
this
I'm,
not
sure
what
it
means
by
all
the
known
uses.
B
Another
known
use
for
this
is
the
mqtt
profile,
which
is
using
TLS
and
the
MQTT
messages.
Token
messages
and
it's
using
JSON
instead
of
sea,
bore
and
is
actually
talking
different
ways
between
the
server
and
the
between
this
between
the
broker
and
a
client
and
the
client
and
the
a
s
at
times.
They
don't
have
to
be
this
they're,
not
you're,
not
talking
the
same
utt
profile.
D
C
B
D
B
C
C
C
Okay,
so
these
are
the
bigger
open
points,
the
first
one,
this
mechanism
of
limiting
the
resource
or
repeat
the
identify
of
the
client,
which
then
commented
on
and
after
some
discussion
with
my
co-authors
I,
we
agreed
that
probably
it's
best
to
just
remove
this
and
just
assume
that
there
is
one
a
yes
that
is
going
to
assign
identifiers
and
Jim.
You
had
comment
that
I
reported
here:
it's
not
the
only
consideration.
C
The
above
statement
presumes
that
only
das
is
going
to
be
assigning
client
identifier.
If
the
RS
uses
a
different
method
of
doing
authentication
such
as
Lake,
then
there
is
a
chain
chance
for
collision
at
that
point
as
well.
How
would
you
run
Lake
I
think
that
running
Lake
with
the
Oscar
profile
would
need
to
be
specified
somewhere.
C
B
Same
resource
server,
yes,
which
means
if
the
score
message
comes
in
and.
B
B
C
C
D
B
A
A
E
B
C
C
A
A
A
A
C
C
B
Well,
it
needs
to
be
looked
at.
It
has
to
cover
two
things.
One
is
how
often
are
ace
tokens
going
to?
How
often
is
the
key
and
then
age
token
going
to
be
reused
in
terms
of
re-registered
and
what
sort
of
randomness
is
expected
from
both
the
client
and
the
server
to
make
sure
you
don't
do
you
don't
generate
the
same
key
twice?
That's
the
analogy!
So
he's
looking
for.
B
C
E
C
C
C
C
C
C
Think,
okay
I
will
try
to
add
some
text
like
that
and
and
let's
try
to
also
continue
the
conversation
with
Ben
and
then
the
last
point
is
then
did
not
want
us
to
use
scene
ons
and
he
wants
us
to
register
two
new
parameters
to
transport
the
nonces
and
since
this
was
a
decision
that
was
taken
in
the
working
group
during
the
meeting,
I
just
wanted
to
check
that
the
working
group
is
fine.
We're
doing
this
change.
I,
don't
have
a
strong
opinion.
Yeah
I,
don't
care,
but
yeah
I.
C
So
the
plan
is
recap:
I
will
do
the
the
changes
that
it
just
exchanges
that
we're
discussed
today
as
soon
as
Ben
gives
me,
the
okay
I
merged
the
pool
requests
who
made
a
new
version.
I,
don't
know
if
I
will
submit
one
or
two
new
versions.
I
could
submit
one
version
and
then
do
the
changes
we
discussed
today
and.
C
C
F
C
Perhaps
a
profile
I
started
doing
the
modifications
I'm
a
bit
late
with
this
work
as
I
was
working
heavily
on
the
Earth's
core
profile,
so
I'm,
sorry
for
for
the
delay,
but
I
started
a
restructuring
and,
as
I
mentioned
it's
now,
the
stew
up
application
profiles
of
X
key
group,
calm,
the
mqtt
pub/sub
and
coop
pops
up,
and
it's
also
up
to
date
with
the
s
key
group
calm.
So
next.
C
Put
in
the
table
of
contents
from
the
draft
right
now,
so
what
was
expecting
it's
not
much
tech
started
at
all
is
just
some
restructuring
of
a
general
text
and
and
co-op
or
MQTT
specific
text
right
now,
the
MQTT
publisher,
so
4.2
and
5.2
are
empty.
These
are
supposed
to
be
examples
of
what
publisher
and
subscriber
would
send
into
the
K
to
the
K
to
get
to
the
to
get
the
keys.
C
A
C
A
C
D
C
D
D
C
That'll
be
awesome,
so
yeah.
Let's
continue
this
in
there
offline
or
I.
Think
that
I
don't
know.
If
you,
you
won't
get
some
some
time
to
talk
about
this
and
after
you
had
a
chance
to
to
review.
As
I
said,
the
text
changed
a
lot.
It's
the
structure,
but
you
probably
have
better
ideas
of
what
needs
to
be
added
and
I.
D
C
D
A
C
D
D
A
A
Because
one
of
my
I
don't
know,
but
a
the
thing
I'd
like
to
discuss
is
so
once
this
version
is
published.
If
we
expect
it
to
be
final,
I
would
like
to
have
maybe
some
people
reviewing
carefully
the
document.
I'm
just
wondering
if
you
have
in
mind
some
some
people
we
can
designate
or
ask
privately
to
review
that
very
carefully
I
think
that
would
speed
up
sending
it.
The
document
to
the
is
G.
So
this
is
something
I'd
like
to
discuss
with
you
all.
A
A
F
F
F
We
clarified
also
that
the
moment
key
material
is
update
on
a
node.
That
node
is
supposed
to
not
use
that
material
anymore
for
outgoing
messages,
especially,
and
you
still
have
the
possibility
for
special
policies
for
retaining
it
a
bit
for
incoming
messages
we
clarify,
you
may
have
different
reasons
out
of
which
building
policies
for
failing
in
processing
incoming
messages,
so
we
were
considering
only
the
keys.
I
have
don't
work,
but
you
may
have
a
separate
case.
F
I,
just
don't
find
any
context
at
all
that
I
can
even
try
and
they
maybe
handle
differently
with
different
policies,
and
we
clarified
also
that
the
moment
the
KDC
decides
to
rekey
the
group
and
to
distribute
new
key
material
to
the
group.
That's
enough
for
incrementing
the
version
number
of
the
key
material
regardless
any
possible.
F
So
that's
why
I
also
try
to
cap
the
a
generic
name
like
control
path,
rather
than
racking
path,
or
something
like
that,
and
also
putting
together
an
initial
discussion
and
loss
coming
from
Jim
and
we
added
a
new
sub
resource
which
is
actually
a
sub
resource
to
the
node
sub
resource.
So
in
the
sub
resource
of
every
node,
we
have
a
pub
key
sub
resource
where
that
node
can
possibly
upload
a
new
public
key,
and
we
started
to
see
a
possible
need
for
this
and
in
case
as
we
are
describing
in
a
separate
document.
F
The
group
administrator
changes
the
signature
algorithm
in
the
group
and
that
may
force
all
group
members
to
provide
the
KDC
with
a
new,
workable
public
header.
So
they
may
need
to
upload
a
new
one
rather
than,
of
course,
just
leaving
the
group
all
together
and
join
again.
They
will
take
probably
more
time
but
yeah.
The
last
tip
bullet
points
where
the
the
major
one
is
a
if
you
can
move
to.
The
next
slide
is
just
about
one
big
open
point:
I
can
think
about
other
than
continue
processing.
F
A
few
points
left
in
Jim's
review
and
in
Peters
review
asked
the
first
open
bullet
point.
That's
something
we
kind
of
discussing
yesterday
and
this
morning,
depending
on
the
time
zone
with
Jamie.
We
were
considering
already
at
the
previous
interim
to
improve
scope
to
cover
at
once,
not
only
one
topic
group
but
multiple
at
once,
and
we
seem
to
agree
already
in
a
kind
of
format
that
can
work
that
way.
F
Well
the
same
note,
member
of
different
groups
under
the
same
group
manager,
kind
of
forced
to
have
different
public
keys,
one
for
a
group
and
one
for
another,
for
instance,
cause
in
the
different
groups,
different
signature,
algorithms
are
used,
and
you
just
have
to
end
with
two
public
keys
and
Jim
has
some
comments
on
that,
but
I
think
it's
kind
of
a
separate
thing.
Regardless
the
way
you
exactly
format
the
scope,
so
we
can
work
on
both
aspects.
In
parallel,
the
scope
format
itself
seems
safe
way
to
go.
A
F
A
A
F
A
C
The
point
that
a
Markov
brought
up
I
think
if
we
have
a
second
to
discuss
it.
That
would
be
good,
because
the
point
is
the
question
is:
do
we
think
it
is
a
scenario
that
a
node
that
is
doing
group
communication-
that
is
talking
to
one
other
ization
server
to
point
to
different
groups,
well
use
two
different
piece
of
the
keys
to
sign
or
countersign
the
communication.
C
A
D
C
C
C
F
F
F
A
A
F
A
But
I
don't
think
okay,
so
because
what
so
so
is
it
true
that
it
seems
better
to
have
one
identity
per
group
and
I
mean
if
you
suppose
the
identity
is
a
public
key,
but
I
don't
see
any
any
motivations
for
having
different
signature
algorithms,
if
you,
you
have
different
groups,
especially
because
I
mean
maybe
I'm
completely
out
of
scope,
but
if
I
am
creating
a
group.
I
may
not
even
know
that
node
is
associated
to
other
groups,
so
you.
A
C
F
A
C
C
E
F
F
Think
the
moment
you
have
the
group
working
that
way
we
that
algorithm.
That
means
you
have
to
go
for
that
particular
kind
of
key
is
not
whatever
keys.
F
A
F
A
F
A
F
A
Yeah
but
I
mean
the
thing
we
I
mean.
What
is
the
attacks?
The
face?
I
mean
it's
not
that
I
mean
if
you
have
two
keys
for
two
different
groups:
I
mean
I
mean
as
long
as
you
belong
to
two
different
groups.
You
were
when
you're
you,
you
can
do
the
bridge
between
the
and
leaks
information
from
one
group
to
the
other,
so
the
keys
are
doing
very
little
mm-hmm
that
he's
dead.
As
you
mentioned,
when
we.
A
F
F
When,
yes,
you
can
already
move
to
slide
two
actually,
and
that
will
be
all
there
again.
A
summary
from
the
interim-
and
this
was
mostly
I'll
say,
taking
care
of
the
review
that
came
from
Jim
the
same
day
of
the
interim
one
point
is
to
open
I,
have
it
in
the
next
slide,
but
we
also
added
here
considerations
on
the
side
of
Nancy's.
Again,
it
ended
up
in
a
brand
new
section.
I
think
it
was
easier
for
this
work.
F
Then
then,
what
we
have
to
do
with
the
oscar
profile,
so
first
of
all,
cause
and
C
is
always
transported
in
a
secure
way
in
a
journal
request
that
is
protected
and
also
these
two
analysis
have
much
less
critical
role.
This
is
not
about
building
a
security
context
or
not
breaking
a
cipher
or
anything,
but
it's
just
about
building
a
signature
challenge.
F
F
That
I
noticed
that
the
previous
interim
is
summarized
that
in
the
mail
proposing
a
way
out,
I
got
no
feedback,
so
I
went
for
that
actually
and
I
fixed
one
of
the
metal
provided
by
the
interface
of
the
group
manager,
so
that
now
the
operation
that
is
supposed
to
return
only
the
group
King
material
without
anything
individual
individually
belonging
to
that
node
works
according
to
expectation.
So
essentially,
in
that
particular
method,
the
response
return
doesn't
include
the
sender
ID
that
that
node
has
in
the
group.
F
So
it's
consistent,
we
will
specify
in
ASCII
lucam
and
we
are
also
clarifying
exactly
what
group
working
is
about.
So
what
exact
information
would
distribute-
and
this
is
something
we
just
echoed
here-
to
also
4sq
calm
about
when
what
it
is
sufficient
to
update
version
number
of
the
key
material
from
Jim.
F
Again,
the
server
side,
nuns
and
s
was
also
included
in
a
narrow
response,
return
to
the
join
request,
so
that
next
join
request
can
essentially
build
again
a
new
fresh
signature
challenge
to
consider
just
to
be
sure
in
case
of
not
to
good
quality
dances
involved
here
in
the
exchange
and
I
noticed.
We
weren't
really
having
a
very
good
error
handling
for
the
corner
case
of
group
members
configured
as
monitor
only
or
silent
servers
in
the
group
of
score
parlance.
F
So
I
had
a
few
lines
more
at
Wendell
errors
for
them
and
I
mention
in
the
presentation
before
we.
We
have
defined
that
new
parameter
for
the
join
request,
control
path,
pointing
at
resource
local
to
the
group
member
that
the
group
manager
can
use
and
well,
we
are
using
here
and
pointing
at
that
for
the
sake
of
operations
like,
for
instance,
Ricky
and
then
lasting.
These
points
again
to
the
other
draft.
F
It
is
convenient
for
the
group
manager
to
notify
the
group
members
about
the
current
status
of
the
group
as
active
or
inactive.
All
the
group
members
would
to
check
them
so
I've
essentially
extended
the
original
interface
from
the
KDC
of
SQL
comm
have
ascended
here
with
one
additional
sub
resource
of
the
group,
the
central
returns
true
or
false.
F
In
case
the
group
is
said
to
be
active
or
inactive
I
thought
about
this
for
a
while
in
the
end,
I
thought
of
the
fun
in
this
here
as
an
extension
of
the
original
interface
cause
I'm,
pretty
sure
it
makes
sense
in
the
place
here.
A
problem
probably
is
not
so
general
to
be
in
in
SQL
comm,
where
the
KDC
is
not
the
broker,
while
it
is
the
broker
that
has
all
in
all
a
view
of
active
inactive
topic.
So
probably
this
has
to
be
in
case
they
find
somewhere
for
the
broker.
F
F
Jim
had
requests
proposals
in
his
review
about
thinking
of
enforcing
the
role
of
legal
requester.
So
if
I
understand
correctly
something
that
can
be
signaled
in
the
public
key
of
this
requester
to
indicate
the
other
group
members
that
this
sender
is
a
legal
requester,
so
that
essentially
the
other
nodes
really
have
to
reply
requests
coming
from
from
this
sender
and
cannot
exactly
ignore
them.
F
We
had
some
exchange
last
month
after
the
interim
in
the
mailing
list.
This
probably
needs
more
discussion,
because
I
used
to
understand
who
the
term
means
that
a
node
is
a
legal
requester
and
should
be
advertised
as
such,
and
if
that
one
is
not
the
group
manager,
how
can
the
group
manager
verify
this
before
starting
to
enforce
this
claim
in
the
group?
And
finally,
practically?
How
can
the
group
manager's
signal
this
information
in
a
public
key.
F
F
F
F
F
F
C
A
So
yeah,
but
I
mean
I
mean
that
we
will
keep
on
moving
the
document.
Do
you
think
those
interim
meetings
were
useful?
Yes,.
A
So
I
have
did
also
I
have
I'm
sharing
this,
and
this
impression
and
yeah
I
think
we
all
know.
What's
the
next
step
for
each
draft
is
so
I
mean
unless
we
have
any
last
comments,
I
think
we
can
return
the
meeting
I
think.
A
Okay,
okay
looks
good
well,
thank
you
for
taking
part
of
that
meeting
and
yeah
see
you
wait.