►
From YouTube: Supply Chain Integrity WG (March 2, 2022)
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
Hey
good
morning,
folks,
good
day,
folks,
good
morning
from
seattle,.
B
A
It
feels
like
we
should
be
having
some
sort
of
like
banter,
I'm
not
trying
to
think
of
what
what
good
topic
there
is.
Oh
somebody
can
bring
their
pet
on
camera.
That
always
helps.
C
I'd
grab
mine,
but
I
think
they're
in
front
of
a
heating
vent
right
now.
Is
it
cold
where
you're
at
well
I'm
in
portland?
So
it's
not
too
bad
right
now,.
A
A
A
A
A
A
A
Okay
and
I
just
sent
both
of
them-
email
as
well,
so
I
haven't-
I
haven't
heard,
but
it
seems
like
we're.
Seven
minutes
in
so
it'd
be
good
to
get
started
from
our.
Let
me
pull
up
the
agenda
document.
E
A
Okay,
on
the
let's
see
so
on
the
agenda,
we
had
just
one
thing
for
today,
unless
anyone
else
has
anything
to
add,
and
that
is
to
discuss.
So
microsoft
has
been
doing
some
work,
looking
at
signing
formats
for
supply
chain,
artifacts
things
like
software
bills
and
materials
and
other
things,
and
I
wanted
to
share
with
you
a
document
that
we
put
together
internally,
where
we
identified
a
set
of
requirements
and
then
also
evaluated
a
number
of
different
formats.
F
A
So
kim
lewandowski
just
sent
me
a
slack
that
said
that
today's
meeting
was
canceled.
Okay,
I
didn't
see
that.
A
C
Yeah
can't
really
access
google
docs
and
stuff
easily
from
within
our
vpn.
So.
A
Okay,
well,
I
don't
know
we
could
we
could
still
go
ahead
and-
and
you
know,
discuss
this
one
item
that
we
had
or
we
could
also
wait
and
do
that
in
the
next
meeting,
which
would
be
two
weeks
from
now.
I
guess
I'd
rather
go
ahead
and
and
share
if,
if
that
works
for
unless
anyone
has
concerns
with
that.
A
F
G
F
I
don't
know
why
it
was
cancelled.
It's
something
to
follow
up.
I
think,
there's
not
it's
not
right.
A
Okay,
so
let
me
I'm
gonna
I'll
sort
of
kick
off
this.
The
discussion
of
you
know
what
we
did
in
this
supply
chain
envelope
comparison
and
then
ian
mcmillan,
for
microsoft
is
also
with
us,
as
well
as
brian
krell,
and
they
really
led
this
work
so
I'll.
Let
them
kind
of
talk
people
through
the
through
the
document.
A
Inside
of
microsoft,
we
are
planning
with
the
upcoming
executive
order,
on
improving
the
nation's
cyber
security
executive
order,
14028
we're
planning
to
publish
some
artifacts
of
conformance
to
executive
order
requirements,
it's
actually
conformance
to
the
secure
software
development
framework
ssdf,
and
that's
all
information
that
nist
has
published
about
how
companies
demonstrate
conformance
with
the
executive
order
requirements
so
we'll
be
providing
these
attestations
we'll
also
be
we're
also
planning
to
make
publicly
available
our
software
bills
of
materials
for
all
of
our
products
and
services.
A
First,
we'll
in
terms
of
sequencing
first
we'll
be
providing
the
conformance
attestations
and
then
a
little
later
we'll
be
making
our
our
software
bills
of
materials
public.
That's
just
you
know
internal
the
time
it
will
take
us
to
get
those
various
documents
ready
for
publishing.
A
So,
as
we
were
evaluating
how
we
would
be
site,
we
want
to
assign
those
when
we
make
them
available,
and
this
document
is
something
that
just
describes
our
process
for
looking
at
which
signing
format
we
would
use.
So
that's
the
background
that
I'll
give
and
then
I'll
turn
it
over
ian
if
you're
ready
and
let
you
walk
us
through
from
there.
B
Yeah
thanks
kate,
yeah
and
as
kate
was
saying
I
in
in
as
the
document
states
I
mean
when
we
look
at
signatures
and
what
are
we
trying
to
get
from
them?
It's
really
those
two
main
things
that
we
we
know
and
love
about,
signing
it's
authenticity
and
that
integrity
promise
those
those
can
be
used
to
equate
do.
I
trust
this
or
not
trusted
and
and
other
security
decisions
can
be
made
with
a
signature.
B
So
we
had
to
look
at
our
requirements
from
a
number
of
technical
angles
that
included
the
os
independence
perspective.
We
in
this
document
we
give
a
brief
summation
of
what
we
mean
by
os
dependence.
What
do
we
mean
by
device
reach?
You
know
going
if
you
simplify
that
going
from
a
server
class
machine
all
the
way
down
to
a
you
know.
Very,
very
l,
zero
firmware
that
little
die
running
inside
of
a
chip,
type
of
of
device
or
even
smaller
iot
devices
that
have
low
low
resources.
B
We
also
looked
at
aspects
of
crypto
agility
and
what
we
need
to
be
able
to
account
for
the
good
practices
that
we
see
out
there
in
the
crypto
world
and
that
we
follow
around
having
the
ability
to
to
establish
different
algorithms
that
we
may
want
to
use
based
on
different
findings
and
different
needs
out
there,
going
from
rsa
to
ecc
different
key
lengths,
different
hashing
algorithms
and
hashtag
algorithm
lengths
and
whatnot,
then
formatting.
B
The
version
format
has
to
have
a
version
id.
This
is
really
to
to
allow
verification
tools
to
be
able
to
understand
which
version
of
the
signature
am
I
working
with
and
be
able
to
not
have
to
resign
everything
just
because
we
came
up
with
a
new
signature
version
or
modified
the
existing
version
to
then
we
needed
to
have
unauthenticated
and
authenticated
metadata,
as
well
as
the
really
focus
on
the
authentication
of
of
metadata
and
the
payload
trust
model
flexibility.
B
This
is
really
a
hot
topic
of
when
we
bring
in
os
independence
and
other
independence
and
into
focus
here
you
have
to
have
keys
to
x509
pki
your
traditional
kind
of
x509
public
trust
pki,
maybe
even
to
open
pgp,
secure,
ledgers
and
and
whatnot.
So
we
really
needed
to
to
look
at
a
signature
format.
That's
going
to
be
able
to
support
that
trust
model.
Flexibility
goals
that
we
have
signature
lifetimes
is
common
thing
that
we
see
when
we
talk
about
any
kind
of
signatures,
that's
associated
to
code
or
any
kind
of
artifact.
B
B
Other
things
here,
like
air
gap
network,
if
you
look
at
the
way
we
one
might
look
at
traditional
pki
you're
thinking,
I
need
to
have
online
connectivity
for
krills
and
ocsp.
B
B
All
these
other
ones
are
kind
of
self-explanatory,
especially
when
we
get
into
multiple
endorsers
to
then
what
we
call
trust,
resilience,
signatures
or
multiple,
hybrid
signatures,
where
I
can
actually
sign
an
artifact
at
the
time
of
signing
with
multiple
keys
and
have
a
path
to
alternate
chains
of
trust.
B
Then,
from
an
ecosystem
perspective,
we
really
focused
on
industry
standard
having
something
that
our
consumers
out
there
would
would
widely
feel
comfortable
with
adopting,
especially
if
it's
a
standard,
it's
easier
for
all
of
us
to
work
on
it
cohesively
together
and
not
have
forks
of
one
going
this
way,
one
going
that
way,
we
can
stay
together
and
work
together
to
to
make
something
that
is
going
to
meet
all
of
our
customer
and
consumer
needs.
B
The
ecosystem
support
was
really
big.
We
didn't
want
to
just
have
a
signature
format
that
is
only
supported
by
this.
This
small
ecosystem-
let's
say
by
on
windows
to
you,
know
something
that
I
couldn't
really
parse
or
understand.
There's
no
ecosystem
support
on,
say
linux,
for
instance,
multi-laying
library
speaks
to
that
as
well,
it's
again
getting
to
that
device
reach
and
that
os
platform
independence
perspective.
B
And
that
also
goes
into
minimizing
developer
error,
so
we
dove
into
primarily,
I
would
say,
four
signing
formats
that
we
looked
at.
We
looked
at
seabor
cozy
or,
I
should
just
say
cozy,
because
the
c
in
cozy
stands
for
sibor
dead,
simple
signing
envelope,
dizzy
the
then
the
ever
so
popular
jws,
jwt
and
all
of
its
variants,
as
well
as
pkcs7,
and
really
as
we
went
through
this,
what
you'll
see
in
the
document
is
we
outline,
you
know
what
is
cbore
or
what
is
cozy?
B
B
What
are
the,
what
is
our
perspective
on
on
how
it
can
or
cannot
meet
those
requirements,
and
you
know
with
cozy,
we
found
a
lot
of
value
in
in
its
ability
to
meet
a
lot
of
these,
and
it
was
by
far
it
really
came
out
as
the
one
that
kind
of
shined
for
us
that
that
we
would
like
to
to
look
at
leveraging
across
all
of
those
those
artifact
types
and
all
of
the
different
scenarios.
A
We
should
probably
mention
that
I
mean
there.
There
were
concerns
about
cozy
as
well.
Oh
yeah,
it
is
still
it's
still
relatively
new
and
you
know
there
are
there's
some
libraries
for
it,
but
in
terms
of
ecosystem,
it's
a
I
would
call
it
a
developing
ecosystem,
certainly
not
not
as
strong
as
the
jws
jwt
or
the
pkcs7
communities.
A
A
We
have
been
involved
with
a
few
folks
from
the
cozy
community,
in
particular
some
people
from
the
from
the
company
arm
who
have
implemented
a
they've
implemented
a
go
version
of
the
cozy
library.
At
microsoft,
we've
implemented
a
net
version
and
there's
also
a
there's
a
python
version,
but
there
is
now
between
microsoft
and
the
rm
community.
We've
started
a
project
that
we
call
glue
cozy,
and
I
can.
B
A
Yeah,
okay,
anyway,
so
there's
there's
this
community,
that's
just
getting
started
that
is
setting
up
a
shared
test,
suite
that
library
developers
can
run
those
test
suites
against
their
like
their
libraries
and
then
reports
can
be
put
out
indicating
you
know
their
conformance
to
various
features
of
the
libraries
and
that
information
about
the
libraries
and
the
features
supported
will
be
available
on
that
glucosi
website.
A
The
other
place
where
there
were
concerns
is
about
the
complexity
of
the
specifications
specifically
relative
to
cosy,
which
is
a
very
simple
specification,
and
so
for
that
there's
a
proposal
which
is
to
use
a
subset
of
the
what
we
call
a
profile
or
subset
of
the
cozy
specification,
and
it's
it's
not
going
directly
to
that
anyway.
So
we've
we've
proposed
a.
A
A
profile
that
limits
the
features
of
cozy
that
would
be
used
for
signing
supply
chain
artifacts.
A
So
just
a
couple
of
details
about
cozy
anyway
go
go
on.
B
B
So
with
and
brian
feel,
free
to
jump
into
or
or
steve,
you
all
were
a
part
of
this
too
and
looking
at
this
so
feel
free
to
jump
in
at
it
at
any
point
here
and
add
any.
E
Color
commentary
yeah.
The
only
thing
that
I
would
add
quickly
is.
I
mean
I
think,
that
there's
sort
of
been
an
interesting
evolution
of
this
document
from
sort
of
an
internal
discussions
to
getting
some
feedback
from.
We
talked
to
santiago
at
purdue
who's
behind
the
tuff
and
in
toto
also
see
some
comments
in
the
the
doc
from
from
dan
lawrence,
specifically
around
the
dizzy.
E
I
think
that
there's,
as
ian
mentioned
there
there's
definitely
it
is
a
design
goal
is
a
feature
of
dizzy
to
be
very
simple
in
our
initial
analysis
of,
or
comparison
of
some
of
these,
these
formats
probably
evaluated
it
unfairly
in
in
that
respect,
because
it
was
intentionally
not
considering
the
fact
that
dizzy
is
intended
to
be
used,
for
example,
in
tough
or
in
toto,
where
a
lot
of
some
of
the
security
guarantees
that
we
were
expecting
an
envelope
to
be
capable
of
handling
are
handled
in
that
trust
model.
E
And
so
you
know,
I
think
that
is
one
of
the
gaps,
because
we
did
identify
that
trust
model.
Flexibility
is
important
for
us
and
we
have
concerns
around
dizzy,
because
it
does
sort
of
tie
to
those
models
that
that
include
those
features,
and
it
doesn't
have
the
capability
of
carrying
some
of
that
information
within
the
signature
envelope.
But
again,
just
as
people
have
a
chance
to
read
this
and
review
it,
I
think
it's
important
to
keep
the
context
of
that
evolution
in
mind.
E
G
I
mean,
I
think,
the
you
guys
covered
it's
the
the
overly
simple,
because
some
things
were
delegated
into
other
areas,
where
the
breadth
of
scenarios
where
we
see
we
need
to
support
signature
formats
need
something
more
robust,
but
it
doesn't
need
to
be
as
large
as
the
cozy
spec,
such
as
the
glue.
So
the
glucose
spec
reduces
that
down
to
a
reasonable
scope.
So
I
think
that's
the
balance
that
we're
shooting
for.
B
Those
goals
that
we
had
here
and
jwt
overall
is
widely
used,
but
maybe
the
json
serialization
not
so
widely
used,
and
while,
like
notary
v2,
is
starting
to
leverage
jws
json
serialization,
we
we
definitely
were
we're
looking
at
can
can
jws
json
serialization
also
work
for
us
or
is
cosi
a
better
thing
or
is
dizzy
a
better
thing
here,
so
it
it
was
a
delicate
balance
of
looking
at
all
of
these
requirements
and
saying
which
one's
most
important
or
where
they
stack
rank
as
well
to
us,
and
that,
like
brian,
was
mentioning
that
trust
model.
B
Flexibility
really
becomes
important
as
we
expand
out
beyond
just
the
supply
chain,
artifacts
or
with
inside
of
tough,
and
then
total
models
or
similar
models
to
that.
And
how
do
we
look
at
the
digital
media
portion
too
here
that
we're
also
trying
to
create
a
world
that
doesn't
have
multiple
signature
formats
across
a
lot
of
artifacts?
That
we
similarly
send.
G
And
get
the
note
on
the
notary
stuff,
the
the
awt
was
a
placeholder.
We
knew
from
the
beginning.
We
needed
to
change
it.
We
were
originally
thinking
pkcs7,
but
there
was
some
gap
in
libraries,
so
jwt
was
used
as
a
placeholder
until
we
can
get
what
we
thought
pkcs7
was
going
to
fill,
but
the
cozy
work
really
seems
to
fill
it
much
better.
So
that's
it's!
B
B
B
A
It
might
be
worth
mentioning
you
know
as
one
next
step,
so
in
our
conversations
with
with
santiago,
he
was
suggesting
that
perhaps
we
could
consider-
and
you
know
this
is
something
that
we're
talking
about
on
the
microsoft
side-
is
adding
optional
support
for
cozy
to
the
in
toto
golang
library,
and
then
that
way
you
know,
people
who
are
interested
in
the
cozy
format
could
choose
that
and
but
yeah
and
and
dizzy
of
course,
would
would
still
be
the
default.
But
but
then
there
could
be.
You
know,
options
and
people
could
select.
H
B
H
What's
interesting,
is
you
you
brought
up
one
aspect:
was
it
the
the
multi,
the
multi
trust
chains
with
mate,
yeah,
multi-chain
trust
being
able
to
be
trusted
among
different
ecosystems?
That
was
I've.
Never
thought
about
that.
I
don't
know
why,
but
until
you
mention
that
today,
that's
that's.
B
Cool
yeah
and
that
that
alternate
chain
of
trust
aspects
we
start
to
think
about
how
how
else
can
that
evolve,
with
even
the
concepts
of
of
how
do
we
think
about
like
quorum?
When
we
talk
about
quorum
is
does
this?
Does
this
cluster
meet
quorum?
Do
I
have
enough
servers
here
enough
people
here
to
meet
quorum?
What
about
signatures
and
trust
anchors
for
for
some
critical
pieces
of
content
that
that
may
be
necessary.
H
Well,
you
talked
about
one
thing
I
was
as
you're
saying.
One
thing
I've
been
thinking
about
is
like
the
probability
of
trust,
I
think
about
like
sort
of
the
concept
behind
search,
centered
results.
You
have
this
this
this
authority
rating
right.
This
is
almost
like
a
trust
rating
where
you're
going
as
if
it's
in
different
chains
of
trust
or,
if,
like
microsoft,
says
yes,
I
trust
this
and
it's
out
here,
and
so
you
have
other
big
companies
saying
they
trust
it,
and
you
know
it
can
validate
it.
H
Almost
like
social
proof,
but
social
proof
applied
that
it
wasn't
the
this
is
not
the
the
concept
of
social
proof
applied
to
you
know
publicly
open
our
open
source
software.
H
F
A
Well,
if
no
other
questions
or
comments
on
that,
that
was
the
only
item
that
we
had
on
the
agenda.
We'll
try
to
figure
out.
I
can
you
know,
reach
out
to
dan
and
kim
and
jennifer
from
the.
I
guess.
Jennifer
from
the
linux
foundation
was
the
one
who
actually
canceled
the
meeting,
but
I'll
try
to
figure
out.
Why
not
everyone
saw
that
it
was
canceled.
Maybe
there
was
a
snafu
in
the
mailing
list
or
something
else
too.
Okay,.
F
I
think
you
know
you
guys
asked
for
questions.
I
don't
feel
like
there
was
a
sufficiently
broad
set
of
people
here
to
be
able
to
actually
ask
all
the
questions
you
wanted.
So
I
I
feel
like
we're
going
to
want
to
do
this
again
with
the
broader
group.
I
I
should
have
said
that
I
find
wasn't
clear.
You
know.
G
F
F
I
Problem,
what
is
the
expected
output
that
we
would
choose
one
to
make
a
recommendation
for
signing
formats
going
forward.
E
I
think
there's
also
a
goal
if
ian
talked
about
hopes
and
dreams,
if
everybody
agree
yet
we're
all
going
forward
in
the
same
direction,
that
may
not
be
entirely
realistic,
but
getting
some
momentum
behind
it
leveraging
the
the
community
to
you
know,
contribute
to
the
the
cozy
profile.
Some
of
these
efforts,
like
kay,
talked
about
the
glue
cozy
is
sort
of
a
shared
way
forward,
leveraging
feedback
from
a
lot
of
different.
You
know
potential
stakeholders,
I
think
getting
some
community
support
behind.
It
would
be
excellent.
G
I
mean
it,
it
is
a
pretty
big
recognition
that
I
mean
this
is
obviously
a
and
it's
been
a
change
happening
for
a
long
time.
Microsoft
I
mean
it
used
to
be.
What
do
we
have?
What
do
we
ship
on
the
windows
platform,
but
that
windows
is
now
a
target,
not
the
target,
so
we
we
do
recognize
that
our
customers
are
running
on
multiple
operating
systems
or
running
in
multiple
clouds.
They're
running
on-prem.
G
There
is
no
clearer
line
for
people,
so
the
fewer
things
that
tooling
has
to
enable
to
enable
customers
to
work
across
things
fluidly
in,
but
it
has
to
range.
You
know
it
has
to
span
that
range
of
devices
and
ecosystems.
So
I
I
think,
there's
a
lot
of
benefit
in
trying
to
at
least
get
down
to
as
few
as
possible,
but
they
do
need
to
have
enough
robustness
to
handle
the
outlines
in
here
from
small
devices
to
air
gap,
environments
to
cross-government
agencies,
kind
of
things.
I
No,
I
had
forgotten
to
take
myself
off
of
mute,
though
now
that
I'm
unmuted
again,
I'm
curious
whether
the
something
like
this
would
result
in
government
agencies
only
accepting
a
single
format
in
the
end,
because
that's
what
the
tooling
they
have
is,
or
or
because
of
this,
this
group's
recommendations
is
that
a
possibility.
G
I
think
it's
a
good
question,
I
I
don't
you
know
it's
hard
to
know
what
how
these
things
go.
I
mean
the
governments
are
not
there
to
create
they're
more
like
endorsing.
What
they
see
is
has
been
a
best
practice
for
things
and
identifying
their
scenarios.
So
I
think
it's
I'm
sure.
We've
already
seen
this
like
the
government
is
a
customer.
G
I
mean,
let's
be
clear
right,
it's
a
pretty
big
customer,
it's
a
pretty
impactful
customer,
but
it's
we
get
this
from
all
of
our
customers
have
certain
standards
they
require,
as
they
see
better
standards
evolve.
They
shift
theirs
to
that
so
we're.
This
is
why
I
think
we're
seeing
the
team
focus
on
something
like
cozy,
which
has
an
evolving
footprint.
It's
it's
growing.
It's
accounted
for
the
complexity
of
scenarios.
I
A
Yeah,
I
think
we're
maybe
we're
in
the
kind
of
the
early
socialization
you
know,
let's
and
and
hopeful
that
you
know
we
can
have
a
conversation
and
then
you
know
together.
Ideally
like
others
said
they
agree
on
something
common
that
that
we
would
all
want
to
use
we'll
we'll
see
how
that
goes.
First,
first,
steps
of
a
conversation.
F
F
So
what
is
the
next
part
right
like
if
we
agree
on
this?
What
happens
next
and
how
do
we
start
incorporating
this
into
the
various
solutions
that
are
being
built
across
the
space
right?
Because
it's
not
going
to
be
you
know
whatever
you
guys
are
building
internally
suddenly
becoming
the
thing
everywhere
right.
So
what
are
the
moving
parts?
How
do
we
fit
this
in?
How
does
it
become
an
ecosystem
integrated
solution?
Because
you
know,
I
think
many
of
us
share
the
same
point
of
view,
which
is
I
don't
care
about
this?
F
I
don't
want
to
care
about
this
and
I
shouldn't
care
about
this,
but
we
seem
stuck
on
it
really
hard
great.
How
do
we
get
past
it
and
how
does
it
actually
play
out
over
time?
And
so
this
doc
is
great,
but
it's
really
for
people
who
are
going
to
be
arguing
about
the
minutiae
of
this
format
of
that
format.
From
us
either
a
heels
dug
in
position
or
a
crypto
opinion
of
any
position.
Neither.
F
Describes
me
right
and
neither
which
describes
anybody
who's
sitting
there
as
a
job
is
to
say
how
do
I
make
my
systems
more
secure?
How
do
I
not
look
like
an
idiot?
How
do
I
comply
with
various
eos
right?
This
doesn't
solve
that
problem
either,
though,
and
so
we
got
to
connect
those
dots
and
that's
what
this
group
should
be
talking
about
and
figuring
out.
I
would.
I
would
like
to
see
that
conversation
playing
out
as
well.
F
So
again,
I'm
just
being
very
direct
in
terms
of
like
what
I
think
needs
to
happen
next,
in
order
for
us
to
be
able
to
understand
like
how
do
we
as
a
community,
be
able
to
say
I
built
a
build
system
or
I
am
building
my
software
in
a
way
that
can
comply
with
various
expectations
right
and
I'm
not
even
being
specific
about
eo
or
just
my
own
internal
security
expectations.
I
have
risk
here.
I
want
to
reduce
risk.
F
I
want
to
show
that
I
can
match
the
ssdf
expectations
by
doing
this
right,
I
could
paint
cozy
over
every
single
line
of
code.
I've
got,
and
it
doesn't
do
a
damn
thing
for
that
thing:
directly.
There's
work
to
get
between
there
and
there.
A
D
A
F
And
I
think
that's
I
think,
that's
great,
I
mean
I
agree.
I
would
love
to
see.
Where
are
the
impedance
mismatches?
No,
because
there
was
a
conversation
which
I
understand
conceptually,
but
don't
have
the
specifics
around
the
different
trust
sort
of
expectations
of
different
layers
of
the
of
the
frameworks.
F
A
Okay,
well
great
thanks
thanks.
Everyone.
Apologies
sounds
like
we'll.
Probably
do
this
again
in
two
weeks
from
now
so,
but
we
definitely
appreciate
the
feedback
in
the
comments
today.