# C2SP and the attempt to run cryptography specifications like open source > The Community Cryptography Specification Project treats a specification document the way a software project is treated: named maintainers review and accept changes, versions are immutable, and the whole thing is licensed under Creative Commons. The interesting question is whether that process survives contact with the standards it replaces. **C2SP/C2SP** — Community Cryptography Specification Project - Repository: https://github.com/C2SP/C2SP - Website: https://c2sp.org - Stars: 679 · Forks: 112 - Language: Go - License: not declared - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/c2sp-c2sp ## Specifications with maintainers who accept or reject changes The stated premise of the project is that cryptography specifications should be maintained using software development methodologies, applying the successful processes of open source to specification documents. That is the whole thesis, and it is unusual enough to be worth reading closely. In practice it means each specification has its own maintainers, and those maintainers are responsible for reviewing and accepting changes, exactly as maintainers of a software project do. The project attributes this arrangement with a specific benefit, describing it as enabling rapid, focused and opinionated development. That is a claim about process speed that you should judge from the specification catalogue rather than take on trust, but the structural point stands: there is a named person accountable for each document, and a change lands when that person accepts it. What you get in return is a document with an owner, a history of changes and a versioned identity, rather than a PDF that was published once. For an implementer, that difference matters, because the interesting part of a cryptographic specification is rarely the initial text. It is the corrections, the clarifications, and the edge cases that only showed up after someone tried to implement it. ## Stewards hold the keys but stay out of the specification Governance is split into two roles, and the division is deliberate. A small team of stewards maintains the overall project, enforces the Code of Conduct, assigns new specifications to proposed maintainers, and may intervene in cases of maintainer conflict or to replace lapsed maintainers. What stewards explicitly do not do is take part in the development of individual specifications in their steward capacity. That sentence is doing real work. It means the people who run the process are not the people who decide the contents of a document, which keeps a governance function from quietly turning into editorial control. The cost of that separation is that resolving a stalled specification depends on the maintainer or on the steward mechanism rather than on a committee with a fixed deadline. A team that has been waiting six months for a conformance test vector to be updated learns this quickly. The project also names its own procedure for bringing a new document in, and the maintainer list is published, so a reader can see who is accountable for what before they complain to anyone. The set of associated projects shows the same bias toward verification. The organisation hosts Wycheproof, a large library of tests for cryptographic libraries against known attacks, CCTV, the Community Cryptography Test Vectors, and x509-limbo, a suite of tests for X.509 certificate path validation. The intent is that a specification is accompanied by something that can fail it. ## Semantic versioning applied to a document, not a package C2SP specifications follow semantic versioning, and the README spells out what that means in practice: each specific tagged version is immutable, while new versions can be created to improve or fix the specification, preserving backwards compatibility for v1.x.x versions. Immutable tags are the part that matters for an implementer. When you cite a version, that text cannot be edited underneath you. A patched version becomes a new version, and the v1.x.x line stays compatible so that an implementation written against 1.0 does not break because a note was reworded. The repository has no GitHub releases, so the version identifiers live in the tags and in the short links rather than in a release feed. The commit history in the repository is the changelog. The repository layout reflects the model as well. The top level is a list of specification documents, each named for what it specifies: BLAKE3.md, FLOE.md, XAES-256-GCM.md, age.md, chacha20-poly1305-siv.md, chunked-encryption.md, cocktail-dkg.md, https-bastion.md, httpsig-pq.md, jq255.md, kopis.md, mtc-tlog.md, passkey-record.md, phc-strings.md, sequencehash.md, signed-note.md, static-ct-api.md, tlog-checkpoint.md, tlog-cosignature.md, tlog-mirror.md, tlog-policy.md, tlog-proof.md, tlog-tiles.md, tlog-witness.md, upki-revocation.md, vrf-r255.md and well-known-ssh-hosts.md. A cluster of those names belong to transparency log work, which is where the volume of recent specification writing has been. Several also have their own directories, such as XAES-256-GCM/, chacha8rand/, det-keygen/ and jq255/, which is where the accompanying data and test files live. ## Specifications are addressed by c2sp.org short links Distribution is the quiet engineering decision in this project. A specification should be linked using its c2sp.org short link, in the form https://c2sp.org/ for the current version and https://c2sp.org/@ for a specific one. That gives implementers a citation that is short, stable and human typable, and it removes the need for anyone to guess a raw file path in a repository. The version suffix matters most: a document that changes is a new artifact, and the versioned link is what you put in a document describing your implementation. The reference links the project itself relies on point at the same place, and they are the entry points for anyone reading along: ```markdown [C2SP homepage]: https://c2sp.org/ [C2SP Manual]: https://c2sp.org/-/manual [maintainers]: https://c2sp.org/-/maintainers [CC BY 4.0]: https://creativecommons.org/licenses/by/4.0/ ``` The manual is the document to read before contributing, and the maintainers page is where accountability for each specification is listed. There is no installation step here, because the deliverable is a document rather than a program: consuming a C2SP specification means reading it and implementing it, and the linked manual covers how to do both. ## Two licences, and the awkward one is the specification The licensing is split, and the split has consequences for how you can use the output. All C2SP specifications are licensed under CC BY 4.0, the Creative Commons attribution licence. All code and data in the repository is licensed under the BSD 1-Clause License, in a file named LICENSE-BSD-1-CLAUSE. The repository is not archived and the last push was on 2026-10-22, so the work is current. Attribution under CC BY 4.0 is a real condition, not a formality. If your product ships a document that reproduces a C2SP specification, or a derived work of it, the licence requires credit. That is worth checking against your own legal review, especially for a specification you intend to fork into a house style. The code and data under BSD 1-Clause carry no such condition. Test vectors and the supporting files in the repository are therefore easy to embed in a test suite, while the prose that describes the format is the part with obligations attached. That asymmetry surprises people who assume everything in the repository shares one licence. The licence for the repository as a whole is not one of the identifiers a scanner recognises, and the project metadata records it as unknown. The two explicit statements in the README are the authoritative position, and if your tooling depends on a machine readable licence field, it will need to be pointed at the two files by hand. ## Where the community process is the wrong bet The first wrong case is regulatory. If a specification has to be blessed by a national standards body, or if a procurement process requires a document with a recognised designation, a community specification does not satisfy it, whatever the technical quality. C2SP produces good engineering documents, and that is a different thing from an official standard. The second is timing. The claim of rapid development is a claim about a small group of maintainers working on documents they care about. It does not cover the case where a specification nobody maintains needs a change, or where the maintainers of a document are the implementers of the only implementation and see no reason to prioritise it. The steward mechanism exists for the first case, and it intervenes on conflict and on lapsed maintainers, but it does not create maintainers for a document nobody wants. The third is scope creep in the other direction. A specification that the community can revise is also a specification you can find yourself coding against a moving target if you follow the unversioned short link. Pin the version in anything you ship. The realistic alternative is a traditional standards process, and the difference is structural rather than editorial. A standards body has a fixed submission calendar, a named sponsor and a document that does not change once published. C2SP has a faster loop and a version history, at the cost of depending on the continued attention of specific people. Which one is right depends on whether your requirement is a document that will still be there in five years unchanged, or a specification that tracks what implementers are actually running. ## Conclusion C2SP fits implementers who want a written specification they can point at with a stable URL, and contributors who are willing to work through maintainer review rather than a formal standards body timetable. It does not fit projects that need a specification blessed by a national body, and it is the wrong place to look for a document you can fork without limit, because the repository operates by agreement between named maintainers. Before adopting one, read the manual at c2sp.org/-/manual, check the maintainer list for the specific specification, and confirm that the version you link to is the one your implementation was written against. ## FAQ ### What is the Community Cryptography Specification Project? C2SP is a project that facilitates the maintenance of cryptography specifications using software development methodologies, applying open source processes to specification documents. Each specification is developed by its own maintainers, who review and accept changes. ### How are C2SP specification versions handled? C2SP specifications follow semantic versioning. Each specific tagged version is immutable, and new versions can be created to improve or fix a specification while preserving backwards compatibility for v1.x.x versions. ### How do I link to a C2SP specification? Specifications should be linked with their c2sp.org short links, using https://c2sp.org/ for the current version and https://c2sp.org/@ for a specific version. The list of specifications is on the C2SP homepage. ### What licence applies to C2SP specifications and to the repository code? All C2SP specifications are licensed under CC BY 4.0. All code and data in the repository is licensed under the BSD 1-Clause License, held in the LICENSE-BSD-1-CLAUSE file. ### What is the role of C2SP stewards? A small team of stewards maintains the overall project, enforces the Code of Conduct, assigns new specifications to proposed maintainers and may intervene in maintainer conflict or to replace lapsed maintainers. Stewards are otherwise not involved in the development of individual specifications. ## Sources - [C2SP/C2SP on GitHub](https://github.com/C2SP/C2SP) - [Issues](https://github.com/C2SP/C2SP/issues) - [Project website](https://c2sp.org) - [README](https://github.com/C2SP/C2SP/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/c2sp-c2sp