Merge QS01/QS02 into a single HNDL entry; move signature content to QS03 (#11)

[m-khan-97]

Delivers the merge shape discussed in #11, where the consensus converged on:
one Harvest-Now-Decrypt-Later entry covering both transit and at-rest
confidentiality, with QS02's signature/credential content folded into QS03.

QS01 now covers both surfaces under Mosca's inequality as a single frame -
in-transit collection (the original QS01) and at-rest exposure of already-stored
data (the former QS02), which are the same threat differing only in where the
ciphertext currently sits. Common examples, prevention steps, and the two
strongest attack scenarios are merged and deduplicated rather than concatenated.

QS02 is deleted. Its confidentiality content is in QS01; its integrity
content - long-lived signed artefacts, identity/credential records, and the
forged-release scenario - is now in QS03, with the same Mosca's-inequality
reasoning applied to signature trust instead of confidentiality.

README updated: QS02's row removed, QS01's anchor broadened to include
Mosca's inequality, and a note added on the freed slot - explicitly framed as a
byproduct of the merge, not a claim about what fills it. #20 is a candidate; so
is anything else Sprint 1 surfaces. That's for voting, not this PR.

No other entries touched. Filenames for QS03-QS10 are unchanged, so this
doesn't renumber anything or break existing cross-references (e.g. QS06's
"upstream of QS01").

@galoisField7 @rot169 - this is the shape the three of us converged on in #11;
flagging you both since you did the actual thinking here.

[nmcitra]

This is the merge shape from #11 done properly — deduplicated rather than concatenated, and extending Mosca's inequality from confidentiality to integrity is the move that makes QS01 and QS03 read as one coherent frame instead of two lists. Re-verifying the references with a fresh date and leaving the Standards TODO for the leads are both the right call. So is the README note refusing to claim the freed slot; that sentence will save an argument later.

One substantive point, and it's about the boundary the merge has just created.

Common Example 6 brings identity and credential records into QS03 — government identity issuance, professional credentials, root certificates. Prevention 6 answers with re-signing or counter-signing before the classical scheme is deprecated. That answer is right for the artifacts in Common Example 5 and incomplete for the credentials in Common Example 6, because the two objects fail differently.

A contract or a signed release has fixed content. Counter-signing it with ML-DSA asserts nothing that wasn't already true — you're re-attesting an unchanged artifact, and the original signing event stays valid history.

A credential is a claim that a named subject controls a key. Re-signing it with a post-quantum key re-asserts that claim with fresh cryptographic strength, but it doesn't re-establish the thing the claim is about. If the classical key was the only evidence that the subject controlled the identity, then a PQ re-signature inherits its assurance from a signature scheme we've just agreed is failing. The credential comes out cryptographically strong and evidentially unchanged.

Suggestion, minimally invasive: split Prevention 6 so the artifact case keeps the re-signing guidance, and the credential case says re-issuance requires evidence independent of the credential being replaced — fresh proofing, a still-trusted anchor, or hardware attestation — rather than the outgoing key. That keeps the entry's scope exactly as you've drawn it while making the two remedies non-interchangeable.

Smaller note on Scenario #3: "records the signed artefacts today and, after a CRQC becomes available, forges signatures" implies the recording does work. It doesn't — forging a malicious update needs the key, not copies of prior releases. Your own next clause has it right ("the artefact was exposed from the day it was signed"), and dropping the recording step would keep the scenario cleanly on the TNFL side of the split @galoisField7 drew in #11.

None of this blocks the merge. I'd land it as-is if the alternative is waiting.

[m-khan-97]

This is a real distinction and the entry was wrong to treat re-signing as one remedy for two different objects. Pushed a fix: former Prevention 6 is now two items - artefacts (contracts, releases, fixed content) keep the re-signing guidance, since a new signature only re-attests something already true; credentials get their own item requiring re-issuance to rest on evidence independent of the outgoing key - fresh proofing, a still-trusted anchor, or hardware attestation - rather than the old key vouching for its successor. That is basically your #31 argument stated as a QS03 mitigation, which is exactly where it belongs.

Also fixed Scenario #3 - you are right that "records the artefacts" implied the harvest step does work it does not. Forging the update needs the recovered key, not copies of prior releases. Dropped the recording clause; the scenario now goes straight from CRQC to key recovery to forgery.

Appreciate you reading it at this level of care rather than waving it through - especially since you already said this would not block the merge.

[nmcitra]

Prevention 7 is a better statement of the distinction than mine was — "the outgoing key vouching for its own successor" gets the whole failure into one clause.

On the other thing you said: that this is basically the #31 argument stated as a QS03 mitigation, and that's where it belongs. That's the right question to raise, and I'd rather answer it now than have it surface during ranking.

Prevention 7 is a remedy with no risk behind it. QS03 names the risk that signatures become forgeable. Prevention 7 prescribes how to re-issue credentials safely. Nothing in QS01–QS10 describes what happens when re-issuance is done the other way — an enrollment flow that accepts proof-of-possession from a key the same document has already classified as forgeable, and issues a strong new credential on the strength of it. Both certificates verify. The migration completes and logs as successful. The failure is that the process accepted the wrong evidence, and the record it produced is indistinguishable from a correct one.

In a risk taxonomy, a prevention whose corresponding risk isn't named tends to get read as hardening advice rather than a failure mode with consequences. Prevention 7 currently tells an implementer what to do without telling them what happens if they don't, and that asymmetry is what I think is worth fixing.

Two resolutions, and I don't have standing to choose between them:

1. Expand QS03's scope statement to name re-establishment failure as a risk in its own words, with Prevention 7 as its mitigation. Cheapest, touches no numbering, and it's a sentence.
2. A separate entry — which is what Proposal: Trust Re-establishment Failure — identity and authorization continuity across cryptographic transition #31 proposes.

Disclosure, same as on #26: I authored #31, so discount this accordingly. I'd rather the class be named inside QS03 than not named at all, and option 1 costs you one sentence.

[nmcitra]

Richard — supporting this, with one thing for the leads rather than for you.

I did say QS-NEW-02 is the entry I'd most want to see, and that hasn't changed. The v2 artifact is the strongest evidence anyone has put on a proposal in this project.

What I'd flag isn't about candidates. It's about the slot.

QS02's number came free because its confidentiality content merged into QS01 and its integrity content moved into QS03. The vacancy is an artifact of a merge — not a gap someone identified and left open. The README was careful about exactly this, noting the freed slot without presuming what fills it, and that restraint looks right to me.

An entry should exist because the risk exists. If QS-NEW-02 belongs in the list it belongs whether or not a number happened to come free, and if it doesn't, an empty number isn't a reason.

That cuts against me too. I have an entry in adjacent territory (#31) and I'm not asking anyone to weigh it against this one. They're different failures: forging an agent identity, versus a migration accepting a forged credential as proof of control. The second is downstream of the first. Both could be right, or one, or neither.

So the useful question for the leads isn't which entry fills QS02. It's what makes something a QS entry at all, rather than a control under an existing one. Answer that and this settles itself — along with the next three proposals, which are coming either way.

[galoisField7]

Hello @m-khan-97, I really like the direction of this PR. Merging the previous QS01 (Harvest Now, Decrypt Later) and QS02 (Long-Lived Sensitive Data) results in a much cleaner taxonomy. Treating Mosca's inequality as the prioritisation framework within HNDL, rather than as a separate Top 10 risk, makes a lot of sense.

Reading this draft also reinforced several of the ideas discussed in #15 around the common entry template.

For example:

• The description already contains what is effectively a Scope, distinguishing between data in transit and encrypted data at rest. Making this an explicit template section would help clarify boundaries consistently across all entries.
• A Detection section would fit naturally here, describing how organisations can identify HNDL exposure (e.g. confidentiality lifetime, vulnerable key establishment, encrypted archives, cryptographic inventories, etc.).
• A Related Risks section would make the relationships to QS04 (Cryptographic Inventory), QS05 (Crypto Agility) and QS06 (Migration) explicit, making the taxonomy easier to navigate.
• The recurring Standards & Regulatory Mapping section has become a valuable part of the migration entries and, in my opinion, should be formalised in the common template rather than carried as a TODO.

I think this draft demonstrates why those template sections would improve consistency across the entire Top 10. Looking forward to the continued evolution of both the entries and the common template.

I've proposed these changes in PR #40 (Formalize the Quantum Security Top 10 Entry Template), with the goal of providing a consistent structure that can be adopted incrementally across all entries rather than within this PR alone.