►
From YouTube: Digital Identity WG (September 16, 2020)
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
A
All
right,
everyone
we
are
now
recording
and
for
anybody
that
doesn't
know,
I
upload
these
to
youtube
to
the
channel
somewhere
in
one
of
the
repos
link
to
that
channel.
So
you
can
find
it
later.
B
A
All
right,
so
the
recording
has
started.
Do
you
want
to
jump
in
santiago,
we're
going
to
start
the
presentation
on
in
toto
and
tough.
C
Okay,
just
a
second,
I
added
my
name.
Yes,
so
here's
where
I
awkwardly
try
to
present
my
star
screen
and
we
find
out
whether
it
works.
I.
C
Hey
okay,
so.
A
C
Okay,
great
so
today
I
wanted
to
talk
mostly
about
in
toto
and
some
of
the
driving
principles
behind
teletub,
and
I
also
wanted
to
cover
some
of
the
future
work
of
in
total
somehow
and
how
it
can
fit
the
broader
goals
of
the
open
ssf
to
be
a
little
bit
more
explicit.
C
C
So
to
do
that,
I
want
to
show
connection
between
software
supply
chains
and
developer
identities
and
how
solving
one
is
only
one
equation,
but
solving
both
is
what
I
think
is
the
future
of
secure
software
and
development
pipelines.
And
to
do
this,
I
am
going
to
propose
a
call
way
forward
again.
This
is
only
two
spark
conversation.
D
C
I
am
really
hoping
to
show
ideas
that
are
new
that
are
somehow
interesting
and
that
can
probably
set
some
ground
for
the
future.
Where
we're
going
to
do
here
at
the
open
ssf.
C
I
also
want
to
show-
and
I
think
this
is
something
that
I've
been
running
into
when
I
talk
to
a
lot
of
the
communities
out
there-
some
of
the
guiding
principles.
This
is
a
little
bit
on
the
academic
side
of
things,
but
why
toto
is
like
it
is,
and
to
do
that,
I'm
going
to
talk
about
artifact
flow
integrity,
artifact,
authentication
and
supply
chain
layout
integrity.
C
Then
I'm
going
to
show
how
this
come
to
life
and
in
total,
as
a
framework
that
you
can
use
today.
But
then,
what
I
think
is
the
most
interesting
part
of
this
is
what
I
want
to
mention
beyond
the
chain,
how
you
can
use
in
toto
to,
for
example,
authenticate
actors
in
the
chain
and
how
you
can
use
intoto
to
ensure
best
practices,
something
similar
to
what
the
cii
batching
process
works
today,
so
without
yeah,
without
losing
any
more
time.
C
I
just
and
I
apologize
if
for
the
people
here
that
have
been
to
like
kubecon
or
cdcon
or
or
any
of
those
like
linux
foundation,
sponsored
events,
because
probably
this
will
be
repetitive
for
you,
but
I
really
want
to
cover
exactly
what's
the
problem
of
space
that
in
total
said
to
set
off
to
answer
and
how
we
eventually
came
to
what
we,
where
we
are
right
now.
C
C
C
Now
in
total,
is
trying
to
answer
the
question
of
security.
So
you
wouldn't
be
surprised
if
I
told
you
that
hackers
can
actually
break
into
all
of
the
steps
and
the
supply
chain
that
I
spoke
about,
and
this
is
actually
not
an
academic
problem.
We
have
seen
cases
such
as
the
free
software
foundation,
software
poster
being
had.
C
We
have
seen
cases
of
multiple
different
source
code,
reposters
hacked
to
try
to
introduce
backdoors
or
to,
for
example,
in
the
case
of
the
juniper
firewalls,
to
introduce
a
small
change
in
the
pseudo-random
number
generator
in
such
a
way
that
anybody
who
knew
this
change
existed.
They
were
able
to
decrypt
every
single
conversation
that
was
being
used
by
the
juniper
firewall
vpn
screen
os
operating
system.
C
There's
all
the
cases
like
what
I
brought
linux
kernel
compromise
pro
ftpd,
and
this
is
just
for
the
version
control
system,
there's
cases
of
compiler
backdoors,
there's
of
course,
the
cam
thompson
hack,
which
pretty
much
sparked
the
whole
conversation
around
compiler
backdoors,
but
a
more
realistic
one
is
the
ios
xcode
ghost
attack
for
those
of
you
that
are
not
familiar
with
this.
C
It
was
a
hacker
that
started
publishing
a
version
of
xcode
ghost
that
introduced
the
backdoor
into
all
the
compiled
ios
apps
that
worked
on
with
this
with
this
tool
chain
and,
interestingly
enough,
very
popular
applications
actually
ended
up
having
this
backdoor.
One
of
them
that
I
can
remember
from
the
top
of
my
head
was
angry
birds,
which
I
assume
that
many
people
here
at
least
heard
of
or
know
somebody
that's
using
angry
birds.
C
So
this
is
the
this
is
the
the
in
the
last
radius
of
the
compromise
somebody
putting
a
small
change
somewhere
in
the
pipeline
brings
down
the
whole
system
and,
of
course
this
is
not
pointing
fingers.
There's
been
many
different
instances
on
different
parts
of
the
chain
and
plugging
the
build.
You
can
have
a
compromise
in
the
packaging
infrastructure.
C
There's
one
that
I
like
a
lot,
how
somebody
built
about
net
of
800
or
so
hosts
in
less
than
20
hours,
just
because
they
published
a
compromise
version
of
linux
mint
in
the
linux
mint
website.
There's
other
cases
like
kingslayer
there's
the
phpmyadmin
corrupted
copy
on
a
korean
mirror
server.
I
like
this
example,
for
example,
because
it
allows
us
to
see
how
a
clever
attacker
can
target
a
particular
population.
C
In
this
case
it
was
a
south
korean
mirror,
which
in
turn
means
that
maybe
a
political
situation
was
going
on
there.
Maybe
this
particular
population
was
of
interest
to
the
attacker
people
point
out.
Maybe
north
korea
did
it.
We
don't
know,
but
it's
it's
cases
like
this.
There's
there's
even
cases
of
compliance.
One
of
them
is
linux,
kernel
being
published
without
being
tested.
It's
it
can
happen
to
anybody
another
more
interesting
case.
Is
the
windows
published
an
update
that
essentially
breaks
your
machine,
and
originally
everybody
thought
like?
C
Oh
windows
got
hacked
and
the
hacker
just
like
created
havoc
in
the
whole
windows
ecosystem,
then
windows
very
diligently
went
and
did
an
internal
audit
and
they
found
out
that
the
person
was
that
was
supposed
to
check
that
the
test,
the
update,
wasn't
breaking
the
machines
just
had
a
slip
and-
and
that's
the
question
of
compliance,
how
a
small
human
error,
small
deviation
from
the
process
can
result
again
in
uncountable
damage
to
the
users.
C
So
here's
what
where
I
want
to
stop,
I
use
this
slide
generally
to
showcase
how
something
that
looks
very
simple,
something
that
one
would
expect
that
many
other
people
here
would
say.
Well,
I
can
set
this
up
in
a
couple
of
days,
but
real
software
in
the
industry
is
actually
way
easier
way,
more
convoluted
and
way
easier
to
protect.
But
here
we
have
a
supply
chain
that
that
is
just
essentially
four
steps
of
three
that
if
they
get
compromised,
we
have
a
complete
subversion
of
the
whole
system.
C
So
how
can
we
fix
this?
Well,
there's
many
good
point
solutions.
There's
things
such
as
kit
signing,
there's
push
certificates,
there's
dpms
and
hsns
for
builds,
there's
very
viable
compilers,
there's,
reproducible
bills
in
place,
there's
things
such
as
dls
gpg
and
tough
to
sign
your
releases.
You
can
add
their
notary
and
many
like
last
mile
solutions
to
protect
your
infrastructure.
But
the
question
is
how
we
fix
this
just
by
putting
all
of
these
little
elements
in
place,
and
I
think
the
answer
is
well.
C
How
do
we
know
these
things
are
in
place?
How
do
we
know
that,
if
even
if
commit
signing
was
in
place,
it
was
actually
followed
the
way
that
it
should
and
that
the
person
that's
supposed
to
build
out
of
the
latest
tag
actually
checked
that
the
git
commits
were
signed
and
they
were
signed
by
the
right
people
and
the
same
goes
for
the
testing
infrastructure
and
the
same
goes
for
the
packaging
infrastructure.
C
So
here's
where
essentially
as
academics
with
stupas
step
out
and
we
try
to
understand
what
what
are
the
principles,
the
security
principles
that
are
missing-
and
this
is
what
drove
in
total-
and
this
is
what
I
wanted
to
underline
here-
to
have
a
conversation
about
how
this
could
apply
to
new
challenges
that
we're
facing,
and
these
principles
are
three.
The
first
one
is
called
supply
chain.
C
Integrity,
which
is,
is
the
supply
chain
structure,
a
split
chain
graph,
not
modified
by
adding
elements
or
not
I'm
going
to
talk
a
little
bit
more
about
it
later.
The
other
was
the
other.
One
is
artifact
flow
integrity,
which
means
have
the
artifacts
as
they
were
passed
through
the
chain
not
modified
in
the
transition
and
finally,
step
authentication,
which
is,
is
the
person
that's
supposed
to
perform
a
step
to
the
right
person
to
perform
that
step?
C
So,
to
put
it
a
little
bit
more
clearly
supply
chain
integrity
means.
We
know
that
there's
a
version,
control
system,
there's
a
built
server
and
there's
travis
ci
running
on
this,
and
we
have
a
packaging
step.
That's
supposed
to
produce
a
debian
package.
C
Now
this
means
that
we
should
be
able
to
tell
if
steps
were
flipped
around
if
somehow
packaging
of
the
sources
was
done
before,
building
which
I
know
it's
a
little
bit
weird,
but
but
it
is
wrong.
C
Another
thing
is
well
what,
if
somebody
just
disabled
tests,
we
want
to
be
able
to
say
well,
that's
also
wrong.
We
shouldn't
trust
the
package.
This
is
exactly
the
type
of
things
that
that
caused
the
the
windows,
not
malicious,
but
a
faulty
update.
C
C
We
want
to
know
that
there's
nothing
else
added
in
this
case,
if
somebody
added
some
sort
of
special
tool
to
make
the
tests
pass,
we
want
to
say
well,
we
don't
trust
that
either
because
it's
doing
something
that
we
don't
know
if
it
will
have
an
effect
in
the
chain.
C
So
that
is
when
what
we
mean
when
we
say
software
supply
chain
integrity.
It
means
that
the
chain
it
is
integral
it
hasn't
been
modified.
The
second
principle
is
artifact
flow
integrity,
which
means
well.
We
know
that
the
version
control
system
will
produce
sources.
We
know
that
the
build
system
will
take
sources
and
produce
a
probably
a
binary
or
or
some
sort
of
like
intermediate
representation
of
pipe
code,
and-
and
we
know
that
the
packaging
will
take
in
the
result
of
the
build
and
we'll
put
it
on
the
ending
package.
C
So
we
want
to
make
sure
that
there's
no
tampering
as
the
sources
go
into
the
build
and
as
the
products
of
the
build
make
it
into
the
package.
That
is
what
we
call
artifact
flow
integrity
so
that
somebody
broke
into
to
our
version
control
system
and
modify
the
tag.
We
want
to
be
able
to
say
hey,
I
don't
trust
the
result
of
this
build
because
it
didn't
take
the
right
sources,
there's
a
disagreement
as
things
made
it
through
the
chain
of
custody,
somehow
that
is
artifact
flow
integrity
and
finally
step
authentication.
C
Many
of
you
may
have
guessed
it's
like.
Well.
All
of
this
was
done.
The
flow
was
proper,
but
was
it
done
by
the
right
person
was
both
the
not
builder
but
version
control
systems,
person
producing
the
right
sources
or
tags
and
is
carl,
the
builder
taking
in
the
right
source
system?
Is
she
the
one
that's
doing
the
builds
and
finally
is
airing
the
one?
C
That's
packaging
or
is
it
somebody
else
that
we
don't
trust,
and
we
want
to
make
sure
that
this
is
the
case,
because
we
want
to
make
sure
that
the
person
who's
performing
each
transformation
in
the
chain
is
trusted.
C
So,
with
this
three
principles,
we
can
build
something
like
in
toto
again.
Software
supply
chain,
integrity,
artifact
flow
integrity
and
step
authentication,
and
we
want
to
build
a
system
that
using
these
three
principles
can
answer
the
following
questions.
One
of
them
is:
are
the
steps
in
the
software
supply
chain
verifiably
defined?
C
C
So
how
do
we
do
this?
In
the
total
world
and
in
total
we
have
basically
a
file
called
a
layout
that
describes
essentially
the
steps
that
need
to
happen
supply
chain
integrity.
It
also
assigns
functionaries,
as
we
call
them,
which
are
the
individuals
or
machines
that
are
supposed
to
take
care
of
each
individual
step.
C
It
also
lets
them
register
materials
and
products,
which
is
what
are
they
supposed
to
consume
and
produce,
and
it
lets
you
using
a
small
domain.
Specific
language
say
what
is
supposed
to.
C
How
is
it
supposed
to
flow
to
answer
the
architect
flow
integrity,
question
which
is
again,
we
want
to
make
sure
that
the
sources
of
a
tag
were
the
ones
that
carl
and
dave
use
to
run
the
test
and
to
build
the
binary,
and
we
also
want
to
make
sure
that
the
binary
that
carl
produces
is
the
one
that
aaron
is
actually
putting
into
the
debian
package.
C
Now
this
describes
what
is
the
expected
result
of
the
supply
chain,
but
there
is
a
question
of.
Is
this?
What
actually
happened?
Oh
sorry,
I
forgot.
You
also
need
to
have
a
signature
over
there,
so
you
know
that
this
comes
from
the
right
person,
but
to
answer
the
question
of
is
what
happened,
the
thing
that
is
supposed
to
happen?
We
will
have
a
another
piece
of
information
called
in
total
links
which
are
basically
rubber
stamps
over
the
over
the
operations
that
were
done,
that
they
will
register.
C
Who
did
it?
How
did
they
do
it?
What
did
they
take
as
materials
and
what
did
they
produce
as
products?
All
of
this
rubber
stamped
information
can
then
be
shipped
as
a
final
product,
along
with
a
policy
for
the
end
user
to
verify
the
end
user
can
basically
go
back
and
say
well,
I
know
that
there
needs
to
be
these
four
steps.
C
Is
there
enough
evidence
that
these
four
steps
took
place,
and
can
I
actually
follow
the
the
cryptographic
paper
trail
from
my
package,
all
the
way
into
the
version,
control
system
and
there's
no
disagreement
between
all
of
the
members
in
this
chain
of
custody?
C
Intel
basically,
does
it
in
in
a
way
that
you
provide
layout
and
a
public
key,
and
it
takes
it
from
there
now.
What
I
find
more
interesting
in
torah's
done
today
is
that
these
principles
can
actually
apply
to
answer,
questions
that
are
beyond
supply,
chain
security,
but
but
essentially
automating
processes
and
describing
trust
relationships
between
different
parties
in
an
ecosystem.
C
So
two
examples
that
I
want
to
bring
forward
was:
one
of
them
is
automatically
boarding,
trust
in
an
ecosystem,
and
the
second
one
is
verifiably
checking
the
best
practices
so
the
first
one.
To
give
an
example,
I
have
recently
moved
to
the
midwest,
so
I
I
found
out
that
I.
C
Especially
if
I
want
to
buy
guitar
amplifier,
I
need
to
drive
far
from
home,
so
I
went
to
the
dmv
website
and
I
tried
to
figure
out
how
how
do
I
exactly
get
a
driver's
license,
my
identification
that
I
am
allowed
to
use
the
infrastructure.
That's
called
the
road,
and
actually
I
found
that
it
was
very
complicated.
So
I
I
moved
to
an
example:
that's
a
little
simpler
how
to
get
a
parking
permit
in
london,
so
this
process
is
very
similar
to
the
supply
chain.
I
need
to
go
perform
an
operation.
C
I
need
to
prove
that
it's
me
I
go
to
ringgo
and
register
for
a
permit.
Then
I
need
to
go
and
complete
an
application
form
somewhere
else
and
finally,
I
can
go
to
purchase
my
permit
somewhere
else.
C
All
of
all
of
these
three
things
need
to
be
done
with
different
custodians
and
they
gave
me
essentially
what's
an
artifact,
it's
a
it's,
a
proof
that
I
can
use
in
the
next
step
to
perform
the
next
operation
so
to
bring
this
example
a
little
back
down
to
to
the
software
supply
chain
security
world
and
the
the
total
speak.
Well,
we
have
the
supply
chain
in
which
we
basically
have
bob
produce
some
elements
that
were
needed
by
carol
to
perform
her
operation
and
carol
produce
something
that
aaron
needs.
C
So
imagine
that
we
can
do
something
like
this
to
automatically
on
board,
say
maya
into
the
colonel.org
ecosystem
by
making
sure
that
maya
is
doing
two
things.
One
of
them
is
she's
acknowledged
by
linus
and
greg
and
junior,
so
they
signed
her
key
saying.
Well,
I
saw
her
passport.
I
know
that
two
weeks
ago
we
heard
that
that
was
somewhere
somewhat
hard
to
do,
but
imagine
that
it
happens.
Imagine
that
we
can
do
this.
C
These
three
people
will
sign
her
key
and
say
well,
I
recognize
her
as
a
physical
energy,
but
also
we
can
do
other
interesting
operations
such
as
well.
Maya
can
take
the
code
of
conduct
and
read
it
and
create
a
manifestation
that
say:
aye
malia
hereby
declare
to
follow
the
code
of
conduct
of
kernel.org
and
finally,
we
could
have
an
operator
saying
well
now
that
I
have
these
two
pieces.
C
So,
in
a
sense
the
what
I
want.
What
I'm
bringing
forward
is,
how
can
you
actually
use
software
supply
chain
principles,
artifact
integrity,
step,
authentication
and
and
supply
chain
integrity
to
make
sure
that
somebody
is
following
all
of
the
required
steps
to
be
trusted
to
be
a
trusted
member
of
certain
communities,
and
we
can
use
this
to
perform
very
powerful
operations
such
as
cross
organizational
trust
such
as
checking
that
somebody's
auditably,
creating
attestations
of,
for
example,
dco
or
well,
you
name
it.
C
Now
the
other
example
that
I
wanted
to
bring
forward
is:
how
can
we
verify
verifiably
check
best
practices?
Many
of
you
may
be
familiar
here
about
the
cii
badging
program,
which
is
it's
something
that
I
actually
love
in
total
is
on
its
way
to
get
to
gold,
which
is
I,
as
somebody
who's
producing
open
source.
C
I
want
to
check
what
are
the
best
practices
for
for
the
development
of
my
application,
and
I
want
to
ensure
that
I'm
following
them,
so
my
application
is
more
secure
and
thus
users
can
trust
and
trust
them
when
they're
making
decisions
on
what
types
of
things
they're
using
so
cii
may
tell
you
things
such
as
oh
well,
you
need
to
have
a
ssl
distribution
of
your
sources,
so
so
it's
not
easy
to
man
in
the
middle,
the
connection
when
somebody's
downloading
their
product,
they
may
also
tell
you
well,
you
need
to
also
statically
analyze
your
application,
to
make
sure
that
the
way
that
you're
writing
code
is
not
obviously
vulnerable.
C
So
you
can
use
an
application
like
cubesec
to
analyze
some
of
your
kubernetes
deployment
yamls,
and
they
may
also
tell
you
hey.
You
need
to
run
continuous
test
testing
in
your
sources
to
make
sure
that
every
single
change
that
you're
making
follows
follow
the
code
quality
that
you
expect
so
say
that
maya
is
actually
writing
a
new
deviant
package
and
she
wants
to
show
that
the
best
practices
are
being
followed.
The
way
it
works
today
she
says
I
did
it.
C
I
swear
and
in
the
best
of
cases
the
best
practices
infrastructure
will
run
an
automatic
check
and
hopefully
constantly
will
do
it,
but
it
has
no
notion
of
where
has
this
actually
been
followed
in
the
latest
artifact,
or
has
this
actually
been
followed
on
the
on
the
artifact
that's
intended,
so
we
can
use
the
same
supply
chain
security
principles
to
build
something
that
can
allow
us
to
create
the
next
generation
best
practices
effort
so
that
we,
for
example,
have
the
cai
created
a
cai
vetted
layout.
C
That
says:
well,
we
actually
expected
to
do
all
of
these
things
and
then
maya
can
go
and
say
like
well,
I'm
going
to
do
all
of
these
things.
I'm
going
to
make
sure
that
this
is
there
I'm
going
to
talk
to
let's
encrypt
and
get
a
certificate,
I'm
going
to
run
a
cubesat.io
on
my
application
to
get
the
to
make
sure
that
things
are
right
and
I'm
going
to
constantly
run
privacy
ci
over
them.
C
If
we
do
this
this
way,
we
can
have
some
providers
creating
links.
That
basically
said:
oh
well,
I'm
let's
encrypt,
and
I
know
that
maya
requested
a
certificate
for
her
application
and
I
am
cubesake-
and
I
know
that
maya
run
a
static
analyzer
on
her
code
and
I
am
travis
and
here's
the
latest
adaptation
of
the
result
of
the
run
so
dealing
back.
C
We
can
use
the
same
benefits
on
the
cii
system.
The
software
supply
chain
security
community,
I
would
say,
are
trying
to
to
get
which
are
supply
chain
integrity,
ensure
that
everything
was
done.
Artifact
flow
integrity
ensure
that
they
were
done
on
the
right
artifact
and
the
step
authentication
that
these
checks
were
actually
done
by
the
right
people
so
supply
chain
integrity.
We
have
a
ci
vetted
layout.
That
tells
you
exactly
what
needs
to
happen.
Artifact
flow
integrity.
We
know
that
the
artifact
being
analyzed
and
being
checked
by
this
individual
efforts
were.
D
C
The
right
on
the
right,
artifact
and
finally
step
authentication.
We
know
that,
let's
encrypt
is
the
one
that's
giving
you
the
attestation,
not
some
random
colluding
party.
That's
pretending
to
do
the
thing,
but
not
redoing
it,
and
to
wrap
up.
C
Inktober
is
used
today
to
ensure
software
supply
chain
security.
Its
driving
principles
can
help
understand,
supply,
chain
security
threats
and
it's
all
about
process,
so
you
can
use
it
in
many.
C
That
that
may
be
in
need
to
answer
questions
such
as
was
the
thing
everything
done.
Was
it
done
by
the
right
people
and
is
there
a
flow
of
information,
that's
integral,
and
with
that
I
think
I
want
to
open
the.
D
A
Thank
you
that
answers
a
bunch
of
the
questions
and
vague
areas.
I've
had
in
my
head
around
the
different
types
of
attestations
and
how
they
can
flow
through.
I
have
one
kind
of
question
this
all
kind
of
seems
to
hinge
on.
You
know
a
pki
still,
and
I
know
in
total
supports
pgp
and
a
bunch
of
other
types
of
signatures.
A
C
Yeah,
that's
a
great
question,
an
issue,
so
what
we
wanted
to
do
with
intel
was
something
that
is
not
a
prescriptive
in
the
way
that
people
follow
practices.
C
So,
for
example,
we
knew
that
it
was
a
very
bad
idea
to
come
over
to
the
deviant
community
and
say
like
hey
by
the
way,
throw
away
gpg
and
you
need
to
use
openssl.
C
But
in
contrast,
you
cannot
do
the
same
to
say,
microsoft
that
they're
probably
very
invested
in
code
signing
they
have
a
big
infrastructure
to
do
this,
the
right
way
they
have
their
own
processes
to
ensure
that
everything's
done
to
the
letter
in
that.
In
that
sense,
so
we
wanted
to
be
a
little
bit
agnostic
on
those
particularities
and
we're
providing
tooling
to
basically
interface
with
those
with
those
pki
solutions
to
call
it
and
like
to
call
that
group
in
a
way
in
total
does
allow
you
to
say
well.
C
This
gpg
key
can
be
used
for
git
commit
signing,
but
this
other
pkcs
v8
pam
can
be
used
for
signing
a
build
and
in
a
way
it's
it's
relatively
agnostic
and
that's
by
the
sign,
because
we
want
to
be
able
to
cover
as
much
of
the
supply
chain
as
possible.
I
I
don't
think
we'll
see
a
trend.
I
bring
this
up
a
lot,
but
the
xkcd
nine
to
seven.
I
don't
like.
We
know
the
name,
the
number
by
my
memory.
C
It's
unfortunate
that
in
this
industry
we'll
see
that
a
lot
people
will
just
say,
come
and
say
like
actually
we're
open,
psd
or
or
for
dsd,
and
we're
going
to
use
signify,
and
it's
like
well.
Okay,
then
that's
another
thing
that
we
need
to
handle,
but
the
trust
assumptions
are
are
basically
the
same.
It's
a
it's
a
cryptographic,
primitive
that
is
telling
you
that
this
thing
comes
from
the
right
person.
A
Yeah,
it
seems
like
that's
yeah.
I
think
you
answered
it
by
clarifying
that
that
is
still
an
area
to
figure
out.
I
think
supply
chain
is
extra
tough,
because
these
are
things
that
cross
organizational
and
community
boundaries
and
everything
and
each
one
of
these
organizations
and
communities
comes
up
with
their
own
pki
system.
Like
you
outlined.
E
A
And
so
kind
of
bootstrapping
that
layout
file
with
the
correct
keys
is
remains
a
challenge.
C
Right
and
I
think
in
that
sense
I
hope
that
in
the
future
some
conversations
around
this
will
start
to
crystallize
towards
some
more
universal
standards.
But
again
it's
it
really
does
sound
like
a
kcd-97.
F
I
have
a
question
for
you:
how
do
you
add
test,
so
this
provides
a
storage
for
a
testing
like
who
can
make
certain
changes
to
the
repository
or
the
parts
of
the
infrastructure
right.
So
you
already
need
to
know
the
person
before
you
can
trust
them
right.
So
isn't
there
like
a
catch
22
here
so
that
you
know
and
an
external
developer
coming
in.
F
C
Yes,
and
no
the
way,
I
phrase
it
and
I
think
it's
a
it's
a
running
joke,
it's
insecure
turtles,
all
the
way
down.
C
Yes,
you
need
to
have
a
mechanism
to
bootstrap
trust
but,
for
example,
an
example
that
I
was
bringing
up
with
a
maya's
key
is
you
could
use
the
same
driving
principles
to
say
well,
somebody
who
wants
to
submit
a
full
request
and
they
want
to
be
authenticated
in
some
way
they
can
go
through
this
process
and
again
it
probably
doesn't
need
to
be
like
greg
and
linus
signing
your
key,
but
it
could
be
something
like
well
register
your
key
under
this
directory
and
make
sure
that
you
present
some
evidence
that
you
commit
to
the
best
practices
of
the
of
the
code
or
something
like
this,
which
eventually
should
float
into
into
the
infrastructure,
to
mark
somebody
as
enrolled
in
the
system
and
allow
to
to
create
that
submitted
applications
and
code
say.
F
Yeah
so
kind
of
like
we
talked
about
the
key
server
like
if
I
have
like
a
hagrid
key
server
that
specifically
exists
for
this
purpose.
You
know
if
you
want
to
submit
something.
Please
submit
your
public
key
to
this
key
server,
which
does
the
email
back
and
forth
as
a
sort
of
a
way
of
verifying
that
you
own
it.
C
Right
and-
and
it
could
be
other
like
interesting
things
such
as
I
mean
you
can
look
at
let's
encrypt
in
a
way
that
it
has
a
similar
effect
right.
It's
you
are
following
a
small
protocol
that
eventually
gets
you
a
like
bootstrapped
into
the
ssl
ecosystem,
to
call
it
something
somehow.
You
now
have
a
path
all
the
way
to
the
let's
encrypt
for
ta,
which
could
be
encoded
as
an
in
total
layout.
C
In
fact,
it
would
be
a
little
like
to
like
it
would
be
more
work
than
you
need
to
do
with
let's
encrypt,
but
if
you
wanted
to
do
something
like
that,
you
could
do
something
like
that.
C
Yeah,
it's
all
these
last
two
things
were
an
example.
I
know
that,
for
example,
the
second
one
that
I
that
I
put
forward,
let's
encrypt,
is
not
producing
stations.
I
know
cubesat
that
I
o
can
produce
in
terms
of
stations.
I
know
that
travis
doesn't
produce
introvert
stations
unless
you
do
some
backflipping
to
bootstrap
an
os
image
inside
of
traffic
that
has
each
other
installed
and
same
goes
for
kernel.org.
C
I
think
that's
also
a
good
segue
to
another
aspect
that
I
that
I
think
is
a
common
question
here.
A
lot
of
people
say
well
how
hard
is
insulator
to
use
and
a
lot
of
times
a
lot
of
the
times.
C
People
think
that
it
is
installing
in
total,
in
the
right
place,
but
in
fact
it's
it
is
not
installing
and
turning
the
right
place,
but
taking
a
good
hard
look
at
what
your
practices
are
and
distilling
that
into
a
total
layout,
because
more
often
than
not,
people
find
it
that
they
have
no
clue
of
all
of
the
practices
and
how
the
process
actually
looks
like
yeah.
G
Yeah,
if
I
may,
it
looks
to
me
like
the
the
bigger
problem,
is
the
where's,
my
pki?
It's
it's
easy
to.
G
You
know
it's,
it's
easy
to
say:
hey
everybody
signed
it
well,
are
those
the
right
keys
and
are
those
the
right
people,
and
this
doesn't
solve
that
problem
and
that's
in
my
mind
the
key,
the
pun
not
intended
the
key
problem
so
yeah
I
I
can't
afford
it,
but
you
know
once
you
have
that
addressed,
then
you
can
use
keys
and
this
to
help
you,
but
you
clearly
also
need
to
solve
the.
How
do
I
know
that
these
are
the
right
people
problem
for
and.
G
C
G
Does
solve
it
to.
C
Some
extent,
for
example,
with
reproducible
builds,
you
can.
You
have
a
layout,
that's
signed
by
deviant
developers
and
that
layout
inside
contains
the
keys
of
trusted
rebuilders.
C
So
you
can
trust
at
the
stations
from
the
trusted
rebuilders
by
the
transit
property
of
well,
where
they
trusted
to
rebuild
by
the
deviant
packager
that
created
this
layout.
So
in
a
way,
yes,
it
said
secure
tools
all
the
way
down,
because
you
need
to
bootstrap
the
trust
of
the
debian
ecosystem
into
your
say.
C
App
transport
for
reproducible
builds,
but
but
this
dials
back
all
the
way
to
the
to
the
question
that
the
dan
brought
originally,
which
is
all
of
this
ecosystems,
are
basically
using
their
own
pki
solution
and
you
need
to
somehow
fit
their
mental
model.
C
C
G
A
All
right,
yeah
thanks,
could
you
paste
the
I
just
left
a
comment,
but
if
you
could
paste
a
link
to
these
slides
and
agenda
doc,
that
would
be
awesome,
so
we
can
refer
back
to
them.
That
was
really
helpful
for
me.
Yeah.
It.
E
Feels
like
the
word
trust,
is
doing
a
lot
of
work
in
that
last
conversation,
I
think
that's
kind
of
thing
we've
been
discussing
in
comments
the
last
couple
days
right,
there's
there's
two
sides
of
it.
There's
the
side
of
it
is
strictly
the
do
we
recognize
this
entity
as
the
one
that
we
we
already
know
about,
but
then
there's
the
first
part,
which
is
how
do
we
trust
this
thing
to
begin
with,
and
we
seem
to
be
mixing
the
two
kind
of
liberally.
A
H
B
B
Oh,
I
think
I
don't
know
that's
something
that
was
saying
paste
the
link
there
and
for
those
of
you
that
started
leaving
some
comments.
Thank
you
gavin.
I
think
you're
in
there
a
few
places.
So
what
I
thought
we
could
do-
and
I
could
I
could
share
my
screen-
is
sort
of
just
you
know
continue
the
discussion
on.
You
know
what
are
the
actual
threat
models
that
we
see
along
the
supply
chain
and
then
taking
it
one
step
further.
B
You
know
what
are
folks
in
this
room
interested
in
tackling
and
you
know
we
started
with
a
developer
identity
piece
beginning
that
whole
trust
thing
in
the
supply
chain,
but
think
that
we
can,
you
know,
think
about
other
things
along
the
supply
chain
and
like
how
to
group
these
together
and
then
and
then
come
up
with
a
plan.
So
let
me
see,
if
I
can,
is
everyone
able
to
see
the
threat
models
doc
or
should
I
share?
Should
I
share
my
screen.
B
B
All
right,
I
haven't
caught
up
on
all
the
comments
myself
either,
so
we
started
to
categorize
all
the
ones
that
were
listed
at
the
bottom,
and
these
are
some
of
the
categories
that
we
came
up
with,
which
you
know
we
can
discuss
here.
What
people's
thoughts
are
on
them.
I
think
there's
some
comments
about.
There
might
be
some
overlap
and
the
first
one
we
pulled
out
was
account
hijacking
and
then
categorized
a
number
of
the
threads
underneath
and
then
sorry.
I
We
understand
the
point
of
this
exercise,
so
I
mean
a
couple
things.
One
there's
already
a
dog
that
lays
out
a
lot
of
the
existing
threads
that
is
incredibly
well
researched
and
written.
That
was
led
by
michael
scovera,
published
by
the
identifying
threat,
speaking
group,
and
I
don't
know
why
we
have
a
different
list
that
we're
working
from
and
second
of
all,
we
can
certainly
prioritize
these
threats.
But
I
don't
understand
wonder
what
scope
we
are
prioritizing
these
threats
for
for
what
purpose?
A
So
this
is
basically
one
of
these
studies.
Next
week
is
basically
meant
to
cover
scope,
so,
instead
of
trying
to
cover
scope
in
a
more
abstract
sense,
cover
scope
from
the
list
of
threat
models
pulled
out
of
microscope
at
his
dock,
so
and
then
a
couple
other
lists
of
threat
models.
So
it's
not
supposed
to
meant
to
be
like
a
novel
publication
on
the
threat
models
facing
open
source
just
a
way
to
figure
out
the
scope
of
this
working
group
and
what
threat
models.
People
are
interested
in
actually
attacking
here.
I
I
A
Yes,
the
point
here
is
to
figure
out
which
ones
this
working
group
is
interested
in.
I'm
not
quite
sure
the
suggestion
like
maybe
are
you
saying
we
take
this
up
a
different
level
and
then
have
some
other
group
decide
like
assign
threat
models
to
people.
I
I
B
Yeah,
I
think
we
could
use
the
stock
to
reference
those
because
I
you
know,
I've
sat
in
a
few
of
the
other
working
groups
now
and
I
don't
think
any
are
quite
tackling
some
of
the
things
that
we're
talking
about
here.
So
but
if
they
are,
let's
call
that
out
and
then
we
can
make
sure
that
we're
not
duplicating
work
anywhere.
K
My
I
I
think
I
agree
with
you.
It
might
be
a
you
know,
a
good
process
to
start
from
the
the
the
doc
that
happened
in
the
identifying
security
threats
group.
I
think
that
might
be
a
process
that
runs
from
that
working
group.
Though,
and
then
you
know,
we
could
use
that
at
some
point
in
the
future
to
identify
if
there
are
new
working
groups
that
that
need
to
be
available.
K
It
I'm
just
thinking
that
that's
kind
of
a
I
I
wouldn't
want
to
stop
progress
on
what
this
group
is
doing.
To
wait
for
that,
though,
because
there
are
the
some
of
the
threats
that
they've
identified
in
that
this
group
is
identified
in
their
document,
I
don't
believe
those
are
covered
by
other
groups.
L
So
I
the
way
I'm
kind
of
hearing
from
different
people
is
that
you
know
if
that
is
sort
of
the
source
of
truth,
the
centralized
repository,
if
you
will
of
the
known
threats
that
we
want
to
track,
it
makes
sense
to
work
off
of
that.
But
at
the
same
time
I
don't
think
that
doc
is
really
set
up
for
then
identifying
who's.
L
Doing
what-
and
it
seems
like
this
document,
I
think,
is
useful
for
this
group
to
help
brainstorm
or
correct
me
from
wrong
to
figure
out
what
this
group
is
going
to
target
and
then
eventually,
if
we
just
have
a
plan
going
forward
of
how
we're
going
to
reconcile
the
two
together
so
that
we
say
okay,
we're
not
duplicating
we're,
not
redefining.
L
What's
already
in
that
document,
maybe
we
add
to
it
and
edit
there,
and
then
we
just
use
this
to
kind
of
dictate
what
this
group
is
going
to
focus
on,
and
I
I
don't
think,
there's
a
whole
lot
of
conflict
there.
I
I
think
maybe
the
concern
is
just
making
sure
that
we're
a
little
bit
more
coordinated.
So
if
we're
just
more
intentional
about
saying
that
we're
more
coordinated
and
how
we're
going
to
sync
between
the
two
does
that
sort
of
solve
everybody's
concerns.
A
B
So
so
yeah
so
back
to
the
back
to
the
dock,
using
this
to
help
scope,
what
this
working
group
is
going
to
do,
there's
a
few
areas
that
we're
particularly
interested
in,
which
is
why
you
know
we
started
started
this
to
begin
with
so
yeah.
I
don't
know
if
people
want
to
like
openly
discuss
some
of
these
categories.
If
you
want
to
sort
of
thumbs
up
in
the
document,
do
a
plus
one
on
the
things
that
you're
interested
in
that
would
be
some
sort
of
signal
to
us.
B
Otherwise,
I'm
not
sure
if
we
want
to
go
around
to
each
people
and
to
everyone
on
the
call
and
ask
sort
of
what
you're
interested
in,
but
some
way
to
to
give
us
some
signal.
That
would
be
helpful.
Yes,.
B
Yeah
that
that
would
be
awesome,
and
then
this
is
linked
in
the
in
the
meeting
notes
today.
If
you
lose
a
link
to
it
as
well
and
so
gavin
did
you
want
to
bring
up
any
of
the
comments
that
you
had
about
sort
of
the
categories
that
we
picked.
E
Well,
I
guess
even
just
asking
people
to
go
mark
which
ones
they're
interested
in
right
interested
in.
In
what
context
I
mean
these
are
all
problems,
but
I
don't
know
if
they're
all
problems
within
the
bounds
of
what
this
working
group
was
supposed
to
be.
So
I
think
we
kind
of
need
to
have
the
sort
of
fundamental.
E
H
What
you
could
do
is
see
if
there's
some
interest
in
them:
okay
and
then
the
ones
that
there's
no
interest
they
can
be
knocked
out
and
then
the
ones
where
there
is
an
interest
we
can
assess
if
there
are
a
relevant
fit
for
this
group.
Or
is
it
a
case
that
over
another
group
should
be
looking
at
this?
How
would
that
work.
B
Yeah,
I
think
that's
we'll
go
ahead.
Okay,.
K
Well,
so
I
I
think
you
know
we
have
just
12
minutes
left
and
we
we
have
had
some,
I
feel
like
we
should
maybe
shift
focus
and
and
talk
about
scope
of
the
group.
I
know
you
know
it's
a
little
hard
because
we're
trying
to
say
okay
well,
let's
let
people
just
say
what
they're
interested
in
and
let
that
drive
scope,
but
I,
but
I
think
we
you
know
just
given
our
time
frame
and
the
sensitivity
about
this
group,
I
think
it.
K
Maybe
we
want
to
kind
of
come
from
the
other
direction
and
make
sure
we
understand
the
concerns
that
have
been
brought
up
with
the
current
scope.
Think
about
how
to
address
values.
But
I
want
to
address
this
kind
of
in
a
way.
That's
broad
that
leaves
this
group
room
to
still,
you
know,
go,
go,
go
forward
and
decide
what
actual
work
needs
to
be
done.
K
But
let's,
let's
try
to
you
know
I
I
I
think
we
really
need
to
address
the
immediate
concern
and
we'll
we'll
have
people
still
frustrated
about
that.
So
would
you
mind
if
we
shifted,
focus
and
talked
about
the
name
and
scope
of
the
group.
B
But
I
think
before
we
can
do
that,
we
still
need
to
sort
of
come
to
agreement
with
what
problem
areas
people
are
interested
in
solving
like
you
can't
scope,
something
until
you
understand
what
you're
trying
to
do
together.
So
I
mean
that's
why
we
put
this
stuff
together
in
some
way.
You
know
a
helpful
thing
to
help
frame
our
frame
our
thoughts
around
this.
B
A
Like
this
is
meant
to
be
kind
of
an
open
community
and
like
you,
can't
really
assign
work
to
people
in
this
context,
you're
kind
of
just
shepherding
and
figuring
out
what
people
are
interested
in
and
trying
to
get
everyone
together.
If
we
want
to
come
and
say
certain
things
are
off
limits
or
something
like
that,
I
think
that's
a
different
direction,
but
really
actually
getting
anything
done.
We're
gonna
have
to
just
see
who
wants
to
do
stuff
and
what
they
want
to
do.
A
K
Let
me
ask
one
question:
so
you
know
there
was
a
proposal
to
change
the
scope.
I
think
to
supply
chain
integrity.
Is
that
right.
K
From
anyone
with
that,
well
first
are
the
people
you
know.
Let's
just
ask:
are
people
interested
in
that?
I
I
I
think
the
answer
is
probably
yes,
but
you
know
I
can
go
write.
My
name
on
it.
Are
there
others
who
are
interested
in
that.
I
I
think
supply
chain,
integrity
and
verification
make
a
lot
of
sense.
We've
talked
about
surfacing
some
of
that
metadata
as
part
of
the
dashboard
project,
but
we
haven't
talked
about
creating
that
metadata,
so
we
certainly
need
to
talk
about
how
that
would
work.
I
My
qualms
remain
with
the
word:
identity,
specifically
developer
identity,
I'm
fine
with
code,
identity,
binary
identity.
All
of
those
concepts
make
sense
to
me
when
we
start
to
talk
about
developer
identity
in
the
context
that
we
don't
mean
cryptographic
keys.
I
I
think
that
is
out
of
scope.
A
So
the
name
aside,
the
name
is
one
thing
back
to
the
conversation
we
just
talked
about
before
bootstrapping
pki.
I
guess
that's
kind
of
that's
kind
of
the
piece
of
identity
that
we've
identified
as
missing
everywhere
from
all
these
presentations,
and
that's
kind
of
the
piece
that
I'm
really
interested
in
tackling
here
is
that
aspect
of
it
if
we
can
come
up
with
a
different
name
or
something
that
makes
people
feel
more
comfortable.
A
I
I'm
gonna
slightly
disagree
with
you,
because
I
think
that
you
could
certainly
manage
a
key
today
and
you
could
have
five
years
ago
using
key
base
and
the
fact
that
people
weren't
signing
things
is
a
problem
that
we
need
to
address
at
the
same
time
that
we
address
how
to
manage
keys.
K
Could
could
we
agree,
I
if
we
could,
you
know
sort
of
agree
on
one
thing
at
a
time
so
could
we
could
we
agree
on
a
scope
that
is
supply
chain
integrity,
and
how
did
you
say
it
maya,
supply,
chain,
integrity
and
verification
is
any.
Would
anyone
be
opposed
to
that?
Does
that
rule
out
anything
that
people
are
interested
in.
H
H
More,
I
mean
you,
you
call.
K
D
H
K
Sure
I
need
to
broaden
the
scope
of
this
group
and-
and
we
need
to
do
it-
we
need
to
do
it
expeditiously.
So
can
you
get
it?
I.
A
Mean
there's
a
sense
of
urgency
here
that
I'm
getting
that.
I
don't
really
understand
where
it's
coming
from
just
could
maybe
help
motivate
that
it
would
help.
But
I
feel
like
we're
being
rushed
into
deciding
something
that
we're
not
really
ready
for.
I
I
H
H
I
If
we
say
code
identity,
like
I
said,
I
have
no
concerns
the
there
is
wording
in
the
file
that
is
being
changed
on
the
pr
right
now
that
talks
about
naming
like
people's
names
and
developer
identity.
Those
are
the
parts
that
I
feel
very
uneasy
about.
Like
I
said
I
I
don't
have
a
need
to
rush
towards
a
new
scope.
Obviously
I
would
love
us
to
figure
out
what
that
is,
and
I
understand
that
takes
time,
but
just
those
words
are.
H
So
I
mean
the
way
I
see
this
group
is
it's
to
explore
the
topic,
it's
not
to
make
anything
mandatory
or
enforce,
or
it's
and
but
I
can't
totally
understand
the
the
connotations
that
are
there,
so
so
I
just
think
perhaps
for
now
we
can
at
least
remove
the
word
developer.
H
J
And
I'm
sure,
there's
a
I'm
sure,
there's
a
bigger
conversation
to
be
had
here
right,
because
if,
if
we
end
up
needing
to
identify
developers,
it
doesn't
matter
what
that
we've
removed
the
phrase
developer
identity
people
are
smart
and
they're
going
to
figure
that
out
and
it's
going
to
be
a
problem
one
way
or
another
right.
So
there's.
I
think,
a
bigger
sort
of
broader
issue
of
of
how
to
wrangle
that
issue
right,
yeah,
yeah,
very
much
just.
K
But
if,
if
you
would
consider
having
a
broader
scope,
then
you're
not
recording
discussions
back
with
our
probability
you're
allowing
discussions
about
other
things,
you're
resolving
the
immediate
concerns
that
people
have
with
the
name
of
the
group,
you
know
potentially
creating
problems.
You
know
concerns
from
developers
and
I've.
I've
heard
these
concerns.
I've
had
people,
you
know
coming
and
talking
with
me
about
it,
and
you
know
I.
I
understand
that
this
is
an
area
that
we
want.
K
K
This
is
just
my
my
opinion
or
my
recommendation
by
broadening
the
scope
and
if
you
broaden
it
to
something
like
supply
chain
and
integrity
and
verification,
you
can
you
know,
continue
it.
You
know
exactly.
We
can
continue
it
with
you,
I'm
very
interested
in
this
topic
as
well,
but
you
know
we
can
continue
working
working
through
the
details.
F
K
K
You
know
they're
they're,
all
kind
of
similar
and
personally,
I
think
any
of
those
could
work.
You
know
we
just
pick
one
and
then
move
to
that,
and
then
we
can
continue
about
our
business.
K
Let's,
let's
do
that
because
at
least
we
can
you
know,
even
if
it
pushes
it
down.
That's
that's,
okay,
let's,
let's
resolve
the
current
issue
and
and
then
we
can
still,
you
know
have
have
that
discussion
and
but
we
can
have
it
in
a
less
loaded
environment.
We
can,
you
know,
have
it
with
with
time
at
our
leisure
we
do.
K
I
mean
there
is
some
pressure
to
get
this
settled,
which
is
that
we're
working
to
announce
what
our
working
groups
are
and
so
the
longer
we
delay
this,
the
you
know
the
longer
it
takes
to
get
it
through
the
attack
and
the
approval.
K
C
E
Yeah,
I
think
that's
true.
I
think
my
other
concern
is
that
you
know
this.
This
group
isn't
working
in
a
vacuum
right
the
work
we
stream
was
created
with
this
specific
intention
in
mind
who
has
context
on
what
that
right?
What
was
the
problem?
They
were
expecting
this
group
to
solve.
They
created
this
work.
C
I
mean
it's
been
in
my
experience
that
nobody's
expecting
anybody
to
do
anything.
You
kind
of
show
them
a
solution
and
they
will
take
a
look
at
it
and
say
like
oh,
this
solves
my
problem.
If
we're
doing
nothing,
then
I
don't
know,
what's.
E
C
Yeah
I
mean
all
I'm
saying
is:
I
think
we
should
consider
the
context
of
well
we're
starting
and
people
will
probably
see
a
pr
publication
say,
like
that's
cool,
and
it
takes
a
lot
of
building
to
have
people
concerned
about
your
name.
J
There
was
only,
I
think,
there's
like
a
sort
of
semantic
conversation
here
which
again
like
we
don't
need
to
fight
yet
and
debate,
but
like
there
was
only,
I
think,
one
threat
model
identified
that
actually
required
physical
identity
sort
of
like
tying
back
to
a
human
in
a
name,
and
I
think
that
was
a
threat
around
two
people,
like
one
person,
one
physical
person
having
multiple
identities
in
the
system
and,
interestingly,
I
I
had
noticed
that
that
threat
did
not
even
make
it
into
this
document.
J
So
you
know,
even
if
there's
some
form
of
identification
in
this
system,
I
don't
think
we're
implying,
even
yet
that
that
is
applying
to
a
a
real
human
identity.
You
know
it
could
be
something
more
like
debian's
doing
around
reputation
and
and
really
it's
a
technical
mechanism
that
may
make
key
management
easier
right.
So
I
I
think
it
is
interesting
to
sort
of
scope.
This
stuff.
H
Yeah,
I'm
gonna
have
to
drop
now.
I'm
just
just
thinking
we're
on
the
hour,
so
right
so
should
we
should
we
go
forward
with
dropping
a
developer
term?
Okay,
everybody
there's
a
pr.
H
Okay,
yeah
and
everybody
put
their
interest
so
that
we
can
just
be
sure
that
we're
getting
a
when
we
decide
on
a
name
or
how
we're
going
to
make
a
name
at
the
next
meeting.
We
at
least
know
the
component
parts
that
make
that
name
make
sense.
Does
that
sound
good
thanks,
luke
yeah.