Who wrote this, what it is today, what would have to change for it to become something more — and the questions that are genuinely still open.
Governance follows participants. Today the work is stewarded by one author, in public — every decision and its rationale recorded in the repository. The structure that will govern it as contributors arrive is already written down in GOVERNANCE.md, and activates with the first of them.
Two things, in that order of value. A second, independent implementation — this architecture cannot be evaluated on one, and being argued with is worth more than being agreed with. And disagreement on the substance: the domain boundary, the capability list, the maturity model, the claim that governance can converge while trust stays distributed.
Contributions arrive as issues and pull requests on the repository. Every change and its rationale is recorded in public.
These are commitments, not descriptions of anything that exists. The first contributor with a sustained record is invited to maintainership, which is personal and not tied to an employer. When three or more independent organizations are engaged, decision-making moves to a shared model and the governance document is rewritten by them rather than by ANKATech.
The full text is in GOVERNANCE.md. It is deliberately short, and it stays short until there are people to govern.
This reference architecture explicitly acknowledges areas requiring community input. We invite engagement from enterprise architects, security researchers and cryptographic engineers on the following.
This document defines the architectural requirements for a Control Plane but does not specify a wire protocol or API contract. Should the community converge on a common API specification to enable interoperability between applications and CCP implementations?
This is the artifact that would legitimately be a standard. It does not exist — which is why this material does not use the word.
What constitutes a conformant implementation, and who certifies it? There is no conformance suite, no test harness and no certification body today. Should there be — a self-assessment framework, a test suite, an independent certifier? Each implies a different governance model. Until this is answered, listings are self-declared.
Should there be an open-source implementation of the required capabilities, and under what governance? One would accelerate adoption, provide a testbed for the architecture, and lower the barrier for organizations evaluating the approach.
How should this reference architecture relate to NIST SP 800-57 (key management), NIST SP 800-131A (algorithm transitions), ETSI TS 119 312 (cryptographic suites), ISO/IEC 19790 (cryptographic modules), and emerging PQC migration guidance? It should complement rather than duplicate them, but the precise integration points need community input.
Current position: this material scopes itself to application and data cryptography and treats PKI, transport cryptography and key infrastructure as complementary rather than superseded. How that scoping should be expressed relative to the documents above remains open.
The reference architecture describes a logical stack but does not prescribe deployment topology. What are the recommended patterns for operating a CCP across multi-cloud, on-premises and hybrid environments while maintaining cryptographic sovereignty?
Current position: the architecture requires that governance converge without requiring trust domains to be consolidated — Centralized Governance, Distributed Trust. The concrete topologies that satisfy this across specific provider combinations remain open.
We explicitly invite contributions from enterprise architects, security researchers, standards bodies and cryptographic engineers. Reach out at contact@cryptographiccontrolplane.org or open an issue on the project repository on GitHub.