►
From YouTube: IETF106-ANIMA-20191120-1520
Description
ANIMA meeting session at IETF106
2019/11/20 1520
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
D
B
D
D
D
D
Whatever
then,
we
have
that
for
five
years,
okay,
this
is
not.
Will
you
should
have
that?
Not
we
all
the
same?
Not
we
offer
five
years
already,
so
you
should
really
read
it
and
assume
you
did
and
before
you
can
meet
him.
We
have
distributed
to
the
blue
sheets
around
make
sure
you're
signed
before
you
leave
the
matter,
how
early
your
and
we
did
jobs
crater
when
we
tell
it
to
do
that.
Yeah.
G
D
D
D
Okay,
oh
okay,
that's
fine!
No!
So
whatever
you
can
you
want
to,
you
know,
take
your
time
is
only
hams,
frisky
and
crowded,
which
traitor
at
biome
and
the
press
key
AE
updates
by
Stefan
and
the
SME
integrating
with
risky
I
came
back
over
then
the
last
one
without
a
draft
is
dedicated
to
voter
proposed
safe
gated
future
by
my
Kaka.
Okay,
that's
why
I
didn't
die
any
at
in
the
posh
why's
Christ.
D
A
I
And
then
somehow,
if
you
did
it
in
the
wrong
order,
yep
start
all
over
again
by
rebooting
the
computer
and
leaving
the
room
and
coming
back
okay,
hi,
so
update
on
bootstrapping
key
infrastructure.
It's
been
my
life
for
three
to
five
three
days
a
week
for
since
the
last
ITF
it
seems-
and
this
is
what
I
told
you
last
time-
the
various
edits
and
comments
and
discusses
that
we
received
this
is
last
time.
I
So
this
is
since
then,
so
the
we
see
there's
a
button
that
lets
me
do
the
light,
yes,
which
remote
people
can't
see,
of
course,
so
the
these
ones
are.
We
got
I
got
ATS
to
say
something
like
okay
and
removed.
There
discusses
and
new
revisions
were
posted,
there's
some
wisdom
periods
of
in
August
with
intense
discussions,
mostly
with
Ben
Cooke,
on
the
security
parts
of
it.
Elisa
gave
us
her
okay
and
then
removed
it
again
say
pointing
out.
There
was
a
yang
doctor
review
that
we
hadn't
addressed
that
were
they
were
mostly
editorial.
I
I'm
waiting
on
okay's
friend,
Roman,
Ben
and
ELISA,
and
there's
this
or
periods
of
pestering
of
ATS,
where
I
emailed
unicast
them
multiple
times,
not
always
not
more
than
once
a
day.
But
you
know
you
kind
of
have
to
do
that
and
get
them
to
pay
attention,
and
you
have
to
know
when
they're
Telesat
SAR,
so
you
don't
bother
them
when
they're
when
they're
reading
other
people's
documents.
I
Okay.
So
what?
What
did?
What
happened?
The
since
the
last
ITF,
the
the
abstract
got
revised?
Part
of
this?
The
challenge
is
I.
Think
in
abstracts
is
how
to
write
it
without
using
the
acronyms
that
you
haven't
expanded
yet,
and
you
can't
expand
them
in
the
app
in
the
in
the
abstract.
So
that's
always
a
challenge.
There
is
a
mixing
xml
registry
that
was
added
and
section
9.1
included
operational
requirements
for
the
autonomic
control
plane
applicability.
I
G
I
The
manufacturer
goes
away,
willy
loman
is
a
character
from
Death
of
a
Salesman.
If
you
don't
know
that,
there's
a
diff
of
the
thing,
if
you
are
have
this
slides,
downloaded
and
want
to
load
that,
and
you
can
see
the
diff
11.6
expanded
to
include
another
situation
from
the
manufacturer
where,
if
the
manufacturer,
you
know
messes
up
and
loses
his
Massa
or
see
a
signing
Keys,
you
know
I,
don't
know
fire
whatever
they
didn't
do
it
right.
I
We
started
the
terminology,
alphabetically
I,
guess
we
had
been
adding
the
terminology,
any
kind
of
grouping
as
to
with
related
terms
that
were
seemed
related
together.
So
at
some
point
that
made
sense
to
us
and
clearly
it
didn't
make
sense
anymore,
just
sorting
it
made
sense.
After
that
there
were
many
TAS
that
weren't
expanded
before
they
were
used.
I
We
fixed
that
added
a
reference
for
RESTful
API
is
that
actually
was
a
bit
difficult
to
find
an
appropriate
reference
that
worked
out
left
the
reference
for
802
NIR
at
the
2009
version,
despite
several
people
telling
us
how
wonderful
the
2018
version
is,
I
can't
download
it.
Several
of
the
people
I
have
spoken
to
have
been
unable
to
download
it.
I
We
of
multiple
tickets,
open
with
the
I
Triple
E
webmaster,
who
basically
clearly
thinks
we're
idiots
and
has
asked
us
to
do
things
like
reinstall
our
browser
and
stuff
like
that,
because
you
know
that's,
obviously
the
reason
why
we're
getting
XML
errors
from
his
single
sign-on
system
is
for
that
reason,
so
you
know
don't
ask
me
what
I
think
of
the
I
Triple
E,
because
I
don't
think
I'm
allowed
to
the
code
of
conduct
won't
will
would
it
prevent
me
from
telling
you
that
figures
were
I
think
already
remembered,
but
some
descriptions
were
missing.
I
We
had
some
comments
about
the
fact
that
the
idea
of
ID
some
systems
were
unable
to
produce
proper
eye.
Dev
IDs,
which
are
supposed
to
have
a
expires
on
and
you're
supposed
to
put
in
the
maximum
number,
which
is
99
9
is
29.99,
or
something
like
that.
1231,
that's
supposed
to
be
that
date,
that's
infinitely
in
the
future.
Some
of
them
are
unable
to
do
that,
and
we
had
some
comments.
We
had
some
weasel
words
around
that
and
I
guess.
I
The
conclusion
is
that
in
the
number
of
years
since
the
document
started,
those
CAS
are
been
fixed.
Mudd
got
published,
we
fixed
those
links.
There
was
a
quite
a
bit
of
I,
think
lack
of
understanding
among
some
reviewers
that
the
ACP
has
ipv6
link
local
addresses
for
enrollment,
and
you
can't
reach
them
from
outside
that
link
and
that's
why
the
link
is
secure,
because
you
can't
talk
to
link
local
addresses
unless
you're
on
that
link
had
a
bunch
of
goofs
in
some
of
the
voter
examples.
I
One
of
our
original
authors,
who
came
up
with
some
of
the
concepts
this
guy
named
Sten
Thor
I've,
actually
never
met
him,
but
he's
known,
but
other
people,
and
after
some
consultation
among
the
authors
and
the
area,
directors
removed
him
as
an
author
and
we
added
tourists
who
actually
fair
fair
bit
of
work
on
editorial
thing
over
quite
a
few
years.
On
this
document
there
and
people
complained
that
the
yang
doctor
list
was
not.
I
The
author
list
was
not
the
same
as
the
document
we
fixed
that
we
had
Hasina
dl
definitions
for
pretty
much
everything
at
this
point,
so
he
fixed
it
for
the
I
guess,
I
mean
when
we
started
this
document
grasp
was
just
hesitantly
using
CD
DL
to
describe
itself
CD.
Dl
is
now
published
and
they're
doing
this,
so
it
makes
sense
to
do
that.
We
add
a
CD
DL
definitions
for
all
of
the
JSON
based
stuff.
I
So
like
that,
the
audit
log,
the
telemetry
status,
the
enrollment
log,
and
there
there
was
a
lot
of
back
and
forth
about
RFC
6120
5,
which
basically
says
you
get
a
CLS
certificate.
How
do
you
know
it's
the
right
one
and
we're
just
saying?
Well,
you
do
what
browsers
do
and
apparently
that
was
not
acceptable
to
say
so.
We
add
some
other
text
there
there's
a
lot
of
push
about.
Why
can't
we
just
make
it
TLS
1.3.
I
So,
even
though
yes,
their
current
codebase,
is
totally
what
TLS
1.3
your
Great
Wolf
SSL,
it's
you
know
they're
1.3
and
that's
great,
and
they
have
a
Phipps
library
as
well,
but
that's
not
drop
incompatible
necessarily
to
you
know
certain
platforms.
So
what
we've
said
is
that
TLS
1.2
suffice,
but
we
would
really
like
everyone
to
support.
I
I
So
we
had
said
it's
the
sha-1
hash
of
the
public
key
or
actually
the
subject
public
key
info
structure
and
that
comes
from
RFC
5280
and
a
couple
other
documents
that
specify
sha-1
is
that
okay
or
some
other
way
of
calculating
it,
which
they
don't
specify.
So
the
question
is
we?
Don't
they
don't
want
us
to
say
anything
about
sha-1
and
that's
okay,
but
the
issue
is
well
if
the
registrar's
certificate
doesn't
have
the
subject
public
key
info.
I
Subject:
public
key
there's
a
oh
I,
D
extension
that
you
would
normally
put
the
fingerprint
in
I
can't
remember
the
name
of
it
right
now.
But
if,
if
you've
calculate
the
CA
has
calculated
it
already
using
whatever
algorithm
it
likes
to
do
and
it
puts
in
a
16
or
20
byte
fingerprint
and
that's
the
thing
you
used
a
reference
to
that
key.
So
if
they've
calculated
that,
then
we're
good
you
just
use
it.
That's
the
point.
If
they
haven't
calculated
it,
then
we
all
need
to
agree
on
how
to
calculate
it.
I
I
So
I
hope
that
the
document
is
sufficiently
complete
about.
Yes,
there
are
considerations
that
you
need
to
think
about,
but
that
I'm
trying
not
trying
to
to
write
a
cookbook
on
how
to
run
things,
but
I
am
looking
for
help
on
that
and
I'm
gonna
go
on
talk
about
about
constrained
voucher
for
one
minute:
okay,
okay,
yeah!
All
right
I
could
take
questions.
If
perhaps
at
this
point.
H
I
Yes,
we
in
fact
have
had
done
interoperability,
testing,
we
being
the
I
guess
I'll,
say
the
fair
hair
Alliance,
which
is
now
part
of
the
ocf
between
Siemens
building
technology
and
nxp
sai
labs
myself
and
signify
was
initially
a
participant,
but
they
didn't,
they
I
think
they
they
ran
out
of
patience,
been
I,
would
say
at
some
point
and
we
have
mixed
amounts
of
success
between
the
implementations.
Mine's,
only
one
that's
publicly
available,
but
we
have.
We
have
some
things
of
interoperating
well
and
some
things
have
not.
Last
at
the
outlast
ITF
you
saw.
I
One
of
the
documents
was
the
clarifications
of
RFC
70/30
about
whether
or
not
things
are
base64-encoded
and
that's
some
of
the
stuff
that
came
out
of
that,
because
70/30
basically
says
he
base64
encode
things
and
then
market
in
a
way
that
HTTP
says,
is
forbidden,
and
then
that
also
confused
people
in
believing
that
you
should
base64
encode
all
the
brewski
vouchers
and
responses
which
there's
no
reason
to
so.
We
went
into
this
thing
and
to
make
things
more
complicated.
I
Of
course,
many
of
the
times
for
debugging
of
our
stuff,
the
debug
info
that
we
get
out
of
our
programs,
is
base64
encoded.
So
so
we're
not
actually
sure
for,
like
Oh,
am
I
looking
at
the
wire
and
seeing
base64
or
did
I
just
base64
that
encode
it
so
that
I
could
debug
the
thing
right.
So
there's
a
couple
times
when
we
had
interoperability,
because
we
all
agreed
to
base64
things
when
we
actually
weren't
supposed
to
right.
I
I
So
constraint
hasn't
changed
since
105
his
arrange
a
voucher
was
had
was
stalled
by
a
couple
of
things.
The
major
thing
was
the
progression
of
the
CID
yang
documents
in
the
core
working
group.
Those
were
unstuck
a
little
bit
at
105
and
then
have
not
progressed
again
as
far
as
I
can
tell
so
where,
where
were
we
did
get
our
CID
allocation
Donna
like
the
last
day,
so
we
have
to
change
our
CID,
our
CID
number.
So
these
are
the
indexes
into
the
map
of
the
C
bore.
I
That
tells
you
maps
the
the
big
long
strings
that
we
have
in
the
Jason
or
they're,
not
big
long,
but
there's
strings
in
the
Jason
two
small
integers,
so
they've,
given
us
a
new
mapping
base,
and
that
requires
that,
at
least
for
the
examples
that
we
go
back
and
fix
our
code
and
do
interoperability
testing
again
with
it,
and
there
simply
hasn't
been
time
to
do
that.
In
addition,
Peter
van
der
stalk
who's-
not
here
this
week,
is
looking
for
work,
so
he
hasn't
had
any
time
to
work
on
the
documents
either.
I
So
there's
been
no
progress
on
that,
but
even
if
all
of
the
the
things
that
were
in
our
way
were
not
in
our
way,
I,
don't
think
any
of
the
authors
would
have
had
time
to
progress.
The
document,
since
we
have
other
documents,
co-op
est,
is
in
the
iesg
discuss.
So
that's
a
dependency
of
the
constraint
voter
document
and
so
there's
a
couple
other
other
documents
that
are
are
would
limit
our
progress
anyway.
So
there
seems
no
point
in
running
fast
and
stumbling
to
for
that
document.
I
J
D
I
So
I
hear
what
you're
saying
is
is
is
how
dare
I
do
new
work
when
I
haven't
finished
my
old
work,
yeah?
So
I
take
your
point
and
you're
absolutely
right
and
my
my
feeling
is
I
have
to
fix
my
code
before
I
can
produce
examples,
and
that
is
unfortunately,
a
different
mindset
for
me
than
writing
documents
or
editing
documents,
but
I
haven't
fixed
the
code
and
the
other
documents
suck
too.
I
You
notice
that
the
other
ones
are
pretty
bad,
so
so
not
exactly
you're
doing
a
lot
of
work
anyway,
but
it's
at
least
one
other
document
has
another
author,
which
is
the
sixth
ish
version
of
the
constraint.
Voucher
has
a
new
author
who
has
a
lot
of
enthusiasm
and
energy
and
so
hopefully
make
some
progress
on
that
as
well.
Yeah.
D
I
D
J
K
G
K
Of
always
figuring
this
out,
what
this
is
it's
an
this
tact
was
presented
or
a
variation
to
this
tech
was
presented
in
you
and
was
presented
IT
f-105
as
well.
What
it
is
is
it
shows
how
acne
and
can
be
used
for
multi,
to
enable
multiple
different,
how
acne
can
be
used
to
integrate
multiple
different
integrations
for
facilitating
client
or
device
Church
enrollment
and
the
one
that's
interesting
here
is
search
enrollment
with
these
two-year
brewski.
K
So
yeah
so
so,
basically,
and
it
can
be
integrated,
multiple
different,
existing
content
device,
enrollment
mechanisms,
the
one
that's
of
interest
here-
is
brewski
or
est
next
slide,
and
so
what
the
acne
integration
staff
does
cover
is.
It
covers
how
acne
can
be
integrated,
ste
brewski
boost
the
new
risky
cloud,
registered
raft
and
teeth,
and
there's
a
new
draft
40
pop
date
and
the
one
that
we'll
touch
on
here
is
EST,
because
brewskis
based
on
top
of
that
for
this
Freddie
Norman
piece,
anyways
next
slide,
and
so
we
presented
this
last
time
around.
K
What's
changed
is
and
an
acne
subdomains
part
has
been
broken
out
and
I
was
requested
at
the
acne
working
group
and
well,
but
acne
for
subdomains.
Does
it's
a
nice
optimization?
It
enables
a
acne
client
to
prove
ownership
of
a
parent
domain
and
then
issue
search,
enrollment
requests
for
hundreds
or
thousands
of
clients,
after
so
after
parent
am
in,
and
also
we've
added.
The
brewski
crowd.
K
Huge
kiss
has
been
added
to
acne
integrations
next,
so
you
had
the
two
met,
the
two
main
and
protocols
doing
that
we
can
integrate
acne
with
is
e,
ste
and
T.
So
both
east
G
and
T
describe
the
protocol
for
how
the
client
or
the
device
interacts
with
the
each
server
that
each
server
with
both
protocols,
its
out
of
scope,
filed
the
server
interacts
with
the
back
end
CA.
So
we
can
plug
in
acne
into
that
next.
K
Okay,
so
this
is
a
bit
of
an
eyeful,
but
it's
it's
straight
out
of
the
strata.
The
specs
on
the
left-hand
side
is
just
border
packing.
It
shows
how
an
ACME
client
can
interact
with
an
acne
server,
improve
ownership
of
a
parent's
domain
and
on
this
joint
example
of
domains
that
come
here
and
it
does
at
fire
well
as
most
unlikely
reason
by
which
you
can
do
it.
K
But
the
mechanism
showing
here
is
simply
by
publishing
a
text
record
to
DNS
and
proving
ownership
of
the
DNS
domain
and,
on
the
right
hand,
side
what
I'm
showing-
and
this
is
actually
this.
The
picture
on
the
right
hand,
side
is
from
the
previous
version
of
the
acme
draft
and
it's
missing
something,
and
what
it's
showing
is
how
a
pledge
our
client,
when
it's
interacting
with
an
ESD
or
a
or
a
brewski
registrar,
how
the
client
can
send
easting
sympton
will
request
to
the
RA
and
what
it
should
be
doing.
K
First
is
sending
a
CS
or
a
trapinch
request.
The
csr
attributes
request
is
documented
in
the
latest
version
of
draft.
It's
just
now
shown
this
light.
It
sends
an
e
CS
or
attributes
request,
gets
response
then
sends
a
nice
T,
symptom,
roll
request
to
the
RA,
and
it's
the
same
enroll
request
that
sent
for
brewski
as
well
as
baseline,
EST
and
the
or
a
can
then
turn
around
and
interact
with
AK
means
and
the
New
York
requests,
send
the
finalized
request
and
send
a
certificate
request.
K
If
necessary,
can
reply
with
a
two
or
two
and
if
it's
gonna
take
a
long
time
for
the
surgery
issued,
but
a
longer
time
interval
and
once
Acme
is
issued
a
certificate,
then
the
RA
a
just
turns
around
and
replies
to
the
simple
Road
request
with
a
with
a
pkcs7
response
and
that's
pretty
much
it
right.
So,
on
the
left
hand,
side
we
have
standard
e,
is
key
or
standard
brewski
and
the
right
hand
side
who
stand
Arachne.
There's
no
changes
required.
K
Why
the
protocol
it
is
to
work
and
the
one
optimization
that
has
been
proposed
and
it's
been
discussed
at
Wharton,
Group
and
actually
and
Friday
exactly
for
subdomains,
which
is
really
useful:
optimisation
for
issuing
device,
ID
certs,
and
but
apart
from
that,
there's
no
reason
why
we
can't
block
these
two
protocols
together.
There's
no
reason
why
we
can't
plug
acne
into
teep
as
well.
Next
slide.
K
And
so
what's
missing
from
this
is
is
security
considerations,
but
I
think
the
big
open
question
is
like
this:
integration
spans
across
the
acme,
the
EMU
and
the
Panama
working
groups
towards
this
dock
live,
and
quite
a
few
people
have
expressed
interest
in.
If
there's
interest
in
EU
does
interest
in
acme
there's
been
interest
here
as
well
and
towards
the
dock
belong
and
how
we
bring
it
forward.
L
E
K
Oh
an
emu,
an
emu.
In
order
for
this
to
work,
clean
e.
Believe
me,
we
actually
do
need
a
couple
of
updates
to
teep,
so
II
new
working
group,
our
supportive
offer,
but
want
to
tape,
updates
to
happen.
The
first
before
we
can
cleanly
integrate
teeth
with
acne
and
and
mu
are
considering
well
once
the
tick
mark
is
done.
It
may
make
sense
for
this.
Acne
integrations
draft
to
live
in.
In
you
don't
know:
I,
don't
wanna
have
the
same
conversation
on
Friday
at
the
acne
working
group
right.
F
F
K
It
really,
it
really
depends
on
what
the
private
interfaces
the
private
CA
supports,
like
for
example.
Well,
what
we
see
typically
most
of
our
customers,
were
on
Microsoft's
private,
see
that's
what
we
see
to
integrate,
what
microsoft
CA
you
have
to
integrate,
with
the
cost
from
proprietary
it
the
eyes
and
which
means,
if
you
actually
want
to
do
an
integration
to
microsoft,
CA.
You
need
to
get
an
SDK
and
build
a
custom
integration
onto
your
RA
to
integrate
with
microsoft
CA
out
there.
K
There
are
some
CAS
that
do
support
acne
that
you
can
deploy
on
premise
or
not.
Let's
encrypt
in
the
cloud
you
can
deploy
and
Acme
on-premise,
and
what
this
does
is.
If
it's
a
if
the
custom,
a
private
CA
you
can
deploy
on
premise,
support
act
make
this
just
a
standard
way
of
integrating
that
with
any
RA.
Okay,.
E
E
K
E
K
E
I
Michael
Richardson
I
think
it
probably
belongs
to
acne
I.
Think
that
if
there's
some
I
think
that
the
only
issue
I
think
is
going
to
be
working,
group
milestones
and
load,
in
which
case
asking
SEC
dispatch,
might
be
the
useful
thing,
but
I
don't
think
it's
I,
don't
think
it
makes
less
of
us
I.
Think
I!
Think
you
wind
up
in
acne,
I,
think
that's
the
right
right
answer.
Yeah.
Can
you
say
why?
I
Because
I
think
that
I
think
that
there
are
no
protocol
different
changes
to
brewski
that
it
impacts
mm-hmm
there
you
said
there
are
some
t
changes
that
are
required,
but
as
I
understand
them,
that's
because
of
validating
of
of
it's
the
whole
conversation
about
the
the
TLS
certificate
and
that
by
thread
that's
happening
right
now,
right
and
so.
I
So
so
that
will
have
an
impact
for
the
document
needs
to
be
kept
track
of
there,
but
I'm
saying
it's
primarily
I
think
I
think
primarily
it
needs.
It
needs
acne,
acne
review
rather
than
other
entities
review.
That's
why
I'm
saying
I
think
it
belongs.
There
probably
goes
right,
so
I
don't
think
we'll
get
a
working
group
last
call
review
from
acne
people
was
an
email,
for
instance,
yeah
right.
C
K
K
This
draft
does
and
well
really
what
a
captures
is
and
most
of
the
options
that
are
available
and
there's
a
bunch
of
open
items
willing
to
work
through
em.
The
two
primary
use
cases
for
a
cloud
registrar
are
a
pledge
bootstrapping
from
allocate
a
room,
location
remote
from
the
domain.
Where
a
must
register.
There
is
no
joint
proxy.
K
K
It's
a
default
cloud
registrar
is
when
the
plague
bootstraps
it
tries
to
discard.
It
tries
to
discover
a
registrar
on
its
local
domain
or
the
domain.
It's
bootstrapping
in
and
kind
of
find
one,
and
there
is
a
default
manufacturing
registrar
baked
into
its
farmer
like
it's
a
it's,
a
it's
a
Cisco
device
and
it
has
registrar
that
Cisco
to
come
back
into
it
and
I
just
go
to
the
manufacturers
cloud
to
find
out.
Where
do
I
go
next,
so
it's
kind
of
a
fallback.
It's
a
fallback
onea
and
it's
it's
documented
in
the
brewski
draft.
K
K
This
is
current.
This
is
the
high
level
architecture
showing
all
the
moving
parts
and
there's
multiple
different
possible.
Signaling
permutation
combinations
need
to
be
worked
through,
but
the
plug
is
going
to
connect
to
a
cloud
registrar
on
bootstrap
and
request
a
voucher.
The
crowd
register
will
enforce
mutual
TLS
it'll.
G
F
K
K
What
are
yours
you
want,
so
your
local
domain
is
where
you
power
the
thing
up
right.
You've
heard
it
up
here
in
the
ITF,
but
what
the
device
you
want
to
actually
register
to
my
Cisco
office
in
Ireland
are
so
so
I'm
plugged
box
and
I'm
a
remote
worker
I
powered
up
on
my
home
network
I'm,
a
remote
where
or
connects
to
the
cloud
and
the
cloud
were
redirected
to
the
corporate
network
or
the
operator
network.
That
I
want
to
connect
to.
K
So
for
home
domain
or
the
domain
that
I
want
to
connect
to
not
to
demand
on
bootstrap
booting
up
in
I'm
home
domain
requires
mutual
authentication.
So
the
pledge
you
must
be
imprinted
with
a
trust
anchor
for
the
home
registrar
and
the
plague.
You
may
need
to
be
imprinted
with
the
realm
or
domain
information
if
the
home
register
is
using
a
identity
circuit
signed
by
a
public
CA.
Well,
that's
currently
not
I'm
specified
how
this
could
work
in
vouchers
or
brewski
today,
and
the
home
registrar
must
either
have
visibility
to
and
verified
of
actors.
K
M
Tariqa
just
one
short
question:
is
it
possible
to
have
several
homes
for
one
physical
device?
Would
it
be
supported?
Because
you
know
we
have
this
bio
two
situations
and
more
and
more
virtual
domains
like
within
one
physical
device,
some
kind
of
secure
environments,
you
know
which
essentially
make
the
beam
to
services.
M
Correct
it's
a
general
question,
but
it
would
be
supported
at
all,
because
I
think
today
we
be
faces
it.
The
situation
typically
right.
The
the
examples
that
you
just
have
given
that
you
connect
to
your
let's
say:
Enterprise
is
very
clear
as
long
as
we
are
let's
say
in
2005,
but
somehow
today
I
feel
that
my
PC
can
connect
to
several
homes.
It
depends
on
what
role
it
just
plays
so
I
have
the
secure
enclaves
right.
We
are
supported
from
the
chipsets,
so.
M
Correct
tory's:
it's
a
public
good!
Well,
that's
all
my
question,
but
sorry
as
long
as
it
is
that
what
some
of
the
answers
it
works
at
this
point,
there's
nothing
there
use
whatever
may
be.
Just
what
L
may
be
the
same.
Mac
address
would
somehow
make
it
not
work.
I,
don't
know
I'm
just
asking
a
question:
yeah
yeah.
K
So
this
there's
three
major
deployment
and
operational
models.
We
want
to
talk
to
three
major
options
and
which
shopkins
make
sense.
Should
we
support
all
of
them?
Should
we
support?
None
of
them
are
the
questions
you
need
to
answer.
So
the
first
option
is
when
the
pledge
connects
the
fallback
or
default
registrar
and
the
card
register
will
do
mutual
authentication.
It
will
verify
the
idea
of
ID
that's
installed
on
the
page
and
the
collaborator
will
have
a
lookup
table.
So
this
idea
of
ie
this
device
and
should
be
redirected
to
this
home
registrar.
K
The
cloud
isn't
going
to
issue
a
bit
about
your
response
to
cover
is
gonna,
do
HTTP
3xx
response
and
redirect
the
voucher
to
the
home
register
the
vouchers
that
are
sorry.
The
pledge
is,
then
gonna
do
standard,
brewski
flow
against
the
home
registrar
and
send
a
new
value
request
via
the
home
register.
Okay,
this
is
kind
of
the
simplest
case
next
slide.
K
So
this
is
scenario
number
two
where
the
card
register
is
going
to
issue
a
voucher
and
the
home
CA
is
going
to
issue
or
the
home.
She
is
going
to
issue
a
local
device
ID
the
home.
She
is
going
to
choose
local,
it's
significant
search,
so
Kyra
cherish
is
a
voucher.
The
crowd
rag
is
the
next
step
that
the
leg
is
going
to
use.
K
The
pledge
is
going
to
start
the
est
enrollment
operation
is
going
to
send
the
C's
or
attributes
then
send
an
enroll
request
so
when
it
sends
its
first
est
operations
the
card
register,
the
car
racer
can
3xx
worse
with
three
exits
and
redirected
to
the
home.
Registrar
and
another
option,
of
course,
is
that
the
voucher
could
includes
the
home
domain
network
as
a
field.
That's
not
in
there
yet
either.
K
The
problem
we
have
here
is
the
voucher
issued
by
the
voucher
issued
by
the
cloud
and
is
not
going
to
be
seen
by
the
home
registrar.
If
the
crowd
just
does
a
simple
3-xx
redirect
on
the
uski
request,
how
does
the
home
registrar?
Do
you
mutual
authentication,
how's,
the
home,
registrar
cat
visibility
to
the
voucher
that
was
issued,
because
the
factor
that
is
issued
is
going
to
find
the
pledge
to
the
home
domain
and
the
voucher?
That
is
the
you
will
also
have
to
pledges
and
serial
numbers.
K
So
there's
a
couple
of
different
options
for
how
the
home
rights
track.
You
get
the
voucher,
it
could
be
potentially
included
as
a
barrier
token
DHCP
requests
and
the
home
register
could
potentially
fetch
the
back
from
the
cloud
or
they
look.
The
lowest
common
denominator
is
that
the
the
pledge
identity
needs
to
be
explicitly
provisioned
on
the
home
network,
as
well
as
in
the
cloud.
There's
three
options
there
and
we
don't
know
which
is
the
correct
one
to
take
next
slide,
and
so
in
this
scenario,
the
card
register
is
issuing
device
around
the
cloud.
K
Ta
also
issues
the
local,
a
significant
search,
so
there's
two
problems
here:
right
and
first,
how
does
the
cloud
Registrar
tell
the
pledge
what
it's
holding
service
two
mayonnaise
tanning
pledges
buzzer
home
service
domain
is
currently
not
in
scope
at
all
for
risky
fractures,
and
the
second
problem
is
the
certificate
that's
issued
by
the
cloud
CA
and
because
the
cloud,
the
registrar
and
the
cloud
CA
will
be
redirecting
pledges
across
multiple
different
home
domains,
assuming
there's
multiple
different
customers.
Are
you
urging
this?
K
How
is
that
locally
significant
certs
it'll
be
names
based,
so
that
the
homeless
service
domain
can
do
a
proper
Arabic
and
policy
check?
If
the,
for
example,
if
the
cloud
C
is,
let's
encrypt,
it's
not
a
strong
enough
policy
decision
for
the
homeless
services
to
check
that
the
certificate
is
from.
Let's
encrypt,
it
needs
to
check
out
the
certificate
is
from
let's
encrypt,
but
it's
also
something
named
operator.
Comm,
it's
not
their
open
question.
Do
we
do
not
know
the
answer
to
that's
like
and
this
this
is
last
slide.
K
It
just
summarizes
the
three
different
mechanisms
by
which
I
fall
back
or
default.
Carb
registrar
could
redirect
a
pledge
to
its
correct
home
register.
Error
does
open
questions
associated
with
all
three
options,
and
the
questions
we
have
is
how
many
options
should
be
supported
for
the
options
we
do
support.
How
do
we
answer
the
questions
that
are
posed
for
each
one
of
those
options
and
what
we
do
next.
K
Well,
what
water
would
there's
three
options
on
the
table
which,
if
any
of
those
three
options,
should
we
support
like
one
well
the
option
to
support?
None
of
them
means
that
we
need
to
operate
whiskey
to
remove
the
default
card
registrar,
so
we
should
be
sporting,
one
of
them
and
at
least
four
for
each
one
of
the
options.
There's
a
number
of
open
questions
that
need
to
be
answered
for
each
option.
So
we
need
to
figure
out
how
we
get
the
answers
for
those
questions
as
well,
and
then
what
are
our
next
steps?
K
Okay,
yeah,
so
which
options
do
we
support?
If
he's
working
under
them,
then
we
need
to
go
back
and
revisit
the
brewski
Draft.
So
we
have
to
support
at
least
one
of
them,
then,
for
the
open
for
the
subset
of
options,
we
support
there's
open
items
against
each
option
and
then
we
need
to
investigate
what
the
correct
answer
is
for
those
organizers.
E
E
K
E
I
So
correctly,
I
didn't
missing
the
differences,
so
Mike,
lurchers
and
so
yeah
yeah.
So
maybe
we
Ellis
trated
this
poorly.
By
putting
the
dotted
line
between
around
the
masa
and
the
other
thing,
I
was
I'm.
Sorry
I
was
my
suggestion
to
put
the
three
together
like
that,
so
that
you
could
see
you
could
easily
see
the
differences,
but
between
the
two
that
they
are
different
without
flipping
those
slides
but
totalus,
the
the
the
cloud
registrar
could
be
operated
by
anybody.
So
an
example
would
be
X.
I
Y
Zed
widgets
makes
a
thing
sells
it
on
Amazon
and
then,
but
the
cloud
registrar
that
it
uses
is
sewers.
Iot,
you
know
think
right.
So
in
that
case
you
know,
there's
really
a
fairly
far
relationship
between
the
different
pieces
and
and
there's
no
requirement
that
the
manufacturer
run
the
cloud
registrar,
there's.
Currently,
some
efficiencies
is
probably
some
you.
You
know
you
just
dip
into
the
same
sales
database.
If
you
want
to
and
stuff
like
that,
but
I
don't
think.
There's
any
strong
requirements,
architectural
II
in
to
doing
that.
E
I
To
validate
the
masses
vouchers
regardless,
that's
brewski!
Okay,
when
you
go
in
the
case
of
part
two
or
or
three,
but
it
particularly
two.
If
I
can't
read
it
either,
then
you
know:
there's
still
a
voucher,
that's
being
issued
that
spins,
the
Registrar
okay,
so
you,
after
that,
the
device
doesn't
have
to
actually
trust,
have
a
trust,
the
cloud
registrar,
because
it's
still
going
to
get
pinned
by
the
Massa
by
the
voucher
same
as
inverse
key,
no
difference
there
and
in
in
at
least
one
of
these
cases
it
is
a
local
registrar.
I
It's
just
not
local
to
the
network
you're
on.
So
that's
the
case
where
you
take
your
take
a
company
phone
and
bring
it
to
IETF
your
or
something
like
that,
and
you
want
it
to
work
with
the
with
your
company,
even
though
you're
not
actually
at
the
company
and
that's
why
you
don't
have
any
anima
infrastructure
to
help
you
get
on
board
it
right.
So
that's
where
the
manufacturers
cloud
registrar,
redirects
you
to
the
local
registrar,
though
sorry,
not
the
local,
the
company
registrar,
possibly
over
the
internet,
but
you
still
onboarding
with
that
local.
I
E
I
G
I
Group
right
certainly,
we
find
certainly
a
viaduct
a
in
the
case.
They
there
there's
no
local,
that's
a
hosted
PBX
solution,
so
they
want.
But
but
each
customer
has,
you
know,
gets
a
stack
of
virtual
PBX
equipments
in
a
in
a
nearby
cloud,
nearby
public
cloud
and
so
the
manufacturer
actually
redirects
them.
You
know
maybe
only
three
hops
down
the
street
to
their
PBX
system
right
and
and
they're
gonna
get
onboard
into
that
system.
It
just
happens
not
to
be
within
their
building.
Okay,
that's
all,
but.
K
One
deployment
scenario
that
are
Dutch
IP
phones
need
to
figure
out
when
you
play
so
I've
taken
on
people,
in
other
words
box
in
my
home
office
and
I
plug
it
in
for
the
first
time
and
I
could
be
getting
service
from
okay,
I'll,
say
Cisco
I
could
be
getting
service
from
a
Cisco
hosted.
Sir,
it's
a
Cisco
phone
I
could
be
getting
service
from
a
Cisco.
Bolstered
virtual
PBX
I
could
be
getting
service
from
a
service
provider.
It
could
be
an
open
service.
I
K
I
C
N
Okay,
so
I
know
we're
a
little
bit
behind
schedule,
so
I'll
try
to
be
pretty
quick.
I
am
here
to
try
and
get
this
discussed
resolved
on
the
ACP
document.
The
RCA
to
need
to
name
aspect
is
probably
the
trickiest
part,
there's
a
few
other
things
that
should
be
pretty
mechanical
so
summer.
Here
is
I'm,
frequently
confused.
If
I'm
confused
getting
me,
unconfused
is
going
to
be
a
success.
N
I've
come
here,
so
please
be
don't
be
shy
about
jamming
apples,
Mike,
so
just
set
the
stage
I'm
gonna
be
using
a
be
enough
accepts
my
minor
tweak
to
make
it
a
little
bit
more
sense.
I'm
just
gonna
go
through
the
a
be
enough
and
then
talk
about
a
little
bit
more
so
breaking
down
to
the
little
components.
We've
got
this
RFC
self
literal
string.
N
That's
just
sort
of
saying
this
is
the
type
of
thing
that
we're
using
in
our
name
and
that's
sort
of
my
understanding
of
it,
and
then
we've
got
the
IP
address
pretty
straightforward
and
then
in
the
our
sub.
So
we've
got
this
routing
sub
domain
concept
and
we
have
the
R
sub
string
that
we
append
or
prepend
to
the
domain
in
order
to
get
the
routing
sub
domain
itself,
and
so
this
RS
I
was
like
a
prefix.
N
I
tried
to
go
back
through
the
email
discussion
and
through
the
document,
and
the
only
thing
I
could
find
that
we
actually
use
this.
For
is
this
input
to
the
hash
and
so
I
forced
to
assume
that
this
is
also
used
in
like
the
human
readable
output
that
we
can
get
out
and
extract
in
a
certificate.
So
it's
like
used
for
organizational
reporting
about
which
part
of
the
network
is.
E
This
device
part
of
no
so
basically
the
whole
idea-
was
that
the
local
parts
would
have
kind
of
all
the
local
attributes
that
we
need.
In
addition
to,
let's
say
the
the
the
simple
address
stuff
and
one
of
the
things
were
doing
algorithmically
out
of
it
is
the
calculation
of
the
hash.
So
if
we
start
saying
we
have
the
one
security
domain
which
is
coming
from
the
ACP
domain
name
right.
So
that's
basically,
for
example,
where
we
we
based
the
trust
anchors
but
we're
starting
with
multiple
separate
networks.
E
Then
the
separate
network
should
have
separate
address
prefixes.
So
basically
the
Arzo
creates
the
ability
to
have
different
address
prefixes,
and
so
then
these
can
be
easier,
concatenated
together,
right,
so
you're,
basically
saying
okay,
I've
got
just
one
trust
Amina,
but
I
need
to
have
five
different
networks.
If
they
all
have
the
same
addressing
prefix,
then
we
can't
basically
easily
partition
and
put
them
together
right.
We
get
so
that
it's
just
you
know
some
some
trick
to
make.
You
know
the.
I
Think
think
of
it,
as
some
large
campus
say,
I,
don't
know
Cambridge
University,
as
you
may
know,
that
has
sub
campuses
in
other
cities,
but
our
wishes
to,
but
but
doesn't
want
to
run
a
ula
across
all
of
them.
Okay,
however,
anticipates
that
possibility
of
multi
terabit
networking,
which
would
change
their
their
view
on
that,
and
so
they
want
to
make
sure
that
there's
not
going
to
be
a
overlap
or
conflict
in
the
future
right.
E
E
Use
case
we
actually
were
faced
with
they're
talking
with
customers
at
that,
when
we
came
to
these
things
was
you
know
you
wanted
to
go
autonomic,
but
then
you
do
interconnect
through
a
third
party
like
a
layer,
3
VPN
provider,
and
there
you
don't
have
the
autonomic
mechanism
so,
but
you
wanted
to
foresee
that
the
you
know
third
party
service
provider
at
some
point
would
also
be
able
to
integrate
across
it.
So.
N
I
The
idea
is
that
that
the
administrator
types
in
his
domain
name,
the
UI,
runs
the
hash,
okay
of
that
to
make
a
ula
which
presents
to
him
okay,
which
for
most
of
people
they
just
hit
next,
and
it's
done.
They
never
need
to
know
that
again
unless
they
were
to
reconfigure
the
whole
thing,
in
which
case
you
get
deterministic
the
same
thing.
However,
some
of
them
realize
no,
no,
no
I'm
supposed
to
use
this
ula
cuz.
I
You
know
there
was
some
decision
about
previously
installed,
whatever,
in
which
case
they
over
type
that
that
ula
with
something
that
they
use
last
time
and
which
case
they
go
forward
that
way.
So
at
that
point,
yes,
we
generated
the
ula
from
that
that
string
and
that's
the
default
recommendation,
but
we
don't
want
to
ever
have
anyone
else
have
to
run
that
hash
again
in
case
they've
decided
that
there's
a
different
address
space
they're
going
to
use
that
make
sense
so
like
we
don't.
I
N
E
There
is
always
the
fine
line
in
terms
of
figuring
out.
What
is
this,
you
know
persistent
type
of
policy
that
otherwise
would
be
very
hard
to
distribute
right
because
I
mean
you
look
at
something
like
brewski
and
if,
if
we're
trying
to
have
you
know
core
bootstrap
information,
you
know
that
wouldn't
be
in
a
certificate.
Then
we
we
have
to
reinvent
kind
of
something
as
complex
as
this
as
brewski
and
and
so
that's
that's
a
fine
line.
So
we
try
to
minimize
it
and
definitely
the
RSF
is
really
at
the
edge
of
that
information.
E
Right
and
I.
Think
at
this
point
in
time,
we
just
feel
a
lot
more
comfortable
if
we
sure,
if
we
have
it
in
there,
but
it's
certainly
something
we
also
need
to
explore.
We
didn't
have
that
in
initial.
You
know
pre
standard
implementations,
but
basically
there
was
a
lot
of
interest
expressed
to
be
able
to
better
address
these
larger
denominator.
Okay,.
N
E
N
N
Is
just
come
at
it
from
like
the
x5,
a
nine
point
of
view,
we're
having
an
extension
point
in
the
name
of
the
thing
being
certified
feels
very
streams
as
like
a
cognitive
mismatch,
I
mean
so
like
in
the
certificate.
This
is
going
in
the
RFC
82
dating
Thea,
so
it's
like
the
name
of
the
thing
being
certified
and
so
having
an
extension
point
in
the
syntax,
for
your
name
feels
a
little
bit
weird
I
can
sort
of
see
how
it
might
make
sense.
These.
N
And
then,
of
course,
we're
sort
of
covered
the
ACP
domain
name,
that's
pretty
key,
you
know
it
it's
the
tenant
of.
Are
you
part
of
the
same
domain
or
not?
It
goes
into
the
authorization
policy
is
pretty
important,
so
I
tried
to
make
a
little
table
except
table
formatting
and
lot
tech,
it's
hard.
So
it's
a
list
and
that's
basically
summarizing
my
understanding
of
what
we
talked
about
the
previous
slides.
N
N
So
if
we
need
to
say
something
about
the
type
of
the
thing
we're
shooting
we're
certifying
in
the
certificate,
we
can
have
x5
an
extension.
That's
a
pretty
common
thing
to
have
x5.
An
extension
to
say
you
know,
is
the
certificate
for
doing
thing
X,
as
opposed
to
the
certificate
for
doing
thing
Y,
as
opposed
to
you
know
a
web
certificate
or
a
seed
certificate,
and
the
crysta
got
the
IP
address.
We
actually
have
a
name
type
with
IP
address.
N
Of
course,
if
we're
using
x5
on
our
extensions,
that's
sort
of
an
extension
point,
the
every,
if
we've
not
using
the
x5,
ending
name
for
getting
the
domain
information
in
the
certificate
and
then
the
domain
name,
I
didn't
have
as
great
of
a
natural
place
to
put
that
the
best
I
could
come
up
with
was
to
say.
Okay,
we've
got
x5
on
an
extension
in
a
certificate.
That's
gonna
be
like
our
type
marker
for
this
as
a
CP
node
certificate,
given
that
we
already
have
that
we
can
stuff
a
little
bit
more
information
in
there.
N
The
ACP
domain
name
is
kind
of
intrinsically
tied
to
being
an
ACP
certificate,
so
just
from
the
sort
of
information
model
mapping
putting
the
ACP
domain
name
in
the
x5,
an
extension-
that's
our
type
marker
feels
fairly
natural.
It's
not
a
knock
out
of
the
park
perfect
fit,
but
that
would
be
my
sort
of
sense
of
how
to
do
it
and.
E
I,
maybe
give
another
point
to
think
about
it,
so
the
primary
you
know
subject
identification
through
the
subject.
Name
kind
of
you
know
to
me.
It
always
looks
very
similar
to
X
400,
identifying
some
object
through
this.
You
know
tied
value
list
of
pairs
right
and
effectively.
You
know
an
RFC
822
address
is
very
much
the
same
thing
and
actually
in
the
industry
has
won
out
over
X
400
to
name
objects
right.
E
That's
why
it's
it's
natural
from
that
perspective
and
the
whole
idea,
of
course,
was
not
to
use
the
subject
name
because
we
wanted
to
reuse
a
certificate,
so
somebody
else
might
have
already
some
assignment.
The
subject
name
needs
to
be
something
else.
So
we
wanted
to
sneak
in
so
that
we
can
basically
extend
the
use
of
existing
kind
of
that
the
certificates
are
used
for
something
and
the
entity
right.
I.
N
I
We
didn't
do
all
these
other
things
and
I
argue
for
doing
all
this.
Okay,
the
reason
we
didn't
go
that
way
or
I
didn't
I
was
in
the
rough
as
it
were,
was
that
we
have
operational
experience
that
we
can't
get
CS
to
put
anything
in
other
than
a
name
and
since
they
can
verify
the
part
on
the
right
hand,
side
of
the
app
and
that's
a
domain
name,
and
they
can
verify
the
ownership
of
that
and
they'll.
I
Let
us
put
anything
that
we
like,
on
the
left
hand,
part
mostly,
because
it's
not
their
business,
that
we
at
least
could
get
through,
that
that
part
right
and
and
toilets
also
made
sure
that
if
they
really
wanted
to
verify
that
part
by
saying
an
email
to
it,
that
we
could
actually
do
that
and
create
a
mailbox
to
create,
receive
the
email
to
validate
the
whole
thing.
If
we
needed
to
do
that
right
so
so
that
we
just
we,
we
just
didn't-
want
to
fight
the
the
CA
infrastructure,
because
it's
hard
enough
already.
N
I
They
just
don't
know
how
they
you
just
you
just
you,
you
try
to
do
it
unless
it's
your
own
CA
that
you
control
enough
detail
on
you
wind
up
with
you
know.
Well,
you
just
can't
do
that
here
right.
So
that's
that's
where
it
came
from
and
I
think
it's
I've
written
the
code
I
think
it's!
It's
ugly
dogs
breakfast
right,
but
you
know
what
it
doesn't
done
much
and
we
we
actually
have
on
the
on
the
client
and
the
new
device.
E
And
I'm
also
looking
from
the
operators
experience
right.
So
all
the
crazy
tooling
you
may
have,
whether
it's
you
know
OpenSSH
or
others.
Right
so
I
mean
you
always
get
the
bloody
RFC
822
address
string
in
a
human
readable
form,
so
you
know
fortunately
there's
a
lot
more
known
than
autonomic
Administration.
On
the
security
side.
Right
I
mean
almost
nothing
there.
You
know
from
the
Massa
to
the
registrar.
All
these
things
are
non
autonomic.
E
Humans
need
to
surveil
that,
and
so
basically
the
a20
to
address
is
actually
fairly
easy
to
read
for
for
humans
right
and
we
don't
have
to
define
it's
a
standard
presentation
make
standard
presentations
which
we
otherwise
would
need.
If
all
the
same
information
fields
would
be
in
a
binary
encoding
from
it.
I
also
have
to
define
a
standard,
Hume
presentation
and
then
how
do
I
get
that
standard
human
presentation
to
a
lot
of
tooling
that
exists
right.
N
Now
it's
sort
of
dovetailing,
naturally
into
the
other
question
I
sort
of
had,
which
is
you
know.
Yes,
I've
heard
that
we
need
the
human
readable
version
of
this
and
you're
just
saying
right
now
about
how
that
comes
in
throughout
several
stages.
The
process,
which
is
good
for
me
to
think
about
and
I
just
sort
of
final
question
about
is
in
terms
of
when
we
have
the
human
readable
part.
N
E
Think
the
domain
name
so,
for
example,
if
you're
really
saying
oh
I,
want
to
create
different
domains
within
my
security
context,
right
you're,
a
single
organization,
you
want
to
have
networks
that
shouldn't
talk
to
each
other,
so
their
domain
names
need
to
be
different.
So
that's
something
that
you
would
immediately
have
in
any
type
of
neighbor
ship
forming
yeah
you're.
E
Not
because
the
keys
are
incompatible,
but
the
domain
name.
So
the
reason
why
you
know
you
couldn't
attach
these
devices
would
be
immediately
seeing
all
the
domain
name
strings
are
different
right.
So
all
the
pieces
I
think
are
important
to
see.
Actually
the
question
of
what
would
we
likely
see
in
extensions
I
said
we
don't
have
an
idea,
but
that's
not
true
I,
just
didn't
remember
so,
for
example,
the
one
next
logical
thing
is
key
roles
right,
so
we've
been
talking
about.
E
We
have
the
role
of
the
registrar
where
we've
been
starting
to
put
one
existing
flag
in
there
already
right,
but
there
might
be
other
important
roles
like
for
the
NOC
to
be
able
to
push
down
policy
into
other
devices
or
things,
but
we
still
don't
are
far
away
from
complete
mutual
autonomic.
Anybody
can
do
something
at
the
same
level
of
authority
and-
and
those
are
all
things
I
think
are
going
to
be
important
extensions
that
certain
devices
are
going
to
be
given
certificates
with
the
specific
role.
That
would
be
an
example.
Okay,.
N
O
So
the
changes
from
the
last
meeting,
as
basically
some
updates
of
the
introduction
text
that
relate
to
the
usage
of
ID,
f,
ID
and
rfid.
So
it
basically
explains
the
self
contained
object
that
is
being
used
here
or
that
is
being
argumented,
and
it
explains
that
a
nun
protocol
agnostic
way.
I
also
updated
the
description
of
some
architectural
elements
and
changes
in
the
Brisky
architecture.
So
it's
just
an
enhancement
to
section
5,
which
was
already
there.
O
So
the
biggest
change
of
the
biggest
enhancement
of
the
draft
is
actually
the
introduction
of
an
addressing
scheme
when
more
than
one
enrollment
for
the
course
being
used.
So
I
have
a
slide
on
that
one
as
well,
and
the
consideration
of
existing
enrollment
protocols
has
been
enhanced.
So
last
time
there
was
a
discussion
about
that.
O
What
we
need
for
a
synchronous
enrollment
is
to
have
a
binding
of
the
proof
of
procession
which
we
get
into
the
pkcs
10
request,
and
then
we
need
a
binding
of
the
proof
of
identity
that
is
being
done
in
Brisky,
using
the
direct
binding
to
TLS.
If
we
have
multiple
TLS
hops
to
the
RA
or
if
we
have
a
terminated
connection
and
no
connection
to
backward
services
or
back-end
services,
then
we
need
something
else.
Brisky
AE
is
basically
motivating
that
was
having
a
rep
pkcs
10
can
be
done
with
a
CMS
for
instance.
O
So
what
we
also
need
is
a
certificate
waiting
indication.
That
is
what
Elliot
likes
to
reference
as
come
back
later
for
the
soup
that
has
been
included
in
the
last
iteration
of
the
draft.
Already
so
I
skipped
that
slide.
So
what
I
said
at
the
beginning,
we
have
more
than
one
enrollment
protocol,
so
unfortunately
we
have
that
so
we
have
est-ce
npc
MC
s--
kept
within
the
ACE
working
group.
There
is
a
new
est
wrapping
being
defined
which
actually
ends
up
in
something
like
a
self-contained
object.
O
But
it
could
also
be
some
of
the
other
protocols
that
are
stated
there,
and
the
request
will
basically
be
something
like
simple
enroll
that
has
been
used
in
risky
or
full
CMC
requests,
which
would
be
used
in
risky
AE
for
the
safe
contained
object,
so
open
issue
that
we
see
risky
itself
regarding
the
naming
scheme
or
that
addressing
scheme
risky
uses
est
over
HTTPS.
If
we
also
take
into
account
what's
happening
in
the
ACE
working
group
with
co-op
est,
we
may
enhance
the
naming
scheme
to
also
support
co-op
s
instead
of
HTTPS
there.
O
So,
what's
what's
being
necessary,
is
a
selection
of
a
set
of
mandatory
enrollment
protocols
to
increase
interoperability,
but
keeping
the
option
to
also
select
other
and
loan
and
protocols
that
brought
us
to
the
introduction
at
least
partly
introduction
of
some
kind
of
discovery
mechanism
which
is
auktioner.
The
discovery
mechanism
could
use
the
naming
scheme
for
the
different
enrollment
for
the
code,
so
a
pledge
could
easily
be
discover
which
enrollment
other
codes
are
supported
by
the
registrar.
O
So
to
not
change
too
much
of
the
architecture
but
being
able
to
to
let
the
pledge
work
as
a
server
and
well.
That
is
actually
the
reason
that
I
think
right.
Now,
it's
not
the
right
time
to
ask
for
reduction.
We
have
asked
for
adoption
last
time,
but
then
this
new
feature
came
into
into
the
picture
and
we
thought
it's
better
to
not
ask
for
adoption.
So
it's
just
an
update
that
I
would
like
to
give
you.
E
Would
but
it'd
still
be,
you
know
a
separate
small.
You
know
HTTP
like
like
a
separate
one,
which
I
mean
brewski
right
now
is
kind
of
EST,
plus
plus
so
the
limited
context,
or
even
in
a
more
broader
context,
like
let's
say
in
a
net
confessed
connection
at
which,
which
maybe
embroider
it
could
probably
also
be
a
broader
approach.
E
What
I
mean
they?
They
obviously
have
some
opinions
of
their
own
in
terms
of
already
having
a
bunch
of
components
like
you
know,
certificate
enrollment
that
would
replace
her
70/30,
but
obviously
nothing
that
would
replace
the
brewski
elements
right.
So
that
seems,
like
you
know,
a
fairly
big
difference
in
how
they
do
encoding
models
or
so,
but
maybe
the
the
brewski
steps
would
be
logical
to
bring
into
that
context
right.
O
So
what
we
had
in
mind
here
are
two
different
modes
actually
for
push.
Oneness
just
push
the
pledge
to
start
with
risky,
and
that
could
be
if
the
network
is
discovering
that
there
is
a
new
device
in
the
network.
Instead
of
the
the
device
is
discovering
that
it's
happened
to
be
in
a
new
network
and
the
other
thing
would
be
to
reverse
the
roads
that
the
pledge
is
really
the
server.
D
F
I
I
So
someone
who
you
know
actually
could
do
something,
perhaps
before
they
put
the
device,
take
the
device
off
their
network
and
put
it
in
a
box
and
ship
it
to
you
second
sell
via
creditor
bankruptcy,
etc,
which
means
that
in
fact
means
that
the
and
the
enterprise
that
has
the
equipment
essentially
is
non-functional,
doesn't
exists
and
you
couldn't
you
can't
really
get
anywhere
with
it.
So
the
second
problem,
manufacturer
of
assembly
or
composite
devices.
I
The
examples
been
given
as
a
passenger
rail
car
that
might
have
a
whole
bunch
of
interesting
sensors
on
them,
which
will
be
not
proxied,
so
they'll
actually
all
be
on
the
network
and
they
all
need
to
be
on
boarded.
But
the
the
assembly
needs
to
be
on
boarded
together
and
they
don't
want
the
devices
that
are
you
assemble
with
to
each
be
having
vouchers
from
their
their
manufacturers.
You
want
some
other
process
and
the
same
same
situations
been
sent
for
Factory
kind
of
environments
disconnected
owner.
I
Who
can
then
issue
another
certificate
which
is
more
specific,
and
then
you
might
have
a
have
a
limit
to
how
many
of
these
chains
of
certificates
that
you
could
have?
Okay,
that's
the
general
shape
of
what
it
would
look
like.
So
imagine
this
is
the
the
first
case
you
had
a
delegated
voucher.
This
dv1
to
have
owner
number
one
owner
number
one
effectively
can
now
run
a
Massa
and
can
delegate
to
owner
number
two
okay
and
the
pledge
has
to
evaluate
the
whole
set.
I
So
you
have
to
send
the
dv1
voucher,
along
with
the
ephemeral
voucher,
so
that
the
pledge
can
see.
Oh
I
can
go
from
the
original
Massa
to
the
first
owner
and
then
to
the
second
owner
right.
So
you
have
this
chain
of
rare
thing
and
here's
another
example
with
a
third
thing:
how
many
layers
and
this
chain
do
you
want
to
have?
Well
that's
an
interesting
question
whether
you
want
to
have
a
limit
or
not
one
of
the
things
that
you
can
do
with
this
is
owner.
I
One
could
be
the
same
guy
as
owner,
but
owner
two
is
when
he
has
a
new
see
a
right.
So
the
last
thing
he
does
before
he
gets
a
new
changes
hit
from
godaddy
to
thottie.
Right
is
issue
himself
as
a
delegated
voucher
for
his
new
name
right,
which
lets
them
basically
continue
operating,
that's
really
yet,
okay
and
in
intermediary.
That's
conversations
with
some
companies
that
do
essentially
they
collect
equipment
from
bankrupt
companies
and
resell
them.
I
I
How
am
I
going
to
get
ownership
of
things,
and
so
they
may
be
able
to
negotiate
with
the
manufacturers
better
than
I
can
and
in
particular,
if
they
do
it
right,
then
the
they
may
be
able
to
essentially
go
in
and
put
their
own
trust
anchors
into
the
equipment
and
have
the
expertise
to
do
that,
whereas
I
either
won't
or
many
I
won't
have
the
right
chance
to
do
that.
So
they
could
resell
things
and
do
that
and
there's
a
bunch
of
cases
where
people
said
an
intermediary
would
would
help
add
a
layer
of
indirection.