Chapter 21 — Quantum and post-quantum security: requirements
Lesson map
Lesson 21 published. Map, example, EX041.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Good requirements"]
N2["21.2 Sources"]
N3["21.3 Requirement categories"]
N4["21.4 Traceability"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX041"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 Good requirements"]
N2["21.2 Sources"]
N3["21.3 Requirement categories"]
N4["21.4 Traceability"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX041"]
[Learning outcomes]
|
v
[21.1 Good requirements]
|
v
[21.2 Sources]
|
v
[21.3 Requirement categories]
|
v
[21.4 Traceability]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX041]
Learning outcomes
You will (1) write verifiable PQC requirements; (2) derive requirements from data lifetimes, policy and partner constraints; (3) include availability and agility requirements; and (4) trace requirements to verification methods. It builds on Chapter 20 and prepares models and threat analysis.
21.1 Good requirements
A requirement is necessary, unambiguous, verifiable and traceable. "The system shall be quantum-safe" fails all four. Better: "REQ-KE-01: All TLS connections at the external edge shall negotiate X25519MLKEM768 or a stronger PQ/T hybrid group when the client offers one. Verification: passive telemetry shows ≥ 99% of offering clients negotiate it."
The rewritten requirement names a property, a place and a threshold, and the verification line says what evidence counts. The condition "when the client offers one" matters: BPA cannot force old handheld scanners to support the hybrid group, so a requirement that ignored them could never be met.
21.2 Sources
Derive requirements from: data confidentiality lifetimes (Chapter 13), signature validity periods (bills of lading: 12 years), policy (NIST transition plans, sector regulators, CNSA 2.0 for national-security partners), partner capabilities and operational constraints (handshake size budgets, device memory).
Each source produces numbers that end up in requirement text. The 25-year customs lifetime makes REQ-EXP-03 urgent; the 12-year validity of bills of lading sets the deadline for ML-DSA signing; the 1,300-byte handshake budget limits the parameter set; the 32 KB flash in crane controllers constrains the firmware signature choice. Recording which source each requirement came from lets reviewers check it when that source changes.
21.3 Requirement categories
- Key establishment: which protocols use hybrid or PQC KEMs, which parameter sets.
- Signatures: which artefacts need post-quantum signatures, by when.
- Agility: "REQ-AG-02: Replacing the KEM algorithm in edge TLS shall require only a policy change and shall be completable within 30 days including testing."
- Inventory: "REQ-INV-01: The CBOM shall cover ≥ 95% of assets, with unknown share reported monthly."
- Availability: "REQ-AV-01: Enabling hybrid groups shall not raise handshake failures above baseline + 0.04 percentage points (95% upper bound)."
Every requirement here carries a number so testing can say pass or fail.
21.4 Traceability
Each requirement links to a source and to a verification method (test, analysis, inspection, demonstration). A traceability matrix shows coverage and helps reviewers find orphaned requirements.
In BPA's matrix, REQ-KE-01 traces back to the customs data lifetime and forward to the passive telemetry query; REQ-AG-02 traces to the agility policy and forward to a timed drill in which the team swaps the KEM in a test environment. A requirement with no forward link has no evidence it was met, and one with no backward link may have no reason to exist. Both kinds are flagged in the monthly review.
21.5 Worked example
BPA's customs export requirement: "REQ-EXP-03: Files exported to the customs agency shall be encrypted to the agency's ML-KEM-1024 key using CMS KEMRecipientInfo (RFC 9629), with an RSA-OAEP recipient retained in parallel until the agency confirms support (target date recorded). Verification: inspection of exported file structure; interoperability test with agency test system."
Keeping the RSA-OAEP recipient in parallel means the agency can read files during transition, but it also means the files remain exposed to harvest until that recipient is removed, so the target date matters.
21.6 Common errors and limits
- Requirements that name products instead of properties.
- No availability or agility requirements.
- Requirements without verification methods.
Naming a product locks BPA to a vendor and says nothing about the property needed, so a replacement product cannot be checked against it. Without availability and agility requirements, a rollout that breaks partners or cannot be changed later still passes review. A requirement with no verification method cannot be closed, as REQ-KE-01's telemetry line shows by contrast. Each requirement is reviewed for all three faults before it is baselined.
Exercises
- EX041 — Rewrite. Rewrite "Use PQC for VPN" as a verifiable requirement. Rubric: 3 = protocol, parameter, condition and verification stated.
- EX042 — Trace. Build a five-row traceability matrix for BPA. Rubric: 3 = sources and verification methods for each.
Synthesis
PQC requirements are specific, verifiable and traced to data lifetimes, policy and constraints, and they include agility, inventory and availability, not only algorithms.
Continue studying — chapter 21 of 50
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →