Skip to content

Commit 68d3377

Browse files
bhessbhess
committed
Add sample PQC readiness perspective
Signed-off-by: Basil Hess <bhe@zurich.ibm.com>
1 parent bbbcaec commit 68d3377

1 file changed

Lines changed: 118 additions & 0 deletions

File tree

‎perspectives/pqc-readiness-perspective.json‎

Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,118 @@
1+
{
2+
"$schema": "https://cyclonedx.org/schema/2.0/cyclonedx-2.0.schema.json",
3+
"specFormat": "CycloneDX",
4+
"specVersion": "2.0",
5+
"version": 1,
6+
"metadata": {
7+
"timestamp": "2026-06-03T12:00:00Z"
8+
},
9+
"perspectives": [
10+
{
11+
"bom-ref": "perspective-pqc-readiness",
12+
"name": "PQC Readiness",
13+
"description": "Defines the data elements needed to assess a product's readiness for the post-quantum migration, and the structural assertions that determine readiness. Organized along three dimensions inspired by the PQCA readiness-tracking working group: inventory (is the cryptography recorded and classifiable), algorithm (is the cryptography in use quantum-resistant, split into a confidentiality/HNDL facet and an authentication facet), and agility (can vulnerable cryptography be replaced without code changes). Mappings carrying an 'expectation' are hard checks; mappings without one are descriptive and feed a graded readiness score. This perspective assumes the 'expectation' field on perspective mappings (see perspective-expectation-rationale.md).",
14+
"domains": [
15+
"cryptographic-security",
16+
{
17+
"name": "post-quantum-migration",
18+
"description": "Concerns related to migrating cryptography to post-quantum algorithms ahead of cryptographically relevant quantum computers."
19+
}
20+
],
21+
"mappings": [
22+
{
23+
"expression": "$.components[?(@.type=='cryptographic-asset')]",
24+
"nativeName": "Cryptographic Inventory",
25+
"nativeDescription": "All cryptographic assets (algorithms, certificates, protocols, and related material) used by the product.",
26+
"relevance": "required",
27+
"expectation": "present",
28+
"weight": 1.0,
29+
"rationale": "Inventory dimension. PQC readiness cannot be assessed unless the cryptography in use is inventoried."
30+
},
31+
{
32+
"expression": "$.components[?(@.cryptoProperties.assetType=='algorithm' && !@.cryptoProperties.algorithmProperties.primitive)]",
33+
"nativeName": "Unclassified algorithm",
34+
"nativeDescription": "An algorithm asset that does not declare its primitive.",
35+
"relevance": "required",
36+
"expectation": "absent",
37+
"weight": 0.8,
38+
"rationale": "Inventory dimension. Every algorithm must declare its primitive so the confidentiality and authentication facets can be evaluated."
39+
},
40+
{
41+
"expression": "$.components[?((@.cryptoProperties.algorithmProperties.primitive=='kem' || @.cryptoProperties.algorithmProperties.primitive=='key-agree' || @.cryptoProperties.algorithmProperties.primitive=='pke' || @.cryptoProperties.algorithmProperties.primitive=='signature') && !@.cryptoProperties.algorithmProperties.nistQuantumSecurityLevel)]",
42+
"nativeName": "Asymmetric algorithm without a quantum security category",
43+
"nativeDescription": "An asymmetric algorithm — key establishment (KEM, key agreement, or PKE) or signature — that does not declare a NIST security strength category.",
44+
"relevance": "required",
45+
"expectation": "absent",
46+
"weight": 0.8,
47+
"rationale": "Inventory dimension. Restricted to the quantum-relevant asymmetric primitives, whose NIST security category gates the confidentiality and authentication facets; symmetric algorithms are out of scope for this check. Without the category, an asymmetric algorithm's quantum resistance cannot be judged."
48+
},
49+
{
50+
"expression": "$.components[?((@.cryptoProperties.algorithmProperties.primitive=='kem' || @.cryptoProperties.algorithmProperties.primitive=='key-agree' || @.cryptoProperties.algorithmProperties.primitive=='pke') && @.cryptoProperties.algorithmProperties.nistQuantumSecurityLevel==0)]",
51+
"nativeName": "Quantum-vulnerable key establishment",
52+
"nativeDescription": "Key encapsulation, key agreement, or public-key encryption that provides no post-quantum security.",
53+
"relevance": "required",
54+
"expectation": "absent",
55+
"weight": 1.0,
56+
"rationale": "Algorithm dimension, confidentiality (harvest-now-decrypt-later) facet. Highest priority, because ciphertext captured today can be decrypted once a cryptographically relevant quantum computer exists."
57+
},
58+
{
59+
"expression": "$.components[?(@.cryptoProperties.algorithmProperties.primitive=='signature' && @.cryptoProperties.algorithmProperties.nistQuantumSecurityLevel==0)]",
60+
"nativeName": "Quantum-vulnerable signatures",
61+
"nativeDescription": "Signature algorithms that provide no post-quantum security.",
62+
"relevance": "required",
63+
"expectation": "absent",
64+
"weight": 0.7,
65+
"rationale": "Algorithm dimension, authentication facet. Needed for forward integrity and for long-lived signatures such as firmware and roots of trust."
66+
},
67+
{
68+
"expression": "$.components[?(@.cryptoProperties.assetType=='certificate')]",
69+
"nativeName": "Certificates",
70+
"nativeDescription": "X.509 and other certificates whose quantum resistance derives from their signing algorithm.",
71+
"relevance": "recommended",
72+
"weight": 0.5,
73+
"rationale": "Algorithm dimension, authentication facet. A certificate's quantum resistance follows from its signature algorithm, which is resolved through the certificate's related cryptographic assets rather than a single field."
74+
},
75+
{
76+
"expression": "$.components[?(@.cryptoProperties.assetType=='protocol')]",
77+
"nativeName": "Protocols",
78+
"nativeDescription": "Protocols such as TLS, SSH, and IKE whose security depends on the negotiated key exchange and signatures.",
79+
"relevance": "recommended",
80+
"weight": 0.5,
81+
"rationale": "Protocol dimension. A protocol's readiness follows from the cipher suites and key exchange it negotiates."
82+
},
83+
{
84+
"expression": "$..cryptoProperties.agility",
85+
"nativeName": "Cryptographic agility",
86+
"nativeDescription": "How an asset's cryptographic configuration was determined and how a change to it can be applied.",
87+
"relevance": "recommended",
88+
"weight": 0.5,
89+
"rationale": "Agility dimension. Informs migration effort, not the readiness verdict."
90+
},
91+
{
92+
"expression": "$..cryptoProperties.agility.changeMechanism",
93+
"nativeName": "Change mechanism",
94+
"nativeDescription": "How a change to the cryptographic configuration is applied.",
95+
"relevance": "recommended",
96+
"weight": 0.4,
97+
"rationale": "Agility dimension. A value of runtime-config or restart-required indicates low-effort migration, while firmware-update or hardware-replacement indicates higher effort."
98+
},
99+
{
100+
"expression": "$.components[?(@.cryptoProperties.assetType=='related-crypto-material')].cryptoProperties.relatedCryptoMaterialProperties.rotation",
101+
"nativeName": "Key rotation",
102+
"nativeDescription": "How key material is rotated, covering both the degree of automation and the concrete rotation mechanism.",
103+
"relevance": "recommended",
104+
"weight": 0.3,
105+
"rationale": "Agility dimension. Automated rotation and a known rotation mechanism (e.g. a cloud KMS or PKCS#11) ease re-keying during migration."
106+
},
107+
{
108+
"expression": "$.components[?(@.cryptoProperties.assetType=='certificate')].cryptoProperties.certificateProperties.renewal",
109+
"nativeName": "Certificate renewal",
110+
"nativeDescription": "How certificates are renewed, covering both the degree of automation and the concrete renewal mechanism.",
111+
"relevance": "recommended",
112+
"weight": 0.3,
113+
"rationale": "Agility dimension. Automated renewal and a known renewal mechanism (e.g. ACME or EST) ease certificate re-issuance during migration."
114+
}
115+
]
116+
}
117+
]
118+
}

0 commit comments

Comments
 (0)