In M1 you saw the “harvest now, decrypt later” (HNDL) threat: the risk of traffic encrypted today being recorded and decrypted in the future with a quantum computer. This lesson shows a different threat model for signatures; we move from TLS’s question “who is listening today” to S/MIME and code signing’s question “will this signature stay non-repudiable for years”.
A different threat from TLS: not “sign now, forge later” but “lifetime risk”
How HNDL works for TLS is clear: today’s encrypted traffic is recorded and decrypted in the future. That logic does not apply directly to signatures; there is no such thing as “recording a signature and decrypting it later”, because a signature is already public. The real risk is different: if a signing key is classical (RSA/ECDSA) and a document or code signed with it must stay valid for years, then when a quantum computer breaks that key in the future, every signature made with it becomes questionable; and if the broken key is still accepted as “belonging to that person or organization”, new forged signatures can be produced too. This is a risk that accumulates over the signature’s lifetime, different from TLS’s “today’s connection” risk.
RFC 3161: a time-stamp, validity beyond the certificate
When a signing certificate’s own validity period expires (and, as you saw in M7, it is getting shorter), the signature itself may automatically be considered invalid, because the verifier cannot answer “was this signature made while the certificate was still valid”. RFC 3161 (August 2001, long in force) solves this: an independent TSA (Time-Stamp Authority) attests with its own signature that a document or signature existed at a particular moment. If this time-stamp exists, the verifier can trust that “the signature was made while the certificate was still valid”, even if the certificate itself expired long ago.
The extra layer PQC adds: the time-stamp itself must be PQC
There is a subtle but critical point here: a time-stamp is itself a signature, made with the TSA’s own key. If the TSA’s signature is still classical (RSA/ECDSA), the assurance “it existed at this particular moment” also becomes questionable once the TSA’s key is broken. So moving a code signing chain to PQC must cover not only the end-user signing certificate but also the time-stamp authority’s own signature; if one is PQC and the other stays classical, the weakest link of the chain stays classical.
Why code signing may come earlier than TLS
CNSA 2.0’s own schedule, which you saw in M6, makes this difference concrete: CNSA 2.0, with SELECTED2025-05-30 status, requires software/firmware signing to move exclusively to PQC by the end of 2030SOURCED, 3 years earlier than the 2033SOURCED date for OS/web/cloud services. The logic is the lifetime difference you saw above: a web server’s TLS certificate is now short-lived (as you saw in M7, dropping to 47 days in 2029), but a firmware package signed today can stay on a device running in the field for decades; that longer exposure window requires an earlier transition. When defending this prioritization to a bank, show that the opposite of the assumption “we have handled TLS, code signing can wait” is the defensible position.
Numbers to know
CNSA 2.0's own schedule (which you saw in M6): software/firmware signing must move exclusively to CNSA 2.0 (PQC) by 2030; that is earlier than the 2033 date for OS/web/cloud, because the signature-lifetime threat carries a different urgency from the TLS moment-of-connection threat
Lab: Examine a time-stamped signature in your own environment
[not run] Requires access to a real RFC 3161 TSA (time-stamp authority) server, which is outside this course's scope; a conceptual review exercise
# Review your own organization's code signing process: does a signed binary or package include a time-stamp? (If there is a .tsr file it can be verified with openssl ts -reply)
Recorded output
If there is a time-stamp, the signature stays valid even after the signing certificate expires; if not, the signature itself becomes questionable once the certificate expires
At the table
How to say this in a bank meeting.
To an executive
TLS's urgency is the question 'who is listening to today's traffic' (harvest now, decrypt later); the urgency of code signing and S/MIME is a different question: 'how do we guarantee that something we sign today is still non-repudiable years from now.' If we miss this difference, we will migrate our signing infrastructure with the wrong priorities.
To an architect
A time-stamp (RFC 3161) has an independent third party (a TSA) attest that a signature existed at a particular moment; that lets the signature stay valid even after the signing certificate expires. But the time-stamp is itself a signature; if the TSA's own signature is classical, it can be broken in the future, and then the assurance the time-stamp gives collapses too. So TSAs' own signatures also need to move to PQC, not just end-user certificates.
Objection
“"We have moved our TLS certificates to PQC. Code signing doesn't have the same priority; it can wait."”
Answer
It may be the opposite: TLS certificates are now short-lived (as you saw in M7, 47 days in 2029), so the risk of a TLS certificate being broken sits in a limited window. But a software package or contract we sign today is a document that must stay non-repudiable for years (sometimes decades); that longer life means longer exposure to the risk of the classical signature being broken. CNSA 2.0's own schedule reflects this: software/firmware signing must move exclusively to PQC 3 years earlier (2030 versus 2033) than general web/OS/cloud.
NSA, 2025. The source of this lesson's main argument: why software/firmware signing (2030) has an earlier exclusive-PQC date than OS/web/cloud (2033)
transition schedule / 5 min
Commercial stake: NSA is publishing a requirement for its own national security systems; as noted in M6, the primary PDF could not be accessed directly for this course (Access Denied), and the dates are passed on from converging secondary sources
Checkpoint
Answer first, then compare with the model answer and score yourself against the rubric. Saved in this browser only.
01Recall
Why is the threat model of TLS (harvest now, decrypt later) different from that of code signing?
Model answer
In TLS, HNDL is the risk of today's encrypted traffic being recorded and decrypted in the future. That does not apply directly to signatures, because a signature is already public; the real risk is that a classical signing key protecting a signature that must stay valid for years is broken in the future, making every signature made with that key questionable.
02Recall
How does an RFC 3161 time-stamp extend a signature's lifetime?
Model answer
An independent TSA (Time-Stamp Authority) attests with its own signature that a signature existed at a particular moment. That lets the verifier trust that the signature was made while the certificate was still valid, even if the signing certificate has since expired.
03Scenario
In 2020 your bank distributed a software package signed with RSA and without a time-stamp, and it still runs in production. Once the quantum computer threat becomes concrete, what is the risk to this package's signature?
Model answer
Because there is no time-stamp, the signature automatically becomes questionable once the signing certificate expires, since it cannot be proven that it was made while the certificate was still valid. Once a quantum computer breaks the RSA key, this package's signature, like every signature made with the broken key, becomes questionable; both the certificate expiry and the key itself create risk.
A complete answer includes
Your score: 0/2
04Hostile
An architect says 'Code signing can wait; TLS is the priority.' Push back on this prioritization using CNSA 2.0's own schedule.
Model answer
CNSA 2.0's own schedule says the opposite: software/firmware signing must move exclusively to PQC by 2030, 3 years earlier than the 2033 date for OS/web/cloud. The reason is the difference in lifetime: TLS certificates are now short-lived (dropping to 47 days in 2029), but a firmware package signed today can run in the field for decades, and that longer exposure window requires an earlier transition.
A complete answer includes
Your score: 0/3
Project linkContributes to the signature-lifetime risk classification of Project 3 (crypto inventory and prioritization), as a priority category separate from TLS.