RFC-3161 Timestamp Policy Assertions
Audience: Policy authors and Attestor operators who write or review timestamp-validation rules.
Purpose: Describe the timestamp policy context fields, the assertions they back, the built-in defaults, and the offline verification contract.
Overview
Attestation timestamp policy rules validate RFC-3161 evidence alongside Rekor inclusion proofs. The policy surface is backed by AttestationTimestampPolicyContext and TimestampPolicyEvaluator in StellaOps.Attestor.Timestamping.
Context fields
AttestationTimestampPolicyContext exposes the following fields:
| Field | Type | Description |
|---|---|---|
HasValidTst | bool | True when RFC-3161 verification succeeded. |
TstTime | DateTimeOffset? | Generation time from the timestamp token. |
TsaName | string? | TSA subject/name from the TST. |
TsaPolicyOid | string? | TSA policy OID from the TST. |
TsaCertificateValid | bool | True when TSA certificate validation passes. |
TsaCertificateExpires | DateTimeOffset? | TSA signing cert expiry time. |
OcspStatus | string? | OCSP status (Good/Unknown/Revoked). |
CrlChecked | bool | True when CRL data was checked. |
RekorTime | DateTimeOffset? | Rekor integrated time for the entry. |
TimeSkew | TimeSpan? | RekorTime - TstTime, used for skew checks. |
Example assertions
The policy engine maps the context into evidence.tst.* fields. Example rules:
rules:
- id: require-rfc3161
assert: evidence.tst.valid == true
- id: time-skew
assert: abs(evidence.tst.time_skew) <= "5m"
- id: freshness
assert: evidence.tst.signing_cert.expires_at - now() > "180d"
- id: revocation-staple
assert: evidence.tst.ocsp.status in ["good","unknown"] && evidence.tst.crl.checked == true
- id: trusted-tsa
assert: evidence.tst.tsa_name in ["Example TSA", "Acme TSA"]
Built-in policy defaults
TimestampPolicy.Default enforces:
RequireRfc3161 = trueMaxTimeSkew = 5 minutesMinCertificateFreshness = 180 daysRequireRevocationStapling = true
Offline RFC-3161 Verification Contract
Attestor timestamp verification is fail-closed. A timestamp is valid only when the RFC-3161 CMS token can be decoded, the embedded TSTInfo message imprint matches the attestation envelope digest, the CMS signature verifies, and the TSA signing certificate chains to an explicit offline trust anchor.
Verification callers must provide trusted TSA roots through AttestationTimestampVerificationOptions.TrustedTsaCertificates. Intermediate certificates may be embedded in the CMS token or supplied through ExtraTsaCertificates. If no trust anchors are configured, verification returns Untrusted; malformed, empty, bad-imprint, bad-signature, and expired certificate cases also return explicit failure statuses.
Offline mode does not fetch OCSP or CRL material. When revocation checking is requested in an offline run, Attestor records that verification used the configured trust-anchor set and does not treat network revocation as available. Bundles that require stronger revocation evidence must carry that evidence in the bundle and enforce it through policy.
References
- Offline Verification Guide
- Attestor Architecture
- Source:
src/Attestor/__Libraries/StellaOps.Attestor.Timestamping/AttestationTimestampPolicyContext.cs - Source:
src/Attestor/__Libraries/StellaOps.Attestor.Timestamping/AttestationTimestampVerificationOptions.cs
