Operational and legal framework for experimental certificate issuance.

BeatQuantum is not a CA approved by the CA/Browser Forum. Certificates issued by BeatQuantum are not trusted by default in any browser, operating system, or application. Users and relying parties who choose to install the BeatQuantum root certificate do so entirely at their own risk and discretion.

This Certificate Practice Statement (CPS) describes the practices and procedures by which BeatQuantum operates its Public Key Infrastructure (PKI) and issues X.509 digital certificates. It is intended to provide transparency to subscribers, relying parties, and the public regarding BeatQuantum's certificate lifecycle management.

BeatQuantum operates two certificate chains:

• Option A — Pure Post-Quantum (ML-DSA): a three-tier hierarchy rooted at a FIPS 204 ML-DSA-87 root CA, aligned with NIST, NCSC UK, and CNSA 2.0 guidance.
• Option B — Hybrid Post-Quantum (SLH-DSA / p384_mldsa65): a three-tier hierarchy rooted at a FIPS 205 SLH-DSA-SHA2-256s root CA with hybrid EC+ML-DSA intermediate and issuing CAs, aligned with BSI (Germany) and ANSSI (France) hybridisation requirements.

1.1 Compliance Profiles

The two chains are operated as named compliance profiles, so that subscribers and auditors can map each chain directly to the regulatory regime it follows:

The two profiles embody deliberately different transition philosophies — CNSA 2.0 rejects hybridisation while the principal European authorities mandate it — and operating both in parallel is itself part of BeatQuantum's research mission. Subscribers select a profile at CSR submission (Option A or Option B).

BeatQuantum is not a member of any browser root programme. It is not subject to the CA/Browser Forum Baseline Requirements except where BeatQuantum voluntarily adopts those requirements as best practice, as noted throughout this document.

Certificates issued by BeatQuantum are strictly for experimental and research purposes only. Permitted uses include cryptographic agility testing, post-quantum cryptography migration planning, algorithm evaluation, and academic or technical research.

Certificates must not be used in any production environment, for any commercial service, or in any context where their untrusted status could cause harm to end users or third parties.

By submitting a Certificate Signing Request (CSR) to BeatQuantum, the subscriber accepts and agrees to these acceptable use terms in full.

End-entity certificates are issued for a fixed duration up to the prevailing maximum validity period defined in the CA/Browser Forum Baseline Requirements §6.3.2, which BeatQuantum adopts voluntarily as best practice. The current schedule is:

BeatQuantum issues certificates for a duration slightly below each cap to account for clock skew and rounding. Future certificate renewals may therefore be issued for a shorter period as the schedule progresses. Subscribers should plan for increasingly frequent renewals in line with the industry-wide move toward shorter certificate lifetimes — itself an important driver for crypto-agility research.

CA certificates have the following validity periods: Root CA — 20 years; Intermediate CA — 10 years; Issuing CA — 10 years.

BeatQuantum accepts CSRs signed with the following algorithm classes. The research value of a certificate depends in part on the algorithm chosen. Subscribers should consult the User Guide for detailed guidance on algorithm selection for specific research scenarios, including a comparison of recommended, experimental, and weak algorithms.

4.1 Standardised Post-Quantum Algorithms

These algorithms have completed NIST standardisation and carry formal regulatory endorsement from one or more Western cryptographic authorities. They are the recommended choice for post-quantum migration readiness research.

• ML-DSA-44, ML-DSA-65, ML-DSA-87 (FIPS 204)
• SLH-DSA-SHA2-128f/s, SLH-DSA-SHA2-192f/s, SLH-DSA-SHA2-256f/s (FIPS 205)
• SLH-DSA-SHAKE-128f/s, SLH-DSA-SHAKE-192f/s, SLH-DSA-SHAKE-256f/s (FIPS 205)

4.2 Pipeline Post-Quantum Algorithms

These algorithms have been selected by NIST but standardisation is not yet finalised. Parameter sets or object identifiers (OIDs) may change before the final standard is published. Certificates using these algorithms may require replacement when the standard is finalised.

• Falcon-512, Falcon-1024, FalconPadded-512, FalconPadded-1024 (draft FIPS 206 / FN-DSA)

4.3 Hybrid Post-Quantum Algorithms

These combine a classical elliptic-curve algorithm with a post-quantum algorithm in a single key and signature. They are required by BSI (Germany) and ANSSI (France) during the post-quantum transition period. Hybrid algorithms are not yet IANA-registered and may exhibit compatibility issues outside controlled research environments — which is precisely what makes them valuable subjects for research.

• p256_mldsa44, p384_mldsa65, p521_mldsa87
• p256_falcon512, p521_falcon1024
• RSA-3072 hybrid variants are accepted but discouraged due to significant performance penalties (approximately 16× slower key generation than EC-hybrid equivalents); see Section 4.5.

4.4 Experimental Algorithms (NIST Additional Signatures Round 2)

These algorithms are under active NIST evaluation as additional signature candidates. They carry no current regulatory backing and parameter sets may change or an algorithm may not proceed to standardisation. Certificates using these algorithms are the most experimental category and are appropriate for algorithm comparison and cryptographic diversity research.

• MAYO-1, MAYO-2, MAYO-3, MAYO-5
• CROSS variants
• SNOVA variants
• UOV / OV variants — non-compressed variants produce very large key sizes (up to 415 KB private key); consult the User Guide before selecting these.

4.5 Classical Algorithms

Classical algorithms provide no quantum resistance but are accepted to support interoperability testing and migration pathway research. Their inclusion allows direct comparison between classical and post-quantum certificate behaviour in the same research environment.

• ECDSA P-256, P-384, P-521 — accepted
• Ed25519, Ed448 — accepted
• RSA-4096 — accepted
• RSA-3072 — accepted with notice that this provides no quantum resistance
• RSA-2048 and below — not accepted; these do not meet current classical security baselines

4.6 Stateful Hash-Based Signature Algorithms (NIST SP 800-208)

BeatQuantum operates an offline signing capability based on the stateful hash-based signature schemes of NIST SP 800-208: LMS/HSS (RFC 8554) and XMSS/XMSS^MT (RFC 8391). These schemes are the first algorithms mandated by CNSA 2.0 (for firmware and software signing) and are recommended equally by BSI TR-02102-1.

Stateful signatures are not accepted in CSRs and are never used in TLS certificates. Each private key can produce a strictly limited number of signatures, and reuse of any one-time key position is catastrophic to security; the schemes are therefore standardised for offline code, firmware, and document signing only. BeatQuantum's implementation enforces state discipline through write-ahead index reservation, dual-copy committed state, an append-only audit trail with rollback detection, and host binding of key material.

Profiles in operation, each verified by at least one independent second implementation where one exists:

Public keys for the LMS interoperability profile are additionally published in RFC 8708 SubjectPublicKeyInfo form for consumption by standard X.509 tooling.

Footnote: Classic McEliece is deferred due to the lack of library support and of a technical solution for large-key handshakes.

BeatQuantum validates domain control using DNS TXT record verification. No other validation method is currently supported. DNS validation is chosen because it does not require a running web server, works for any domain, and produces a verifiable audit trail independent of HTTP infrastructure.

5.1 Domain Scope and Multi-SAN Certificates

A CSR may contain multiple Subject Alternative Names (SANs). BeatQuantum validates at the level of the apex domain (the registered domain or eTLD+1). Validation of an apex domain covers all hostnames within that apex that appear in the CSR. Specifically:

• A CSR containing example.com and www.example.com requires one validation challenge at the apex example.com.
• A CSR containing example.com and otherdomain.com requires two separate validation challenges, one per apex domain.
• All SANs in a submitted CSR must belong to apex domains for which validation has been completed. BeatQuantum will not sign SANs for unvalidated apex domains.

Wildcard SANs are not accepted. See Section 5.5 for the rationale.

5.2 Validation DNS Record

For each apex domain requiring validation, the subscriber must create a DNS TXT record at the following location:

_bq-challenge.<apex-domain> IN TXT "<validation-token>"

For example, to validate example.com (which also covers www.example.com, api.example.com, and any other subdomain of example.com present in the CSR):

_bq-challenge.example.com IN TXT "bq-abc123xyz..."

The validation token is generated by the BeatQuantum PKI portal at the time of CSR submission and displayed on screen with the exact record to be created. Each token is unique, cryptographically unpredictable, and tied to a specific certificate request and apex domain.

5.3 Validation Flow and Token Lifetime

1. The subscriber submits a CSR via the BeatQuantum PKI portal and selects Option A or Option B.
2. The portal generates a unique validation token for each apex domain present in the CSR and displays the exact DNS record(s) to be created.
3. The subscriber adds the TXT record(s) at their DNS registrar or authoritative DNS provider. There is no time pressure to complete this immediately.
4. The portal polls DNS automatically every 60 seconds and displays live validation status for each domain on screen.
5. Once all apex domains validate successfully, the certificate is signed immediately and a download link is presented on the same page.
6. The subscriber may close the browser and return later using the Request ID displayed at submission time. The Request ID provides access to the status page at https://beatquantum.com/pki/status/<request-id> without requiring an account or email address.
7. Validation tokens remain valid for 72 hours from the time of CSR submission. If validation is not completed within this period the request expires and a new CSR submission is required. 72 hours is chosen to accommodate DNS propagation delays on all major registrars.

BeatQuantum does not collect or store email addresses. No account registration is required at any point. The Request ID is the subscriber's only means of retrieving a pending or completed certificate after closing the submission page; subscribers should record it securely.

5.4 DNSSEC

BeatQuantum validates DNSSEC signatures where present on a domain. If a domain has DNSSEC enabled and the DNS response fails DNSSEC validation, the challenge will not be accepted. Subscribers are encouraged to enable DNSSEC on their domains; this makes the domain validation tamper-evident and strengthens the overall security of the issuance process. Detailed DNSSEC guidance is provided in the User Guide.

5.5 Wildcard Certificates

BeatQuantum does not issue wildcard certificates. This is a deliberate policy choice rooted in the research mission of this CA rather than a technical limitation:

• Blast radius. A wildcard certificate covers every subdomain of an apex domain. A compromised wildcard private key therefore affects all services under that domain simultaneously. Per-hostname certificates limit the scope of any single compromise.
• Crypto-agility research. The value of post-quantum certificate research is maximised when certificates are issued per-service or per-hostname. Wildcard certificates encourage long-lived, broadly-scoped deployments that are the opposite of the agile, short-lived, per-service certificate model that post-quantum migration requires.
• Renewal cadence alignment. As validity periods shorten significantly through 2029 (see Section 3), wildcard certificates become operationally impractical. Designing systems around per-hostname certificates now prepares subscribers for the direction the industry is moving.

5.6 Rate Limiting

A maximum of 5 certificates may be issued for the same apex domain within any rolling 7-day period. This limit applies across all subscribers for the same domain and is intended to prevent abuse while providing adequate capacity for research workloads.

All CSRs submitted to BeatQuantum must meet the following requirements. CSRs failing any validation check will be rejected with a descriptive reason code.

• The CSR must be self-signed — the CSR signature must verify against the public key contained in the CSR. This proves possession of the corresponding private key without transmitting it.
• The CSR must contain at least one Subject Alternative Name (SAN) of type dNSName. A Common Name alone is not sufficient.
• The CSR must not request CA:TRUE in any Basic Constraints extension. BeatQuantum does not issue CA certificates to external parties under any circumstances.
• The CSR must not contain wildcard SANs (e.g. *.example.com).
• All SANs must be DNS names. IP address SANs are not currently supported.
• The signing algorithm must be from the accepted list in Section 4.
• The CSR must be submitted in PEM format.

BeatQuantum does not generate private keys on behalf of subscribers. The private key must be generated by the subscriber on their own infrastructure and must never be transmitted to BeatQuantum or to any third party. This is the fundamental security property of the CSR-based issuance model.

7.1 Subscriber Responsibilities

Subscribers are solely responsible for the protection of their private keys. BeatQuantum provides no key escrow, key recovery, or key custody services. If a private key is lost, a new key pair and CSR must be generated and a new certificate requested. If a private key is compromised or reasonably suspected to be compromised, the subscriber must immediately request revocation in accordance with Section 8.

7.2 BeatQuantum CA Key Protection

BeatQuantum CA private keys are protected as follows:

• Root CA private keys are encrypted with a strong passphrase, stored offline on encrypted media, and are not connected to any network. They are brought online in an air-gapped environment only when signing new intermediate CA certificates, which is an infrequent operation.
• Intermediate CA private keys are encrypted with a strong passphrase and used only for signing issuing CA certificates and CRLs.
• Issuing CA private keys are encrypted with a strong passphrase and reside on the signing server for automated end-entity certificate issuance and CRL renewal.
• No CA private key material is transmitted over any network in unencrypted form at any time.

8.1 Revocation Timelines

BeatQuantum commits to revocation timelines that meet or exceed the CA/Browser Forum Baseline Requirements §4.9.1.1, which BeatQuantum adopts voluntarily. BeatQuantum targets 24 hours for all revocation requests regardless of reason — more stringent than the BR's 5-day limit for non-urgent revocation cases.

8.2 How to Request Revocation

Revocation requests must be sent to contact@beatquantum.com with the subject line Revocation: <domain>. The request must include one of the following to authenticate the requester's authority over the certificate:

Method 1 — Revocation Token (preferred)

Include the revocation token provided in the certificate bundle at the time of issuance. BeatQuantum will verify the token against the issuance record and proceed with revocation upon confirmation. This is the fastest method and requires no DNS change.

Method 2 — DNS Revocation Confirmation (if token is lost)

If the revocation token has been lost, authenticate via DNS by creating a TXT record at the following location for the apex domain of the certificate to be revoked:

_bq-revoke.<apex-domain> IN TXT "BeatQuantum-Revocation-Confirmation"

For example, to revoke a certificate covering example.com or any subdomain thereof:

_bq-revoke.example.com IN TXT "BeatQuantum-Revocation-Confirmation"

Send the notification email after placing the record. BeatQuantum will query the DNS record, confirm its presence, and proceed with revocation. The subscriber should remove the TXT record after receiving confirmation of revocation.

This record uses the _bq-revoke subdomain and is entirely separate from the _bq-challenge record used during certificate issuance. Both records may coexist without conflict.

8.3 CRL Distribution

Certificate Revocation Lists are published at the following URLs. CRL endpoints are served over plain HTTP as required by RFC 5280; relying parties must not expect or require HTTPS for CRL retrieval.

Issuing CA CRLs are renewed automatically every 5 days within their 7-day validity window. BeatQuantum does not operate an OCSP responder, consistent with current industry direction away from OCSP.

8.4 Root and Intermediate CA Compromise

In the event of confirmed compromise of a root or intermediate CA private key, BeatQuantum will publish a notice at https://beatquantum.com/status within 24 hours of confirmation. The notice will describe the scope of the compromise, which certificates and chains are affected, and the steps subscribers should take, including whether a new root certificate must be installed.

8.5 Cryptoagility Procedures

Upon credible verification that a KEM algorithm in use is compromised:

KEM removal from BeatQuantum infrastructure: Within 1 hour (tested: 14 minutes). Our world leading algorithmic interoperability ensures services remain operational, unless the entire set of algorithms were simultaneously broken.

Upon credible verification that a Digital Signature algorithm in use is compromised:

Third-party certificates (e.g. Letsencrypt): Replacement deployed within 1 hour of availability.

BeatQuantum CA certificates: Revoked, CRL updated, reissued within 24 hours (tested: 30 minutes).

BeatQuantum does not collect, store, or process the email addresses or IP addresses of users submitting CSRs, checking validation status, or downloading certificates. No account registration is required at any stage of the certificate lifecycle.

The following information is recorded as part of the certificate issuance audit log, which is necessary for the operation of the CA and for revocation authentication:

• The domain name(s) appearing in the issued certificate
• The public key contained in the CSR (this is not secret material and will be embedded in the issued certificate)
• The certificate serial number and issuance timestamp
• The revocation token (stored securely; used solely for revocation authentication)
• The Request ID associated with each submission

This information is retained for the operational lifetime of the CA and may be disclosed if required by applicable law.

BeatQuantum is not required to submit certificates to Certificate Transparency (CT) logs as it is not a publicly trusted CA. BeatQuantum may submit issuance details to CT logs or operate its own transparency log once the relevant infrastructure has been developed and tested. Any such submission policy will be documented in an updated version of this CPS and announced at https://beatquantum.com/status before taking effect.

BeatQuantum accepts no liability whatsoever in connection with the issuance, use, reliance upon, or revocation of any certificate issued under this CPS.

To the fullest extent permitted by applicable law:

• BeatQuantum provides all certificates and associated services "as is", without warranty of any kind, whether express, implied, statutory, or otherwise, including without limitation any implied warranties of merchantability, fitness for a particular purpose, accuracy, or non-infringement.
• BeatQuantum shall not be liable for any direct, indirect, incidental, special, consequential, punitive, or exemplary damages arising out of or in connection with the issuance or use of any certificate, even if BeatQuantum has been advised of the possibility of such damages.
• BeatQuantum makes no representation that certificates issued under this CPS are fit for any purpose other than experimental research use as described in Section 2.
• BeatQuantum's total aggregate liability to any person or entity in respect of any certificate or this CPS shall not exceed zero.

11.1 Subscriber Indemnity

By submitting a CSR and accepting a certificate from BeatQuantum, each subscriber unconditionally and irrevocably agrees to fully indemnify, defend, and hold harmless BeatQuantum, its officers, employees, agents, and successors from and against any and all claims, demands, proceedings, losses, damages, costs, expenses (including reasonable legal fees on an indemnity basis), and liabilities of any nature whatsoever arising out of or in connection with:

• the subscriber's use or deployment of any certificate issued under this CPS;
• any reliance by any third party on any certificate issued to the subscriber;
• any breach by the subscriber of the acceptable use terms in Section 2;
• the subscriber's failure to adequately protect their private key;
• any misrepresentation made by the subscriber in connection with their certificate request or domain validation;
• any claim by a third party arising from the subscriber's use of a BeatQuantum certificate in a production, commercial, or consumer-facing environment; or
• any failure by the subscriber to request timely revocation following a key compromise or suspected unauthorised use.

11.2 Relying Party Acknowledgement

Any party that chooses to rely upon a certificate issued by BeatQuantum, including any party that installs the BeatQuantum root certificate into a trust store, does so entirely at their own risk. BeatQuantum accepts no liability to relying parties under any circumstances. Relying parties are strongly advised not to rely upon BeatQuantum certificates in any context other than isolated, controlled experimental environments.

This CPS 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.

The parties irrevocably agree that the courts of England and Wales shall have exclusive jurisdiction to settle any dispute or claim arising out of or in connection with this CPS. The parties agree to attempt in good faith to resolve any dispute through direct negotiation before commencing formal proceedings. Where negotiation does not resolve the dispute within 30 days, the parties agree to refer the matter to mediation or arbitration under standard commercial dispute resolution procedures before pursuing litigation.

BeatQuantum reserves the right to amend this CPS 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 https://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.

Continued submission of CSRs or use of certificates issued under a prior version of this CPS constitutes acceptance of the amended terms.

In the event that BeatQuantum ceases to operate its CA, BeatQuantum will provide at least 30 days notice at https://beatquantum.com/status before termination. BeatQuantum will revoke all outstanding certificates, continue to publish CRLs until all issued certificates have expired or been revoked, and provide guidance to subscribers on transitioning to alternative certificate authorities.

Questions about this CPS? Contact BeatQuantum at contact@beatquantum.com. For CA status and announcements see beatquantum.com/status. For technical guidance on key generation, CSR creation, and algorithm selection see the User Guide.