►
From YouTube: IETF-SCITT-20230619-1500
Description
SCITT meeting session at IETF
2023/06/19 1500
https://datatracker.ietf.org/meeting//proceedings/
A
B
B
B
B
The
the
main
sort
of
new
thing
is
to
revisit
the
117
hackathon
aims,
because
initially
we
agreed
I
think
there
was
a
good
agreement
that
we
would
base
the
hackathon
on
interoperable
registration
policies,
because
it's
such
a
big
open
area
of
the
spec,
but
we've
made
essentially
no
progress
on
on
anything
interoperable
there
and
and
I
honestly
think
it's
a
bit
of
a
it's
a
bit
of
a
Time
sink
compared
to
making
progress
in
other
places.
So
I
know
Dick's
got
a
use
case
from
the
healthcare
industry
that
that
might
be
interesting.
B
C
D
B
D
Well,
okay,
so,
regarding
this
registration,
let
me
just
outline
a
few
things,
at
least
from
my
point
of
view
and
number
one
I
was
very
much
I
didn't
understand
that
the
registration
policy
was
the
rate.
Is
the
the
policy
for
submitting
stuff
into
the
into
the
log,
and
it
seems
that,
like
the
key
trends,
work
which
is
very
I,
have
to
say
a.
D
They
might
do
that.
So
you
know
one
way
to
handle.
This
is
just
to
say
to
kind
of
opt
for
a
very
minimal
description
of
registration
policy,
which
is
nothing
except
for
just
the
absolute
minimum
checking
of
the
submitter
being
okay,
well,
there's
gonna!
So
so
here's
how
I
look
at
it
is
that
there's
going
to
be
a
user
that
is
connected
to
the
skit.
You
know
man,
log
manager,
machine
with
a
secure,
Channel
and
they're
going
to
have
a
key
that
is
in
their
machine.
But
it's
not
going
to
be.
D
What
we're
going
to
need
is
to
relate
that
to
to
the
authority
to
submit
things
for
a
product
and
and
that
that
was
what
I
was
relating
to
to
that
we
would
need.
It
looks
like
almost
a
relationship,
a
map
of
here,
here's
people
who
are
who
are
authorized
to
submit
for
this
this
product
and
this
now,
if
that's,
if
and
this
this
entity
that
follows
the
product.
E
The
I
I
wouldn't
want
any
sense
in
which
the
only
people
allowed
to
comment
on
a
product
are
people
who
are
I,
don't
know
in
some
sense
officially
associated
with
a
product,
or
you
know,
seen
by
the
product
developers
as
legitimates
on,
because
something
that
is
of
course
very
interesting
to
anyone
who
thinks
there's
a
problem
with
the
product
is
a
skeptic
who
says
it's
broken
and
there
may
be.
You
know
reasons
that
the
product
owner
wants
to
suppress
that
information.
E
So
you
know
it's
very
tricky
because
I
mean
the
main
reason
for
a
registration
policy,
in
my
mind,
is
to
prevent
spam
and
spam,
which
simply
overloads
the
system
and
makes
the
system
break
down
and
I'm
less
worried
about
risks
of
it.
Being
untrue,
because
I
think
the
relying
parties
are
the
only
ones
who
can
decide.
You
know
what
slant
on
not
slant
on
truth,
but
like
what,
how
they
evaluate
truth,
you
know
I
mean
we
can
look
to
to
follow.
F
E
Colleague
of
mine,
Alex,
halderman
and
through
spring
all
who
criticized
the
Dominion
equipment.
It
criticized
really
just
some
specific
aspect
of
of
security
vulnerabilities
and,
as
we
know,
all
equipment
has
security
vulnerabilities
because
that's
the
nature
of
software,
that's
complex
and
you
know,
Dominion
didn't
want
people
to
know
about
it
in
the
state
of
Georgia.
Didn't
want
people
to
know
about
it
and
it
all
get
conflated
with
this
brouhaha
around.
E
You
know
denying
the
outcome
of
the
election
and
the
researchers
were
completely
uninterested
in
that
they
were
interested
in
trying
to
preserve
election
systems.
So
we
can't
have
gatekeeping
role
for
that.
We
need
at
least
those
administrators
who
do
want
to
understand
the
security
vulnerabilities
of
their
systems
to
be
able
to
get
at
it.
So
I
mean
just
a
long
way
to
say
what
what
we
want
is
a
system-
that's
usable,
that's
not
spammy
in
the
sense
of
broken
by
denial
of
service,
but
we
don't
want
to
vet
declarations.
B
E
B
Cool
so
I've
pre-written
in
the
notes,
so
I
will
now
clarify
I.
Think
it's
a
really
good
point
that
you
and
Ray
in
the
past
Roy
also
have
described
these
use
cases
very.
Similarly,
as
making
claims
about
a
product
and
I
am
a
thousand
percent
with
you,
Neil
that
restricting
who
is
allowed
to
make
comments
about
a
particular
thing
runs
counter
to
the
aims
of
skit
and
runs
counter
to
the
interests
of
a
of
a
trusted
Community
or
a
cyber
secure
Community.
B
But
what
we
do
with
access
controls
and
identification
is
actually
limiting
access
to
feeds
not
to
products.
So
I
think
the
way
that
we
get
around
this
and-
and
certainly
this
one
I
mean
I've
implemented
this
for
the
dod,
so
I'm
sure
it
works
to
some
degree
is
that
you
have
you'll,
have
a
feed
for
the
official
software
vendor
and
only
they're
authorized.
Builders
and
cicd
systems
can
say.
Yes,
this
is
the
correct
latest
version,
but
equally
well
the
transparency
Advocates,
the
you
know
the
United
Nations,
the
security
researchers.
B
B
So
it
depends
what
question
you're
asking
but
I
think
that's
an
important
thing
that
we're
not
very
good
at
explaining
in
skit
is
what
a
what
strong
benefit
we
get
from
having
this
feeds
structure
and-
and
probably
that's
a
note
for
us
to
tidy
up
some
of
the
supporting
pieces,
but
a
thousand
percent
with
what
you
said
on
preventing
spam
absolutely
but
preventing
people
from
making
comment
about
stuff
there
in
a
legitimate
position
too.
Absolutely
not.
B
B
Thank
you
I
think
that
that's
a
good
idea,
I
mean
I,
might
as
well
hear
because
Hank
and
Cedric
are
in
the
crew
and
Roy
there
we
go
so
some
of
the
most
experienced
folks
on
this
topic
are
here.
So,
let's,
let's
hear
it
out,
but
I
agree
making
significant
decisions
on
a
day
when
a
lot
of
people
are
out
is.
Is
we
shouldn't
do
things
like
that?
Cedric.
F
Of
what
it
means
and
I
think
the
context
in
the
architecture
releases
the
feeder
as
just
aware
of
separating
between
different
purposes
from
the
semi-shoir.
So
you
have
an
issue
and
then
you-
and
so
you
have
the
name
of
the
issue-
reconsider
and
accept
when
using
transference
statement,
and
then
that
issue
are
selected.
The
feeder,
which
is
the
way
for
the
visual
to
say.
F
They
are
issuing
segments
on
the
side
effects,
I
I,
think
from
what
John
was
suggesting.
It
was
more
like.
There
is
a
fear
and
forgiven
feat:
there
are
some
issuers
that
are
authorized
and
others
that
are
not
and
that's
possible
that
as
a
resolution
policy,
but
yeah
I,
don't
think
that's
what
you
guys
in
mind
when
we
describe
the
feed
in
the
initial
architecture.
B
B
F
F
C
How
come
yeah,
sorry
hi
there
I'm
recovering
in
summer
I,
don't
know
why
so
what
I
am
I'm
trying
to
there's
a
lot
of
things
have
been
said.
So
what
I'm
trying
to
comment
on
is
first
of
all,
I
think.
There's
wide
agreement
on
a
skid
service
shall
not
be
spammed
with
arbitrary
inputs
that
are
just
ending
on
append,
only
Ledger
and
therefore
clogging
it.
Okay,
I
think
everybody
wants
that.
That
should
be
a
number
one
rule
and
I
have
no
idea
how
to
achieve
that.
Why?
C
Because
we
have
this,
this
interesting
spectrum
between
issua
feed
and
registration
policy,
I
just
heard
that
maybe
I
misheard,
but
I'm
I'm
rephrasing
it.
So
you
please
correct
me
if
I'm
wrong,
that
feeds
could
have
separate
registration
policies
I'm
just
letting
this
float
there
for
as
an
as
an
assertion,
I
don't
know,
but
I'm
definitely
sure
about
that.
C
Different
issuers
can
talk
about
the
feed
and
one
of
a
few
of
them
are
more
like
the
originator
of
the
of
the
feed
they
are
responsible,
have
some
Authority
about
the
the
artifact
product,
slash
topic
and
and
because
they're
I
don't
know
the
creator
of
it,
of
the
software
component,
for
example,
and
now
they
they
State
something
about
it.
That
seems
fine,
I
I
do
not
know
if
the
feed
is
exclusive
to
the
issuer.
That
feels
weird.
C
So
what
I
would
assume
is
that
multiple
issuers
can
add
to
that
feed
issuing
from
a
different
point
of
view,
so
to
speak
with
their
own
identity.
Now,
registration
policy
is
called,
for
example,
for
the
for
the
simplest
version
of
avoiding
spam
filter,
so
to
speak
by
identity.
So
not
everybody
May
comment
on
a
few
or
add
to
a
feed,
but
only
a
few
issuers,
and
maybe
registration
policies
to
feeds
are
different
per
feed.
I,
don't
know
so
that's
an
interesting
set
of
Lemma
here.
C
So
it's
a
trilemma,
somehow
maybe
a
contra
demo,
and
so
so
I
think
we
have
to
kind
of
Mark
out
what
we
want
to
do
in
the
first
Simple
Solution.
Here
the
minimal
viable
product
we
want
to
produce
and
for
me
it
was
always
like
every
issuer.
Independent
of
fees
is
somehow
running
through
a
gate
gatekeeping
function,
maybe
that
is
augmented
by
a
feed.
It's
the
issue
wants
to
add
two
I,
don't
know,
that's
of
course
management
overhead,
and
we
just
have
to
have
a
first
decision
here.
C
I
think
I
think
that's
the
most
important
thing
to
continue
to
have
this
three
dimensions
of
registration
policies
that
they
apply
just
to
issuer.
Do
they
apply
to
issue
our
fees
or
even
even
more
I,
think
all
of
this
again
wants
to
reduce
spam.
We
do
not
want
to
exclude
anyone
from
commenting,
but
we
do
want
to
exclude
spam,
and
that
is
a
conundrum
and
I
think
the
minimal,
viable
Next
Step
should
at
least
have
some
solution
for
that.
But
then
we
can
go
from
there.
G
Good
morning,
everyone
so
I
started
the
thread
with
Charlie
and
Ray
to
try
and
give
some
clarity
to
my
thoughts
and
get
their
in
input.
So
we
could
actually
break
this
up.
A
bit.
I
haven't
heard
back
from
Charlie
and
Ray.
Yet
so
it's
in
flight,
so
don't
despair
right
when
it
comes
down
to
the
policy
that
I
think
we're
talking
here
for
for
ledgers
and
so
forth,
It's
all
about
who
the
identity
providers
or
types
of
identities
that
that
we
validate
making
the
bar.
G
If
you
start
talking
about
product
and
who
can
write
to
things,
I
think
you're
getting
into
more
of
the
product
built
on
top
of
the
building
blocks
yeah.
And
if
we
wanted
to
diverge
to
that,
then
there's
a
different
set
of
policy.
I
still
believe.
As
I
wrote
in
the
in
the
chat,
there
is
going
to
be
instances
where
there's
for
OSS
or
for
small
businesses.
They
can't
afford
to
run
their
own
feeds
or
whatever,
and
it's
going
to
be
too
costly
or
too
high
of
Maintenance.
G
B
Yeah,
it's
a
great
Point,
certainly
there
it's
always
very
tempting
to
get
above
the
building
blocks
and
I.
Think,
certainly,
to
my
mind,
I,
don't
know
if
anyone
would
disagree.
But
to
my
mind
what
you
just
said
sounds
exactly
right:
you
have
a
a
use
case
or
an
application
vertical
aware
layer
on
top
of
skit,
which
is
picking
up
artifacts,
that
it
can
check
and
trust,
but
that's
not
the
same
as
having
a
full-featured
CI,
CD
system
or
software
supply
chain.
F
Yeah,
yes,
so
I,
I,
I,
think
I.
We
agree.
I
just
want
to
to
clarify
in
response
to
to
Hank
that
I
think
it's
critical,
that
we
specified
enough
checks
to
prevent
impersonation
and
forgery
and
that's
about
getting
the
signatures.
I
mean
the
identities
were
found
in
the
signature
is
valid,
I
think
in
practice
it's
important
to
do
whatever
we
can
against
them,
but
I
don't
see
how
we
will
be
able
to
Define
spam
for
every
for
every
supply
chain
in
the
standard.
F
So
I
think
as
I
believe
Ohio
is
suggesting,
though
it's
a
responsibility
of
the
transparency
service
to
decide
whether
to
authorize
the
registration
or
not
of
a
statement
based
on
the
visual
and
the
field
and
the
other
headers
and
which
we
in
the
architecture.
We
can
say
that
it
is
the
case
and
the
transparency
service
document.
C
Yeah,
so
this
is
hanging
coming
back
to
this
sorry,
yeah
I
I.
Absolutely
this
makes
it
more
clear
for
me
so
defining
what
vehicles
or
Dimensions
we
provide
in
the
first
draft
here
to
be
used
is
our
scope,
how
that
is
implemented
and
then
enforced
is
autoscope,
so
we
provide
the
channels
and
the
and
and
the
the
dimensions
for
how
to
restrict
something,
but
we
can't
guarantee
no
spam.
We
can't
also
that's
definitely
a
no-go
we'll
not
never
check
a
lying
issuer.
C
B
Yeah
I
mean
that's
a
great,
a
great
show,
because
things
like
impersonation
right,
if
somebody
steals
the
private
key
from
somewhere
that
isn't
part
of
the
implementation,
then
is
that
impersonation
or
not?
Who
knows
it's
different
different
things?
So,
let's,
let's
not
get
caught
up
in
that
area
right.
D
Yeah,
let
me
tell
you
I'm,
really
afraid
of
of
of
anything
but
a
pretty
strict
model.
The
idea
I
mean
it'd,
be
great.
If
we
could
save
this,
anybody
can
can
put
things
into
this
is
doing,
but
I
think
that's
just
going
to
become
a
Spam
magnet
and
it's
going
to
be
a
mess,
whereas
a
strict
model,
meaning
that
you
can
only
submit
stuff
to
this
if
you're,
the
actual
owner
of
the
product,
for
example.
D
That
gives
us
the
vast
majority
of
the
benefits
of
the
system
without
and
also
give
us
a
way
to
limit
who
said
who
supports
it.
That
can
be
supported
just
by
a
few
fields
that
are
that
are
exposed
in
the
in
the
log
that
that
we
can
match
up
to
or
or
some
other
kind
of,
a
different
type
of
a
log
that
allows
us
to
keep
track
of
who's
who's
authorized,
but
the
because
some
of
the
things
that
have
been
discussed
in
terms
of
complaints
of
the
system
or
maybe
bugs
of
the
system.
D
It
could
be.
You
could
have
one
of
these
set
up
just
to
track
vulnerabilities
and
bugs
of
systems,
but
that's
a
little
bit
different
than
than
getting
the
you
know,
bills
and
materials
and
actually
like
the
official
statement
of
here,
is
the
product
and
here's
the
here's,
the
component
of
the
product
or,
in
my
case,
here's
the
election.
Here's
a
component
of
the
election,
not
all
of
everyone
else,
saying
I,
don't
like
the
results,
so
there's
a
great
benefit
to
sort
of
a
strict
model.
D
Now
whether
we
want
to
put
that
into
the
actual
underlying
I,
don't
think
it
should
go
into
the
lower
level.
You
know
I,
think
both
models
should
be
supported
by
the
lower
level
and
then
then,
but
I
do
believe
that
the
only
one
that
will
be
you
know
actually
productive
is
sort
of
a
strict
model,
and
that
doesn't
mean
you
can't
run
a
key,
a
skit
log
with
loose
or
registration.
It's
just
that
we
need
to
Target
a
the
capability
of
having
the
strict
model,
otherwise
and
I.
G
B
Yeah,
certainly
what
I
have
in
mind
right
and
the
way
I
think
it
should
work
the
way
my
implementation
does.
Work
allows
both
very
very
cleanly,
so
I
think
we
usually
clean
up
some
wording
first
and
then
talk
about
more
specific
wording,
Cedric
and
then,
unless
anyone
really
feels
strongly
I'd
like
to
move
on
to
the
use
case
topic.
F
Yes,
thanks
so
I
as
I
think
we
we
said
several
times.
We
all
agree
it's
important
to
prevent
spam,
but
I
think
doing
that
is
going
to
be
application
specific.
So,
in
your
example,
determining
who
is
the
owner
of
an
artifact
is
really
not
something
I
want
to
Define
insulator,
although
I
will
encourage
people
who
set
up
the
transforms
to
decide
that
for
their
feedback
child
what
it
means.
F
F
So
I
think
the
main
problem
with
Spam
is
going
to
be
the
workload
of
the
Conservancy
service
itself
and,
in
that
sense,
I
think
the
transparency
service
should
be
able
to
decide
or
to
avoid
it
by
every
characteristic
Access
Control
policies,
but
that's
really
a
new
denotation
or
application
specific.
It
should
not
something
we
should
strictly
require
because
it's
12
in
general.
B
Good,
okay,
so
a
little
bit
of
progress
there
I
think
in
terms
of
so
two
very
concrete
things
that
we
can
move
forward
with.
In
addition
to
picking
up
the
thread
on
the
email
clarifying,
the
scope
of
a
feed
sounds
like
it
would
be
fruitful,
because
I
think
we
get
an
awful
lot
of
this
stuff
done
if
we
just
have
a
common
idea
of
what
the
objects
are
that
we're
dealing
with
and
as
Hank
suggested.
B
B
Cool.
Thank
you.
So
I
wanted
to
move
on
to
use
well,
not
quite
use
cases
the
117
hackathon
in
particular,
but
again
you
know
for
those
who
weren't
here
earlier
we
agreed
a
few
weeks
ago.
The
117
hackathon
was
going
to
be
around
interoperable
registration
policies
because
it
was
a
difficult
area
of
the
spec
I.
B
A
Okay,
well,
thank
you,
harness
I'm
going
to
share
my
screen
at
this
point.
So
let
me
go
ahead
and
do
that
I'm
just
going
to
share
the
entire
screen,
because
I've
got
a
bunch
of
stuff
I
want
to
show
you
today,
okay
wow!
That
looks
ugly.
So
let
me
let
me
start
by
showing
you
what
I'm
going
to
talk
about
today.
A
Okay,
so
Hannah's
reached
out
and
asked
me
if
I
was
aware
of
any
real
practical
use,
cases
that
we
might
want
to
consider
for
for
the
hackathon,
and
so
the
one
that
came
to
mind
is
what's
happening
here
in
the
U.S
starting
October
1st.
There
are
enforcement
rules
requiring
medical
device
manufacturers
to
provide
s-bombs
and
other
materials.
So
let
me
show
you
the
materials
that
FDA
is
going
to
be
requesting.
A
G
A
I
could
provide
s-spons
to
FDA
and
to
provide
s-bombs
to
users,
but
they
also
have
additional
requirements
with
regard
to
these
elements
that
need
to
be
submitted
by
medical
device
manufacturers,
for
example,
known
vulnerability,
information
they
want
to
know,
support
status
and
they
want
to
know
end
of
life,
basically
commercial
status,
so
I
went
ahead
and
took
this
information
from
FDA
that
was
presented
on
June
1st
to
nist
and
miter
and
I
formulated
a
use
case
around
it,
and
just
so
you
know
this
is
this
is
a
real.
This
is
really
happening.
A
G
A
A
G
A
G
A
Okay,
so
at
the
top
I
go
through
all
of
the
justification,
the
information
about
the
FDA
requirements
and,
basically,
what
they.
What
they're
looking
for
is
is
really
highlighted
right
here.
Those
are
the
items
that
they
are
requesting:
the
device
manufacturers
to
submit
so
they're.
Looking
for
a
plan
to
Monitor
and
identify
vulnerabilities
and
exploits
and
so
forth,
they
want
to
see
that
soft
that
suppliers
are
following
specific
processes
and
procedures
to
ensure
a
reasonable
assurance
that
the
vice
that
devices
secure
and
one
of
the
items
there
is
also
a
software
bill
of
materials.
A
A
So
you
get
a
look
at
that.
Can
you
see
what
the
vendor
response
file
on
the
screen?
Now?
Yes,
okay!
So
here,
you'll
notice,
there's
some
essentially
some
data
about
the
party,
that's
submitting
the
information,
so
this
would
be
a
medical
device
manufacturer.
This
is
actually
a
production
document
that
Rea
issues
for
our
own
products,
and
so
what
you
see
here
is
there's
the
vendor
who's,
supplying
all
the
information
and
then
there's
the
details
about
the
individual
products,
and
so
the
way
this
would
work
is
a
medical
device.
A
F
A
Okay,
so
the
medical
device
manufacturer
would
identify
the
license
or
the
software
that's
applying
the
product
name
of
the
software
in
the
version
of
the
software
they'd
also
have
to
identify
the
location
of
the
s-bomb,
and
this
is
kept
in
a
secure
location
because
it
is
sensitive
material.
So
the
only
information
that
would
actually
be
provided
to
the
skit
registry
would
be
the
location.
The
actual
s-bomb
itself
would
remain
under
Access
Control,
but
you
see
it.
A
It
contains
different
characteristics
about
describing
the
s-bomb
like
what
type
it
is,
what
version
and
the
format
of
the
document
and
the
digital
signature
that
goes
with
it,
there's
also
the
location
of
this,
where
the
software
was
obtained
from
some
information
about
whether
or
not
has
vulnerabilities
it.
Also,
in
this
case
right
here,
it
lists
the
actual
vulnerability
disclosure
report
that
the
medical
device
manufacturer
has
created,
and
this
follows
the
Miss
of
vdr
format
and
then,
following
down
below
you
see,
there's
additional
information.
A
It's
also
been
requested,
so
the
sdlc
policy
URL
describes
the
processes
that
were
used
in
the
sdlc
or
the
development
of
the
product,
the
evidence
URL.
In
this
case,
we
talk
about
the
use
of
the
self-attestation
from
sisa,
which
is
still
undergoing
development,
and
then
we
have
the
two,
the
two
statuses
that
have
been
requested:
the
commercial
status
and
the
support
status
and
again
that
that
goes
back
to
this
material.
A
Here's
the
here
are
the
steps
that
would
that
would
occur.
So
the
registration
of
a
vendor
response
file
within
a
skid
transparency
service,
with
an
appropriate
registration
policy
specifying
the
FBA
response
file
and
that
would
be
stored.
That
would
be
placed
into
a
skit
registry
by
a
authorized
party.
A
So
the
point
here
is
that
a
a
genuine
use
case
for
this
could
be
the
filing
of
a
vendor
response
file
into
skit
into
a
skit
registry
that
is
digitally
signed.
That
payload
is
digitally
signed,
the
vrf
is
digitally
signed
and
it
identifies
the
documents
that
FDA
would
be
requiring
from
device
manufacturers
and
all
that
material
can
be
downloaded
by
the
FDA
based
on
the
contents
of
the
vendor
response
file.
A
B
D
A
A
D
D
D
The
the
key
trends
thing
has
has
a
whole
secondary
sort
of
structure
to
make
it
easy
to
search
for
Stuff
within
the
log,
and
we
may
need
the
same
kind
of
thing
because
in
order
to
find
this
like,
if
you
don't
happen
to
have
the
URL,
we
need
people
to
be
able
to
say
gee
I
want
to
find
out
about,
and
and
what
would
they
have
dick?
What
would
be
the
is
there
a
name
of
this
product
or
something
within
this
use
case?
That
would
be
the
normal
thing.
It
would
be
specified
other.
A
Than
so
I'll
just
answer
your
question
Ray
the
way
it's
I've
spoked
about
here,
and
it's
not
the
only
way
to
do
it.
Obviously,
but
the
way
I
spoke
to
hear
is
that
when
that
device
manufacturer
submits
this
into
the
skit
registry,
they
receive
a
URL
that
can
be
given
to
the
FDA
to
pull
down
that
vendor
response
file.
So
this
is
just
as
the
proposed
use
case,
but
you
make
a
very
reasonable
point
that
this
thing
should
be
searchable,
and
so
you
know
you
may
want
to
use
information.
A
You
know
from
the
actual
vrf
itself
to
make
this
information
searchable,
like
I,
want
to
see
all
of
the
all
of
the
filings
by
reliable
energy
analytics.
Let's
say
in
this
case,
or
you
know,
or
dick
Brooks
the
contact
person
in
this
case.
So
it's
conceivable
that
support
for
searches
is
entirely
a
reasonable
expectation,
I
believe.
D
D
Because
it
seems
like
and
then
within
that
they
have
what
looks
like
a
number
of
products
listed
there
Pro
product
name,
sag,
Dash,
PM,
trademark,
TM,
yes,
okay,
so
that
first
thing
there
is
the
product
name.
Now,
in
my
mind,
I
was
conceptualizing
that
each
one
of
these
products
would
be
separately
submitted
as
a
as
a
product
such
that
that
you
know
it
could
be
separately
access,
but
you're
doing
here
is
proposing.
Now
is
this?
Is
this
the
standard
way
to
do
this,
where
a
number
of
products
are
listed?
A
I
wouldn't
say
it's
standard:
this
is
a
an
open
source
artifact
that
Rea
created
a
couple
years
ago
to
support
our
own
use
cases
our
own
customers,
and
we
found
that
they
would
be
needing
to
submit
this
information
to.
In
our
case,
you
know,
end
user
customers
who
would
then
retrieve
the
information
and
store
the
evidence
data,
and
this
is
the
evidence-
data.
Of
course,
all
this
stuff
here.
D
E
D
E
If
they
wish
wasn't
true,
you
know,
vulnerabilities
or
whatever,
but
that
that
they're
fulfilling
the
letter
of
the
law
and
what
I'm
wondering
about
is
for
relying
parties
who
not
only
care
about
those
disclosures
but
also
our
main
currently
outside
the
mainstream.
Maybe
they're,
worried
about
emerging
diseases
or
risks
that
other
people
aren't
yet
worried
about,
might
never
be
worried
about,
might
be
worried
about.
E
So
so,
how
does
a
relying
party
learn
not
only
what
is
required
by
the
FDA,
but
also
what
other
people
who
they
are
interested
in
say
about
a
specific
product?
How
does
the
railing
party
discover
a
feed
if
we're
going
to
have
multiple
feeds
in
a
skid
instance,
or
how
do
they
discover
the
skid
instances
that
are
going
to
actually
delve
into
this
area
that
they
care
about?
E
You
know,
I
can
imagine
this
being
all
an
open-ended
world
that
there
could
be
an
enormous
amount
of
stuff
to
kind
of
Wade
through,
and
people
are
going
to
disagree
about
identifiers
and
stuff
like
that.
So
how
does
a
relying
party
get
everything
that
they
care
about
without
being
spammed
by
having
to
look
through
too
much
stuff.
A
That's
a
great
question:
let
me
let
me
try
and
answer
that
for
you,
so
there's
also
vendor
level
information.
So,
in
addition
to
having
the
product
level,
information,
there's
also
vendor
level
information,
so,
for
example,
in
these
documents
that
are
these
URLs,
there
are
policy
documents,
and
so
in
here
you
would
have
things
like
information
about.
You
know
your
education
or
your
personnel
for
cyber
security.
A
You
would
basically
put
all
the
information
within
those
policy
documents,
and
so
here
the
cyber
security
policy
would
talk
about
all
those
things
this
vendor
does
in
order
to
ensure
that
the
environment
is
safe,
so
that
this
is,
this
is
bigger
than
the
ssdf
that
nist
talks
about.
This
is
other
other
practices
that
go
into
play,
that
you
know
things
like
data
protection
that
they
may
have
in
place
for
personal
information,
there's
also
financial
data,
so
they
can
make
available
financial
data
for
the
vendor
and
also
other
company
data.
A
E
But
my
guess
is
that
there
will
be
think
you
know,
so
they
might
so
suppose.
I
don't
have
to
come
up
with
an
example
where
the
company
doesn't
believe
in
this
emerging
Theory
doesn't
think
it's
an
issue
knows
that
it's
embarrassing
doesn't
want
to
have
anything
to
do
with
it
doesn't
want
to
disclose
things
and-
and
other
people
say
well,
it's
very
straightforward.
E
The
company
claims
that
it
has
so
and
so,
and
that
means
that
it's
going
to
be
a
disaster
for
the
environment
or
whatever
how
how
do
I,
who
only
I
mean
I'll,
try
to
be
concrete,
so
suppose
that
it,
you
know,
enhances
some
Fringe
environmental
thing
which
again
I'm
not
trying
to
I.
You
know
relying
parties
are
going
to
want
to
be
able
to
tie
together.
E
You
know
mash
up
company
data
with
other
data
and
make
that
easy
for
people
to
find
and-
and
this
may
over
time
actually
be
incorporated
into
the
law
where
it's
like.
Well
now,
everybody
realizes
that
smoking
is
bad
for
you
and
we
have
to
reassess
all
the
stuff
that
we've
been
told
about
risks
and
so
on.
You
know
what
about
the
stuff
that
is
not
part
of
anything
that
is
officially
government
required,
that
that
I
know
that
you've
got
so
much
experience
with.
A
The
only
thing
I
could
say
there
is,
you
know
we
tried
to
be
as
generic
as
possible
and
we
use
this
vrf
primarily
within
the
energy
industry.
That's
where
most
of
our
work
takes
place,
so
it
works
over
there.
It
looks
like
it
would
work
in
the
case
of
the
FDA
use
case
here,
so
we
think
it's
generic
enough,
but
you
know
to
be
very
candid
with
you.
We
would
be
happy
to
pass
on
this
vrf
concept,
this
open
source
concept
to
another
entity
and
that
may
that's
the
ITF
skit.
A
B
B
All
on
board
for
that
great
okay!
Well,
let's,
let's
sync
up
after
this,
it
should
be
quite
easy,
because
I
I'm
inclined
to
agree
I've
got
experience
in
the
ESG
side
and
the
nuclear
side
as
well.
We've
found
similar
flexibility
is
actually
quite
easy.
As
long
as
we
maintain
that
respect
for
the
boundaries
between
the
skit
layer
and
the
and
and
the
the
application
layer.
A
B
G
Normally,
we've
been
online
in
other
committees
or
other
working
groups
to
Define
documents
for
for
the
various
verticals
now
like
s-bombs,
are
defined
outside
of
here
of
X.
The
same
way
that's
going
forward
if
we
want
to
make
a
hackathon
where
we
try
and
use
our
building
blocks
to
solve
a
mobile
problem.
I
have
no
problem
with
that,
but
is
there
no
other
group
driving
this
discussion,
dick.
A
I
I
know
there
are
other
discussions
underway.
Roy
there's
been
a
lot
of
talk.
Of
course,
the
NIS,
the
nista
meeting
that
occurred
on
June
1st
had
a
lot
of
discussion
about
this.
The
material
I
presented
from
FDA
was
actually
presented
at
the
nist
meeting.
I
can
provide
you
a
link
to
the
the
topics
that
were
discussed
up
in
this
meeting.
If.
G
G
B
G
Exactly
okay
but
yeah,
this
will
change.
I
have
to
go.
Look
at
this
document.
This
changes
some
of
the
the
goals
for
short
term,
for
what
critical
software
is
that
FDA
is
driving
this
independently.
It
may
increase
the
scope
of
what
all
has
to
have
s-bombed
really
quickly,
but
in
that
regard
just
be
aware,
this
discussion
kind
of
is
supersedes
what
the
working
group
is
currently
tasked
with.
If
we
want
to
use
a
hackathon
as
a
an
example
of
trying
to
use
our
own
tools,
I'm
fine
with
that.