►
From YouTube: Istio Security Working Group Meeting 2019-05-01
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
We
have
one
agenda
today,
which
is
this
beefy
trust
domain
and
bundle
presented
by
Eva
event.
So
this
one
was
to
give
some
background.
This
one
was
already
discussed
in
their
spiffy
working
group
and
I-
guess
maybe
multiple
times
so,
but
we
haven't
presented
here
so
I
want
to
introduce
this
document
to
this
community
and
yeah.
A
It
will
be
most
beneficial
to
spiffy
team
and
there
is
two
team
and
also
on
our
side,
there's
still
team.
We
are
planning
to
do
this
support
this
trust,
omen
and
bundle,
as
well
as
following
their
TV
standard.
So
yeah
I
think
a
you.
Man
can
give
a
presentation
about
this
or
just
yeah
talk
through
this,
and
maybe
if
we
have
time,
I
can
also
talk
about
how
he
still
how
we
think
about
this
yeah.
B
B
Oops
just
unloaded
there
we
go
alright,
so
the
scope
of
this
document
that
we've
been
working
on
this
document
in
this
be
suspect
route
for
several
months
now,
it's
kind
of
got
to
the
point
where
it's
mostly
stabilized,
there's
a
small
number
to
I
think
two
different
kind
of
edits
that
are
outstanding
that
we
like
to
make
before
we
publish
it
as
a
proposed
specification,
but
you
know
wanted
to
kind
of
take
the
time
to
present
it
to
the
sto
community
today,
to
kind
of
get
your
guys
thoughts
and
feedback
on
it.
You
know.
B
B
So
this
disco
of
this
document
is
basically
trying
to
try
to
define
you
know
the
logical
idea
of
a
custom
main.
We
have
trust
a
main
to
find
in
this
50
ID
specification
as
to
those
component
of
the
URI,
but
we
don't.
We
don't
talk
a
lot
about
kind
of
the
semantics
of
a
trust
domain.
We
also
used
the
term
bundle
a
lot,
but
we
haven't
been
really
defined
that
term
and
talk
about
what
it
means,
and
so
this
document
is
aimed
at
kind
of
putting
some
concrete.
B
B
It
means
that
maybe
that
may
be
named
as
something
news,
so
we
treat
them
kind
of
as
opaque
strings
and
for
each
one
of
these
opaque
strings,
this
trust
domain
there's
a
set
of
signing
keys.
There
can
be
multiple
sign
keys.
We
multiple
signing
keys,
can
support
rotation
and
can
support
AJ
and
things
like
this.
A
B
Can
be,
but
there's
a
yes,
let
me
go
into
a
bundle.
I'm
done
it'll
be
a
little
bit
clearer.
So
in
order
to
kind
of
represent,
we
need.
We
need
a
way
to
represent
the
authorities
key
material,
all
right.
So
that's
what
we
call
it
bundle
and
and
in
this
bundle
is
essentially,
there
is
a
relationship
between
bundle
to
trust
domain.
That
is,
let's
see
what
would
be
trust
it
made.
The
trust
domain
to
bundle
relationship
is
one-to-one,
so
you
can
have
one
signing
key,
which
is
signing
bundles
for
multiple
trusts.
B
Devane's
herbs,
I'm
signing
us
if
it's
in
multiple
trust
amines,
but
each
one
of
this
trust
amaze
has
their
own
bubble
can
be
that
the
bundle
is
identical
between
multiple
trust
items.
But
there
is
a
relationship.
There's
like
a
one
to
one
relationship
between
trust
domain,
a
bundle.
What
does
that
make
sense?
Fmo.
C
B
So
it
is
possible
for
a
singing
bird.
It
is
possible
for
one
bundle,
the
further
bundles
to
clean
trust,
amazed
to
be
identical.
So
if
you
have
trusted
name,
one
accustoming
two
and
there
could
have
managed
by
the
same
Authority
and
Trust
the
main
one
entrusted
me
to
have
their
own
bundles.
However,
they
happen
to
be
identical.
Bundles,
yes,.
B
And
like
the
internal
internal
control,
plane
implementation,
but
when
it
when
it
is
surfaced,
it
becomes
one-to-one
mapping
so
I
know
his
team
does
not
use
the
workload
API.
But
if
you
were
look
at
the
workload
API,
we
said
we
send
bundles
in
a
Mac
where
the
key
of
the
map
is
the
name
of
the
trust
domain,
and
then
the
value
is
the
bundle
so
as
it
is
exposed,
it
is
exposed
as
I
want
to
one
relationship.
B
A
Yeah
from
there,
let
me
try
to
interpret
this
from
trust
domain
to
bundle.
It
is
always
one
to
what
right,
yes,
okay
and
in
your
bundle,
you
may
have
multiple
kids,
yes,
so
from
one
trust
domain
to
key.
It's
a
1
to
n
Maddy,
but
those
kids
can
be
the
same
from
multiple
for
different
trust
comments.
Correct.
B
A
B
I
will
continue,
I
think
when
we
get
a
little
further
down.
Maybe
some
of
this
stuff
will
be
a
little
clearer,
so
so
we
define
this
bundle
and
its
relationship
to
trust
domain.
We
need
to
define
for
map
of
the
bundle.
So
you
know
what
news
bundles
are
transmitted
between
trust
domains
or
between
control
planes
for
different
trust
domains.
How
is
it
represented?
We
have
because
we
have
different
Aspen
tights.
B
We
need
kind
of
a
flexible
way
to
represent
raw
like
public
keys,
so
this
problem
is
like
fairly
well
solved
in
though
IDC
by
using
Jade
chaos
or
a
trinity
case
set
and
j2me
case
set,
is
defined,
RFC,
75
17
as
a
document
that
allows
you
to
essentially
like
a
second
marvel
of
for
a
public
key
material.
It
supports
many
different
kinds
of
public
keys,
but
it
is
not
necessarily
directly
tied
to
the
document
type
that
that
public
he
represents.
B
B
C
Forth
is
there
a
terminology?
If
was
private,
the
PE
class
bundle
send
it
to
the
workload.
Is
there
a
terminology
nology
or
is
also
called
a
bundle
to
walk
low,
the
bundle
or
I
just
want
to
clarify,
because
bundle
is
like
you
said
in
the
beginning:
bondo
is
used
everywhere.
I
just
want
to
have
a
clear
understanding.
You
know
the
bundle
exchanged
between
the
spire
servers
and
the
bundle
received
by
walk
load
right.
B
So
I
can
tell
you
how
we
have
done
this
with
the
workload
API
and
again.
I
know
that
you
guys
are
using
it
as
an
example.
This
this
bundle
format
is
what
we're
going
to
call
this
spiffy
bubble
right.
That's
the
spiffy
bundle
is
very
specific.
It
is
this
jwk
format
and
it
is
meant
primarily
for
exchange
between
smithy
trust
domains
are
exchanged
between
spiffy
implementations
control
plants.
This
is
different
than
what
we
call
bundle
and
workload
API
on
workload.
B
Api
forget
about
the
estimate
and
the
private
key
is
for
a
current
minute,
but
the
workload
still
needs
to
be
able
to
receive
the
public
use
the
signing
authorities
for
the
various
trusts
immense
right
and,
depending
on
the
type
of
s
good
that
is
being
validated
by
the
workload.
It
makes
sense
for
different
different
kinds
of
public
key
representations.
So,
if
we'd
hand
directly
this
fifty
bundle
to
the
workload.
The
workload
has
got
some
extra
work
to
do
in
order
to
make
sense
of
it
and
make
use
of
it,
for
instance,
an
x.509
validation.
B
So
we
avoid
this
in
Sewickley
workload,
api
and
in
sniffily
workload,
API
for
x.509
related
endpoints.
We
give
a
raw
x.509
bundle,
which
is
just
the
expert
on
ica
certificates.
For
that
festive
aim
for
JWT
we
give
the
trader
bks
format
that
includes
only
the
keys
for
the
JWT,
the
jana
bt
signing
keys.
So
when,
when
it
comes
time
to
interface
with
the
workload
we
used,
we
do
use
the
term
bundle,
but
we
use
it
in
the
context
of
the
estimate
type.
B
C
B
Workload
bundle
only
contains
the
public
keys
for
the
authority
and
that
trust
domain.
However,
we
do
give
the
workload
a
private
key
and
a
nested,
but
you
know
we
are
not
giving
obviously
the
private
key
of
the
authority
to
the
workload.
So
we
have
a
message
called
Espen
message,
which
includes
the
estimate
and
the
private
key
for
that
method,
and
then,
along
with
that,
we
provided
the
bundle
where
the
bundle
has
only
the
public
use
for
the
issuing
authority.
Okay,.
A
B
Well,
that's
kind
of
loyalists
thing
in
this
buddy
yeah
I.
We
give
a
bundle
which
is
which
is
the
one
that
makes
sense
for
the
estimate
type
right.
So
we
don't
give
it
the
spiffy
bubble,
which
is
like
this
and
perhaps
perhaps
I
should
amend.
Perhaps
I
should
amend
this
to
say:
spiffy
bundle,
format
or
something,
but
this
spiffy
bundle
format
is
not
meant
to
give
directly
to
a
workload.
I
mean,
certainly
you
could,
but
the
workload
will
have
to
make
sense
of
that.
So
for
us
we
just
give
like
the
x.509
CA
certificates.
A
A
So
if
you
have
a
speedy
transponders,
for
example,
if
you
have
two
mappings
one
mapping
from
Testament
one
to
sending
key
one,
the
other
one
is
from
trust
women
to
two
sang-hee,
two
very
simple,
and
then
how
you
deliver
that
information
on
to
the
workloads,
so
that
were
close
when
it's
talking
to
trust
a
memoir
and
Trust
omen.
It
understands
to
use
the
keys
he
won
and
the
key
to,
respectively.
B
A
A
A
B
The
way
that
is
done
so
the
workload
API
will
deliver
to
the
workload
a
map
and
the
keys
in
the
map
are
the
custom
main
and
the
values
are,
are
the
bundle.
So
in
the
case
of
x.509,
the
keys
are,
you
know,
trusted
main
once
estimate
and
the
values
are
a
set
of
CA
certificates
for
trust
having
one
on
a
set
of
CA
certificates
for
trusting
me
to
and
the
workload
library,
we'll
look
at
the
client
certificate
that
is
being
presented
and
then
we'll
choose
the
correct
bundle
for
validation
based
on
the
seven
system.
A
C
B
B
A
A
B
It
is
not
I,
don't
know
if
it's
I
don't
know.
If
API
is
the
right
word,
we
said,
we've
been
calling
it
bundle
and
point,
and
it
is.
It
follows
similar
mechanism
as
Jun
BK
s
URI
for
Apple
ID
C,
so
it
is
nominally
transmitted
with
TLS,
protected
HTTP
GET
and
you
define
the
end
point
for
a
particular
trust
domain.
B
So
so
you
know
back
to
kind
of
the
you
know
once
with
the
assertion
that
the
trust
domain
and
bundles
one-to-one,
even
though
the
bundle
between
multiple
trust
amaze
may
be
identical.
When
you
define
this
this,
this
bundle
end
point
this
Federation
relationship.
You
have
to
define
it,
you
say
trust
domain
1
as
bundle
endpoint,
foo
trust
to
make
two
may
also
have
bubble
and
point
food.
B
The
same
bundle,
but
you
want
to
be
able
to
kind
of
control
exactly
what's
trust
domains
are
being
federated
between
between
control
claims,
and
what
do
we
send
that
mapping?
We
know.
Okay,
even
though
trust
I
made
one
and
two
have
the
same
bundle.
We've
really
only
federated
with
trust
domain
1,
and
so
we
will
include
only
trust
in
main
one
in
that
Federation
mapped,
at
least
on
the
workload
sure,
okay,.
C
You
know
federating
CA
to
lie
about
its
ownership
of
or
Transco
main,
let's
say,
I'm
a
hacker
I
say
I'm,
an
owner
of
cusco
main
one
and
the
keys
are,
you
know,
et
cetera,
et
cetera,
but
do
you
have
like
a
centralized
the
cia's
that
are
governing
all
these
federating?
You
know
servers
Aspire
servers
to
say
to
prevent
someone
to
lie
about
their
ownership
of
trust
on
main
or
you
use
some
explicit
trust
relationship.
Saying
I,
trust
you
so
I.
C
B
We
don't
we
don't
provide
any
way
to
discover
the
trust
domain
on
point
and
we
do
this
purposefully
and
so
the
way
that
you
would
do
this
Federation
is
kind
of
down
here.
In
this
section,
you
would
manually
configure
the
name
of
the
trust
of
an
on
the
endpoint.
That
is
a
bundle
for
that
trust
domain.
So,
in
order
to
lie,
the
operator
has
to
be
tricked
okay,
I
say.
C
B
Okay,
correct
so
so
this
this
trust
domain,
endpoint,
two
bullets
kind
of
you
know
going
back
to
the
original
question
of
the
one-to-one
relationship
between
trust,
imminent
bundle.
This
configure
to
trust
domain
to
endpoint
to
blow
is
kind
of
where
that
starts
to
show
up
the
operator.
If
multiple
trust
events
share
a
bundle.
The
operator
may
configure
multiple
of
these
tuples
with
the
same
endpoint
address,
but
as
as
far
as
the
control
plane
is
concerned.
If
each
one
of
those
trust
domains
is
explicitly
federated
by
the
introduction
or
configuration
of
this
tool,
does
that.
C
B
To
be
as
compatible
as
possible
with
existing
IBC
works,
so
we
have
a
little
bit
of
research
to
do
on
coexistence
of
existing
YDC
key
material
with
the
smithy
key
material.
But
this
has
been
written
in
such
a
way
that
we
hope
that
it
should
be
free
or
very
easy
to
adopt
support
for
this.
An
existing,
oh
I,
DC,
libraries.
A
B
B
B
So
next
I
have
a
nine
document
type,
the
you
know
the
bundle
that
would
be
expected
as
a
set
of
CA
certificates,
so
so
the
modifications
that
are
required
that
are
required
for
a
workload
to
support
this
aren't
extremely
invasive
they're,
not
so
invasive
that
they
have
to
be
able
to
understand
this
new
bundle,
format
and
all
this
stuff,
but
they,
but
they
are
going
to
have
to
understand
this
kind
of
mapping
of
trust
domain
to
bundle
of
manage
multiple,
independent
bundles.
That's.
A
Right,
yeah,
yeah,
yeah
I.
Remember
previously,
we
were
talking
about
their
name
constraints,
yes
and
because,
of
course,
speedy
doesn't
understand
subdomains
they
don't
have
you
don't
have
some
domain
concepts,
so
the
name
constraint
is
not
really
enforced
mentioned
in
your
facts,
but
them
considered
again
it
it
needs
some
customization,
even
though
it's
already
in
expand
on
that
standard,
not
how
the
workflows
are
following
that
I
think
it's
basically
very
similar
to
this
and
also
I
think
using
the
trust,
Omen
distrust
on
the
solution.
A
B
Exactly
and
I
think
in
the
x.509
nested
specification
I
believe
there
is
some
language
exactly
talks
exactly
about
this
thing
that
name
constraint.
An
x.509
is
very
similar
to
what
we
were
trying
to
accomplish,
but
from
specification
point
of
view
is
fifty
point
of
view.
We
can't
we
can't
mandate
it
because
of
lack
of
widespread
implementation
support
for
it
also.
B
A
B
A
I'm
sorry
lint
is
ruin
if
you
are
applying
that
it's
not
a
single
customer,
because
Nikki's
review
will
be
applied
to
supplements
and
in
your
is
beefy
word,
the
sentiments
are
different
domains.
So
when
you
are
talking
about
like
supporting
name
constraints
is
vv,
you
are
actually
talking
about.
Multiple
trusted
means
yeah.
B
A
B
You
strain
is
optional
right,
so
it's
a
little
bit
of
a
you
know
and
and
to
introduce
name
constraint,
support
where
you
did
not
have
it
before
it
can
be
disruptive,
and
you
know
it's
not
not
fun
and
games
so
either
we
required
or
we
don't,
and
we
chose
not
to
for
a
number
of
reasons.
You
know
widespread
support
being
one
single
trust.
Having
case
being
another,
the
the
name
constraint
is
required
to
be
set
as
critical.
B
So
if
workload
encounters
a
CA
chain
that
has
name
constraint,
step
and
it
doesn't
know
how
to
do
you,
alright
income
strengthen
it
will
reject
this
this
certificate.
Also,
there
is
specific
to
x.509.
We
asked
the
obtain
a
BTS
bit
and
additional
as
the
types
in
the
future
and
a
constraint
character.
Yeah.
C
So
even
about
question
ohms
enforcement
on
workload
of
the
TV
bundle.
So
if
I
recall
correctly
the
STS
validation
context,
it
doesn't
have
as
a
concept
of
scope.
Basically,
if
you
have
a
few
public
is
certificated,
then
they
will
treat
them
as
no
scope
related,
no
scope
constraint
for
them.
So
basically,
how
does
like
us,
the
concept
of
or
for
trust
domain,
one
you
create
only
is
a
bundle.
Is
the
certificate
one?
Two
and
three:
how
does
this
is
actually
implementable?
On
SDS,
all
you
needed
to
change
is
a
mo
SDS
API.
B
C
B
Concept
that
there's
there
is
one
bundle
to
rule
them
all
and
it's
filled
with
all
the
different
CAS
and
the
rule
that
we
trust
is
one
that
that
you
know
I
think
there's
a
lot
of
flaws,
and-
and
so
you
know
this-
this
scoping
is
trying
to
work
around
some
of
those
flaws.
By
saying
this,
Authority
is
good
for
this.
One
trust
yeah.
C
B
In
the
context
of
SDS
API,
we
have
a
SDS
API
support
inspire
and
the
way
that
we
have
managed
validation
context
is
that
we
name
the
validation
context
resource
with
the
trust
domain,
so
the
trust
domain.
For
that
we
are
sending
the
bundle.
So
you
know
trust
domain
number
one
we
have
bundles
for
it.
We
send
the
validation
context
called
trusted
main
one
trusted
main.
We
have
bundles,
really
send
another
validation
contest
called
first
domain,
so
for
any
given
listener.
B
C
Path
is
n,
sub
e
Phi,
then
correctly
evil.
With
this
approach,
they
are
config
the
case
by
case
based
on
different
trust
domain.
One
here
for
this
listener
get
you
know
the
connection
from
trust,
Camilla
and
Trust
domain
to
they
are
not,
for
example,
right
now.
If
they
are
configured
for
transforming
one
and
then
a
packet
from
trust
domain
tool,
then
they
are
not
at
being
able
to
validate
it
right
or.
C
Okay
I
say
so:
basically,
you
are
saying
your
way
of
info
CA
is
you
have
multiple
listeners
and
this
mod
condition
are
each
convicted
for
different
transcon
mains?
Okay,
this.
B
C
B
C
B
D
C
So
so,
basically,
right
now
the
annual
SDS
API
has
a
validation
contest
and,
as
a
validation
context,
has
an
array
of
four
CA
certificates
to
validate
as
incoming
connections.
So,
but
with
the
species
introduce
this
scoping
concept,
basically
for
us
for
trust
domain,
one
you
can
use
a
certain,
you
know
say:
certificates
for
transforming
to
you
can
use
another
set
up
for
certificates.
C
Basically,
this
say
a
certificates
are
now
to
treat
it
blindly
as
without
no
scope
as
the
author
scope
is
infinite,
so
this
is
smoking
right
now,
if
I
understand
correctly,
is
not
directly
supported
by
sts-80
I.
So
what
we
are
proposing
is
whether
the
SGS
API
can
be
extended
to
support
as
a
scoping
for
the
validation
for
the
transforming.
Basically,
those
assay
certificates
has
a
trust
domain
associate
here.
Is
it.
C
D
A
B
A
A
A
Good,
besides
that,
we
there
Easter
team,
we
have
talked
about
internally
discussed
about
their
Federation's,
so
this
is
beefy
trust,
domain
and
bundle.
Federation
is
one
we
basically
four
to
identity,
to
PGI's,
to
stretch
route
and
then
mutually
authenticate,
there's
another
way
to
feather
it,
which
is
sharing
the
route
right.
A
B
B
This
is
a
supported
configuration
under
spiffy
and
it
is
supported
just
by
vanilla,
trust,
a
man
and
a
7i
nested.
In
that
scenario,
you
almost
certainly
want
to
have
be
having
main
constraint,
and
this
is
obviously
x.509
specific,
and
the
thing
about
name
constraints
is
that
it
has
this
idea
of
subdomains
if
he
does
not
have
idea
of
subdomains,
but
you
know
you
would
certainly
be
having
you
certainly
be
introducing
subdomain
concept
and
stuff
apology
having.
A
A
B
Think
so
I
think
so.
I
got
to
think
through
that
you
can
further
the
JWT
case.
I
know,
I,
don't
know,
I
think
you
guys
are
not
using
Jamie
Beach
yesterday
to
be
T
case,
for
instance,
if
a
subdomain
one
was
a
trusted
name.
Some
domain
wand
on
example,
not
work
was
a
trusted
main
an
example
that
work
would
example.
That
would
be
a
different
trust
of
aim,
yep
yeah
and
then
for
the
Trinity
case.
B
Subdomain
one
example
of
work
would
have
its
own
jet
ability
signing
keys,
because
Jamie
T
does
not
have
any
concept
of
chaining
like
behind
us
Gemma
and
then
the
bundle
the
bundle
for
the
the
the
bundle,
for
example,
Trevor,
subdomain
wand
on
example.
No
more
would
be
I
guess
the
root
of
it
would
be
the
same
bundle,
as
example
not
work.
B
Cassandra
yeah,
so
we
lived
on
this
path
on
spire
under
immediately
ran
into
problems
because
the
default
the
default
configuration
for
OpenSSL
will
not
validate,
will
not
validate
a
chain
that
terminates
of
an
intermediate
that
is
not
self
signed.
In
order
to
do
this,
you
have
this
special
option
called
partial
chain,
I
snap
and
by
default
envoy
does
not
do
this
and
others
do
not
do
this
and
okay
yeah
we.
This
is
something
that
I
thought
would
be
the
nice
thing
to
do,
but
because
of
that
problem,
there's
other
there's
other
problems
too.
B
Some
of
the
folks
on
Google
Chrome
team
have
published
a
nice
paper
on
TLS
validation
errors
in
the
wild
and
talked
about
all
these
different
TLS
client
implementations
that
are
out
there.
One
of
the
surprising
things
that
we
found
was
that
many
TLS
clients
of
Lamentations
will
cache
intermediates
if
they
find
when
talking
to
other
peers
and
if
they
run
into
a
chain
which
they
DeMuth
and
complete
them.
B
B
So
this
we
we
worked
on
BTS
vs,
expect
for
I,
don't
know,
probably
four
months
or
so,
and
the
way
that
we
wanted
to
do
it
originally
was
exactly,
as
you
described,
with
x.509
embedded
J
to
be
T
and
J
to
be
T
sine
PI
X
5
at
night.
We
are
not
doing
that
because
the
validation
methodology
was
not
widely
implemented
and
JW
t
client,
libraries,
and
also
because
if
it
was
a
difficult
thing
to
implement,
there
was
the
way
that
you
would
do.
B
The
validation
meant
that
if
there
was
an
implementation
error,
it
would
fail
at
them
and
this
particular
property.
We
were
worried
about
because
we
have
seen
lots
of
people
implement
Jaina,
BT
validation
incorrectly
and
having
that
having
that
failure
mode,
B
fail
of
an
assay
at
UWT,
isvalid
Runa
does
not
was
the
one
that
we
weren't
very
comfortable
with
I.
B
Think
that
in
the
long
run,
we
would
like
to
have
the
either
rev
the
current
J
WTS
the
document
or
introduce
a
new
one
that
allows
for
these
training
properties
and
some
of
the
other
distributed
signing
of
some
of
the
nicer
properties
that
we
would
prefer
to
have.
But
the
main
goal
of
the
j2
BTS
suspect
that
we
have
now
as
be
compatible
with
existing
software
and
having
the
chain
validation,
x.509,
chain,
validation
and
JWT.
Even
though
the
RFC
supports
this
was
not
a
common
commonly
implemented
or
supported
thing
that
we
were
able
to
find.
D
B
Okay,
so
this
is
the
last
piece
of
the
document
here,
which
is
basically
just
just
kind
of
addressing
the
problem
of
how
do
you
authenticate
this
bundle
point
we
say
that
you
use
TLS
and
HTTP,
but
how
exactly
do
you
know
that
the
TLS
artist,
Aled
and
so
on
and
so
forth?
How
do
you
go
about
bootstrapping?
That
first
connection,
so
the
specification
does
not
actually
say
you
must
do
it
this
way
or
you
must
use
this
protocol
or
you
must
do
it
that
way.
B
Rather,
we
give
some
guidelines
and
we
say:
here's
two
recommended
authentication
strategies
that
we
recommend
you
support.
The
first
is
just
using
web
PKI
to
protect
the
TLS
endpoint,
so
you
would
give
the
endpoint
address
in
terms
of
like
DNS
name
and
on
the
trust
domain,
which
represents
it,
which
it
represents
and
you'll
do
web
PKI,
your
name,
validation.
This
way,
okay,.
B
So
it
is,
it
is,
for
all
intents
and
purposes,
the
mechanics
here
are
identical
to
JW
KS
URI
semantics
for
ABC,
where
you
just
publish
a
very
basic
gunpoint.
That
is
that.
Has
this
publishing
this
jwk
that's
document
and
when
you
want
to
federated,
you
were
configured
with
the
endpoint
address
and
some
authentication
information,
and
you
just
you
pull
it.
I
see.
B
So
what
are
the
action
items
that
came
out
of
the
last
six
that
call
we
had
was
exactly
this.
This
question
the
current
oh
I,
DC
Oh,
a
DC,
does
not
have
a
lot
to
say,
but
in
practice
the
way
people
are
doing
it
is
by
setting
cache
control
headers
on
the
HTTP
response.
This
document
does
not
mandate
the
use
of
HTTP
for
transmission,
although
we
recommend
it,
but
because
people
might
have
custom
distribution
mechanisms,
and
things
like
this.
B
There
is
a
pending
action
item
to
amend
this
document
with
a
new
field
and
JW
KS
document
that
will
be
called
the
spiffy
refresh
hit
and
the
publisher
of
the
bundle
will
be
able
to
stay
and
stuck
in
seconds.
You
should
probably
check
back
on
this
frequency,
okay
you-you-you're,
if
you're
using
HTTP-
and
why
do
you
see
stuff
like
that?
You
are
free
to
use
cache
control
header
also
and
as
spiffing
refresh
heads
will
not
be
required
but
recommended
okay.
B
So
what
PKI
is
one
of
recommended
authentication
methods
for
authenticating
bundle,
endpoint
second
recommended
authentication
method
is-
is
just
to
use.
Spiffy
authentication,
of
course,
when
you're
being
introduced
to
entrust
I
mean
that
you
don't
know
anything
about.
It
is
necessary
to
bootstrap
that,
if
you're
not
using
web
PKI,
so
it's
bethey
authentication
when
you
configure
the
trust
domain
and
the
endpoint
tuple
additionally
requires
that
the
operator
provide
an
initial
bundle
and
anon
initial
bundle
is
what
is
used
to
authenticate
the
endpoints
from
then
on.
B
The
bond
or
rotation
can
have
an
invent,
but
in
order
to
bootstrap
this
first
connection,
additional
configuration
is
required.
So,
like
I
mentioned,
we
don't.
We
do
not
mandate
that
you
do
any
of
these.
These
are
just
kind
of
like
the
recommendation.
I
have
already
spoken
to
some
folks
who's
who
are
building
internal
distribution
mechanisms
for
this
bundle,
that
is
on
them,
but
I
think
that
supporting
web
PKI
are
spiffy
off
with
HTTP,
GET
and
TLS
is
strongly
recommended
to
be
supported
as
kind
of
the
de
facto
exchange
method.
B
So
that
is
the
last
part
of
this
document
that
we
have
now
the
only
pending
things.
I
have
to
make
this
update
for
spiffy
refreshment,
and
we
will
write
in
the
security
considerations
as
well
below
this
document.
We
have
a
number
of
amendments,
so
we
will
amend
x.509
as
the
document
and
we
will
also
amend
the
JWT
aspen
documents.
B
The
way
that
this
is
structured
is
that
I
mentioned
that
within
this
jwk
s,
we
have
keys
and
represent
multiple
ESPA
types
that
are
that
are
authorities
from
Israeli
issuing
multiple
ESPA
types,
so
the
semantics
of
each
one
of
those
types
of
is
defined
actually
in
the
esvet
specification,
so,
for
example,
the
s
x.509.
As
for
this
details,
exactly
how
X
on
my
certificate
is
represented
as
an
agenda
bouquet
tree.
B
So
this
is
to
say
that
the
youth,
their
youth
parameter,
must
be
set
to
X
by
the
9s
hood
and
the
x5c
parameter
is
used
to
store.
That's
not
a
nicer
to
be
good,
there's
a
similar
text
on
brown
JWT.
So
the
idea
here
is
that,
as
we
introduced
new
Vespa
types
in
in
the
estimate
specification,
we
can
define
directly
how
the
keys
for
this
aspect
are
represented
in
the
bundle
and
we
do
not
have
to
continually
update
the
trust
domain
and
but
no
specification
to
support
them.
A
A
You
guys
are
having
any
questions,
I
think
for
our
sides,
the
ìiî
of
this
mom.
The
eyes
of
this
meeting
is
to
converse
beefy
and
you
steal
teams
to
cooperate,
to
propose
a
design
talk
and
why
SDS,
how
to
to
support
the
workload.
Trust
bundle
right,
yeah,
okay,
well,
you
guys
start
a
dog
and
add
us
to
it
or
yes,
we
can
do
that.
All
right!
A
Thank
you
and
on
our
side,
we
will
think
about
how
to
propose
the
solutions
for
customers
to
federate
different
trust
omens
to
the
Federation's,
maybe
across
trust,
omens
or
or
across
multiple
clusters.
If
they
want
to
use
a
single
custom-
and
maybe
they
can
share,
can
use,
they
can
use
the
single
root
of
trust,
even
though
it's
not
very
interesting
to
spiffy.
We
want
to
keep
the
optional
pee
yeah.
B
A
A
B
A
A
B
We
have
changes
that
have
been
published
in
spire
that
will
allow
multiple
intermediates
and
the
chain
to
be
formed,
but
currently
this
is
limited
to
a
single
trust
domain.
So
even
for
spire
project
will
be
interesting
to
understand
the
implications
of
having
supporting
multiple
trust
remains
within
the
same
PKI
hierarchy.
Right.