►
From YouTube: IETF109-ANIMA-20201120-0730
Description
ANIMA meeting session at IETF109
2020/11/20 0730
https://datatracker.ietf.org/meeting/109/proceedings/
C
All
right
yep,
thank
you
very
much
for
attending.
So
this
is
the
enema
working
group
meeting
standard
disclaimer
right.
Please
mute
your
cell
phones
and
all
the
other
things
about
the
itf
notewell.
I
think
we
don't
need
to
go
through
this
in
detail,
so
yep,
I'm
not
sure.
If
we
have
an
explicit
jabber
scribe,
anybody
who
who's
following
would
would
would
be
lovely
to
help
and
basically
reflect
any
possible
questions
from
people
who
cannot
get
on
the
microphone
line
itself.
C
I
think
shang
will
primarily
take
care
of
the
microphone
line
as
I'm
sharing
the
slides
joanna
is
going
to
take
the
minutes,
and
the
other
thing
should
be
well
known
all
right,
let's
get
directly
into
it,
so
we
have
cluster
c
325
with
all
the
documents
in
it
not
being
blocked
on
anything
but
rfc
editor,
so
that
it
means
the
anima
grasp
the
prefix
management
reference
model,
bootstrapping
and
autonomic
control
plane.
We're
still
getting
updates
on
these
two
documents,
as
they
still
had
worked
since
the
last
itf.
C
The
cluster
also
has
other
documents
in
it,
which
you
know,
because
by
virtue
of
being
linked
to
grasp,
but
they're,
not
really
from
our
working
group,
so
that's
the
main.
You
know
round
one
of
anima
charter
finishing
up
so
there's
also
the
grasp
api
and
that's
going
to
be
on
the
telechat
in
december.
C
So
it
has
enough
positions
to
pass
so
that
would
also
go
into
the
cluster.
There
was
a
an
update
from
the
authors
I'm
going
to
quickly
show
on
the
next
slide,
but
otherwise
no
presentation.
Here
then
we
have
the
working
group
documents
in
their
way
into
the
working
group.
So
there
are
the
asa
guidelines
from
the
individual
draft
09,
so
that
was
adopted
by
the
working
group
on
mid
this
month.
C
So
I've
assigned
myself
as
the
shepard-
and
I
haven't
actually
checked
in
the
last
few
days,
if
I
I
think
brian
had
put
put
put
in
a
version:
zero,
zero.
I'm
sorry!
I
didn't
update
that
in
the
slide.
So
then
we
have
the
draft
vendor
stock.
So
shang
was
doing
the
adoption
call
for
that.
Please
provide
more
feedback,
I'm
not
sure.
What's
the
latest
status
of
that
of
that
chain.
D
You
know
any
objections
on
that,
but
I
have
to
give
a
reminder
for
the
other
and
other
participants
as
well,
because
there
are
little
discussion
for
this
document
for
a
while.
I
can
fully
understand
that,
because
you
know
this
document
already
be
around
for
a
while,
but
as
cheer
we
actually
would
like
to
see
more
discussing
in
the
mailing
list.
D
C
And
also,
I
guess
that
this
stuff
came
from
a
particular
iot
area,
so
one
of
the
ways
on
how
to
get
more
feedback
for
these
type
of
working
group
documents
is
also
when
we
work
with
the
authors
and
suggest
presenting
this
bringing
this
up
on
the
actual.
You
know
mailing
list
of
the
working
groups
that
would
use
this
stuff,
you
know,
could
even
be
ops
area.
C
Okay,
then
we
have
brewski
as
essence
and
roll
we'll
get
an
update
in
this
meeting
that
was
adopted
after
107,
and
then
we
have
the
constraint
voucher,
for
which
there
is
a
design
team
formed
after
108
also
an
update,
we've
got
grass
distribution
and
since
108
there
was
some
essential
content
merged
from
the
grass
bulk
documents,
so
the
authors
have
been
doing
work,
but
we've
been
also
running
out
of
time.
So
there
is
no
no
update
given
in
this
meeting
but
check
out
the
the
latest
version.
C
Okay,
draft
anima
grasp
api,
given
how
that's
going
to
be
on
its
way
out,
so
the
the
list
of
changes
here
so
pretty
significant
good
improvements
from
from
from
the
review,
I'm
not
going
to
read
that
out
in
more
detail.
If
anybody
has
questions
or
so
please
come
to
the
mic,
and
we
can
answer
them
here
in
this
slot,
I
hope
otherwise,
let's
move
on
so
non-working
group
documents.
C
We've
got
the
anima
voucher
delegation
that
was
updated
after
108,
so
that's
pending
for
adoption
calls
so
well
we'll
do
that.
Adoption
call
after
this
ietf
meeting
we've
got
the
only
non-working
group
item
that
made
it
onto
the
agenda
for
this
time.
That's
the
brewski
cloud,
that's
going
to
be
discussed
and
then
there
are
three
further
documents
that
we
discussed
in
108,
for
which
we
haven't
heard
update.
C
I
guess
it
might
be
something
like
work
overflow
on
behalf
of
the
authors,
so
I'm
assuming
that
unless
you
know
one
of
the
authors
may
want
to
step
forward
and
say
something
about
them,
yeah
and
any
other
interest,
or
so
please
come
to
the
mic
during
this
slot
and
note
anything:
we've
we've
forgotten
on
the
work
side,
so
other
business.
So
I
mentioned
the
iot
ops
working
group
that
actually
was
discussed.
The
first
you
know
direction
toward
the
charter
just
in
before
in
the
ops
area
meeting.
C
I'm
not
sure
if
you
attended
that
so
hopefully
that's
going
to
come
down
and
it's
going
to
be
hopefully
good
adjacency
for
for
use
cases,
scenarios
and
so
on.
No
standards
were
planned
with
enema
and
I
was
making
my
concern
that
you
know
iot
is
is,
is
kind
of
is
a
strange
term,
but
I
think
routers
and
switches.
You
know
also
have
very
much
the
same
life
cycle
issues,
so
we
should
be.
You
know,
inclusive
of
of
those
devices
as
well.
Even
if
iot
people
often
don't
think
about
them.
C
You
know
applications
that
they
were
suggesting
like
automation,
of
operational
aspects
of
routing
protocols,
because
those
would
be
great
asas
to
bring
into
enema.
That
was
the
gist
of
it.
Otherwise,
please
check
out
the
slides
about.
You
know
how
to
use
grasp
for
asa.
I
think
that
was
very
well
received
in
the
working
group.
C
Tooling
reminder
if,
if
you're
getting
into
enema
at
this
point
in
time
and
don't
know
how
to
operate,
if
you,
if
you
want
to
bring
documents
in
and
want
to
have
them
edited
more
easily
by
other
members
of
the
team,
use
the
the
github
that
we
have
for
a
long
time
and
then
we're
done
with
the
chair,
slides
and
given
how
you
know
the
time
10
minutes.
Okay,
I'm
still
good
in
the
time.
Any
further
question
on
this
slot.
C
A
C
Excellent,
thank
you
all
right,
so
we
were
at
28
after
itf-108,
so
the
majority
of
the
time
was
actually
spent
with
the
isg
final
reviews.
For
that
29.
I
converted
to
xml
v3,
which
is,
I
think,
recommended
for
every
document
now
to
speed
up
rfc
editor
pass
because
they
they
need
xmlv3.
I
also
did
it
because
I
put
pascal
michael
and
brian
into
contributors,
and
that
only
has
formal
xml
tags
in
version
three.
C
C
So
you
want
to
have
hardware
with
secure
boot
and
software
upgrade
the
registrars
and
the
est
protocol.
Of
course,
are
you
know
one
of
the
core
attack
vectors,
so
it's
quite
important
to
make
sure
that
only
the
registrars
have
the
this
tag
in
the
certificate
that
gives
them
the
authorization
to
be
registrar,
so
that
not
every
device
could
be
hacked
to
become
a
registrar,
and
then
I
think
you
know
the
the
remainder
of
the
security
considerations
are
really
the
ones
also
applicable
to
est
nothing
new,
otherwise,
the
men
in
the
middle
attacks.
C
C
Ben
brought
up
the
point
about
the
well-known
port,
the
the
port
numbers
in
dull
grasp
during
discovery
of
neighbors.
I
refined
that
to
explain
how
that's
a
possible
attack
vector.
We
were
discussing
this
and
didn't
have
these
port
numbers
five
years
ago
when
we
started
so
they
sneaked
in
later
on,
because
we
were
looking
into
dtls.
C
So
that's
still,
you
know
something
which
people
cannot
fully
agree
that
you
know
well
known.
Port
numbers
are
a
good
way
to
avoid
this
problem,
but
obviously,
once
we
would
see
that
for
dtls,
this
would
become
a
problem.
We
could
go
forward
and
ask
for
an
acp
over
dtls,
well-known
port
number,
two
to
avoid
that
problem.
But
given
how
right
now
we're
focusing
on
ipsec,
I
think
we
shouldn't
be
worried
about
this
yeah
formatting
as
cbor
cddl.
C
C
We
obviously
want
to
make
sure
that
in
case
that
one
of
them
is
the
you
know,
least
secure
one
that
we
discover
when
somebody
man
in
the
middle
does
a
downgrade
attack
there
so
yeah
that
that
was
was
good
time
and
work
spent.
Then,
basically,
when
we're
done,
the
thing
went
to
eric
and
so
dash
30,
which
is
now
in
the
rfc.
Editor
queue
was
kind
of
the
leftovers
run
yeah.
C
C
The
first
one
is
this
very
old
negotiation
via
grasp
for
the
acp
secure
channel
mechanism.
I
had
left
it
in
the
draft
before
for
feedback
from
isg
actually
ben
liked.
It
also
suggested
additional
text,
but
still
I
felt
not
safe
to
move
it
into
the
rfc,
given
how
we
couldn't
finish
the
text
and
how
the
working
group
originally
thought.
C
It
was
too
much
for
this
initial
rfc
and
then
the
other
three
were
kind
of
smaller
things,
so
one
that
we
discussed
very
early
on
as
well
kind
of
should
the
acp
address
in
the
forwarding
plane
for
appear
be
verified,
and
there
is
good
discussion
about
that.
But
I
don't
think
we
we
have
given
recently
enough
consideration
for
that.
I
think
the
answer
is
no,
then,
basically,
I
think
a
very
interesting
discussion
about
how
would
we
use
acp
with
public
cas
and
well
guess
what?
C
C
I
think
that's
where
the
rfc
editor
sits
behind
that
big
door
and
well.
Thank
you
very
much.
Everybody
involved,
especially,
you
know,
all
the
hard
work,
also
from
the
isg
in
in,
in
all
the
reviews,
it
took
a
very
long
time,
but
I
think
it
was
worth
it
from
you
know,
really
the
fact
that
there
are
a
lot
of
security
related
things
around
the
acp.
I
you
know
by
now.
I
know
a
lot
more
than
even
brewski
itself,
so
that
was
definitely
well
spent.
A
Any
more
questions
about
that
no
questions,
but
I
just
want
to
chime
in
to
say
a
big
thank
you
tell
us
for
getting
this
one
over
the
line
and
the
amount
of
effort
you've
put
in,
and
the
working
group
and
also
eric's
helped
the
shepherding
ad
for
this.
So
I'd
just
like
to
thank
everyone.
I
know
this
has
been
a
tricky
document.
A
D
D
This
is
the
last
document
in
our
stage
one,
and
actually
we
can
together
release
the
five
rfcs
one
of
them
already
being
released
for
more
than
thousand
days
yeah
and
by
now
actually
we
hand
our
original
autonomic
network
infrastructure
components,
three
of
them
all
published
complete
and
that
including
the
sap
and
reski
and
grasp
will
help.
You
know
in
this
second
stage
we
can
say
more.
D
C
E
E
So
a
change
was
prepared
to
discuss
it.
There's
a
the
the
the
difference
the
diffs
are
in
that
email.
That's
listed
there.
The
couple
implementers
were
con
were
contacted
and
they're
all
kind
of
yeah.
We
can
make
this
change
it's
not
so
terrible,
and
particularly
on
the
registrar's
side,
it's
easy
to
support
both.
So
if
you
have
your
own,
you
know
pledge
code
that
you
don't
want
to
update
immediately.
E
Then
you
could
support
the
old
names
as
well
as
the
new
names,
but
going
forward.
We
would
use
the
new
names
warren
pulled,
put
it
into
a
we
had
a
working.
Do
we
have.
We
had
a
working
group
last
call,
I
think
on
that,
and
then
we
had
an
ietf
last
call
that
concluded
on
september
14th,
so
that
was
version
44
updated
and
that
changed
some
ionic
stuff
and
a
conversation
with
mark
nottingham
occurred
as
the
well-known
reviewer
designated
expert,
so
that
went
okay
next
slide.
Please.
E
E
Maybe
and
there
we
go
so
that
was
those
two
two
two
lines
were
added
to
allocate
the
thing
this
went
again
had
an
80
approval,
no
ietf
last
call
it
was
oops
again,
it
was
sitting
in
the
sitting
in
the
rfc
editor
queue
anyway,
so
it
got
updated
and
went
in
and
ayanna
has
signed
off
on
that
next
slide.
Please
yeah,
and
that
was
because
I
was.
C
E
C
B
C
E
C
E
All
right,
yeah,
so
constraint,
voucher,
so
we've
been
working
on
this.
This
is
peter
esko
panos,
a
few
other
people
that
have
come
to
the
thursday
design
team
meetings,
and
so
this
document,
if
you
haven't
read
it
before
essentially
replaces
http
with
coap,
replaces
tls
mostly
with
dtls,
but
also
possibly
with
os
core
and
basically
makes
it
a
much
more
constrained
scenario.
E
I
believe
they've
just
finally
passed
properly
into
the
isg
and
I
hope
they'll
pass
through
easily,
but
we'll
see,
that's
probably
the
critical
thing
for
this
document.
It's
not
yet
obviously
critical
path,
because
we're
not
done
with
it,
but
it
would
be
very
nice
to
have
that
document
finished
because
it
was
rather
difficult
to
figure
out
how
do
we
allocate
numbers
from
a
registry
that
isn't
yet
created?
So,
in
fact,
the
document
now
contains
an
allocation
for
us.
There
next
slide.
E
So
one
of
the
conversations
that
we've
had
is
that
the
well-known
things
are
are
mandatory
to
implement
if
you
want
to
put
it
elsewhere
as
on
the
registrar,
if
you
want
to
put
it
elsewhere
as
well,
then
you
can
do
that,
and
this
means
that
a
client
that
can,
if
it
wishes,
can
skip
the
discovery
process.
If
it
knows
where
the
registrar
is
already,
the
discovery
typically
could
be,
for
instance,
multicasted
to
find
out
what
registrars
are
out
there
next
slide.
E
Please
we
have
asked
the
question
come
back
to:
why
are
we
doing
cms
science
seaboard?
That
was
a
request
when
we
started
this
document
to
do
this
and
we
don't
seem
to
remember
who
or
why
wants
that,
and
it
seems
really
daft,
but
we're
gonna
do
this
we're.
So
we
were
asking
the
working
group
what's
going
on.
We
have
some
clarifications
around
the
use
of
proximity
registered
public
key
info,
and
we
have
some
interactions
with
questions
about
how
it
deals
with
a
composite
or
asynchronous
registrar.
E
C
E
Yeah,
so
also,
I
will
send.
I
owe
a
mailing
list,
a
summary
of
some
of
what
this
is
discussed
and
some
deeper
things.
So
one
of
the
things
the
discussions
we
had
is,
as
you
know,
we
have
actually
next
slide.
Please
we
have
a
pledge.
Next,
we
just
guess
and
hit
down.
Next
we
have
a
registrar
and
we
have
a
massa
right.
E
So
you
know
we
have
those
three
things
next
slide,
so
we
wind
up
with
a
connection
between
the
pledge
and
the
registrar
next
and
we
may
have
a
joint
proxy
in
between
there
next
slide,
if
you're
making
a
presentation
by
the
way-
and
you
want
these
icons-
they
are
in
the
iot
directorate
github
as
well
next
slide,
so
you
can
put
a
cozy
signed
c
board
and
we
do
this
over
co-app.
So
that's
what
the
that's!
E
E
So
the
registrar
can
give
a
preference,
but
the
mass
is
going
to
return
the
one
that
the
pledge
can
actually
process
next
slide,
please
so
yeah!
That's
the
same
point
next
slide
so
start
again
here.
Let's
think
another
way,
this
right,
one
proposal
was
next
slide.
Please
we
have
this
cosy,
signed
c
board
as
before
next
slide.
Can
you
just
say:
click.
That's
faster
click,
okay,
so
we
make
the
connection
click.
E
E
Why
we
can't
put
the
cosy,
signed
seabor
in
as
the
prior
sign
voucher
request
in
a
cms
sign
json?
Yes,
you
have
to
base64
encode
it,
but
you
have
to
do
that
anyway,
for
the
anyway
and
the
interesting
part
about
this
is
that
this
means
that,
on
the
on
the
right
hand,
side,
the
registrar
essentially
has
always
sends
out
the
things
in
the
same
pro
request
and
the
mass
always
processes
things
in
the
same
request,
regardless
of
whether
it's
a
constrained
or
a
non-constrained
request.
E
E
So
this
is
the
the
case
that
we
more,
we
think.
Basically,
we
thought
we
discussed
that
a
fair
bit
and
we
basically
decided
that
that
previous
case
was
dumb,
that
we
didn't
like
it.
In
particular,
it
means
that
a
master
that
only
deals
with
constrained
devices
would
have
to
speak,
non-constrained,
voucher,
request,
content
and
it
doesn't
remove
really
any
code
paths
from
the
registrar,
so
click.
D
E
E
So,
just
a
little
bit
of
a
kind
of
summary
of
these
issues
right
about
what
the
different
things
are
and
how
it,
how
it
does
things
and
the
con
consensus
that
we
had
in
the
in
this
in
the
design
team
was
that
you
will
always
sign
your
parboiled
voucher
request
with
the
same
format
as
you
received.
Okay,
so
all
these
other
variations
are
gone,
that
we
will
not
use
coap
s
between
the
registrar
and
the
masa
for
the
reasons
that
were
stated
there.
I
think
that's
the
last
slide.
E
E
E
The
issue
is
that
one
of
the
ways
to
build
a
scalable
registrar
is
to
separate
the
southbound,
the
pledge
interface
box
in
the
bottom
there
from
the
masa
client
interface.
So
you
could
have
scale
the
pledge
interface
appropriately
for
the
number
of
devices
that
you
expect
to
unroll
at
any
one
time,
which
I
guess
at
certain
times
of
the
could
be
zero
and
other
times.
Maybe
it's
thousands
and
you
need
to
have
a
a
fair
bit
more
capability
there
to
do
that
and
that's
kind
of
kind
of
typical.
E
You
know
web-based
scaling
things
with.
I
don't
know,
containers
and
and
orchestration
and
other
stuff
like
that
there
and
then
the
only
real
connection
from
the
bottom,
which
talks
to
the
devices
of
the
pledges
and
the
thing
at
the
top
which
talks
the
nasa
is
the
database.
So
in
fact
you
can
build
a
system,
that's
a
synchronous!
You
put
the
voucher
request
into
a
database.
E
In
fact,
there's
nothing
that
stops
you
from
having
a
different
certificate
on
each
of
those
pledge
interfaces,
so
you
can
actually
spin
things
up
and
given
that
they
actually,
in
theory,
can
be
self-signed
certificates
and
as
long
as
they
last
long
enough
for
the
voucher
to
pin
them,
there's
not
actually
a
you
could
actually
destroy
them
as
you
as
you
destroyed
the
vm,
or
something
like
that.
You
could
even
do
something
like
that.
That's
not
not
how
I
design
it,
but
you
could
do
that.
E
E
Right
so
that
was
it
yeah.
So
that's
the
kind
of
that's
the
outline
of
the
problem
and
and
we're
trying
to
explain
the
the
answer,
and
one
of
the
answers
for
the
the
constrained
case
is
that
we
pretty
much
have
to
send
some
additional
pieces
and
just
clarify
what,
when
you
can
pin
things
and
when
you
can't
ping
things,
and
there
are.
C
C
E
You
like
it's
when
you
substitute
a
raw
public
key
down
there,
that
you
realize
oh
wait,
the
there's
no
relationship
to
a
certificate
authority
there.
So
I
can't
do
anything
specific
and
there's
another
conversation
that
we
had
yesterday
a
little
bit
in
the
acme
working
group
about
what
happens.
If
you
want
like
to
use
a
web
pki,
let's
encrypt
certificate
for
that
pledge,
interface,
what
happens
to
the
pinning
process
and
the
cms
the
a
bit?
That's
a
different
conversation
that
requires
a
longer
thread
to
to
discuss.
E
Oh
there's
some
slides,
there's
some
slides
after
the
last
slide
about
the
constraint
join
proxy.
If
you
just
give
me
one
more
minute:
okay,
okay,
that
was
in
the
same
deck
yeah
there
you
go.
No,
that's
not
my
slide.
Is
it
draft
relationships?
Yes,
it
is!
I'm
sorry!
Yes,
there
you
go
so
the
constraints
yeah.
So
there's
the
constrained
joint
proxy
document-
and
this
has
been
revised
a
few
times
by
the
design
team.
Next
slide
click,
so
brewski
uses
http
and
tls
essentially
builds
a
circuit
proxy.
E
There
is
a
way
to
do
this,
statelessly
with
coap,
which
comes
with
a
six
dish
working
group,
but
there
is
no
way
to
do
this.
Statelessly
with
dtls.
You
can
build
a
circuit
proxy,
creating
state,
but
there's
no
way
to
do
this
in
a
stateless
way
with
dtls,
and
this
document
tries
to
do
that.
So
next
slide
please.
E
C
Right,
have
you
seen
I'm
trying
to
remember
what
the
working
group
is
right,
so
there
there's
a
lot
of
you
know
also
these
type
of
proxy
things
for
for
for
quick
happening
and
quick
is
trying
to
get
also
into
the
datagram
service.
So
are
we
you
know
going
to
wake
up
in
another
year
or
so
and
having
to
do
everything
we're
doing
with
dtls
with
quick.
E
I
don't
know
what,
and
I
guess
I
could
go,
look
at
those
documents
and
see
if
there's
something
there.
Maybe
part
of
the
answer
is:
don't
bother
with
teal,
maybe
it's
stupid
to
do
dtls
if
you're
going
to
do
quick
anyway,
but
I
don't
know
I.
I
would
appreciate
some
other
feedback
from
people
as
to
whether
to
deal
with
all
of
these
different
possibilities.
E
Who
really
wants
what
versus?
Maybe
the
answer
is
just
if
you
can't
use
tcp
for
some
reason,
can
you
really
use
quick?
I
don't
know
the
answer
that
question.
I
would
tend
to
think
that
if
you're
in
that
constrained
space
that
you
are
probably
more
interested
in
using
ad
hoc
and
os
core
than
you
are
in
using
quick.
C
E
B
B
Yes,
okay,
so
I
would
like
to
give
an
update
on
the
brisket
ae.
Asynchronous
enrollment
draft.
We
haven't
submitted
an
updated
draft
because
we
are
still
working
on
on
one
of
the
use
cases
to
get
more
more
meat
into
the
use
case
and
get
a
better
description
of
the
single
items
that
we
will
talk
about
in
a
minute.
B
B
B
We
address
that
and
use
case
one
by
basically
using
signed
wrapped
objects
which
are
used
for
the
certification
requests
in
the
same
way
as
the
voucher
request
that
poses
some
requirements
to
the
enrollment
protocol
and
in
use
case
one
we
are
mainly
focusing,
or
we
are
mainly
pointing
to
enrollment
protocols
that
support
those
signature.
Wrapped
objects
for
certificate
for
certification
requests,
which
would
be,
as
stated
in
the
draft
est,
with
full
cmc
or
also
the
lightweight
cmp
version
click,
so
that
there
was
no
change
to
the
description
yet
for
use
case.
B
One
use
case:
two
introduces
a
push
model,
so
we
call
it
push
model
because
in
the
original
brewski
draft
we
consider
that
as
pool
model,
because
the
pledge
pulls
essentially
all
necessary
information
like
the
voucher
and
the
certificate
from
the
infrastructure
near
the
domain
registrar
in
use
case
two
and
the
push
model.
We
reverse
that
role,
because
in
industry,
industrial
environments,
typically
the
the
pledge
site
would
be
the
server
side.
So
that
means
we
need
to
to
provide
that
reverse
role
description.
B
So
the
draft
again
uses
signature
wrapped
objects
to
basically
have
a
secure
exchange
between
the
pledge
and
the
domain
registrar.
So
if
you
jump
to
the
next
slide,
then
you
can
see
the
architecture
for
that.
So,
on
the
on
the
right
hand,
side
you
see
that
between
the
pledge
call
ye
and
the
the
domain
registrar
there
is
a
new
component
called
pledge
agent
that
basically
works
as
a
proxy
between
the
pledge
and
the
joint
proxy,
and
so
the
use
case
too,
is
currently
what
we
are
focusing
on.
B
Also
in
the
discussion
of
the
in
the
design
team,
which
michael
mentioned
so
the
the
protocol
approach
at
first,
we
thought
to
be
very
close
to
briskey.
So
we
at
the
time
of
discussion.
Now
we
are
at
the
stage
where
we
say
between
the
pledge
agent
and
the
pledge
called
ye.
We
use
a
similar
approach,
as
in
brewski
that
means
http
and
tls
between
those
components.
B
What
we
are
currently
discussing
is
the
trust
relationship
between
the
pledge
agent
and
the
pledge,
and
also
between
the
pledge
agent
and
the
domain
registrar.
So
we
had
some
discussion
of
how
to
use
tls
between
the
pledge
agent
and
the
pledge,
because
there
is
no
no
prior
trust
relation
for
them.
So
we
thought
about
using
a
psk
based
cipher
suite
in
tls,
which
can
be
used
to
at
least
vouch
for
proximity
between
the
pledge
agent
and
the
pledge.
B
B
So
a
further
point
is
the
endpoint
definition
for
the
pledge
itself,
because
the
pledge
assert
acts
as
a
server,
so
we
we
need
to
have
endpoints
defined
on
the
on
the
pledge
side
to
be
able
to
contact
the
pledge
and
to
request
certain
actions.
So
for
that
we
also
relied
on
the
the
currently
defined
approach
in
brewski
yeah
period.
B
Okay,
so
because
I
just
read
it
the
the
comment
from
esco,
so
the
the
intention
also
to
use
a
psk
based
mode
between
the
fletch
agent
and
the
pledge
itself
was
also
to
not
rely
on
the
or
to
not
bind
the
exchanges
to
tls,
because
if
there
is
some
other
means,
some
other
transport
means
between
the
pledge
agent
and
the
pledge
that
doesn't
feature
a
tls
or
http
like
nfc
or
bluetooth.
Then
we
may
not
be
able
to
rely
on
the
transport
security
as
defined
than
if
it
is
bound
to
tls.
B
Right,
so
that
was
the
discussion
that
we
have
on
the
the
design
team,
so
more
or
less
repeating
some
of
the
things
are
already
set,
so
the
potential
use
of
a
qr
code
or
something
similar
to
vouch
for
the
proximity
between
the
pledge
and
the
pledge
agent
is
currently
being
discussed.
That
relates
to
the
tls
and
tls
cipher
suites
to
be
used.
B
We
discussed
also
to
use
something
like
the
the
subserts
that
is
currently
in
discussion
in
the
tls
working
group,
but
it's
yeah
because
of
the
possibility
to
use
bluetooth
or
nfc
or
other
protocols
between
the
pledge
agent
and
the
pledge.
We
decided
that
this
is
not
a
good
fit,
because
that
has
a
high
dependency
on
tls,
obviously,
and
regarding
the
trust
relation
between
the
pledge
agent
itself
and
the
registrar.
B
Right
so,
let's
see
what's
on
the
slide
down
there,
so
we
have
some
some
open
discussion
regarding
the
the
potential
attacks.
So
regarding
the
security
considerations
and
from
the
discussion
we
had
during
the
last
design
team
meeting,
we
figured
out
that
from
a
security
perspective,
there
is
a
denial
of
service
attack,
possibility
on
the
pledge.
B
Then
the
same
would
be
done
with
the
enrollment
request,
resulting
in
a
certificate
signing
request,
pkcs10,
which
is
which
is
being
forwarded,
then
to
the
registrar
as
soon
as
the
pledge
agent
talked
to
the
registrar
and
the
register
did
the
backend
communication
with
the
mother
and
the
domain
ca,
and
you
expect
the
information
about
the
voucher
responses
and
role
response.
He
gets
back
to
the
to
the
pledge
and
provides
those
information
to
the
appropriate
endpoint.
B
B
We
had
some
discussion
about
the
necessity
of
providing
the
proximity
register
certificate
for
the
pledge
to
include
that
in
the
voucher
request.
I
think
that
discussion
is
finished,
because
from
my
understanding
we
see
that
there
is
a
necessity
that
the
pledge
agent
basically
provides
a
proximity
register
certificate
to
the
pledge
agent
to
be
included
in
the
voucher
request
that
enables
the
the
registrar
at
the
end,
because
he
doesn't
have
a
direct
relationship
to
the
to
the
pledge
that
the
registrar
can
verify
that
he's.
B
B
So
next
step
would
be
the
further
refinement
of
the
push
approach.
That
relates
to
the
use
case
too.
Also,
according
to
the
discussions
that
we
had
in
the
design
team,
addressing
certain
open
issues
and
then
the
outcome
will
be
circulated
on
the
mailing
list
for
further
discussion
and
would
be
used
to
update
the
draft
to
be
ready
for
the
yeah.
I
I
would
submit
that
then,
probably
in
december
or
beginning
of
january,.
C
E
E
E
So
we
work,
that's
reworked,
the
terminology
which
is
on
the
next
slide.
We
clarify
the
two
use
cases
and
eliminated
one
use
case
and
whatever
the
third
point
was
I
missed.
This
is
the
terminology
about
what
we're
dealing
with.
So
the
local
domain
is
the
place
where
you're
physically
from
and
it
may
be
different
than
the
pledge
owner's
domain,
so
you
may
in
fact
be
bringing
up
a
device
or
a
pledge.
E
You
plug
it
in
to
the
wire,
because
we
can't
do
onboarding
on
wi-fi
without
some
local
help,
so
we
assume
we
plug
it
in
and
then
it
discovers
oh
you're
supposed
to
be
connected
to
this
hosted
pbx
system
and
it
reaches
out
to
that
system
using
the
same
provisional
tls
and
does
its
onboarding
continues
on
so
next
slide.
Please
and
the
other
situation
is
one
where
the
enterprise
is
perhaps
a
little
bit
more
advanced
or
in
some
cases.
E
Maybe
they
are
a
little
bit
more
behind
having
implemented
something
maybe
a
decade
ago
and
they've
they
have
a
regis.
They
have
a
an
est
system.
It
doesn't
speak.
Brewski,
however,
is
the
problem,
but
it
could
on
board
a
device
if
only
the
device
knew
to
talk
to
it,
and
so
that
in
this
case,
what
happens
is
that
the
cloud
ra
answers
the
voucher
request
with
a
voucher,
but
it
doesn't
pin
the
itself
to
the
to
the
device.