[FEATURE]: CBOM - agility features

[bhess]

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 certificateProperties and relatedCryptoMaterialProperties.
• 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.