The crypto-agility manifest is a small, versioned JSON document that a site or repository publishes at a well-known URL — `/.well-known/crypto-agility.json` — so that agents, auditors, and CI bots can read its post-quantum posture the way they already read security.txt or robots.txt. It is a proposed, machine-readable convention, submitted as the IETF Internet-Draft draft-acosta-crypto-agility-manifest — not a ratified standard, and it should not be described as one. The well-known path follows RFC 8615, the same mechanism behind /.well-known/security.txt, so a consumer that knows only an origin can discover the manifest without out-of-band configuration.
Why it matters
AI coding agents and CI bots increasingly make dependency and cryptography choices, but there has been no standard place for them to learn a project's crypto posture, policy, and migration deadlines — every integration is bespoke, and the alternative is running a full scan. The manifest proposes a stable, backlink-verifiable URL for that summary: small enough to fetch and parse on every CI run, and answering three questions at a glance — how ready is this project, what quantum-vulnerable cryptography is it still using, and by when has it committed to migrate. It is deliberately a summary, not a replacement for the full CBOM or a readiness report; a consumer that needs component-level detail fetches the CBOM the manifest points to.
What a manifest contains
The manifest is a single JSON object with an integer `version` (1 for the current schema) and a `manifestType` discriminator of "crypto-agility" so consumers can tell it apart from other JSON. Around those sit provenance fields — `generatedAt`, a `generator` (name and version of the emitting tool), and a `subject` describing what was scanned (root, repository, commit) — and four substantive sections:
- posture — the distilled cryptographic posture: a `readinessScore` (0–100, where 100 means no classical asymmetric cryptography was found), `hybridKexInUse` (a boolean, or null when the generator could not determine it — a static scan cannot observe a negotiated TLS group), `quantumVulnerable` counts (a total plus a breakdown by severity), and `hndlExposedCount` — how many findings are exposed to harvest-now-decrypt-later.
- cbomSummary — a pointer to and digest of the full CycloneDX CBOM: its serial number, asset count, and the algorithm families in use with per-family quantum-vulnerability flags. The full CBOM is intentionally not inlined, keeping the manifest small.
- policy — the migration policy the project declares it is measured against: a source label, the years after which classical public-key cryptography is deprecated and disallowed, an optional operator-declared transition deadline, and a citation. By default the deadlines follow the NIST IR 8547 transition timeline (deprecate after 2030, disallow after 2035).
- attestation (optional) — a link to a machine-verifiable posture credential, i.e. signed evidence. The manifest records the URL verbatim; verifying the credential behind it is a consumer-side step.
Consumers are expected to branch on `version` and reject versions they do not understand, and to treat a null `hybridKexInUse` as "unknown" — distinct from false. A typical CI consumer fetches the manifest, checks the discriminator and version, then gates on the posture: for example, warning when a candidate dependency's own manifest reports a readiness score below a threshold, or failing when its critical quantum-vulnerable count is non-zero.
A manifest is a self-published summary, not proof
Everything in a crypto-agility manifest is asserted by the party that publishes it. On its own it certifies nothing — it is a posture summary, only as current as its last regeneration and only as honest as its publisher. It becomes trustworthy through two additions: the optional attestation link to signed, machine-verifiable evidence, and continuous regeneration in CI so `generatedAt` reflects the current codebase rather than a snapshot from last year. Consume it as a claim to verify, not a certificate.
Producing and validating a manifest
The reference emitter is qScan: `qscan crypto-agility emit` runs a scan and derives the manifest from the same inventory and CBOM as the scanner's full outputs, so the summary can never disagree with the detailed results of the same scan. Emitting is additive — it always exits 0, because publishing a posture document should not fail CI — and the intended workflow is to regenerate the file on every run. A local manifest is checked with `qscan crypto-agility validate`, and this site hosts a public validator that applies the same v1 schema rules to pasted JSON or to a live URL's /.well-known/crypto-agility.json. The manifest composes with the rest of the interchange chain: the CBOM it summarizes, SARIF scan results, OpenVEX exploitability statements, and the evidence trail an ISO 27001 A.8.24 audit expects.
How quantakrypto helps
A manifest is only as good as the scan behind it and the process that keeps it fresh. We establish the underlying posture during a readiness audit — building the cryptographic inventory and CBOM the manifest summarizes, and ranking the harvest-now-decrypt-later exposure it reports — then wire manifest regeneration into your pipeline so the published document tracks the codebase instead of drifting from it. You can check any manifest, yours or a dependency's, with the crypto-agility validator on this site.
Frequently asked questions
Is the crypto-agility manifest a standard?
No. It is a proposed convention, submitted as the IETF Internet-Draft draft-acosta-crypto-agility-manifest. Internet-Drafts are working documents with no formal standing — they may change or expire. The well-known URL mechanism it builds on (RFC 8615) is a standard; the manifest schema itself is not, and adoption beyond its reference tooling should not be assumed.
How does the manifest differ from a CBOM?
A CBOM is the full, component-level inventory of cryptographic assets; the manifest is a deliberately small summary published at a stable URL. The manifest's cbomSummary section points to the full CBOM (by serial number) and digests it — asset count and algorithm families — but never inlines it. A consumer reads the manifest for a quick gate and fetches the CBOM when it needs detail.
Does publishing a manifest prove a project is post-quantum ready?
No. The manifest is self-published: every field is an assertion by the publisher, and nothing in the format prevents an inaccurate or stale document. Trust comes from the optional attestation field — a link to signed, machine-verifiable evidence — and from continuous regeneration in CI, so the generatedAt timestamp reflects the current code. Without those, treat the manifest as a starting claim, not a conclusion.
How do agents and CI pipelines consume a manifest?
Fetch https://<origin>/.well-known/crypto-agility.json, check that manifestType is "crypto-agility" and that the version is one you understand (rejecting unknown versions), then read the posture and policy sections. Typical uses: a dependency-introduction bot failing when a candidate's manifest shows critical quantum-vulnerable findings, a CI gate warning below a readiness-score threshold, or an auditor reading the declared deadlines and following the attestation link to verify posture out-of-band.
Work with us on Crypto-agility manifest
Related reading
References
- IETF datatracker: draft-acosta-crypto-agility-manifest — the submitted Internet-Draft.
- IETF: RFC 8615 — Well-Known Uniform Resource Identifiers, the mechanism behind the /.well-known/ path.
- quantakrypto: crypto-agility.json validator — validate a pasted manifest or a live URL against the v1 schema.
- NIST: IR 8547 — Transition to Post-Quantum Cryptography Standards, the source of the default policy deadlines (deprecate after 2030, disallow after 2035).