[FEATURE]: Update signatures to use formal standard X.590 (JSS) instead of JSF

[j28smith]

Describe the feature

Goal:
Transition the CycloneDX JSON signature implementation from JSON Signature Format (JSF) to the formally standardized JSON Signature Scheme (JSS) as defined in ITU-T X.590.

Problem Statement:
While CycloneDX currently utilizes the JSON Signature Format (JSF), it is important to note that JSF was never ratified as a formal standard. The JSF specification has since been updated and evolved into the JSON Signature Scheme (JSS), which achieved formal international standardization through the ITU as ITU-T X.590. This transition ensures that CycloneDX integrity mechanisms are anchored in a recognized, stable framework.

Value Proposition:

Standardization: Anchors CycloneDX integrity in a formal International Standard.
Regulatory Compliance: Simplifies adoption in sectors requiring ITU/ISO-level certification.
Consistency: Aligns with parallel efforts in the SPDX community.

Scope:
Limited to the signature object within the CycloneDX JSON Schema and associated references.

Possible solutions

TBD

Alternatives

TBD

Additional context

This proposal is a result of research and coordination within the OpenSSF SBOM Everywhere SIG and the SBOM Signing Best Practices initiative (GitHub). The shift from JSF to JSS (ITU-T X.590) addresses the need for a formally standardized signing mechanism.

Community Alignment

OpenSSF: Initially developed within the OpenSSF SBOM Everywhere SIG.

SPDX Alignment: This proposal has been presented on the SPDX Tech Call. SPDX is currently evaluating adding JSS-based signatures to their 3.0 data model (see SPDX Model Issue #1065 and SPDX Spec Issue #1362).

Interoperability: Adopting JSS (ITU-T X.590) drives consistency between CycloneDX and SPDX, significantly reducing the burden on tooling vendors who support both formats.

Technical Foundation

Canonicalization: JSS utilizes JSON Canonicalization Scheme (JCS - RFC 8785), maintaining consistency with existing JSF-based implementations in CycloneDX.

Standard Evolution: This move transitions CycloneDX from a community-led specification to an International Standard (ITU-T), which is critical for adoption in highly regulated sectors.

Stakeholder Engagement
The rationale for this transition was discussed with core authors and maintainers of these standards. Notable insights were provided by:

• Steve Springett (@stevespringett) – CycloneDX Chair
• Anders Rundgren (@cyberphone) – Author of JSF / Co-Author of JCS
• Bret Jordan (@jordan2175) – Co-Author of JCS and JSS (ITU-T X.590)

References

https://github.com/shiftleftcyber/sbom-signing-best-practices
https://cyclonedx.org/docs/1.7/json/#signature
https://spdx.dev/use/specifications/
https://cyberphone.github.io/doc/security/jsf.html
https://www.rfc-editor.org/rfc/rfc8785
https://www.itu.int/rec/T-REC-X.590-202310-I/en
spdx/spdx-3-model#1065 (comment)
spdx/spdx-spec#1362
https://www.linkedin.com/posts/j28smith_openssf-sbom-supplychainsecurity-activity-7426752007064985600-5cMX/

[cyberphone]

Hi Jason, this is probably a good decision with respect to uptake and deployment.

FWIW, I have personally abandoned JSON altogether in favor of CBOR. Although the Embedded Signature signature solution currently does not enjoy IETF support, it builds on RFC 8949 (CBOR RFC) with respect to serialization. You can test it online if you want: https://test.webpki.org/csf-lab/home

Embedded Signatures is a part of an effort making CBOR useful in the enterprise space:
https://www.ietf.org/archive/id/draft-rundgren-cbor-core-25.html

Cheers,
Anders

[j28smith]

Thanks, Anders (@cyberphone)!

Given that CycloneDX is moving toward exclusive JSON support for v2 (slated for release later this year), this approach currently aligns best with this roadmap and recent research.

I also want to thank you again for your insights and connections. They were instrumental in bringing JSS to my attention and ultimately shaping this proposal.

[jordan2175]

I will be submitting JCS to ITU Study Group 17 soon, so that it can go through the formal standardization process.

[j28smith]

Thanks for the update @jordan2175.

In your upcoming submission to ITU, are there any changes being made from what is in the current version of JCS (RFC 8785) to be aware of?

[cyberphone]

Hi Jordan (@jordan2175), the primary reason I have sort of "moved on" is that JCS requires RFC 8785 support to function. With CBOR, deterministic encoding can without drawbacks be a part of the platform itself. The following 300 lines (+ test) of not overly complex JavaScript (and no external dependencies) contains a full-featured RFC 8949-compatible CBOR encoder using deterministic encoding:
https://github.com/cyberphone/simple-cbor-encoder.js/blob/main/cde.js

The project is known as CBOR::Core and can be found at: https://github.com/cyberphone/cbor-core#main

[jordan2175]

@j28smith no changes will be made to the submission to ITU. There are far too many organizations, technologies, and products already using JSS and JCS. The goal is to just up-level the standard to the ITU level.

@cyberphone, hi Anders, I get it. But that is not where the vendor market is at right now. For good or for bad vendors are not moving off of JSON anytime soon. So JSS and JCS seem like a good option for everyone that still needs and/or wants their JSON format.

[cyberphone]

@jordan2175 I'm painfully aware of that JSON is the undisputed King 🥇