Last updated: 26 September 2026
This document follows the structure of RFC 3647. It states what AxiomCode certificates mean, how they are issued, and what happens when something goes wrong. It should be reviewed by qualified legal counsel and a PKI auditor before certificates are relied upon in regulated contexts.
1.1 Overview. AxiomCode operates a certification authority (“AxiomCode CA”) that issues certificates binding a software artifact’s hash to a machine-checked verification verdict. Verification-as-evidence, not verification-as-opinion: every certificate carries the evidence needed to re-check it.
1.2 Document name. AxiomCode Certificate Policy and Certification Practice Statement, version 1.0 (2026-09-26).
1.3 Participants. The CA (AxiomCode), subscribers (paying customers who request verification), and relying parties (anyone who validates a certificate).
1.4 Certificate usage. Certificates assert: on the stated date, the AxiomCode engine compiled the artifact with the stated hash under the stated toolchain, and the proof checked. Appropriate uses: audit evidence, procurement deliverables, counterparty assurance. Prohibited reliance: treating a certificate as a warranty of safety, fitness, or intent — see §9.
The CP/CPS, the CA’s public verification keys, and the revocation list are published at axiom-code.com and queryable without an account.
Subscribers are identified by account (email + API key). Artifacts are identified by SHA-256 hash computed at submission. No identity vetting of persons is performed: the certificate speaks about the artifact, not the author.
4.1 Application. A paid verification request is a certificate application. Trial requests are never applications — no certificate can result.
4.2 Issuance. On a PASSED verdict, the CA signs a certificate containing artifact hash, verdict, toolchain versions, issuer name, unique serial, and a 90-day validity window. FAILED and INCOMPLETE verdicts produce no certificate, ever.
4.3 Validity and renewal. 90 days from issuance. Renewal is re-verification at the standard credit meter — there is no shortcut renewal, because the point is fresh evidence.
4.4 Revocation. The CA revokes a certificate when: (a) a toolchain or engine defect undermines the verdict; (b) the certificate was mis-issued; (c) the subscriber requests it. Revocations are published to the revocation list promptly (target: within 24 hours of the decision) and are permanent.
4.5 Incident handling. Suspected mis-issuance triggers an internal review; confirmed mis-issuance triggers revocation, a public incident note, and re-verification of affected artifacts at our expense. Mis-issuance is treated as the CA’s existential risk.
Verification runs in isolated, single-use build environments. CA signing keys are segregated from the web/API tier; signing requires the isolated CA service. All issuance, revocation, and metering events are written to a tamper-evident append-only log.
Certificates are signed with modern asymmetric signatures (Ed25519); the CA’s public keys are published for independent verification. Key generation uses a vetted CSPRNG; private keys are access-controlled and backed up encrypted. Key compromise triggers key rollover, re-issuance of affected certificates, and public disclosure.
Certificates are signed JSON documents with the fields listed in How it works §3. The revocation list is a signed JSON document listing revoked serials with reason codes and timestamps, updated on every revocation.
We log every issuance and revocation; logs are available to auditors under NDA. Annual self-assessment against this CP/CPS is published in summary form.
Certificates are factual statements about a verification event, not warranties. Liability is limited as stated in the Terms of Service. Subscribers warrant they have the right to submit the artifact. Relying parties must validate certificates through the published checker and revocation list; reliance on an expired or revoked certificate is at the relying party’s own risk.