[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 00:36 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 4F83412D1E2D8 for <scitt@mail2.ietf.org>; Thu, 20 Aug 2026 17:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787272591; bh=yZl+dMEa4Pemhn/H+nDQwiOVMpGQwsL5bKDdSRuPGqM=; h=Cc:From:In-Reply-To:References:Subject:To:Date; b=cGqb7/pB4qy48vZMgOYqotjQ1yQq4H6mNfYoNK55IdXiL26v5pJYUXbRXfR6AaTAS CnkV5QMwPX9foItk7tK6LnuIdBWhS0RK+0e1R9V7ZwZ+q1HoeLey13OP4e9iIXhxkg +Dv4bArnF2E3rd+apAY89IxoRpFXza5s8h6ETF44=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Level:
X-Spam-Status: No, score=-1.619 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_H2=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 1aNaUHrz8A30 for <scitt@mail2.ietf.org>; Thu, 20 Aug 2026 17:36:30 -0700 (PDT)
Received: from fly.ash.relay.mailchannels.net (fly.ash.relay.mailchannels.net [23.83.222.61]) (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 EA36912D1E2D3 for <scitt@ietf.org>; Thu, 20 Aug 2026 17:36:29 -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 404A47E0C80 for <scitt@ietf.org>; Fri, 21 Aug 2026 00:24:28 +0000 (UTC)
Received: from fr-int-smtpout27.hostinger.io (100-96-17-137.trex-nlb.outbound.svc.cluster.local [100.96.17.137]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 7ABCA7E1E7B for <scitt@ietf.org>; Fri, 21 Aug 2026 00:24:27 +0000 (UTC)
X-Sender-Id: hostingeremail|x-authuser|e.dogru@conarium.dev
X-MC-Relay: Neutral
X-MailChannels-SenderId: hostingeremail|x-authuser|e.dogru@conarium.dev
X-MailChannels-Auth-Id: hostingeremail
X-Drop-Arithmetic: 6ce88b7f109122b9_1787271868072_3018764532
X-MC-Loop-Signature: 1787271868072:3024255291
X-MC-Ingress-Time: 1787271868071
Received: from fr-int-smtpout27.hostinger.io (fr-int-smtpout27.hostinger.io [148.222.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.96.17.137 (trex/8.0.2); Fri, 21 Aug 2026 00:24:28 +0000
Received: from localhost (34.86.89.34.bc.googleusercontent.com [IPv6:2a00:1d35:17a4:d900:51f5:85e2:e74c:e841]) (Authenticated sender: e.dogru@conarium.dev) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4hR1Jn3XV3z30YS for <scitt@ietf.org>; Fri, 21 Aug 2026 00:24:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conarium.dev; s=hostingermail-a; t=1787271865; 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=7JRnICR4mn+w/WWRopmFFptwvYF7F0tU0V2QZ+m1pc8=; b=ir5Wb3hyfSQVU7DeX45mn7y/9vkU5WG48LcbwW9xmtr/OSAAZNgSJzwLvWeI+PP9y+Yt8K bwUMyeE/ZDCSWX+dVWODNTKbok2WGnh0WJYs28ljQ8Nfumtz+2U8jufNpb3BeyHu7t7fwu mL63FIvqtjAwhrUlqRR3oVtbz2/tuKGtruGSRYt4xRVTJ3qAzHmctcTBYYX5pbAFVVxPsn FTtMHuWIQvUqtm9Qwbjd3+Tg0pc9asQUO2+w/aC3MX6NVGo7qdPxtaIvBNL0/vOkJuDbXx rdBc/9GaNxQxb08bpk7+aq5nBgaA00/NIVQ1LmzNIo3xrSwNXODgetYH/cfF0w==
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"
From: e.dogru@conarium.dev
In-Reply-To: <jEdImn2bNKlGWITO9gK7r7EGdnPb8CMNEjz2sLEE8VOycj58CjssToBVJ5A-DIkTvWD7V5istl-Va8_KC3WVwa6CX7tKqtS8dw5imf0WBYc=@donttrustverify.pt>
Message-Id: <1787271857871353840.1787271857@conarium.dev>
Mime-Version: 1.0
References: <BYAPR19MB280613FCD91EC0ED03A93970ADA42@BYAPR19MB2806.namprd19.prod.outlook.com> <jEdImn2bNKlGWITO9gK7r7EGdnPb8CMNEjz2sLEE8VOycj58CjssToBVJ5A-DIkTvWD7V5istl-Va8_KC3WVwa6CX7tKqtS8dw5imf0WBYc=@donttrustverify.pt>
To: tiago=40donttrustverify.pt@dmarc.ietf.org
Date: Fri, 21 Aug 2026 00:24:25 +0000
X-CM-Analysis: v=2.4 cv=V5Av0vni c=1 sm=1 tr=0 ts=6a879ab9 a=RddCdUNZqxBAE8jYSUBS9Q==:617 a=qdAjI2r-bzQ5Qs_1:21 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=48vgC7mUAAAA:8 a=0-Hl2Lrx2KXBL0kaTXIA:9 a=a1J50a181rilr_tg:21 a=QEXdDO2ut3YA:10
X-CM-Envelope: MS4xfD2CbVVhA5dCizaWaSbTFdrw9rBa64HzBK4uDSIaZMz9kx6rAa2c8z5ccFSmG3KAYtlWvfWFgen2Myy+NxmXHPnSEt1C6ru9V/gWOE/QkKFDJ0ZuBWJ/ lciUi3DCbelAU+ts+ISk3OgtQfP5Ou7Hq8bJhOwZ/d0m3cX35HM630wtUIY+kIxeLIj2L9HdlA0YIukSpzoYj0mFzm48NOeNnIJ4guLrG1ER3zEolUwqSTb7 p4TQOYZFJicO87EZMEN9Gg==
X-AuthUser: e.dogru@conarium.dev
Message-ID-Hash: 2UMVQDS426M3ZMX3YI2ATNADGAYV62VL
X-Message-ID-Hash: 2UMVQDS426M3ZMX3YI2ATNADGAYV62VL
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: jhillier=40certisyn.com@dmarc.ietf.org, scitt@ietf.org, wdhawkins46@gmail.com, 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/gpaaCW2DT3z24IAgieKQa95wDis>
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 mailing list -- scitt@ietf.org
To unsubscribe send an email to scitt-leave@ietf.org
- [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