OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

csaf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [csaf] Generic Software Identification Parameter/Attribute to be included in CSAF 2.0 schema.

This is solved by having a secondary definition for Other, which requires the inclusion of things such as a human readable reference page and a JSON or XML Schema URI.


Not JSON..


Product ID Vector: <ID String>


ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ ID String Version: <Version String>

ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ Vendor Product Name: <Common Public Name>


Type Schema: <Schema URL>


Documentation: <Documentation URL>



Something like that to replace the CPE ID field. Things that show up other than one of the expected values can certainly be added to the validator by minor revs as we produce them.





Troy Fridley, CISSP

Incident Manager, Cisco PSIRT

Phone: 614-336-4385

E-Mail: troy.fridley@cisco.com

PGP Key ID: 0x7B31ED20


From: <csaf@lists.oasis-open.org> on behalf of "Omar Santos (osantos)" <osantos@cisco.com>
Date: Thursday, November 29, 2018 at 12:32 PM
To: Eric Johnson <eric@tibco.com>
Cc: "csaf@lists.oasis-open.org" <csaf@lists.oasis-open.org>
Subject: Re: [csaf] Generic Software Identification Parameter/Attribute to be included in CSAF 2.0 schema.


Makes sense. Thank you for taking a look at this.







On Nov 29, 2018, at 12:17 PM, Eric Johnson <eric@tibco.com> wrote:


Hi Omar,

On Thu, Nov 29, 2018 at 9:14 AM Omar Santos (osantos) <osantos@cisco.com> wrote:

Thank you Eric! 


I like your suggestion. The main challenge that I was trying to address is that we cannot predict when the next software bill of material (SBOM) standard will be created. If we provide the ability to strictly define cpe, SWID, SPDX, etc,  what happen when the next standard format is created? 


For instance, the example that Art mentioned around âpurlâ.


I think the standard answer there is simply to add another property, as it is deemed useful. In contrast to XML, where an extra element in a schema creates massive backwards compatibility problems (at least when attempting to validate using XML Schema), merely adding an additional property to a JSON object is pretty much a no-brainer.





I was trying to suggest something like:


"standard_product_id": {


"type": "#/cpe/swid/purl/co-swid"

"$ref": "#/definitions/non_empty_string_t"




I think that it is basically the same as you are suggesting.



Omar Santos
Email: os@cisco.com
PGP Key: 8E19A9D13AF27EDC



On Nov 29, 2018, at 12:00 PM, Eric Johnson <eric@tibco.com> wrote:


Hi Omar,


Sorry I didn't manage to get off a response to this before our meeting yesterday.


On Tue, Nov 27, 2018 at 5:31 PM Omar Santos (osantos) <osantos@cisco.com> wrote:

This is to continue the discussion related to a Generic Software Identification Parameter/Attribute to be included in CSAF 2.0 schema.


The following is the current CSAF 2.0 draft schema:



Under full_product_name there is a CPE property. Replacing CPE for âstandard_product_identifierâ (or similar) may be the best place. Then the $ref: could be to a pointer to a SWID, CO-SWID, SPDX, etc docâ Thoughts or suggestions?


Due to the expectations and processing model behind JSON, I don't see the need or value to be generic. Put differently, in a JSON instance, the product definition could have a property for cpe, swid, spdx. The JSON schema could then more readily validate the corresponding value the property with a regular _expression_ match, at least. That also gives us the freedom, in some ideal future, to decide that one of these properties might be required, while the others could continue to be optional.


So instead of having "standard_product_identifier" as a property, and then have the implementation required to distinguish the kind of identifier based on the value, why not have "cpe", "swid", "co_swid", "spdx" as distinct properties?






"full_product_name_t": {

"type": "object",

"required": [




"properties": {

"product_id": {

"$ref": "#/definitions/non_empty_string_t"


"text": {

"$ref": "#/definitions/non_empty_string_t"


"cpe": {

"$ref": "#/definitions/non_empty_string_t"




"non_empty_string_t": {

"type": "string",

"minLength": 1








Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]