Dissemination and Evidence Track

Date: 2026-08-08 · Status: Draft 1

Separation of concerns. Nothing in the research memo, the PRD, the specification, or the code should be written for a petition. This document tracks dissemination as a project-management concern. The record is a byproduct of doing the work well and publishing it properly — which is also the only version that survives scrutiny.

1. Sequencing principle

Cheapest credible thing first. Each step’s output becomes the credential for the next.

OWASP Cheat Sheet PR  ──►  IACR ePrint + arXiv  ──►  OpenSSF Sandbox
   (days, high reach)         (weeks, citable)         (needs 3 maintainers)
                                     │
                                     ▼
                    Enigma track + OWASP Global AppSec
                                     │
                                     ▼
                       IEEE S&P magazine ──► CACM Practice

Adopter case studies and the independent security review run in parallel from Phase 2 onward.

2. Step 1 — OWASP Cheat Sheet Series (do this first)

The clearest, cheapest opportunity found in the entire research pass.

The current Cryptographic Storage Cheat Sheet covers the stack levels at which encryption can occur (“at the application level… at the database level… at the filesystem level… at the hardware level”), key management, and envelope encryption with DEK/KEK hierarchies.

Confirmed gaps — none of the following are covered:

• No ORM or framework guidance whatsoever (no Hibernate, SQLAlchemy, Active Record, Entity Framework, Django, GORM)
• No field/column-level specifics — database-native TDE is named but not developed
• No searchable-encryption coverage at all
• No practical code examples — the sheet remains theoretical
• No schema design guidance (how to structure encrypted columns, store per-row key metadata, handle indexes)
• No performance or query-efficiency trade-off discussion

That is almost exactly the surface this project covers.

Mechanism: a pull request to OWASP/CheatSheetSeries. No membership, no fees, days of effort. The Cheat Sheets are among the most-read practitioner security documents in existence.

Do this before any standards body. It is also the best possible test of whether the writing is clear to practitioners.

3. Step 2 — Preprints

The benchmark and migration-cost work is the strongest candidate for the arXiv paper precisely because the literature has none of it — no published person-months, no measured latency deltas, no storage-overhead measurements for application-layer encryption.

4. Step 3 — Governance home

Recommendation: OpenSSF Sandbox for the reference implementations. OASIS only later, if at all.

5. Step 4 — Standards track

6. Step 5 — Conferences

Honest read: only two venues on this list are a natural fit for a defensive reference architecture.

Confirmed dead or dormant — do not target: Strange Loop (final edition 2023) · RailsConf (final edition 2025) · standalone USENIX Enigma (suspended) · LocoMocoSec (no edition since 2024, no discontinuation notice — treat as dormant).

7. Step 6 — Written publication

8. Industry bodies

9. Third-party evidence opportunities

These are the artifacts that carry weight because someone else produced them.

1. An independent implementation passing the test vectors, written by someone outside the project. The single strongest signal that the specification is well written, and PRD metric M2.
2. An independent security review, published in full including unresolved findings. A release gate, not a nice-to-have. 37signals had one and it caught a deterministic-encryption flaw days before launch.
3. Named adopter organizations willing to be referenced. Three is worth more than three hundred GitHub stars.
4. Adoption by an existing library. Rails, Prisma, or CipherSweet maintainers adopting the envelope format would be decisive. Their users already have the problem.
5. Citation in a framework or standard — an OWASP page, a CSA document, an auditor’s guidance, a competing library’s docs.
6. Conference acceptances at Enigma or OWASP Global AppSec.
7. Peer-reviewed publication in IEEE Security & Privacy or CACM Practice.

10. Near-term calendar

11. Standing rules

1. Never write a document, a spec section, or a commit message for the record. If it would not survive the question “would you have written this anyway?”, do not write it.
2. Publish negative results. The finding that SOC 2 does not require this, that CIS says storage-layer encryption suffices, and that insurers do not ask — that analysis is more useful to practitioners than another vendor claim, and it is the kind of thing that gets cited.
3. Every claim gets a citation or a flag. The compliance document’s “not verified” list (§8 there) is a feature. Reviewers trust documents that say what they don’t know.
4. Third-party artifacts beat self-produced ones, every time. Prefer one external implementation over ten blog posts.

View source: docs/05-dissemination.md