[SCITT] Re: New draft: The Coverage Attestation Profile (draft-hillier-coverage-attestation-00), and a request to break it

[Konrad Gruszka <[e-mail]>]

Joel, all,

I read the thread before writing, and I have dropped what Emek, Walter, Tiago and Anton
already have. What is left is one implementation report and one ambiguity I could not find
anywhere above.

First, what this is not. Emek ran two text-derived readers on 21 August and they disagreed
on 15 of 15, with one root: the draft did not name the members. Mine agree. That is not a
better result, it is a later one, and the difference is your repairs and the pinned bundle
rather than anything I did. If it is worth anything it is as a measurement of whether the
repair took, from someone who was not in the thread when it was made.

What I ran. Two verifiers written from the prose of Sections 4, 4.1, 4.2, 4.3, 5 and 6,
with the field names from CAP-1.schema.json. One is Python standard library. The other is
Rust with no dependencies and a hand-written JSON reader, so the two share no parsing path.
I did not read verify.mjs, verify.py or verify.html; copying them would have measured one
reading twice.

Against cap-1 at 0980d32, with core.autocrlf and core.eol unset, no .gitattributes, a clean
git status and zero checked-out files carrying CRLF:

The numbers. Both readers pass 15 of 15 against the conformance class, and Python vs Rust
agree 15 of 15. Against runs/conformance_run.json the exact set of rules fired matches,
including NC-05 firing both R5 and R1. cap-1.zip reproduces at 645dcc47a0082e48... and
verify.html at 62ede737312cefc4..., and the mail-safe repack is 40 of 40 byte-identical
after restoring extensions.

Then I probed eight places where the prose is silent. Seven times all three readers agreed.
The eighth is the reason for this message.

CAP-1 does not say what a verifier does with duplicate names in a JSON object. RFC 8259
Section 4 says names SHOULD be unique and calls the behaviour on violation unpredictable.

Take PV-03 and give integrity.complete twice, first true then false. PV-03 carries a failed
unit, so R7 forbids complete: true there.

A last-wins reader sees false and CONFORMS, which is also what verify.py does, measured.
A first-wins reader sees true and is REFUSED under R7. A strict reader rejects the
document as malformed JSON.

The other direction flips which reader accepts: PV-01 with eligible given twice, first 6
then 13, is refused under R1 by last-wins and accepted by first-wins.

Same bytes, three conforming readers, three answers. A producer can ship one document that
one relying party reads as clean and another refuses.

What makes this worth a clause rather than a footnote about JSON hygiene. The
duplication is the symptom. The property at risk is determinism. CAP-1 exists so that a
relying party can rely on a count, and here the count is the payload. If which count a
reader sees depends on which parser it used, the attestation is unreliable in exactly the
property the profile was written to establish. That argument is not mine; it came out of an
adversarial reading of my own finding, which is also where four attempted refutations of it
died.

Why I think this belongs with your eight classes rather than beside them. Your framing on
21 August was that two byte strings carry the same information and a digest over them
differs, so the information is invariant and the representation is not. This is the mirror.
The representation is invariant and the information is not: one byte string, two conforming
parsers, two different documents.

That has a consequence for the canonicalisation thread. JCS operates on parsed JSON. By the
time it runs, the parser has already chosen a winner, so canonicalisation cannot reach this
one. It sits a layer below everything in that discussion. Emek's open item, that nothing
pins whether a count is 25 or "25" except a schema outside the preimage, is the same shape
one step earlier: there it is which type, here it is which value.

Not the same as Anton's item of 25 August. His duplicate unit identifiers sit inside
unexamined and let R1 close by addition; that is the accounting layer, and one clause in R1
or R2 settles it as he says. This is the parse layer, and a clause in R1 would not reach it.

Harmless readings I checked and ruled out. R0 requires stratum identifiers to be unique and
does catch a duplicated stratum id, measured, in both my readers and in yours; it does not
reach object keys. JSON Schema has no vocabulary for duplicate names, so
additionalProperties: false does not help. It is not in run.mjs's declared gaps, which name
R0 isolation, author independence, and timing, ordering and concurrency, and not in the
self-attestation.

One correction against myself, because it nearly became a false report. My first Rust reader
read digits greedily and accepted "examined": 04, which RFC 8259 Section 6 forbids. My own
probe caught it, and it looked like a divergence in your document before it looked like my
bug. After the fix all three agree and the fifteen still hold.

What I would suggest, in your idiom: a document containing duplicate names within any object
MUST be refused. That is what my strict reader already does, and it costs nothing for
documents that were already well behaved.

The probe package is small, runs from a clean copy with Python 3 alone, and generates the
probes from your tree rather than shipping your vectors. It carries positive controls, two
unaltered vectors that must show CONFORMS and one simple R1 break that must show REFUSED,
so a run that refuses everything is visible as such rather than looking like a perfect score.

It is here, pinned to a commit rather than a branch, so the bytes you fetch are the bytes I
ran:

https://github.com/b7n0de/proofbundle/tree/96dacc4c12015e2859ae31955420707459663a1d/tools/cap1_unabhaengige_umsetzung

I have not written anything against -01, since -00 is the only version posted.

Prepared with AI agent involvement, reviewed and submitted under human oversight.

Konrad Gruszka
b7n0de · Verified AI Workhttps://b7n0de.com