Skip to content

Record verified production progress and remaining v2 gates #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
leonacostaok merged 1 commit into from
Oct 11, 2026
Merged

Record verified production progress and remaining v2 gates #3

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 13 additions & 31 deletions docs/ietf-readiness.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,43 +1,25 @@
# IETF -02 readiness

**Not submitted. The full requested acceptance criteria are not yet satisfied.**
The current branch prepares an individual proposal, not an IETF standard.
**Not submitted. The full requested acceptance criteria are not yet satisfied.** The implementation is merged at `7b79cd2`; the prepared text remains an individual proposal, not an IETF standard.

## Prepared materials

The authoritative RFCXML v3, generated Markdown, rendered text, embedded JSON
Schema and examples describe one v2 contract. Version 1 remains available for
existing qScan producers. The proposal requests a provisional well-known suffix;
it introduces no media type, signature format, feed protocol or cryptographic
algorithm. Contributor instructions require complete schema validation and
regeneration checks rather than a partial hand-written schema check.
The authoritative RFCXML v3, generated Markdown, rendered text, embedded JSON Schema and examples describe one v2 contract. Version 1 remains available for existing qScan producers. The proposal requests a provisional well-known suffix; it introduces no media type, signature format, feed protocol or cryptographic algorithm. Contributor instructions require complete schema validation and regeneration checks rather than a partial hand-written schema check.

## Verified submission process (2026-10-11)

- [Datatracker](https://datatracker.ietf.org/doc/draft-acosta-crypto-agility-manifest/)
lists -01; -02 is the next revision. The author email is `[email protected]`.
- [IETF author guidance](https://github.com/ietf/authors.ietf.org/blob/main/submitting-your-internet-draft.md)
prefers standalone RFCXML v3, validates with xml2rfc/idnits, and requires author
confirmation unless submitted by an authenticated listed author.
- [IETF 127 dates](https://datatracker.ietf.org/meeting/127/important-dates/)
list the draft cutoff as 2026-11-02 at 23:59 UTC. Recheck when submitting.
- [Datatracker](https://datatracker.ietf.org/doc/draft-acosta-crypto-agility-manifest/) lists -01; -02 is the next revision. The author email is `[email protected]`.
- [IETF author guidance](https://github.com/ietf/authors.ietf.org/blob/main/submitting-your-internet-draft.md) prefers standalone RFCXML v3, validates with xml2rfc/idnits, and requires author confirmation unless submitted by an authenticated listed author.
- [IETF 127 dates](https://datatracker.ietf.org/meeting/127/important-dates/) list the draft cutoff as 2026-11-02 at 23:59 UTC. Recheck when submitting.
- Author confirmation and a submission transaction have not been attempted.

## Remaining gates

1. Hosted checks must pass on the exact commit retained in PR #2.
2. Complete the production issuer/exporter trust and deployment boundaries in
[implementation-status.md](implementation-status.md). Reference fixture keys
are not production trust anchors, and unsigned historical telemetry is not
authenticated evidence.
3. Demonstrate the required heterogeneous runtime interoperability. Current
profile tests assess declarations; Node/Python tests establish JWS and schema
interoperability, not independent complete security consumers.
4. Review the final idnits diagnostics and obtain independent IETF-area feedback
on the breaking v2 contract and registration. AI security review is not IETF
endorsement. Recheck author metadata, references and the submission deadline.

No merge or submission is justified merely by a green reference test suite while
these acceptance gates remain open.

The official Datatracker document and submission instructions were checked again during the 2026-10-11 follow-up: -01 remains published and -02 remains the intended next revision. Standalone RFCXML v3 and an idnits review remain the preparation path; author confirmation and a submission transaction were not attempted. Production follow-up evidence and unresolved key-status, ledger and delivery gates are recorded in implementation-status.md. No independent complete semantic consumer implementation or IETF-area endorsement is inferred from the Node/Python wire tests.
1. Hosted checks must pass on the exact candidate commit and generated submission artifacts. Implementation PR #2 is merged; its green checks do not waive the remaining acceptance gates.
2. Complete the production issuer/exporter trust and deployment boundaries in [implementation-status.md](implementation-status.md). Reference fixture keys are not production trust anchors, and unsigned historical telemetry is not authenticated evidence.
3. Demonstrate the required heterogeneous runtime interoperability. Current profile tests assess declarations; Node/Python tests establish JWS and schema interoperability, not independent complete security consumers.
4. Review the final idnits diagnostics and obtain independent IETF-area feedback on the breaking v2 contract and registration. AI security review is not IETF endorsement. Recheck author metadata, references and the submission deadline.

The implementation changes have merged. Submission remains blocked while these acceptance gates are open; a green reference test suite alone does not establish technical readiness.

The official Datatracker document and submission instructions were checked again during the 2026-10-11 follow-up: -01 remains published and -02 remains the intended next revision. Standalone RFCXML v3 and an idnits review remain the preparation path; author confirmation and a submission transaction were not attempted. Dated production receipts are recorded in [implementation-status.md](implementation-status.md): the scheduled collector ran successfully, and the legacy website writers now use one durable serialized ledger with verified real issuance. The 203 retained production collector records remain unsigned; standard-JWS handoff, authorization, exact manifest binding, shared-ledger integration, consumer monitoring and alert delivery remain unaccepted. Authoritative current key status is still missing because the documented revocation endpoint returned HTTP 404. No independent complete semantic consumer implementation or IETF-area endorsement is inferred from the Node/Python wire tests.
52 changes: 29 additions & 23 deletions docs/implementation-status.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,35 +1,26 @@
# Implementation and acceptance

This branch implements reference tooling. It does not certify a deployment.
The workflow tests the PR head commit explicitly, not only GitHub's merge ref,
and retains logs and draft renderings as `validation-<commit>` artifacts.
The v2 reference implementation is merged at `7b79cd2`. It does not certify a deployment. The workflow tests the PR head commit explicitly, not only GitHub's merge ref, and retains logs and draft renderings as `validation-<commit>` artifacts. Production receipts below distinguish the deployed collector and legacy issuer from the remaining standard-JWS acceptance work.

| Requirement | Reference implementation and evidence | Remaining acceptance boundary |
| --- | --- | --- |
| Authenticated ingestion | JWS issuer policy, endpoint/subject binding, transcript digest, provenance and freshness; ingestion and live pipeline tests | Companion Observatory collector/exporter and existing authority bridge are under test; deployment, production identity and fresh signed output remain unverified |
| Authenticated ingestion | JWS issuer policy, endpoint/subject binding, transcript digest, provenance and freshness; ingestion and live pipeline tests | Existing scheduled Observatory collector deployed at `238860e`; its full production run retained 203 certificate-validated records, all unsigned. Authenticated handoff, authorized subjects, exact manifest binding and standard-JWS output remain unverified |
| TLS hybrid and fallback | Mandatory local OpenSSL 3.5.9 handshakes; hybrid, classical, deny-classical, invalid CA, wrong name, expired certificate, TLS 1.2 rejection | Tests cover the pinned TLS stack and fixture endpoints, not every provider, client or CDN edge |
| Signed attestations | Standard compact JWS/JWT, explicit algorithm policy, trusted issuer/key allowlists, revocation, audience, expiry, durable replay state; independent Node/OpenSSL/Python wire tests | RFC 9964 ML-DSA-65 support reuses the existing authority key; Existing-key KMS canary verified in website Actions; signed production deployment remains unverified |
| Signed attestations | Standard compact JWS/JWT, explicit algorithm policy, trusted issuer/key allowlists, revocation, audience, expiry, durable replay state; independent Node/OpenSSL/Python wire tests | RFC 9964 ML-DSA-65 support reuses the existing authority key. Real KMS canary and legacy production issuance passed; authoritative current key status and standard-JWS observation issuance remain unverified |
| Compatibility | Conservative profile comparison across supported device classes, per-hop scope and constraint handling | Declared compatibility is not execution on browsers, mobile hardware, gateways or constrained devices; no fleet enrollment/coverage claim |
| Monitoring | Repeated assessments, stable actionable alert IDs, expiry/regression detection, atomic owner-only state, concurrent-writer and symlink tests | Operator must deploy supervisor and route alerts; state deletion/rollback by its owner requires operational recovery |
| Discovery | HTTPS certificate validation, origin allowlist, pinned public IP, total deadline/size limits, ETag/Last-Modified, no stale-on-error | Optional change notifications only trigger a snapshot refresh; no unnecessary feed protocol |
| qScan | Pinned real qScan v1 producer/scan, repeatable bytes and v2 adapter with exact evidence digest and repository/commit binding | Native qScan remains v1; this PR supplies the tested adapter rather than changing its release |
| qScan | Pinned real qScan v1 producer/scan, repeatable bytes and v2 adapter with exact evidence digest and repository/commit binding | Native qScan remains v1; the merged reference implementation supplies the tested adapter rather than changing its release |
| Tests | Unit, adversarial, real TLS, Node/Python interoperability, qScan integration, concurrency and bounded performance gates | Structural schema and JWS interoperability do not establish independent full semantic implementations or device interoperability |
| Draft | Self-contained -02 XML, Markdown, schema, examples and offline text/HTML rendering | Internet-Draft submission checks and independent IETF-area review remain a separate gate |

## Scope and necessity

Keep discovery small. No custom signature envelope, bespoke Merkle construction,
new hybrid combiner, public feed hash chain, remediation executor or universal
readiness score is required. A fresh HTTP representation does not refresh evidence.
A signed observation authenticates its collector; independent verification must
be reported separately. The manifest never supplies its own trust policy.
Keep discovery small. No custom signature envelope, bespoke Merkle construction, new hybrid combiner, public feed hash chain, remediation executor or universal readiness score is required. A fresh HTTP representation does not refresh evidence. A signed observation authenticates its collector; independent verification must be reported separately. The manifest never supplies its own trust policy.

## Reproduce

Install `requirements.txt` and `npm ci --ignore-scripts`. Build OpenSSL with
`bash scripts/build-test-openssl.sh build/openssl`. Check out pqc-tools at
`6a81b5537eaedf61f259334b4e430e580c35942c`, run `npm ci --ignore-scripts` and
`npm run build` there, then:
Install `requirements.txt` and `npm ci --ignore-scripts`. Build OpenSSL with `bash scripts/build-test-openssl.sh build/openssl`. Check out pqc-tools at `6a81b5537eaedf61f259334b4e430e580c35942c`, run `npm ci --ignore-scripts` and `npm run build` there, then:

```sh
OPENSSL_BINARY="$PWD/build/openssl/apps/openssl" \
Expand All @@ -38,16 +29,31 @@ QSCAN_ROOT="$PWD/build/pqc-tools" \
python scripts/check-tests.py
```

Hosted CI must pass on the exact published commit. Local passing tests are not a
substitute. Merge and IETF submission remain blocked while the requested production
and interoperability acceptance boundaries above are unresolved.
Hosted CI must pass on the exact published commit. Local passing tests are not a substitute. The implementation PRs have merged; unresolved production and interoperability boundaries remain acceptance and IETF-submission gates.

## Production validation follow-up (2026-10-11)
## Production validation receipts (2026-10-11)

The supplied PR heads and their hosted checks were verified before changes. Independent engineering and security review found monitor alert-loss and baseline-loss failure paths; the monitor now retains pending delivery IDs until explicit acknowledgment and preserves historical authenticated measurements across rejected evidence, without presenting them as current assurance.
The original implementation changes merged as crypto-agility `7b79cd2`, Observatory `238860e`, Authority `55ff0fd` and website `c5cdbe0`. Independent engineering and security review corrected monitor alert-loss and baseline-loss failure paths: pending delivery IDs require explicit acknowledgment, and rejected evidence cannot erase the historical authenticated baseline or turn it into current assurance.

An isolated candidate collector on the existing host passed its typecheck and real TLS tests. At 18:03:23 UTC, it observed certificate-validated TLS 1.3 with X25519MLKEM768 for `https://quantakrypto.com`. The separately fetched exact manifest bytes hashed to `sha256:e36400bf76ac5c48791e85fa629fc0a220d032359ed06a8117480346eea0e443`. That record is unsigned, is not a completed manifest-bound issuance, and expires for export after one hour. The existing scheduler was not switched to the candidate.
The existing Observatory timer and service were updated to `238860e`; no second scheduler was created. Its full run from 18:41:47 to 19:00:31 UTC completed with exit status 0 and refreshed all 271 database rows. It retained 203 certificate-validated collector records in an owner-only directory (0700) with owner-only files (0600); filename and transcript hashes were checked. All 203 records remain unsigned. Successful collection and local hashes do not establish an authenticated signing handoff, subject authorization or exact manifest-bound issuance.

The deployed website still has legacy issuer jobs that fetch and overwrite its published ledger. Their history is not yet a single serialized durable observation ledger. The documented key-revocation endpoint returned HTTP 404; matching historical/live public keys and a valid root signature do not establish current non-revocation. No production consumer trust policy, persistent supervisor/replay/outbox deployment or confirmed alert receipt has been accepted. These gates block merge and full deployment even when fixture and hosted tests pass. Device compatibility remains unknown or declared wherever representative execution evidence is absent.
The stricter TLS 1.3/certificate-validation methodology changed the measured web denominator from 70 to 66 while the hybrid count stayed at 48: `48/70` became `48/66`. This is a methodology effect, not adoption growth. The basic website methodology disclosure is live. The explicit cutover-date disclosure is tracked in [website PR #276](https://github.com/quantakrypto/website/pull/276). Device compatibility remains unknown or declared wherever representative execution evidence is absent.

The existing-key KMS canary succeeded in [website Actions run 38162473186](https://github.com/quantakrypto/website/actions/runs/38162473186) at website commit `36f64b7705d3f152f3780093f96a8fe4da7f0e37`. It matched the historical online key SPKI fingerprint, requested a bounded RAW signature and verified it locally. Legacy issuance was skipped; no token or ledger entry was created. This verifies existing-key signing access and continuity, not non-revocation, authorized observation issuance or a deployed consumer.
The existing-key KMS canary succeeded in [website Actions run 38162473186](https://github.com/quantakrypto/website/actions/runs/38162473186) at website commit `36f64b7705d3f152f3780093f96a8fe4da7f0e37`. It matched the historical online key SPKI fingerprint, requested a bounded RAW signature and verified it locally. Legacy issuance was skipped; no token or ledger entry was created. This demonstrates signing access and key continuity, not non-revocation or authorized observation issuance.

### Durable legacy issuance

[Website PR #286](https://github.com/quantakrypto/website/pull/286) merged as `b37e956`. Its [CI run](https://github.com/quantakrypto/website/actions/runs/38165662878), [deployment](https://github.com/quantakrypto/website/actions/runs/38165903487) and [production SEO/JSON-LD checks](https://github.com/quantakrypto/website/actions/runs/38166157610) succeeded. The two legacy website writers now share one serialized durable authority at `/var/lib/quantakrypto-attestation`; the public ledger is a replica, and recovery journals and per-subject artifact state survive website asset swaps.

Authenticated migration preserved the existing 51-entry ledger with full-file SHA-256 `3c0262b8b37edb4c1e8e3f81d254f907c35c759287fe3fafb507a4afab99f765`. Real production issuance increased the ledger to 52 entries, giving full-file SHA-256 `0ab2c5823eeb2d717f6e70c2c3695a04ded4810d28e8b17426ab9126c69c9bb0`. The canonical and served ledgers and all three artifact replicas matched, and no pending journal remained. The public legacy ML-DSA signature verified against SPKI pin `33698c1c345d1df7a5308c513ee5c3925bc7f31c12aeb883549430a6d8f7cc80`.

These receipts cover the legacy writers only. Legacy v1 signs the qScan logical content hash and readiness value; retained byte checksums are storage checks, not signed exact manifest/evidence bindings. The standard-JWS exporter has not been integrated with this shared transaction, and a source attestation does not prove the corresponding build is the live runtime.

### Remaining acceptance gates

- Establish authoritative current key status. The documented revocation endpoint returned HTTP 404; a matching public key, valid historical certificate and working KMS signing access do not prove non-revocation.
- Complete the standard-JWS collector handoff, authenticated source identity, authorized subject policy, exact manifest binding and integration with the same durable issuer ledger. Recollect fresh evidence before issuance; retained unsigned records are not a substitute.
- Deploy and verify consumer trust, persistent monitor/replay state and delivery acknowledgment. Establish the intended alert destination and verify actionable receipt there.
- Demonstrate independent complete consumer interoperability and obtain independent IETF-area feedback. Node/Python wire tests and declared compatibility are narrower evidence.

No IETF submission has occurred. The merged code, deployed collector and successful legacy issuance do not close these remaining gates.