[SCITT] Re: Signed Statement identity when the ECDSA signature is not byte-unique

[Joel Hillier <[e-mail]>]

Hi Anton, Henri,

The files are run. Result first, then a correction to something I told this list on Wednesday.

Both digests match what you published before I opened them. Both 395 bytes, protected header and unprotected header and payload byte-identical, only the 64-octet signature differing. r equal, s2 exactly n - s1, both verifying against the attestation-certificate key. One Sig_structure, so one Signing Input Digest, e104e763c87f8bda.... Your protected header decodes to {1: -7, 4: "piv-9c/37587575"}, and slot 9c is the digital-signature slot, which matches your account of the device.

Against ARP's ledger constructions: -03 Prior-Entry Hash differs, -04 is the same. Merkle leaf over the served envelope gives two leaves for one act, over the Sig_structure gives one. So the repair does what it was written to do, on bytes a secure element produced rather than ones I generated to prove a point.

There's one thing in your files you didn't mention, and I think it makes the case worse rather than better. Your original is high-S and the twin is low-S. The twin isn't an exotic artefact. It's the canonical low-S normalisation of the original, which is exactly what an implementation following the usual hardening advice produces on receipt.

So the second identifier doesn't need an attacker at all. A well-behaved middlebox that normalises s on ingest manufactures it, out of the honest signer's own bytes, while believing it's improving matters. "Mandate low-S" doesn't merely fail to close this. Applied to an artefact already in flight, it's one of the ways the gap gets opened. Worth a line in the payload-binding draft, because low-S is the first thing everyone reaches for and it's being reached for in the wrong place.

Now the correction. I said five constructions. It's six.

I ran a fresh adversarial pass over the whole document yesterday, on Henri's depth rule rather than on the thing I was looking at, and it found a sixth carrier that both of my earlier sweeps walked past.

ARP has an Override Record: where an adversarial pre-transmission test fails and a human operator authorises the reconciliation anyway, the Output carries a record of that, and the last element of the record is a COSE_Sign1 by the authorising operator. Deliberately by the operator and not by the server, because a record the server signs attests only that the server says someone authorised it. That signature is a field of the Reconciliation Output. The Reconciliation Hash preimage names two carriers to be replaced by Signing Input Digests, the register signature in each Query Binding Record and the register signature in each Non-Answer Statement, and the Override Record is neither.

So a third party holding an override signature substitutes (r, n-s), and the Reconciliation Hash moves. It's the ledger index, so the entry is indexed under a value the requester can't reproduce. It's a field of every ledger entry, so the Self-Entry Hash moves, so the Entry Signature payload moves, so the next entry's Prior-Entry Hash doesn't match. A reader concludes the chain is broken when the operator equivocated about nothing, which is the sentence I wrote in the security section for a case one level shallower than this one.

How it was missed is the part worth having. The first sweep looked for digests taken over signed artefacts, found the Reconciliation Hash embedded a register signature, and repaired that. The Override Record is a signature by a party who is neither the server nor a register, travelling to the server over a channel the server doesn't control, sitting in a field the preimage already carried. It failed no test that was applied to it. No test was applied to it.

Henri, this is your breadth rule with the last step taken. One file being right is no evidence about the next one, and an enumeration of carriers is right until someone adds a field. So the repair isn't a sixth item on the list. The document now states the rule over the class: in any preimage this document defines, every signature made by a party other than the party computing the digest is replaced by its Signing Input Digest. The enumeration stays as a reader's aid, with a note saying that is all it is. Correctness that expires on the next revision isn't the property the section exists to establish.

I'd suggest the payload-binding draft state it that way too, for the same reason. "Key the identifier on the signed payload" is right and is about one artefact. "No preimage carries a signature made by a party other than the one computing the digest" is the rule that survives someone adding a field to that artefact.

The wrong answer, since I said I'd report those too.

Take a holder of the original who's shown an inclusion proof issued over the twin. Under -03, ARP's leaf-binding rule requires the verifier to recompute the leaf from the object and refuse the proof when it doesn't match. It refuses. That's correct, and it's the right outcome.

What the document didn't give it was any way to say why. The section said MUST refuse and stopped. ARP had reason codes for a stale attestation, an unverifiable attestation, an unresponsive register, an exhausted budget and an incomplete notarisation, and nothing at all for "the object I hold and the object this proof commits to are the same signing act under two encodings."

Henri, that's your false split arriving in the vocabulary rather than in the digests. The digest is stable now and the report was still wrong, because a deployment reporting this as detected tampering reports something that didn't happen, and it'll be believed, since the check that produced it worked exactly as specified. Fixing the construction and leaving the error taxonomy alone gets you a correct refusal with a false explanation attached.

There's now a verification-outcome vocabulary with four values, and one rule that matters: where the artefact a verifier holds and the artefact the proof commits to have equal Signing Input Digests and unequal enveloped bytes, it MUST report that and MUST NOT report a leaf mismatch or a root mismatch. Same-act-two-encodings is evidence of a re-encoding and of nothing else, and it has to be tested for before either of the outcomes that accuse somebody.

The same pass found one reason code carrying five distinct causes, because four other sections pointed at it for conditions its own definition never named: a failed signature, an echo mismatch, a query-binding mismatch, a fabricated source-data identifier, and a register attesting something the registry says it can't. A register operator reading its own entry was told something was wrong with its attestation and not whether the fault was its own. Now five values.

And a residual that isn't in ARP's digests any more.

Evaluation Sweep Statements chain by carrying the transparency-service identifier and EntryID of the previous Statement's notarisation. If a Transparency Service keys EntryID on the enveloped bytes, one Statement has two EntryIDs available to it, and a party walking the chain backwards from a pointer to one of them holds a pointer the other copy's chain doesn't reach. SCRAPI retrieves by EntryID and offers no query surface, so that party can't search for the other one.

That series is ARP's evidence that a sweep it was obliged to perform was performed. A chain a third party holding no key can make look broken, using bytes the honest signer produced, is a weaker instrument than my own section claims. It isn't ARP's defect and ARP can't repair it alone, but ARP can state what it assumes about EntryID stability, and now does. That's a concrete consequence for the SCRAPI point rather than a hypothetical one.

The rest, briefly.

Henri, your restatement of the rule is the right one and it isn't what I said. "A digest can carry a signature it never names, through an object someone else signed" is the finding. Your Tuesday sentence was breadth. The Reconciliation Hash was depth: a construction that names an exclusion, honours it exactly, and is still over signature-bearing bytes because the preimage embeds an artefact a third party signed. The Override Record is both at once, which is presumably why it survived two sweeps.

On your third finding, the direction distinction is the part I'd carry. Tuesday's two let two byte-different artefacts claim one signing act. grant_fingerprint lets one act produce two identities. A false merge collapses a distinction that's real and an event gets under-counted. A false split manufactures one that isn't, and a verifier recomputing from the grant it holds fails to match a receipt for an authorization that did govern. A false merge loses information. A false split manufactures an accusation.

A sweep written for one direction won't find the other, which is why you hadn't looked. One asks whether two artefacts can reach one identifier that should have been two; the other asks whether one act can reach two identifiers that should have been one. Different queries over the same tree, and the first returns nothing at a site that only fails the second way.

And the test you applied to your own repair is the one I'd name explicitly. You checked that the intent survives: over the signed payload and the signing key, a re-mint under a different key or a changed scope still moves the value, and a malleated twin doesn't. A repair has to preserve every discrimination the construction was written to make, and drop only the ones that were never real. Mine failed that in one place and only stating the failure made it visible: the rule that an entry is signed exactly once had a verifier-side test before the change and doesn't have one after. Checking the discriminations you keep is half the test. The other half is writing down the one you lost.

Anton, on the credit: yes, happy to be named, and I'd rather the draft carry the rule than the names. "A checker that rebuilds the preimage it was meant to perturb reports exactly the property it was written to demonstrate, and it passes." That's yours as a sentence, it's sharper than mine, and it generalises past signatures to any harness that derives its expected value from the subject under test.

And your correction lands on the same form mine did, independently. The supportable claim is that RFC 9053 2.1 constrains neither r nor s, and that SEC1 4.1.4 and FIPS 186-5 6.4.2 range-check only. Two people retracting the same locator in the same week is a fair argument that 4.1.3 is a citation the whole area has been passing along without opening.

Transcript and the script are in the repo under _audit/anton/, no arguments, standard library plus cryptography.

Joel