Post-quantum RFC 3161 timestamping, built on its own dedicated root.

This service is live. Both profiles are reachable over HTTPS at the endpoints in Section 4, and every token they issue has been independently verified end to end. Status is tracked at beatquantum.com/status.

RFC 3161 timestamping binds a cryptographic hash of a document to a trusted time, without ever seeing the document itself: a client sends only a hash, and receives back a signed token proving that hash existed at or before a given moment. A timestamp is only as durable as the signature that carries it. A classical signature does not merely become insecure when a sufficiently capable quantum computer arrives. It fails backwards, retroactively voiding every token it ever issued, including ones stamped and archived correctly decades earlier. BeatQuantum's TSA exists to close that gap: every token this service issues is signed with a post-quantum algorithm, not a classical one held over from the pre-quantum era.

Tokens issued under this disclosure are RFC 3161 time-stamp tokens. They are not qualified electronic time-stamps under Regulation (EU) No 910/2014. BeatQuantum Limited is not listed as a qualified trust service provider on an EU or EEA trusted list, and nothing in this document is a claim of such listing or of conformity with ETSI EN 319 421 as a qualified service.

This TSA is operated as two cryptographic profiles. A relying party chooses the algorithm family that matches its own verification capability. The names below are algorithm profiles. They are not national or Union qualification schemes.

Both profiles are lattice- or hash-based, category-5-strength assurance throughout their chain, and neither carries a classical signature component at any tier: a client unable to parse a post-quantum signature cannot verify a post-quantum-signed chain either, so this service does not offer a classical-compatible fallback token. A second, independent stamp from the other profile (lattice-based and hash-based respectively) is the recommended way to hedge against a future cryptanalytic advance against either family individually.

This TSA is anchored at a dedicated root, R3, used for no purpose other than timestamping. It is not a branch of either certificate chain described in BeatQuantum's Certificate Practice Statement: those roots also anchor ordinary TLS and client-certificate issuance, on a different validity schedule, and one of them carries a classical component that this TSA's SLH-DSA profile deliberately does not. Keeping timestamping on its own root means a certificate's presence under R3 always means the same thing.

The root's own algorithm is chosen independently of either profile: a hash-based signature rests on the most conservative assumption available in post-quantum cryptography, and R3 is the single most consequential key in this structure, since its compromise would affect both profiles at once. Each Time Stamp Unit (TSU) certificate carries the critical Extended Key Usage id-kp-timeStamping and no other purpose, and is issued for three years.

Download the chain

Each bundle contains the issuing CA, intermediate, and root certificates for that profile, in the order a verifier needs, everything -CAfile requires for the recipe in Section 5, but not the TSU leaf itself, which travels inside each token.

• CNSA 2.0 profile: chain-cnsa.pem
• SLH-DSA profile: chain-eu.pem
• R3 root certificate alone: beatquantum-tsa-root-r3.crt, fingerprint and further detail at beatquantum.com/status

This service takes its primary time from BeatQuantum's own post-quantum-authenticated Network Time Security (NTS) source, cross-checked continuously against at least two independent external NTS or NTP sources so that a fault in the primary source is detected rather than silently trusted.

If clock offset exceeds policy, or the primary source has not synchronised within its policy age, the service refuses new tokens rather than sign with a clock it cannot vouch for. RFC 3161 requires only that a TSA's time be "trustworthy"; this service goes further. Declared accuracy is sub-millisecond — several orders of magnitude tighter than the one-second floor the relevant standards ask for.

• Endpoints: https://tsa.beatquantum.com/cnsa (CNSA 2.0 profile) and https://tsa.beatquantum.com/eu (SLH-DSA profile). The /eu path is a stable identifier for that profile; it does not denote an EU qualified service. POST a DER TimeStampReq with Content-Type: application/timestamp-query; the response is a DER TimeStampResp with Content-Type: application/timestamp-reply.
• Hash algorithms accepted: SHA-256, SHA-384, SHA-512. SHA-1 and MD5 are rejected outright, not merely discouraged.
• Requester identity: never included in a token, and never recorded against a token in the issuance log. This service sees only the hash it is asked to stamp.
• Nonce: echoed unchanged in every token where the request supplied one.
• Policy OID: 1.3.6.1.4.1.66626.1.1 for the CNSA 2.0 profile and 1.3.6.1.4.1.66626.1.2 for the SLH-DSA profile, under BeatQuantum's IANA Private Enterprise Number 66626.
• Transport: HTTPS only. RFC 3161 makes every transport mechanism optional, and this is a positioning choice, not a security one. The token authenticates itself independently of the channel it arrived on.

Every operation below has been tested against real tokens issued under this chain. Given a token you have received (token.der) and the published chain for its profile (chain.pem: issuing CA, intermediate, and root), verification with a stock, unmodified OpenSSL 4 installation is:

openssl cms -verify -in token.der -inform DER \
  -CAfile chain.pem -purpose timestampsign -out /dev/null

This checks signature validity, chain of trust to R3, and enforcement of the timestamping-only Extended Key Usage. It does not fetch a CRL or query OCSP. A relying party that also wants current revocation status must obtain the CRLs in Section 6 and apply them with the verifier's own CRL options (for example -crl_check / -crl_check_all when using OpenSSL), at the time of verification they care about.

The openssl ts -verify command will not work on a post-quantum token. That command verifies signatures through OpenSSL's legacy certificate-verification path, which has no support for the ML-DSA or SLH-DSA signature algorithms. The failure is architectural, in tooling that predates these algorithms, not a defect in what this service issues. Use the cms -verify recipe above; a wrapper that adds the remaining RFC 3161 checks (message imprint, nonce, genTime) is on the roadmap.

A timestamp token embeds the TSU certificate that signed it, and verification checks whether that certificate was valid at the token's own claimed time, not whether it is valid today. A token therefore remains verifiable after its signing certificate expires. That property is the basis of timestamping, and it is why this service does not pursue long-lived signing certificates: a long-lived key held in service for decades would be a larger compromise surface for no corresponding benefit.

R3 is sized to a horizon of 2046, matching BeatQuantum's other published roots, with a succession programme committed to begin no later than 2040 and old and new roots running in parallel for several years thereafter. Relying parties who verify against the full published chain, rather than pinning an intermediate or issuing certificate directly, are unaffected by intermediate or issuing-CA rotation and need only act when R3 itself is succeeded.

Revocation

This TSA publishes Certificate Revocation Lists over HTTP. It does not operate an OCSP responder for the R3 hierarchy. Status of TSU, issuing-CA and intermediate certificates is carried in the CRLs below. A root is not revoked through this mechanism; untrusting R3 means removing it from the trust store used for verification.

• R3: http://crl.beatquantum.com/tsa-root.crl
• CNSA 2.0 intermediate: http://crl.beatquantum.com/tsa-intermediate-cnsa.crl
• SLH-DSA intermediate: http://crl.beatquantum.com/tsa-intermediate-eu.crl
• CNSA 2.0 issuing CA: http://crl.beatquantum.com/tsa-issuing-cnsa.crl
• SLH-DSA issuing CA: http://crl.beatquantum.com/tsa-issuing-eu.crl

CRLs are served on port 80 only. Clients should not expect an HTTP to HTTPS redirect. If a TSU private key is compromised, the corresponding TSU certificate is revoked with reason keyCompromise. Tokens produced after that revocation time should be rejected. Tokens produced before it may still be accepted if the relying party's policy treats the revocation time as the cut-off, which is the model in RFC 3161 when a reason code is present.

• R3's root key is held offline, encrypted, and disconnected from any network. It is not resident on any server operated by BeatQuantum.
• Intermediate and issuing CA keys are encrypted at rest under dual control and held outside the network-facing service.
• TSU signing keys are dedicated exclusively to timestamping, generated and used under dual control, and are never used for any other purpose.
• No key material in this hierarchy is transmitted over any network in unencrypted form at any time.

Nothing in RFC 3161 mandates a certified hardware module for TSA key protection; that requirement appears only in policy regimes a TSA opts into, such as national qualification schemes or browser root programmes, neither of which BeatQuantum currently participates in for this service. The protections above are the ones actually in force, stated as what they are.

Per token, this service records the serial number, the time asserted in the token, the policy identifier, the hash algorithm and message imprint, whether a nonce was present, the token size, and the measured clock offset at the moment of signing. Each start of a responder records the signing certificate's subject, SHA-256 fingerprint and expiry, which binds every subsequent record to a specific key. Clock synchronisation, loss of synchronisation and recovery are recorded as they occur, as is every rejected request together with the reason it was refused.

A requester's identity and IP address are never recorded, and no account or registration is required to use this service. The message imprint is recorded because the token already carries it; nothing about the submitted data is recorded or derivable beyond that.

Each record is written and flushed to disk before its token is returned, so no token reaches a client without its record already durable. The file is append-only at the filesystem level: entries cannot be rewritten or removed without a deliberate administrative act, an administrator included. Records are retained for seven years beyond the expiry of the signing certificate under which they were made, to 24 August 2036 for the certificates in use today. Within that period records may be moved to offline archival storage, where they remain available on legitimate legal demand.

Both HTTPS endpoints in Section 4 are live and issuing real post-quantum tokens, verified end to end against the published chain. The network time watchdog and the issuance log are live. Status and milestones are tracked at beatquantum.com/status.

BeatQuantum accepts no liability in connection with the issuance, use, reliance upon, or unavailability of any token issued under this TSA, and provides it "as is", without warranty of any kind, to the fullest extent permitted by applicable law.

Any party that relies upon a token issued by this service, including any party that installs the R3 root certificate into a trust store, does so at their own risk.

This document and any dispute or claim arising out of or in connection with it, its subject matter, or its formation (including non-contractual disputes or claims) shall be governed by and construed in accordance with the laws of England and Wales, and the courts of England and Wales shall have exclusive jurisdiction over any such dispute or claim.

BeatQuantum reserves the right to amend this document at any time. The version number and effective date in the Document Information table will be updated with each amendment. Material amendments will be announced at beatquantum.com/status with at least 7 days' notice before taking effect, except where an amendment is required urgently for security reasons, in which case it takes effect immediately upon publication.

Questions about this service? Contact BeatQuantum at contact@beatquantum.com. For build status and announcements see beatquantum.com/status. For BeatQuantum's certificate-issuance CA, which this document does not cover, see the Certificate Practice Statement.