Attendees:
- Shane Coughlan, OpenChain manager
- Norio Koboto, Sony
- Masahiro DAIKOKU, KDDI Corporation
- Jari Koivisto, Analog Devices
- Marc-Etienne Vargenau, Nokia
We have no news from CISA about our comments on their Minimum Elements document, due to the current shutdown in the US. Our comments are visible, but not all. The comments sent by Nokia on the last possible day are not yet visible.
There are comments from big companies, smaller companies, and individuals.
Some comments give different opinions on the document. For example, some comments are in favor of including the license information, and others are against it, as they consider it is unrelated to security.
In the Telco Guide version 1.0 and 1.1, the license information is mandatory, but the value might be NOASSERTION, which is equivalent to not providing the information. In the draft of version 1.2, we have disallowed this value, so that the real license information is provided. We will keep this or not depending on the content of the final version of the CISA document.
Shane explains there have been layoffs at CISA and currently two thirds of the employees are not in office. Allan Friedman has left CISA and his replacement is not in office due to the shutdown.
In the October meeting, we had discussed the encryption proposal text from Jimmy. Jimmy will propose a better wording; he could not do it today as he is travelling in Asia.
A small bug was found in the validator in the handling of the CISA SBOM Type. A new minor release will be published soon.
In the October meeting, it was suggested that the Telco validator could validate SPDX 3. This is currently difficult to implement, as the validator uses to parse the SBOM the Python library 
https://github.com/spdx/tools-python that does not currently support SPDX 3. There has been no update of the library since more that 1 year, but a new maintainer has been nominated, so we hope there will be a new release soon.
We review the document from the SBOM working group, especially the part about the Telco Guide, available athttps://docs.google.com/document/d/1iuXX8j10N70dfce1-CZFWhW6S2jEqc–flcCgXMMdjg/edit?tab=t.0#heading=h.ayxknpo2zsfl.
We first review the table listing the fields present in the Telco Guide (section 6.4) Everything seems OK, but we have a discussion on the Telco Guide section 3.5 “SBOM Build information”. It is suggested to rename it to “SBOM Document Build information” in order not to confuse the build of the software and the creation of the SBOM.
In section 6.3 of the document, we have the fields from the last version of the BSI document.
In this last version 2.1.0, they mandate the use of SPDX 3.0.1 or later instead of 2.2.1 or later. This seems a bit premature to us, as many tools still produce only SPDX 2.2 or 2.3. This is for example the case for BlackDuck.
Jari reports a remark from Philippe Ombredanne explaining that the most important thing for a good SBOM is the content and not the format. Many SBOMs are incomplete or contain wrong information.
The document lists several possible identifiers for a package (SWHID, PURL, CPE or the URL of the package distribution site), whereas in the Telco Guide, we recommend only PURL (Package URL). Package URL will become an ECMA standard, then will be fast-tracked to ISO. We do not know when the ISO standard will be published, but Shane’s experience is that it takes about 9 months for an official standard such as ECMA to become an ISO standard.
It is difficult to express the “known unknowns” in SPDX. Norio Koboto-san point out that they are often not provided.
The document gives examples of different naming of packages. This is a recurrent problem; different tools name them differently.
The document uses the words SHALL, SHOULD, etc. in upper case, but the RFCs that define this usage are not present. We recommend adding them to the document as we have done in the Telco Guide.
Everyone is encouraged to provide comments on the document as soon as possible in order that it can be presented at the Open Compliance Summit Japan in December.
