[SCITT] Re: SCITT WG: IETF 127 Agenda Planning

Nicholas Templeman <nicholas@csoai.org> Tue, 22 September 2026 03:44 UTC

Received: from out-utut-a194.jellyfish.systems (out-utut-a194.jellyfish.systems [198.177.127.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id 6646A3F for <scitt@ietf.org>; Tue, 22 Sep 2026 03:44:33 +0000 (UTC)
Authentication-Results: mx.ietf.org; dkim=pass header.d=csoai.org header.s=default header.b=blczWW4k; dmarc=pass (policy=none) header.from=csoai.org; spf=pass (mx.ietf.org: domain of nicholas@csoai.org designates 198.177.127.194 as permitted sender) smtp.mailfrom=nicholas@csoai.org
Received: from MTA-05.privateemail.com (unknown [10.50.14.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by BSN-01.privateemail.com (Postfix) with ESMTPS id 4hpmDn0HXKz3hhT9; Mon, 21 Sep 2026 23:44:25 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=csoai.org; s=default; t=1790048664; bh=aruBbimKwPpIWHe1OAiW8b6vBqUfCA+O5pD+2PhvETA=; h=Date:From:To:Cc:Subject:From; b=blczWW4k59tCQb5RKoP8A9vxeRyVgsumm2TixzZbB6exEmu137SZeACql+A/723/Q t1cPZmRaIoU1nm/YoqKWi2VtAvSRZmkuhI98xrfWwvZ85d+LqgIkZW+B1voiHYKdpQ YWvlbvZcGv1cYGJtoiLjL25c13UOnZ8PUAUBQ732JC6axOI30gClXGzuUkvb8OipD9 jQFZ4hy4heiKxUdnEGdUTHW2TdA7nxglxF/zo31Io/dPHVuff7W/UfPrspu9MNosa1 91ecOk1vBK9Wc/zxavPkDrGWzPd8ywPU/6NLzObFCqabNOxl3rXmIkbC0XA8x1Cq/N TO/dy1lQ+Eeww==
Received: from APP-02 (unknown [10.50.14.152]) by mta-05.privateemail.com (Postfix) with ESMTPA id 4hpmDl54B6z3hhTj; Mon, 21 Sep 2026 23:44:23 -0400 (EDT)
Date: Mon, 21 Sep 2026 23:44:23 -0400
From: Nicholas Templeman <nicholas@csoai.org>
To: scitt@ietf.org
Message-ID: <1798060325.83196.1790048663335@privateemail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.6-Rev95
X-Originating-Client: open-xchange-appsuite
X-Spamd-Bar: /
X-MailFrom: nicholas@csoai.org
X-Mailman-Rule-Hits: header-match-scitt.ietf.org-3
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-scitt.ietf.org-0; header-match-scitt.ietf.org-1; header-match-scitt.ietf.org-2
Message-ID-Hash: IT24IJKUM25PFJSNVQJNPJAIL2NMDXFC
X-Message-ID-Hash: IT24IJKUM25PFJSNVQJNPJAIL2NMDXFC
X-Mailman-Approved-At: Tue, 22 Sep 2026 07:54:35 +0000
CC: scitt-chairs@ietf.org
X-Mailman-Version: 3.3.10
Precedence: list
Subject: [SCITT] Re: SCITT WG: IETF 127 Agenda Planning
List-Id: "Supply Chain Integrity, Transparency, and Trust" <scitt.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/scitt/OKAXFA-eBiFXXImFjrk73vV_zGo>
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>

Nicole, Henk, all,

Support for Henk's second item, the re-chartering discussion on relation
semantics between statements, and one implementation data point for it. I am not
asking for a slot of my own, and our interoperability work belongs in the
hackathon unless it raises a decision for the group.

The data point bears on how a relation by digest is stated. Working the CCF 2.2
data-hash axis for the joint interop report, we minted one signed statement and
re-encoded it 64 ways using six CBOR encoding freedoms. All 64 carried one
identical Sig_structure and one valid signature, produced 64 distinct data-hash
values, and none was rejected by a stock decoder; 31 were silently repaired on
read. The prior art that closes the class is
draft-mih-sokolov-scitt-payload-binding-02, section 4.4, which Anton Sokolov
wrote before the measurement. For the re-chartering question the consequence is
narrow: a statement that says it references another statement by digest has to
say which bytes the digest is over, or two verifiers can hold the same relation
and disagree about whether it resolves.

Mikhail's audit-coverage case is one we meet from the other side. Our withdrawal
records share the subject of the statements they withdraw and fall outside any
set an earlier audit statement covered, and a generic verifier has no way to see
that from the headers today. So the decision I would want from the discussion is
the same as Konrad's: whether references of that kind, content-type agnostic and
readable without interpreting the payload, are in the proposed scope.

Two declarations so that nothing above is over-read. Council of AI is not a
Transparency Service and mints no Receipts, and both digests in that measurement
were recomputed from the published bytes rather than read off the implementation
that produced them.

Nicholas Templeman
Council of AI (csoai.org)