[SCITT] Re: New draft: The Coverage Attestation Profile (draft-hillier-coverage-attestation-00), and a request to break it
Tiago Pinto <tiago@donttrustverify.pt> Fri, 21 August 2026 00:05 UTC
Return-Path: <tiago@donttrustverify.pt>
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 CFB5B12D1BC44 for <scitt@mail2.ietf.org>; Thu, 20 Aug 2026 17:05:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787270711; bh=hv+zbVjLcQL1VfzMEHLpCcMB7HlVBkqMdQ0YrGTPy9E=; h=Date:To:From:Cc:Subject:In-Reply-To:References; b=mHI3zovJLhY6lDwM5r1OzKcr0iM0gxJul1dwdiuYquj9BfU8eF80fBFq0bWwrXpsa uXV9jmc8wPYipDHr4wEOZNBUTCSYJKwVidxVRbFaJRMFcZGq9fwxZVwTJGd7jybMuR cguHS8nOJD350FTgvtw71volUj0WtPc/DHL59TxI=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=donttrustverify.pt
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 JCzwllkIcO2G for <scitt@mail2.ietf.org>; Thu, 20 Aug 2026 17:05:08 -0700 (PDT)
Received: from mail-106117.protonmail.ch (mail-106117.protonmail.ch [79.135.106.117]) (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 59AC412D1BC1B for <scitt@ietf.org>; Thu, 20 Aug 2026 17:05:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=donttrustverify.pt; s=protonmail; t=1787270705; x=1787529905; bh=hv+zbVjLcQL1VfzMEHLpCcMB7HlVBkqMdQ0YrGTPy9E=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=nPtGadR+8aL1qEe6G8fCeX8fAAGiItNUzivSKYcHTYyJimEAXxpxVpep0nknZIqJX dl7sWSpfA9LTRF7WSXMjHPUKh89Lq8m7MonCs7aKsm9oTT/4mRS5AciVRVlO1iDq2f zZOgHAbZOTEXFXIpq0cFgl4Vw7qnoAkGsbks2/kGEXjQqo7/xwuy6/BNyT8/p7sQbl h5sPHPg8mton7lXfTYMRG92Ao0a4WWGUo+lk14T3hBENdWRYNOv8qQgIdlduY+TScE wkMPneRfeRhmUD8Prhui0C430d6TtNscFBExqH7Ibl58KZnKdKnhqKCnTDFjVY2Asr EpXi8jJKaGX2Q==
Date: Fri, 21 Aug 2026 00:05:00 +0000
To: Joel Hillier <jhillier=40certisyn.com@dmarc.ietf.org>
From: Tiago Pinto <tiago@donttrustverify.pt>
Message-ID: <jEdImn2bNKlGWITO9gK7r7EGdnPb8CMNEjz2sLEE8VOycj58CjssToBVJ5A-DIkTvWD7V5istl-Va8_KC3WVwa6CX7tKqtS8dw5imf0WBYc=@donttrustverify.pt>
In-Reply-To: <BYAPR19MB280613FCD91EC0ED03A93970ADA42@BYAPR19MB2806.namprd19.prod.outlook.com>
References: <BYAPR19MB280613FCD91EC0ED03A93970ADA42@BYAPR19MB2806.namprd19.prod.outlook.com>
Feedback-ID: 206570780:user:proton
X-Pm-Message-ID: ec79fef42e7fa1dd789e88d30959d71870983ade
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 2ZTLUYNW3B6YPX3W543AJTJIW4B2KFQB
X-Message-ID-Hash: 2ZTLUYNW3B6YPX3W543AJTJIW4B2KFQB
X-MailFrom: tiago@donttrustverify.pt
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" <scitt@ietf.org>, "wdhawkins46@gmail.com" <wdhawkins46@gmail.com>, "hello@vaara.io" <hello@vaara.io>, "playplay2736@gmail.com" <playplay2736@gmail.com>, "Todd.Gibson@t-mobile.com" <Todd.Gibson@t-mobile.com>, "anton.sokolov@tyche.institute" <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/DigjXBd4A5b_o0En6iuP4kq9RFo>
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>
Joel, I took the four break-tests in your message literally. I reviewed `draft-hillier-coverage-attestation-00`, dated 20 August 2026, against the exact bytes with SHA-256 `7a9eeb1fbdb1fee95697622546d2ae7efba762fff193d6ee34765233539ac353`. I think the core construct survives, but I found four things worth putting back to you, in the order of your tests. 1. `withheld` has no semantically consistent accounting under the current model The Terminology definition says a Disposition is the reason a unit was not examined. Section 4.1 says `unexamined` contains one entry per unit not examined. Section 6 then defines `withheld` as "Examined, but the result is not disclosed in this document." R1 requires `eligible` to equal `examined` plus the number of individually accounted unexamined units. For a withheld unit, I do not see a count assignment that preserves all four statements. If the unit is included in `examined`, as the definition of `withheld` requires, and also appears in `unexamined`, R1 counts it twice. If it is excluded from `examined`, the arithmetic can reconcile but the `examined` count is false by the definition of `withheld`. There is a second contradiction in the same mechanism: R2 says every unexamined entry MUST name a unit, while the Privacy Considerations say `withheld` exists so that a sensitive unit can be accounted for without being named in the document. The obvious defence would be that `unexamined` really means something like "not examined with a disclosed result". I do not think that saves the current text; it is the repair. It requires changing the Terminology definition, the meaning or name of the array, and the R1 accounting semantics. My instinct would be to separate two axes: whether the unit was examined, and whether the unit/result is disclosed. 2. I can produce a legitimate non-examination state that fits none of the closed dispositions Suppose a unit applies to the subject, is supported, is authorised, has all dependencies/licences/network available, and was intended to run, but the overall examination is aborted before that unit is dispatched. The abort could be operator cancellation, fail-fast after an earlier condition, or a global threshold. I cannot place that unit cleanly in any of the eight dispositions. It is not `not_applicable`, `disabled_by_policy`, `unsupported_input`, `resource_exhausted`, `failed`, `unavailable`, `out_of_scope`, or `withheld` under their current definitions. Section 4.3 makes this sharper: `integrity` says whether every dispatched unit reached a recorded outcome. In a clean operator cancellation, every unit that was dispatched may have completed, so `complete = true` remains consistent with that definition even though part of the eligible population was never reached. R7 does not repair this, because it only forces `complete = false` for `failed`, `resource_exhausted`, or `unavailable`, and none accurately describes the undispatched unit. Reducing `eligible` after the abort to the units actually reached would be worse: that is precisely denominator selection after the fact, the class of hidden-bound problem the draft is trying to prevent. I think this needs either a distinct state such as `not_reached` / `aborted_before_dispatch`, or an explicit widening of an existing disposition plus corresponding integrity semantics. 3. The denominator basis distinction breaks on a derived population Consider a denominator constructed by taking external catalogue C at digest D, enumerating properties of the subject, and applying a deterministic applicability predicate to C using that enumeration. The resulting eligible population is a subset E. `catalogue` does not fully describe the basis because E was not simply taken from C. `enumeration` does not fully describe it because the candidate universe came from C. `declared` is plainly weaker than what happened. The same issue appears with catalogue unions, catalogue subtraction by authorisation scope, and other deterministic filters. These seem like ordinary derived denominators rather than edge cases. A composable basis, or a `derived` basis that identifies its source bases and derivation method, would preserve the information that choosing any one of the current three loses. 4. I cannot yet do the independent implementation/run honestly because the conformance bytes are not identifiable from the -00 text alone The draft says the normative shape is given by an accompanying JSON Schema, that there are fifteen vectors, that three implementations agree on them, and that production fixtures are published. In the -00 text I have, I cannot find a stable URI plus digest identifying the exact schema, vector set, implementations, and fixtures to which those statements refer. I would not call that an R4 violation; R4 governs CAP-1 documents, not the Internet-Draft. But it reproduces the same epistemic shape that R4 is designed to avoid: a set is asserted and described while the exact revision of the set is not recoverable from the claim itself. That also blocks the contribution you say would be most useful. I can build a fourth implementation from the prose rather than porting yours, but I cannot honestly claim an independent run against "the fifteen vectors" until I can identify exactly which fifteen bytes/objects constitute that class. If you point me to a bundle or manifest with stable identities, I will run it independently and record the implementation source, environment, hashes, and results. I also have smaller findings around duplicate unit identifiers, R0-R8 versus "eight mutants", technique/depth being part of the stated bound but not represented in the normative object, the hiding property of the `withheld` digest, and one sentence in the XCCDF comparison. I held those back here to keep this aligned with the four tests you actually asked for. If any of the four above is closed by a sidecar rule that is not visible in the -00 text, send me the exact bytes and I will rerun the analysis against them. Best, Tiago Note added before sending, after Walter's message arrived. The review above had already been frozen and submitted to OpenTimestamps before I read his message, and I am leaving it unchanged rather than editing it in hindsight. The stamped file has SHA-256 `7717c82bba7842257cd0757945b8cbd2445390d47b2a29cb4d305671c2fbecce`. I can provide the exact file and its OpenTimestamps receipt so that the commitment to those bytes can be verified independently. Walter independently reached the same derived-denominator problem as my third finding, but he also identified an adjacent gap I had not: an enumeration basis records its method without binding the exact identifier set that method returned. His proposal to digest the ordered identifier set closes that output-binding gap. I think the two repairs are complementary rather than alternatives: a composable or derived basis preserves how the population was obtained, and the digest fixes exactly which population was obtained. Neither substitutes for the other, since a digest of the set does not let anyone re-derive it without the source and the predicate. His `not_sampled` and `not_yet_due` cases also reach the closed-vocabulary problem independently of my `aborted_before_dispatch` case. That makes me more confident this is a boundary in the current taxonomy rather than one missing label. His first test also finds a different denominator attack, fixing a declared population after the results are known. That is not in my frozen review, and I would rather leave it visibly as his finding than retrofit it into mine. On the fourth implementation, Walter and I are blocked on the same missing artefact. He has said he wants to write from the draft text alone, without reading your implementations. I think the same discipline has to hold between the two of us: neither should read the other's code or results before both are frozen. Ideally we each hash the implementation and our interpretation notes first, then run independently against the same pinned conformance bundle. Agreement would then be worth something. Disagreement would be worth more. Em quinta-feira, 20 de agosto de 2026 às 23:29, Joel Hillier <jhillier=40certisyn.com@dmarc.ietf.org> escreveu: > Hi all, > > I posted this today. It isn't a SCITT draft, it makes no reference to SCITT, COSE, receipts or transparency logs, but I reckon it still belongs in front of this list. > > draft-hillier-coverage-attestation-00, Informational. > > The abstract is one sentence and then the consequence: a report can be complete and still silent about its own scope. A statement that something was not observed gets recorded in a form that reads as a claim about the world, when what was established was a claim about a bounded population examined to a stated depth. Nothing in the record distinguishes the two, and no relying party can recover the difference afterwards. > > Why it should still land here. Four of us have spent a few days converging on a wall, from four designs in four subject matters, and the wall is that completeness of what was anchored is not proof that nothing was withheld from anchoring. This draft sits one layer up from that, and it's the layer where the loss actually happens: before you can ask whether a record set is complete, somebody has to have said what population it was complete of. Almost nothing says. > > Specifically, against what each of you has put on the list: > > Henri, your sequence catches a record removed from a held set and says nothing about a record never created, and you said so directly. CAP-1 is the vocab for the second half. A conforming document declares a population, a denominator whose basis is itself declared, and an individual accounting for every unit not examined, drawn from a closed set of eight dispositions. A remainder that reconciles only by arithmetic is refused. A count that comes out right and can't say which units it is right about is exactly the artefact this declines to accept. > > Emek, the disposition vocabulary is your rung ladder now aimed at a very different question. `not_applicable`, `disabled_by_policy`, `unsupported_input`, `resource_exhausted`, `failed`, `unavailable`, `out_of_scope` and `withheld` are not eight ways of saying "no". They're eight different grounds, and collapsing them into a fraction is the same information loss as reading a result at an unnamed rung. Your rule that an unnamed ground reads at the weakest one has a direct parallel or analogue here, and I think citing yours is the best option. > > Walter and Todd, the receiver vantage needs the executor's record set to say what it purports to cover. As things stand - a short set, and a complete set over a narrower population, are the same bytes. > > Pablo, three denominator bases are defined - `catalogue`, `enumeration` and `declared` - and which one you're on is your placement question asked at the level of the population rather than the anchor. Another thing worth recognising IMO. > > What I'm actually asking for, and it isn't just a good read. > > Fifteen vectors ship with it: five positive, ten negative controls, each negative control carrying exactly one mutation and required to fail under the rule it targets rather than under some other rule that happened to catch it. The verifier is mutation-tested: each of the eight normative rules is silenced in turn and the class re-run, and the class must fail each time. Eight rules, eight mutants, eight kills. Three implementations accompany it, one on Node built-ins, one on the Python standard library, one a single-file HTML verifier, and there's a production run at a scale of 227 catalogued check identifiers with both conforming and non-conforming fixtures published. > > Please try to break it. Specifically: > > Construct a document that satisfies all eight rules and still misleads a reader about what was examined. That's the failure the draft exists to really prevent, and it's the one I'm least able to test myself for obvious reasons. > > Find a disposition that belongs in the closed set and is not in it. A closed vocabulary is a strong claim and I think eight is a suspiciously round number. > > Break the denominator basis distinction. If `catalogue`, `enumeration` and `declared` do not partition the real cases, the whole accounting rests on a trichotomy that leaks. > > Here's the claim I'd probably attack first if it were somebody else's. "Eight rules, eight mutants, eight kills" and "three implementations agree on all fifteen vectors" are claims about my own rigour, and this list has spent the last week or so establishing that those are the claims most likely to be false, because nothing was pointed at them. Three implementations written by one author from one reading of one text agree that the author is self-consistent. That's not nothing, and it also isn't what the sentence sounds like. The mutation result is the stronger of the two, since a silenced rule the class still passes is a real finding, but it tests the verifier against the rules and not the rules against the world. > > So the thing that would actually move it is a fourth implementation by somebody who has never actually spoken to me IRL, working from the text alone, disagreeing with the other three about a vector. Henri, that is the shape of what you built the run register for, and I would rather CAP-1 acquired one independent run than another rule. > > What it deliberately isn't. It carries no action log, no transformation sealing, no quality assessment and no trust establishment, and it doesn't tell you whether to believe the examiner. It's basically just coverage accounting and nothing else. Section 1.2 states the relationship to existing practice before the draft makes any claim of its own: coverage accounting with a declared denominator is settled in configuration assessment and in vulnerability scanning, XCCDF has had it since 2012 and the PCI ASV programme since 2006. What is new is separating the vocabulary at three points where those formats lose information, not the idea of counting what you looked at. > > Which is also why I think it composes with the work here rather than competing. A transparency layer records that something was attested. CAP-1 gives the thing being attested a legible scope. A receipt over a document that can't genuinely or specifically say what it covered is a receipt for an unbounded claim, and this list has three drafts whose payloads would be more useful bounded. > > Wrong answers welcome, and preferred. > > 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