►
From YouTube: Supply Chain Integrity WG (March 16, 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).
D
B
I
saw
that
the
us
just
signed
a
bill
for
keeping
daylight
savings
time
forever,
or
something
should
be
fun.
F
A
B
All
right
people
are
trickling
in.
I
posted
the
meeting
notes
doc
in
the
in
the
chat.
If
you
want
to
sign
in
I'm,
not
sure
if
I'm
writing
this
or
dan
but
I'll
just
go
ahead.
Sorry
about
last
meeting,
I
know
if
a
bunch
of
folks
showed
up
and
there's
some
discussion,
we
tried
to
cancel
it.
There
was
consensus
in
the
slack
that
people
wanted
to
cancel
due
to
craziness
going
on.
B
We
dan
tried
to
send
out
a
email
to
the
mailing
list,
but
the
groups
thing
that
we
use
on
for
this
working
group.
It's
a
little
bit
tricky
when
you're,
not
a
member
and
several
of
us
have
many
different
email
addresses
it
get.
It
gets
blocked
or
it
gets
put
in
a
queue,
and
then
you
don't
get
any
notice
back
that
that
your
email
wasn't
delivered
as
expected.
So
sorry
about
sorry
about
the
last
meeting,
the
cancellation
that
happened,
I
think
on
the
agenda
today.
B
The
the
first
thing
is
the
signing
formats
discussion
continued
and
I'm
not
sure
who's
driving
that
today,
but
it'd
be
great.
If
you
wanted
to
do
a
quick
recap
of
what
you
were
all
able
to
discuss
in
the
last
meeting
yeah,
I
I
can
hi
kay
hi.
H
Hello,
everyone
good
morning
from
seattle:
it's
it's
not
raining.
Currently
now
we
have
a
status
update
the
the
topic
of
the
signing
envelope,
so
we
did
have
a
few
folks
at
the
meeting
last
week
and
yeah
we
were
confused,
but
it's
totally
fine
no
worries,
we
kind
of
did
a
pre-review
of
the
document
with
the
people
who
were
there,
and
you
know
recognized
that
we'd
need
to
do
it
again
when,
when
we
had
had
more
folks
in
attendance,
so
the
it
came
for
some
reason
in
the
chat.
H
I
don't
see
a
link
to
the
to
the
meeting
notes,
the
only
one
that's
missing
that
do.
I
show
up
again.
I.
F
And
while
we
get
this
ready,
I
expect
this
is
gonna,
be
the
most
of
the
discussion
today.
I
know
the
last
naming
one
is
quick.
I
don't
know
how
long
the
other
topic
is.
Brandon.
I
assume
that's
brandon
lum.
Do
you
know
how
much
time
you
need
for
that
one?
Just
we
can
make
sure
to
save
it
at
the
end.
I
I
H
Okay,
all
right,
so
I
dropped
over
the
document
in
the
chat.
It
was
also
in
the
notes.
H
All
right,
so
let
me
provide
some
background
and
context
the
as
this.
This
document
started
as,
and
you
know,
an
effort
inside
of
microsoft
and
and
we've
shared
it
with
you
know
quite
a
few
other
people
now
we're
still
very
much
looking
for
comments
the
and
it
started
inside
of
microsoft,
as
we
were
looking
at.
What
signing
envelope
do
we
use
for
signing
our
supply
chain
evidence
and
particular
the
evidence?
That's
re
requested
by
the
executive
order,
8014028.
H
So
this
is
a
new.
You
know
this
is
new
type
of
content
that
that
we're
starting
to
create
and
wanting
to
share
with
others
across
the
industry.
It
includes
things
like
software
builds
of
materials,
but
in
addition
to
sufferability
of
materials,
you
know
other
types
of
content
required
by
the
executive
order
and
in
particular
now
to
satisfy
executive
order
requirements.
Government
agencies
will
begin
requesting
a
high-level
attestation
of
conformance.
H
This
is
a
lot
of
detail,
so
apologies
to
this
software
secure
software
development
framework
ssdf.
So
it's
a
new
type
of
conformance
attestation,
we'll
provide
we'll
be
providing
to
government
agencies.
H
S-Bombs
will
be
another
type
of
content
and
as
we're
starting
to
provide
this
type
of
data
we're
looking
at.
How
do
we
sign
this?
So
go
ahead.
H
H
H
We
aren't
expecting
to
mass
migrate,
a
bunch
of
existing
ecosystems
onto
a
new
format,
but
for
supply
chain
data
and,
for
you
know,
any
type,
any
new
types
of
signing
going
forward.
We
wanted
to
give
a
look
at
what
what
format
would
we
use
so
so
our
process
was.
We
got
together
internally,
a
bunch
of
folks.
You
know
across
microsoft
involved.
H
You
know,
including
our
iot
folks,
that
work
on
our
iot
devices
books
in
our
windows
organization,
folks,
that
think
about
container
signing
and
folks
in
our
it's
our
product
release
and
signing
services
organization.
H
I
I
think
some
of
you
had
a
chance
to
read
this
ahead
of
time.
So
I'm
not
going
to
go
through
this
in
detail.
I
could
just
kind
of
breeze
through
them,
but
you
know,
as
I
do,
if
people
have
questions
about
any
feel
free
to
jump
in
a
key
requirement
was
os
independent.
So
we
wanted
you
know
so.
A
key
goal
for
these
types
of
artifacts
is
that
they're
exchanged
freely
and
globally.
H
You
know
across
the
industry,
so
we
you
know
we
needed
them
to
be
able
to
be
signed
and
verified
on
any
operating
system.
Another
goal
was
device
reach.
So
you
know,
we
think
that
this
type
of
content,
especially
things
like
maybe
bills
of
materials
and
other
supply
chain
evidence,
would
need
to
be
validated
on
low
power
devices.
H
Another
area
that
we're
looking
at
is
cryptographic
agility,
so
we
we
know
in
in
the
security
world
that
cryptic
graphic
algorithms
are
are
broken
over
time
and
need
to
be
deprecated,
so
we're
looking
for
a
format
that
allows
for
deprecation
of
of
algorithms
we're
looking
for
versioning
of
the
format-
and
this
you
know
again,
is
to
allow
kind
of
for
changes.
It's
forward
thinking
to
allow
for
changes
in
the
format
over
time.
H
Another
is
authentication
of
metadata
and
payload,
and
I
said
some
of
these
areas,
I'm
gonna
brian.
Can
I
let
you
help
me
with
some
of
these
areas,
as
I
talked
through
it.
So
brian
krell
is
an
engineer
in
our
product
release
and
signing
services
so
and
he'll.
He
knows
more
details
in
some
of
these
areas.
Do
you
want
to
just
touch
on
the
why
this
is
important.
J
Yeah,
I
I
think
the
the
idea
here
and
one
of
the
requirements
that
we
identified
was
that
there
would
likely
be
a
need
to
include
additional
headers
additional
metadata
along
with
with
the
payloads.
So
we
we
wanted
a
format
that
was
capable
of
of
separating
those.
A
J
H
And
here's
one
where
dan
raised
a
question
so
it
might
be,
might
be
worth
stopping
and
and
talking
through
that.
H
F
Yeah
the
authenticated
non-authenticated
one
yeah.
There
are
other
approaches
here
where,
like
you,
just
don't
put
them
in
the
same
envelope
and
I
guess
they're
pros
and
cons
either
way.
That's
kind
of
the
thought
process.
I
think,
when
working
on
dizzy
and
some
of
the
other
fields,
if
it's
on
authenticated
metadata,
it
doesn't
need
to
go
in
the
same
envelope.
You
can
go
next
to
it.
I
guess
it's
kind
of
a
conceptual
piece.
J
Right,
I
I
agree
with
that.
I
think
there
are
pros
and
cons
to
both.
I
think
one
of
the
principles
that
we
were
trying
to
approach
this
from
on
the
microsoft
side
was
not
choose
a
particular
path,
allow
flexibility
for
for
either
approach
or
whatever
combination
of
approaches.
Someone
wants
to
use,
but
not
limit
by
choice
of
assigning
format.
Those
options.
J
Sure
I
mean
I
think
that
this
was
a
conversation.
Definitely
that
started
within
microsoft
and
people
coming
from
different
angles.
Thinking
years
down
the
road
thinking
about
months
down
the
road
thinking
about
years
in
the
past
and
a
lot
of
investment
in
x,
509
pki
hierarchy
that
it's
not
necessarily
easy
to
change
over
overnight,
and
so
also,
then,
thinking
about
you
know,
open
source
communities
and
open
pgp
key
only
scenarios
there's
a
lot
of
stuff
out
there
and
we
wanted
to
provide
for
the
flexibility
of
without,
I
think,
at
the
very
top.
J
We
we
just
that
we
call
out
that
an
identity
model
is
out
of
scope
for
for
this
document,
but
the
trust
model
flexibility
is
that
that
identity
model
that
trust
model
should
not
be
constrained
by
the
choice
of
signing
format
that
we
can.
F
J
J
It
sort
of
ties
back
into
that
authenticated
and
unauthenticated
metadata
that
if
a
format
is
capable
of
carrying
arbitrary
additional
information
that
a
verifier
can
understand
in
some
some
way,
then
that
provides
the
opportunity
to
support
some
model
that
some
verifier
wants
to
to
build
and
support,
whereas
a
format
that
does
not
have
the
ability
to
carry
any
additional
information
could
not
possibly
could
not
be
compatible
with
it
with
a
different
model.
So
I
think
these
are
examples
of
things
that
people
might
want
to
use.
They're,
not
prescriptive
about.
K
K
What
will
allow
this
flexibility
to
exist
as
a
matter
of
fact
something
I
realized
after
I
reviewed
this
document-
is
that
the
protocol
header
on
the
signature
envelope,
that's
part
of
the
authenticated
header
it's
actually
optional
and
on
the
notary,
pull
request.
They
mentioned
that.
The
reason
why
that's
optional,
it's
a
good
idea,
because
it
makes
it
more
secure,
whereas
all
this
time
I've
been
saying
that
the
reason
why
we
took
it
out
of
the
dc
envelope
is
because
it
was
a
security
liability.
K
So
I
I
really
don't
know
what
the
benefit
is
of
having
a
bunch
of
like
optional
things
that
you
can
hash
and
sign.
That's
something.
For
example,
pgp.
C
C
To
do
this,
but
I'm
not
missing
your
point
and
if
there's
means
we
need
to
work
with
the
industry
to
figure
out
how
we're
going
to
do
this
right.
And
I
do
not
want
to
say
hey
what
we've
used
for
the
last
40
years
is
going
to
be
what
we're
going
to
use
for
the
next
40
years
and
we
need
to
might
be
able
to
migrate
from
one
format
to
another
sure.
K
C
K
Not
complaining
the
two
of
them.
I
have
been
thinking
about
this
problem
for
many
years
and
that's
part
of
the
reason
why
I
do
not
believe
that
you
can
go
process,
an
expiration
header
if
it
is
there
and
then
expect
to
be
able
to
combine
mixed
scenarios
and
reason
through
them
on
two
different
layers:
the
semantic
layer
of
what's
inside
the
payload
and
what's
outside,
of
the
payload
and
somehow
make
some
like
tight
binding
between
the
two.
J
Yeah,
I
think
that
that
is
I
I
I
have
not
spent
nearly
as
much
time
thinking
through
some
of
these.
As
you
have
santiago,
and
I
I
think
that's
that's
valid,
but
I
think
that
the
the
idea,
I
I
think
the
claim
is
not
that
separating
authenticated
metadata
from
a
payload
specifically
enables
a
solid
trust
model
story.
I
think
what
it
says
is
that
there
are
potential
valid
trust
models
that
may
need
this
support,
that
that
may
need
the
ability
to
carry
authenticated
headers.
J
In
addition
to
the,
in
addition
to
the
payload,
there
may
be
valid,
very
secure
models
that
do
not
require
it.
However,
the
signing
format
given
that
some
may
require
it
should
should
be
able
to
support
that.
I
think
that's
what
we're
trying
to
capture.
K
J
Hand
so,
and
if
we
don't
that's
fine,
I
think
that
there's
plenty
of
examples
of
ways
that
we
do
this
today.
I
think
you
could
come
up
with
a
counter
argument
like,
oh
you
don't
have
to
do
it
that
way
today.
In
fact,
it
might
be
better
to
do
it
this
this
other
way.
You
know
back
to
pkcs7
and
signed
attributes.
J
Rfc
3161
counter
signatures
for
you
when
you've
got
an
x509
model,
so
I
think
a
lot
of
these
examples
are
there.
You
could
absolutely
make
the
argument
that
there's
a
better
way
to
do
that,
but
I
think
what
it's
acknowledging
is
that
there
are
ways
that
are
known
today
and
in
use
today
that
do
require
these
capabilities.
D
Okay,
sorry,
is
that
better!
D
Now,
yes,
so
there's
two
of
us
in
the
same
room
with
the
thing
which
is
me
okay,
I
I'm
missing
the
like
the
higher
level
of
what
the
purpose
is
and
what
problem
you're
trying
to
solve
here
like
this
is
going
into
like
signing
artifacts,
but
it's
not
explaining
why
you
need
to
sign
them
or
what
exactly
you're
signing
or
in
what
context
you're
doing
that
and
what
problem
you're
trying
to
solve
or
why
there
needs
to
be
a
single
one,
and
so
I
think,
a
lot
of
the
kind
of
the
decisions
it's
hard
to
say
like
there
should
be
a
single
signing
format
in
the
entire
world,
but
it
would
help
to
know
like
for
what
purpose
does
there
need
to
be
one
yeah?
D
H
We
are
yeah.
I
tried
to
tee
that
up.
Maybe
I'm
not
sure
if
you
were
on
when
I
first
started,
or
maybe
I
did
a
bad
job
of
teeing
it
up,
but
the
a
key
scenario
driving
this
is
the
ability
to
share
supply
chain
evidence
across
the
global
ecosystem.
H
So,
for
example,
the
sharing
of
software
bills
of
materials
and
another
example
would
be
sharing
of
attestations,
of
executive
order,
conformance
and
and
then
in
addition
to
that,
we
were
looking
at
using
the
same
signing
format
for
things
beyond
supply,
chain,
evidence
or
supply
chain
artifacts
to
other
digital
artifacts
like
containers,
I
think
that
was
kind
of
the
the
other
main
one
that
we
were
looking
at.
C
Your
general
question,
the
reason
we're
saying
is
to
give
some
assurance.
It
is
the
content
we're
giving.
You
is
immutable
and
and
who's
stating
that
it's
immutability
right
and
that's
what
we
typically
do
with
science
content
and
either
email
or
whatever,
if
it's
at
risk
somewhere
and
it's
not
signed
it's
very
hard
for
us
to
make
that
claim
and
we've
picked
we
settled
on
signing
even
c2pa
is
the
same
thing
to
prove
that
multimedia
content
has
not
been
faked,
they're
going
into
a
signing
format
with
cozy
right
so
main
reason.
D
So
so,
okay,
so
that's
that's
what
I
had
thought
this
was
about
was
signing
supply
chain
metadata,
but
in
that
case
a
lot
of
the
arguments
for
trusted.
D
Flexibility
in
the
envelope
format
don't
seem
to
apply
because
you
could
put
them
one
layer
down
in
the
like
in
the
payload.
I
think
that
was
the
comment,
if
I
understood
correctly,
that
santiago
had
mentioned,
which
is
that
it's
not
clear
why
you
need
to
have,
for
example,
lifetime
support
and
arbitrary
fields
in
like
kind
of
the
outermost
layer.
J
Is
that
you,
you
must,
or
we're
even
recommending
that
you
put
that
in
a
in
a
separate
layer,
we're
saying
that
if
we're,
if
there
is
going
to
be
any
broader
alignment
on
a
format,
it
shouldn't
block
you
from
doing
so.
If
that
is
something
that
makes
sense
for
you,.
J
I
mean,
I
think,
there's
a
risk
that
anything
is
potentially
implemented
incorrectly,
if,
if
there
is
a
fundamental
security
vulnerability
with
that
approach,
I
mean,
I
think,
that's
absolutely
a
conversation
with
happening
or
with
sorry
with
happening.
Having
I'm
not,
you
know,
I
I'm
not
convinced
that
they're
that
that
is
a
fundamental
flaw
regardless
there
is
no
way
to
implement
that
securely.
C
No,
no,
no,
no,
no,
no,
no,
no,
no,
no,
no,
the
key!
So
the
right
individual.
A
lot
of
our
scenario
is
unauthenticated.
Content
is
already
self-authenticatable
and
potentially
a
secure
receipt
or
a
secure
timestamp.
It's
already
something
that
is
independently,
so
they're
authenticated
on
authenticated
editors.
C
D
I
guess
maybe
to
my
like
the
higher
level
question
of
my
point
is:
it
seems
like
what
the
ultimate
goal
is
is
to
define
an
ecosystem
where
supply
chain
metadata
could
be
interchanged
and
compatible
across
systems.
D
D
It
might
be
valuable
to
kind
of
have
a
bigger
picture
and
do
them
at
the
same
time,
because
it
seems
like
some
of
the
arguments
around
like
preferences
between
things.
Don't
like
not
everyone
has
the
same
picture
about
what
the
payload
will
be
and
how
it
will
be
used
and
having
that
picture
might
make
it
easier
to
get
agreement.
H
D
I
mean
I
understand,
having
like
30
multiple
types
of
payloads
that
we
support,
but
having
particular
examples
would
be
helpful
and
saying,
like
here's,
how
we
support
transferring
spdx
here's,
how
we
transport
transferring
salsa
providence,
here's
where
we
do
cyclone
dx
but
mark
again.
C
Because
absolutely
it's
kind
of
difficult
mark.
So
why
is
this
an
issue
for
email?
It's
all
mine,
it's
it's
multi-part!
You
can
put
anything
you
wanted,
create
a
new,
multiple,
part-time
right.
You
shouldn't
focus
it
on
the
content,
because
they're
trying
to
leverage
this
for
multiple
scenarios,
either
from
iot
to
to
multimedia
to
even
ours,
we're
trying
to
say
hey
what
is
our
requirements
for
assigning
format
and
for
every
permutation
we
have
on
the
signing
format.
The
security
threat
model
doubles
or
triples
right.
So
that's
why
we're
having
the
discussion?
D
I
I
just
think
that
goes
again.
I
think
you're
simultaneously
arguing
that
we
need
to
have
a
universe
like
a
single
format
like
I
just
don't
understand
if
we
support
kind
of
any
arbitrary
payload
why
there
needs
to
be
a
single
signing
format.
Actually
I
already
answered
that,
which
is
for
every.
C
Permutation
we
have
the
security
risks,
go
exponential.
We've
already
seen
this
for
every
time.
We
we
support
it
and,
if
you're,
asking
that
every
single
device
has
to
now
support
four
different
security
signing
envelopes
from
s
mime
to
dizzy,
to
to
josie
to
cozy.
Those
are
all
super,
complicated
things
and
if
we
can
say
hey,
here's
one
where
the
industry
is
settling
on
and
it
solves
a
lot
of
the
needs
and
we
can
limit
the
need
to
support
more
than
one.
Then
I
think
that
is
a
great
goal.
H
G
D
I
guess
what
I'm
and
and
just
as
a
time
check,
I
don't
want
to
take
up
all
the
time.
I'm
saying
in
the
in
the
goal
of
like
several
commenters
and
myself
included,
have
brought
up
that
a
lot
of
the
req.
The
requirements
are
that
it's
ultra
flexible
and
can
support
lots
of
things.
We're
we're
basically
shifting
the
complexity
instead
of
having
to
support
three
different
envelopes,
you're
supporting
one
envelope
which
is
extremely
complex
and
could
support
arbitrary
things.
C
We're
not
we're
trying
to
say
this
is
what
we
thought
for
the
minimum
requirements
that
we
needed
to
have
to
support
all
the
scenarios
that
we
see
within
microsoft
and
notary
and
secure
supply
chain,
and
that's
why
we
wrote
this
document
to
say
here's.
What
we
think
is
the
flexibility
that
people
are
asking
for
and
if
we
can
find
something
that
answers
these
subset,
then
that's
where
we're
going
to
go.
M
Yeah,
so
my
question
may
may
be
simple
here:
I
haven't
had
a
chance
to
read
this
doc
yet,
but
do
you
discuss
somewhere
the
relate
interrelationships
between
sig
store
and
tough,
and
in
toto
I
mean,
if
you
do
that,
that's
all
great,
but
I
think
that
might
actually
help
with
some
of
these
other
questions
too.
The.
How
does
this
fit
in
with
other
things
that
people
are
doing
or
intending
to
do.
H
Yeah
great
question:
we
don't
discuss
that
directly
in
this
document,
so
tough
and
in
total
and
are
using
the
dizzy
signing
format,
which
is
one
of
the
formats
that
we
identified
here,
and
so
the
relationship
would
be
that
we'd,
we
we'd
love
to
see
all
of
us
agree
on
a
signing
format
and
then
adopt
that
the.
In
our
analysis,
we
felt
like
the
dizzy
format
is
too
constrained
for
the
needs
that
we
identified
and-
and
so
you
know
underlying
this
is
really
you
know.
H
Can
we
you
know,
can
we
all
come
to
a
common
agreement
on
a
format?
That
would
be
the
ultimate
goal
you
know
and
and
if
we
can't,
maybe
there
are
multiple
formats.
It
just
makes
it
more
complex
to
exchange
data.
M
Okay,
so
I
I
think
somewhere
in
here,
trying
to
explain
the
relationship
with
like
sigstor
and
tuff
and
in
toto,
I
think,
might
that
might
give
much
clarity.
C
Okay,
good
point
thanks
david,
actually
that
I
have
the
kind
of
question:
did
we
ever
in
the
store
documentation,
explain
why
we
signed
it
you're
asking
us
to
do
the
same
thing
here.
So
I'm
going
to
us
it's
basically
bread
and
butter
that
if
it's
going
to
be
at
rest,
we
need
some
way
to
protect
it
to
be
immutable
and
signing
technology
solves
that
question,
for
it
doesn't
really
matter
the
payload,
whether
it's
multiple
new
content
streaming
on
the
wire
or
an
s-bomb
document,
really
doesn't
matter
to
us.
C
C
I
worked
in
s
mine
for
nine
years.
I
know
it
intimately,
I
know
all
its
faults
and
everything
else
and
when
we
started
down
this
road,
I
asked
the
question
of
why
not
esmond,
and
we
should
be
very
clear
as
to
why
it
is
not
what
we
want
to
use,
but
as
a
technology
signing
to
us
is
a
way
to
protect
the
content
in
flight
and
on
storage.
Sure
this
is
this
is
this
is
something
that
I
think
everybody
in
this
call
can
agree
with
yeah.
C
H
H
I
you
know,
I
think
what
we're
what
we're
discussing
here
is
just
about
the
risks
of
having
a
very
flexible
signing
format
versus
versus
the
benefits
of
the
the
flexibility.
For
you
know,
resilience
to
you
know.
Future
changes
in
you
know
in
signing
formats
and
and
and
other
resilience.
M
H
M
C
So
david
we're
just
at
the
part
of
the
document
where
we're
listing
out
what
we
thought
the
requirements
were,
we
haven't
even
talked
about
what
the
formats
and
who
solves
what
these
are
the
things
we
thought
we
needed
to
cover.
So
we
haven't
got
past
that
far
and
you
you
write
on
the
other
comments.
Santiago,
if
there's
content
and
there
could
be
confusion,
we
have
to
be
really
crisp
as
to
what
is
authoritative.
What
is
a
failure
or
an
error
and
and
not
close
those
doors?
C
Those
show
you
got
some
malformed
problems
and
we
got
into
trouble
with
the
internet
for
trying
to
allow
sloppy
content
and
fix
it
for
the
user,
and
it's
been
nothing
but
problems
for
for
the
mime
world
and
for
for
html
for
years.
Right
and
we've
tried
to
slowly
tighten
this
up
and
stop
all
the
magic
auto
fixing
stuff
and
from
when
it
comes
to
security.
That's
a
failure.
If
we
continue
to
do
that.
K
I
totally
agree-
and
this
is
not
to
say
that
I
am
staunchly
opposed
to
it.
I
am
in
favor
of
playing
around
and
trying
things
out.
I
just.
I
just
feel
that
I
need
to
communicate
the
parts
supporting
me.
H
E
That
was
me
I
decided
to
back
out
based
on
some
of
roy's
comments
I
will
hold.
I
will
hold
my
fire.
E
G
Feedback
has
added
clarity
to
these
things,
so
it's
I
mean
it's
part
of
like.
I
know
we
want
to
rush
through
because
there's
other
items
or
other
topics,
but
that's
the
kind
of
the
points
we
want
to
make
sure
we're
getting
the
right
feedback
to
refine
this,
because
it
is
such
a
broad
impacting
decision
and
discussion.
F
H
Yeah
great
great
question,
so
what
you
know
what
we
wanted
to
do
and
it
might
take
another
meeting
or
so
is
to
you
know,
kind
of
continue,
walking
through
requirements
and
and
and
the
different
formats
that
we
evaluated
separate
from
this
discussion
here.
We
we
did
have
some
discussions
with
santiago
and
santiago.
H
You
know
in
the
spirit
of
sort
of
learning,
together
kind
of
coming
at
this
with
an
open,
open,
mind,
growth
mindset
and
you
know,
learning
together,
santiago
suggested
that
it
could
be
interesting
to
modify
the
in
toto
golang
library
so
that
it
could
include
optional
support
for
either
dizzy
or
cozy,
and
so
that's
something
that
we've
been
looking
at
in
term
internally
and
you
know
I
don't
have
a
team
signed
up
exactly
to
do
this,
yet
we
need
to
think
through.
H
You
know
who
would
do
it
and
you
know
what
we
wanted
that
we're
thinking
about.
This
is
just
experiment.
You
know
kind
of
I'm
a
little
concerned
about
our
doing
something
that
would
be
that
we
wouldn't
be
committed
to
potentially
keeping
up
in
the
long
term.
So
I
want
to
make
sure
we've
kind
of
thought
through
it
and
santiago.
H
We
may
want
to
have
some
more
conversations
with
you
there
and
then
I
noticed
that
in
the
recore
project
dan,
you
had
kind
of
put
a
stub
in,
for
maybe
adding
cozy
support
to
record
as
well,
and
so
you
know
maybe
in
parallel
some
next
steps
would
be
for,
and
it's
certainly
something
that
we're
looking
at,
maybe
investing
in
adding
some
support
for
cozy
and
then
then
you
know
people
can
see
it
think
about
it,
and
and
we
can
continue
the
discussions.
K
Yeah,
I
will
say
that
I'm
happy
to
to
to
work
on
the
support
for
cozy
on
etoro,
and
I
think
that'll
probably
help
also
david
be
a
little
bit
more
confident
that
he
can
picture
how
this
technology
interrelates
and
yeah.
I
think
I
think
that's
that's
a
cool
next
step
to
to
have
something
more
tangible
to
show.
H
I
think
there's
also
there's
some
concern
that
you
know,
because
the
cozy
format
is
complex,
very
flexible.
You
know,
there's
there's
concern
and
rightfully
so
I'm
going
to
skip
to
the
one
of
the
requirements
that
we
had.
We
had
some
concerns
about
minimizing
the
the
errors
and
implementing
libraries
and-
and
it's
definitely
harder
to
implement
libraries
when
they're,
more
complex
and
also
there
were
concerns
about
minimizing
errors
that
developers
might
make
from
you
know,
lack
of
information
or.
H
Again,
just
complexity,
and
so
we
had
some
proposals
for
addressing
those,
but
that
you
know
for
at
first
we're
just
thinking
about
the
requirements.
So
minimizing
error
is
one
and
minimizing
library
and
developer
area
are
both
part
of
the
requirements.
H
So
so
I'm
hopeful
that,
as
we
sort
of
get
into
approaches
for
for
doing
those,
it
might
help
not
minimize
that
you
know
help
some
of
the
comfort
level
for
considering
an
alternative
to
disease.
So.
H
So
I
guess
proposed
next
step.
You
know
we
at
microsoft
we're
going
to
look
at
doing
some
work
on
the
existing
open,
ssl
projects
and
then
maybe
we
can
continue
this
discussion
of
this
document
in
a
future
meeting.
Does
that
sound,
reasonable
other
suggestions.
C
Brian
also
mentioned
we're
trying
to
dis
to
tangle
what
we
use
for
identity
out
of
this
document.
It's
a
great
discussion
to
pull
off
onto
a
second
document.
I
agree
we
kind
of
need
to
have
that
discussion,
but
in
this
document
we're
trying
to
say
hey,
we
want
a
migration
path.
We
haven't
stated
what
it
is
and
what
our
preferences
are,
because
I
think
community
we
have
to
figure
that
out.
C
F
Sorry,
I
think
the
identity
one
if
you
just
want
to
jump,
I
clicked
the
link
and
there
was
a
reference
to
something
else
that
had
made
a
choice.
So
that
was
just
my
only
question
trying
to
understand
the
implications
there.
There's
like
a
was
it
the
profile
one
I'm
trying
to
remember
now,
there's
a
suggested
profile,
and
I
clicked
that
and
that
had
mandated
something.
So
that
was
my
only.
H
H
F
F
Oh
yeah
yeah,
I
was
just
trying
to
understand
the
implications
of
these
sentences
said.
Something
like
you
know,
is
pgp
a
requirement
because
then
I
don't
think
any
of
the
things
below
really
support
that
okay,
yeah
yeah,
so
yeah.
I
get
that
no
examples,
not
requirements.
Okay,
yeah
and
then
below.
There
was
a
link
to
like
a
cozy
profile
for
supply
chain
and
when
I
had
clicked
that
link
that
thing
had
also
specified
decentralized
id
for
dids.
I
don't
remember
exactly
where
in
the
document
that
is,
though
yeah.
J
J
I
think
it's
something
that
we've
been
thinking
through,
like
hey
during
signing
format.
Evaluation,
could
something
like
this
be
done
with
the
format
that
we
are
looking
at
and
certainly
open
to
other
ideas,
proposals
as
well
just
a
very
early
draft
potential
example.
C
I
think
if
we
were
to
start
doing
something,
we
would
continue
to
use
x509
and
we're
asking
the
community
large
what
the
heck
do
we
want
to
move
to
right.
Do
we
want
to
stay
on
x509?
Do
we
want
to
go
to
did?
Is
it
did
web?
Is
it
dod?
Iond
is
dns,
there's
a
whole
set
of
questions
that
that
comes
out
of
that.
C
I
Yeah,
so
I
think
this
is
going
to
be
quick.
Let
me
share
my
screen
just
to
show
this
stuff
to
talk
about,
so
I
think
there
was
a
discussion
around
the
supply
chain,
catalog
that
the
cnc
have
created.
I
know
there
were
some
comments
from.
I
think
this
working
group
or
another
working
groups
that
were
saying
that
you
know
maybe
we.
This
is
something
that
we
can
collaborate
on.
I
know
you
know
to
be
able
to
add
the
resources
and
make
sure
this
is
kept
up
to
date.
I
With
the
correct
information,
I
wanted
to
kind
of
revisit
that
I
know
the
discussion
was
like,
probably
like
three
months
ago
at
this
point,
so
I
wanted
to
check
back
whether
there's
interest
for
us
to
collaborate
on
this
and
to
kind
of
keep
this
up
to
date,
whether
it
lives
within
the
cncf
or
as
part
of
ssf.
You
know,
I,
I
don't
think
we
as
a
cncf.
We
don't
have
that
bigger
opinion
about
it
is
mainly
about
you
know.
I
How
can
we
get
the
most
contributions
and
keeping
it
up
to
date?.
B
Hey
brandon:
this
is
kim.
We've
been
chatting
about
something
like
this
in
the
salsa
working
group
meetings
too
and
john
speed.
One
of
my
co-workers
has
started
to
look
into
this.
So
yes,
absolutely
it's
something
that
folks
are
interested
in
contributing
and
keeping
up
to
date.
There's
a
salsa
group
meeting
tomorrow,
if
you,
if
you're
able
to
attend-
and
we
can
bring
this
topic
up
a
bit
more-
there
too.
I
Okay,
yeah.
Let
me
let
me
see
what
I
can
enter
that
one.
If
not,
I
will.
I
will
try
and
adopt
an
issue
that
we
kind
of
had
to
discuss
some
of
these,
so
yeah
I'll
I'll,
try
and
make
it
to
the
meeting
and
if
not,
we
can
just
fold
up
and
get
up.
Okay,.
M
I
just
for
myself,
I
I
do
think
that
collecting
data
about
what's
been
going
on
is
really
valuable,
because
then
we
can
answer.
Questions
like
hey
is
this
common?
Is
this
not
common?
Now.
L
M
Not
much
better,
let
me
how
about
now
better
all
right,
I
I
have
a
little
volume
control
on
my
mic
and
I
sometimes
bump
it.
Okay,
so
repeat,
so
I
I
think
it's
very
valuable
to
have
a
list
because
it
helps
you
answer.
The
question:
is
this
important?
Is
this
not
have
people
done
it?
Is
it
a
common
thing?
How
have
they
done
it?
That
said,
I
believe
also
the.
It
might
be
useful
to
talk
to
the
backstabbers
knife
collection
folks,
because
this
is
a
different
collection
right.
I
This
collection's
only
the
stuff,
that's
public,
and
it's
just
community
community
driven
yeah.
K
Tell
me
yeah
so
there's
pretty
much.
Three
data
sets,
there's
the
backstabbers
collection
that
I
really
think
that
we
should
invite
them
and
then
there's
the
cncf
one.
That's
essentially
the
one
that
we
started
in
total
project
and
donated
there's
a
third
one.
That's
I
think,
john
speeds
one.
That's.
I
think
you
collected
that.
I
think
you
tell.
M
Term,
if
we
could-
and
maybe
you
know,
I
realize
that
some
of
them
don't
cover
exactly
the
same
things,
but
things
like
like
the
backstabbers
knife
collection.
They
only
do
open
source.
Fine,
you
know
have
a
little
check
mark.
Is
this
open
source,
but
it
would
be
awesome
if
we
could
avoid
doing
things
multiple
times.
K
Yeah,
no,
I
think,
for
research.
That
would
be
an
amazing
tool
for
everybody
to
not
only
design
systems
but
also
to
to
analyze
trends
and
to
yeah
understand
exactly.
M
Right
yeah
right
I
mean
the
backstabbers
just
as
a
for
instance.
They
showed
that
every
year,
except
the
most
recent
one,
the
big
one
was
typo
squatting,
but
all
of
a
sudden
dependency
confusion
showed
up
because
new
attack,
everybody,
it's
the
it's
the
new
thing,
everybody
hit
it
the
new
vulnerability
hotness.
I
guess
so,
but
you
know,
I
think,
that's
that's
very
valuable
in
terms
of
knowing
what
the
attackers
are
actually
doing.
K
The
third
one
is
john
speeds:
on
hqtail,
oh
I'll,
post
it
on
the
slack
yeah
yeah.
B
M
I
Research
cool,
so
it
sounds
like
let
me
try
and
drop
by
the
call.
If
not,
we
can
continue
the
discussion
on
on
I'll
put
in
a
github
issue
that
we
can
chat
on.
M
C
I
Yeah,
at
least
from
from
at
least
the
cncf
perspective
with
members,
have
found
this
useful,
the
kind
of
whether
it's
to
better
understand
what
type
of
attacks
are
and
also
kind
of
just
to
bring
back
to
executives
to
be
like
yeah.
This
thing
is
real,
although
I
feel
like
with
vlog4j.
That's
that's
easy
to
justify
now.
N
B
And
then
quickly
can
we
move
to
the
last
topic?
It's
naming
our
favorite
topic
in
computer
science.
Michael,
are
you
gonna
drive
this?
You
picked
the
perfect
name.
O
Sure
yeah,
so
I
think,
and
to
be
clear
right
like
we
can
put
it
up
for
a
vote
or
whatever.
I
think
what
we're
probably
going
to
do
is
is
we're
going
to
remove
we're
going
to
name
it
from
the
secure
software
factory
right.
We
want
to
kind
of
clear
any
confusion
that
it's
the
only
sort
of
thing
and
just
call
it
ssf.
A
lot
of
folks
are
already
sort
of
referring
it
to
ssf.
O
We
can
macro
nimit
with
something
like
you
know.
Ssf
is
a
software
factory
or
something
like
that.
We
just
you
know
based
on
some
of
the
other.
You
know
there's
a
lot
of
good
suggestions,
but
a
lot
of
them
were
sort
of
either
super
focused
around
salsa
or
were
already
names
taken
by
other
pretty
popular
projects
or
companies
or
whatever,
and
so
that's
kind
of
my
big
suggestion
is
just
to
kind
of
leave
it
as
just
ssf,
and
so
that
clears
up
the
confusion
that
it's
like.
O
Oh,
this
is
the
secure
software
factory
nope,
it's
just
ssf
and
since
people
are
already
sort
of
referring
it
to
referring
to
it
as
ssf,
we
could
just
sort
of
leave
it
as
that,
unless
you
know,
there's
any
big
objections.
F
N
You
tim
can,
I
can,
I
ask
to
add,
to
the
next
meeting
agenda
a
suggestion
for
a
new
project.