One
of my follow-up
actions was to
address the
description of
products in the
CSAF JSON
format. Until
now, I've
avoided defining
the schema for
this problem,
because the JSON
mapping enables
some approaches
that are harder
to implement in
XML. I wrote
something up
about this in a
previous email (May 8).
A snippet
of a CVRF XML
instance looks
like this:
 Â
<Branch
Name="Cisco"
Type="Vendor">
  Â
<Branch
Name="IOS"
Type="Product
Name">
   Â
<Branch
Name="12.2SE"
Type="Product
Version">
    Â
<Branch
Name="12.2(55)SE"
Type="Service
Pack">
    Â
Â
<FullProductName
ProductID="CVRFPID-103763">Cisco IOS 12.2SE
12.2(55)SE</FullProductName>
    Â
</Branch>
    Â
<Branch
Name="12.2(55)SE3"
Type="Service
Pack">
    Â
Â
<FullProductName
ProductID="CVRFPID-105394">Cisco IOS 12.2SE
12.2(55)SE3</FullProductName>
    Â
</Branch>
    Â
<Branch
Name="12.2(55)SE2"
Type="Service
Pack">
    Â
Â
<FullProductName
ProductID="CVRFPID-105689">Cisco IOS 12.2SE
12.2(55)SE2</FullProductName>
    Â
</Branch>
    Â
....
The above
defines three
products:ÂCVRFPID-103763,ÂCVRFPID-105394,
andÂCVRFPID-105689.
Each
of these
products has
associated a
"full product
name", a
"service
pack", a
"product
name", a
"product
version", and
a "vendor".
The CVRF
specification
identifies
additional
attributes
that can be
defined in the
"branches",
however those
attributes are
not strictly
hierarchical -
architecture,
host name,
language,
legacy,
product
family. This
makes fitting
them into the
above
structure
awkward, at
best.
The
underlying
goal here is
to associate a
bunch of
property
values with a
given product
ID. In the
most verbose
form, the JSON
form of the
product
definition for
"CVRFPID-103763
" could just
be:
{
Â
"id":
"CVRFPID-103763",
Â
"full_name": "Cisco
IOS 12.2SE
12.2(55)SE",
Â
"service_pack":
"12.2(55)SE",
Â
"version":
"12.2SE",
 "name":
"IOS",
 "vendor":
"Cisco"
}
(Note that
I removed
"product" from
attribute
names, so
instead of
"product_name"
it is just
"name".)
Keeping
with the data
model of CVRF,
additional
properties to
allow here
would include
"architecture", "host_name", "language", "legacy", "product_family",
"specification".
Of course,
we've also
been talking
about how to
identify
products
uniquely, so
"cpe", "swid",
and "spdx" are
good
candidates for
properties
here as well.
And of course,
since it is
JSON, we can
allow for
arbitrary
vendor
extensions
here. So far,
the proposed
JSON
definition of
a product is a
significant
improvement
over the XML
of CVRF,
because it has
an obvious
approach for
extensibility,
eliminates the
arbitrary
taxonomy for
attributes
that don't fit
a taxonomy,
and allows for
multiple
different
software
identity
mechanisms.
While the
above form is
explicit and
flexible, it
is also quite
verbose. How
do we
eliminate the
verbosity?
Proposal is to
allow for the
definition of
a "set" of
attributes
that can then
be reused. A
definition of
a set of
attributes for
the above
examples in
XML:
{
 "id":
"ios-12.2SE",
 "vendor":
"Cisco",
 "name" :
"IOS",
Â
"version":
"12.2SE"
}
The above
defines three
attributes
that can be
reused in
association
with a product
definition
Being able
to combine
attribute sets
will further
reduce
duplication.
So the full
proposal is to
allow "union"
of attribute
sets:
{
 "id":
"ios",
 "vendor":
"Cisco",
 "name":
"IOS",
},
{
 "id":
"ios-12.2SE",
 "union" :
"ios", // this
means share
properties
"vendor" is
Cisco, name is
"IOS".
Â
"version":
"12.2SE"
}
Restating
the original
XML product
descriptions
using
attribute
sets:
product_descriptions:
[
 {
 Â
"attribute_set":
"ios-12.2SE",
 Â
"products": [
   {
   Â
"id":
"CVRFPID-103763",
   Â
"full_name":
"Cisco IOS
12.2SE
12.2(55)SE",
   Â
"service_pack":
"12.2(55)SE",
   },
   {
   Â
"id":
"CVRFPID-105394",
   Â
"full_name":
"Cisco IOS
12.2SE
12.2(55)SE3",
   Â
"service_pack":
"12.2(55)SE3",
   },
   {
   Â
"id":
"CVRFPID-105689",
   Â
"full_name":
"Cisco IOS
12.2SE
12.2(55)SE2",
   Â
"service_pack":
"12.2(55)SE2",
   },
 },
 {
 Â
"attribute_set":
"ios-12.2EX",
 Â
"products": [
   ...
  ]
 }
]
For
discussion at
our meeting
tomorrow: Any
objection to
me changing
the product
tree in JSON
to match what
I describe
above?
Further
enhancement
ideas:
- "id"
attribute is
optional, if
only one of
swid, cpe, or
spdx is
provided, then
the value of
the one
present is
used as the
"id".
- full_name
- it strikes
me that this
field could be
completely
optional. The
default might
simply be to
take the
space-separated
concatenation
of the
available
attributes
(excluding
"id").
Eric.