RFC 3161 Timestamp Verification

RFC 3161 is an IETF standard for trusted timestamping. It provides independent, cryptographic proof that a piece of data existed at a specific point in time.

ABS Core uses RFC 3161 to seal every governance decision with a timestamp from a trusted third-party authority, making the audit trail resistant to clock manipulation and retroactive tampering.

Why Independent Timestamping

A system that timestamps its own records proves nothing. If the system is compromised, the attacker can modify both the data and the timestamp.

RFC 3161 solves this by delegating timestamping to an independent Time Stamping Authority (TSA):

ABS Core                           TSA (FreeTSA.org / DigiCert)
    |                                    |
    |  1. Hash(SAR block)               |
    |  --------------------------------> |
    |                                    |
    |  2. Signed timestamp token         |
    |  <-------------------------------- |
    |                                    |
    |  3. Store token in SAR             |
    |     rfc3161_token: "..."           |
    |     rfc3161_authority: "FreeTSA"   |

The TSA never sees the original data. It only receives a SHA-256 hash, signs it with its own key and current time, and returns the token.

What the Token Proves

A valid RFC 3161 token proves:

1. The data existed at the stated time -- The TSA certified the hash at that specific timestamp.
2. The data has not been modified -- If the data changes, the hash changes, and the token no longer verifies.
3. The timestamp is independent -- It comes from a trusted third party, not from the system being audited.

These properties are recognized by courts in the EU, US, and most other jurisdictions as admissible evidence.

How ABS Core Uses It

Every SovereignAuditRecord contains:

{
  "rfc3161_token": "MIIRyQYJKoZIhvcNAQcCoIIR...",
  "rfc3161_authority": "FreeTSA.org",
  "temporal_drift_ms": 12
}

Temporal Drift Detection

ABS Core v4.1.0 compares the local timestamp with the TSA response timestamp and records the drift:

A large drift may indicate:

• Clock desynchronization -- NTP misconfiguration
• Time-jump attack -- An attacker manipulating the system clock to backdate or future-date records

Asynchronous Sealing

The governance decision is never blocked by TSA latency:

1. Local decision -- The hash chain is committed immediately with the local timestamp
2. TSA request -- The RFC 3161 token request is sent asynchronously
3. Token enrichment -- When the token arrives, it is attached to the existing record

This ensures:

• Governance latency is unaffected (< 0.015ms P99)
• TSA downtime does not stop the system
• Records without TSA tokens are marked as rfc3161_token: "" (degraded mode)

Verification

To verify an RFC 3161 token independently:

# Using OpenSSL
openssl ts -verify -data record_hash.bin -in timestamp.tsr -CAfile tsa_ca.pem

The standalone SAR Verifier (tools/sar-verifier.html) can also validate RFC 3161 token presence in an air-gapped environment.

TSA Relay Service

The ABS Cloud provides a managed TSA Relay that:

• Routes to the best available TSA (FreeTSA, DigiCert)
• Provides automatic failover if a TSA is down
• Requires no customer configuration

The relay only receives SHA-256 hashes. It never sees the original governance data.

Related

• NIST AI RMF Mapping -- RFC 3161 satisfies MEASURE-2.3
• Sovereign Checklist -- Network connectivity verification
• Air-Gapped Operations -- Operating without TSA access