Received: from mail-pz2-x28.google.com (mail-pz2-x28.google.com [IPv6:2607:f8b0:4864:3b::28]) (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 485284B for ; Sun, 04 Oct 2026 20:23:05 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=gmail.com header.s=20251104 header.b=mnhtC+bN; spf=pass (mx.ietf.org: domain of csingletary@gmail.com designates 2607:f8b0:4864:3b::28 as permitted sender) smtp.mailfrom=csingletary@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pz2-x28.google.com with SMTP id d2e1a72fcca58-88a0f29ce98so414968b3a.3 for ; Sun, 04 Oct 2026 13:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1791145378; x=1791750178; darn=ietf.org; h=mime-version:content-type:msip_labels:content-language :accept-language:message-id:date:thread-index:thread-topic:subject :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=ca4dDoUFMcoRMzVuXra6ACt+0f6GtLyar2MCn9iFYww=; b=mnhtC+bNUDMqlrhl7AH8QCiI7AzFu6Qyz+WciXAJguC8jWYwyWFAldlkdv80LyFx18 WpBKWYveMD6+aXPL18U9JwyzUybURvBza/ht8kgkZ5Qq+QcqtlFd77Cfb5K82yKSUBsR ibC6PHsAO+EpcddtqHRwKQEKQUbcPFemYMZzC7CEMQb/1F45eOlkqkn5hYZ+TB9CK3Yp 0crwtbRS9bsJqqLi1gYY5fOWyeey9b1pFdBuzdmk3jCNsR6gPFJ5T3GmH0Bs1VW2KaeO szts5mvxa3nByx+VRxymqaRQwtjFs/atgIKp0QIK+bsBnIf5WIJVa0gv3RkCykTH8IG3 yH/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1791145378; x=1791750178; h=mime-version:content-type:msip_labels:content-language :accept-language:message-id:date:thread-index:thread-topic:subject :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ca4dDoUFMcoRMzVuXra6ACt+0f6GtLyar2MCn9iFYww=; b=19miK9n5iOnhZ/jUtYa5OZ7kA+wnfRIViCUMS15pWwhobKpqf3cyFY5vYVarKPGLK2 YXOd0hUEtGzKbvsVIlDOSJipsCHPhiNtBGdNdYw+misZP1POdkIWw0wumDHt5GAUJ0zD S3mePOvGxRh1s/Z9ZKF3Hqkrh71ufzi+Dlbd0uHzuCGo8gjR2mTE247jWqg20kWcH60d DnUE2kENiPPlYkhtA/lL8CeI94cou0RL5CKm97Qtpu2r7+3mG9Ggy+IFdR5ULfxtzFDw DHCr0XYq72XTbkN71rCCKnZT1xx9Gv9E9iPJCXyYZoKOgXChEftAsq+BKTAnEBzZ/UXp cROw== X-Gm-Message-State: AFuF++nOAIu8mBqgw0R+iWEvm01inmd/+5JhuE0eggMEUyfvIkgSz080 DMTpR7Ip3R3itfzk3oXx5hPyVgzdFEZG93VDPg9i+TEukTmvrxMvBhVWUj2FkQ== X-Gm-Gg: AYBFou0CXFQjVP4LRigSRZOdi+9CY3Rf6RiymuqlJD+4CTmGHAsSC7mjE9Fi1ySIo9j 4SgGoWPvV89wX26XpKX50z6blNWmQCqcHwZOElfWXg+xWi7wgCzQreKpA6X942yFmJ6R9d3bnID y4xL33loqUAduULGNlImcHxy4RDSuKWmnhUqxJAlaw9BRuZEkfNvwRna8Y4R93Gc12MGfXX4Hjl ihP5R8UV4Ok6056demPXVyIrDZQkwhBQUHpjfrRG5ULJ5JUpCnT9iBDjS0ExluK1576SVEMisPu 6aaT9mbTmwNUFk9ahHsbCCDOqSc8ql9/eNYnL2MGKcC5PInNG4VxvXYVr/BTYzC38KMkAqSVdxY aVn62lsmFALGE9crV3/8dA+BjkBh+jhOeXYcyLHzATV5GwG2LW2vCBjHl5FgXlkjJey66BMlOQ5 Lhqs6WpqAYmbov1lJQ0pgDVptQKsMFR6bG9wB3lgXRms2C8rG2yPWBpZuaWMj0m0QllZ1lW/ShT +ZL2LHuLiu6vNbfDH+gAKKF X-Received: by 2002:a05:6a00:94d1:b0:886:3d9e:aac1 with SMTP id d2e1a72fcca58-88af58d4ef9mr7428031b3a.45.1791145378060; Sun, 04 Oct 2026 13:22:58 -0700 (PDT) Received: from DS0PPFF5AE83660.prod.exchangelabs.com ([2603:1036:903:36::1d]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-88cb27d93bdsm1348674b3a.30.2026.10.04.13.22.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Oct 2026 13:22:57 -0700 (PDT) From: Cliff Singletary To: "scitt@ietf.org" Thread-Topic: [SCITT] Re: Action requested: Focused Working Group Last Call on Section 4 of the CCF Profile Thread-Index: AQHdVD4iaPbr9BYCdUG7kLMlmzdUag== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 4 Oct 2026 20:22:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 msip_labels: Content-Type: multipart/alternative; boundary="_000_DS0PPFF5AE8366065E17D021472A891897EF8972DS0PPFF5AE83660_" MIME-Version: 1.0 X-Spamd-Bar: -- X-MailFrom: csingletary@gmail.com 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: V7W7MGVUGOYZHRFA4257I4ZSON6PETRE X-Message-ID-Hash: V7W7MGVUGOYZHRFA4257I4ZSON6PETRE X-Mailman-Approved-At: Mon, 05 Oct 2026 18:56:17 +0000 X-Mailman-Version: 3.3.10 Precedence: list Subject: [SCITT] Re: Action requested: Focused Working Group Last Call on Section 4 of the CCF Profile List-Id: "Supply Chain Integrity, Transparency, and Trust" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_DS0PPFF5AE8366065E17D021472A891897EF8972DS0PPFF5AE83660_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Konrad, all, I independently recomputed the fifteen Section 4 vectors (b7n0de/proofbundl= e@8994f52) from the -05 text alone: Python standard library plus cryptograp= hy, my own CBOR decoding, and none of the vectors' checker or generator cod= e. The per-vector results table is available on request. Figure 9 as written reproduces all 15 recorded outcomes. On the four reject= s (S4-11, S4-13, S4-14, S4-15) it also fails at the same first statement. A= strict reading built only from -05's MUSTs and CDDL agrees with the record= ed reading B on all 15 outcomes, with and without tree sizes. For Section 4: * Figure 9 accepts S4-03, S4-05, S4-06 and S4-12, which 4.1, 5 and Figure 11 = exclude. I support Figure 9 asserting that every proof in a receipt, consis= tency or inclusion, recomputes the same newer root. Figure 9 should also sa= y whether verifiers reject or ignore verifiable-proofs keys other than -1 a= nd -2. * Two anchor conditions are checkable without m: the first sibling is a right= sibling, and at least one sibling is a right sibling. Both hold for every = canonical proof with 0 < m < n =98 128, and they reject S4-08 and S4-09. 4.= 2 could state them. * S4-10 passes every size-free check and fails only once (m, n) =3D (6, 7) is= known. That makes "neither tree size is needed for verification" look too = strong. If the full anchor rule needs sizes, how is a verifier meant to obt= ain m and n bound to the roots? Thank you, Cliff Singletary --_000_DS0PPFF5AE8366065E17D021472A891897EF8972DS0PPFF5AE83660_ Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Konrad, all,
I independently recomputed the fifteen Section 4 vectors (b7n0de/proofbundl= e@8994f52) from the -05 text alone: Python standard library plus cryptograp= hy, my own CBOR decoding, and none of the vectors' checker or generator cod= e. The per-vector results table is available on request.
Figure 9 as written reproduces all 15 recorded outcomes. On the four reject= s (S4-11, S4-13, S4-14, S4-15) it also fails at the same first statement. A= strict reading built only from -05's MUSTs and CDDL agrees with the record= ed reading B on all 15 outcomes, with and without tree sizes.
For Section 4:
    1. Figure 9 accepts S4-03, S4-05, S4-06 and S4-12, = which 4.1, 5 and Figure 11 exclude. I support Figure 9 asserting that every= proof in a receipt, consistency or inclusion, recomputes the same newer ro= ot. Figure 9 should also say whether verifiers reject or ignore verifiable-proofs keys other than -1 and -2.
    2. Two anchor conditions are checkable without m: t= he first sibling is a right sibling, and at least one sibling is a right si= bling. Both hold for every canonical proof with 0 < m < n =98 128, an= d they reject S4-08 and S4-09. 4.2 could state them.
    3. S4-10 passes every size-free check and fails onl= y once (m, n) =3D (6, 7) is known. That makes "neither tree size is ne= eded for verification" look too strong. If the full anchor rule needs = sizes, how is a verifier meant to obtain m and n bound to the roots?
Thank you,
Cliff Singletary
--_000_DS0PPFF5AE8366065E17D021472A891897EF8972DS0PPFF5AE83660_--