Standards we follow, decisions we’ve made, and links to the primary sources. Every entry below points to a real spec or a real section of our documentation — no manufactured posts.
Our IETF draft (draft-quantumsecure-acme-pqc-00) extends RFC 8555 with a kty=PQC JWK shape, an algorithm-aware order resource, and an alt-signature delivery path so existing ACME clients can issue hybrid certificates with minimal changes.
RFC 8555 anchors itself in classical JWS — RSA, ECDSA, Ed25519. Our draft adds a single new key type, kty=PQC, with FIPS-204 / 205 / 206 algorithm identifiers, plus a small extension to the order resource so a client can request a specific PQC algorithm or a hybrid (classical+PQC) issuance.
The CA returns the leaf certificate with a classical signature in the standard signatureValue field and a parallel PQC signature in the altSignatureValue extension (draft-ietf-lamps-x509-alt). Existing TLS stacks validate the classical half and ignore the unknown extensions; PQC-aware verifiers validate both.
The QuantumSecure CA implements the draft live at https://api.quantumsecure.app/acme/directory. Source for the draft and a reference certbot plugin lives at github.com/quantumsecure/draft-acme-pqc.
A side-by-side of the three NIST-finalised signature families: lattice-based ML-DSA (FIPS 204), lattice-based Falcon (FIPS 206), and hash-based SLH-DSA (FIPS 205). When to pick which, and what each costs on the wire.
How draft-ietf-lamps-x509-alt embeds a parallel PQC signature inside a classical certificate. The wire format, the verification logic, and what changes for relying parties — versus what stays exactly the same.
Order, validate, issue, deploy, monitor, renew, revoke. The same five verbs as classical PKI, with three things that change: algorithm-aware key generation, larger signature footprints, and parallel chain validation.
The full specification for what was Dilithium and is now ML-DSA. Algorithm parameters for security levels 2, 3, and 5; signature and public-key sizes; and the NIST-published test vectors.
SPHINCS+ as standardised. A conservative, hash-based alternative to lattice signatures, useful for code signing and as a defence-in-depth fallback if a lattice break is ever announced.
The RFC that everyone uses without thinking. Re-read it before extending it: the JWS account model, the order/authorization/challenge state machine, and the bits our PQC draft touches.
Low-volume, technical updates when we ship something significant — new algorithm support, draft revisions, or deployment lessons. No marketing fluff.