Code Signing Timestamping Standards and Requirements
Trusted timestamping gives a software signature evidence of when the signing operation occurred. This reference explains the standards, trust model, cryptographic requirements, implementation controls, and verification checks that publishers should evaluate before relying on a timestamp.
Standards That Govern Code Signing Timestamping
Timestamping for software signing sits across several layers. RFC 3161 defines the Time-Stamp Protocol and the structure of code signing timestamping evidence. Certificate and trust requirements come from the applicable public PKI ecosystem, while platforms and signature formats determine how timestamp evidence is embedded and evaluated.
| Standard / requirement | What it governs | Why publishers care |
|---|---|---|
| RFC 3161 | Timestamp protocol and token structure | Defines how signing-time evidence is requested and issued. |
| CA/Browser Forum | Public code-signing ecosystem requirements | Provides requirements affecting participating CAs and public trust. |
| Cryptographic standards | Hashes, signatures, and keys | Determines whether the cryptography remains acceptable for the intended use. |
| Platform requirements | Signature and timestamp processing | Determines whether the target verifier recognizes and accepts the timestamp. |
Why Software Signatures Need Trusted Timestamps
A code signing certificate has a finite validity period, but software can remain distributed and verifiable for much longer. The signing system therefore needs evidence that connects the signature to a point in time when the signing credential was acceptable.
Signature + certificate expiry
A later verifier may see that the signing certificate is no longer within its ordinary validity period, making historical verification more difficult.
Signature + timestamp evidence
The timestamp provides cryptographically protected evidence of the signing time, allowing the verifier to evaluate whether the signature was created while the certificate was valid under the applicable verification rules.
How RFC 3161 Timestamping Works
RFC 3161 defines the Time-Stamp Protocol, commonly called TSP. A timestamp request contains a message imprint, which is a hash-based representation of the data for which time evidence is requested. The TSA processes the request and returns a signed TimeStampToken.
Publishers should understand the important fields involved in the protocol: message imprint, hash algorithm, timestamp policy, serial number, genTime, accuracy when provided, nonce where used, extensions, TSA identity, and the TSA signature.
What a Timestamp Actually Covers
A TSA does not necessarily receive the entire software file. The timestamp request can carry a message imprint representing the data being timestamped. The resulting token is cryptographically related to that imprint.
Message imprint
The relevant signed data is represented by a cryptographic hash rather than requiring the TSA to process the full software artifact.
TSA response
The TSA issues a TimeStampToken containing the imprint, time information, policy information, and its signature.
Signature relationship
The verifier checks that the timestamp evidence corresponds to the expected signed data. Changing signed content can break that relationship.
Fields That Make Up a Timestamp Token
The token is more than a date string. Its fields allow a verifier to determine what was timestamped, when the TSA says it processed the request, which policy applies, and whether the TSA's cryptographic signature validates.
| Element | Purpose |
|---|---|
| Message imprint | Identifies the data represented by the timestamp request. |
| Hash algorithm | Defines how the message imprint was calculated. |
| GenTime | Records the TSA-issued timestamp generation time. |
| Serial number | Uniquely identifies the token. |
| TSA signature | Protects the integrity and authenticity of the timestamp token. |
| Policy identifier | Identifies the TSA timestamping policy under which the token was issued. |
| Accuracy | Can communicate the time accuracy asserted by the TSA. |
| Nonce | Can help correlate a response with a particular request when used. |
Requirements for a Timestamp Authority
A Certificate Authority is a different trust service from the Timestamp Authority that issues time evidence for a publisher’s code-signing certificate. The TSA operates the timestamping service, maintains its timestamping certificate and signing key, and provides the time evidence represented by the token.
Cryptographic boundary
The TSA signing key requires controlled protection and an operational security model appropriate to the service.
Time source
The TSA needs a controlled source of time and procedures supporting the accuracy represented by its timestamping service.
Trust and operations
Certificate lifecycle, trust chain, availability, auditability, and status handling all affect whether relying systems can validate the service.
How Verifiers Establish Timestamp Trust
Timestamp verification depends on the certificate chain and several other checks, not a single check. The verifier must establish that the token is intact, corresponds to the expected message imprint, has a valid TSA signature, and chains to a trust anchor accepted for the intended purpose.
Code Signing Certificates and Timestamp Certificates
| Code Signing Certificate | Timestamp Certificate | |
|---|---|---|
| Issued for | Software publisher | Timestamp Authority |
| Main purpose | Authenticate the signer | Establish trusted signing time |
| Private key used by | Publisher | TSA |
| Identifies | Publisher | TSA |
| Signs | Software/signature data | Timestamp token |
| Main trust question | Who signed this? | What trusted time evidence exists? |
Choose a signing approach that fits your release process
Compare certificate options and signing approaches against your platform, key protection needs, and software distribution workflow.
Compare Code Signing Certificate OptionsHow Timestamping Relates to Certificate Expiration
Certificate expiration makes timestamping especially useful because certificate validity has a time boundary. A timestamp can provide evidence that signing occurred during the certificate's valid period, subject to the verification rules and trust information applicable to the signature.
Signed and timestamped before expiration
The verifier can use the timestamp as historical signing-time evidence when evaluating the signature.
Signed without timestamp
The verifier has less independent evidence about when the signing operation occurred.
Signed after expiration
A timestamp cannot retroactively move the signing operation into an earlier validity period.
How Timestamping Relates to Certificate Revocation
Certificate revocation needs separate treatment from ordinary expiration. A timestamp can provide evidence about when signing occurred, but it does not provide a defense for a signature created by an attacker after a key compromise.
Cryptographic Requirements for Trusted Timestamps
RFC 3161 defines the timestamp protocol; it should not be treated as a universal statement that one particular hash or signature algorithm is always required. Algorithm acceptability can come from profiles, policies, certificate requirements, platform rules, and current cryptographic guidance.
Message imprint
Evaluate the hash algorithm used to create the message imprint and whether it remains acceptable for the intended signing environment.
TSA signature
Evaluate the algorithm used by the TSA to sign the timestamp token and whether target platforms can validate it.
Weak or deprecated algorithms
Older algorithms may create interoperability or security problems even when the protocol itself supports them.
Migration
Long-lived signing systems should have a plan for cryptographic changes rather than assuming today's algorithms will remain acceptable indefinitely.
Trusted Timestamping Compared With Local Signing Time
A signing-time attribute and a trusted timestamp are not the same thing. A signing environment may record a local time value, but a relying system should not automatically treat the local computer's clock as independent trusted time evidence.
Time associated with the signing environment
It can describe when the signer says the operation occurred, but it is not equivalent to an independently issued TSA timestamp.
Cryptographically protected TSA assertion
The TSA processes the timestamp request and returns signed evidence containing the timestamping information and the message imprint.
How Platforms Validate Timestamp Evidence
Timestamp handling depends on the signature format and target platform. The implementation question is not simply whether a timestamp exists, but where it is stored, how the verifier extracts it, and which certificate and time information the verifier evaluates.
| Environment | What to verify | Publisher question |
|---|---|---|
| Windows / Authenticode | Timestamp representation in the signature and Windows verification behavior. | Does the signed artifact verify correctly on a clean supported Windows environment? |
| Java / JAR | Timestamp information associated with the JAR signature and Java verification behavior. | Does the target Java runtime validate the signature and timestamp chain? |
| macOS | Timestamp handling within the applicable Apple signing and distribution workflow. | Does the intended macOS verification and distribution path accept the resulting signature? |
| Other formats | Signature-specific timestamp encoding and verifier support. | Does the target ecosystem define and recognize the timestamp evidence being used? |
RFC 3161 Compared With Other Time Evidence
Not every time claim provides the same type of evidence. RFC 3161 timestamping uses a defined protocol and signed timestamp token. A local system clock, a generic signed time field, or a public ledger may provide different properties and should not automatically be treated as equivalent evidence for software signature validation.
RFC 3161 timestamping
Structured protocol exchange with a TSA and a signed TimeStampToken.
Platform-specific profiles
Signature formats may define how timestamp evidence is embedded and interpreted.
Local system time
A local clock is not the same as independently issued TSA evidence.
Public-ledger timestamping
Can provide a different form of public time evidence, but does not automatically satisfy a software-signing verifier's timestamp requirements.
Timestamping Checks for Software Publishers
Before relying on a timestamp service, a publisher should verify both the protocol and the complete trust path used by the target platforms.
Building Timestamping Into CI/CD
Timestamping should be part of the software signing pipeline rather than an optional manual step after deployment. A practical pipeline is Build → Sign → Timestamp → Verify → Release.
CI/CD integrations should define timeout behavior, retry behavior, release blocking, multiple signing environments, cloud code signing or HSM integration, isolated runners, and logging. If timestamping is required for the release policy, an unavailable TSA should not silently produce an unsigned or improperly timestamped release.
Diagnosing Timestamp Server Failures
Timestamp failures should be diagnosed from the request outward. A successful network connection does not prove that the returned token is valid, and a token that validates cryptographically may still fail platform trust evaluation.
Typical failures include timeout, network errors, invalid TSA responses, untrusted TSA certificates, invalid tokens, unsupported algorithms, incorrect message imprints, certificate-chain failures, and timestamps that are present but rejected during final verification.
How to Verify Timestamp Evidence
Verification should inspect the evidence instead of stopping at “timestamp present.” The goal is to determine whether the token is correctly bound to the signed data and trusted by the target verification environment. Publishers should also verify the final artifact using the relevant signature verification process.
Timestamping Considerations by Use Case
| Scenario | Timestamping consideration |
|---|---|
| Internal software | Depends on the trust and distribution model. |
| Public Windows software | Strongly relevant to long-lived signature verification. |
| Commercial desktop software | Important when signatures need to remain verifiable after certificate expiration. |
| CI/CD releases | Should be integrated into the signing pipeline where required. |
| Long-lived software | Especially important because verification may occur long after release. |
| Frequently updated applications | Relevant to every release that relies on code signing. |
| Incident-sensitive environments | Requires careful validation of timestamp and revocation behavior. |
Distinguishing Standards From Recommendations
Credible technical guidance should distinguish requirements from recommendations. A control can be a formal requirement in one certificate profile or platform and merely a strong security practice in another environment.
Standard/profile
Required by the specific rule set that governs the certificate or service.
Verifier
Required for acceptance by the target software or operating system.
Risk reduction
A control recommended because it improves security even when not universally mandated.
Release process
A process control that improves reliability, traceability, and incident response.
Keeping Timestamping Standards Current
Timestamping guidance needs periodic review. Protocol specifications, CA/Browser Forum requirements, hash algorithms, platform trust stores, TSA certificate policies, and cryptographic guidance can change independently.
Standards maintenance record
Last reviewed: October 2026
Standards reviewed: RFC 3161, current CA/Browser Forum code-signing requirements, applicable TSA policy, target platform documentation, and relevant cryptographic guidance.
Next review trigger: Major CA/Browser Forum, RFC, TSA policy, cryptographic, or platform trust change.
Timestamping Compliance Checklist
✓ Timestamp protocol supported
✓ Correct request and response format
✓ Current acceptable hash algorithm
✓ Appropriate TSA signature algorithm
✓ TSA certificate trusted
✓ Chain validates
✓ Timestamp policy is appropriate
✓ Timestamp attached to final signature
✓ Message imprint matches signed data
✓ Timestamp failures are handled
✓ CI/CD behavior is defined
✓ Verification is tested
✓ Certificate expiration is considered
✓ Revocation scenarios are considered
✓ Standards are reviewed periodically
Authoritative Timestamping References
Use authoritative sources for the governing details. Each reference should have a clear purpose rather than appearing as an undifferentiated bibliography.
RFC 3161
Use for the Time-Stamp Protocol, timestamp request, message imprint, token structure, and protocol semantics.
CA/Browser Forum
Use for current public code-signing requirements and applicable certificate ecosystem rules.
Platform documentation
Use Microsoft, Java, Apple, and other target-platform documentation to verify how timestamp evidence is embedded and evaluated.
Also review relevant TSA policies or practice statements and current cryptographic standards or guidance that apply to the signing environment.
Protect signing keys across automated releases
For teams signing software through build systems, evaluate remote signing and controlled key storage as part of the release architecture.
Explore Cloud Code Signing