From: Joel Hillier <jhillier@certisyn.com>
To: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Re: draft-ietf-rats-multi-verifier-00: corrections to the
 cell table
Thread-Index: AQHdPoPNeIttWEQFDkC5tiZDE/f2hg==
Date: Mon, 7 Sep 2026 05:17:21 +0000
Message-ID: 
 <BYAPR19MB2806E5FF630BD1CFB4BD05EEADB22@BYAPR19MB2806.namprd19.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
msip_labels: 
x-ai-generated: mcp-office365
authentication-results: dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=certisyn.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BYAPR19MB2806:EE_|CO1PR19MB5221:EE_
x-ms-office365-filtering-correlation-id: 4c1846db-d4e5-459d-c008-08df0c9f4b9d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: 
 BCL:0;ARA:13230040|1800799024|376014|23010399003|366016|10067099003|7055299009|6133799003|56012099006|18002099003|38070700021;
x-microsoft-antispam-message-info: 
 sgjKfubWOSdD99WIk2OkEJQuUi0q3b2AvoPQ8pejCAMEeLyqmRjYPYTJ01b3I/vVFM2S9KktHxLIdySZXVa0OWu9EoyRUWBZkoJxPtHreTnT8ugFUh0eDTFtImgZot8mOH2a9ai44hm2wLDeCv3DdnHnCoYobnt7QeFMUVgG7GkVv4Y/cb/o6QcbY26ADP0r9jW8pVdd4GqCO9xSjl1kttW5lQQWPY7uJw3v9YTV6ZqRW2qFEi3wPKG3W9d3HUhqPmeLTQQq/wCs908vUY8BRCNsR+VkqKmiyPxK4LpG00Vk/u7Br9HneFJm4sagbX4uKdxIZ6hNMBQR3KltAyC649hrOc5qDFXJBY6lTZ6mSPcQd1Q7s+gr9P+dlo61fAWLzDQZe8Ug8OKiruot1yHpn2s1pWbgcZfbtCuTKy+aKQSeecMCSry9V6bV3s/wwGaxxUPuhuUWuoyV2A5rMiD0sNgKSwuBy55bvgZjF0AluB4YuCg18VqQg+1i2HxhO1P9XSeOl7iMthScC4YX+M8Sa6YIniBUEEa61nxZ+0SDC6Kq5nFche9iwr0Q6slTHW5fNHop6QHizFrcEHUKvdc0j0gJ4rYskrOol/Sf4ZHCOKcUVPqQmk8N1j+d+qAJfJJjpTpS1eQ8HwiaqmzRWrJWaQjeTykMjpEWFUUbK3YixTajKdIh121worH1VvvY1l6Mh5Atn5rHOEiSmBgYxct7hkap0p8ToJC7FoaWDtx2Ne5Ekvn00zGQ0fCQRbEwRJWh
x-forefront-antispam-report: 
 CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR19MB2806.namprd19.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(366016)(10067099003)(7055299009)(6133799003)(56012099006)(18002099003)(38070700021);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?iso-8859-1?Q?yz0Bjkit/ga9Q4zyJtOV0ONbaB+2i374wV9DLKiuKJqjPCQgP7f0+on2YK?=
 =?iso-8859-1?Q?xRs7Xrjsxy2BfL4GcfDQNgZPqbmXxKEhwtCoygrJERH9F3MqoNt6hHaJDu?=
 =?iso-8859-1?Q?c/O/ej2ogUGHgj4pfnXmPYlXip1bJQZ/IgdxHjekQ6OphzHNRHSBDFBMde?=
 =?iso-8859-1?Q?GwNBnrmRGVU9nZdzk+Vf1E4M0rGejZrx7FFnx9bs+bmL9Ea76L6IbW/rgh?=
 =?iso-8859-1?Q?KoCtEdIfylehAVS9AAvuC4bJceUhvpcLUn9O7JakS7cFqNJtaa3kna9yWS?=
 =?iso-8859-1?Q?dPJ+aDqCyrRgRsYl2Rrkc75Xty6L83J9vuVV8jOnEmDMK9Nu5gH9LAgm6u?=
 =?iso-8859-1?Q?MrfKDTf3LooINoeXYXOtLQ3uoD5gT6OPFZUrQN+5jjoOCzLdfY6TYgDPPB?=
 =?iso-8859-1?Q?O4GIH83UCJjLr9bzag06nfM9LkvN1eQ5RliMG/8J0UzcSZHGUNOfo1TbWR?=
 =?iso-8859-1?Q?gpakLiOahP+xDNywUmyQzHJlBbyYaES5yYvnLzQFJNrvkqbtJm6ug9VAqb?=
 =?iso-8859-1?Q?yeHloMaLx2YFdVXG/nY/SSnxc7dU7S9VhZHitPG1b/Ab67HY8VTnSXvJgW?=
 =?iso-8859-1?Q?450DVLiXKajSMfTKYR8nI8FJ7Dkpns86Dp1bbeplTSTyjcYMQF6rV6p3wM?=
 =?iso-8859-1?Q?61Fx0LJNUEWziLv0Rp33ubI7nXvZdC52WVi8rJXNIApP/PysinZdNraioF?=
 =?iso-8859-1?Q?w+4S6UP0s3gOLXK1AOYvArGu3b8GwiO+yD8D03Q9P0xaDWxsT/1X37PP3c?=
 =?iso-8859-1?Q?oYasY3bWJK8WokgNdmq7qrv64a8E1dUx4mHSrqtZx0/TwAUO7PMKPb2tBH?=
 =?iso-8859-1?Q?E8YX5ji4ofTz9caU7bvEtOT2N9FpOHyErxsHwB906xoJwxaVOi+BDaJA1d?=
 =?iso-8859-1?Q?ogf7oPc7459NGyBoSmrm0FvDvbPARcIUiSU7MXCLg+i716ektd/oQh0Ail?=
 =?iso-8859-1?Q?QGKYmvrS4fOvEkukRp/jm58BpeowHVQVZryhNgiAiIniOh3gfcqwLNAygC?=
 =?iso-8859-1?Q?RjCumXMkkeGEa8mZuXTz/3EUXYnNP1Excx63X1AK50YUxGaAeDNnZFt9vK?=
 =?iso-8859-1?Q?P+tPbRBuHUjd32JrXIJqK50KK5fg4+W0z/1098honbr9kMctISEd3Iv8Em?=
 =?iso-8859-1?Q?wdLWbRVltfU/WN+Gc5MMskmYuxBdDjIrZujM3P+r8b6MZB83UMNmzbehXM?=
 =?iso-8859-1?Q?aOTWP7KhtoZIJENXC+8ePjcA6FzYva9kFguLE+gFCKeWKd8diL2sH5Qsjt?=
 =?iso-8859-1?Q?747lChXZBgX5fldYwB0KCkpT8HdK0WOuozVIC3KTMO1Dx7zDde457TXi0P?=
 =?iso-8859-1?Q?d5ucmvlgPzDIo7UmhkNXla/UxOSgl1Wh3hIY2n1MaCUh1KR3MMH2mdTJpG?=
 =?iso-8859-1?Q?WScKpM5pg5x0UDi5n3ccOIKUe4eGvKqTvQKAHQ0FB074O8vpjGU+ieNTdt?=
 =?iso-8859-1?Q?k1GWAT7dBsRbUIIdkhsfGrOn7HyIWPOtxtkaadT74Z/+V+gRa7sk8x7jWF?=
 =?iso-8859-1?Q?eMm8qwzBPZVTIgpXElCYu3L4r7B79vQyV93JyCPPYT7oipyzKXxiAuH/Cs?=
 =?iso-8859-1?Q?cX0qC1OACdK/DmIcH94oa5H95Cz4dM603ZdvcLl70LEX3LSRFl3KbBJ7ML?=
 =?iso-8859-1?Q?U0pnfYVZgl6VAeCs0btjtSlDdmVj+iaJ6SIkBqx8lOBEZN1TCdVZrvqKGx?=
 =?iso-8859-1?Q?eYfAQawuwK2mKMoyMa/3qVPnvTKU23EXr6NrY2CfB+tMwZsMW5vUDCvqPA?=
 =?iso-8859-1?Q?xB7VPQu9UBJC1er3cu1eB4h74M2A6oJ6p6CstY3khikUSH?=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: certisyn.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR19MB2806.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 4c1846db-d4e5-459d-c008-08df0c9f4b9d
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2026 05:17:21.7378
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 539494d9-b23d-4e5a-bc74-62613e2403f0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 
 mhsf+uuXLPtgJ1smJydQHqTwUbG39WlslrUhNESzO3fyrDH0zWYAAIH2YnYdySQNYqFYc7da7hhE5kZcYhMkFg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR19MB5221
Message-ID-Hash: UUL6MYLBOU7KZG3AL3YFSNXT6A6FESSR
X-Message-ID-Hash: UUL6MYLBOU7KZG3AL3YFSNXT6A6FESSR
X-MailFrom: jhillier@certisyn.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; header-match-rats.ietf.org-0;
 nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: =?utf-8?q?=5BRats=5D_Re=3A_draft-ietf-rats-multi-verifier-00=3A_corrections_?=
 =?utf-8?q?to_the_cell_table?=
List-Id: Remote ATtestation procedureS <rats.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/rats/FbR5Gdmn4koxPqHLGz3P4LiO_UM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Owner: <mailto:rats-owner@ietf.org>
List-Post: <mailto:rats@ietf.org>
List-Subscribe: <mailto:rats-join@ietf.org>
List-Unsubscribe: <mailto:rats-leave@ietf.org>

Hi everyone,=0A=
=0A=
Todd Kirton went back through the -00 text and checked my cell table of 4 S=
eptember against Sections 6 and 7 rather than Section 5 alone. He is right =
on three cells and partly right on four more. The corrections are below, an=
d they are his findings rather than mine.=0A=
=0A=
The table read Section 5 as if it were the whole document. It is not, and S=
ection 7.3 carries normative requirements that decide three of the cells ag=
ainst what I published.=0A=
=0A=
WITHDRAWN=0A=
=0A=
  H3  Unprotected Partial Evidence.  WITHDRAWN.=0A=
      I rested this on Section 5.1's "may wrap the Partial Evidence ... in =
a=0A=
      signed Conceptual Message Wrapper (CMW)". Section 7.3.1.1.3, Evidence=
=0A=
      Integrity and Origin Authentication (LV -> CV), says: "The LV MUST si=
gn=0A=
      the Partial Evidence using a key that the CV trusts. This prevents an=
y=0A=
      on-path attacker from altering the Partial Evidence." Protected and=
=0A=
      unprotected Partial Evidence are not two permitted end states under t=
he=0A=
      document as a whole. The cell does not collapse.=0A=
=0A=
  H4  Freshness, hierarchical.  WITHDRAWN.=0A=
      I rested this on Section 6's "the Verification of Freshness should be=
=0A=
      checked by the Lead Verifier". Two things are wrong with that. Sectio=
n=0A=
      7.3.1.1.5, Replay Attacks, says: "The LV is responsible for enforcing=
=0A=
      freshness (via nonces, epochs, or timestamps). This freshness value=
=0A=
      MUST be propagated to CVs and back to the LV, to ensure final AR can =
be=0A=
      validated against the original challenge." And the "should" I quoted =
is=0A=
      lowercase, so under the document's own BCP 14 statement, which carrie=
s=0A=
      the "when, and only when, they appear in all capitals" clause, it was=
=0A=
      never normative in either direction. I treated a word with no normati=
ve=0A=
      weight as a weak requirement. The cell does not collapse.=0A=
=0A=
  C4  Freshness, cascaded.  THE DOWNSTREAM HALF IS WITHDRAWN.=0A=
      I said the guarantee holds at the head and fails downstream, because=
=0A=
      5.2.3 lets the Relying Party enter anywhere. Section 7.3.2.1.4, Repla=
y=0A=
      Attacks, says: "The first Verifier in the chain (the one receiving=0A=
      evidence from the Attester/RP) is responsible for enforcing freshness=
=0A=
      (via nonces, epochs, or timestamps) for the entire cascade. This=0A=
      freshness value MUST be propagated with the Evidence and Results=0A=
      through the chain." The freshness value travels with the results, so =
a=0A=
      Relying Party entering at Verifier 3 holds it. What the text does not=
=0A=
      require is that the results name which Verifier established it. That =
is=0A=
      a provenance question and it is narrower than what I published. Todd=
=0A=
      Kirton drew that distinction and it is his.=0A=
=0A=
RESTATED, NOT WITHDRAWN=0A=
=0A=
  H1, H2, C1, Y1 were published as COLLAPSES. They should read as permits a=
=0A=
  lossy profile, which is a weaker claim and a more accurate one.=0A=
=0A=
      The draft says it "only covers the architectural aspects introduced b=
y=0A=
      the Multi Verifier concept, which is neutral with regard to specific=
=0A=
      wire formats, encoding, transport mechanisms, or processing details",=
=0A=
      and it defines an Aggregated Attestation Results as "a collection of=
=0A=
      Attestation Results". Absence of a Section 5 requirement to carry a=
=0A=
      distinction is therefore not proof that the architecture collapses it=
.=0A=
      It shows the architecture does not prevent a profile from collapsing=
=0A=
      it. For a document that is deliberately architecture-only, that is th=
e=0A=
      finding that is available, and it is the one an author can act on.=0A=
=0A=
STANDING=0A=
=0A=
  C2  Who aggregates and who signs.  STANDS, and Todd Kirton strengthened i=
t.=0A=
      Section 7.3.2.1.3, Evidence and Results Protection, says "Partial and=
=0A=
      Aggregated Attestation Results SHOULD be signed by the Verifier that=
=0A=
      generated them", which sits alongside 5.2's aggregating verifier and=
=0A=
      signing verifier being different entities. The provenance question is=
=0A=
      about which Verifier is asserting which part of the aggregate.=0A=
=0A=
  C3  Relying Party entry point.  STANDS. Not addressed by Section 7.=0A=
=0A=
  H5, C5  Still acquitted, for the reasons given the first time.=0A=
=0A=
THE CORRECTED COUNT=0A=
=0A=
Eleven cells. Two withdrawn outright, one narrowed to a provenance question=
, four restated as permissive rather than mandatory, two standing, and two =
acquitted at the start and still acquitted. The arithmetic in my 4 Septembe=
r message, eight collapse and two do not and one partial, is superseded by =
this one.=0A=
=0A=
WHAT THE EXERCISE ACTUALLY SHOWED=0A=
=0A=
The pattern I claimed still holds, but it points somewhere more useful than=
 I had it. The cells that survive contact with the whole document are the o=
nes Section 7.3 pins with a capitalised MUST. The cells that remain open ar=
e the ones where Section 5 describes what an entity does and no later secti=
on says what the result must carry. That is a smaller and more actionable f=
inding than the table claimed: the architecture is sound where it is normat=
ive and permissive where it is descriptive, and the gap between the two is =
where a profile can lose a distinction a Relying Party needs.=0A=
=0A=
So the suggestion from the first message stands, narrowed. Rather than new =
machinery, a requirement that an Attestation Result names the ground it sta=
nds on: which component, appraised under whose policy, with freshness estab=
lished where, and with the evidence protected or not. Section 7.3 already s=
upplies three of those four for the hierarchical case. It is the naming tha=
t is missing rather than the guarantee.=0A=
=0A=
Todd Kirton also sharpened the test itself, and his formulation is better t=
han mine. A collapse finding needs three things: materially different upstr=
eam conditions, the same downstream-observable result, and a downstream dec=
ision that would act differently if it knew the distinction. My version ask=
ed for the first two and assumed the third. Several of these cells fail on =
the third, which is exactly why they should read as permits rather than doe=
s.=0A=
=0A=
Happy to take any of the surviving cells into a PR rather than the list if =
the authors would rather work it there.=0A=
=0A=
Best,=0A=
=0A=
Joel=0A=
Certisyn, Inc.=0A=