[1.7] - Updates from CBOM working group

[stevespringett]

The cryptography working group has received feedback from real-world usage and have made some minor enhancements to the CBOM specificaiton.

Closes #569

---

RFC notice sent 2025-07-26
This RFC will be open for 4 weeks. At the end of the RFC period the CycloneDX community will vote, by lazy consensus, to accept or reject the proposal.
RFC period end: 2025-08-23

---

TODO/DONE

• add examples for XML
• add examples for JSON
• add examples for ProtoBuf
• implement for XML
• implement for JSON
• implement for ProtoBuf

[stevespringett]

This is ready for review.

1. A new schema was introduced which the Java tool does not currently support. This is causing the build to fail.
   • https://cyclonedx.org/schema/cryptography-defs.schema.json
2. The ikev2TransformTypes implemented in v1.6 was defective and could not be used as is. This has since been corrected in all three serialization formats. However, the protobuf check is failing because of this. Technically, it is a breaking change, but it was impossible to use the feature in v1.6, so it needed to be resolved.

[stevespringett]

This PR introduces the following:

• A new schema and corresponding JSON datafile which provides an authoritative source for algorithm families and all known elliptic curves. These schemas may additionally be used outside of CycloneDX, such as in static code analysis.

  • Algorithm families defines the the algorithm along with all the variants that are supported. It leverages the data available from the standard that defines the algorithm.
  • This subschema will only be available in JSON and may be updated independent of the core CycloneDX specification, much like the spdx subschema.

• Certificates:

  • Added support for certificate extensions, both common and custom extensions are supported.
  • Added support for certificate fingerprints.
  • Added support for certificate lifecycle management, via certificateState and introduced additional timestamps such as:
    • creationDate
    • activationDate
    • deactivationDate
    • revocationDate
    • destructionDate

• Added additional protocols requested by ATIS so that cryptographic assets could be represented across the mobile telecommunications industry.

• Corrected ikev2TransformTypes which was introduced in v1.6 in a way that could not be used. This has been resolved in v1.7.

• Several simplifications have been made resulting in the deprecation of multiple properties. These will be removed in CycloneDX v2.0

[prabhu]

Typo corrsponding

[jkowalleck]

Suggested change

	"description": "Defines algorithm variants by a naming pattern and the corrsponding cryptographic primitive.",
	"description": "Defines algorithm variants by a naming pattern and the corresponding cryptographic primitive.",

[prabhu]

Could this attribute be made an enum?

[prabhu]

Could this become an enum as well? Some of the values could be "nist", "secg", "x963", and "other".

[prabhu]

My knowledge on this is quite limited. It appears like we are capturing the form of the equation but not the field type. Based on the below document, an enum called fieldType could be added with the values prime and binary. This would help with categorization.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186.pdf

[prabhu]

In addition to aliases, it will be nice to have a much simpler way to compare the forms like 128 bits, 256 bits etc (computational effort to break). Often these values are approximate but could be still useful. The attribute could be an integer with the name securityBits or keyLength.

[prabhu]

We capture the algorithms, but do not communicate the production status.

An explicit attribute status with enum values such as legacy, active, evaluation, deprecated would help.

[prabhu]

In the same line of thought, it will be nice to communicate some known risks associated with an algorithm. Examples:

timing-attack
replay-attack
side-channel attack

It could be argued that often such risks are due to the implementations. In such cases, an example of a CBOM with components and dependencies.provides to illustrate implementation risks would be perfect.

[prabhu]

This is new to me. We're using placeholders in the pattern string for the first time? To keep the specification consistent, can we define the list of allowed placeholders to help implementation tools? ChatGPT is suggesting an attribute as below:

{
  "pattern": {
    "type": "string",
    "title": "Pattern",
    "description": "Defines the pattern used to construct the complete algorithm name. Placeholders are defined by {} for standardized algorithm-specific properties.",
    // This regex enforces that any placeholder {} contains only one of the predefined standard names.
    // Note: This is a simplified example and might need adjustment for edge cases like escaping or nested brackets.
    "pattern": "^([^{}]|\\{((keyLength)|(mode)|(digestAlgorithm)|(hashFunction)|(saltLength)|(ellipticCurve)|(securityLevel)|(function)|(padding)|(tagLength)|(ivLength)|(primitive))\\})*$"
  }
}