Return-Path: X-Original-To: spasm@mail2.ietf.org Delivered-To: spasm@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id B1D30D8C699F; Thu, 9 Apr 2026 09:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775750943; bh=CVllnrQeLSxx/IsZHSTeOUnATVENnDMrEX0yGRdoIyg=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=JtV8cRh209XGywMIpFZB/E8OJpDnZOyxceh4M/uYkJEMky8+TAUPC9bkQVSeD8ofu yvRQ4E2VUSRoS58h1NHcJnAOaPtD1/hUBnAewK5nKh6EZ80PadGgqw0dl/iwb6jKv8 oCCttWiebio7YZaQn1glC2CPVz4IGPDWtmiiJzCE= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.be 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 G-qnkwZV_sCI; Thu, 9 Apr 2026 09:09:02 -0700 (PDT) Received: from CY7PR03CU001.outbound.protection.outlook.com (mail-westcentralusazon11020091.outbound.protection.outlook.com [40.93.198.91]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 63D2BD8C695A; Thu, 9 Apr 2026 09:09:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cYMDZEJM17Gzn4H3AJlGAuTOFCkX9TEod1WslcdF+A0sdDtfBdWC8feE1bIIOnSstYCeUSzEE39NwvYl4V2OVlucFPo8IE12yiBXu5KRAXO2hKW4oN+0Fc6p6BF4F1BXW8J8UZLGAnYf4NYRTwZB7RIDqw14SaLtidvB1paIyxG3b+NyEYHQrE//tXl6/Z/UzQFLitbzbGBYHOBBP4woEKaH45rM3Eghn1lHyvoHrU2731ZUzNmmbHu/dUhBMM6LwtU8pHG4lyfXnERteLVeZbdQP9R6R447qOPeGXuMFD9JoplhmB45nBGto3B8ngTQadiOyGGA9lWfn/CKtVUW9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wbyA/USPfoU+/u95JYr3LRRBolvPfMlmw+Rd1ijApe0=; b=WqDJUeFMa+Q8qkC3lm4PSQIo2LETjSbbE5sCMu+Y1SxgfMN0TiOW6VLQZ8SMk8ASvsXtjDqFkAxUNvaR/SGJSGwehL+2uwXcoxTkXijdjvTDT8Yt/zzAFtsQYPggNW9cDpgZarQ5s9p4FfI5ljubaF9B/bqkFKKk0cdVcD0g2vySX6443wa56E3IR9iUMZ6csl4GjA4pIHXfyxML9iBZzLB6rMBF14FSU5BE8t6U+Afw1yY3qpSOUpfqHJstcloufmFVtRKZZJjFkaqI1+h7ypx5M17iqiG64miZ2rYtN9gQao2sMokJDTfada3MBge3lU0SfIc/TB6Wn4Is63wmaQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=evequefou.be; dmarc=pass action=none header.from=evequefou.be; dkim=pass header.d=evequefou.be; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.be; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wbyA/USPfoU+/u95JYr3LRRBolvPfMlmw+Rd1ijApe0=; b=TDyMXkxxjHRL1LDoDtAoyVsk0iNrQlwV/FYyOheotHvp9i96wN0armM3b7cna1S53batOaH1YMIidFB1+ul96hLGfEVEIUdf3zXHRbgHiIG4FykGnhcWNFaXlk4mZMqc1kxVRufAt5vpg2teHPjRLYc71U2Z1VyWTA7slkdQRm0= Received: from IA0PPF726CD7A1F.namprd22.prod.outlook.com (2603:10b6:20f:fc04::d2b) by LV3PR22MB5103.namprd22.prod.outlook.com (2603:10b6:408:1e1::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.21; Thu, 9 Apr 2026 16:08:52 +0000 Received: from IA0PPF726CD7A1F.namprd22.prod.outlook.com ([fe80::a2b8:b90:2078:cad0]) by IA0PPF726CD7A1F.namprd22.prod.outlook.com ([fe80::a2b8:b90:2078:cad0%5]) with mapi id 15.20.9769.020; Thu, 9 Apr 2026 16:08:52 +0000 From: Mike Bishop To: Mike Ounsworth Thread-Topic: [lamps] Mike Bishop's No Objection on draft-ietf-lamps-pq-composite-sigs-15: (with COMMENT) Thread-Index: AQHcwebmjU4OQ32hUkykyJmeWmCCyLXV70kAgAD+T/U= Date: Thu, 9 Apr 2026 16:08:51 +0000 Message-ID: References: <177505503029.1878830.18439971232258801938@dt-datatracker-5775bcb475-pnkww> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=evequefou.be; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: IA0PPF726CD7A1F:EE_|LV3PR22MB5103:EE_ x-ms-office365-filtering-correlation-id: 42dde505-f461-4c12-5ea6-08de96524ad7 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|4022899009|10070799003|366016|1800799024|376014|38070700021|13003099007|18002099003|22082099003|56012099003|8096899003; x-microsoft-antispam-message-info: UnD6u/uKdk8swClfGSUoO9+dkYohCBWdkkNasdBhvBI7jtYdwRDu+t5r+b/IcmiHOZYDKxmvs8QPoZXVCdnEt8DH0GtMh83WxzkmyWb+SNtAefVd8M3K7F13DutYee97Qa94kYvYuh0WEVKPjOpogZms5sGITUVoyNSOXH70DTxUxcFmWKHDvh5eki4jJaFrnwZQ5KivNMMB0vAqYsv1g21Xa/oNJYJ2EJZsU2l0LFkApYp5deqXesKb9O1ZunniabJM6KFZ92/IOt8OnV0ussI3k82dlw8hsdXF0/VZVShUa1/0EB8UgL/AlplwzQrdDXZ5/J1NyEbZ0O44ZRWYJcxuUVaJSc5t6NJx5lFKdqLDhTGgt5tsB79/w3rMVZ5dPryKlDsg+NvnWq6ockKKC8lgjJkYKPn1UAmjIjl6oIDMMCH5FxWVA4jKG8k8oPvoGJIdVbv7kDMgVJN8xDPqDM6MHaGTjhx3PpnbL5hpo3Y/4rqEzd/WRsqjnT/Yj2fqBzCGjzdhc6+c/VCcL2JFADBMva+zI47ybtDt9naSIxmrVB7XKf1NSHjT69N9lDjofOg/0V4RezYWE4nsb/vJQ2Z14USS+L9ImFspVT6v0sVYSFxVLHcAY2ExkRpAnXIOtuSgkXMrR7SOfwkeUKkLJ0DwAGbA1sE+ISwAUngZLNVDZz62nEKGNo11nleR/6eBI3WmTkDl43TVJJEx0HbxW/rhy/ci+bPDN7tJFaG+n9JzDvt3pAThCbtzZ5rCasFNkZJYsnJPvKryynyhetTyBavlO+FZgAIIBTwGQ4pLgLA= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PPF726CD7A1F.namprd22.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(4022899009)(10070799003)(366016)(1800799024)(376014)(38070700021)(13003099007)(18002099003)(22082099003)(56012099003)(8096899003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?nDNHRTHDKQ9e7Fqm//BUQPmnSpT6MEBTJmsdFZTRr2hfFQhYvtyksjbTKC?= =?iso-8859-1?Q?nQsQcwbbsibPf72ykOqqJjYUx/L6mHI2OYYXdZ6MTC9tyiJ9w7xXPCXVXa?= =?iso-8859-1?Q?c2IKTlOXPbQRw/6pJRJ7R0EaJsFI9zuOkCyKdn5Ukj5/D5eVzRXdNDONGG?= =?iso-8859-1?Q?a2JDR820Y/JgTgonMpioye4fl4xZK3Sidh9L13msTzu5Q3TiRKx74Jo4BW?= =?iso-8859-1?Q?zFEk/NY7ZzXTdIY4jObCf0tzLjOaM7hE/0Wsf+71qUj03BWWq3BQy/LJ+9?= =?iso-8859-1?Q?VOYqYpHqxLL912jV1JGse6OJX7jGgOQtIX7Xxw/9wt36mymTp/1gCQHzlw?= =?iso-8859-1?Q?sBlmw9GoUeL/QqpL0vapiVK/af9lqIHQB064eb05ctHwTicZrMKCu19feL?= =?iso-8859-1?Q?HvXQfgsjJpyCxLCWTMpL8P3PV0xU6rNomGX3ARx4TxfWzuMJK5HweG9qGv?= =?iso-8859-1?Q?r+uGZKKHvCnaC3EL8t3B+aaePXbBqGxoR0AakuEiCUrvBKT14iiGviyFYn?= =?iso-8859-1?Q?gOiN7nmJkpQNRl0/hrA5WEvE3e3N/5dzwCzCsjIZ5judY97yV6oLNCN9vY?= =?iso-8859-1?Q?YSlE82UPTUrIo5AwbHvDOApLGpgBRf8Qaa1ttiY16LZIgMC4koXAx8Jm42?= =?iso-8859-1?Q?f257dSJcYE9z2veihNFTvB7A0Lz7Bi0KBNAHWqPIM3fxOk+OZUVTkS9K3r?= =?iso-8859-1?Q?uUiiRjkn/tlfIqvuui+bxFHiMhp4toomzhMcxhJpDu8WjIU9UFEIOqsdLl?= =?iso-8859-1?Q?mMLzajJ9wHicQv3IwiYbMzzHWwzP0elj2edJu/mn7Getivah3A1tZbBNhE?= =?iso-8859-1?Q?CgaJBrVYlWOHdnKeYLHMnx11oBAzH7f3rEYLdqsM8zf3eLag2GKMv3Xdmz?= =?iso-8859-1?Q?K/y/lNvwI9fVSwX5A1tRpxB9a5tqfp1IH51bZjEN/gF3blCvlL/sqYKXId?= =?iso-8859-1?Q?sDLAtt+zFJaWN2upuMsRh0zj9Pu/OeMWhVuXbiFFgk78TJg1FXhrCl8bKx?= =?iso-8859-1?Q?JXaRj47PxnrXCtLQPAGguW1lkvppr1oBsERG3AyW2RsQet+xL44Gd6Pxtv?= =?iso-8859-1?Q?eIX+eRZQW6e7TgJ/Ou35HZL1wl0l4qZneUnM7XAOccV4uPp/I0ZeNP9i+a?= =?iso-8859-1?Q?5a76kctfE51VJfiYMCPeYTjj1a4hs/XmlPh80x7YBvl0Q5JzVN7sBftsT0?= =?iso-8859-1?Q?iFTLuEHD/sddusUkUdslowsy4LFD8EGlrQLyY+PRoD7i112fx1xo3S8o3C?= =?iso-8859-1?Q?ppfeSaqLyjQf9fp4Hn1HQJ7wbMNyCo2Izxzdr9n2CebTXmxZWmh9dYxIy9?= =?iso-8859-1?Q?8wMQkO0ZI9fJKTH3vrrEwd9Z+7p4R4LZxZGOEtWpRwbak119s81w8/1JkK?= =?iso-8859-1?Q?Qryj/WEZeJ4MDA+cEYwzvjnubVG+sr1NV205ZbVzhwdKD6oE1gFipFGjYq?= =?iso-8859-1?Q?sKbzMCaDHFdenSvekgm1WNfuB8df+U//ShF/vRdw51zb4yRIfPZmq7LLUr?= =?iso-8859-1?Q?Ubiu6cf1QWuSTN/CSJ+0OWV1YzVOWTq97D7k73hTa+GO9GsHnmeSib/oE6?= =?iso-8859-1?Q?oqnqcwSIDDpfyusmLFM76tn+tn2DHWdw/toQet4LlaZA7KB2T88IWkn265?= =?iso-8859-1?Q?IlG5mO+jbnVrvQ/pYyAkEMVNCQnu2dTKPPjqnMMZiPP0PsPfOUgWw/WFLm?= =?iso-8859-1?Q?KL4vreL9hytW5dB92bAG6QiyxrjyEhgY74K310HtztuzXVoixYd2lU58ZS?= =?iso-8859-1?Q?pwJUblXrvfr/0cp3HPmAZeHd+bt+q48Ek1NavRGz0ouqQsg5saotn0bmyL?= =?iso-8859-1?Q?qXW68heXFehU8GE6579fbwp6wAaA8U798ASlXRMRx2nM1SEHgwkL?= Content-Type: multipart/alternative; boundary="_000_IA0PPF726CD7A1F6F069AB802925BBA6242DA582IA0PPF726CD7A1F_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: IA0PPF726CD7A1F.namprd22.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42dde505-f461-4c12-5ea6-08de96524ad7 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2026 16:08:51.9720 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: G0hX+AOo8JufU5nzkCabHC+iVOrK+YpXEIUIgrk81JMwUANLeQAgQdIB3W1ph3yOYX4boqoV9mKdlxbs6xk9Wg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR22MB5103 Message-ID-Hash: V7FO5WM6OS53LD36V4YNINMMICFGW5EV X-Message-ID-Hash: V7FO5WM6OS53LD36V4YNINMMICFGW5EV X-MailFrom: mbishop@evequefou.be X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spasm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The IESG , "draft-ietf-lamps-pq-composite-sigs@ietf.org" , "housley@vigilsec.com" , "lamps-chairs@ietf.org" , "spasm@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Blamps=5D_Re=3A_Mike_Bishop=27s_No_Objection_on_draft-ietf-lamps?= =?utf-8?q?-pq-composite-sigs-15=3A_=28with_COMMENT=29?= List-Id: This is the mail list for the LAMPS Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_IA0PPF726CD7A1F6F069AB802925BBA6242DA582IA0PPF726CD7A1F_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm thinking of something like https://www.ietf.org/archive/id/draft-ietf-c= ore-oscore-groupcomm-28.html#section-14.8, which says "We take this securit= y precaution, because if we didn't, the following attack would work: ... Th= e attack above is prevented because (thing) leads to detection of the attac= k." You're wanting to hint at a fallback position, so maybe also "Doing (al= ternative) would reduce the odds of the attack succeeding, but not eliminat= e it." That is, document the reason the requirement is there, discuss the fallback= , and why it's helpful but not sufficient. If someone's operational constra= ints dictate disabling core security features of the protocol, you've expla= ined why that's a bad idea and also discussed how to mitigate the fallout. Another approach might be to phrase it as uncertainty. It MUST be freshly g= enerated, but if there's concern about potential collisions due to limited = sources of randomness, this additional step can mitigate the fallout of a c= ollision; if a "collision" is made more likely by someone's operational set= up, you've at least helped. ________________________________ From: Mike Ounsworth Sent: Wednesday, April 8, 2026 8:41 PM To: Mike Bishop Cc: The IESG ; draft-ietf-lamps-pq-composite-sigs@ietf.org <= draft-ietf-lamps-pq-composite-sigs@ietf.org>; housley@vigilsec.com ; lamps-chairs@ietf.org ; spasm@ietf.o= rg Subject: Re: [lamps] Mike Bishop's No Objection on draft-ietf-lamps-pq-comp= osite-sigs-15: (with COMMENT) Hi @Mike Bishop Thanks for the careful review. I have made these changes here: https://github.com/lamps-wg/draft-composite-sigs/commit/c2d3ca12014874ab5ad= bc3a4750ed59e36c54011 I think this COMMENT of yours is really astute and probably actually should= be a DISCUSS. So let's discuss ;) In Section 9.3: > designers are aware that some implementers may be forced to break > this rule due to operational constraints. This section documents the > implications of doing so. This statement makes me nervous. Maybe this section should explain why the = MUST exists, and not touch any implied "permission" to violate it? That section basically says "We are aware that people are going to have to = violate the core security requirement of the draft, so let's analyse exactl= y what happens when you do". Trust me, it also makes me nervous. Very nervous. I have a customer in this situation, and trust me, I have tried my hardest = to talk them out of it. The thinking here is that if we can't stop it, then at least we can documen= t what sharp pointy edges you need to watch out for. Thoughts? On Wed, 1 Apr 2026 at 09:50, Mike Bishop via Datatracker > wrote: Mike Bishop has entered the following ballot position for draft-ietf-lamps-pq-composite-sigs-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-= ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this work. This is an important step forward in our handling = of PQ crypto. Section 3.1.1: There are a lot of MAY-examples in this section, when the wh= ole thing is an overarching "MAY do whatever internally so long as the external= is consistent." Consider not using MAY for every single example. ---- Section 4 has: > example, a stand-alone RSA private key can be encoded in Chinese > Remainder Theorem form. In order to obtain interoperability, Consider an informative reference? ---- Section 6 has: > Labels are represented here as ASCII strings, but implementers MUST > convert them to byte strings using the obvious ASCII conversions While they may be obvious, calling them so comes across a bit oddly. Maybe = just say something like "Labels are represented here as ASCII strips, but are oc= tet sequences when used in..." ---- Consider moving Section 6.2 to an appendix; it's not part of the core proto= col, just design background. ---- In Section 9.1: > algorithm security or to provide migration flexibility. Let's > quickly explore both. It's typically advised to avoid first- or second-person language in specifications. I'd just drop this final sentence, personally. ---- In Section 9.3: > designers are aware that some implementers may be forced to break > this rule due to operational constraints. This section documents the > implications of doing so. This statement makes me nervous. Maybe this section should explain why the = MUST exists, and not touch any implied "permission" to violate it? ---- In Section 9.4: > message which happens to start with this string. The designers > accepted this trade-off. I would remove this last sentence. You've explained the trade-off; it's up = to the implementers to decide whether it's worth making, no? ---- Consider moving Section 10 to an appendix. _______________________________________________ Spasm mailing list -- spasm@ietf.org To unsubscribe send an email to spasm-leave@ietf.org --_000_IA0PPF726CD7A1F6F069AB802925BBA6242DA582IA0PPF726CD7A1F_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm thinking of something like https://www.ietf.org/archive/id/draft-ietf-core-oscore-groupcomm-28.html#se= ction-14.8, which says "We take this security precaution, because = if we didn't, the following attack would work: ... The attack above is prev= ented because (thing) leads to detection of the attack." You're wanting to hint at a fallback position, so may= be also "Doing (alternative) would reduce the odds of the attack succe= eding, but not eliminate it."

That is, document the reason the requirement is there, discuss the fallback= , and why it's helpful but not sufficient. If someone's operational constra= ints dictate disabling core security features of the protocol, you've expla= ined why that's a bad idea and also discussed how to mitigate the fallout.

Another approach might be to phrase it as uncertainty. It MUST be freshly g= enerated, but if there's concern about potential collisions due to limited = sources of randomness, this additional step can mitigate the fallout of a c= ollision; if a "collision" is made more likely by someone's operational setup, you've at least helped.

From: Mike Ounsworth <ounsworth+ietf@gmail.com>
Sent: Wednesday, April 8, 2026 8:41 PM
To: Mike Bishop <mbishop@evequefou.be>
Cc: The IESG <iesg@ietf.org>; draft-ietf-lamps-pq-composi= te-sigs@ietf.org <draft-ietf-lamps-pq-composite-sigs@ietf.org>; housl= ey@vigilsec.com <housley@vigilsec.com>; lamps-chairs@ietf.org <lam= ps-chairs@ietf.org>; spasm@ietf.org <spasm@ietf.org>
Subject: Re: [lamps] Mike Bishop's No Objection on draft-ietf-l= amps-pq-composite-sigs-15: (with COMMENT)
 
Hi @Mike Bishop

Thanks for the careful review.

I have made these changes here:


I think this COMMENT of yours is really astu= te and probably actually should be a DISCUSS. So let's discuss ;)

In Section 9.3:=0A=
=0A=
>   designers are aware that some implementers may be forced to bre=
ak=0A=
>   this rule due to operational constraints.  This section do=
cuments the=0A=
>   implications of doing so.=0A=
=0A=
This statement makes me nervous. Maybe this section should explain why the =
MUST=0A=
exists, and not touch any implied "permission" to violate it?

That section basically says "We are awa= re that people are going to have to violate the core security requirement o= f the draft, so let's analyse exactly what happens when you do".
Trust me, it also makes me nervous. Very ner= vous.
I have a customer in this situation, and tru= st me, I have tried my hardest to talk them out of it.
The thinking here is that if we can't stop i= t, then at least we can document what sharp pointy edges you need to watch = out for.
Thoughts?

On Wed, 1 Apr 2026 at 09:50, Mike Bishop via= Datatracker <noreply@ietf.org> wro= te:
Mike Bishop has entered the following ballot position for
draft-ietf-lamps-pq-composite-sigs-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions= /
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lam= ps-pq-composite-sigs/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this work. This is an important step forward in our handling = of
PQ crypto.

Section 3.1.1: There are a lot of MAY-examples in this section, when the wh= ole
thing is an overarching "MAY do whatever internally so long as the ext= ernal is
consistent." Consider not using MAY for every single example.

----

Section 4 has:

>   example, a stand-alone RSA private key can be encoded in C= hinese
>   Remainder Theorem form.  In order to obtain interoper= ability,

Consider an informative reference?

----

Section 6 has:

>   Labels are represented here as ASCII strings, but implemen= ters MUST
>   convert them to byte strings using the obvious ASCII conve= rsions

While they may be obvious, calling them so comes across a bit oddly. Maybe = just
say something like "Labels are represented here as ASCII strips, but a= re octet
sequences when used in..."

----

Consider moving Section 6.2 to an appendix; it's not part of the core proto= col,
just design background.

----

In Section 9.1:

>   algorithm security or to provide migration flexibility.&nb= sp; Let's
>   quickly explore both.

It's typically advised to avoid first- or second-person language in
specifications. I'd just drop this final sentence, personally.

----

In Section 9.3:

>   designers are aware that some implementers may be forced t= o break
>   this rule due to operational constraints.  This secti= on documents the
>   implications of doing so.

This statement makes me nervous. Maybe this section should explain why the = MUST
exists, and not touch any implied "permission" to violate it?

----

In Section 9.4:

>   message which happens to start with this string.  The= designers
>   accepted this trade-off.

I would remove this last sentence. You've explained the trade-off; it's up = to
the implementers to decide whether it's worth making, no?

----

Consider moving Section 10 to an appendix.



_______________________________________________
Spasm mailing list -- spasm@ietf.org
To unsubscribe send an email to spasm-leave@ietf.org
--_000_IA0PPF726CD7A1F6F069AB802925BBA6242DA582IA0PPF726CD7A1F_--