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

[Anton Sokolov <[e-mail]>]

Henri, Joel, Emek,

I have been quiet for five days while three of you did the work, so this is
overdue rather than a summary.

Joel, the observation in your last message is stronger than anything in my
original post and I would like it to be the part that survives this thread.
My
original is high-S and the twin is its canonical low-S normalisation. So the
second identifier does not require an attacker. A conforming middlebox that
normalises s on ingest -- doing the thing every hardening guide tells it to
do --
manufactures the second identifier out of the honest signer's own bytes, and
believes it is helping. That means "mandate low-S" is not a weak mitigation
here. Applied to an artefact already in flight it is one of the ways the gap
gets opened. I will propose that as a paragraph in
draft-mih-sokolov-scitt-payload-binding; Steven is lead author, so that is a
proposal and not an announcement.

I am also dropping my own formulation in favour of yours. "Key the entry
identifier on the Sig_structure" is about one artefact and is correct until
someone adds a field to it. "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" is a property of the class and survives the
next
revision. Your Override Record is the argument for it: it failed no test
because
no test was applied to it. Emek's guard reading its label list from the
tool's
own output rather than from a written list is the same rule in a different
place.

Henri, your two rules are the reusable part of this thread and I would
rather
name them than paraphrase them. One file being right is no evidence about
the
next one -- which found three defects in your tree and, taken to depth by
Joel,
found a digest carrying a signature it never names. And the second: a
conformance corpus can go stale invisibly, because the checker and the
fixtures
fail in the same direction, so the suite goes green while describing an
implementation that no longer exists. Ask whether the independent checker
recomputes the rule you changed, separately from whether the suite passed.

Joel, on the verification-outcome vocabulary. Your point that a correct
refusal
can carry a false explanation is, I think, the second finding of this
thread and
not a footnote to the first. A deployment reporting same-act-two-encodings
as
detected tampering reports something that did not happen, and it will be
believed precisely because the check worked as specified. That a stable
digest
still produces a wrong report is the argument for reason codes over
verdicts,
and it is worth stating in whatever text comes out of this.

Now a correction of my own, since it is the price of the rest.

My post said the consequence for entry identity is, as far as I know, not
on the
record. That was too wide, and I should have found this before posting
rather
than after. draft-prabel-cfrg-suf-hybrid-sigs section 6.2.1 states that
weaknesses in EUF-only schemes allow "re-signing" the same message, enabling
real-world exploits such as replay of messages, double receipts, and log
poisoning. And Gabriel Urdhr published the JOSE version on 27 June, with
results
for eight implementations across six languages, reaching the same structural
advice from the other end: do not build a deny list on a token's raw value
or
its hash, because the holder of a revoked ECDSA JWT can derive a valid
unrevoked
one for the same claims.

The sweep behind my sentence covered the SCITT and COSE working-group
repositories, this list and the RFCs -- where I expected the answer to be,
which
is exactly why its silence was not evidence about anywhere else. CFRG was
one
hop away. What I do still not find anywhere is the SCITT-specific question:
what
an EntryID is derived from, and whether "the same registered Signed
Statement"
in SCRAPI 2.3.1 is meant byte-wise.

What I owe back. I offered the full measurement and nobody has needed it
yet:
eleven verification paths over four verifier cores, with the one-bit
negative
controls that make the verdicts informative. If the class rule is going into
anyone's document I will post it, since a rule about preimages deserves
evidence
that the substitution survives every path that might otherwise catch it.

Anton Sokolov
Tyche Institute, Tallinn

On Fri, Aug 21, 2026 02:42 PM, [e-mail] wrote:

> Anton, Henri, Joel,
>
> Two things in this exchange are worth more than the ECDSA case, and I want
> to
> report against both rather than agree with them, because we failed one of
> them
> today.
>
> **The repair is a rule over the class, not a sixth item.** Joel's Override
> Record
> failed no test that was applied to it, because no test was applied to it,
> and the
> fix was to state the property over every preimage the document defines
> rather than
> to extend the list. Keeping the enumeration as a reader's aid *with a note
> saying
> that is all it is* — that is the part I would copy verbatim.
>
> We reached the same shape from a different direction and it is worth one
> data
> point. A guard here checks that every conformance label still has a case
> producing it, so that deleting the last case for a label cannot silently
> shrink
> the class while the suite stays green. The label list is not written in the
> guard; it is read from the tool's own output, because a written list is
> correct
> until someone adds a field, which is your sentence about correctness that
> expires
> on the next revision.
>
> **And Anton's sentence is the one I would put on a wall.** *A checker that
> rebuilds the preimage it was meant to perturb reports exactly the property
> it was
> written to demonstrate, and it passes.*
>
> I have a fresh instance of it, from today, in a guard I wrote to pin the
> order in
> which our verifier runs its checks. The order matters because putting the
> signature check first makes a deleted record report as a bad signature —
> true
> verdict, wrong reason. So the guard builds records that fail two checks at
> once
> and asserts which failure is named.
>
> Its first version removed the signature from *every* record in the file.
> That
> makes the file's first record fail the signature check before the chain
> break is
> ever reached, so the guard reported "signature" for a verifier whose order
> was
> correct. It was measuring its own fixture. It now learns which record the
> pristine vector already fails on, from the tool's own JSON output, and
> unsigns
> exactly that one — plus a control asserting that a record whose only
> defect is a
> missing signature does fail on the signature. I would not have caught it
> if it
> had gone green the first time.
>
> **On the format itself, one structural note, useful only as an existence
> proof.**
>
> Our identity is not the served envelope. The content hash is computed with
> the
> signature, the hash field itself, and the anchor excluded from the
> preimage, and
> the signature is then taken over that hash. So Joel's rule — every
> signature made
> by a party other than the one computing the digest is replaced by its
> signing
> input digest — holds here vacuously, because no signature enters any
> preimage at
> all. Two encodings of one signature are one identity by construction.
>
> We did not choose that to defeat malleability. We chose it so a
> transparency-log
> anchor could be attached after signing without invalidating the record,
> which is
> mild evidence that the repair is structural rather than a patch for ECDSA.
>
> And the discrimination we lost, since Joel is right that writing that down
> is the
> other half of the test: excluding the signature from the preimage means an
> operator who controls the file can strip or thin the signature without
> invalidating the content hash. We document it as not solvable in-file.
> What runs
> against it is a keyed HMAC alongside Ed25519 — strip the signature,
> recompute the
> unkeyed hashes, and the HMAC still fails, which a test covers — plus the
> external
> anchor.
>
> Emek
>
>
> On Fri, Aug 21, 2026 at 12:06 AM Joel Hillier <jhillier=40certisyn.com@
> dmarc.ietf.org> wrote:
>
> 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 ratherthan 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. Wortha 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 sweepswalked 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 lastelement 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
> ReconciliationOutput. 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, sothe 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 repairedthat. 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. Notest
> 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. Sothe 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 thatexpires 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 signaturemade 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 unresponsiveregister, 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 detectedtampering 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 InputDigests 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 accusesomebody.
>
> 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 envelopedbytes, 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'tsearch 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, isa 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. YourTuesday 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
> bothat 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 matcha 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 askswhether 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 differentkey 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 thefailure 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 propertyit 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
>
>