[SCITT] Re: New draft: The Coverage Attestation Profile (draft-hillier-coverage-attestation-00), and a request to break it
e.dogru@conarium.dev Fri, 21 August 2026 20:44 UTC
Return-Path: <e.dogru@conarium.dev>
X-Original-To: scitt@mail2.ietf.org
Delivered-To: scitt@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 92AF712D9279A for <scitt@mail2.ietf.org>; Fri, 21 Aug 2026 13:44:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787345067; bh=kq5b5JEfivwV7ppbSniRIeP2sfUH6efFSOEO7cc4Cvo=; h=Cc:From:In-Reply-To:References:Subject:To:Date; b=M0zqF/wdLWKKfuHukHzlbFvnFSf8g8TKKhCyFfCoQs10JN7jdKthTKepI5RgmfmXe duRt1tOL7QeJ37EqpdSzMqMHLya41yMi0WUCbQpOnUT+Mb2BLzsnYl3+t0euCOLmUe kdYgbTf/WU2m8Htt8/QJY0ykUVKaXBULi4cqZm7g=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level:
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=conarium.dev
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYeb_2nX_bv4 for <scitt@mail2.ietf.org>; Fri, 21 Aug 2026 13:44:25 -0700 (PDT)
Received: from grey.cherry.relay.mailchannels.net (grey.cherry.relay.mailchannels.net [23.83.223.78]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 9CD8612D9272B for <scitt@ietf.org>; Fri, 21 Aug 2026 13:44:25 -0700 (PDT)
X-Sender-Id: hostingeremail|x-authuser|e.dogru@conarium.dev
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D8AA0380359 for <scitt@ietf.org>; Fri, 21 Aug 2026 20:44:18 +0000 (UTC)
Received: from de-fra-smtpout6.hostinger.io (100-117-162-196.trex-nlb.outbound.svc.cluster.local [100.117.162.196]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id F26F8381486 for <scitt@ietf.org>; Fri, 21 Aug 2026 20:44:17 +0000 (UTC)
X-Sender-Id: hostingeremail|x-authuser|e.dogru@conarium.dev
X-MC-Relay: Good
X-MailChannels-SenderId: hostingeremail|x-authuser|e.dogru@conarium.dev
X-MailChannels-Auth-Id: hostingeremail
X-Grain-Relation: 480f9f8d320447c1_1787345058836_835644810
X-MC-Loop-Signature: 1787345058836:3896948185
X-MC-Ingress-Time: 1787345058836
Received: from de-fra-smtpout6.hostinger.io (de-fra-smtpout6.hostinger.io [148.222.55.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.117.162.196 (trex/8.0.2); Fri, 21 Aug 2026 20:44:18 +0000
Received: from localhost (34.86.89.34.bc.googleusercontent.com [IPv6:2a00:1d35:17a4:d900:f9a7:4dfc:5b46:5980]) (Authenticated sender: e.dogru@conarium.dev) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4hRXNH3V1Dz40Fg for <scitt@ietf.org>; Fri, 21 Aug 2026 20:44:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conarium.dev; s=hostingermail-a; t=1787345055; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iS34zAqa1Esg7MMSLkQzijMiVZOpwUPITpujki7NFWI=; b=cCg4/e5fYu3MBTJ4LEmiJ5R/OEU+HlqsBiTKJiRQ8pj1eYPg9NUcQUxxjXkoB5nCWkHWzg fQ0aqhsGE2us22PXy/8At2gvH84i04IAi/xVUV6iWpkX7W7avo8+vozR0BwLsXhhHEOBdz 5nRS4z7gal+0TYnP6dRrGyrvLSFpS16vXrfyuLsiaO0GNPNKbZFLvBVp4dhK1UgRfMy4Fx 9Uqpxjs26ySzSNHuvHww1g6IbcF20kkruIF5b11W+KH2A3w9wjxRORCHp/v9kPECbnG9Zs PAyKBNjPyXXXObPI7pkw1xelGteY83PGYzGUO7plpq5izISO3tssf89pOJMKyQ==
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"
From: e.dogru@conarium.dev
In-Reply-To: <BYAPR19MB2806B7556B4AB84F63552AFCADA32@BYAPR19MB2806.namprd19.prod.outlook.com>
Message-Id: <1787345047654385405.1787345047@conarium.dev>
Mime-Version: 1.0
References: <BYAPR19MB280613FCD91EC0ED03A93970ADA42@BYAPR19MB2806.namprd19.prod.outlook.com> <CALc05oF+y8m9SicMQVj67mTv1gzq2f0Tw0-W0Vne6P6FLJ-rPQ@mail.gmail.com> <BYAPR19MB2806B7556B4AB84F63552AFCADA32@BYAPR19MB2806.namprd19.prod.outlook.com>
To: jhillier=40certisyn.com@dmarc.ietf.org
Date: Fri, 21 Aug 2026 20:44:15 +0000
X-CM-Analysis: v=2.4 cv=fr2OZ04f c=1 sm=1 tr=0 ts=6a88b89f a=/mYa/mVueCak43dcYQE4Uw==:617 a=qdAjI2r-bzQ5Qs_1:21 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=48vgC7mUAAAA:8 a=g8oq2QynkGy8gTSrS5MA:9 a=wP-YvIHq8KcI_aSZ:21 a=frz4AuCg-hUA:10 a=QEXdDO2ut3YA:10
X-CM-Envelope: MS4xfFDEXic8k3RRHYMYPZh/V2phgTMQaoi0ZaXw+PWAoEhMLI+qPheQt/Bx7TEBEyQNb3TQrvyYSJb8npMzIPLm/LYuXVHRam8vHHlfmvtR6yUvjex6VFcl HbbD954qZCD5smoPbyr49i788yi8oi42dIrOvYYS9yNuBvnlOjWUNI+X8VGvjn36DnnvvhjGIwsqYbuJZgcArzwPEaWf12mvNjKcs7oRCXPp+EUo4zuTt7Se PZyodCmiCuORDd7+Ks+3ig==
X-AuthUser: e.dogru@conarium.dev
Message-ID-Hash: CBTCJC4E672PCFT4G36NKFEQUVUFZNXS
X-Message-ID-Hash: CBTCJC4E672PCFT4G36NKFEQUVUFZNXS
X-MailFrom: e.dogru@conarium.dev
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: scitt@ietf.org, wdhawkins46@gmail.com, tiago@donttrustverify.pt, team@emiliaprotocol.ai, hello@vaara.io, playplay2736@gmail.com, Todd.Gibson@t-mobile.com, anton.sokolov@tyche.institute
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [SCITT] Re: New draft: The Coverage Attestation Profile (draft-hillier-coverage-attestation-00), and a request to break it
List-Id: "Supply Chain Integrity, Transparency, and Trust" <scitt.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/scitt/ntw3Eh9-KI_Fpfe-Tq5zOSaFScI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scitt>
List-Help: <mailto:scitt-request@ietf.org?subject=help>
List-Owner: <mailto:scitt-owner@ietf.org>
List-Post: <mailto:scitt@ietf.org>
List-Subscribe: <mailto:scitt-join@ietf.org>
List-Unsubscribe: <mailto:scitt-leave@ietf.org>
Hi Walter, Emek, Tiago, Iman,
Well, you all took me seriously when I said break it, and inside a day. Thank you. This is the loop working exactly as it should, and it's a far better use of a draft than agreement wouldhave been.
Emek has now run both his text-derived verifiers against the published fifteen, and that result is the news, so it goes first. Everything else is conceded below it, and the pinned bundleis at the end.
Two readings of my document, run against my own class, agree on nothing.
verdicts strict attribution reader A 14/15 9/10 reader B 10/15 0/10 A vs B disagree on 15 of 15Fifteen for fifteen. Not a divergence on an edge case, a total divergence, and it has one root: the draft doesn't name the members.
And the root under the root, which I would not have found by reading either. Emek's finding is that the published schema makes Section 9's MUST unsatisfiable. I checked it againstthe schema rather than take it on trust, and it reproduces exactly:
subject.digest object, required [algorithm, value] states it catalogue_digest string ^[0-9a-f]{32,128}$ cannot withheld_digest string ^[0-9a-f]{32,128}$ cannotSection 9 says a producer "SHOULD use an algorithm that is unbroken at time of production and MUST state which was used." The pattern spans 32 to 128 hex, which is MD5 through SHA-512, sothe algorithm isn't recoverable from the value. And both enclosing objects,
basisand theunexamineditem, areadditionalProperties: false, so a producer who wants to comply has nowhere to put the statement. At two of the three sites where R3 and R4 rely on it, the schema forbids compliance with thedraft's own MUST.That isn't a style inconsistency between two shapes. It's a normative requirement that cannot be met, and it's the root of the string-versus-object split Emek measured yesterday as eightdisagreements in twenty. The first shape is the one to keep.
{algorithm, value}goes to the other two, because the string form is exactly what the weakest-rung argument is about: a digest whose algorithm is unstated is a claim whose strength thereader can't evaluate.One correction to Emek's own finding, and it makes it worse rather than better. He writes that
subjectis an object withkindandref, and that neither word occurs in the Internet-Draft.refoccurs zero times, which is right.kindoccurs three times, and every one of them isbasis.kindor the ordinary English word. So the schema requiressubject.kind, and a reader who does meet the word meets it bound to a different object meaning something else. That's worse than absence, because absence at least reads as absence.Reader B took R0's "MUST name a subject" at face value, expected a string, and refused all fifteen under shape, which is why its attribution is 0/10. Emek's line for it is the one I'd keep:a class where every document fails the shape check tells its author nothing about the rules underneath. And
withheld_digestcost reader A its only lost verdict on PV-04, because it looked fordigestand forhash, the two names the prose suggests, and found neither. One member name, and a conforming document reads as non-conforming.NC-05, in my own negative control, without either of you arranging it. Reader A refuses NC-05 under R1 and R5 together. That's the analytic point arriving empirically inside the vectorI wrote: a document violating R5's second sentence has already violated R1, so the mutant survives R5's removal. Emek reached it by reading and Walter reproduced it from the other side. My own control shows it, which is better evidence than either readingof it was.
Walter found what sits underneath: whether 7.2's "the class MUST fail" incorporates 7.1's refused-by-the-rule-it-targets requirement. Attribution-aware, his R5 mutant dies. Mere-refusal,it survives, which is the survival Emek measured. Same protocol, two readings, opposite kill counts, and it's the load-bearing sentence of the whole conformance section.
Emek, on the part of your message that wasn't about my draft. You could have pointed only outward and you didn't. An implementer reached 13/13 against your published vectors onlyafter opening your source, and four things were nowhere in your documents: what the Ed25519 signature actually covers, that the sequence counter advances by exactly one, which absent fields are schema errors rather than tampering, and the order the checksrun in. The last one is the one worth the thread: run the signature check first and a deleted receipt reports as a bad signature. True verdict, wrong reason. Check order is a wire fact and almost nobody writes it down. That's the same failure as
kindandref, and you found yours the same week you found mine.So the claims become, and all of it goes into
-01with mechanism rather than as quieter sentences:Nine rules of which eight are exercised, R0 tested by nothing. Walter has that one concretely: silencing R1 through R8 kills the class eight times, silencing R0 leaves it passing, becauseno vector exercises shape alone, so a verifier with no shape checking whatsoever agrees on all fifteen. One R0-only negative control closes it, and until it exists the schema is normative and untested in the same breath.
Agreement among implementations on the rules and not on the normative shape. That sentence is now measured rather than hedged.
And the production-fixture claim comes out. Walter: Section 7.4's fixtures contain no
cap/1document at all, both arecertisyn.verdict-document/1.0.0hosts carrying the older coverage shape, and grep forcap/1returns nothing in either. So "correctly refused under R1" has no referent in the artefacts it cites. Your line for it is right: the claims most likely to be false are the ones nothing was pointed at, and these were never pointed at a CAP-1verifier.The denominator has two doors, not one.
Walter moves the edge after the answers are known: 500 checks, forty ugly, declare 460 on the
declaredbasis, eight for eight,complete: true, perfectly accounted, about a population drawn after the fact. His sentence goes in the draft: the information didn't survive being moved from the remainder to the denominator, it just moved.Emek then leaves the edge alone and moves the claim instead. A stratum states which classes of claim it supports and nothing requires the cited claim to fall inside what it states. FiveTLS configuration checks declaring
supports: ["absence-of-any-vulnerability"]and bounding "no vulnerability was observed in the release" is conforming under both his verifiers. R8 checks presence. The failure it names is containment.The R7 incentive is the third face. A check you expect to error is safer never dispatched, because running it and erroring costs
completewhile declining to run it keepscompletewith a tidy disposition. It rewards not looking, and nobody has to write a false statement to use it.The closed vocabulary isn't closed, and you found the boundary from four directions.
not_sampledandnot_yet_duefrom Walter, and his R4 argument settles the first: if an enumeration must state its method because the method determines what the enumeration could not see, then sampling is such a method and the undrawnunits are none of the eight.access_denied, because landing an active refusal beside a missing licence loses the most interesting event in the run.aborted_before_dispatchfrom Tiago, with the sharper half being thatintegrity.completespeaks only of dispatched units, so a clean operator cancellation keepscomplete: truewhile part of the eligible population was never reached. And Emek's unit that was dispatched, ran, terminated normally and determined nothing, whichfailedmisdescribes andunavailablemisdescribes andexaminedcounts anyway.Emek, you declared an interest before anyone could notice it. That case is right on its merits and I'd have reached it more slowly without you naming it.
supersededI want and am not adding yet, because the successor pointer is a different shape from the other dispositions and I'd rather get it right than get it quickly.The basis trichotomy, and two repairs that aren't alternatives. Walter and Tiago reached the derived population independently, and Tiago's note is the one I'd keep: a composable or
derivedbasis preserves how the population was obtained, Walter's enumeration digest fixes which population was obtained, and neither substitutes for the other because a digest of a set doesn't let anyone re-derive it without the source and the predicate. Both go in. Walter's re-derivability axis then replaces the trichotomy: external artefact,internal artefact, or none. That partition doesn't leak, anddeclaredcomes to mean exactly one thing. The argument that convinced me is that the careful ones currently get punished, and a vocabulary that penalises rigour gets routed around bythe people you most want using it.
withheldis incoherent, and the vectors already disagree with the text. Tiago has it analytically: Terminology says a disposition is why a unit was not examined,Section 6 sayswithheldis examined, Section 4.1 puts it inunexamined, and R1 counts. No count assignment preserves all four. Plus R2 requires every unexamined entry to name a unit while the privacy rationale exists so a sensitiveunit needn't be named. Walter settled it empirically in both halves: PV-04 carries eligible 7, examined 4, unexamined 3 with the withheld unit among the three, so the class countswithheldas unexamined against Section 6, and the withheld entry names its unit,selector.ts, against the privacy rationale. The vectors have been practising the repair on one axis and refusing it on the other. Tiago's two-axis split, examined and disclosed, is the fix.
The pinned bundle. Built, not promised.
class digest 742509bba744a1b6bf57a057a7769db00d583dbf656648218583a53dcac51254 bundle digest 7e3e54963de75316e41a957447b290739bfac5c408f9d973a66f04cf7313dca7 MANIFEST.json 0637ea1db3d330aa616e20c1727a191f1065b250e8f2f2df59db2345fe32ce59 archive 680e7d20862fee173c568cdf2f384e5bfa0d4fb07df614fc48b22f438fd241ad members 42, of which 15 are the conformance class source Certisyn-Inc/certisyn-drafts @ 0980d3201aa2caab3cbad5c6e9bc99b422370b43Walter, both digests you pinned reproduce exactly against that tree,
170aa81e...for the vector manifest and4453f216...for the schema.Emek, one question about your reproduction, and I think it's a real hazard rather than a nitpick. You wrote that Walter's digests reproduce "exactly once line endings are normalised."The bundle pins SHA-256 over stored bytes with no normalisation, deliberately, so if your checkout is translating line endings then the bundle digest will not reproduce for you as specified, and the artefact built to end this class of ambiguity has one init. Can you tell me whether that was a checkout setting on your side or a genuine difference in the stored bytes? If it's the second, the bundle is wrong and I'd rather know now.
Your class digest doesn't reproduce, and that turned out to be the most useful thing in the exercise. "SHA-256 over the sorted per-file sha256 list of the fifteen" fixes the informationand not the representation. I tried forty-four readings of that sentence against your value and none reproduced it: sorted by path or by digest, joined by newline or nothing or comma or space, with and without a trailing byte, hex or raw octets, with and withoutthe filename, in
sha256sumorder or reversed, over fifteen files or sixteen, over stored bytes or canonicalised JSON.That isn't a criticism of the proposal. It's the proposal's own argument arriving one level up, and it's why the bundle specifies the construction to the octet instead of describing it.Six points, each naming a byte: enumerated member set never inferred from a directory listing; SHA-256 over stored bytes with no normalisation; ordered bytewise over the UTF-8 path; one line per member as lowercase hex, one U+0020, POSIX relative path; joinedwith U+000A including after the last; SHA-256 over that sequence.
One departure from your construction, with the mutant that earns it. The digest is over path-and-digest lines rather than over digests alone, because a list of content digests commitsto the multiset of contents and not to which file holds which. The bundle's mutation test swaps the contents of NC-01 and NC-02 and prints the path-blind digest either side:
path-blind class digest, before: 47314682fddd39da path-blind class digest, after : 47314682fddd39da UNCHANGED, so a digest over content alone cannot see thisThe bundle carries its own verifier and its own mutants.
verify_bundle.py, 42 members, 0 failures, and it reports every failure rather than stopping at the first, which is Emek's short-circuiting finding applied to the tool. That finding deserves its own line, because it generalises past both our drafts: refused by the rule it targets is only checkable against a verifier that reports every refusal. Against a short-circuiting one it's a fact about check order.
mutate_bundle.py, four mutants, four killed, and the crediting rule there is a set rather than a singleton, for your reason rather than mine. Altering a vector must move its member digest, the class digest and the bundle digest together, so a mutant cannot produce exactly one failure. That is NC-05 again, in a different tool, withinan hour of reading your report on it: a protocol demanding exactly one broken rule per control cannot be met where the rules entail one another. I hit it building the thing that exists because you found it.Standard library, no network, no arguments. Tiago, that should meet your bar; if it doesn't, say where and I'll fix the bundle rather than argue.
Tiago's freeze discipline, agreed and extended: you, Walter and Emek's two readers each hash implementation and interpretation notes before seeing another's, then run against this. Agreementis then worth something and disagreement is worth more.
Iman, thank you for the priority note, and it wasn't necessary from my side. An additional implementation is exactly as useful as a fourth one, and PR #630 written from
-00is another reading of the same text by someone I haven't spoken to. Yes to the schema-shape and examined-set negative controls against the pinned commit, and they can now cite a class digest rather than a commit.
One thing your break has already changed elsewhere. I read Walter's first message, went looking for the same shape one level up in the other draft, and it was there. ARP's evaluationsweeps carry an accounting identity over a bracket of ledger sequence numbers and check that nothing was skipped inside the bracket. Nothing required the bracket to abut the previous one, so a sweep could be complete over an interval beginning after the entriesan operator would rather not have examined, and every rule passed. Now fixed: brackets must abut, and any range deliberately not examined is individually disposed with a registered reason, where the registry refuses a reason the reader can't check for itself.Walter's sentence is quoted there with his name on it.
Different subject matter, same defect, found by reading a review of a different document. Which is the strongest argument any of us has made for the shared substrate, and it wasn't madein the abstract.
Keep going. This is the most useful day either draft will ever get.
Joel
- [SCITT] New draft: The Coverage Attestation Profi… Joel Hillier
- [SCITT] Re: New draft: The Coverage Attestation P… Pablo Play
- [SCITT] Re: New draft: The Coverage Attestation P… Walter Hawkins
- [SCITT] Re: New draft: The Coverage Attestation P… Joel Hillier
- [SCITT] Re: New draft: The Coverage Attestation P… Iman Schrock
- [SCITT] Re: New draft: The Coverage Attestation P… e.dogru
- [SCITT] Re: New draft: The Coverage Attestation P… e.dogru
- [SCITT] Re: New draft: The Coverage Attestation P… Joel Hillier
- [SCITT] Re: New draft: The Coverage Attestation P… Tiago Pinto
- [SCITT] Re: New draft: The Coverage Attestation P… e.dogru
- [SCITT] Re: New draft: The Coverage Attestation P… Anton Sokolov
- [SCITT] Re: New draft: The Coverage Attestation P… Tiago Pinto
- [SCITT] Re: New draft: The Coverage Attestation P… e.dogru
- [SCITT] Re: New draft: The Coverage Attestation P… Walter Hawkins
- [SCITT] Re: New draft: The Coverage Attestation P… e.dogru
- [SCITT] Re: New draft: The Coverage Attestation P… Iman Schrock
- [SCITT] Re: New draft: The Coverage Attestation P… Konrad Gruszka