Discussion: QS01 and QS02 - same thing or different?

[rot169]

The two entries QS01 and QS02 feel very similar to me. I suggest collapsing down into a single item. If this is meant to be a list of quantum threats, I'd suggest this is branded under "Harvest Now, Decrypt Later".

Thoughts?

[galoisField7]

Hi @rot169 ,

I agree that the two entries appear closely related at first glance, as both are driven by future quantum attacks against today's public-key cryptography. However, they represent two fundamentally different risk categories. Harvest Now, Decrypt Later (HNDL=QS01) targets the future loss of confidentiality through encrypted data collection, whereas Trust Now, Forge Later (TNFL=QS02) targets the future loss of trust (breaking integrity, authenticity and non-repudiation) through forged digital signatures and trust relationships. Rather than merging the entries, it may be more beneficial to strengthen their descriptions and scope so that this distinction is immediately apparent to readers. See also my proposal #15 (section scope).

=> I overlooked QS02, see my further comments below.

[rot169]

QS03 covers the TNFL angle, right?

The more I read QS02, the more muddled it appears to me. Feels like QS01, QS02 and QS03 could be wrapped up into two items - one on HNDL and one on TNFL.

[galoisField7]

Yes, you are right, I completely overlooked QS02 :).
Looking at it again, I agree there is significant overlap between QS01 and QS02. I could see them being merged into a single HNDL entry that covers both short-lived and long-lived stored data, with Mosca's Theorem used as the common prioritisation framework.

That would also leave room for a dedicated Trust Now, Forge Later (QS03=TNFL) entry focusing on short- and long-lived signatures, certificates and trust relationships.

[m-khan-97]

Supporting the merge, with one addition on where QS02's content actually goes,
because QS02 is currently straddling both sides of this discussion.

QS02's confidentiality material - long-retention archives, RSA-wrapped AES
stores, Mosca's inequality as the prioritisation frame - folds naturally into a
merged HNDL entry. One entry covering harvest-in-transit and harvest-at-rest,
scoped by confidentiality lifetime rather than by where the ciphertext happens to
sit, reads more cleanly than the current split and removes the boundary nobody
can state crisply.

But QS02's integrity material is already QS03's territory and should move
there explicitly. Specifically: common example 3 (signed artefacts whose validity
must persist - contracts, filings, signed releases, blockchain transactions),
example 4 (identity and credential records, root certificates), and scenario 2
(ECDSA-signed releases forged against a long-lived trust anchor after a CRQC).
That makes QS03 the single signature and trust entry, covering both short- and
long-lived signatures, which is the TNFL framing @galoisField7 described above.

Worth noting that the merge nets ten entries down to nine, so it opens a slot for
Sprint 1 rather than forcing a squeeze - which seems like the right outcome given
how much is being proposed this week.

If there is agreement on that shape, I am happy to draft the merged entry and the
QS03 additions as a PR so there is something concrete to vote on in Sprint 1
rather than a direction.

[nmcitra]

+1 on the merge. QS01 and QS02 are both "confidentiality outlives its protection," and splitting them by where the ciphertext happens to sit never held up.

QS03 as reshaped covers signatures breaking. It doesn't cover what happens next.

A CRQC lands and you start migrating. To issue someone a new PQ certificate, your enrollment flow asks them to prove they control the old one. That proof is a signature from the key you just decided is forgeable. So an attacker presenting a forged old credential walks through the migration and comes out holding a cryptographically strong certificate, with the original identity's roles, delegations, and sessions attached. You've upgraded them.

QS03 covers what gets forged. Accepting that forgery as proof of continuity is a separate step, and it's where authority changes hands.

I come at this from systems architecture rather than cryptography, so I'm unsure where it lands in the taxonomy:

• A subsection of the new QS03, since it falls straight out of it
• With the migration entries, since it's a process failure more than a crypto one
• Its own entry, if it reads as distinct. The merge does free a slot.

I've been working the identity-continuity piece on another project, so it's already drafted against the entry template. My AI assistant and I have been going back and forth on exactly this boundary. @m-khan-97, if you're already writing the merged entry and the QS03 additions, happy to coordinate so we're not duplicating work.

[m-khan-97]

PR up: #38. Merges QS01/QS02 into a single HNDL entry under Mosca's inequality (in-transit and at-rest as the same exposure, differing only in where the ciphertext currently sits), and moves QS02's signature/credential content into QS03 applying the same inequality to integrity rather than confidentiality.

Kept QS03-QS10 filenames and numbers untouched - only QS02 is deleted - so this doesn't force a renumbering decision before Sprint 1 voting has even happened. README notes the freed slot without presuming what fills it.

@galoisField7 you got there first with the TNFL/HNDL split and the "significant overlap" read; @rot169 the original merge proposal was yours. Flagging both of you since this is really just writing up where the thread already landed. Happy to adjust anything that doesn't match your intent.