Migrate enveloped signature support from JSF to JSS

[stevespringett]

Migrate enveloped signature support from JSF to JSS (ITU-T X.590)

Summary

• Replaced legacy JSON Signature Format (JSF) with JSON Signature Scheme (JSS) per ITU-T X.590 (10/2023). Added CycloneDX 2.0 model schema that implements JSS
• Updated all schema files referencing signatures to use the new signatures array (JSS) instead of singular signature object (JSF)
• Removed old JSF test (valid-signatures-2.0.json) and added 18 targeted JSS test cases (8 valid, 10 invalid)

This PR closes #851

All tests are structural validations only. Keys, certificates, thumbprints, and signature values are illustrative and may not be cryptographically valid. No content validation is performed.

[j28smith]

I took a quick look at this @stevespringett and it looks good at a high level. I noted a number of places where the descriptions still reference JSF instead of the updated JSS.

For the core change/update, is this the main file to look more closely at to ensure it references the JSS spec correctly?

schema/2.0/model/cyclonedx-jss_X590_2023_10-2.0.schema.json

[j28smith]

@jordan2175 if possible, would you be able to take a look at this PR? Or perhaps you can suggest someone else who worked closely on the JSS technical standardization process that could lend assistance with a review of Steve's PR here?

Note the key thing to look at is the schema definition for JSS in this file:

schema/2.0/model/cyclonedx-jss_X590_2023_10-2.0.schema.json

Thanks.

[j28smith]

@jordan2175, here is the PR that I mentioned on our call today. Would appreciate your review if you could also take a look.

Thanks!

[jkowalleck]

RFC notice sent on May 04, 2026

• https://groups.io/g/CycloneDX/topic/119149389
• https://cyclonedx.slack.com/archives/CVA0G10FN/p1777922813922089

Public RFC period ends June 01, 2026

[jkowalleck]

My initial review was AI-assisted, so please treat this as a first-pass, skeptical read rather than a definitive standards-conformance assessment. I’ll need more time to do a deeper manual review against the actual X.590/JSS text.

That said, I’m not yet convinced that schema/2.0/model/cyclonedx-jss_X590_2023_10-2.0.schema.json really implements X.590/JSS as claimed, as opposed to a looser CycloneDX-flavored approximation of it.

A few things make me hesitate:

• The schema root is type: "null" and seems to exist only as a $defs container. That may be fine as an internal helper schema, but it weakens the claim that this file itself “implements” JSS in a direct or normative sense.

• algorithmVocabulary is defined with an enum, but algorithm is not constrained to it. So the schema documents a vocabulary without actually enforcing it.

• Several fields that appear to have normative formatting requirements are only typed as generic strings:

  • value
  • thumbprint
  • public_key
  • hash_algorithm

  If X.590 is prescriptive here, this schema is currently much more permissive than the spec text suggests.

• Important semantic constraints seem to be described only in prose, not enforced by the schema. For example:

  • modified should be >= created
  • valid_until should be > valid_from

  I realize JSON Schema cannot express every cross-field rule cleanly, but then we should be careful not to overstate conformance.

• unevaluatedProperties: true makes the schema intentionally open-ended. That may be pragmatic, but it also means this is not acting as a strict validator of a tightly bounded signature object.

• The signatures array modeling may match CycloneDX’s desired embedding, but I’m not convinced that this fully captures the actual structural and semantic requirements of X.590 rather than just borrowing its terminology.

So my concern is not that this schema is useless — it may be perfectly reasonable as a CycloneDX profile/adaptation — but that the wording currently suggests a stronger level of standards conformance than the schema appears to enforce.

I want to come back with a deeper manual review once I’ve had time to compare this more carefully against X.590 itself.

---

I will continue research about the topic, and might come up with yet another review.

[jkowalleck]

Important semantic constraints seem to be described only in prose, not enforced by the schema. For example:

* `modified` should be `>= created`

* `valid_until` should be `> valid_from`

@stevespringett , doees somethink like this work here?

{
  "$schema": "https://json-schema.org/draft/2019-09/schema",
  "type": "object",
  "properties": {
    "p1": { "type": "string", "format": "date-time" },
    "p2": { "type": "string", "format": "date-time" }
  },
  "required": ["p1", "p2"],
  "allOf": [
    {
      "properties": {
        "p2": {
          "exclusiveMinimum": { "$data": "1/p1" }
        }
      }
    }
  ]
}

PS: we decided to not incorporate this for now - might do in the future.
we are not quite sure if this exclusiveMinimum works with dynamic data - especially for strings in custom zulu time-format

[jkowalleck]

re: #858 (review)

was addressed in

• b1e46dd
• 4c830f4
• 2e89140

[jkowalleck]

remark: we might want to use the "extensiveProperties" approach instead ...
see

specification/schema/2.0/model/cyclonedx-common-2.0.schema.json

Lines 442 to 446 in 522d5b7

	"extensibleProperties": {
	"type": "object",
	"title": "Extensible Properties",
	"patternProperties": {
	"^ext:[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}:.+$": {