►
From YouTube: IETF-ACE-20230508-1300
Description
ACE meeting session at IETF
2023/05/08 1300
https://datatracker.ietf.org/meeting//proceedings/
A
C
D
Hi,
this
is
Marco
yeah,
just
a
few
words
I
confirmed
since
itf116.
We
added
a
submission
addressing
the
reviews
from
the
working
group
last
call
and
we'll
reply
to
those
on
the
mailing
list.
So,
from
the
author's
point
of
view,
we
think
we
are
down
for
now,
and
the
next
step
should
be
the
shepherd
review
and
write
up
as
in
the
slide.
D
I
can
say
a
few
words.
Almost
two
yeah
there
was
a
private
exchange
between
the
chairs
and
the
authors.
Seek
them
mostly
don't
have
time
to
to
check
on
this
yet
I
I've
had
a
full
reading
on
the
whole
draft
and
with
sigdan
we
are
going
to
have
later
in
May.
First
discussions,
some
outstanding
open
points
in
the
meanwhile
I'll
do
my
best
to
start
already
addressing
uncontroversial
editorial
points
on
the
GitHub,
but.
E
D
D
Yeah,
that's
me
again
of
the
last
one
I
started
to
work
on
the
split
so
I
created
on
the
Ace
GitHub
organization
in
your
repo
for
this
document.
With
the
agree
title,
it
used
to
be
just
a
skeleton.
Until
a
few
days
ago,
I've
been
feeling
it
with
content.
I
I
pull
back
from
the
main
draft
as
soon
as
I
have
something
complete.
I'll
start
publishing
at
the
main
draft,
actually
taking
away
Coral
content
from
them.
D
C
C
Yeah,
so
there
was
a
call
and
option
called
for
adoption
on
the
list
which
ended
on
19th
of
April.
The
draft
was
adopted
as
a
working
group
document.
In
the
meantime,
we
received
a
review
from
from
Marco
on
29th
of
April.
Oh
so
I
would
just
like
to
take
the
opportunity
to
thank
Marco
for
this
review.
Really.
A
million
thanks,
Marco
I've,
already
went
ahead
and
fixed
non-controversial
points.
C
The
points
I
deemed
as
non-controversial
and
they
are
fixed
in
this
pull
request
that
is
open
on
the
in
GitHub
I
will
go
ahead
after
this
meeting
and
respond
to
Marco's
email
with
point
to
point
replies
to
the
to
these
points
which
were
fixed,
and
the
goal
of
my
today's
presentation
is
to
discuss
the
remaining
comments
from
Marco
that
when
that
were
a
little
more,
that
require
a
little
more
discussion
than
than
usual.
So
next
slide.
Please.
C
Foreign,
so
first
comment
is:
is
here,
I
mean
the
the
outline
of
the
next
slides
will
be.
The
italic
words
represent
the
Marcos
quote,
then
I
give
some
context
and
then
the
proposed
action
at
the
very
end.
So
the
first
comment
is
regarding
the
the
message
flow
which
which,
which
is
implied
in
the
draft
to
be
to
be
a
forward
message
flow
in
in
respect
to
the
roles
of
ad
hoc
peers
and
the
ESD
protocol,
client
and
roles.
C
C
So
Marco
brought
up
a
question
whether
a
reverse
flow,
where
the
EST
client
plays
the
role
of
the
ad
hoc
responder
can
be
ruled
out
and
I
think
that
we
can
safely
rule
out.
I,
don't
see
a
use
case
for
that
role,
unless
someone
is
can
bring
it
up
so
I.
My
proposed
action
here
would
be
to
explicitly
specify
in
Section
3,
which
is
the
sectional
authentication,
that
the
ESD
client
must
play
the
role
of
the
ad
hoc
initiator.
Unless
there
are
any
objections
to
this.
C
C
Yes,
so
the
Marcos
comment
number
two
is
on
section
one
where
we
state
that
we
also
support
pre-shared,
Oscar
King
material,
and,
apart
from
supporting
the
exchange,
the
Adcock
exchange
for
authentication
and
Marco
is
asking
whether
in
such
a
case,
Channel
binding
is
simply
not
achievable
or
it's
or
it
is
somehow
possible.
As
long
the
escort
King
material
was
established
through
some
sort
of
interactive
protocol.
C
And
since
we
are
not
using
TLS
1.2,
you
might
you
might
wonder
what.
Why
are?
We
are
doing
this
and
we
are
specif.
We
are
men,
we
are
having
optional
Channel
binding
in
order
to
counter
any
future
attacks,
so
essentially
for
future
proofing
the
protocol
in
and
to
have
a
possibility
of
linking
the
ad
hoc
session
to
the
to
the
ESD
Exchange.
C
We,
the
my
proposed
action,
would
be
simply
to
specify
that
ad
hoc,
exporter-based,
Channel
binding,
is
applicable
only
to
cases
when
ad
hoc
is
executed.
So
essentially
just
a
notorial
note
in
the
draft
that
we
support
this
and
that
we
do
not
support
it
for
cases
when
pre-shared
Oscar
context
is
used
I.
Unless
there
is
any
objection
to
this.
A
B
B
C
Okay,
so
just
to
make
sure
so
we
are
not
using
TLS
1.2,
so
this
was
just
making
a
parallel
with
RFC
9148.
We
are
using
in
this
draft
in
EST
Oscar
draft
we
are
using
ad
hoc
to
achieve
authentication.
Ad
hoc
is
another
protocol
which
is
being
standardized
in
ITF
Lake,
another
working
group
of
the
ITF,
and
but
we
are
still
using
we
in
this
draft.
We
have
a
mechanism
similar
to
TLS
1.3's
exporter
interface,
to
achieve
Channel,
binding.
C
C
I
did
not.
There
is
a
question
by
Marco
Marco.
Maybe
you
can
so
maybe
you
can
jump
in
on.
Is
it
somehow
possible,
as
long
as
the
Oscar
King
material
was
established
through
some
sort
of
interactive
protocol?
We
do
not.
We
do
not
detail
this
in
the
draft,
so
I
don't
think
it's
really
relevant
to
specify
Channel
binding
for
something
that
is
not
detailed
in
the
draft.
D
C
Foreign,
yes,
so
this
is
a
Marco's
comment
on
using
in
scenarios
where
using
message,
four,
wouldn't
wouldn't
it
make
sense
to
have
the
pkcs
10
request
and
response
transported
in
ead3
and
ead4
item
respectively.
So
I
I
just
want
to
clarify
here
that
EST
payloads
are
currently
carried
in
Oscar
protected
messages,
so
they
are
not
carrying
within
the
external
authorization
data
fields
of
ad
hoc,
and
this
is
specifically
for
the
reason
to
be
homogeneous
with
respect
to
the
re-enrollment
and
not
require
ad
hoc.
C
So
essentially,
when
we
do
the
first
enrollment,
we
want
to
do
it
with
Oscar
and
not
with
ad
hoc,
not
with
EAD
fields,
in
order
to
be
homogeneous,
when
we
do
a
re-enrollment
that
we
do
not
require
ad
hoc
in
the
first
place.
So
my
assessment-
so
this
is
is,
is
it
is
detailed
here
on
this
slide?
Is
that
carrying
a
request
and
response
in
the
EAD
items
would
complicate
the
protocol
as
the
flow
would
no
longer
be
homogeneous
and
I
propose
to
take
no
action
on
this
comment.
D
Is
good
honestly
I
missed
the
re-enrollment
option
document
I,
don't
I,
don't
know
if
it's
there
already,
so
maybe
it
makes
sense
actually
to
say
that
that
path
is
intentionally
excluding
or
not
considering
the
interest
of
of
a
better
alignment
that
you
have.
Instead,
if
you
considered
the
combined
Adult
School
request,
because
in
that
case
the
EST
messages
in
all
effects
and
all
score
Co-op
message.
D
C
Okay,
so
I
also
note
in
the
draft.
A
comment
by
yoran
carrying
EST
in
oscot
is
also
another
analogous
to
RFC
9148,
where
the
EST
messages
are
not
sent
in
the
handshake.
So
what
I
gather
here
is
that
we
should
clarify
essentially
for
the
optimization
I'll
sync
up
with
Marco,
for
for
for
exact
action
to
take
on
the
mailing
list.
C
C
C
Should
it
remain
optional
here
too,
and
then
Marco
goes
on
and
gives
a
compelling
example
where
we
support
both
the
Oscar
and
dtls
that
accessing
a
resource
with
when
we
are
accessing
a
resource
and
over
dtls,
and
we
are,
it
may
signal
to
the
device
that
we
are
essentially
using
ESD
Co-op
s
and
we
are
not
instead
of
ESD,
oscore
and
I.
Think
the
proposed
action
here
is
really
to
mandate
the
osc
attribute
in
links
to
SD
resources.
In
order
to
to
to
signal
that
we
are
using
the
STL
score.
C
D
C
C
C
So
the
next
slide
is
related
to
server-side
generation
of
keys
and
Marcos
commented
regards
the
response
from
SKC
resource
which
is
and
he's
asking.
Is
it
possible
to
deviate
from
what
is
defined
in
1948
and
not
encrypted
the
private
key?
After
all,
end-to-end
encryption
of
the
whole
EST
payload
is
insured
by
your
score
and
then,
if,
yes,
that
might
open
for
a
new
content
format
pair
an
unencrypted
PK,
cs8
private
key
together
with
a
single
certificate.
C
Saying
yes,
so
I
was
saying
about
the
Marcos
comment:
I
was
reading
out
the
Marcos
comment,
and
that
is:
is
it
possible
to
deviate
from
what
is
defined
in
RFC
9148
and
not
encrypt
the
private
key?
After
all,
end-to-end
encryption
of
the
whole
EST
payload
is
insured
by
your
score
and
just
to
give
context
on
this.
In
our
draft,
contrary
to
to
EST
Co-op
s
where
register
May
terminate
the
dtls
connection.
Oscar
protection
is
end-to-end
between
the
EST
client
and
the
ESD
server.
C
So
this
indeed
allows
the
private
key
to
be
returned
as
unencrypted
PK
cs8,
because
the
key
will
later
be
encrypted
by
your
score,
but
we
are
not
specifying.
We
are
not
mentioning
this
in
the
draft
draft,
and
my
assessment
is
that
we
can
safely
specify
this
in
the
draft
and
use
the
new.
The
proposal
by
Mark
on
the
content
format
pair.
C
C
So
these
these
two
comments
are
really
straightforward.
So
the
comment
is
on
content
formats
mimicking
an
RFC
9148,
which
we-
which
we
indeed
intend
to
do,
but
we
did
not
explicitly
State
and
the
proposed
action
is
really
to
just
explicitly
make
a
statement
on
the
content
format
support
as
in
RFC
9148.
So
this
should
be
non-controversial
and
to
add
a
table
similar
to
RFC
9148
table
3
in
our
draft.
In
order
to
summarize
the
supported
content
formats.
B
C
C
So
this
is,
there
is
a
list
of
requirements
in
section
4.4
which
is
currently
preceded
by
it
is
recommended
that
which
makes
these
requirements
optional.
However,
isn't
it
a
must
for
at
least
the
co-op
options?
Oscar
and
Yuri
part
and
I
give
a
screenshot
of
the
proposed
action
where
essentially
I
am
proposing
to
replace
the
recommended
with
required
in
order
to
mandate
the
support
for
these
set
of
requirements
that
are
listed
here.
So
the
first
one
is
that
the
EST
Oscar
endpoints
must
support
delayed
responses.
C
The
second
one
is
that
the
endpoints
must
support
the
following
Co-op
options,
which
is
oscorruption
so
the
which
is
natural,
because
we
are
using
Oscar
to
practice.
Uri
host
your
iPad
URI,
Port
content,
format,
block
one
and
block
2
and
accept,
and
the
third
one
is
that
the
EST
URLs
based
on
https
are
translated
to
co-op,
but
with
the
mandatory
use
of
the
Coopers
corruption.
C
G
So
oh
you're
on
here,
can
you
hear
me?
Yes,
so
I'm
I'm
a
little
bit
curious?
Why
do
we
need
to
mandate
this
or
what
does
it?
What
is
the
impact
here?
I
understand
that
you
have
to
have
an
old
score
option
because
you're
using
of
oscore,
so
that's
clear
but
a
new
right
path.
Of
course,
if
you
need
to
identify
which
of
the
which
of
the
different
enrollment
operations
that
that's
going
to
be
used,
but
what
what?
Why
do
we
need
to
go
into
this
detail
of
mandating
options.
C
So,
okay,
so
it
could
be
so
one
one
response
I
can
make.
Is
that
this?
So
there
was
a
comment
on
this
specific
section
that
was
recommended
before,
so
that
it
was
optional.
So
now
the
question
is
whether
what
should
we
do
with
it
and
whether
we
should
mention
I
guess.
Your
comment
is
whether
we
should
be
mentioning
this
at
all.
G
E
G
B
E
So
this,
this
is
all
just
summary,
information
and
information
that
that
I
think
is
actually
useful
for
as
the
checklist
for
an
implementer,
so
I
would
leave
it
in
in
every
case,
but
it
should
not
be
stated
as
a
new
requirement.
It
should
be
something
that
that
is
identified
as
something
that
simply
is
required
by
nature
and
not
required
by
Fiat
here
in
in
this
particular
statement.
E
G
E
C
So
I
believe
you're
reading
it
correctly
Carson
and
the
action
I
hear
now
is
to
summarize
this
without
a
requirement,
even
though
you
you
mentioned
the
keyword,
must
but
without
making
a
normative
statement
here
on
that,
we
that
we
need
to
support
these
options
that
it's
just
a
natural
consequence
of
having
support
support
for
us.
Essentially.
E
G
G
C
C
D
F
G
C
Manda
is
the
implementation
of
Co-op
option
block
one
and
block
two
fragmentation
mechanism
which
contradicted
the
text
where
Co-op
option,
block
1
and
block
2
is
only
recommended
so
I
had
a
mandate
block
as
a
proposed
action
on
this
slide
was
to
mandate
block
one
and
block
two
in
section
4.4
s
per
slide
number
nine,
which
is
the
discussion
we
just
had,
but
since
we
agreed
on
having
just
in
informational
text
in
that
section,
we
should
probably
restate
this
to
support.
Also
to
to
some
inform,
inform,
informative
language.
C
B
C
No,
so
we
we
do
not
want
to
make
we
as
part
of
the
discussion.
We
just
had
cartoon
on
slide
number
nine
or
we
don't
want
to
mandate
anything
on
block
one
and
block
two
in
section
point
four,
so
my
proposed
action.
This
is
not
the
proposed
action
I'm
proposing
in
here
it's
just
to
informatively
summarize
that
that
it's
a
logical
consequence
of
the
draft
that
these
options
need
to
be
implemented.
E
I
I
don't
have
a
strong
opinion
on
this,
yet
I.
Just
think
that
if
you
single
these
out
to
be
optional,
then
essentially
you
are
creating
an
interability
problem.
When
you
are,
you
happen
to
hit
a
link
that
that
has
problems
with
large
packets,
so
I'm
just
trying
to
understand
what
the
rationale
behind
that
is.
G
Yeah
I
think
I
think
this
was
a
good
discussion,
because
first
we
had
the
more
principal
discussion
about
what
to
mandate
whether
we
should
mandate
any
Co-op
options,
and
now
we
have
a
specific
example
of
where
it
might
be
useful,
but
I
I'm
thinking
like
this,
so
we're
doing
certificate
enrollment.
So
if
there
is
a
certificate
coming
back,
we
probably
have
a
problem
with
fragmentation
and
then
again
do
we
have
options
when
there
is
not
a
certificate
coming
back,
I'm
thinking
loud
now.
G
So
do
we
have
a
case
where
you
get
back
just
a
reference
rather
than
a
certificate,
because
in
that
case
you
may
not
need
to
implement
any
fragmentation
scheme
because
you
don't
have
the
sizes
and
and
when
you
need,
as
we
said
you
you
implement
URI
host
because
you
need
to
send
the
main
names
or
the
the
well.
There
is
some
obvious
need
for
for
the
certain
options.
G
So
I
don't
have
a
strong
conclusion
here:
I'm
just
noting
that
either
we
could
rely
on
on
that
that
we
will
state
somewhere
that
these
are
the
options
that
are
being
used
in
section
4-4.
We
state
that
block
one
block
two
are
being
used
and
and
then
you
need
to
implement
those
if
you're,
if
you're,
if
you
hit,
if
you
have
large
sites
and
payload
sizes,
yes,.
C
G
G
F
G
F
G
C
G
E
C
C
E
G
C
C
The
local
code,
Oscar
capable
proxies
so
so
my
proposed
action
would
be
to
informatively
reference,
this
draft
as
a
way
to
establish
a
secure
association
between
the
ESD
client
and
the
co-op
to
HTTP
proxy,
but
not
to
mandate
anything.
Essentially,
it's
just
as
a
way
architecturally
how
this
could
work.
G
G
D
G
D
C
G
F
B
B
E
C
G
G
For
this
interim,
what
I've
been
working
with
is
the
shepherd
write-up
on
the
revoked
token.
So
that's
the
second
point
on
the
agenda,
but
that's
not
finished
either,
but
I
expect
that
to
be
finished
first
and
then
come
back
with
the
Costco
profile
for
for
the
next
meeting
or
for
the
next
ITF
meeting.