crypto-agility.json: a place to publish cryptographic posture

what i wanted the file to do

a cryptography inventory answers which algorithms appear in a system. a migration decision also needs context: where those algorithms are used, whether classical fallback is allowed, how recently something was measured, and what still blocks a change

the manifest provides a public entry point to that information. it can point toward a fuller cryptography bill of materials and supporting evidence without publishing every internal detail. CI tools, auditors and coding agents can read the same structure instead of building a new integration for each project

publication is only the beginning. a file served by a website tells me what that website is declaring. i still need to decide whether its evidence is relevant and trustworthy

the October revision

the version 2 candidate separates three things that are easy to confuse: an operator's declaration, a runtime observation, and a consumer's verification of the evidence

it also separates key establishment from authentication. a connection can negotiate a hybrid key exchange while still using classical certificate signatures. reporting only that it supports “PQC” would hide that distinction

the candidate describes a specific subject, endpoint profiles, capabilities, dated observations, evidence references and migration status. browser, server and device profiles can have different constraints. a successful test against a gateway does not establish what happens on the gateway's next connection to a device

freshness matters too. retrieving the same file again must not make an old measurement current. evidence needs its own time and scope, and unknown or missing data needs to remain unknown

version 2 changes the data model. existing version 1 producers remain supported through the documented tooling, but a consumer must understand the version it receives. it must not reinterpret an old readiness score as a new runtime observation

making the proposal checkable

i added reference tools for bounded discovery, schema and semantic assessment, real TLS probing, signed observation ingestion, attestation verification and monitoring. the implementation record distinguishes what was tested from what remains to be demonstrated

that distinction applies to signatures as well. verifying an issuer's signature establishes who made a statement under the configured trust policy. it does not establish that the measurement was correct or that the whole system is secure. a manifest also cannot grant itself permission to change a consumer's policy, install software or rotate keys

the October work includes a merged reference implementation and production collection receipts. the remaining work includes the authenticated collector-to-issuer path, exact evidence and manifest binding, consumer monitoring, and independent interoperability. the production measurements recorded there were unsigned; i am not treating them as authenticated attestations

where it stands

the repository was last updated on October 11, 2026. the latest submitted Internet-Draft is still draft-acosta-crypto-agility-manifest-01, whose text is dated August 7, 2026. the October -02 candidate has not been submitted, and this remains an individual proposal, not an IETF standard. the Datatracker record and submission-readiness notes make those stages visible

what i want from the proposal is a useful starting point for a harder conversation: what cryptography is actually in use, what can be changed, and what evidence would let someone rely on the answer