►
From YouTube: IETF-SCITT-20230130-1600
Description
SCITT meeting session at IETF
2023/01/30 1600
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
A
A
E
E
A
E
E
A
A
So,
let's
do
a
quick
John
is
here
as
well:
hey
John!
Let's
do
it
quick
agenda
patch
to
collect
what
we
skipped
last
week
and
what
you
did
work
wise
in
the
in
the
meanwhile.
So
in
use
case,
I
want
to
talk
about
use
cases.
What
what
is
you
you
had
sent
me
a
pointer
to
the
thread
document
which
you
had
started
already?
Do
you
want
to
talk
about
that
too?.
A
A
F
Yeah
hi:
this
is
Hank
I'm,
sorry
for
being
late,
also
for
being
on
vacation.
So
that's
that's.
Why
I'm
late
yeah
I
do
prefer
some
dinner
for
my
kids,
so
I
think.
Last
week
we
Consolidated
the
use
case
from
dick.
This
is
number
one
and
we
did
this
with
yogesh
so
that
we
can
he'd
proposed
some
simplifications
and
and
some
reverting
and
I.
F
So
I
think
these
are
I'm,
not
sure
where
these
are
to
be
honest
because
I'm
literally
on
vacation,
but
but
but
I,
think
that's
the
the
status
quo.
So
we
did
a
lot
of
updates
and,
yes,
I,
think
dick
knows
a
little
bit
more
about
how
how
this
worked
out
with
his
first
use
case
and
the
second
one.
Okay,.
A
B
You
harness
yeah,
we
just
we
did
exactly
that.
We
went
through
the
materials
there's
Hank
indicated.
There
was
just
one
dangling
open
item
that
we
need
to
address:
there's
an
emphasis
on
the
distributor
that
makes
it
look
like
there's
a
hard
link
between
the
supplier
and
the
distributor
and
and
we
need
to.
We
need
to
address
that.
That's
still,
so
that's
still
an
open
issue.
You
know
what
I'm
referring
to
right
hand.
F
B
Yeah
that
that's
the
that's
the
third
use
case
that
I
I
had
put
onto
the
list
as
a
proposal
but
I'm
referring
to
the
work
that
we
still
have
with
the
first
use
case,
where
we
have
an
emphasis
on
distributor
and
and
the
in
the
original
concept
was
the
the
trust
relationship
between
the
supplier
and
the
signer.
And
then
somehow
the
distributor
came
into
that
mix
as
well.
So
we
just
need
to
resolve
those
those
Concepts
thank.
A
F
Yeah
but
exactly
we
do
that,
and
so
the
distributor
was
introduced
by
OSHA.
We
accepted
that
with
a
comment
of
let's
go
with
this
first
and
now
it's
becoming
more
roles,
I
assume,
so
that
that's
the
point
so
distributor
signing
Authority
and
the
package
manager
might
be
different
entities
and
we
can't
just
Clump
them.
I
think
that
was
the
current
understanding.
But
let
me
just
shut
up
for
now
and
let's
talk.
E
Yeah
just
wanted
to
highlight
Joshua
you
had
made
an
excellent
points
on
your
email
thread
and
I
hope
you
might
have
seen
my
email
that
we
are
very
welcome
for
you
to
also
add
contribute
to
PR,
basing
this
PR
or
anything
sub
use
cases.
You
I
thought
of
you
put
forward
a
cessation.
We
are
welcome
to
that
as
well.
E
Okay,
sure
so
so,
normally
the
other
use
case
documents,
if
you
see
in
rats
or
any
other
use
case
documents
in
ITF,
is
that
they
are
centered
around
different
Industries
like
if
you
take
rats
document
you.
They
talk
about
use
case
for
Network,
endpoint
assessment,
machine
learning
model,
but
in
in
our
case
it's
software
supply
chain
and
all
our
software
use
cases.
So
these
these
try
to
highlight
different
aspects
of
software,
Distribution,
Systems
and
use
cases
which
kind
of
highlight
different
set
of
problems.
E
So
this
is
at
a
high
level,
but
I'm
open
to
a
feedback
to
understand.
If
anybody
wants
to
see
more
specific
instance
of
a
more
concrete
use
case
then,
but
we,
the
the
only
side
effect
or
downside
of
this
is
it
gives
the
document
growing,
because
everybody
is
quite
keen
on
adding
set
of
problems
which
manifest
as
a
use
case,
from
a
different
domain
or
direction
from
the
software
side
of
things,
and
it
is
letting
the
document
kind
of
increase
in
size
which
is
fine.
E
For
now
we
can
maybe
address
it
as
a
software
document
reduction
activity
where
we
consolidate
later.
But
this
is
the
kind
of
making
it
more
readable,
General
and
tidying
up
the
work
which
Hank
and
Dick
and
others
have
done
in
my
absence
in
when
I
was
in
sabbatical
in
December,
so
so
I
I,
basically
yeah
sorry,
go
ahead.
Any
questions
here,
I
can't
see
the
chat,
queue
or
something
so.
A
E
Yeah,
it's
almost
quite
a
bit
of
rewrite
so
so
the
first
use
case
is
the
use
case
which
Dick
had
come
up
with.
Where
there
is
a
there
are
effectively
three
entities,
one
is
the
package
supplier
or
the
package
producer.
One
is
the
signing
Authority
and
then
one
is
the
distribution
entity
which
is
Distributing
it
most
cases.
The
distribution
entity
and
the
signing
Authority
are
most
in
most
cases
same,
but
we
have
tried
to
kind
of
portray
this
use
case
as
a
verifiable
authenticity
in
software
Distribution
Systems.
B
Yeah
you'll
guess
that
that's
definitely
I
mean
certainly
what
you
described
is
occurring.
The
Distributors
are
signing
that's
very
true
in
cases
of
the
app
stores,
for
example,
but
there
are
many
cases
where
that's
not
true.
One
classic
case
we
see
is
with
systems
integrators
price.
Cooper's
Waterhouse
is
a
good
example.
They
go
into
an
environment
and
they
provide
a
set
of
software
packages
as
part
of
an
overall
solution.
They're
delivering.
A
A
A
B
F
A
B
Can
hear
you?
Okay,
thank
you
so
so
the
system's
integrator
in
this
case
is
price.
Cooper
is
they're
the
distributor
of
the
software,
which
includes
a
set
of
packages
that
they're
delivering
this
happens
quite
frequently
in
the
federal
government,
where
they'll
come
in
and
distribute
software
as
part
of
a
solution,
so
they're
not
signing
the
software
each
package
that
they
deliver
has
its
own
signature
and
supplier.
B
F
A
G
A
F
C
B
Correct
that's
correct
Roy
yeah.
We
we
identified
three
roles
involved
in
the
transaction
as
the
software
supplier
who
produces
the
code,
the
package
that's
being
used,
you
know
by
the
end
user
is
the
signing
entity
that
has
been
authorized
to
sign
that
package
by
the
supplier,
and
then
there
is
one
or
more
different
distributors
of
that
software
that
can
be
made
available
by
different
parties.
You
can
get
it
on
the
Microsoft
store.
You
can
get
it
on
GitHub.
B
C
B
B
C
A
G
I,
thank
you.
I
didn't
quite
hear
my
name,
so
thank
you.
I
I
guess.
One
of
the
questions
I
mean
first
of
all,
I
want
to
note
that
this
notion
of
a
distributor
is
of
course
very
well
entrenched
in
the
Linux
operating
system,
new
Linux
world,
where
there
are
packages
and
they're
distributed
by
Distributors
and
there's
many
different
distributors
for
the
same
set
of
packages
and
I
I,
guess
the
question
that
I
would
have
that
I
that
I
keep
having
when
I
hear
This
this
term.
G
Trust
relationship
is
how
is
a
verifying
party
going
to
know
which
signing
authorities
that's
kind
of
an
odd
term.
To
me,
signing
entities
are
authorized
to
sign
for
a
particular
software
supplier,
because
I
can
imagine
a
supplier
needing
to
use
a
different
signer
to
go
through
a
different
distributor.
So
it
certainly
seems
like
many
to
many
relationship
and
unless
we
have
a
very
well-defined
authorization
defined
for
that,
then
how
am
I
gonna
distinguish
those.
E
E
Okay,
so
the
exactly
that
point
we're
trying
to
highlight
is
to
understand
and
verify
that
an
actual
relationship
link
exists
between
the
supplier
of
a
certain
software
component
package
and
the
authorized
signing
Authority
that
signs
the
package.
So
for
the
consumer
of
a
release,
software,
it
wants
to
know
what
relationship
exists
and
that's
what
we
are
trying
to
highlight
as
a
use
case
where
we
want
to
have
that.
So
so,
basically,.
E
E
E
G
I
I
guess
I'd,
like
some
more
clarification
on
why
the
supplier
can't
sign
it
themselves
and
it
as
soon
as
you
get
into
this
kind
of
Delegation
of
signatures,
you
get
into
a
whole
realm
of
policy
languages
that
I've
heard
groups
struggle
about
for
years
about
you
know.
Well
what
are
they
authorized
to
sign
on
my
behalf
like
why?
Why
can't
they?
Why
can't
the
supplier
sign
themselves?
G
C
Well,
I
I'll!
Let
me
take
a
whack
at
this
please
so
the
EO
or
the
executive
order
of
the
U.S
believes
that
self
claims
is
maybe
a
good
start.
So
they've
asked
for
the
ability
of
third
grade.
Let's
get
back
to
that
in
a
second
third
parties
to
be
able
to
do
equal
amounts
of
endorsements
against
the
product.
C
So
if
the
self-endorsement
from
the
producer
is
one
thing
but
having
third
parties
be
able
to
endorse,
is
the
other
concept
they're
bringing
into
this
whole
mess
in
the
case
of
whose
third-party
endorsements
you
trust,
is
a
question
of?
Is
it
done
by
your
corporate
entities?
Your
group
policy
through
your
company?
Is
it
done
through
the
the
store
geolocation,
which
is
Dick's
case?
C
Where
he's
talking
about
hey,
there's,
a
a
green
check
mark
shows
up
on
the
store
and
those
are
the
vetted
set
of
in
of
Auditors
that
are
tasked
with
giving
you
a
a
and
I
guess
in
his
terminology,
trust
score
to
say:
hey
is
this
thing,
okay
for
you
to
use
as
a
personal
person
that
doesn't
work
for
corporations
or
it
doesn't
work
for
governments
or
so
forth?
Whole
concept
of
taking
it
past
self-endorsement
to
third-party
endorsements,
is
exactly
what's
being
driven
to
us
by
the
government.
G
Because
I,
we
certainly
need
to
be
able
to
allow
for
Auditors
to
sign
statements
of
some
sort
and
we
need
to
be
able
to.
But
but
what
I'm
hearing
is
that
a
distinction
between
a
supplier
which
I
forgive
me,
you
know
I?
Obviously,
no
I
haven't
caught
up
in
a
little
while,
but
I
I,
think
of
a
supplier
as
being
the
entity
that
actually
did
the
work.
G
So
why
would
you
know
assigning
Authority
some
impression
that
signing
is
something
magic,
I,
think
all
the
things
we
want
to
deal
with
are
going
to
be
either
a
statement
that
I
produce
this,
which
is
just
you
know,
an
authorship
sort
of
thing
or
a
statement
that
I
produced
an
opinion
about
something
I
I,
don't
know
it's
there's
other
exciting.
Authority
is
a
little
opaque
to
me.
C
The
Aggregates
Sign
Authority
to
the
difference
the
difference
of
the
role
of
the
producer
is,
he
doesn't
only
just
produce
a
claim
that
he
thinks
a
software
is
made
some
bar.
He
also
is
responsible
for
producing
evidence
that
the
Auditors
get
to
look
at
to
make
their
own
determination,
so
they're
not
making
claims
for
for
evidence,
they're
making
claims.
A
H
I
I
feel,
like
we've
gotten
a
little
off
here
in
the
sense
that
we've
gotten
into
the
solutioning
side,
which,
while
it
is
absolutely
critical
and
important,
you
know
the
topic
at
hand
is,
are
we
capturing
the
use
cases
properly
or
not
and
I
think
keeping
the
use
cases
Simple
and
Clean
into
the
three
roles
as
long
as
we're
describing
that?
Well,
that's
good
and
let's
roll
forward
and
I
think,
as
was
called
out
by
Yo
Dash.
H
This
implies
that
if
we
are
describing
one
of
these
things,
then
yes,
as
we
get
into
PRS
and
discussion
in
detail
on
how
we
are
handling
this
in
the
architecture
and
related
actual
RFC,
you
know
potential
rfcs
and
IDs.
That's
where
we're
actually
going
to
get
into
the
actual
solutioning
side.
Because
to
me
the
bigger
question
is:
is:
do
we
have
the
roles
properly
captured?
Do
we
have
the
core
use
cases
captured
and
this
PR
definitely
takes
us
that
direction?
A
F
I
Thanks
guys,
so
this
is
Charlie
hurt,
I,
I,
guess
I
am
scratching
my
head
a
little
bit
about
why
A
supplier
is
not
just
as
good
of
an
entity
for
providing
evidence
as
an
auditor
or
anybody
else.
If
I'm
A
supplier
I
may
there's
a
lot
of
different
use.
Cases
here
down
the
road,
but
for
software,
for
example,
I
might
want
to
say
that
I
have
complied
with
a
bunch
of
standards
and
provide
evidence
about
those
standards,
and
that
is
those
are
factual.
I
I
At
this
point
and
I
think
that
you
know
almost
anyone
who
is
entering
information
into
the
skit,
let's
get
instance
should
have
the
authority
of
you
know
that
is
sort
of
granted
to
them
by
the
role
and
the
supplier
role
is
one
of
the
most
important
roles
and
they
should
have
full
authority
to
put
in
whatever
they
want
on
their
own.
You
know
with
their
own
faith
and
credit.
I
E
B
Thank
you
harness
so
I
I'd,
just
like
to
say
that
I
think
Michael
pororock
got
exactly
right,
that
there
are
three
roles,
but
it's
important
to
note
that
you
know
enroll.
Each
role
can
be
served
by
the
same
entity.
We
we
see
this
a
lot
with
Microsoft
Microsoft
is
the
is
the
supplier
they
have
a
signer
and
they're
the
distributor
they
serve
in
all
three
roles.
B
So
we
need
to
just
be
clear
that
the
roles
exist,
but
they
can
be
served
by
one
or
more
entities
sitting
in
those
roles,
so
so
I
think
having
the
semantics
clear,
and
you
know
making
clear
that
we
when
we
say
supplier
we
mean
the
party
that
produces
the
software
and
not
the
party
that
is
actually
Distributing.
The
software
I
think
these
are
the
kind
of
semantics
we
need
to
make
clear,
and
the
last
thing
I
want
to
say
is
we
talked
about
well?
B
So
if
an
entry
is
in
the
registry,
they
can
assume
that
someone
up
Upstream
has
done
the
work
to
do
the
verifications,
whether
that's
the
you
know,
the
notary,
whoever
that
is.
But
the
point
is
that
there's
going
to
have
to
be
a
process
somewhere
and
someone
has
to
perform
that
process
to
do
those
validations
and
verifications
before
placing
an
entry
into
the
registry.
B
So
the
consumer
answers
the
question
by
saying:
is
there
something
in
the
registry
declaring
the
trust
and
if
there
is,
they
can
assume
that
someone
did
the
work
in
a
trustworthy
but
somewhere
up
the
line?
Someone
has
to
have
done
that
work
and,
and
that
part
I
think
is
somewhere
in
in
the
skit
the
sausage
making
process
where
we
go
through
that.
Thank
you.
F
Yeah,
so
I
want
to
address
Charlie's
very,
very
comment.
Of
course
the
supplier
is
the
first
entity
in
charge
and
they
should
State
as
many
things
they
believe
in
and
Trust
in,
and
they
are
pretty
assured
that
it
was
confident
that
they
did
it
SSA
science
statement
first
party
educationist,
is
calling
them
that's
coming
from
you.
So
now.
F
Yeah
actually,
first
party
education
in
this.
This
is
called
that
way.
So
that's
all
that
evidence.
That's
that's!
That's
just
how
you
you
what
you
would
think
you
can
prove
that
should
be
your
obligation
to
put
on
here
now.
Some
of
these
first
party
attestations
involve
like
I'm
using
this
as
an
example,
a
secure
element,
fips
certification-
you
got
that
from
something
then
can
that
can
do
these
trips
certification?
That's
a
third
party.
F
You
can
State,
you
did
that
in
a
Phipps
conformant,
but
you
can
also
put
the
flip
statement
which
is
coming
from
a
third
party
or
make
them
put
it
on
the
register.
That
is
a
third
party
attestation
that
is
either
relayed
by
you.
So
you
sign
something
that
is
already
signed.
It
says
that
you
did
it
or
the
third
party
attestation
happens
by
the
third
party.
F
If
you're
looking
at
the
near
very
near-term
future,
certain
parties
will
make
these
statements
so
they're
they're,
pretty
much
would
offload
some
of
the
duty
of
Distributing
them
and
so
so
I
think
some
of
what
you're
saying
about
your
product
is
just
up
to
you.
Some
of
the
things
that
you
are
about
your
product
are
things
you
paid
other
people
to
certify
and
you
are
stating
it,
which
is
an
indirect
third
party
at
a
station.
I
hope,
that's
that's.
How
I
think
that
that
is
I'm
sitting
with
fact,
I'm.
I
Yep
and
then
just
do
it
real,
quick.
The
executive
order
is
going
to
rely
on
self
attestation
of
first
party
attestation
for
I'm
about
99
of
the
stuff
that
goes
in
there,
and
there
is
a
provision
there
for
testing
and
other
external
activities
for
certification,
but
and
we
need
to
handle
both
of
those.
So
I
just
want
to
make
sure
we
we
weren't
charging
down
the
second
party
attestation
thing
with
the
exception
of
the
first
party.
So
thank
you.
H
You're
next,
it's
gonna,
Echo,
I,
think
Charlie
again
it's
something
good
and
I
think
Hank
helped
clarify
quite
a
bit
there.
One
thing
I
did
want
to
point
out
just,
and
this
might
be
worthy
of
just
a
bit
of
text
in
the
use
case
side,
but
that
first
party
attestation
side
me
saying
that
my
software
complies
with
such
and
such
standard.
H
That's
what
sets
up
the
ability
to
have
a
trust
but
verify
and
that
trust
but
verified
situation
is
really
important
when
you're
deploying
out
into
various
either
governmental
or
contractual
type
scenarios
Etc.
So
I
just
wanted
to
call
that
out
and
because
I
think
that's.
That
is
a
very
critical
aspect
right
when
I
have
a
customer
that
comes
to
me
and
says:
oh,
did
you
meet
your
contractual
obligations?
G
E
E
A
G
I
I'm
still
really
I.
Maybe
you
need
a
different
term,
but
the
term
signing
Authority
is
invites
a
great
deal
of
confusion.
I
I
hear
some
people
kind
of
talking
about
it
as
if
it's
third
party
any
time
that
that
a
third
party
would
opine
something
about.
You
know
a
an
artifact
that
that's
a
signing
Authority,
but
that
that
sounds
like
a
bad
term
to
me,
if
it's
some
sort
of
generic
delegation
opportunity
where
it's
me,
the
provider,
giving
someone
else
authority
to
sign
for
me,
then
I'm
very
nervous.
G
G
It
would
cut
through
a
lot
of
this
or
if
we
just
simplify
it
down
and
say
you
know,
there's
a
statement
and
there's
someone
who
authored
the
statement,
and
then
we
have
a
policy
language
for
what
sorts
of
things
you
can
sign,
which
might
be
packages
or
audit
reports
or
certification
statements
or
compliance
evidence
or
delegation
of
authority
I.
Just
don't
like
signing
Authority.
It
doesn't
make
sense
to
me.
B
A
It's
really
the
additional
verifications
that
are
being
done
in
the
the
statements
that
are
being
made
about
that,
in
this
case
software
component
from
A
supplier.
So
it's
because,
but
currently
it's
kind
of
suggesting
that
it's
really
about,
like
literally
only
about
the
the
digital
signature
and
that's
it.
B
In
the
use
case
that
I
presented
harness,
you
are
correct.
It
is
just
about
the
one
point
about
the
digital
signature
applied
to
a
software
product.
It's
not
other
attest
stations
or
anything
else.
It
is
the
ability
for
a
consumer
to
say
the
signer
of
this
software
product
and
the
supplier
of
that
software
product
have
are
in
a
verified.
Trust
relationship
and
the
consumer
can
verify
that
by
checking
a
skit
registry,
where
someone
has
done
the
work
to
verify
that
relationship
and
place
that
information
into
the
registry
for
all.
B
G
E
B
B
B
So
let's
be
really
clear
that
what
we're
talking
about
here
are
roles
and
those
rules
are
fulfilled
by
entities
who
can
you
can
like
I
said
earlier?
My
ICU
frequently
Microsoft
is:
is
the
supplier,
the
signer
and
the
distributor,
so
one
entity
is
serving
in
all
three
roles.
So
let's
distinguish
roles
from
entities
because
that's
a
key
concept.
Understanding
this
use
case.
Thank
you.
F
C
Difference
to
the
rule,
I
think
Neil
says:
hey
the
signing.
Authority
is
the
issue
and
the
real,
quite
anybody
can
sign.
The
question
is:
is
the
configuration
of
the
policy
and
say
hey
that
signature
is
valid
for
what
the
content
you're
submitting
up
and
that's
different
I?
Think
that's
where
Neil's
asking
us
to
change
some
of
the
terminology.
Is
that
not
correct
Neil.
G
A
G
By
looking
at
a
use
case
versus
something
that
is
not
directly
related
to
something,
it
will
be
in
the
architecture,
but
regardless
I'm,
I'm
still
I
think
the
use
case
should
clarify
under
these
circumstances,
why
the
supplier
can't
do
a
bloody
digital
signature
all
by
themselves
like.
When
do
you
need
to
to
give
it
to
somebody
else
and
under
what?
And
what
do
you
authorize
them
to
sign
for
and
how
do
you?
How
do
you
allow
a
verifier
to
know
when
assigning
Authority's
signature
is
allowed
meaningful?
E
I
think
there
are
two
aspects:
one
is
if
you
are
expecting
a
Clarity
of
the
rules.
We
can
certainly
help
in
that
by
adding
more
text
like
a
package.
Supplier
is
releasing
the
package
and
it
is,
there
is
another
rule
which
is
a
signing
Authority,
but
if
you
are
saying
that
how
that
relationship
needs
to
be
established
is
to
be
clarified
that
will
go
in
the
architecture.
A
A
E
A
B
G
J
In
many
ways,
I'm
starting
to
wonder
if
this
is
going
a
bit
off
topic
for
skit
altogether,
but
if
I
have
a
view
on
Dick's
use
case
and
I,
don't
again,
nobody
is
saying
that
supplier
cannot
I
think.
The
suggestion
is
that
different
identities
will
perform
these
roles
and
a
legal
entity
might
include
multiple
identities
and
an
example
of
this.
That
happens.
J
But
only
the
security
team
could
Security
review
and
approve
the
firmware,
and
only
a
very
small
group
of
card
and
key
holders
would
actually
then
bless
and
sign
the
firmware
that
could
go
into
live
modules
and
the
paper
trail
and
the
attestations
and
the
supply
chain
Integrity
that
goes
into.
That
is
not
just
the
fact
that
the
thing
was
signed,
but
also
the
set
of
processes
and
signatures
and
verifications
and
Security
reviews
that
went
into
deciding
that
this
was
a
good
thing
to
sign
in
the
first
place.
So
I
guess
there's
a
question
to
dick.
B
Well,
that's
that
is
precisely
correct,
John
that
there
is
a
there's,
a
partners
that
goes
through
that
performs
the
verification
of
this
trust
relationship,
and
you
know
I
I,
don't
have
the
answers
to
exactly
what
that
process
is.
I,
think
that's
something
we
would
have
to
work
out
here,
but
yeah.
There
is
a
process,
but
from
a
consumer
standpoint
their
process,
the
verification
process
is
actually
quite
simple.
B
All
they
have
to
do
is
check
a
skit
registry
and
if
there's
an
entry
in
the
registry,
then
that
means
that
someone
has
done
the
work
to
verify
that
trust
relationship.
Whatever
that
work
is
yeah
from
a
consumer
standpoint,
it's
really
easy
for
them
to
check.
If
it's
on
the
registry,
then
someone
did
the
work
to
check
it.
J
E
A
E
Evaluating
the
multiple
component
parties
are
evaluating
the
software
product
on
certain
aspects
of
common
criteria,
fips.
All
that
is
a
very
valid
use
case,
and
that
is
highlighted
in
the
Second
Use
case
multi-stakeholder
evaluation
of
a
released
software
product
yeah,
which
you
have
to
take
care
of
John
yeah.
Okay,
that.
E
Anybody
can
sign
anything,
but
if
it
is
put
in
a
registry
where
everything
anybody
can
audit
it
or
then
that
owner
the
ownership
is
kind
of
the
responsibility
is
taken
there
right.
Anybody
can
then
come
to
you
and
say
hey.
Why
did
you
sign
this
or
you
signed
it
in
correctly
that
kind
of
responsibility
you
are
taking
by
putting
in
a
transparent
registry?
That's
what
we
are
trying
to
highlight
here,
indirectly,.
G
Yeah,
but
we
have
lots
of
ways
of
identifying
ourselves
and
I
mean
maybe
you're
going
to
try
to
handle
that
with
the
policy
for
who
gets
to
actually
enter
things
into
the
registry.
But
I
thought
we
were
going
to
have
a
very
generic
registry
and
kind
of
open
for
anyone
to
sign
anything
they
want.
So
we
need
to
have
a
policy
that
a
policy
language
that
allows
users
verifying
authorities
to
say
this
is
how
you
express
to
me
something
that
I
will
be
able
to
to
track
down
and
figure
out.
B
So
maybe
one
thing
we
can
do
is
add:
let's,
let's
just
see
if
we
all
agree
that
there
are
indeed
three
individual
roles,
free
roles
performed
in
this
transaction
that
is
and
I'll
call
it.
You
know
signing
digitally
signing
a
software
package.
That's
that's
the
transaction
I
had
in
mind
when
I
submitted.
This
is
that
someone
is
digitally
signing
a
software
package
and
and
a
consumer
wants
to
verify
that
that
digital
signature
and
yeah
and
and
the
supplier
of
that
software
are
in
some
type
of
trustworthy
relationship.
D
Rules,
no
I.
Let
me
let
me
jump
in
I've
been
on
the
list
for
a
while
I,
don't
think,
there's
three
roles
and
I
think
we
need
to
boil
it
down
as
a
rule
that
you
can
only
sign
for
yourself.
Any
entity
cannot
sign
for
somebody
else.
You
can
only
sign
for
yourself.
You
can
say
something
like
I'm
signing
for
that
other
party,
but
you
can
only
sign
for
yourself.
Another
party
can
say
I'm
delegating
such
and
such
to
this
entity,
exactly
your
signature
and
then
that
other
party
can
sign
for
themselves.
D
This
idea
that
you're
splitting
the
role
and
that
you're
having
somebody
delegated
and
say
you're
signing
for
me,
there's
gonna
have
to
be
some
other
thing.
That's
where
that
other
party
says
I'm
delegating
that
to
that
par
that
entity
and
there's
a
signature
on
that.
So
I,
don't
think.
There's
additional
role
and
I
think
that
we
should
just
do
away
with
the
the
language
that
there's
an
authorized
signing
Authority
thanks.
E
D
Then
we're
overloading
the
term
signing
we're
gonna
have
to
say
something
like
an
approving
like
I'm
approving
this
entire
package.
It
has
all
kinds
of
signatures
on
it:
I'm
reviewing
it,
I've
audited,
all
the
signatures
and
now
I'm
putting
a
stamp
of
some
kind
of
logo
on
it.
That
says
that
it
is
good,
according
to
my
rules,
that
I
believe
is
well
above
anything
that
we
need
to
actually
deal
with
directly
with
the
mechanism
and
skit.
D
But
since
we're
talking
about
it,
I
still
think
whoever
does
that
can
only
actually
sign
for
themselves
and
I
believe
that
the
confusion
here
is
what's
what
the
term
signing
means
and
if,
if
the
term
signing
means
I'm
collecting
everything
together,
I
see
all
these
I
see
the
original
supplier
sign
put
their
signature
on
it,
I
see
that
the
Sig
store
guys
but
they're
they're
sort
of
weak
signatures
on
it.
I
see
that
a
test
house
tested
it
I
see
that
it
actually
somebody
says
it
meets
fips
whatever,
and
that
team
says
they've
done
it.
D
You
get
all
these
teams
together
and
then
somebody
that's
aware
of
all
that
says.
Okay,
according
to
my
checklist,
I've
gone
down
and
everybody
has
signed
this
properly
and
now
I'm
putting
a
big
stamp
of
approval
on
it.
That's
a
different
thing
than
just
a
signature.
That's
I
think
where
we're
getting
into
trouble
with
with
different
people.
Reading
that
and
then
and
their
minds
coming
up
with
a
different
concept.
A
J
A
F
F
Second
raise
right:
everybody
is
responsible
what
they're
saying
by
their
own
and
if
they
say
I
authorized
or
delegated
some
Authority,
or
something
like
that.
That's
a
statement
that
that
you
own-
and
you
can
only
put
your
own
statements
on
skit-
that's
how
skit
works.
So,
yes,
Ray
is
absolutely
right,
but
one
thing
we
are
not
taking
into
accounting
solution
here.
We.
F
Account
the
problem,
so
the
problem
is
not
a
problem.
It's
a
use
case.
What
are
we
doing?
What
are
we
trying
to
do
here
and
and
as
I
as
a
responsible
stakeholder
I
want
to
designate
a
signing
Authority,
which
is
absolutely
fine,
but
it's
not
indicating
what
the
whole
solution
will
be.
So
now
we
have
to
just
make
the
use
cases
less
confusing,
as
they
are
at
the
moment,
assumes
about
that
and
so
I
and
say
every
role
or
entity
which
will
end
up
in
the
architecture.
F
What
we
use
in
the
use
cases
will
not
be
the
final
thing.
They
are
layman's
terms,
a
colloquial
and
that's
adjust
the
need
of
a
single
certain
use
case
perspective
and
all
of
them
combined
will
end
up
in
what
just
Ray
said:
you're
just
responsible
what
you
say,
but
you
can
dig
edit
something
with
it.
F
So
I
think
I
say
now
a
weird
discrepancy
between
what
a
use
case
supposed
to
look
like
and
what
the
solution
will
Encompass
at
the
end
and
what
your
name
we
have
to
split
it
a
little
bit
and
and
yes,
I,
absolutely
agree
with
everything.
Ray
said
and
I
brutally
apologize
for
signing
Authority
in
the
use
cases
because
I
didn't
know
that
would
make
such
a
confusion.
But
it's
just
one
use
case:
it's
not
the
entire
solution
and
that's
what
that's
all
I
say:
yeah.
I
I
How
do
I
tell
if
it's
a
real
signature,
and
that
is
not
the
same
thing
as
signing
for
that
piece
of
software
I
think
I
am
not
100
sure
that
I
feel
that
that
use
case
is
compelling,
but
it
is
important,
I
think
to
just
make
sure
that
we're
talking
about
apples
and
apples
here
so
dick
is
that
does
that
represent
your?
What
you're
trying
to
capture
here.
B
The
use
case
is
specifically
aimed
at
Imperial
and
empirical
cases
yeah.
This
is
not
Theory.
This
is
we
see
this
all
the
time
in
our
supply
chain.
Risk
assessments
is
that
you,
you
get
a
software
package.
It's
digitally
signed
the
signature
in
the
package.
You
can't
really
tell
if,
if,
if
it's
a
sign,
if
the
signer
has
been
authorized
based
on,
what's
in
the
signature
versus
what's
in
this
in
the
software
itself,
the
supplier
identification.
B
So
this
is
a
this.
This
is
not
theoretical.
This
is
happening
every
day
where
this
reconciliation
of
here's,
the
digital
signature,
it's
Oracle,
America,
and
when
you
looked
inside
the
software,
the
JRE,
it
said,
Oracle.
Well,
how
do
you
know
that
Oracle
in
Oracle
America
are
in
fact
you
know
the
same
thing
intuitively?
We
know
they
are,
but
your
computer
checking
those
two
strings.
There's
no
way
to
know
that,
there's
a
trust
relationship
between
Oracle.
I
B
Well,
that's
a
problem:
Charlie
is
anyone
can
and
I
wrote
an
article
about
this?
Anyone
can
sign
the
JRE
I.
Did
it
I
used
rehq
to
sign
the
JRE
and
sure
enough
that
thing
installed
without
any
issue
at
all,
and
so
therein
lies.
The
problem
is
that
today
the
Way
digital
signature,
verification
is
performed,
it
doesn't
really
check
to
see.
You
know.
Is
this
priority
authorized
a
sign,
it
just
says:
is
the
Mac
correctly
a
calculate
and
is
it
is
a
key
signature
and
a
valid
certificate?
B
I
B
Is
so
important
that
you
can
pill
the
package
from
any
distribution
point
I
could
get
the
JRE
all
right.
You
know,
I
get
a
package
from
I
can
get
them
bound
to
from
you
know.
One
location
I
can
get
it
also
from
Amazon,
so
the
Distributors
can
be
different,
and
so
you
want
to
be
able
to
verify
that
trust
relationship
from
wherever
you
got
the
package
from.
G
I
I
just
want
to
jump
in
again
and
and
ask
if
there's
any
work
in
here,
any
use
cases
describing
the
need
for
a
more
General
policy,
language
and
a
policy.
Language
is
again
something
that
has
come
up
in
this
field
for
decades
and
it
it
helps
a
verifier.
It
helps
document
what
a
verifier
needs
to
check.
You
know
for
these
kinds
of
products
to
be
deployed
in
this
kind
of
Realm.
You
need
fips
approval
and
it
needs
to
comply
with
rfcc
whatever,
and
it
has
an
s-bomb.
We
need
a
some
use.
G
E
F
E
A
Use
cases
here
glad
that
we
walked
through
this
in
in
that
detail,
because
it
didn't
occur
to
me
previously,
like
I
heard
John's
use
case,
I
Heard
dick
saying,
like
phrasing
it
phrasing
this
in
a
very
different
way,
namely
more
from
the
consumer
side.
Obviously
this
touches
more
on
the
trust
anchors.
It
touches
on
the
identity
management
piece.
A
So
there's
there's
certainly
some
challenges
there.
That
I
think
we
we
better
describe
because
that
will
come
up
and
I
also
hear
the
the
question.
The
issue
of
the
that
Neil
deck
just
brought
up
the
more
complicated
use
case
where
you
actually
want
to
have
some
complicated
verification
to
actually
make
sure
that
indeed
the
steps
are
taken
that
ought
to
be
taken.
So
now
we
we
at
the
end
of
the
hour,
unfortunately
already
but
I'm
curious
like
like.
What's
definitely,
this
text
needs
some
update.
A
F
Yeah
we
can't
solve
this
today.
Issue
comments,
issue,
PR's,
put
email
to
the
list,
I
think
we
have
an
understanding,
I
think
next
week,
sorry
I'm
vacation
this
week.
I
can
help
getting
this
bi-directional
calls
again
but
issue.
You
are
your
concerns
Neil,
if
you're
still
online,
maybe
put
your
three
most
concerns
into
a
current
PR
as
a
comment
or
as
an
issue
and
I
think
that
that's
that's
driving
discussion
same
goes
through
Zach
and
Joshua's
gone
yeah.