f4a0ca0 · Oversight

Update roadmap to reflect current shipped state

Fold into docs/ROADMAP.md: v0.4.6 SIEM export and v0.4.7 registry
federation spec + conformance harness are now under Shipped. Adds a
new section for the browser inspector and classic-suite in-browser
decrypt. Public launch sequence updated: step 2 (browser inspector
and drag-drop workflow) is marked as inspector-plus-classic-decrypt
shipped, hybrid decrypt pending. Next section lists hybrid
post-quantum in-browser decrypt, the Outlook add-in, hardware
KeyProvider in Rust, and the Rust Axum registry. Phased status
table updated through phase 17.

f4a0ca0 Zion Boggan committed on Apr 22, 2026 (2 months ago)

docs/ROADMAP.md +262 -257

		@@ -1,304 +1,309 @@
		# Oversight Roadmap

	-	## April 20, 2026 correction
	-
	-	The launch plan is now gated on product usability and threat-model honesty:
	-
	-	1. L3 safety fixes and collusion docs - shipped in v0.4.5: L3 defaults off for wording-sensitive document classes, requires explicit disclosure when enabled, records `canonical_content_hash`, and supports a boilerplate-only mode.
	-	2. Web viewer / drag-drop share UI - next website/product milestone. Do not launch broadly on HN/Reddit until non-technical recipients can open and inspect Oversight files without the CLI.
	-	3. Outlook add-in only for the first ecosystem integration. Defer Drive, Box, SharePoint, and Teams plugins until there is a maintainer or design partner paying for them.
	-	4. SIEM integration before SOC 2: prioritize Splunk HEC, Microsoft Sentinel, and Elastic Common Schema exports because they are fast and high enterprise ROI. Formatters, the `oversight siem export` CLI, and the operator guide shipped in v0.4.6; see `docs/SIEM.md`.
	-	5. SOC 2 Type 1 scoping is realistic after a design partner. ISO 27001 comes after SOC 2. FedRAMP is dropped from near-term planning; it is a multi-year commercial program requiring sponsor-agency backing.
	-	6. Registry federation: publish and harden `docs/spec/registry-v1.md` during the Rust Axum/SQLx registry work so a second operator can run a compatible registry. Spec hardened and a conformance harness at `tests/test_registry_conformance.py` landed in v0.4.7; an operator runs it with `OVERSIGHT_REGISTRY_URL=<url> python3 tests/test_registry_conformance.py` to claim v1 compatibility.
	-
	-	Correct public-launch sequence:
	-
	-	1. L3 safety + collusion documentation.
	-	2. GUI / web viewer / drag-drop share workflow.
	-	3. Outlook add-in.
	-	4. One regulated-industry design partner deployment.
	-	5. SOC 2 Type 1 scoping in parallel.
	-	6. Public launch after the above, not while CLI-only.
	-
	-	This roadmap tracks work that lives outside a single release cut: external
	-	integrations, spec publication, third-party review, and community milestones.
	-	Every item references real upstream projects with current links so the plan
	-	can be audited, not assumed.
	-
	-	Dates and prices reviewed against upstream sources on April 20, 2026.
	-	Re-verify before committing to procurement or travel.
	+	Last revised 2026-04-22. The launch plan is gated on product usability and
	+	threat-model honesty, not on a calendar date.
	+
	+	## Where we are
	+
	+	1. L3 safety fixes and collusion documentation shipped in v0.4.5. L3
	+	defaults off for wording-sensitive document classes, requires explicit
	+	disclosure when enabled, records `canonical_content_hash`, and supports a
	+	boilerplate-only mode for contracts and filings.
	+	2. SIEM integration ahead of SOC 2 shipped in v0.4.6. `oversight_core.siem`
	+	and the `oversight siem export` CLI emit beacon events as Splunk HEC,
	+	Elastic Common Schema 8.x, or Microsoft Sentinel Log Analytics records.
	+	Operator guide at `docs/SIEM.md`.
	+	3. Registry federation hardening shipped in v0.4.7. The v1 interop spec
	+	at `docs/spec/registry-v1.md` is aligned against the reference server:
	+	canonical-JSON algorithm, uniform error envelope, normative endpoint and
	+	beacon paths, `/evidence` bundle shape, and `/tlog/head\|proof\|range` are
	+	pinned. `tests/test_registry_conformance.py` runs 33 checks in-process
	+	or against a live URL. An operator claims v1 compatibility with
	+	`OVERSIGHT_REGISTRY_URL=https://registry.example.org python3 tests/test_registry_conformance.py`.
	+	4. Browser inspector and classic-suite decrypt shipped on
	+	`oversight-protocol.github.io/oversight/viewer/`. Drag-drop `.sealed`
	+	parsing, WebCrypto Ed25519 signature verification, canonical JSON
	+	byte-identical to Python, optional registry lookups, and full
	+	decryption of classic-suite sealed files using WebCrypto X25519 + HKDF-SHA256
	+	with a vendored `@noble/ciphers` XChaCha20-Poly1305. Post-decrypt
	+	SHA-256 matches `content_hash` or the flow aborts. Hybrid (post-quantum)
	+	in-browser decrypt is the follow-up milestone.
	+	5. Outlook add-in first for the first ecosystem integration. Drive,
	+	Box, SharePoint, and Teams plugins are deferred until a maintainer or
	+	design partner funds them.
	+	6. SOC 2 Type 1 scoping becomes realistic after a design-partner
	+	engagement. ISO 27001 follows SOC 2. FedRAMP is dropped from near-term
	+	planning; it is a multi-year commercial program requiring sponsor-agency
	+	backing.
	+
	+	## Public launch sequence
	+
	+	1. L3 safety and collusion documentation. Shipped in v0.4.5.
	+	2. Browser inspector and drag-drop share workflow. **Inspector and
	+	classic-suite decrypt shipped**; hybrid decrypt pending.
	+	3. Outlook add-in. Next up.
	+	4. One regulated-industry design-partner deployment.
	+	5. SOC 2 Type 1 scoping in parallel with the design partner.
	+	6. Broad public launch (HN, Reddit, conferences). Not before the inspector,
	+	the Outlook add-in, and a real deployment are all in hand.

		---

		## Shipped

	-	### RFC 3161 qualified timestamps - shipped in v0.3
	+	### RFC 3161 qualified timestamps - v0.3

		`oversight_core/timestamp.py` and `registry/server.py` perform real RFC 3161
		requests. The default TSA chain tries FreeTSA first, falls back to DigiCert,
		and falls back to the registry's own clock if both are unreachable. Verified
		live: 4667-byte signed TimeStampToken, valid P-384 signature, correct
	-	gen_time, correct nonce.
	-
	-	For an evidence bundle to be admissible under EU eIDAS (qualified) or US FRE
	-	901 (authenticated), the timestamp must come from a Time Stamp Authority
	-	whose clock and signing key are independently auditable. RFC 3161 defines the
	-	request/response format; ETSI EN 319 421 defines the operational
	-	requirements for qualified status.
	-
	-	Configured vendors (free, no account, no vendor lock-in):
	-
	-	\| Vendor \| URL \| Status \| eIDAS-qualified? \|
	-	\|---\|---\|---\|---\|
	-	\| FreeTSA \| https://freetsa.org/tsr \| Primary, live-tested \| No (research-grade) \|
	-	\| DigiCert \| http://timestamp.digicert.com \| Fallback, live-tested \| No (RFC 3161) \|
	-	\| sigstore/timestamp-authority (self-hosted) \| github.com/sigstore/timestamp-authority \| Optional \| No (operator CA) \|
	-
	-	Optional paid integrations for deployments with eIDAS requirements:
	-
	-	\| Vendor \| Pricing \| eIDAS-qualified? \|
	-	\|---\|---\|---\|
	-	\| GlobalSign Timestamping SaaS \| ~$1K-5K/yr \| Yes (AATL + eIDAS) \|
	-	\| GLOBALTRUST \| Contact sales \| Yes (eIDAS) \|
	-
	-	To add a paid qualified TSA, edit `DEFAULT_TSA_CHAIN` in
	-	`oversight_core/timestamp.py` and put the paid endpoint first. The RFC 3161
	-	client code is URL-identical across providers.
	-
	-	FreeTSA modernized to the P-384 curve in March 2026, valid until 2040.
	-	Timestamps are self-consistent and court-useful as long as the examiner
	-	trusts FreeTSA's published root cert. Not eIDAS-qualified, so EU litigation
	-	may reject it. Under US FRE 901, FreeTSA's timestamps satisfy "evidence that
	-	the item is what the proponent claims it is" as long as chain of custody is
	-	documented - sufficient for most legal purposes short of financial-regulatory
	-	disputes.
	-
	-	### Sigstore Rekor v2 transparency log - shipped in v0.5
	-
	-	Oversight now attests registrations into a public Sigstore Rekor v2 log.
	-	Implementation lives in `oversight_core/rekor.py` (Python) and
	-	`oversight-rust/oversight-rekor/` (Rust), with a conformance suite proving
	-	byte-identical behavior across the two implementations.
	-
	-	- Wire format: DSSE statements appended via `/api/v2/log/entries` on
	-	`log2025-1.rekor.sigstore.dev`, returning real `log_index` values.
	-	- Predicate type resolves to a git-tagged GitHub path
	-	(`docs/predicates/registration-v1.md`) so third-party verifiers can
	-	resolve the schema without a live oversight.dev endpoint.
	-	- Privacy contract: recipient X25519 public keys are SHA-256 hashed before
	-	going on-log.
	-	- Opt-in by default (`OVERSIGHT_REKOR_ENABLED=1`). Failures are non-fatal;
	-	the local SQLite tlog stays authoritative for issuer-scoped queries.
	-	- Offline verification: `build_bundle()` produces a sigstore-compatible
	-	bundle (`bundle_schema: 2`) carrying the log public key, checkpoint,
	-	entry schema, and optional RFC 3161 chain.
	-	- Test coverage: 10 Python unit tests + 9 Rust unit tests + 2 live end-to-end
	-	tests + 5 backcompat tests + 4 cross-language conformance checks.
	-
	-	Self-hosted Rekor v2 is supported: point `OVERSIGHT_REKOR_URL` at a private
	-	instance. Trillian or tile-backed deployments both work since the protocol
	-	surface is the upstream Rekor v2 API.
	-
	-	### Rust canonical port of the hot path - shipped in v0.4
	-
	-	The seal / open / manifest / policy / semantic / tlog / rekor path is
	-	implemented as a Rust workspace under `oversight-rust/`, with `cargo build
	-	--workspace --release` passing with zero warnings. Python remains the
	-	reference implementation; Rust is the canonical implementation for
	-	production deployments. A conformance suite proves bit-identical output for
	-	every manifest and envelope.
	-
	-	Current crate selection:
	-
	-	\| Function \| Python reference \| Rust canonical \| Notes \|
	-	\|---\|---\|---\|---\|
	-	\| X25519 + Ed25519 + AEAD \| `cryptography` + `pynacl` \| `aws-lc-rs` \| Audited \|
	-	\| ML-KEM-768 \| `liboqs-python` \| `ml-kem` (RustCrypto, pure Rust) \| FIPS 203; pending independent audit \|
	-	\| ML-DSA-65 \| `liboqs-python` \| `ml-dsa` (RustCrypto) \| FIPS 204; pending independent audit \|
	-	\| HKDF / SHA-2 \| `cryptography` \| `hkdf` + `sha2` (RustCrypto) \| Audited \|
	-	\| JSON canonicalization \| `json` \| `serde_json` + `canonical_json` \| - \|
	-	\| Transparency log \| `oversight_core/tlog.py` \| `oversight-tlog` + `oversight-rekor` \| Local + Rekor v2 \|
	-
	-	A dual-stack build option lets operators diff outputs between AWS-LC and
	-	liboqs to catch divergence in PQ implementations.
	-
	-	The registry server remains Python + FastAPI; the performance-critical path
	-	is client-side.
	+	gen_time, correct nonce. FreeTSA is free and research-grade; GlobalSign or
	+	GLOBALTRUST drop in for deployments that require eIDAS-qualified status.
	+
	+	### Rust canonical port of the hot path - v0.4
	+
	+	The seal, open, manifest, policy, semantic, tlog, and rekor path is
	+	implemented as a Rust workspace under `oversight-rust/`. `cargo build
	+	--workspace --release` passes with zero warnings. Python is the reference
	+	implementation; Rust is canonical for production deployments. A conformance
	+	suite proves bit-identical output for every manifest and envelope.
	+
	+	### Fail-closed security hardening - v0.4.4
	+
	+	Codex review pass across the policy engine, Rekor verification, registry
	+	input validation, and the container format. Nine findings, nine fixes.
	+	Failed decryption no longer consumes open counts. REGISTRY and HYBRID
	+	policy modes fail closed instead of silent local fallback. DNS event
	+	callbacks from non-loopback clients must carry `OVERSIGHT_DNS_EVENT_SECRET`.
	+	Multi-recipient sealing disabled until the manifest format can honestly
	+	bind every recipient.
	+
	+	### L3 safety and GUI starter - v0.4.5
	+
	+	`oversight_core/l3_policy.py` gates L3 on document class: legal,
	+	regulatory, technical specifications, source code, SQL, logs, and
	+	structured data default to off. Explicit `full`, `boilerplate`, and `off`
	+	modes are supported. The CLI refuses to seal with L3 enabled unless the
	+	caller acknowledges that the recipient copy is textually non-identical to
	+	the canonical source. The manifest records `canonical_content_hash` and
	+	`l3_policy` so disputes can reach ground truth. `oversight gui` launches
	+	a Tkinter desktop starter covering keygen, seal, and open.
	+
	+	### Sigstore Rekor v2 transparency log - v0.5
	+
	+	Seal registrations are attested to the public Sigstore Rekor v2 log as
	+	DSSE envelopes. The predicate type resolves to a git-tagged GitHub path
	+	so third-party verifiers can resolve the schema without a live
	+	`oversight.dev` endpoint. Recipient X25519 public keys are SHA-256 hashed
	+	before going on-log. Opt-in by default via `OVERSIGHT_REKOR_ENABLED=1`;
	+	failures are non-fatal and the local SQLite tlog stays authoritative.
	+	Offline bundles carry the log public key, checkpoint, entry schema, and
	+	optional RFC 3161 chain. Self-hosted Rekor v2 is supported via
	+	`OVERSIGHT_REKOR_URL`.
	+
	+	### SIEM export - v0.4.6
	+
	+	`oversight_core/siem.py` ships a normalized `OversightEvent` model that
	+	maps the registry `events` table onto three schema-stable formatters:
	+	Splunk HEC envelopes, Elastic Common Schema 8.x documents, and Microsoft
	+	Sentinel Log Analytics custom-log rows. `sentinel_authorization()`
	+	implements the Data Collector API HMAC signing recipe. `FileSink`,
	+	`StdoutSink`, and `HTTPJSONSink` cover the transport surface without
	+	pulling SIEM credentials into the Oversight process by default.
	+
	+	The `oversight siem export` CLI streams events as JSON lines to stdout,
	+	a file, or a generic HTTPS collector. Supports `--since`, `--limit`,
	+	repeatable `--header`, and Splunk source/sourcetype/index overrides.
	+	Opens the registry database read-only so it is safe to run against a
	+	live service. Full operator guide at `docs/SIEM.md`. 11 unit tests cover
	+	envelope shape, None-field suppression, SQLite row mapping, read-only
	+	iteration, Sentinel HMAC determinism, and action-name coverage.
	+
	+	### Registry federation hardening - v0.4.7
	+
	+	`docs/spec/registry-v1.md` rewrites the interop contract against what
	+	the reference server actually serves. The spec now pins:
	+
	+	- Canonicalization algorithm: sort keys, compact separators, UTF-8,
	+	matching `json.dumps(manifest, sort_keys=True, separators=(",", ":"))`
	+	- Uniform error envelope with a defined `code` vocabulary
	+	- Full endpoint table including normative beacon paths
	+	(`/p/{token_id}.png`, `/r/{token_id}`, `/v/{token_id}`)
	+	- `/.well-known/oversight-registry` identity shape
	+	- `/evidence/{file_id}` bundle fields
	+	- `/tlog/head\|proof\|range` for federated verifiers
	+
	+	`tests/test_registry_conformance.py` is a 33-check harness with two
	+	modes. In-process against a FastAPI TestClient for CI, or against a
	+	live URL when `OVERSIGHT_REGISTRY_URL` is set. An independent operator
	+	who passes the harness claims v1 compatibility.
	+
	+	CORS middleware on the live registry lets the browser inspector read
	+	`/health`, `/.well-known/oversight-registry`, and `/evidence/{file_id}`
	+	from the public site origin. Methods are restricted to GET and OPTIONS;
	+	registration, DNS events, and attribution stay browser-unreachable.
	+
	+	### Browser inspector and classic-suite decrypt - post-v0.4.7
	+
	+	`site/viewer/` is a static page that parses the `.sealed` container
	+	in the browser, verifies the issuer Ed25519 signature via WebCrypto,
	+	and renders the manifest, watermarks, beacons, and policy. Canonical
	+	JSON in JS is byte-identical to the Python reference, validated
	+	against a Python-generated test vector.
	+
	+	Classic-suite decryption runs locally. WebCrypto performs X25519 ECDH
	+	via JWK import and derives the key-encryption key with HKDF-SHA256;
	+	a vendored pinned copy of `@noble/ciphers` (sha256 `b31ecc4f`) provides
	+	the XChaCha20-Poly1305 primitive that WebCrypto does not expose. After
	+	decrypt, the plaintext SHA-256 is compared against `manifest.content_hash`
	+	and a mismatch aborts. Wrong private key, mismatched recipient, tampered
	+	ciphertext, and hybrid-suite inputs all fail with explicit messages.
	+
	+	A tutorial `.sealed` and its recipient `identity.json` are published
	+	under `viewer/samples/` with an in-file note that the keypair is a
	+	public demo key.
	+
	+	### Operational hygiene - ongoing
	+
	+	History rewrite removed every occurrence of RFC 1918 addresses,
	+	internal workspace paths, and container identifiers that had leaked
	+	into early commits. Two internal-only files (`SESSION_RESUME.md` and
	+	`docs/RUNBOOK.md`) were removed from every commit and every tag.
	+
	+	`scripts/opsec-scan.sh` scans either the whole tree or the staged
	+	diff for the same patterns plus GitHub PATs, OpenAI and Slack tokens,
	+	and raw private-key PEMs. `.github/workflows/opsec.yml` runs the
	+	scanner on every pull request and push to main. `scripts/githooks/pre-commit`
	+	is the optional local hook. `.gitignore` blocks session, handoff,
	+	runbook, `private/`, `secrets/`, and `*.local.md` filename patterns
	+	so notes of that flavor cannot be accidentally committed in the first
	+	place.

		---

	-	## In progress
	-
	-	### Open-source strong-key protection (hardware security keys)
	-
	-	Earlier drafts proposed a cloud-TEE design to hold recipient private keys
	-	with attestation-gated release. That approach tied Oversight to a single
	-	cloud vendor, which contradicts the "truly open source" goal, and has been
	-	dropped.
	-
	-	The remaining threat: an adversary who steals both a ciphertext and a
	-	recipient's private key. With plain X25519, they win. The defense is a
	-	hardware security key - YubiKey 5, OnlyKey, Nitrokey, or any FIDO2/PIV
	-	device. All are vendor-independent, ~$50-$80 one-time, no cloud account.
	-
	-	The recipient's X25519 private key is generated on the device and never
	-	leaves it. All ECDH operations happen inside the device's secure element.
	-	The host OS sees only ECDH outputs. Even with root on the recipient's
	-	machine, an adversary can only perform ECDH while the device is plugged in
	-	(and typically touch-to-confirm or PIN-gated).
	-
	-	Tradeoffs vs. a TEE design:
	-
	-	- Weaker: does not prove "a specific signed binary is the decryptor."
	-	An attacker with the plugged-in device can still open files via a
	-	compromised client.
	-	- Equal: an attacker who only stole a key file off a dead drive gets
	-	nothing.
	-	- Better for open source: no cloud vendor, no recurring cost, no
	-	attestation-based revocation choreography - deauthorization is a
	-	single row change in the registry.
	-
	-	Integration plan:
	-
	-	1. Define a `KeyProvider` trait in `oversight-crypto`:
	-	```rust
	-	pub trait KeyProvider {
	-	fn x25519_public(&self) -> [u8; 32];
	-	fn ecdh(&self, peer_pub: &[u8; 32]) -> Result<[u8; 32], KeyError>;
	-	fn ed25519_sign(&self, msg: &[u8]) -> Result<[u8; 64], KeyError>;
	-	}
	-	```
	-	2. Ship two providers:
	-	- `FileKeyProvider` - current behavior, 0600-mode JSON key file.
	-	- `PivKeyProvider` - PKCS#11 to a YubiKey or Nitrokey slot, via the
	-	`yubikey` or `pcsc` crate.
	-	3. The registry records whether each recipient pubkey is `file_backed` or
	-	`hardware_backed`, so issuers can require hardware backing for sensitive
	-	material.
	-	4. `docs/HARDWARE_KEYS.md` documents a vendor-neutral setup covering
	-	YubiKey 5C, OnlyKey, and Nitrokey 3.
	-
	-	Operators who need the stronger TEE guarantee can layer AWS Nitro, Azure
	-	Confidential VMs, or Google Confidential Computing on top of Oversight
	-	themselves. The core will not bake any specific cloud vendor in.
	+	## Next

	-	### Spec publication
	+	### Hybrid (post-quantum) decrypt in the browser

	-	GitHub (complete). Canonical repo:
	-	[github.com/oversight-protocol/oversight](https://github.com/oversight-protocol/oversight).
	-	Licensed Apache 2.0. Test vectors published. Discussions open for
	-	community questions.
	+	Classic suite works today. Hybrid adds ML-KEM-768 decapsulation for the
	+	second shared secret alongside X25519. WebCrypto does not expose
	+	ML-KEM yet. Candidate path: a wasm build of `liboqs` for the KEM step
	+	with the rest of the primitives handled as they are today. Viewer
	+	already surfaces a stub error for hybrid inputs so the UX degrades
	+	gracefully until the KEM is available.

	-	arXiv preprint (in progress). ~15-page paper targeting `cs.CR`.
	-	Structure: motivation, threat model, protocol, cryptographic construction,
	-	security arguments, implementation, evaluation, limitations, related work.
	-	arXiv publishes within 1-2 days of endorsement; this establishes
	-	date-of-invention and a citable artifact.
	+	### Outlook add-in

	-	IETF Internet-Draft (next). Format as `draft-oversight-00` using
	-	xml2rfc or mmark; submit to datatracker.ietf.org; present at an informal
	-	BoF of a security working group (SUIT, OHAI, LAKE, or CFRG depending on the
	-	framing chosen). Iterate 6-12 months before pushing for RFC publication.
	-	Multiple independent implementations are required before the RFC stage.
	+	Microsoft add-in manifest, JS SDK surface, hosted manifest URL, and a
	+	pilot with one tenant. The manifest advertises seal and open against
	+	the user's configured registry URL. Browser inspector code already
	+	handles the open path; the add-in is primarily integration and UX work.

	-	---
	+	### Hardware `KeyProvider` in Rust

	-	## Planned
	+	`docs/HARDWARE_KEYS.md` already documents the vendor-neutral setup
	+	covering YubiKey 5C, OnlyKey, and Nitrokey 3. The remaining work is
	+	the `KeyProvider` trait and two concrete implementations
	+	(`FileKeyProvider`, `PivKeyProvider`) in `oversight-crypto`. The
	+	registry records whether each recipient pubkey is file-backed or
	+	hardware-backed so issuers can require hardware backing for sensitive
	+	material.

	-	### Independent security review
	+	### Registry in Rust

	-	Trail of Bits, NCC Group, and Cure53 are the primary candidates. Trail of
	-	Bits has the strongest Sigstore-ecosystem track record (rekor-monitor, OpenSSF
	-	funding) and has publicly funded post-quantum tooling. Zellic is an
	-	additional candidate for cryptography-heavy scope.
	+	`oversight-rust/oversight-registry` is scaffolded with all endpoints
	+	implemented under `#![forbid(unsafe_code)]`. Remaining work: integration
	+	testing, migration tooling from the Python registry, and wire-format
	+	stability declaration. The conformance harness is the acceptance gate
	+	for declaring v1.0 ready.

	-	Typical engagement shape:
	+	---

	-	- Scope: `oversight_core/crypto.py`, `oversight_core/container.py`,
	-	`oversight_core/manifest.py`, `oversight_core/policy.py`, the Rust
	-	counterparts, and the SPEC.md document.
	-	- Duration: 4-8 engineer-weeks.
	-	- Cost: $75K-$200K depending on firm and depth.
	-	- Deliverable: private report, 60-day disclosure window, then public
	-	blog-post version with findings and fixes.
	+	## Mid-term

	-	Prerequisites before soliciting quotes:
	+	### Spec publication

	-	1. Freeze the spec (no changes during review).
	-	2. Publish test vectors.
	-	3. Publish a threat model document (STRIDE or similar), 5-10 pages.
	-	4. Fuzz the container parser for 24+ hours and fix anything that trips.
	-	5. Complete an internal review pass first - catching bugs in-house makes
	-	paid review far more valuable.
	+	- GitHub - live at `github.com/oversight-protocol/oversight` under
	+	Apache 2.0 with test vectors.
	+	- arXiv preprint (~15 pages, `cs.CR`): motivation, threat model,
	+	protocol, cryptographic construction, security arguments, implementation,
	+	evaluation, limitations, related work.
	+	- IETF Internet-Draft as `draft-oversight-00`. Submit to
	+	datatracker, present at an informal BoF of SUIT, OHAI, LAKE, or CFRG
	+	depending on framing. Iterate 6 to 12 months before an RFC stage.
	+	Multiple independent implementations are required before RFC.

	-	Target window: 2027, after v1.0 spec freeze.
	+	### Conference targets

	-	### Conference presentations
	+	- USENIX Security Cycle 2 (June 2026).
	+	- Black Hat Europe 2026 (December 2026).
	+	- ACSAC 2026.
	+	- Black Hat USA 2027.

	-	Closed for 2026:
	+	Demonstration material: live seal and open in Python and Rust, live leak
	+	simulation with real-time attribution, hybrid PQ sizing, air-gap strip
	+	via VM and retype, hardware-key pull mid-open.

	-	- Black Hat USA 2026 Briefings (closed March 20, 2026)
	-	- WOOT '26 (closed March 3, 2026)
	-	- USENIX Security '26 Cycle 1 (closed February 5, 2026)
	+	---

	-	Open or upcoming:
	+	## 2027

	-	- USENIX Security '26 Cycle 2 - full papers due early June 2026
	-	(re-verify at usenix.org/sec26/cfp). Primary academic target for the
	-	Oversight v0.5 cycle.
	-	- Black Hat Europe 2026 (December 2026, London) - CFP typically opens
	-	July, closes August. Industry-track audience; strong fit for the
	-	"defensive watermarking and attribution" framing.
	-	- Black Hat USA 2027 Briefings - CFP opens ~January 2027, closes ~March.
	-	- WOOT '27 - academic track closes ~December 2026.
	-	- ACSAC 2026 - submissions typically open May-June.
	+	- Independent security audit. Trail of Bits, NCC Group, Cure53, and
	+	Zellic are the plausible candidates. Typical engagement: 4 to 8
	+	engineer-weeks, $75K to $200K, 60-day disclosure window. Prerequisites:
	+	spec freeze, threat model document, fuzz campaign, internal review
	+	pass.
	+	- v1.0 release, spec freeze, RFC shepherding.
	+	- Black Hat USA 2027 Briefings.
	+	- ISO 27001 after SOC 2 Type 2.

	-	Framing: open protocol for data provenance, attribution, and leak
	-	detection for the post-quantum era. Vendor-neutral alternative to
	-	proprietary DRM. Rust implementation, peer-reviewed crypto, no cloud
	-	lock-in, no custom cryptography.
	+	---

	-	Demonstration material:
	+	## Explicitly dropped or deferred

	-	- Live seal and open with DEK wrapping, shown in both Python and Rust for
	-	cross-language compatibility.
	-	- Live leak simulation: paste watermarked text into a webform, scraper
	-	picks it up, attribution fires in real time.
	-	- Hybrid PQ demonstration showing size overhead and future-proofing.
	-	- Air-gap strip demonstration: open in a VM, retype, paste to a pastebin,
	-	attribution still fires via L3 semantic marks.
	-	- Hardware-key demonstration: pull the device mid-open; open fails cleanly.
	+	- FedRAMP. Multi-year, seven-figure, requires commercial entity and
	+	sponsor agency. Revisit only if a commercial pivot occurs.
	+	- Cloud-TEE key custody. Ties Oversight to a single cloud vendor
	+	and contradicts the open-source goal. Hardware keys replace it.
	+	- Drive, Box, SharePoint, Teams plugins. Deferred until a maintainer
	+	or design partner funds them.
	+	- Broad HN and Reddit launch. Gated on Outlook add-in plus one
	+	design-partner deployment.

		---

	-	## Phased plan
	-
	-	\| Phase \| Horizon \| Items \| Status \|
	-	\|---\|---\|---\|---\|
	-	\| 0 \| Complete \| GitHub org, Apache 2.0 license, v0.5 release, SECURITY.md \| Shipped \|
	-	\| 1 \| Complete \| FreeTSA + DigiCert RFC 3161 chain, live verified \| Shipped (v0.3) \|
	-	\| 2 \| Complete \| Rust canonical port of hot path, conformance suite \| Shipped (v0.4) \|
	-	\| 3 \| Complete \| Rekor v2 integration, public log attestations, cross-language parity \| Shipped (v0.5) \|
	-	\| 4 \| Near-term \| arXiv preprint, threat model document, conformance vectors \| In progress \|
	-	\| 5 \| Near-term \| Hardware `KeyProvider` in Rust, `docs/HARDWARE_KEYS.md` \| In progress \|
	-	\| 6 \| Mid-term \| Internet-Draft submission, working-group BoF presentation \| Planned \|
	-	\| 7 \| Mid-term \| USENIX Security Cycle 2 paper submission \| Planned \|
	-	\| 8 \| Mid-term \| Black Hat Europe 2026 CFP submission \| Planned \|
	-	\| 9 \| 2027 \| Independent security audit (Trail of Bits / NCC / Cure53 / Zellic) \| Planned \|
	-	\| 10 \| 2027 \| v1.0 release, RFC shepherding, Black Hat USA 2027 \| Planned \|
	+	## Phased status
	+
	+	\| Phase \| Items \| Status \|
	+	\|---\|---\|---\|
	+	\| 0 \| GitHub org, Apache 2.0, SECURITY.md \| Shipped \|
	+	\| 1 \| FreeTSA + DigiCert RFC 3161 chain \| Shipped (v0.3) \|
	+	\| 2 \| Rust canonical port, conformance suite \| Shipped (v0.4) \|
	+	\| 3 \| Fail-closed security hardening \| Shipped (v0.4.4) \|
	+	\| 4 \| L3 safety, GUI starter, canonical_content_hash \| Shipped (v0.4.5) \|
	+	\| 5 \| Rekor v2 integration, cross-language parity \| Shipped (v0.5) \|
	+	\| 6 \| SIEM export: Splunk, Sentinel, ECS \| Shipped (v0.4.6) \|
	+	\| 7 \| Registry v1 spec + conformance harness + CORS \| Shipped (v0.4.7) \|
	+	\| 8 \| Browser inspector, classic-suite decrypt, opsec scanner + CI \| Shipped \|
	+	\| 9 \| Hybrid PQ decrypt in browser \| Next \|
	+	\| 10 \| Outlook add-in \| Next \|
	+	\| 11 \| Hardware KeyProvider in Rust \| In progress \|
	+	\| 12 \| Rust Axum registry, migration tooling \| In progress \|
	+	\| 13 \| arXiv preprint, threat-model repo document \| Mid-term \|
	+	\| 14 \| IETF Internet-Draft, CFRG or equivalent BoF \| Mid-term \|
	+	\| 15 \| USENIX Security Cycle 2, Black Hat EU 2026 \| Mid-term \|
	+	\| 16 \| Independent security audit \| 2027 \|
	+	\| 17 \| v1.0 release, RFC shepherding, Black Hat USA 2027 \| 2027 \|

		## Cost outlook

		\| Item \| Cost \|
		\|---\|---\|
	-	\| FreeTSA (primary TSA) \| $0 \|
	-	\| DigiCert (fallback TSA) \| $0 \|
	-	\| Public Sigstore Rekor v2 \| $0 \|
	-	\| GitHub Actions CI (open-source tier) \| $0 \|
	-	\| Hardware keys for development and testing (2 units) \| ~$100 \|
	+	\| FreeTSA, DigiCert, Sigstore Rekor, GitHub Actions \| $0 \|
	+	\| Hardware keys for development and testing \| ~$100 \|
		\| Domain, DNS, public beacon hosting (annual) \| ~$60 \|
	-	\| Conference registration and travel (USENIX + Black Hat EU) \| ~$6K \|
	-	\| Independent security audit (2027) \| $75K-$200K \|
	+	\| Conference registration and travel \| ~$6K \|
	+	\| Independent security audit (2027) \| $75K to $200K \|

		All year-one work runs on free and open infrastructure. Paid dependencies
	-	are optional, not required.
	+	are optional.