Public trust for timestamp verification

Timestamp trust is selected through the cryptography library’s CryptoTrustPurpose.TimestampAuthority purpose. It is separate from private signing keys and does not reuse the evidence-bundle signer or enroll a new private key.

Hosts configure a locally provisioned public certificate bundle at Crypto:PublicTrust:CertificateBundles:timestamp-authority. Consumers resolve the purpose through IPurposePublicTrustResolver; feature-specific trust-file options are not used. Missing, empty, unreadable or private-key-containing material fails closed. There is no system-root, unrelated-purpose or network fallback.

Merge the purpose binding into the host’s active JSON configuration, retaining the exact hyphenated purpose name:

{
  "Crypto": {
    "PublicTrust": {
      "CertificateBundles": {
        "timestamp-authority": "/etc/stellaops/trust/timestamp-authority.pem"
      }
    }
  }
}

Mount the public certificate bundle read-only and make it readable by the service UID. For a Production ASP.NET host, the normal configuration file is appsettings.Production.json; preserve the host’s other settings when adding this binding. A shell entrypoint can discard an environment variable whose name contains the hyphen, including Crypto__PublicTrust__CertificateBundles__timestamp-authority. The variable appearing in container metadata therefore does not prove that the application received it. Verify purpose resolution in the actual consumer process with its normal configuration and mounted files before testing timestamp signatures.

The existing CLI --trust-roots selection creates a scoped binding for this same purpose. The library loads public certificates and derives stable SHA-256 identities; the feature does not choose parsing formats or implement certificate trust loading.

CryptoInterop.VerifyRfc3161Timestamp verifies a complete RFC3161 token, TSTInfo, the TSA signature and EKU, and a chain terminating at an explicitly configured root. The timestamp comes from signed TSTInfo genTime, never a generic CMS signing-time attribute. The neutral result exposes the timestamp and root/certificate/token identities; it has no AirGap model dependency. AIA downloads and network revocation retrieval are disabled. Signature and local chain verification do not establish revocation status or bind an external artifact’s message imprint.

The reviewed rfc3161-fixture-x509-cms test carve-out permits only certificate/CMS protocol encoding needed by positive and negative vectors. Fixture keys are generated by the existing central provider, hashes use CryptoHashFactory, randomness uses ICryptoRandom, and private material stays in memory. It adds no product signing API.