Repository navigation
Labels
RFC notice sentA public RFC notice was distributed to the CycloneDX mailing list for considerationA public RFC notice was distributed to the CycloneDX mailing list for considerationRFC vote acceptedcap: cryptographyCapability: Cryptography (CBOM)Capability: Cryptography (CBOM)promote to tc54Promote to Ecma Technical Committee 54Promote to Ecma Technical Committee 54proposed core enhancementrequest for commenttc54 acceptedEcma TC54 has accepted the feature candidateEcma TC54 has accepted the feature candidatetc54 reviewedEcma TC54 has reviewed the feature candidateEcma TC54 has reviewed the feature candidate
Milestone
Description
Cryptographic Agility features
Motivation
Organizations preparing for PQC migration need to understand how agile their cryptography is. The Agility Plane captures properties that describe how easily cryptographic assets can be reconfigured, rotated, renewed, and migrated.
Without this metadata, it is difficult to answer questions like: Can this algorithm be swapped at runtime? Are keys auto-rotated? Is certificate renewal automated? Is this a vendor black box or changeable in-house? Is there a PQC transition plan?
Agility Plane Dimensions
| Dimension | Description | Example values |
|---|---|---|
| Configuration source | How the crypto config was determined | admin-configured, default-config, negotiated, hardcoded |
| Change mechanism | How a crypto change is applied | hot-swap/runtime, restart, software-update, hardware-dependent, not-possible |
| Rotation & renewal | How keys/certs are rotated or renewed | manual, automatic, ACME, on-demand, not-supported |
| Ownership | Who controls the implementation | inhouse, vendor, open-source |
| Roadmap | Migration planning toward PQC | Transition plan, target algorithms, timeline |
Discussion: Schema Integration
These dimensions could be integrated as optional fields in the cryptography model. Some natural attachment points:
- Configuration source & change mechanism — could live on
cryptoProperties(cross-cutting) or on individual asset-type properties (e.g.,algorithmProperties). The key question is whether these apply uniformly across all asset types or are more meaningful for specific ones. - Rotation & renewal — naturally fits alongside existing lifecycle fields on
certificatePropertiesandrelatedCryptoMaterialProperties. - Ownership — could be a new field on
cryptoProperties, but may overlap with existing component-level metadata (supplier,author). - Roadmap / PQC transition — What level of structure is appropriate?
There might be additional agility dimensions to be considered.
Metadata
Metadata
Assignees
Labels
RFC notice sentA public RFC notice was distributed to the CycloneDX mailing list for considerationA public RFC notice was distributed to the CycloneDX mailing list for considerationRFC vote acceptedcap: cryptographyCapability: Cryptography (CBOM)Capability: Cryptography (CBOM)promote to tc54Promote to Ecma Technical Committee 54Promote to Ecma Technical Committee 54proposed core enhancementrequest for commenttc54 acceptedEcma TC54 has accepted the feature candidateEcma TC54 has accepted the feature candidatetc54 reviewedEcma TC54 has reviewed the feature candidateEcma TC54 has reviewed the feature candidate
Activity
bhess commentedon Apr 2, 2026
To further address 'Rotation & renewal', I suggest adding these attributes as properties within certificateProperties and relatedCryptoMaterialProperties:
stevespringett commentedon Apr 30, 2026
Will need to investigate both approaches to ensure that they will meet the intended use cases described in this ticket. The "ownership" feature is currently further along.
jkowalleck commentedon Jul 27, 2026
RFC notice sent on July 23, 2026
Public RFC period ends August 20, 2026