Merge QS01/QS02 into a single HNDL entry; move signature content to QS03 (#11) - #38
Merge QS01/QS02 into a single HNDL entry; move signature content to QS03 (#11)#38m-khan-97 wants to merge 2 commits into
Conversation
Per the discussion in OWASP#11: QS01 (Harvest-Now-Decrypt-Later Exposure) and QS02 (Long-Lived Sensitive Data) covered the same underlying exposure - ciphertext an adversary can obtain now, protected by an algorithm that fails later - differing only in whether the ciphertext was in transit or already at rest. The merged QS01 uses Mosca's inequality as a single prioritisation frame covering both surfaces. QS02's integrity content (long-lived signed artefacts, identity and credential records, the forged-release scenario) moves to QS03, applying the same Mosca's-inequality logic to signature trust rather than confidentiality - QS03 was already the entry covering signature forgery. Net effect: ten entries become nine, opening a slot for Sprint 1. The README table and a note on the freed slot are updated accordingly; no other entries are touched.
|
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. |
…mcitra) Re-signing is the right remedy for fixed-content artefacts (contracts, releases): the content is unchanged, so a new signature only re-attests something already true. It is not equivalent remediation for a credential, which asserts that a named subject controls a key - a PQC re-signature re-asserts that claim with stronger cryptography but does not re-establish it. Splits former Prevention 6 into an artefact case (re-signing/counter-signing) and a credential case (re-issuance must rest on evidence independent of the outgoing key: fresh proofing, a still-trusted anchor, or hardware attestation). Also fixes Scenario 3: forging a malicious update needs the recovered signing key, not copies of prior signed artefacts, so the "records the artefacts today" framing overstated what the harvest step contributes.
|
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. |
2 participants
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.