[leoromanovsky]

Motivation

Response signers and client SDKs need to agree on the same bytes, certificate rules and acceptance decisions. Keeping separate copies makes it easy for one implementation to accept a response another rejects, especially during leaf or intermediate rotation.

Changes

Extract the shared public protocol v1 fixtures into response-signing/v1, with a JSON Schema, SHA-256 manifest, consumer guide and structural-validation workflow. The main corpus contains 46 response cases (six accepted, 40 rejected) and two signer key-matching cases. A separate two-case supplement covers canonical and noncanonical nested DER. A four-case supplement adds an accepted control and correctly signed negatives that isolate certificate size, the leaf CA flag, and the intermediate CA flag.

The comma-combined header case uses 1, 1, and the trailing-DER case has a matching certificate hash and valid response signature so each rejection exercises its intended rule. The validator rejects duplicate JSON object keys, with CI regressions for the schema, manifest and both corpora. HTTP header duplicates remain represented as arrays. The consumer guide specifies application bytes after HTTP transfer/content decoding and a Unix-seconds clock.

flowchart TD
  Fixtures[Shared v1 JSON fixtures and expected results] --> Structure[Schema and manifest validation]
  Fixtures --> Revision[Exact repository revision]
  Revision --> Signer[Native signer tests]
  Revision --> Browser[Browser verifier tests]
  Revision --> Mobile[iOS and Android verifier tests]
  Signer --> Agreement[Assert shared acceptance decisions]
  Browser --> Agreement
  Mobile --> Agreement

Loading

The diagram describes test-time consumption. Browser tests pin a submodule; native consumers can pin an archive or import an exact snapshot with provenance. Cryptography, transport and lifecycle adapters remain in their implementation repositories. No fixture download is added to assignment requests.

Decisions

Version 1 is the first public wire contract. Earlier prototype numbers are not compatibility promises; X.509 v3 certificate encoding remains unchanged. Synthetic chains and signatures were regenerated for v1, preserving the original acceptance decisions and adding rejection cases for prototype version headers and the abandoned transcript domain.

All certificates, identities, tokens and included leaf private keys are intentionally public synthetic test material. They must never become deployed credentials or runtime trust anchors. Accepted fixture responses carry the complete leaf/intermediate chain, allowing an unchanged client root to verify later rotations without another request. The corpus covers buffered response proofs; signed NDJSON checkpoints are outside this change.

Consumers must preserve exact body bytes, header order/duplicates and the fixture clock in Unix seconds. Schema validation checks structure and integrity; native tests establish cryptographic behavior. Implementation-specific diagnostics and the additional SDK KeyUsage tests remain downstream.

Merge this PR before consumers finalize their pins. Browser verifier #435 and native Rust signer #147650 consume c0c95f53e7f736b938849d8f53fff0560a0155b2 and explicitly load the new supplement. iOS #3357 and Android #4049 retain their previous snapshots; the new supplement has not been validated on mobile. If merging changes the commit identity, refresh consumer pins and provenance.

The isolated cases pass the browser and native Rust implementations. Targeted mutations demonstrate added coverage: each browser rule removal fails its new negative; Rust fails the size mutation and CA mutations that remove both its exact-DER and parsed-flag enforcement. Independent cryptographic checks verify all certificate and response signatures.

Checklist

• JSON files are valid (no syntax errors); the signing validator checks 52 response cases and two signer cases; all 19 repository validator tests pass, including six duplicate-key mutation subcases.
• New test cases reference existing flags in config/ufc-config.json — not applicable to the separate signing corpus.
• New flags have corresponding test cases in evaluation-cases/ — no evaluator flags added.
• Expected results match the flag configuration logic — evaluator expectations are unchanged; signing expectations were checked against native implementations. Structural validation alone does not verify signatures.