►
From YouTube: IETF114-SCITT-20220728-1730
Description
SCITT meeting session at IETF114
2022/07/28 1730
https://datatracker.ietf.org/meeting/114/proceedings/
A
Okay!
Thank
you
all
for
joining
the
skip
off
today.
I'm
hannes
next
to
me
is
roman.
Our
ad
who's
responsible
for
this
bath,
elliot
as
you
can
see,
participates
from
remote,
who
is
my
co-chair.
Hey
elliot
he's
going
to
post
on
the
questions
later
on.
We
have
two
meeting
minute
takers,
ball
and
alexey,
and
on
on
the
chat,
we
have
yogesh
monitoring
that
one
and
if
there
are
any
questions
bringing
those
to
our
attention.
C
A
This
is
the
agenda
for
today's
meeting.
First,
obviously,
I
would
like
to
welcome
you.
Then
we
talk.
I
I
give
a
few
details
on
the
background,
the
buff
goals
and
also
the
the
interim
buff
we
had
earlier,
followed
by
a
presentation
about
the
problem
statement.
Bob
is
going
to
give
that
one
cedric
we'll
speak
about
the
architecture
and
the
terminology.
D
I
think
you
covered
the
ground
really
well
already
honest
and
I'll
just
add
that
I'm
really
excited
about
the
bath.
I've
nev,
I
haven't
seen
so
much
energy
behind
the
the
general
concept
in
that
in
a
long
long
time,
in
terms
of
you
know,
you
normally
have
two
or
three
people
who
are
really
driving
things.
You
guys.
The
the
people
who
have
been
involved
in
this
even
early
on
are
are
really
a
quite
a
large
group
of
people.
A
A
A
We
refined
the
problem
statement
later
on
on
the
mailing
list,
which
bob
is
going
to
talk
about
to
make
it
even
crisper,
but
we
also
obviously
had
questions
on
the
deliverable
deliverables
and,
of
course,
discussions
on
the
solutions
which
I
couldn't
then
continue
down
on
the
on
the
mailing
list.
I
don't
want
to
go
into
the
solution
discussions
because
it's
a
little
bit
premature,
obviously
at
this
point
in
time,
but
it
was,
it
was
good.
A
And
at
the
end
of
the
buff,
quite
usually
we
ask
on
for
the
level
of
commitment
in
form
of
like
who
wants
to
review
document
right
document,
but
also
who
is
committed
to
do
some
implementation
work,
knowing
of
course
that
we
haven't
seen
the
solution.
So
it's
a
little
hard
to
exactly
say
what
you're
going
to
implement.
But
there
was
a
lot
of
interest
and
I
was
posted
on
the
mailing
list.
I
tried
to
capture
this
here.
A
This
is
my
sort
of
assessment
on
what
falls
into
the
software
supply
chain
use
case
and
into
other
use
into
other
use.
Cases
like
that
are
more
related
to
hardware,
and
but
overall,
what
you
see
it's
a
lot
of
people
responded
to
my
to
my
email
and
expressed
interest
to
do
an
implementation,
but
it
also
showed
that,
even
though
we
focused
on
the
software
supply
chain
use
case,
people
have
other
use
cases
in
mind
too,
for
that
technology,
which
obviously
quite
important
and
so.
A
We
we
want
to
make
sure
that
those
are
addressed
as
well.
We
don't
want
to
leave
interested
bodies
behind,
so
we've
been
working
on
the
problem
statement
on
the
mailing
list
and
we've
seen
sort
of
this
tension
between
sort
of
writing.
The
text
of
the
problem
statement,
as
well
as
the
charter
in
tailored
to
the
software
supply
chain
use
case
and,
on
the
other
hand,
have
a
little
bit
more
generic
framing
to
cover
also
other
use
cases
like
hardware
for
hardware.
A
F
E
E
We
need
to
focus
on
something,
and
so
we've
chosen
software,
because
pretty
much
all
kinds
of
organizations
make
use
of
software
either
just
software
by
itself
in
some
cloud
or
software
in
a
device
controlling
real
interactions
with
the
universe
as
it
were.
So
you
know
think
about
what
we're
trying
to
do
is
just
like
a
notary.
E
You
know
we're
trying
to
have
a
service,
a
capability
that
can
witness
you
making
statements
or
something
making
statements,
we're
not
really
caring
what
the
statement's
about
just
that,
it's
really
you
or
really
the
thing
that
did
it
and
when
they
did
it.
So
that's
kind
of
our
generic,
our
you
know
broad
application,
but
we
want
to
focus
on
the
software,
because
it's
a
clear
and
very
dire
problem
right
now
and
we
think
it
will
actually
flex
through
the
different
scenarios.
We
need
and
that's
pretty
much
what
I
had
as
a
prepared
discussion.
E
G
E
E
It
was
witnessed
by
the
following
people:
all
these
statements
would
be
go
through
the
notary
and
be
recorded.
The
notary
actually
doesn't
care
what
those
statements
are,
but
we
do
to
solve
the
you
know,
kind
of
things
like
solar
winds
or
so
on.
So
the
idea
here
is
that,
if
you've
done
things
to
show
the
process
show
the
assurance
gaining
activities
done
on
that
software,
that
you
can
bring
them
in
and
also
you
can
have
somebody
independently
third
party
come
in,
and
you
know
endorse
those
that,
yes,
I
physically
was
there.
E
A
E
G
Mostly,
but
I
think
I'm
still
like
I
mean
I
do
understand
it
from
external
reasons,
but,
like
I
just
don't
understand
what
the
notary
is
doing
there,
which
is
to
say
that,
like
you
know
well,
things
like
like
like
there's
like
the
the
concept
like
I
witnessed
has
never
seen.
I
witnessed
you
doing
some
specific
thing
and
what
the
notary
in
this
case
is
doing
is
saying.
You
said
something
or
other
which
I
haven't
looked
at,
but
I
promise
you
did
it
at
this
time,
and
so
I
think
I
just
I
hope
you
could.
E
A
E
Yeah,
just
one
little
aside,
so
if
you
think
about
a
notary
in
the
real
world,
you
know
that
they
can.
You
know
witness
a
contract,
they
can
witness
your
signing,
something
they
they
can
witness
anything.
You
want
and
basically
they're
attesting
that
you
know
it's
you
doing
that
action
they're.
They
aren't
investigating
the
validity
of
that
thing,
and-
and
so
that's
part
of
the
model
you
want
to
think
about.
I
think
so.
I
J
Hello,
okay,
yeah!
So
thanks,
so
I'm
ceric
fournette
from
microsoft,
and
I'm
going
to
give
you
an
idea
of
what
we
have
in
the
initial
draft
architecture
for
skate
and
in
part
2.
I
have
one
slide
explaining
what
we
think
are
the
additional
security
properties
of
that
we
get
through
the
notary
of
the
transparency
service.
J
So,
let's
start
with
a
bit
of
terminology,
so
the
the
core
notion
for
what
we
do
is
the
claim,
so
that
terminator,
that
is
specific
in
the
context,
and
that
is
detailed
in
the
draft.
But
so
a
claim
is
any
statement
made
by
an
issuer
about
an
artifact.
So
that's
quite
generic
intentionally.
So
we
we
want
the
issuer
to
be
identifiable
and
you
want
the
same
one
to
be
non-reputable.
So
in
practice
it
means
the
issuer
will
design
the
statement
with
the
key
associated
with
their
identity.
J
So
the
core
role
of
skit
is
the
notary
of
the
transparency
service
and
the
role
of
the
military
is
to
take
a
claims,
sign
claims
that
are
presented
to
it
and
then
apply
its
designated
registration
policy
and
if
the
claim
matches
the
registration
policy
to
register
that
claim
into
a
transparency
registry
that
it
maintains
and
to
issue
a
receipt.
That
proves
that
this
claim
has
been
inserted
at
a
given
position
in
the
receipt
so
the
getting
in
more
details.
J
So
it's
a
very
fair
data
structures
that
crucially,
is
happening,
so
the
notary
can
add
stuff
to
it,
but
it
cannot
remove
or
edit
or
relied
what
has
been
recorded
in
the
past.
I
want
to
point
out
that
transparency
is
for
the
consistency
of
what's
in
the
registry.
It
doesn't
mean
that
everyone
will
have
full
access
to
the
registry,
that's
something
that
is
a
matter
of
local
implementation
decisions
for
the
notary.
J
J
The
next
slide,
please,
okay,
so
here
we
go
with
the
secrecy
properties.
You
may
ask
what
we
gain
by
having
this
notary
intermediary,
and
here
we
have
to
manage
expectations.
So
there
is
no
way
we
can
say
whether
a
piece
of
software
is
good
or
bad
or
whether
something
that
you
claim
that
is
made
is
malicious
or
in
good
in
good
faith.
J
We
provide
the
guarantee
that
everyone
talks
about
the
same
claims
talking
about
the
same
artifacts
so
when
they
can
refer
to
it,
they
can
endorse
it.
Maybe
they
can
invalidate
it
like
reporter
burg
or
vulnerability
on
it,
but
at
least
there
is
a
common
ground
for
referencing
the
claims
and
the
issuers.
J
Finally,
and
more
specifically
having
this
registry
guarantee,
is
that
it's
not
possible
for
different
relaying
parties
to
be
presented
with
different
claims
or
different
artifacts
for
the
same
objects
and
it's
very
important
to
exclude
classes
of
attacks.
That
would
be
a
target
particular
relaying
parties,
as
opposed
to
others
so
trying
to
avoid
detection.
J
So
there
is
a
price
to
pay
for
that
and
which
is
that
for
all
consumers
or
claims
like
verifiers,
auditor
or
imparties.
We
accept
them
to
check
first
before
they
do
anything
else,
with
the
claim
that
the
claim
has
been
properly
registered
in
the
designated
at
the
dignity
notarian.
For
that
they
will
check
the
counter
signature,
the
proof
of
inclusion
and
the
receipt
to
make
sure
that
they
are
talking
about
something
that
is
properly
registered
before
making
any
decisions
and
looking
at
this
content
and
deciding
what
to
do
with
the
artifact.
J
Okay
next
slide,
so
there
is
quite
a
lot
of
related
work
in
this
area,
so
in
particular,
there
are
many
transparency
mechanisms
and
services
that
have
been
deployed,
typically
for
specific
use
cases
or
applications.
So
the
the
most
famous
is
probably
certificate
transparency
that
it
tends
to
keep
a
global
registry
of
all
xr99
certificates
being
used
in
practice
for
a
tls
authentication,
at
least
on
this.
On
the
server
side.
J
J
So
the
flow
goes
as
a
start
from
the
issuer,
who
decides
to
make
a
claim
about
a
given
artifact.
So
the
issuer
selects
the
statements
and
it
provides
an
envelope
that
contains
headers
that
are
going
to
be
interpreted
by
the
transparency
service,
and
that
includes
its
identity.
Its
choice
of
cryptographic,
algorithms
and
may
also
include
additional
parameters
to
be
passed
to
the
registration
policy
on
first
by
the
by
the
notary.
J
So
the
issuer
then
assigns
the
envelope
containing
the
statement
with
a
key
associated
with
the
identifier,
the
identifier
put
in
the
envelope
of
the
claim,
and
then
the
issuer
or
anyone
else
can
present
that
claim
that
sign
claim
for
inclusion
in
a
transparent
data
transparency
service.
So
the
transparency
service
will
apply
its
restriction
policy
then
insert
in
the
authenticated
data
structure.
That
is
the
registry
then
produce
that
receipt
and
return
it
so
that
it
can
be
attached
to
the
claim
and
distributed
to
any
parties
who
may
rely
about
that
claim
and
its
content.
J
So
from
that
point
on,
the
verifier
should
of
course
check
that
whatever
claim
they
accept
has
been
properly
registered
so
that
it
is
transparent
and
more
more
advanced
security
checks
are
doable
for
auditors.
That
may
be
able
to
collect
a
large
collection
of
physics
and
check
for
their
consistency
and
even
go
to
the
registry
and
replay
the
registration
and
of
what
has
been
put.
What
has
been
accepted
by
the
transparency
service
and
also
independently.
A
K
So
paul
vargas,
just
just
a
remark
on
this
presentation
on
the
previous
slide-
maybe
some
more
slide
back,
oh
yeah!
No,
this
one
we
did
actually
in
the
transparency
working
group
also
do
a
little
bit
of
work
on
this.
We
tried
to
do
a
binary
transparency
for
firmware
images
work,
so
I
don't
think
it
went
very
far
and
it
wasn't
really
consensus
on
doing
it.
The
way
it
was
described,
but
I
just
wanted
to
make
sure
that
we're
aware
of
that
it
has
happened,
and
people.
A
Yeah
paul,
that's
a
that's
a
good
comment
and
and
clearly
like
for
anyone
who
knows
the
certificate
transparency
work.
This
is
obviously
very,
it's
essentially
a
generalized
version
of
of
that.
But
what
we
are
talking
about
here
so
the
problem
with
above
is
always
you
have
to
use
some
terminology
and
while
once
the
working
group
in
a
later
stage
is
formed,
you
will
actually
then
agree
on
that
terminology.
So
you
have
to
pick
something
first
and
then,
of
course
not
everyone
agrees.
A
M
A
Lots
of
other
people
in
the
queue,
but
they
don't
do
they
want
to
go
to
the
microphone
where's.
The
dick
was
first
echoed
you
were
next,
but
but
keep
those
to
the
but
guys
keep
those
to
the
clarifying
questions,
because
we
have
a
like
50
minute
slot
afterwards,
after
hank's
presentation
on
the
program
of
work,
so.
N
N
People
are
relying
on
digital
signatures
today
to
prove
who
the
software
supplier
is
for
many
of
the
sign
software
products
and
the
problem
is
that
there's
really
no
verifiable
way
to
say
this
party
was
authorized
to
sign
on
behalf
of
this
supplier,
and
so
I
did
a
little
experiment
to
prove
this.
To
my
friends
in
the
energy
industry,
I
took
the
java
one
of
the
java
distributions
at
jvm.
N
It
was
signed
by
oracle
and
I
went
ahead
and
I
signed
it
with
rea's
signing
key
and
when
and
when
I
showed
the
people
at
nerc
that
I
was
able
to
overcome,
take
over
the
java
distribution
and
claim
that
I
was
the
supplier
by
virtue
of
the
key
they
they
were
really
kind
of
surprised,
but
that's
the
problem.
We
have
right
now
that
we
we
need
some
way
from
the
supply
chain
side
to
have
to
verify
these
relationships.
That
supplier,
that
microsoft,
you
know,
has
authorized
dick,
brooks
or
rea
to
sign
on
their
behalf.
A
O
I
said
I
wanna,
I
can
address
the
previous
question
from
ecker
and
and
this
one
as
well,
so
my
name
is
roy
williams.
In
the
case
of
the
notary,
we
have
an
opportunity
to
potentially
extend
notarization
of
claims
that
last
longer
than
the
certificates
that
they're
signed
with
microsoft
has
done
this
in
the
past
with
authenticode,
and
it's
been
a
complex
problem
for
us
for
many
years
and
it
doesn't
scale
so
we're
looking
at
a
simpler
solution.
O
That's
an
opportunity
that
comes
with
the
notary
here
and
potentially
a
lot
of
reduction
due
to
the
what
is
perceived
as
a
reduced
set
of
skid
services
now
to
eric's
last
question,
which
is
six
store,
six
store.
Currently,
the
the
open
ssf
project
is
multiple,
so
there's
salsa,
sig
store,
jfrog
is
putting
perseus
and
persia
in
there
and
so
forth
in
the
case
of
sigstor
they're.
O
Currently,
at
the
point,
where
they're
offering
a
free,
simple
way
to
not
have
to
deal
with
pki
by
issuing
certificates
at
a
very
short
timeline,
so
there's
no
curls
or
no
ocsp
and
you're
relying
on
logging
to
come
back
to
proof
of
token
in
this
model,
sigstor
would
end
up
generating
the
content.
That
would
be
shipped
up
to
a
skit
instance,
which
the
notary
would
then
validate
and
then
record
it
when
it
happened
and
put
it
on
the
ledger.
So
they
they
kind
of
plug
into
one
another.
O
In
the
case
of
salsa
they're,
making
claims
and
content
that
somebody's
going
to
sign
and
also
then
submit
to
the
skit
store,
so
they
they
don't
overlap.
They
actually
complement
each
other
and
plug
into
one
another.
Now
who's
to
say
you
know
as
sigstor.
The
open
source
project
grows
into
this,
where
there'll
be
more
overlap,
but
at
the
moment
they
just
plug
into
one
another.
H
Hi,
michael
richardson,
so
this
is
my
problem-
was
with
the
first
slide,
where
it
said
that
our
use
case
was
software.
S-Bomb
things
we're
all
really
good
at
that,
and
here's
a
good
example
of
you
know
the
things
there's
several
different
efforts
and
s
bombs
and
I'm
not
saying
they're,
bad
or
unnecessary.
I
actually
think
they're
really
important
and
really
necessary.
Okay,
I'm
not
actually
sure
what
the
ietf
as
a
network
focused
thing
brings
to
those
other
efforts.
H
Okay
on,
in
particular,
my
concern
is
that,
with
respect
to
the
people
from
microsoft,
I'm
sure
you
can
make
anything
fly
at
scale
at
large
scale.
The
question
is,
you
know:
can
you
make
it
work
for
left
pad
right
and
that's
the
real
question?
Can
you
make
it
work
for
physical
devices?
So
I
my
feedback
is,
of
course,
let's
deal
with
the
software
bill,
a
materials
problem,
okay,
but
I
think
we
need
a
second
use
case
which
is
in
the
physical
world
and
which
explains
to
people
outside
the
itf.
H
Why
it
is
that
we're
involved
in
this
process?
Well,
it's
probably
because
these
claims
need
to
be
transmitted
over
the
internet
and
probably
have
to
have
anchors
that
trust
anchors
they
are,
are
look
up
able
on
the
internet
with
some
authorization,
but
to
do
that,
I
think
we
have
to
go
a
little
bit
out
of
our
comfort
zone
and
we're
actually
going
to
have.
We
need
to
pick
a
an
available
other
thing.
H
Maybe
dick
here
can
can
bring
us
the
energy
sector
of
physical
devices
in
that
sector,
if
so
great,
but
but
I'm
not,
I
don't
want
us
to
focus
on
just
you
know,
left
pad
and
the
latest
open,
ssl
distro.
We
need
to
go
beyond
that
point.
Otherwise.
I
think
that
we'll
we'll
wind
up
with
a
standard-
that's
great
for
us,
but
nobody
else
uses
thank.
A
A
Some
of
the
folks
and,
as
I
tried
to
show
on
this
slide
some
folks
coming
more
from
the
software
supply
chain
inside
others
coming
from
sort
of
other
industries,
other
verticals,
which
is
quite
understandable
because
hardware
and
software
in
in
the
bigger
scale
of
things,
often
very
much
relate
to
each
other
and
and
there's
more
but
point
taken
and
that's
I
I
will.
I
have
to
cut
the
cue
here
to
be
honest,
because
otherwise
we
are
not
getting
to
the
actual
discussion
point
so
rudiger.
Where
are
you.
C
A
J
J
So
so
yes,
there
is
a
very
big
part
for
the
authorization
policy
that
can
be
fed.
Those
claims,
after
we
have
checked
that
they
are
signed
and
transparent,
but
we
try
to
put
that
out
of
scope
for
the
working
group
where
we
just
essentially
make
sure
we
can
automatically
provide
systematically
the
guarantee
that
the
claims
have
been
validated
and
registered
without
directly.
Looking
at
the
content,
which
is
interesting
but
much
more
open
and
complicated.
G
Not
to
worry,
I
have
it,
I
don't.
I
know
so
I'm
sorry
to
keep
pushing
on
this.
But
I
just
didn't
understand
your
answer.
Right,
like
I
looked
at
six
store
and
they
clearly
have
a
transparency
log
where
they
plan
to
and
there's
already
a
bt
vlog
at
google,
and
so
what
I'm
trying
to
just
like
what,
if
I
understand
is,
are
we
at
itf
proposing
to
standardize
something
that
will
be
in
competition
with
existing
working
bt
vlogs?
G
And
if
the
answer
is
yes,
then
I'm
concerned,
if
the
answer
is
no
because
they're
going
to
like
pick
up
whatever
this
is
then
fantastic,
so
like
I'm
in
favor
of
this
area
of
work,
but
I'm
trying
to
figure
out
where,
like
are
we
being
asked
to
spin
up
competitive
work
or
would
you
have
such
a
collaborative
work
and
it's
like
I'd
love
to
hear
from
like
them
actually?
But
if
I
hear
from
you
guys
I'll
start
right.
J
O
Okay,
so
this
is
roy
williams.
At
the
open
ss
mean
this
basically
came
up
the
the
people.
With
the
most
experienced
there
were
cloudflare
people
that
had
have
done
ct
logging
for
the
last
little
while
they
did
not
want
to
continue
down
this
experiment.
They
said
this
has
been
super
problematic
for
us,
and
we've
been
in
talks
with
them
to
see
what
we
could
do
to
improve
it.
O
P
Hi,
so
I
I'm
in
favor
of
this
work,
I
think
it's
it's
a
really
interesting
area
for
us
to
pursue
and
I
think
there's
some
real
gains
that
we
can
get
out
of
it
and
the
the
problem
that
I
have
so
far
is
that
I've
read
through
the
charter
and
all
of
it
seems
to
hint
at
some
very
specific
security
problems
that
that
we're
trying
to
fix
the
problem
is
those
aren't
written
down.
So
I've
got
a
problem
statement
that
has
no
specific
threats
listed.
P
J
If
you
can
look
at
the
draft
architecture
that
describes
the
motivation,
the
attacks
and
some
of
the
proposed
implementation
to
to
actually
achieve
those
properties,
so
I
think
the
architecture,
of
course,
is
just
a
starting
point,
but
but
I
think
it's
it's
already
workable
and
we
also
have
a
prototype
implementations
that
are
close
to
providing
those
guarantees
with
what
we
think
is
a
proper
security
model
for
them.
Okay,.
D
When
we
received
guidance
that
we
should
start
that
we
should
narrow
our
use
case
down
to
supply
chain,
but
that
was
really
from
you
know
the
the
the
ad
and
others
who
who
said
you
know
keep
keep
it
small
first.
So
all
I'm
just
gonna
say
is
please:
let's
not
penalize
the
the
people
who
are,
you
know,
designing
the
who
came
up
with
the
spec
for
the
narrow
focus.
That
was
really
the
ietf
own
goal.
If,
if
you
have
any
concerns.
A
R
Maybe
I
I'm
just
confused
so
hi.
This
is
hank,
so
I'm
going
to
talk
about
the
essence
of
this,
that's
which
we
boil
down
to
milestones,
which
of
course
are
too
abstract,
and
so
we
are
going
into
the
content
that
this
can
be
the
charter
at
some
point
and
that's
why
we
call
the
program
of
work
next
slide,
please.
R
So,
oh
I
have
a
monitor
here
so
yeah
brenton
said
the
obvious
thing:
where's,
the
threat
model
that's
going
to
be
a
hard
one,
because
we
have
to
first
understand
the
building
that
is
on
fire
and
then
now
we
have
to
understand
how
to
rescue
people
from
the
building
if
it
is
on
fire.
So
the
third
model
will
be
part
of
the
architecture
and
it
is
outlined
there
a
little
bit,
but
that
is
a
milestone.
R
R
I'm
going
there
later,
and
so
information
models
and
interaction
models
are
important,
of
course,
because
we
want
to
have
a
protocols,
and
this
has
to
interact
some
signs.
We
have
a
very
specific
one
in
cosy
right
now,
because
we
want
to
have
this
proof
that
this
happened.
People
were
telling
about
us.
This
transaction
really
happened.
The
statement
was
was
made
a
transparent
claim,
you've
heard
that
before
and
we
have
an
ongoing
cozy
independent
id.
That's
talking
about
these
additions
to
counter
signing,
especially
using
causes.
So
there's
something
happening
there.
R
You
can
look
at
it,
there's
something
tangible
here,
so
these
are
potential
milestones.
All
this
is
draft.
Everything
here
should
be
like
proposed
milestones
or
proposed
after
proposed
architecture,
because
this
is
above
okay.
I
think
I
hope
this
is
implied,
so
the
the
the
proposed
way
to
do
a
protocol
here,
of
course,
is
then
using
something
like
an
http
based
rest
api
and
then
request
response
is
just
one
interaction
model
right.
You
can
have
a
lot
of
these,
but
this
is
very
tangible.
R
Everybody
I
think,
gets
request
response,
so
these
are
potential
milestones
that
could
end
up
at
the
bottom
of
a
data
tracker,
but
now
go
into
the
details,
so
I
spoiled
it
all
now.
That's
that's
dissected.
A
little
bit
on
the
following
slides.
We
will
talk
about
a
server
called
program
of
work,
which
is,
I
think,
the
frame
in
which
we
will
allow
deliverables
and
milestones,
and
so
I
think
that
will
become
part
of
the
child
at
some
point.
R
If
we
go
to
chartering
and
again
there's
this
architectural
model,
that
was
talking
about
banks
and
issues
and
buyers
and
such
these
are
the
actors
and
they
somehow
interact
with
each
other.
This
has
to
be
written
down
somewhere.
It
is
not
necessary
to
build
a
system
that
functions
this
document
here,
this
architecture
model,
but
if
you
really
want
to
build
it
in
a
way
that
does
the
things
that
it's
intended
to
do
and
nothing
else,
I
think
you
really
need
the
definition
of
interactions.
R
Terminology,
therefore,
and
interactions
and
brenton's
point
of
view.
I
want
to
add
this
to
the
architecture,
a
threat
model
to
some
extent,
because
that
is
really
tied
into
the
information
model
in
the
action
mode
in
the
end
and
the
consister
actor
identification
is
key.
I
trust
a
transparency
ledger.
It
gives
me
a
transparent
claim
or
just
the
receipt
of
it.
R
That's
a
trust
relationship.
I
have
to
identify
the
issuer
of
this
contrast,
signature.
I
have
to
identify
the
issue
of
the
initial
statement
and
that
has
to
be
consistent.
That
has
to
be
consistent
all
over
the
supply
chain.
I
think
that
is
an
essential
part
of
all
of
this
and
I'm
going
into
much
details,
because
this
is
an
overlook
over
viewers
last
slide.
So
let's
go
to
the
next
ones,
because
I
would
go
deep
in
here
yeah.
R
So
essentially,
the
issue
is
key.
The
issuer
needs
a
low
threshold
way
to
make
a
statement.
It
can't
be
confusing.
I
must
be
working
my
app
if
I
take
a
photo
and
post
it
to
the
transparent
registry.
It
must
be
really
easy.
Click
done
send.
I
have
key
material
and
such
so.
The
issuer
is,
of
course,
not
always
me,
making
a
photo.
So
picture
didn't
happen.
It's
not
really
our
scenario
here,
but
sorry,
but
the
the
important
part
is
that
that
the
re-identification
is
a
a
very
hard
problem.
R
We
have
pkx,
we
have
other
things
in
out
in
the
world
that
might
last
longer
than
a
certificate
and
the
title
pkx-
and
I
heard
before
on
the
mic-
that
these
assertions
have
to
be
audible
for
a
long
long
time.
These
things
will
be,
I
don't
know,
embedded
in
a
in
a
highway
for
a
long
long
time.
You
can't
just
break
and
auto
update
them.
R
R
Yeah,
I
was
basically
I
was
talking
about
this
lofty
slide
again.
Re-Identification
of
all
the
parties
essential
way,
it
has
to
be
some
decisions
on
the
format,
some
decisions
on
how
to
manage
them
and
some
decisions
on
how
people
are
happy
with
it.
Are
you
happy
with
the
way
we
are
doing
this?
That's
working
group
work.
That's
why
this
slide
has
no
indication
of
whatsoever
what
we
want
to
do
here
with
the
actual
solution,
because
it's
just
consistent
actor
identification.
That's
the
problem
and
everybody
can
agree
on
this.
R
We
can
have
rough
consensus
on
this,
a
lot
of
things
on
the
table,
and
I
think
that
is
something
that
is
really
itf
working
good
work,
because
the
experts
are
here.
We
can
also
invite
others
experts
and
I
think
some
of
them
are
already
here.
So
I
think
this
is
a
very
inspiring
slide.
Therefore,
next
slide.
R
We
heard
about
notarization,
I'm
going
with
the
second
one.
First,
it's
like
a
real-life
notary.
It
does
nothing
else.
You
go
somewhere,
you
conduct
some
things
and
it's
getting
notarized
by
a
trusted
party.
So
these
skit
services.
However,
we
want
to
call
them
in
the
end
that
is
transparent,
regency,
a
registry
or
whatever
it's
also
a
logo,
but
a
derm
term.
R
R
R
I
don't
know
who
here
is
actually
an
auditor
and
has
tried
to
do
a
supply
chain
transition
from
one
authority
to
the
other,
but
it
is
a
legal
and
it
is
a
documentation
nightmare
and
we
can't
really
solve
the
legal
nightmare,
but
we
can
solve
the
audibility
and
the
accountability
nightmare
a
little
bit
for
them
and
on
a
technical
level.
Thank.
R
Two
more
slides
yeah.
I
have
one
minute
and
50
seconds:
go
ahead,
I'm
having
about
o'clock
there,
so
I've
been
already
talking
about
our
work
at
cosi,
and
so
I'm
very
encouraged
by
the
feedback
which
seems
to
be.
This
is
an
unobjectable
content
to
the
addition
to
the
cosy
realm
which
I'm
happy
to
hear
again.
We
are
not
inventing
new
wheels
here.
We
are
literally
adding
some
spikes
to
the
wheels,
so
it
gets
mounted
up
better.
R
R
And
this
is
the
one
I'm
I'm
I'm
not
absolutely
sure
about.
So
some
people
told
us
it's
okay
to
do
apis
in
the
itf.
I
was
a
little
bit
surprised
so
yeah.
We
can
do
some
protocol
binding
here,
because
you
would
have
to
find
things
in
there.
Query
response,
apparently
you'll
find
one
want
to
find
the
responsible
issue
of
one
feed
of
one
issue
of
software
and
then,
if
the
authority
really
changes
or
if
somebody
some
other
entity
is
endorsing
it,
you
also
find
that
want
to
find
that.
R
R
Then,
okay,
so
I
mean,
I
think
really
we
are.
We
are
coming
from
the
ietf
point
of
view.
Having
a
reference
protocol
helps
helps
understanding
what
the
operations
are
again
binds
it
all
together.
Information
model,
interaction,
model,
architectural
roles.
A
reference
protocol
would
really
help
you.
I
think,
and.
R
K
R
S
Maybe
this
is
not
the
right
time
for
this.
I'm
just
trying
to
put
this
into
context,
so
so
I'm
not
clear
how
you
become
a
notary
and,
and
whether
this
also
applies
to
open
source
software
as
well
as
you
know,
something
produced
by
a
for-profit
company.
All
right,
if
you
don't
know,
if
you
can
get
to
that
or
or
what.
R
R
This
is
cozy,
and
all
of
this
is
going
to
be
not
very
open
source,
but
also
very
code
reviewed,
and
this
does
not
stop
with
the
single
libraries
that
it
goes
on,
with
interoperability,
between
libraries
and
and
and
on
the
matrix
automatics
that
that
shows
you,
which
library
is
interoperable
with
which
in
your
supply
chain.
So
we
can
recommend
something
here
that
we
there's
a
hard
basis
for
for
decision
actually
and
then
a
reference
notary
is
planned
as
a
open
source
project.
Also,
so
so
you
can't
just
go
with
just
do
this.
R
Yes,
a
open
source
and
and
free
available
and
an
easy
licensable
framework
is
is,
is
on
the
roadmap
and
very
very
close,
and
we
can.
If
we
look
at
the,
I
think
it's
arms
go
cozy.
You
can
see
how
how
how
we
really
mean
this,
because
there
are
there's
a
report
folder
in
there.
That
includes
two
code
reviews
and
and
that's
the
basis
we
basically
achieved
as
aspire
to
to
be
really
reliable
on
the
ground.
The
grassroot
code
here.
J
B
J
So
now
the
more
it
is
open
source
and
the
more
there
is
reference
rotations
and
the
more
guarantees
you
can
provide,
such
as
running
with
they'll
get
replications
or
with
additional
independent
auditing
or
with
trusted
hardware.
The
more
transparency
will
be
on
the
more
likely
it
will
be
crazy
member
people,
but
we
don't
want
to
prescribe
that.
T
Regarding
the
scope,
I'd,
like
you
know,
I
see
a
lot
of
parallels
going
even
further
down
the
stack
than
just
software.
The
software
runs
on
a
machine.
You've
got
firmware,
you've
got
hardware,
and
I
see
this
applicable
not
just
just
the
software
supply
chain,
but
also
the
hardware
and
firmware
supply
chain.
So
I
think
I
would
like
to
see.
T
I
mean
I
think
this
is
a
great
solution
for
that.
We've
got
platform
certificates
out
there,
people
producing
basically
certificates.
That
said
that
machine
came
from
xyz
manufacturer.
We
don't
have
a
way
to
distribute
them
right
now.
I
think
this
is
a
phenomenal
way
to
get
that
as
well
as
reference
measurements
for
firmware,
and
things
like
that.
Firmware
is
really
just
software
and
the
platform
itself
kind
of
emphasizing.
This
is
also
comprised
of
many
components.
T
A
T
I
think
the
literal
wording
right
now,
someone
would
say
hardware,
you
know
shipping
a
safe
platform
certificate
describing
the
hardware
might
be
out
of
scope.
So
I
I
don't
think
it
requires
a
lot
of
tweaks.
Okay,
but
again
we
as
a
group
need
to
decide.
Is
that
in
scope
is?
Is
it
simply
the
software
that's
running
the
operating
system
above
or
does
it
also
include
the
stuff
below?
If
it's
not,
then
I
think
we
need
to
start
up
another
group
for
that.
D
U
T
Yeah
yeah,
so
I
agree:
there's
going
to
be
some
some
balance,
you
don't
want
to
lose
focus.
You
have
a
really
good
thing
to
do
here,
but
at
the
same
time
I
don't.
I
don't
want
to
reinvent
the
wheel
over
in
another
working
group
right.
So
you
know
if
we
can
make
it
general
enough.
That
would
be
great.
Then
we
could
just
tweak
it
a
little
bit
but
I'll
be
more
than
happy
to
participate
in
writing,
use
cases
and
and
and
helping
with
the
charter.
I
Thanks
thanks
monty
and
ellie
you,
since
you
invoked,
I
was
going
to
comment.
That's
what
hannis
and
I
we're
talking
about
here
up
front.
I
think
what
you're
observing
is
the
big
lesson
learned
from
the
first
buff,
which
was
there.
There
was
appreciation
around
the
use
case
of
kind
of
software,
but,
as
we
saw
a
number
of
other
entities
said,
but
wait.
I
This
in
fact
may
generalize
and
I
believe
that
the
finesse
that
occurred
on
the
mailing
list,
after
was
those
changes
to
the
charter,
which
say
we
are
absolutely
going
to
cover
software,
but
we're
writing
this
in
such
a
generic
way
that
this
is
probably
going
to
be
going
to
be
going
to
be
reasonable
for
a
lot
of
other
applications.
We
did
not
know
what
the
answer
was
for
all
of
the
next
use
cases,
and
so
that
perhaps
is
some
of
the
conversation
to
have
here.
I
M
Yeah
just
responding
to
that,
I
think
it's
a
terrible
idea
and
here's
why
software
is
completely
different
to
everything
else,
because
you've
got
a
massive
amount
of
installed
base,
and
if
you
want
to
do
anything
that
makes
any
sense
to
software
provenance,
you
have
git
and
you
have
software
signing
and
anything
that
you
do
has
to
bridge
between
the
two.
If
it's
going
to
be
of
any
use
now,
my
model
of
doing
this,
every
user
is
a
notary.
M
All
you
have
to
do
is
to
modify
git
slightly
so
that,
instead
of
just
putting
a
pgp
signature
in,
you
have
create
a
signature
that
is
enrolled
and
interlocked
to
the
individual
developers
personal
notary
chain,
and
then
that
notary
interlocks
with
every
other
through
a
bridge
eventually,
and
so
every
user
ends
up
being
their
own
route
of
trust
when
they're
evaluating
notary
claims,
so
the
notary
doesn't
need
to
be
a
trusted
party
in
this
system.
You
can
factor
out
that
trust.
M
You
can't
do
that.
If
you're
talking
about
supply
of
baked
beans,
you
can
do
it
for
software
and
then,
when
we
look
at
the,
how
do
you
go
to
code
signing
at
the
moment?
We
have
a
really
bad
model
for
code
signing
well,
every
vendor
seems
to
want
to
do
it
their
own
way
and
we
sign
software
distribution
packages,
not
the
code
that
runs
on
the
machine
and
we
only
do
the
final
code,
not
every
individual.
M
My
point
here
is
that
if
you
want
to
do
something
useful
in
software
supply
chain,
it
is
a
thing
of
itself
that
has
unique
advantages,
that
you
cannot
apply
to
supply
of
baked
beans,
routers
or
anything
else.
It's
got
to
be
considered
separately
and
you've
got
to
interface,
with
all
that
existing
legacy,
infrastructure
or
it'll
be
irrelevant.
A
Thanks,
philip,
in
response
to
that,
I
feel
I
think
what
what
I
hear
is
you
agree
that
there's
a
problem
and
you
you
you
just
phillips
shaking
his
head,
but
not
in
his
head.
Sorry,
and
I
think,
where
the
difference
lies
is
more
in
in
the
solution
space.
Of
course,
we
will
have
hopefully
plenty
of
time
to
discuss
different
solution
spaces.
A
I'm
sure
some
of
you
have
other
ideas
on
how
to
do
that
and
love
to
hear
more
about
that,
but
I
think
it
it
sort
of
like
we
are
not
there
yet
to
really
dig
into
the
the
solutions.
At
least
I'm
not
at
this
point,
but
it's
it's
definitely
something
that
we
should
talk
about
in
the
future
and
the
other
point
on
where
the
software
is
very
different.
A
From
hardware
point
taken
and-
and
it's
like
others,
obviously
like
monty
who
just
spoke
right
before
you
in
the
queue
thinks
differently
so
we'll
have
to
have
to
hash
this
out,
as
we
look
into
specific
use
cases,
which
is
also
part
of
the
architecture
in
terminology
document,
I
think
we
need
to
look
into
this
see
what
is
commonalities
where
the
differences
are
and
then
figure
this
out,
and
if
there's,
let's
assume,
there's
no
relationship
between
any
of
those.
Then
we
have
a
solution
for
software.
A
S
First,
this
is
a
it's
a
it's
an
inquiry,
it's
a
very,
very
important
problem
and
and
definitely
as
a
software
vendor,
I'm
very,
very
interested,
but
so
but
but
a
couple
of
clarifying
things
is
like
like,
like
the
question
of
who
is
a
notary,
and
how
do
I
say
who
a
notary
is
is
very
important.
It's
like
certificate
authorities
can
no
can
I
just
say
I
am
now
a
notary
and
I
will
sign
everything
I
will
attest.
S
I
mean
is
that
can
I
do
that
and
then,
like
now,
like
cas
are
like
you
have
to,
like
you
know
like
cas,
are
defined
in
the
os
and
and
stuff
like
that
and
java
store.
I
mean
there's
a
bunch
of
like
a
bunch
of
details
around
that
like.
How
is
that-
and
I
don't
know
I
is-
that
within
the
scope
of
the
work.
A
So,
and-
and
if
I
may
try
to
respond
to
that
in
general,
like
we
would
work
on
the
protocols
and
the
mechanisms
that
require
intra-mobility,
so
if
some
environment
says
like
everyone
can
do
their
role
their
own,
like
you
could
be
your
own
ca
like
as
I
do
for
testing
at
the
hackathon,
I
am
I'm
literally
setting
up
my
own
say.
Of
course
you
could
do
that
too.
Whether
that
would
be
then
in
a
specific
use
case
then
be
acceptable
to
the
other
parties.
A
V
A
S
S
And
another
thing
is
that
I'm
gonna
I'll
stop
talking
is
so
like.
Okay,
for
example,
like
we
have
software
that
uses
tomcat
and
then
does
commands
maybe
to
the
to
the
linux
os.
So
within
our
software,
do
we
need
signed
whatever
it
is
for
all
these
other
things
and
who
exactly
is
signing
them?
Is
it
linux
foundation
signing
on
behalf
of
linux
or
what.
A
So
that's
a
good
question
in
so
there's
pride,
there's
other
work
that
we
we
definitely
go
are
going
to
reuse
here.
This
is
the
whole
debate
about
software
bill
of
material
in
case
of
the
software,
where
there's
obviously
lots
of
work
on
on
figuring
out
on
who
signs
what?
How
does
this
work?
How
do
the
formats
look
like,
so
we
would
essentially
stand
on
the
shoulders
of
giant
here
who
have
done
years
of
work
on
that
space
already.
A
P
Okay,
there
I'm
I'm
sorry
to
bang
on
about
this
again
with
threat
models
and
and
to,
and
I'm
gonna
about
to
say
some
things
that
sound
like.
I
don't
support
this
work,
but
I
promise
I
do
support
this
work.
I
just
think
that
we
need
to
be
very
specific
about
what
we're
doing
and
I'm
worried
that
right
now
we're
not
so
I'll.
Give
you
a
couple
of
examples.
P
So
if
we
take
that
original
example
that
someone
brought
up
a
little
while
ago
about
taking
a
key,
that's
trusted
by
the
os
for
one
application
and
using
it
to
sign
another
I'd
like
to
know
how
we
see
this
solving
that
problem,
I
mean
there's
an
obvious
way
that
we
could
look
at
it.
And
that
means
you
know
when
you
go
to
install
a
piece
of
software.
You
have
to.
P
You
know,
trace
that
particular
software's
signer
back
through
the
log
and
see
if
it
changed
and
then
then
you
can
maybe
make
some
decision.
But
the
question
is:
do
you
really
need
that?
Or
can
you
just
look
at
what
the
trust
anchor
for
the
previous
key?
Was
you
know
that
you've
you
can
do
the
same
thing
based
on
your
own
history?
Then
the
only
gain
we
get
here
is
for
brand
new
installations.
P
So
is
that
a
goal
of
yeah
is
that
what
we're
trying
to
solve?
The
second
example
is
that
you
know
take
solar
winds,
for
example,
someone
breaks
into
a
build
server
and
they
legitimately
sign
a
piece
of
broken
code.
This
is,
you
know,
a
deliberate
attack
and
they
use
the
existing
signing
infrastructure
to
do
it.
So
now
I
have
to
go
back
again
and
say:
we've
got
supply
chain.
We've
got
a
software
bill
of
materials,
we've
got
signatures,
we've
got
notaries.
P
How
does
it
save
us
from
this
attack?
I
I
don't
understand
where
this
all
fits
in,
and
I
I
just
like
this
is
why
I'm
talking
about
threats
and
threat
models,
I
want
to
see
how
all
these
pieces
fit
together
so
that
I
can
understand
how
we're
solving
this
problem,
because
I'm
lost
right
now.
I
don't,
I
don't
quite
get
it.
A
A
B
D
K
K
V
So
all
right,
so
it
seems
to
me
that
software
is
different
from
real
world
artifacts
in
the
software.
You
want
to
be
immutable,
you
don't
want
it
changed,
whereas
if
I
buy
myself
my
kid
a
gaming
pc
and
he
wants
to
upgrade
his
video
card
and
then
maybe
sell
the
old
one
to
somebody
else,
how
do
you
handle
that?
The
other
thing
is,
I
want
to
know
on
the
software
side.
V
So
I'm
concerned
that
this
is,
you
know,
we're
trying
to
boil
the
ocean
and
merge
too
many
separate
things
here
and
that
instead
we're
going
to
end
up
with
you
know.
Nfts
is
the
only
thing
that
really
works,
so
I
think
it
needs
another.
I
think
it
needs
more
clarification
and
more
refinement.
I
think
the
generalization
is
a
really
bad
idea.
A
Yeah
yeah
yeah,
I
guess
dick
you're,
not
you
are
in
the
queue.
But
in
response
to
that,
I
think
we've
heard
on
the
mailing
list
and
now
here
that
some
people
are
pro
more
than
the
software
use
case
and
others
are
focused
on
the
software
use
case,
and
we
will
have
a
later
on
to
figure
out
like
where
you
guys
are
with
regards
to
that
question
in
general,
and
then
we
just
then
we
do
what
you
guys
want
dick
go
ahead.
N
N
There's
a
need
and
someone's
going
to
have
to
solve
this.
It
doesn't
exist
today
to
have
this
verification
function
so
that
a
consumer
can
go
out
and
check
that
information
and
establish
some
level
of
trustworthiness,
and
I
think
I
think
we
will
have
succeeded
if
we
can
get
some
greater
visibility
into
these
smart
grid,
app
stores,
which
collectively
are
the
largest
distribution
point
to
software
on
the
planet:
commercial
software.
J
J
I
would
like
to
emphasize
that
the
notary,
the
issues
the
counter
signatures,
that
that's
not
the
primary
asceron
clan,
so
the
whole
architecture
suppose,
is
that
issuers,
typically
software
providers
developers,
will
sign
their
artifacts
and
that's
a
primary
signature
and
there
will
be
a
held
accountable
for
that.
What
the
notary
provides
is
more
like
an
administrative
function.
We
are
not
going
to
accuse
the
notary
of
taking
over
the
world
they
just
take.
The
claims
look
check
that
they
look
again
superficially
then
put
that
into
the
registry,
and
that's
it.
J
So
that's
not
a
source
of
authority
like
a
ca.
The
the
notary
has
no
way
of
issuing
signed
claims
on
behalf
of
anyone
else
in
the
system.
Regarding
I
don't
it's
you.
I
don't
think
you
have
time
to
get
in
the
details,
but
there
is
an
interesting
thread
on
the
mailing
list
discussing
why
your
water
approaches
and
some
alternatives
to
it.
J
A
K
W
First
of
all,
I
need
to
say
I
in
favor
of
this
work,
but
my
concern
is
that
this
work
may
be
to
rely
upon
the
supply
chain
or
I
suggest,
recommend
using
the
word
supply
chain
as
less
as
possible,
because
actually
I
feel
this
work
shouldn't
be
bound
to
the
supply
chain,
for
example
the
supply
chain.
The
word
supply
chain
appears
30
23
times
in
the
chatter,
but
it
only
appears
21
times
in
the
architecture
draft,
which
is
our
26
page
draft.
W
W
For
example,
we
don't
we
don't
put
supply
chain
in
the
rats
working
group
names,
but
the
rats
remote
attestation
could
be
used
to
secure
the
supply
chain
in
in
certain
ways,
yeah
and
in
the
chatter
I
saw
in
the
goals,
it
says,
to
standardize
the
overall
security
flows
for
securing
the
supply
chain.
But
I
think
securing
the
supply
chain
involves
a
lot
of
non-technical
points
so
saying
this
may
be
too
broad
for
the
working
group.
A
That's
all.
Thank
you.
Thank
you.
Thanks
ray,
I
hear
you
making
a
couple
of
points
here.
The
I
think
it
would
help
the
group
if
you
could
propose
some
text
on
that
on
the
charter
to
use
maybe
terms
or
also
for
the
architecture
document,
to
use
terms
that
you
think
are
more
appropriate
in
in
places
where
supply
chain
is
maybe
used
too
often.
I
think
that
would
be
helpful.
A
M
A
V
O
Williams,
so
I
wanted
to
make
a
few
comments,
so
there's
been
a
lot
of
discussion
on
the
difference
between
the
software
and
the
hardware
use
cases
and
some
of
the
other
ones.
There
are
probably
a
half
a
dozen
to
a
dozen
that
we
know
of
of
use
cases
that
we
could
walk
through,
but
we
were
really
focusing
on
hey.
Let's
just
see
we
can
do
a
generic
one
to
fill
in
some
basic
building
blocks.
We
have
in
general
for
this
whole
problem
space.
O
Some
of
the
questions
on
how
do
I
set
myself
with
a
notary,
but
what
we're
trying
to
define
here
is
an
interface
for
implementers
to
implement
and
whether
there's
an
instance
you
can
install
on
your
in
your
own
network
or
there's
a
government
one
or
there's
an
industry
one.
Those
are
outside
the
reach
of
this
as
to
whether
big
companies
like
microsoft
or
google,
will
stand
up
on.
That's
still
too
far
in
the
future.
O
The
discussions
on
how
to
supply
a
secure
software
and
all
the
discussions
in
s-bombs
we
kind
of
take
out
of
the
here,
because
there's
already
other
groups
working
on
some
of
the
issues
to
deal
with
the
requests
from
the
us
government
around
s-bombs
in
microsoft's
case
we're
signing
our
our
s-bombs
and
putting
hashes
of
functions
and
and
talking
about
binding
keys.
That's
not
what
this
working
group
is
about.
This
is
about
building
blocks.
O
We
kind
of
need
transmit
those
things
around
when
we
talk
about
signatures
of
software,
microsoft
signs
every
single
binary
we
produce,
but
we
don't
sign
the
text
files
and
those
signatures
readily
expire
well
before
the
product
life
cycle
ever
exits,
and
that's
why
we
were
hoping
for
something
like
the
notary
to
to
transition
that
case.
If
you
want
to
see
how
microsoft
does
its
day,
you
can
read
through
the
athena
code,
specific
specification,
and
you
can
tell
we're
not
very
happy
with
where
the
some
of
the
directions
gone
in
there.
X
I'm
very
much
in
favor
of
this
two
years
ago.
I
pitched
a
bunch
of
presentations
to
the
tcg,
and
this
is
two
years
ago.
The
slides
are
still
up
in
the
tcga
website
for
those
have
access
to
it
and
I
kind
of
didn't
get
a
listening
because
of
many
reasons,
and
that
one
one
being
the
lack
of,
I
guess
software
providers
in
the
tcg.
X
So
it's
great
to
see
iitf
do
this
related
to
this.
I
was
involved.
I've
been
following
a
thing
called
gsa
ties
for
those
who
know
what
the
global
semiconductor
alliances
they're
doing
that
well,
they're
talking
about
the
same
thing
niche.
It
would
be
good
if
they
would
be
made
aware
of
this
work
because
they'll
probably
just
use
it.
So
that's
another
sort
of
audience
that
this
group
could
could
talk
to
using
a
different
hat.
So
on
tuesday
there
was
a
small
company
that
was
called
14
bis
that
is
doing
supply
chain
for
aircraft
components.
X
L
L
It's
a
very
complicated
solution
to
this
type
of
problem,
but
the
thing
that
I'm
trying
to
get
my
head
around
is
it
seems,
like
there's
a
lot
of
different
players
that
need
to
deploy
something
for
this
to
deploy
in
the
real
world,
and
it's
not
obvious
to
me
what
the
incentives
for
each
of
them
are
to
deploy,
and
I'm
not
saying
there
isn't.
I'm
just
saying
it's
not
obvious
to
me,
like
I'm
having
my
hard
time
getting
around
that.
So
if
anyone
could
sort
of
speak
to
like
look,
these
are
the
different
actors.
L
We
need
to
successfully
deploy
a
complete
solution,
even
though
the
itf's
only
doing
a
small
part
of
it,
and
these
are
the
type
of
companies
or
operators
that
would
do
any
of
those.
I
think
that
would
really
help
me
better
understand
the
the
likelihood
of
not
us
successfully.
Writing
some
rfcs,
but
those
successfully
being
used
in
the
real
world.
Y
D
D
Yeah,
which,
let
me,
let
me,
try
and
restate
it
in
this
way.
First
of
all,
who
are
the
minimum
number
of
players
for
for
this
for
this
architecture
to
succeed,
because
cullen
is
basically
saying
you
know
it's
very
complex,
there
are
a
lot
of
players.
It
seems
to
me
that
the
minimum
number
of
players
is
really
three.
D
F
Yeah
I
can
mike
perrock
here.
I
can
talk
to
this
a
little
bit.
You
know
working
in
different
aspects
of
this
and
we're
primarily
looking
at
this
from
you
know:
validation
of
supply
chains,
around
machine
learning
and
machine
learning
assets,
and
I
think
the
three
is
kind
of
the
simplest
construct
right.
You've
got
someone
who's,
creating
some
kind
of
software
that
says
yup.
This
is
me,
here's
the
stuff
I
produce.
Let's
get
a
signature
on
this
right.
F
You've
ultimately
been
getting
that
at
the
notary
level
right
this
third
party,
that's
recording
that
log
putting
it
in
on
you
know
some
kind
of
a
notary
style
ledger
right,
that's
append
only,
and
then
you
have
this
consumer
side
right.
I'm
going
to
go!
Look
at
this
and
decide
do
I
trust
that
notary
do.
I
trust
the
people
that
were
making
claims
about
it,
and
this
is
extremely
in
line
with
the
kinds
of
software
deployment
stuff.
F
F
It's
just
simplifying
it
and
allowing
for
automated
checks
around
this
stuff,
and
if
we
could
do
that
in
a
standardized
way,
it
would
be
extremely
helpful
across
the
board
for
a
lot
of
different
problems,
but
focusing
on
the
software
side
as
a
starting
place
is
good.
It's
clean!
It's
easy!
You
know
nothing
is
easy
around
this,
but
it's
it's
the
easiest
of
the
ways
we
can
go
tackle.
This
problem.
L
Y
I
mean
if
it's
helpful
for
microsoft,
we're
planning
to
be
involved
in
a
number
of
ways,
so
we
will
be
providing
information
about
initially
our
software
that
we
make
available
to
the
public
for
consumption
through
a
service
such
as
this
we're
also
looking
at
beyond
software.
We
were
listed
just
on
the
software
side
earlier,
but
we're
looking
at
this
much
broader
than
software,
we're
looking
at
it
also
for
our
hardware
products.
Y
Another
way
that
we're
looking
at
it
is
as
a
consumer
of
information
from
others.
So
we
want
to
be
able
to
gate
the
software
and
the
hardware
that
comes
to
us
and
we're
looking
at
this
as
a
solution
where
others
can
provide
information
that
that
we
consume
so
we'll
share
with
others,
we'll
request
from
others
and
then
we'll
also
provide
services
where
you
know
both
microsoft
can
use
and
others
can
use
to
stand
up
their
own
notary
services.
A
Z
Z
I
think
for
some
use
cases
that
transparency
kind
of
thing
is
totally
useless,
that
specifically
for
internal
enterprise
registries,
it's
a
waste
of
time
and
money,
and
I
would
claim
that
even
in
the
big
real
world
certificate,
transparency
has
not
been
such
a
wonderful
success
as
opposed
to
hey.
Google
just
has
a
copy
of
each
of
the
you
know,
issued
certificates.
A
U
Hi,
yes,
I
just
wanted
to
quickly
respond
to
yaran's
comment.
I
do
believe
the
the
contacts
or
the
contents
of
the
proposed
charter
and
the
documents
that
I've
seen
are
written
in
such
a
way
to
allow
that
separation.
So
you
could,
for
example,
deploy
something
that
was
not
like
fully
transparent
for
some
definition,
fully
transparent
with
all
the
backing
history
and
everything.
U
Was
this
thing
called
code
verify
with
meta
or
whatsapp,
and
but
there's
a
natural
progression
of
that
work
to
something
like
skit,
especially
six
door?
Slash
whatever
this,
you
know,
the
unification
or
convergence
of
these
things
happens
to
be,
but
I'm
interested
in
experimenting
with
what
is
the
successor
to
this
initial
initial
thing
for
transparency-like
solutions
on
the
web.
AA
Hey
or
ori
steele
from
transmute,
I
just
wanted
to
say
you
know
we're
planning
to
implement
a
version
of
this
and
we're
interested
in
both
both
sides
from
the
slide
earlier,
so
cyber
physical
supply
chains,
you
know
software
supply
chain,
physical
supply
chain
use
cases.
I
believe
I
agree
with
a
lot
of
the
framing.
Q
R
R
Who
wants
to
do
this?
There
was
a
list,
so
I
mean
hannes
projected
that
he
made
a
call
on
the
list
who
wants
to
do
this
and
there
in
the
first
day,
eight
people
said
yeah,
so
maybe
maybe
that
that
helps
a
little
bit
to
reduce
the
concern
here
that
people
do
not
want
to
do
this
because
I
heard
microsoft
wants
to
do
it,
but
that's
nice
there
were.
There
are
others
like
a
lot
of
others,
so
maybe
that
helps
yeah
yeah.
Here
we.
K
Q
Q
A
S
Delaney
elkins,
so
now
first,
don't
get
me
wrong.
I
totally
support
this,
but
but
we're
an
independent
software
vendor
and
we
have
to
do
this,
and
so
I'm
just
trying
to
figure
out
how
to
do
it
and
one
of
the
things
it's
like.
It's
great
you've
got
people
who
want
to
do
it,
but
a
lot
of
the
problem
is
going
to
be
with
the
weakest
link.
Is
the
people
who
don't
do
it
and
then
that
that
software
gets
embedded
the
way
my
customers
deal
with
it
today?
S
A
At
this
stage
we
are
mostly
concerned
about.
Do
you
agree
that
there
is
a
problem?
Do
we
need
to
solve
that
problem,
and
is
this
the
right
place
to
solve
the
problem
and
to
work
on
a
solution
like
how
the
exact
solution
looks
like
and
who
then
based
like?
Obviously,
you
can
shape
a
solution
in
many
different
ways,
so
that
the
responsibilities
shift
around
that's
something
for
the
a
future
group,
not
like
not
at
this
stage
yet
because
we
don't
know
exactly
how
the
solution
would
look
like.
A
A
D
AB
K
D
I
P
AB
A
AB
Have
a
similar
concern
in
that
there
are
lots
of
different
problems
in
this
space
that
we
can
solve
and
lots
of
different
ways
to
solve
them.
I'm
not
quite
sure
exactly
how
the
notary
fits
in
those
k
in
which
ones
we're
going
to
solve,
with
notary
how
it
fits
in.
Like
I'm
missing
that
bigger
picture-
and
maybe
I
have
not-
you
know-
been
involved
in
enough
of
the
discussions
to
see
that.
But
that's
my
concern
right
now.
R
R
A
D
Just
one
point
of
information
somebody
put
in
the
chat
that
the
results
of
the
polls
don't
show
up
in
the
recording,
so
I'm
just
going
to
announce
them
here,
ray's
hand
for
do
you.
The
question
was:
do
you
think
the
revised
problem
statement
is
clear,
ray's
hand
was
56,
people
do
not
raise
hand
was
13,
people
and
participants
were
69.
N
N
N
So
what
I
think
this
group
is
doing
is
giving
us
the
avenue
or
the
at
least
the
guys,
like
microsoft,
who
are
going
to
host
the
registries
and
and
people
like
rea,
which
are
very
small
company
by
the
way
we're
committing
to,
but
we'll
do
it
from
the
consumer
side,
we'll
query
microsoft,
we'll
give
them
here's
the
sha-256
key
hash
and
here's
the
key
identifier
tell
me
if
it's
trustworthy,
that's
what
I
hope
to
see.
Okay,.
AC
I
raised
my
hand
that
I
think
it's
clear,
but
I
think
then
brendan
asked
a
good
question.
I
think
the
part
that's
relevant
to
I
think
the
ad
and
knowing
how
to
go
forward
is.
Is
it
clear
enough
that
the
others
is
the
threats
that
brennan
is
asking
for?
Is
it
okay
for
those
to
go
into
say,
work
of
the
working
group
to
say
put
it
in
the
architecture
document
or
is
it
something
that
needs
to
be
known
enough
in
the
charter
text?
Okay,
that's
relevant
to
the
buff.
AC
Okay,
I
raised
my
hand
saying
I
think
it's
clear
enough
that
I
think
cedric's
presentation
talked
about
enough
that
I
think
putting
it
into
the
architecture.
Document
is
sufficient
for
me,
but
I
just
want
to
clarify.
That's
really
the
question
the
working
group
and
what
I
think
our
ad
would
probably
want
to
know
is:
does
this
something
that
affects
the
charter
and
the
scope,
or
is
this
something?
That's
just
worked
for
the
working
group.
A
A
B
D
D
I
A
F
Might
be,
would
you
still
participate
and
engage
and
think
the
work
is
important,
even
if
it
was
only
limited
to
software,
because
there
are
plenty
of
us
working
across
multiple
aspects
of
supply
chain
that
still
feel
that
it's
very
important.
This
work
moves
forward,
regardless
of
how
it's
scoped
initially.
AD
AD
AD
I
All
right
we're
going
to
run
out
of
time.
If
I
let
everyone
kind
of
speak,
we're
primarily
using
this
to
catch
some
early
feedback.
I
apologize
we're
going
to
kind
of
cut
it
because
I
want
to
get
the
next
question.
So
we
get
a
positive
result
from
the
buff,
so
we're
going
to
kind
of
say
we'll
keep
the
queue
as
it
is.
If
you
can
kind
of
come
back
after
we
run
the
questions
thanks.
I
I
D
D
D
A
A
C
D
I
D
K
D
All
right
on
that
question
the
there
were
61
people
who
did
raise
their
hand.
There
are
nine
people
who
did
not
raise
their
hand
and
just
a
reminder
for
people
who
are
new
to
the
ietf
that
we
confirm
things
on
mailing
lists
and
in
particular
I
would
suggest
that
the
nine
people
who
did
not
raise
their
hands,
who
had
concerns
should
definitely
raise
those
on
the
mailing
list.
I
I
think
it
does
from
what
I
need.
I
mean
what
it
looks
like
we
have
here
in
the
room
is
consensus
to
go
with
the
charter.
We
have,
I
do
recognize
we
we
had
some
folks
that
did
not
support
the
charter.
I
don't
know
whether
it's
outright
or
in
the
form
it
has
given
kind
of
where,
where
we
are
with
the
clock
we
can
actually
collect.
I
I
mean
I
I
do
welcome
those
folks
to
come
to
the
mic,
but
I
think
we
are
going
to
have
to
come
to
the
mailing
list,
because
there
may
be
an
opportunity
just
to
refine
it
a
little
bit
more,
but
in
broad
strokes.
I
think
we
have
something
to
move
forward
with
with
the
working
group
but
again
to
the
mic.
If
you
are
one
of
those
kind
of
nine
nine
folks
or
perhaps
you
didn't
participate
at
all
that
want
to
see
a
particular
refinement
thanks.
I
So
then,
I
would
also
say
there
were
some
folks
in
the
mic
line,
how
we
were
trying
to
finesse
these
questions
that
we
turned
away
just
so
we
can
continue
kind
of
pushing
for
that
to
fit
inside
the
time
if
there
is,
if
there's
anyone
that
wants
to
kind
of
return
back
to
the
mic
as
well.
To
make
that
comment
now
is
the
time.
I
Yeah
great
point,
so
my
next
process,
given
what
I
heard,
which
again
I'll
repeat,
is
it
looks
like
a
strong
consensus
in
this
room
to
move
forward
with
the
charter
we
have
in
this
forum
is,
I
would
return
back
to
the
mailing
list.
We
have
quite
a
lot
of
activity
there,
so
it's
actually
really
nice
to
see
that
healthy
discussion
already.
I
I
would
drop
the
text
we
have
here
with
the
reminder
that
of
the
results
here
about
the
level
of
interest,
who's
kind
of
what
is
interested
in
working
on
what-
and
I
would
give
it
a
little
time
to
collect
more
feedback
so
probably
next
week
after
we
all
successfully
travel
home
with
no
incidents.
Of
course,
I
would
probably
give
it
around
a
two
week
call
to
see
what
we
collect
and
whether
that's
going
to
be
an
opportunity
to
refine
the
text.
We
have
in
some
way
or
kind
of
change.
I
AE
Hi
stu
card
critical
technologies
with
sedate,
again
stu
card
critical
technologies,
a
potential
place
to
draw
the
circle
that's
somewhere
in
between
software,
only
which
is
still
enough
to
be
interesting
and
arbitrary.
Things
like
qr
codes
on
parts
trays
in
a
factory
might
be
things
that
can
run
software,
including
participation
in
cryptographic,
network
protocols
and
that
at
least
occasionally
have
network
connectivity.
B
M
Yeah
my
problem
with
doing
software
as
an
example
of
something
is
that
it
is
not
a
good
example
of
parts
so,
for
example,
take
github.
We've
got
a
microsoft
person
here,
say:
github
just
started
a
notary
and
automatically
through
the
apex
of
everybody's
git,
commits
into
a
notary
chain
like
transparent,
and
we
do
a
merkle
tree
over
it.
M
If
you
have
that
people
can
then
throw
ais
at
it
and
can
analyze
that
data
and
can
come
out
with
you
know
really
useful
stuff
on
current
risks
today,
even
if
nobody
else
deploys,
and
so
when
I
start
to
look
at
the
problem
of
software,
there's
so
many
low-hanging
fruit
that
you
can
get
that
don't
apply
to
anything
else,
and
so
that's
the
reason
that
I'm
kind
of
like
yeah.
I
think
that
we
should
do
software,
but
I
don't
want
to
be
coming
along
here
with
a
solution
that
is
good
for
software.