RFC 3161 Timestamp Authority Support for Certificate Signing

[jzeng4]

Description

Contribution

If this feature request is accepted, we are ready to implement it and submit a pull request. We have already prototyped the signing and verification changes and are prepared to contribute the full implementation including tests and documentation.

What needs to be improved?

Current Gap in Certificate-Based Signing

The model-transparency project currently supports certificate-based signing as an alternative to Sigstore, but lacks support for trusted timestamps, creating several limitations:

1. No Long-Term Signature Validity

• Signatures become invalid when signing certificates expire
• Cannot prove signing occurred while certificate was valid
• No mechanism to extend signature lifetime beyond certificate expiration
• Problematic for archival requirements (5-10+ year model retention)

2. Regulatory Compliance Blockers

• eIDAS (EU): Requires qualified timestamps from approved Timestamp Authorities
• FDA (US): Electronic records regulations (21 CFR Part 11) require trusted timestamps
• Financial Services: Regulations mandate timestamped audit trails
• HIPAA (Healthcare): Requires timestamps for electronic signatures
• Organizations in these sectors cannot adopt model-signing due to lack of timestamp support

3. No Independent Time Attestation

• No third-party proof of when signature was created
• Vulnerable to clock tampering claims
• Cannot provide non-repudiation of signing time
• Missing independent witness required by many compliance frameworks

4. Limited Offline Verification

• Cannot verify signature without trusting local system time
• No cryptographic proof of signing time
• Insufficient for air-gapped or disconnected environments

5. No Alternative to Transparency Logs

For organizations that:

• Cannot use public transparency logs (Rekor) due to privacy requirements
• Need qualified timestamps for compliance (not just transparency)
• Operate in regulated industries with specific timestamp requirements
• Require both certificate-based signing AND trusted timestamps

Result: These gaps prevent enterprise adoption in regulated industries, limiting the project's reach and impact.

---

What should be done?

Proposed Solution: Add RFC 3161 Timestamp Authority Support

Implement RFC 3161 (Time-Stamp Protocol) support for certificate-based signing, enabling:

Signing Enhancement:

• Add optional tsa_url parameter to certificate signer
• Obtain RFC 3161 timestamp token from TSA after signing
• Store timestamp in Sigstore bundle's timestamp_verification_data field
• Support configurable timeout and error handling
• Maintain backward compatibility (timestamps are optional)

Verification Enhancement:

• Validate RFC 3161 timestamp tokens when present
• Verify message imprint matches signature hash
• Check timestamp against certificate validity period
• Optional enforcement of timestamp presence
• Optional timestamp age validation

Benefits

Enables New Use Cases:

• Regulated industries (finance, healthcare, government)
• Long-term model archival (decades)
• Compliance-driven organizations
• Private model signing with qualified timestamps

Expands Project Reach:

• EU market (eIDAS compliance)
• Financial services sector
• Healthcare organizations
• Government contracts

Improves Security Model:

• Independent time attestation
• Long-term signature validity
• Stronger non-repudiation
• Offline verification capability

---

Has there been any related work before?

Prior Art and Related Work

1. Sigstore Bundle Specification Already Supports This

The Sigstore bundle protobuf specification already defines timestamp_verification_data field:

message VerificationMaterial {
  oneof content {
    PublicKeyIdentifier public_key = 1;
    X509CertificateChain x509_certificate_chain = 2;
  }
  repeated dev.sigstore.rekor.v1.TransparencyLogEntry tlog_entries = 3;
  TimestampVerificationData timestamp_verification_data = 4;  // ← Already defined!
}

message TimestampVerificationData {
  repeated RFC3161SignedTimestamp rfc3161_timestamps = 1;
}

This means:

• ✅ The specification anticipates this feature
• ✅ The bundle format already supports it
• ✅ This is not a spec deviation
• ✅ Implementation aligns with Sigstore's design

Reference: https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_bundle.proto#L125-L145

2. Industry Standards and Precedents

Adobe Document Cloud:

• Uses both Adobe timestamps AND RFC 3161 TSA timestamps
• Demonstrates value of dual timestamp approach
• Industry-standard for document signing

Microsoft Authenticode:

• Supports RFC 3161 timestamping since 2005
• Required for driver signing
• Proven model for code signing

PDF Signatures (ISO 32000):

• Standardized RFC 3161 timestamp integration
• Used by Adobe, DocuSign, etc.
• Well-established pattern

---

Any relevant links or material?

Technical Standards

RFC 3161 - Time-Stamp Protocol (TSP)

• URL: https://www.ietf.org/rfc/rfc3161.txt
• Description: Official specification for RFC 3161 timestamp protocol
• Status: IETF Proposed Standard (widely implemented)

Sigstore Bundle Specification

• URL: https://docs.sigstore.dev/about/bundle/
• Protobuf Specs: https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_bundle.proto
• Timestamp Field: Lines 125-145 define timestamp_verification_data

ISO/IEC 18014 - Time-Stamping Services

• Description: International standard for time-stamping
• Relationship: RFC 3161 implements this ISO standard

Regulatory Requirements

eIDAS Regulation (EU)

• URL: https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation
• Article 41: Qualified electronic time stamps
• Impact: Mandatory for legal electronic signatures in EU
• Market Size: 450+ million people in EU

FDA 21 CFR Part 11 (US Healthcare)

• URL: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application
• Requirement: Electronic signatures must be timestamped
• Impact: Healthcare and pharmaceutical ML models

Financial Services Regulations

• SOX (Sarbanes-Oxley): Requires timestamped audit trails
• MiFID II (EU): Timestamp requirements for financial transactions
• Impact: Financial ML models need compliant signatures

---