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 0AF33D97E2A1; Fri, 10 Apr 2026 07:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775830223; bh=TOYWD8FggpU5KclyW4gHlvi4cJZ52UbmWOgNJlANyjc=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=KUFOFzJcNaJHG7BAN7hEXlYPl6f3Zq3l+tunlNvr+ZyV7bwdx8L2DiZ4hUXtHMb98 IEGb+IlA6fvS6prs05ZplUuoRPzpMAot/eH28Y+RLI+Q/9lJFWiWEyO+sNVDSaVz7F It7CswU3HK/1NqEqGHkzSlCgUhLhHLAjF5yBJRL4= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.793 X-Spam-Level: X-Spam-Status: No, score=-2.793 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_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com 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 2m7a5-d6EFFg; Fri, 10 Apr 2026 07:10:21 -0700 (PDT) Received: from smtp-out.orange.com (smtp-out.orange.com [80.12.126.237]) (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 26608D97E195; Fri, 10 Apr 2026 07:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; i=@orange.com; q=dns/txt; s=orange002; t=1775830218; x=1807366218; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=K4lJB1w15+ek/nwkKcy7oy8yzh+8Rl9eFRpG8kKuwqg=; b=HT+RJzYTwcevcMyJZLyP7DZ9nPIAwSg+qY7h7T6fJrG/k+ZEAff4a0mY SGI2uymVXkxsRjTL9GV66xzYRywm4Z57ec0iCfrYMI8EI+urt7tFG3Q94 y5fOLO3afL/3DNq/NrXKu6T9a2m7QIoSdhfVx4ysU8p5qCzkgiaowXbep JeuLtcAFVZAa7heqs0BFvQvobHqNhX2X6ocnzz59QRtmGWNgwSf/uAa6K 3nBcn/DjQBRJ3Kc4O6bzLemwaCb+iA9c/gS0ahn1prUBamjgJW+OO/q8Q fwIaGYuhrv9eVwsvf8Zuhu/WZ8DJkkUt3jt7II6mmvfjwcg7imH9Qyz3D Q==; X-CSE-ConnectionGUID: IAac64e1RD6KsD8ARJ2Fhg== X-CSE-MsgGUID: zCNs6TyqRqW/iLzcVQG7hA== Received: from unknown (HELO opfedv3rlp0a.nor.fr.ftgroup) ([x.x.x.x]) by smtp-out.orange.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 10 Apr 2026 16:10:17 +0200 Received: from unknown (HELO opzinddimail18.si.fr.intraorange) ([x.x.x.x]) by opfedv3rlp0a.nor.fr.ftgroup with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 10 Apr 2026 16:10:17 +0200 Received: from opzinddimail18.si.fr.intraorange (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id 2281612EA42D; Fri, 10 Apr 2026 16:10:06 +0200 (CEST) Received: from opzinddimail18.si.fr.intraorange (unknown [127.0.0.1]) by DDEI (Postfix) with ESMTP id 122EF12EA400; Fri, 10 Apr 2026 16:10:06 +0200 (CEST) Received: from smtp-out365.orange.com (unknown [x.x.x.x]) by opzinddimail18.si.fr.intraorange (Postfix) with ESMTPS; Fri, 10 Apr 2026 16:10:06 +0200 (CEST) Received: from mail-francecentralazlp17011030.outbound.protection.outlook.com (HELO PAUP264CU001.outbound.protection.outlook.com) ([40.93.76.30]) by smtp-out365.orange.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 10 Apr 2026 16:10:05 +0200 Received: from PATP264MB6765.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:533::11) by PR0P264MB1674.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:16d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.46; Fri, 10 Apr 2026 14:10:02 +0000 Received: from PATP264MB6765.FRAP264.PROD.OUTLOOK.COM ([fe80::fcc8:341e:f80e:de16]) by PATP264MB6765.FRAP264.PROD.OUTLOOK.COM ([fe80::fcc8:341e:f80e:de16%4]) with mapi id 15.20.9769.043; Fri, 10 Apr 2026 14:10:02 +0000 From: mohamed.boucadair@orange.com X-CSE-ConnectionGUID: Rcjw+gcDTymaXOjKWeoIFg== X-CSE-MsgGUID: +x0vE6xyQLO0l/KZ6X+OcA== X-TM-AS-ERS: 10.106.160.156-127.5.254.253 X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ== X-DDEI-TLS-USAGE: Used X-CSE-ConnectionGUID: FIv0gxn0S6i/2xHj3Jt3UQ== X-CSE-MsgGUID: BgxWJrf9TYeVApoBzDyAiQ== IronPort-Data: A9a23:B8yIiqydJ/zj5uTuUWl6t+eixirEfRIJ4+MujC+fZmUNrF6WrkVUm zEZUD+PPKmMNmb3KN11bI/k9B8DsZ+AyoQ3GQE4qC00HyNBpPSeCIXCJC8cHc8zwu4v7q5Dx 59DAjUVBJlsFhcwnj/0bP656yM6jPjSLlbFILasEjhrQgN5QzsWhxtmmuoo6qZlmtHR7zml4 bsemOWBfgX8s9JIGjhMsfzb8Usz5K6aVA4w5TTSW9ga5TcyqFFFVPrzFYnpR1PkT49dGPKNR uqr5NmR4mPD8h4xPcium7D9f1diaua60d+m0yc+twCK23CulwRqukoJHKN0hXR/0l1lq+tMJ OBl7vRcf+uL0prkw4zxWzEAe8130DYvFLXveRBTuuTLp6HKnueFL/hGVCkL0YMkFulfL0BQr fMILmg2MBHE3fKWwumZVrJRv5F2RCXrFNt3VnBI9RjkNax4Hbv+G/2To9hFwD03m8ZCW+7EY NYUYiZuaxKGZABTPlAQC9Q1m+LAanvXL2Ue+QnT+vRxuDC7IA9ZiNABNPLQfdyDQMhZ2Eyfu 2nP8234GDkdLtWZxjfD+XWp7gPKtXqhBtpLS+fkp5aGhnW5yXwsKgcYBGeKrMeQkkmUSf5OA k0tr39GQa8arxfxEoaVsweDiHmZuAUDXMBME6475R2D4qXR6gedQGMDS1ZpadE9u+c3SCAkk FiTkLvBCSZmvqHQSH+B+PKQpDaqIm0NNCoJYiocShAE/9Smu4A8lTrOQ8ptVqmvgbXdGTbt2 DSHvQAghroSidUG3OOw+lWvqzalo4DSCwU17wTNRUqk4x93Iom/aOSA8kDS9vNoLYuFQB+Gp ndspiSFxOUHDJXImjaERu4AF7yv++yMNDTOhUY2QMF4rmz2ozikYJxa5yx4KAFxKMEYdDT1Y UjV/wRM+JtUO3jsZqhyC26sNyg05YbBC4zqRvaMVYRPJcJhVA3c3j01WHfFiggBj3MQfbcD1 YCzX/zEMJr3IaFuzT7zSf0U17QmzS042XnaQZnpywz+juLHPSbOEfECLUeEaf0/4OWcugLJ/ t1DNsyMjRJCTOn5ZSqR+okWRbzrEZTZLc+qwyC0XrfZSuaDJI3HI6KPqV/GU9E995m5bs+So hmAtrZwkTITf0Er1jlmmlg4M+mzAv6TXFo+PCc2Ok2v1WRraoG19M8iSnfDRpF+rLYL5actF 5EtIpzcatwREGiv02pGN/HV8tc9HClHcCrSZUJJlhBjJcY4H2QkO7bMImPSycX5JnDs65pi/ eL8h1qzrFhqb10KMfs6ocmHlzuZ1UXxUsorN6cUCrG/oHnRzbU= IronPort-HdrOrdr: A9a23:c/Ibwa3HYAImXT5PaVx7qAqjBWJxeYIsimQD101hICG9Lfbo9P xGzc566farslcssSkb6K+90cm7LU80hqQFn7X5XI3SEzUO11HYV72KgbGSpwEIXheOitK1tp 0QPZSWaueAd2SS5PySiGLXYrRQpeVvsprY+Ns2pE0dKz2CHpsQlzuRfTzra3GeKjM2YqYRJd 633OYCjTymfngcc8S8AVc4f8Wrnbf2vaOjSyQrQzo85iezrR7A0tPHOind8gYVUjtJz7tnym 7Yjgz/6JyktvGw2jXc22XQ45k+oqqh9jJEPqOxo/lQDg+pphejZYxnVbHHlisyuvuT5FEjl8 SJiws8PuxogkmhPV2dkF/I4U3NwTwu43jtxRuzmn34u/H0Qzo8Fo5omZ9ZSB3E8EAt1esMkp 6jnljp8qa/Pymw2xgV1OK4ES2CUXDE+EbKpNRjy0C3l7FuMIO547Zvp3+9W61wbR4SoLpXYN WGSvuspMp+QBe9c23TuHVpzZiHW3Q+GQrDf2050/bliQS/WBtCvhclLAt1pAZcyLstD5ZD/O jKKaJuifVHSdIXd7t0AKMbTdKwEXGle2OGDIu+GyWvKEg8AQOEl7fnpLEuoO26cp0By5U/3J zHTVNDrGY3P0bjE9eH0pFH+g3EBDzVZ0Wh9uhOo5xi/rHsTrviNiOODFgojsu7uv0aRsnWQe y6Np5aC+LqaTOGI/cE4yTuH51JbXUOWswcvdg2H1qIv8LQM4Xv8ujWauzaKrbhGSstHmn/Hn wAVj7uI9go1DHgZlboxBzKH3/9cE32+px9VKDc4ugI0YAIcpZBtwAE4G7JkP1j6QcyxZDeUH EOVI8PyJnL11We7CLN9SFzNhJWE0ZS56+IaQI4meYjCTKATYo+ X-Talos-CUID: =?us-ascii?q?9a23=3AiDJpfGnt9xknDGYxwdE2KUSpj2bXOVP80i/fM0n?= =?us-ascii?q?gMjhoD+eFaV3L2r8/rvM7zg=3D=3D?= X-Talos-MUID: =?us-ascii?q?9a23=3ALj4qJQ81nzmvkf+C6tvgrGmQf+1n85uMEk5craQ?= =?us-ascii?q?LheCcMgZiFya0jQ3iFw=3D=3D?= X-IronPort-AV: E=Sophos;i="6.21,202,1763420400"; d="scan'208,217";a="126017249" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=w2m+0NEzk6NBGtNumg0SL5cNu6pX6ebi0nHbCEpDp0ZwVYGUVURNtwvWkjCRVO6of76UX3xFlXt+e+ohK/7hiru0jejFxCvMrVVzks87+GpOybSjAlObOj7t3gIm1sPpt2AicDoUsqRsUgMAdjM0UfjLCd2UXpwN6Qb7yuYO6vaUYPggCWeZCSgRt21VPVBswY8BvXFQaWQudYezBLCjauzVVuBfXblYnlBoHdufTfo6WeTbPF7s0YHjz1IKFEOUaEqGZ3aYOQ1ylIW4gFDMVhOHEHFdtezVlloPNl9OjsKED7nNke4fJbrbo7ADyxYq/b2BRxLwMTX+Ab+gof/qTA== 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=7a9I8/Tr0ActZfS8vM8wEfDHK7P9QcRvK+HgKC0mlUE=; b=K7hnj2QMfmsT+m17nldxIwEyPxWBRkciz1bll8NZmybA+Z9Hoy1QZJkK1MbbHHQcKuRrR6iyjHx+UjbqHrW1ghyYj/anmi8EJvGwMhAKSA3Vd9qAdxBoHyW5OWDYC5hJddUXH3IsPE/r56amJOs+h/0k1+FobaVc58DRXcIcdsD11NCSzTOzajdcvDy12HFF/W6AKNzOqb3z/W2Dpnj475JtKJRVPXDTjV9vDgKMp45neRbMQENXOSmlHkXoDu2p88F/IPNkRBUAp3a2ur4Aa9UYQ0nLIMfTfr2ISjrda6ZqfCz/7a/F97U30ahJu9KDstI2usB/f4tbgLTbG5W2YQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=orange.com; dmarc=pass action=none header.from=orange.com; dkim=pass header.d=orange.com; arc=none To: Mike Ounsworth Thread-Topic: [lamps] Mohamed Boucadair's Discuss on draft-ietf-lamps-pq-composite-sigs-15: (with DISCUSS and COMMENT) Thread-Index: AQHcxy90xyELnXLNc0Srafojv2wOQbXYUuww Date: Fri, 10 Apr 2026 14:10:02 +0000 Message-ID: References: <177494805963.1623947.10168045227852376086@dt-datatracker-5775bcb475-pnkww> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=96159da8-7d96-4ac2-a9dc-b5d2d00baf5a;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2026-04-10T13:48:07Z;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20;MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Tag=10, 0, 1, 1;MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=0;MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true;MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=orange.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PATP264MB6765:EE_|PR0P264MB1674:EE_ x-ms-office365-filtering-correlation-id: 92323146-54c9-4a9a-b953-08de970adbd4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|4022899009|376014|13003099007|38070700021|8096899003|22082099003|18002099003|56012099003; x-microsoft-antispam-message-info: EqJ2frhsl5dOzNoHhqHLYoT0Qel/JqkeU89gyuEQsiDomtF5NaICsdnR6fRLs/ZodPCwVHY6d9jMpODjHlT4J1eEZscV7KLC3jBUrvuKe5aKyN8z35gJSyBfLZaC/tXI8YG4gmivnIZ56grhpCJlHZ4jElUC/ByFx+lUih0dBgzYNPWypWu4ylqIIBhITTs8k6ECKFI0RKSFFXB9urO+QVNmNmwb+xeha6rIehINbMRQNMzMFnF+oXvbDfwnbzgqoKHml3sm1lhuB9wfJN0HYf4K3Kh/y4uY+hmx/wqDgSYELnkhzYBJ55wuW1X9108R2B8S3xF1UfJgQnPa5sDRBntYZv8ENvz367bM3hHrZZCDAgkhYqgI0L+e3Grkspb3GbOLQmfKFbyb0nyRfGwcNHmQFxLmlQyEVjWH2zpSHh54eRg6d7jd5TMPtt1XWli4Yxb0EI7ss/Rkch6Nkb9LbN+EttEJEC/Ktg9qJFCX39Ofl26iGXpRl+LkxHrHB79JwD3DP19Ol4ye8c7W1jslL2YgWYEs6HYdmJHAbXbdz7EBVKCPxKMwGE7eNhTbGMZNAuOeku0bwRsPLUGtnrVxrchd3WKP0gBN9j82aGenocC+es3XOsF9NTYazEBKvHwlOxWAlDYQrC8EefYoj0UK8cXQzf5c0MC4fs3j9VD/NslP8eMU1LCKuWPBAlLjUUDnezrtpIh/SiwybSk07oM4h9PDJpbol/5xPkFcAjGw7PWYToV63nmjfR8uM9/5kphwZ8oc1c0ya7LQpNf8JNpf2QimUxI/OS+STFN/5/dtNjTsganTCQUO3DZngfcM8rpt x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PATP264MB6765.FRAP264.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(4022899009)(376014)(13003099007)(38070700021)(8096899003)(22082099003)(18002099003)(56012099003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?OFoEbZFESi12G7vWCLuXhUtZttM8hjrheKg/pxVFuB1u64U3oGqjFvHEPq?= =?iso-8859-1?Q?L6nmJfVZiYRPFzSM4iQBoxwa0Aqr2gZO2Zm37Od1wWRuP3vAuBJTOvZX7t?= =?iso-8859-1?Q?k0Uhc4151Sb0ErAC+2BQ4Q66t1M3aHhsttjIsOzJVNhtVHDaI46VCNomTo?= =?iso-8859-1?Q?kKpuOIJMB6hvGH33sQ3Fpv8TAf85/Z3a4BEAXas6EMQoh8AEVWeSC2kZLp?= =?iso-8859-1?Q?jJAC/nPwx5le7hhSDNUWNAbW/svKEcac2Hut+bc0FFLYXeChNskNslZ4tl?= =?iso-8859-1?Q?JVAZYcYU+JTO/e41bsFhJypLuJNmGXa2F95p0B8k1QgHLCh/uQnav+6c0V?= =?iso-8859-1?Q?RxXvkBAuEOmJtIco+9D6WJQh1i+84V94iYCO+tiW/SdqALPflZXHcWgdLM?= =?iso-8859-1?Q?YdinJ2purpjidVNQ+ssg1jUpEpg4XBP4M8PpOQbnelQd06d3hsmKbgvVqb?= =?iso-8859-1?Q?DDOSjRbI+zISXdZdkCNiNqqZARypLSpW1Taedx1IkwJAnY0llAtpzsSNVq?= =?iso-8859-1?Q?0JRXrEMtCMEkncEl4jqtBaOsN0wTBUak72Telaaeh4QwlJXlwcVPqNdWtm?= =?iso-8859-1?Q?5JhUIAxMwrfhiqL+y8WafqzVkUfgUakyDv2zqDWvUYPg+8u7EsDDY3Bhe8?= =?iso-8859-1?Q?HSHnhlD3QZkP1VdOd6RKog1s15snsOxcOQeH7qeFUyQXGbGvNb1HMsWhkN?= =?iso-8859-1?Q?XzHuZIqicaUxik7i8jnyRmCbStoYtxTQyMdruz9A1fom0PkxDlC43LJ9SX?= =?iso-8859-1?Q?c9yAVOCJJ3NSHFaun2K7xvFP0hcgdlWllZShOitvxkK+JNNyK/WOIOqBW+?= =?iso-8859-1?Q?UfOt2om27kxDgrQ5x166WwK320Hxb73bl+oJaxTv8hxYP56jQt5DY0/Ty4?= =?iso-8859-1?Q?4Kj+T5+4FDnFJaN1t3RGH8RreXF7R9ovyj07GlgYfxLttMpCWoYrq6ZpMD?= =?iso-8859-1?Q?yWlBXwFUwVAKvOaCTbhHyzKjEP5Jg8v1hCsgMsTs2/Jlof6a4xhrEHaxhQ?= =?iso-8859-1?Q?97M9sXAg2lLrof5qxJq+qToP6eaLdC5RBtVt+vgRWhvlFB/BNzJX2pIMX8?= =?iso-8859-1?Q?7W6gZfO4BSzi8W85AQv7BLE+H+jQ8Z0VWnNo6tjIKhy70F/soOZyMWzFfP?= =?iso-8859-1?Q?FxFe89FwWRkYWNDS9phnLiNMEGuKKqjN/3DtUqEC+jN7J4Wr3C56FhUGRB?= =?iso-8859-1?Q?acUKGMYvPXDHM8xbLShl2v3gEYKN49o+b0HsxR0Xj1mcIkXJZ4XqqRGwr/?= =?iso-8859-1?Q?3/R6x0huXiLO28AbGyBWO6AEl6aHxHJRRsxUIrz3rhe7g/GkfEPsRjvAez?= =?iso-8859-1?Q?oii99e0YTPAlQx9hjFGE7RDkckbeOUMy1teKDr8KjpmVKa5pQiI89e65jX?= =?iso-8859-1?Q?PhYnt/giICZ45U9eqElNJhb+iPqy/JBVYlCGqoYz1gsfWUsTaSlV2soYfv?= =?iso-8859-1?Q?BuufEf9OHQJJkgQvt7gTFjNd5rzSu1H9j+xUHi34HXfh2Xrw/v5yGfLSYV?= =?iso-8859-1?Q?QsRlEBy95cu7Q+v+JXM+TVaSTtJLSo+cCLIvzMxhFZYBjCdHaE4Y6ib4KI?= =?iso-8859-1?Q?Fdw2E6xKTGlch+RAYvfuMP5lb39ZF2Qmj/BGdq3PDgqlSCvXzfEoGLLa33?= =?iso-8859-1?Q?bKixS4yrQEwMjVZgZ1zyGkiqg2PnxO0EXXFvVB5DTfoelibjQM1W0vqUng?= =?iso-8859-1?Q?Zqe2PxzMtA5N8CBy32plVE2UFO7x/azAfTWZFwrB1yxqT/5M1ej0t3+kAn?= =?iso-8859-1?Q?+dw3mFW3ey7KT1s9Jvk/mUcw71/HSiG1QypJaweH5hLu+uM5LUn36SYHFt?= =?iso-8859-1?Q?RpC9+AwmNPQElrt2IbD57uDf4Dk+0X0=3D?= Content-Type: multipart/alternative; boundary="_000_PATP264MB67653A2DEE31B9961371A87988592PATP264MB6765FRAP_" MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: s1o7+YCanUA5PaBqZL8pVZGUFVvZZcgm5rDtjwj9GvGzXRrHQPl/zFOYj7zmLg9b9M5zDXDG7fPrAwG/ndzd/wLwFc4jBXOfze1+mQkhUEyqXWF18bDw9QuM8XoIO9P3nkiBopdJNuAvfA8Zpw7F2p1n3HXo+A5NdykCVgNzthO0xSvZ0qKRUFi8kcpRNoUF7Dabn2vIxTwaTX/RMNcfReq/gJBCbUn5yhBGZI/Okmx6YMcR+RAKqBhc+TvDg+TVwCHVFQCt7lSFBP49Juk0ejtqtuIek6nBxlQ7t19MPz21ms3qddEGggnod/vwba5F4CaLEz2VlRHE3+0GiMnsFQ== X-OriginatorOrg: orange.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PATP264MB6765.FRAP264.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 92323146-54c9-4a9a-b953-08de970adbd4 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2026 14:10:02.6271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 90c7a20a-f34b-40bf-bc48-b9253b6f5d20 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: P4auIx64TmXAfdUZe1wMCMKlx+PeLQgBkR0BrYM2Wm8QwZJoaJvX+kzhANWrH1Ud7mms1T+aEkNcLtBzgynZiMe1eWcS7/lOsqLgILE74ss= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR0P264MB1674 X-TM-AS-ERS: 10.106.160.156-127.5.254.253 X-TM-AS-SMTP: 1.0 c210cC1vdXQzNjUub3JhbmdlLmNvbQ== bW9oYW1lZC5ib3VjYWRhaXJAb 3JhbmdlLmNvbQ== X-TMASE-Version: DDEI-5.1-9.1.1004-29870.005 X-TMASE-Result: 10--38.687200-10.000000 X-TMASE-MatchedRID: 7u3eoxEoplDyCZGzF+DOCQxvavcYV2dInVTWWiNp+v86En2bnefhoBFB DiQWqOMkcLedUKcF/pzfvVRO/Ffjm35NVjRoX9bqt+Ziu0VS1iamVb+ZZJPWPbDeJMB5o2kwQ+O N76Cnm7nvp3i0IFje5bfVElO3d2YLfEtOTuUcA9YMeUy96gk4BLU+IyHhkXf1yHdfpwipSH6qvc IF1TcLYJXwt1rkqwjU9gAAlDNjtTAdEsZytFo3U1o8LOaXS5gWRN+FMKVZBhELzi3CACU/fd3Kb uePqIWqtZDLKHqpwOSNS2rW4v17YFoOcWWTXxT7exXX42Ne5dQsI6WudaF8axTXFuWNsxr531GU /N5W5BDynQxWKo+F0fmNDPvp636/OQ1ksQL1Vcp3CKyECwwBwZGA/MAGSrEgodQJXaDex6d4YeS lHZYFoptXhf4dcLJZSUQWNWP9oCyTRxvg8CdUPdJOV3MYgiw+vybt3bgNxoJHyz3bB5kG53hOa4 C/aON57CRdYja3ayxa7CrKwaiscLk8FmdX224cOEU+YcB7kkHrCzoWXDcUYnOr3ohrffvTY8r/n dGdDsUUXKizhC4rw3W2uLHcTV4U/A2nuCByI8BPB4rXagQZ+5U7Bltw5qVL0bdjqKOoG3dAzPYU SDzxTGQbxCrT3UJ55uMU7oGSbz8mCJAFAAd83BSHrTqtvqVQ/e+uN180e5dTXS/xn+24q6+WgCc aviqGol+A+a939c6mSniFMnEVJZe0W6Fejgt1taYQGPAVxV7EOJqSsn5KmbQENVAJ0fZ31+OTFq KF59l/y/ItrbUDCaEanSfqxnFrWqEBIOyGYin5FEa8WLE2cp4CIKY/Hg3AaZGo0EeYG964wTpaF Kqo4TsrIxPW/QrJaeysbnrvw4qtIWznhjjBtf558CedkGIvqcoAhihTwviVoB2LjgE7Agheov5E 3o/6+U/JFX+kQuOrwTS5seP+m++nYTmk7seD X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 X-TMASE-INERTIA: 0-0;;;; X-TMASE-XGENCLOUD: NULL-NULL-7-0-1 Message-ID-Hash: QLB4UE5K45C5BGFHZAJTP7QSCA6DCFT5 X-Message-ID-Hash: QLB4UE5K45C5BGFHZAJTP7QSCA6DCFT5 X-MailFrom: mohamed.boucadair@orange.com 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_Mohamed_Boucadair=27s_Discuss_on_draft-ietf-lamp?= =?utf-8?q?s-pq-composite-sigs-15=3A_=28with_DISCUSS_and_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_PATP264MB67653A2DEE31B9961371A87988592PATP264MB6765FRAP_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Mike, Thank you for the follow-up. I also checked https://author-tools.ietf.org/i= ddiff?url1=3Ddraft-ietf-lamps-pq-composite-sigs-15&url2=3Ddraft-ietf-lamps-= pq-composite-sigs-18&difftype=3D--html The changes look good to me. Please see inline for some few points. I will clear my DISCUSS independent of whether you decide to make further c= hanges. Cheers, Med De : Mike Ounsworth Envoy=E9 : mercredi 8 avril 2026 10:12 =C0 : BOUCADAIR Mohamed INNOV/NET Cc : The IESG ; draft-ietf-lamps-pq-composite-sigs@ietf.org;= housley@vigilsec.com; lamps-chairs@ietf.org; spasm@ietf.org Objet : Re: [lamps] Mohamed Boucadair's Discuss on draft-ietf-lamps-pq-comp= osite-sigs-15: (with DISCUSS and COMMENT) Hi Med, Thank you for your very detailed review! You got well into the details of t= his complex draft! And thank you also for the very detailed editorial PR: https://github.com/l= amps-wg/draft-composite-sigs/pull/345 I have addressed many of your points in a PR here, which I will discuss wit= h my co-authors before merging. https://github.com/lamps-wg/draft-composite-sigs/pull/347 [Med] Thanks. The points tat I did not make any changes for are discussed below: > Section 2 says the following: > This specification assumes a seed-based keygen for ML-DSA. > > Maybe I'm misreading this, but is this saying that only the seed mode is > supported? If so, isn't that a deviating from 9881 where expandedKey is a= llowed? You are not misreading that. There was extensive debate in the WG on this p= oint and the WG was very clear not to download the {seed, expanded, both} m= ess into composites. It is not uncommon for one RFC to profile another one;= IE to take only a subset of the features from the other RFC. So I think it= 's "profiling 9881" not "deviating from 9881". Also note that since Composi= te-ML-DSA is a distinct algorithm from ML-DSA with distinct object identifi= ers and distinct key encodings anyway, it's only a spiritual difference at = best. [Med] Thank you for confirming that I was not hallucinating :-) Great to se= e this is an informed decision from the WG. So, all is set for me ... excep= t maybe that I would prefer if this is stated clearing in the document, but= I leave that to you to decide. > ## Unless there is a need to deviate from RFC9794, I would suggest to rel= y on > the terms/definitions in RFC9794 (and make that RFC as normative) and only > define here new terms not listed in RFC9794. First, RFC9794 is Informational, so a Normative ref will cause DOWNREF prob= lems. And a Normative ref to a terminology doc seems weird. [Med] It isn't weird as I expect 9794 to end in the downref at some point. = Please note that having a doc in downref is not a disaster, it is just an a= dmin thing. The idea here was to copy in the definitions that are really important to t= he core understanding of this draft rather than making readers document-hop= . I'll fix the one that does not match exactly. Good eyes! [Med] I think the issue is fixed in your PR with "Some relevant definitions= from {{RFC9794}} are copied here for easier reading" and aligning the defi= nition. Thanks. > # Given the side-channel implication, any reason why this isn't a MUST? > > CURRENT: > Note that in step 4 above, both component signature processes are > invoked, and no indication is given about which one failed. This > SHOULD be done in a timing-invariant way to prevent side-channel > attackers from learning which component algorithm failed. There are lots of cryptographic implementations in the world where a timing= side-channel like this does not lead to any practical security issue; for = example if you're using local TPM where you assume that an attacker does no= t have direct access. And more generally, full side-channel resistance is r= eally really difficult to attain, especially in a software library. Most of= the time, if the underlying component primitive aborts early, that itself = is already a timing difference that you will not be able to mask at the com= posite layer. So turning this SHOULD into a MUST would make like 98% of imp= lementations non-conformant. We actually debated in the WG going the other = way and just removing this note entirely since it's a bit of an un-obtainab= le requirement, but in the end it stayed in as a SHOULD in case it ends up = being helpful to someone. [Med] Thanks for sharing the background. > CURRENT: > *PROTOCOL BACKWARDS COMPATIBILITY*: A property whereby a new feature > can be added to a protocol without requiring any changes to the > protocol's specification and only minimal changes to its > implementations (such as adding new identifiers). > > Adding a new feature is a change per se! I'm gonna disagree with that. I am going to argue that adding an extension = to a point in a protocol that is designed to take future extensions is not = "changing the protocol". For example, the TLS 1.3 protocol is agnostic to the actual ciphers it uses= , so RFC8998 is able to add the Chinese national ciphers to TLS 1.3 in exac= tly this way -- without even needing to consult the TLS WG in fact! That's = protocol backwards compatibility working well! [Med] OK > ### Can we please update this definition to better reflect the intended > property? I have adjusted this slightly by adding this sentence. Is that better? "Typically this means that the new feature fits within a defined extension point of the protocol instead of requiring a structural change to the protocol." [Med] Thanks. > ### Do we need this term at the first place? This is only mentioned once = with > self-contained context. > CURRENT: > Note that while the overall construction of Composite ML-DSA is > similar to that of HashML-DSA, the ML-DSA component inside the > composite is "pure" ML-DSA; implementing this specification does not > require an implementation of HashML-DSA. > > Shouldn't this be more explicit that HashML-DSA is disallowed per the same > rationale as in rfc9881#section-8.3? So, RFC9881 is saying that while HashML-DSA has registered OIDs, and could = structurally fit within X.509, RFC9881 is saying that that would not be con= sidered valid X.509. Here I don't think we need to do that with composites because if you swappe= d out the ML-DSA within a composite for HashML-DSA, you would end up with a= different and incompatible algorithm that doesn't pass the test vectors. There's a near-infinite set of algorithm combinations that are not specifie= d in this document but someone could well do, like composites with Chinese = or Russian ciphers, or with other PQ algs. My personal opinion is that it would be weird for a document like this to h= ave an opinion on things that are not specified in this document. [Med] ACK > # Section 3.1 > > CURRENT: > Errors produced by the component KeyGen() routines MUST be forwarded > on to the calling application. > > I don't understand the use of "forwarded" in this context? Isn't the API = call > internal within a system? I'm trying to conjure the idea of exception chaining. Like the composite im= plementation should not swallow the error, but if the inner API throws an e= rror then the composite should throw the same error. Would the word "MUST be propagated" be better? Maybe I should use more word= s? How about this? NEW: If one of the component `KeyGen()` routines returns an error, then this e= rror MUST be propagated by the `Composite-ML-DSA.KeyGen()` routine. [Med] This is better, thanks. > # Section 3.1.1: Modified process and implications > > CURRENT: > In cases where it is desirable to have a deterministic KeyGen of one > or both component keys from a seed, this process MAY be modified to > expose an interface of Composite-ML-DSA.KeyGen(seed) such that > one component algorithm is generated from the seed and the other from > random, or the input seed is cryptographically expanded to produce > seeds for both components. Implementation details and security > analysis of such a modified key generation process is outside the > scope of this document. > > Shouldn't this need be highlighted in the SEC or OPS cons section so that > appropriate analysis in done before making use of a modified process? Yeah. You're making a valid point, but I'm not sure what we could say that'= s helpful. I mean, it's true for all RFCs that if you implement something d= ifferent than what's in the RFC, then the security analysis may or may not = apply. Do you have specific text in mind? [Med] Moving this to a separate sub-section on the ops consideration sectio= n would give it more visibility for those who will deploy. > ## Inherit ML-DSA Operational Considerations > > There are important considerations that are inherited by the composite de= sign. > Can we please add a note to increase awareness about considerations liste= d in > rfc9881#section-8? So, 8.1 and 8.2 don't apply because we're not inheriting the whole {seed, e= xpanded, both} mess. 8.3 also doesn't apply because a HashML-DSA composite would be something di= fferent and incompatible with the things specified here, so I don't think w= e need to say anything about it at all. So I actually don't think we are inheriting any of the operation considerat= ions from RFC 9881; I think we have successfully profiled down how ML-DSA i= s used to make all three of those problems go away. [Med] ACK. > ## Hidden Operational Consideration > > Section 1.3: > Composite ML-DSA is NOT RECOMMENDED for use in > applications where it is has not been shown that EUF-CMA is > acceptable. > > This reco is IMO hidden in the introduction part. Given the importance of= this > reco for those who will deploy, I suggest we have this more visible as pa= rt of > the OPS Considerations section. This is the subject of the entire Security Consideration 9.2. Do we really = need to duplicate it into an OPS Con? Also please be aware that the EUF-CMA vs SUF-CMA thing is a political hand-= grenade. It took us almost 2 months at the WG to agree on the EUF-CMA text = that's in there currently. I personally have never come across a practical = deployment where EUF-CMA is not acceptable (ie where SUF-CMA is required). = So I personally don't think it is important, and I am not capable of writin= g the OPS Con you're asking for because I literally don't know what kind of= deployment would need that. I'm really hesitant to re-open this can of wor= ms. [Med] No need to open then ;-) I'm fine with the explanation you provided. On Tue, 31 Mar 2026 at 04:08, Mohamed Boucadair via Datatracker > wrote: Mohamed Boucadair has entered the following ballot position for draft-ietf-lamps-pq-composite-sigs-15: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Mike, John, Massimiliano, Jan, and Scott, Thank you for the effort put into this specification. The document reads we= ll ... even for an OPS AD :-) I trust that the test vectors, in particular, were checked by WG participan= ts other than the authors. Please find below some comments below. I also flagged some nits and other m= inor edits that I will send in a PR for authors convenience. # ML-DSA is normative for composite ML-DSA CURRENT: Composite ML-DSA is a Post-Quantum / Traditional hybrid signature scheme which combines ML-DSA as specified in [FIPS.204] and [RFC9881] ... As this specification uses ML-DSA as a component of all composite algorithms, all security considerations from [RFC9881] apply. Please move RFC9881 from Informative to Normative. ## As I'm there, I'd like to check one related part: Section 2 says the following: This specification assumes a seed-based keygen for ML-DSA. Maybe I'm misreading this, but is this saying that only the seed mode is supported? If so, isn't that a deviating from 9881 where expandedKey is all= owed? # Terminology: I'm adding this as a DISCUSS point as I think this is import= ant to ensure consistency among specs in this area Section 2: This specification is consistent with the terminology defined in [RFC9794]. In addition, the following terminology is used throughout this specification: I interpret this as the terms that follow are not listed in RFC9794 but are= an addition. However, it is not clear to me the rationale followed here. For example, ## we do have this entry grabbed from RFC9794 with an explicit pointer to t= hat RFC: *COMPOSITE CRYPTOGRAPHIC ELEMENT*: [RFC9794] defines composites as: A cryptographic element that incorporates multiple component cryptographic elements of the same type in a multi-algorithm scheme. The citation does not match exactly the entry as defined in 9794: A cryptographic element that incorporates multiple component cryptographic elements of the same type for use in a multi- algorithm scheme, such that the resulting composite cryptographic element is exposed as a singular interface of the same type as the component cryptographic elements. ## ... and this one which is already defined in RFC9794 but repeated here *POST-QUANTUM TRADITIONAL (PQ/T) HYBRID SCHEME*: A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm. ## Unless there is a need to deviate from RFC9794, I would suggest to rely = on the terms/definitions in RFC9794 (and make that RFC as normative) and only define here new terms not listed in RFC9794. # Given the side-channel implication, any reason why this isn't a MUST? CURRENT: Note that in step 4 above, both component signature processes are invoked, and no indication is given about which one failed. This SHOULD be done in a timing-invariant way to prevent side-channel attackers from learning which component algorithm failed. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Abstract: regional requirement, not an absolute one OLD: These combinations are tailored to meet regulatory guidelines. NEW: These combinations are tailored to meet regulatory Guidelines in certain regions. # Backward compatibility ## Usual CURRENT: *APPLICATION BACKWARDS COMPATIBILITY*: The usual definition of backwards compatibility, meaning whether an upgraded and non-upgraded application can successfully establish communication. ### If this is usual definition, then do we need to have a dedicated entry = for it here? ### I suggest NEW: *APPLICATION BACKWARDS COMPATIBILITY*: A property indicating whether an upgraded and non-upgraded application can successfully establish communication. ## Section 10.2 has the following: The term "application backwards compatibility" is used here to mean that existing systems as they are deployed today can interoperate with the upgraded systems of the future. Why the definition is repeated here? is there any difference between the in= tent here and the relevant entry in Section 1.1? Unless there is subtlety there, I suggest to delete that text as it is redundant with the terminology section. ## I don't parse the following: CURRENT: *PROTOCOL BACKWARDS COMPATIBILITY*: A property whereby a new feature can be added to a protocol without requiring any changes to the protocol's specification and only minimal changes to its implementations (such as adding new identifiers). Adding a new feature is a change per se! ### Can we please update this definition to better reflect the intended property? ### Do we need this term at the first place? This is only mentioned once wi= th self-contained context. ## Internal inconsistency Section 1: Backwards compatibility in the sense of upgraded systems continuing to interoperate with legacy systems is not directly covered in this specification, but is the subject of Section 10.2. I'm having troubles to digest the intent of this sentence as it conveys conflicting messages (at least for me). ## If the intent is to say that backward compatibility is not ensured then maybe reword to, e.g.: NEW: Backwards compatibility in the sense of upgraded systems continuing to interoperate with legacy systems is not directly covered in this specification. Refer to Section 10.2 for more details. # Notations Can we please add "->" to the list of notations? # Section 2.1: Broken reference CURRENT: Given this design of Composite ML-DSA, it is possible to split the pre-hashing step out from the signature generation process -- see {#impl-cons-external-ph} for further discussion and sample algorithms. # Section 2.1: HashML-DSA CURRENT: Note that while the overall construction of Composite ML-DSA is similar to that of HashML-DSA, the ML-DSA component inside the composite is "pure" ML-DSA; implementing this specification does not require an implementation of HashML-DSA. Shouldn't this be more explicit that HashML-DSA is disallowed per the same rationale as in rfc9881#section-8.3? # Section 3.1 CURRENT: Errors produced by the component KeyGen() routines MUST be forwarded on to the calling application. I don't understand the use of "forwarded" in this context? Isn't the API ca= ll internal within a system? Maybe s/forwarded on/communicated? # Section 3.1.1: Modified process and implications CURRENT: In cases where it is desirable to have a deterministic KeyGen of one or both component keys from a seed, this process MAY be modified to expose an interface of Composite-ML-DSA.KeyGen(seed) such that one component algorithm is generated from the seed and the other from random, or the input seed is cryptographically expanded to produce seeds for both components. Implementation details and security analysis of such a modified key generation process is outside the scope of this document. Shouldn't this need be highlighted in the SEC or OPS cons section so that appropriate analysis in done before making use of a modified process? # Section 4: Table 1 Can we please add a pointer to Section 4 of FIPS.204 to indicate the source= of that table? # Section 6: Obvious CURRENT: Labels are represented here as ASCII strings, but implementers MUST convert them to byte strings using the obvious ASCII conversions prior to concatenating them with other byte values as described in Section 2.2. do we need to keep "obvious" here? If it was, then why calling it out :-) # Section 6: Key sizes CURRENT: For all RSA key types and sizes, the exponent is RECOMMENDED to be 65537. Implementations MAY support only 65537 and reject other exponent values. Legacy RSA implementations that use other values for the exponent MAY be used within a composite, but need to be careful when interoperating with other implementations. Given the interoperability issues there, I suggest to add relevant operatio= nal considerations under the OPS Cons section to cover at least the following: * Implems need to expose which sizes they support * Implems need to offer a configuration knob to control the size. # Section 10: Operational Considerations ## I suggest to rename "Implementation Considerations" to "Operational Considerations" as that section is more about operational guidance. This wo= uld be also consistent with the approach in 9881. ## Inherit ML-DSA Operational Considerations There are important considerations that are inherited by the composite desi= gn. Can we please add a note to increase awareness about considerations listed = in rfc9881#section-8? ## Hidden Operational Consideration Section 1.3: Composite ML-DSA is NOT RECOMMENDED for use in applications where it is has not been shown that EUF-CMA is acceptable. This reco is IMO hidden in the introduction part. Given the importance of t= his reco for those who will deploy, I suggest we have this more visible as part= of the OPS Considerations section. Hope this helps. Cheers, Med _______________________________________________ Spasm mailing list -- spasm@ietf.org To unsubscribe send an email to spasm-leave@ietf.org ___________________________________________________________________________= _________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_PATP264MB67653A2DEE31B9961371A87988592PATP264MB6765FRAP_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Mike,

 

Thank you for th= e follow-up. I also checked https://author-tools.ietf.org/iddiff?url1=3Ddraft-ietf-lamps-pq-composite-s= igs-15&url2=3Ddraft-ietf-lamps-pq-composite-sigs-18&difftype=3D--ht= ml

 

The changes look= good to me. Please see inline for some few points.

 

I will clear my = DISCUSS independent of whether you decide to make further changes.

 

Cheers,

Med

 

De : Mike Ounsworth <ounswor= th+ietf@gmail.com>
Envoy=E9 : mercredi 8 avril 2026 10:12
=C0 : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.= com>
Cc : The IESG <iesg@ietf.org>; draft-ietf-lamps-pq-compos= ite-sigs@ietf.org; housley@vigilsec.com; lamps-chairs@ietf.org; spasm@ietf.= org
Objet : Re: [lamps] Mohamed Boucadair's Discuss on draft-ietf-l= amps-pq-composite-sigs-15: (with DISCUSS and COMMENT)

 

 

Hi Med,

Thank you for your very detailed review! You got well into the detai= ls of this complex draft!

And thank you also for the very detailed editorial PR:= https://github.com/lamps-wg/draft-composite-sigs/pull/345

I have addressed many of your points in a PR here, which I will discuss wit= h my co-authors before merging.
https://github.com/lamps-wg/draft-composite-sigs/pull/347<= /p>

[Med] Thanks.



The points tat I did not make any changes for are discussed below:



> Section 2 says the following:
>   This specification assumes a seed-based keygen for ML-DSA.
>
> Maybe I’m misreading this, but is this saying that only the seed= mode is
> supported? If so, isn’t that a deviating from 9881 where expande= dKey is allowed?

You are not misreading that. There was extensive debate in the WG on this p= oint and the WG was very clear not to download the {seed, expanded, both} m= ess into composites. It is not uncommon for one RFC to profile another one;= IE to take only a subset of the features from the other RFC. So I think it's "profiling 9881" no= t "deviating from 9881". Also note that since Composite-ML-DSA is= a distinct algorithm from ML-DSA with distinct object identifiers and dist= inct key encodings anyway, it's only a spiritual difference at best.

 

[Med] Thank you for confirming that I= was not hallucinating :-) Great to see this is an informed decision from t= he WG. So, all is set for me … except maybe that I would prefer if this is stated clearing in the document, but I leave tha= t to you to decide.

> ## Unless there is a need to deviate from RFC9794, I would suggest to = rely on
> the terms/definitions in RFC9794 (and make that RFC as normative) and = only
> define here new terms not listed in RFC9794.

First, RFC9794 is Informational, so a Normative ref will cause DOWNR= EF problems. And a Normative ref to a terminology doc seems weird.

[Med] It isn’t weird as I expec= t 9794 to end in the downref at some point. Please note that having a doc i= n downref is not a disaster, it is just an admin thing.


The idea here was to copy in the definitions that are really important to t= he core understanding of this draft rather than making readers document-hop. I'll fix the one that does not match exactly. Good eyes!<= /p>

[Med] I think the issue is fixed in y= our PR with “Some relevant definitions from {{RFC9794}} are copied he= re for easier reading” and aligning the definition. Thanks.


> # Given the side-channel implication, any reason why this isn’t = a MUST?
>
> CURRENT:
>    Note that in step 4 above, both component signature proce= sses are
>    invoked, and no indication is given about which one faile= d.  This
>    SHOULD be done in a timing-invariant way to prevent side-= channel
>    attackers from learning which component algorithm failed.=

There are lots of cryptographic implementations in the world where a timing= side-channel like this does not lead to any practical security issue; for = example if you're using local TPM where you assume that an attacker does no= t have direct access. And more generally, full side-channel resistance is really really difficult to attain, especia= lly in a software library. Most of the time, if the underlying component pr= imitive aborts early, that itself is already a timing difference that you w= ill not be able to mask at the composite layer. So turning this SHOULD into a MUST would make like 98% of implement= ations non-conformant. We actually debated in the WG going the other way an= d just removing this note entirely since it's a bit of an un-obtainable req= uirement, but in the end it stayed in as a SHOULD in case it ends up being helpful to someone.

 

[Med] Thanks for sharing the backgrou= nd.


> CURRENT:
>    *PROTOCOL BACKWARDS COMPATIBILITY*: A property whereby a = new feature
>    can be added to a protocol without requiring any changes = to the
>    protocol's specification and only minimal changes to its<= br> >    implementations (such as adding new identifiers).
>
> Adding a new feature is a change per se!

I'm gonna disagree with that. I am going to argue that adding an extension = to a point in a protocol that is designed to take future extensions is not = "changing the protocol".
For example, the TLS 1.3 protocol is agnostic to the actual ciphers it uses= , so RFC8998 is able to add the Chinese national ciphers to TLS 1.3 in exac= tly this way -- without even needing to consult the TLS WG in fact! That's = protocol backwards compatibility working well!

 

[Med] OK


 
> ### Can we please update this definition to better reflect the intende= d
> property?

I have adjusted this slightly by adding this sentence. Is that bette= r?

"Typically this means that the new feature fits within a defined
extension point of the protocol instead of requiring a structural
change to the protocol."

 

[Med] Thanks.



> ### Do we need this term at the first place? This is only menti= oned once with
> self-contained context.



> CURRENT:
>    Note that while the overall construction of Composite ML-= DSA is
>    similar to that of HashML-DSA, the ML-DSA component insid= e the
>    composite is "pure" ML-DSA; implementing this s= pecification does not
>    require an implementation of HashML-DSA.
>
> Shouldn’t this be more explicit that HashML-DSA is disallowed pe= r the same
> rationale as in rfc9881#section-8.3?

So, RFC9881 is saying that while HashML-DSA has registered OIDs, and could = structurally fit within X.509, RFC9881 is saying that that would not be con= sidered valid X.509.

Here I don't think we need to do that with composites because if you swappe= d out the ML-DSA within a composite for HashML-DSA, you would end up with a= different and incompatible algorithm that doesn't pass the test vectors. There's a near-infinite set of algorithm combinations that are not specifie= d in this document but someone could well do, like composites with Chinese = or Russian ciphers, or with other PQ algs.
My personal opinion is that it would be weird for a document like this to h= ave an opinion on things that are not specified in this document.

 

[Med] ACK



> # Section 3.1
>
> CURRENT:
>    Errors produced by the component KeyGen() routines MUST b= e forwarded
>    on to the calling application.
>
> I don’t understand the use of “forwarded” in this co= ntext? Isn’t the API call
> internal within a system?

I'm trying to conjure the idea of exception chaining. Like the composite im= plementation should not swallow the error, but if the inner API throws an e= rror then the composite should throw the same error.

Would the word "MUST be propagated" be better? Maybe I should use= more words? How about this?

NEW:
  If one of the component `KeyGen()` routines returns an error, then t= his error MUST be propagated by the `Composite-ML-DSA.KeyGen()` routine.

[Med] This is better, thanks.



> # Section 3.1.1: Modified process and implications
>
> CURRENT:
>    In cases where it is desirable to have a deterministic Ke= yGen of one
>    or both component keys from a seed, this process MAY be m= odified to
>    expose an interface of Composite-ML-DSA<OID>.KeyGen= (seed) such that
>    one component algorithm is generated from the seed and th= e other from
>    random, or the input seed is cryptographically expanded t= o produce
>    seeds for both components.  Implementation de= tails and security
>    analysis of such a modified key generation process is out= side the
>    scope of this document.
>
> Shouldn’t this need be highlighted in the SEC or OPS cons sectio= n so that
> appropriate analysis in done before making use of a modified process?<= br>
Yeah. You're making a valid point, but I'm not sure what we could say that'= s helpful. I mean, it's true for all RFCs that if you implement something d= ifferent than what's in the RFC, then the security analysis may or may not = apply. Do you have specific text in mind?

 

[Med] Moving this to a separate sub-s= ection on the ops consideration section would give it more visibility for t= hose who will deploy.


> ## Inherit ML-DSA Operational Considerations
>
> There are important considerations that are inherited by the composite= design.
> Can we please add a note to increase awareness about considerat= ions listed in
> rfc9881#section-8?

So, 8.1 and 8.2 don't apply because we're not inheriting the whole {seed, e= xpanded, both} mess.
8.3 also doesn't apply because a HashML-DSA composite would be something di= fferent and incompatible with the things specified here, so I don't think w= e need to say anything about it at all.

So I actually don't think we are inheriting any of the operation considerat= ions from RFC 9881; I think we have successfully profiled down how ML-DSA i= s used to make all three of those problems go away.

 

[Med] ACK.

> ## Hidden Operational Consideration
>
> Section 1.3:
>    Composite ML-DSA is NOT RECOMMENDED for use in
>    applications where it is has not been shown that EUF-CMA = is
>    acceptable.
>
> This reco is IMO hidden in the introduction part. Given the importance= of this
> reco for those who will deploy, I suggest we have this more visible as= part of
> the OPS Considerations section.

This is the subject of the entire Security Consideration 9.2. Do we really = need to duplicate it into an OPS Con?

Also please be aware that the EUF-CMA vs SUF-CMA thing is a political hand-= grenade. It took us almost 2 months at the WG to agree on the EUF-CMA text = that's in there currently. I personally have never come across a practical = deployment where EUF-CMA is not acceptable (ie where SUF-CMA is required). So I personally don't think it = is important, and I am not capable of writing the OPS Con you're asking for= because I literally don't know what kind of deployment would need that. I'= m really hesitant to re-open this can of worms.

 

[Med] No need to open then ;-) I̵= 7;m fine with the explanation you provided.

 

On Tue, 31 Mar 2026 at 04:08, Mohamed Boucadair via = Datatracker <noreply@ietf.org>= ; wrote:

Mohamed Boucadair has entered the following ballot p= osition for
draft-ietf-lamps-pq-composite-sigs-15: Discuss

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-p= q-composite-sigs/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Mike, John, Massimiliano, Jan, and Scott,

Thank you for the effort put into this specification. The document reads we= ll
... even for an OPS AD :-)

I trust that the test vectors, in particular, were checked by WG participan= ts
other than the authors.

Please find below some comments below. I also flagged some nits and other m= inor
edits that I will send in a PR for authors convenience.

# ML-DSA is normative for composite ML-DSA

CURRENT:
   Composite ML-DSA is a Post-Quantum / Traditional hybrid signat= ure
   scheme which combines ML-DSA as specified in [FIPS.204] and [R= FC9881]

   …

   As this specification uses ML-DSA as a component of all compos= ite
   algorithms, all security considerations from [RFC9881] apply.<= br>
Please move RFC9881 from Informative to Normative.

## As I’m there, I’d like to check one related part:

Section 2 says the following:
  This specification assumes a seed-based keygen for ML-DSA.

Maybe I’m misreading this, but is this saying that only the seed mode= is
supported? If so, isn’t that a deviating from 9881 where expandedKey = is allowed?

# Terminology: I'm adding this as a DISCUSS point as I think this is import= ant
to ensure consistency among specs in this area

Section 2:
   This specification is consistent with the terminology defined = in
   [RFC9794].  In addition, the following terminology is use= d throughout
   this specification:

I interpret this as the terms that follow are not listed in RFC9794 but are= an
addition. However, it is not clear to me the rationale followed here. For example,

## we do have this entry grabbed from RFC9794 with an explicit pointer to t= hat
RFC:

   *COMPOSITE CRYPTOGRAPHIC ELEMENT*: [RFC9794] defines composite= s as: A
   cryptographic element that incorporates multiple component
   cryptographic elements of the same type in a multi-algorithm s= cheme.

The citation does not match exactly the entry as defined in 9794:

      A cryptographic element that incorporates multiple com= ponent
      cryptographic elements of the same type for use in a m= ulti-
      algorithm scheme, such that the resulting composite cr= yptographic
      element is exposed as a singular interface of the same= type as the
      component cryptographic elements.

## … and this one which is already defined in RFC9794 but repeated he= re

   *POST-QUANTUM TRADITIONAL (PQ/T) HYBRID SCHEME*: A multi-algor= ithm
   scheme where at least one component algorithm is a post-quantu= m
   algorithm and at least one is a traditional algorithm.

## Unless there is a need to deviate from RFC9794, I would suggest to rely = on
the terms/definitions in RFC9794 (and make that RFC as normative) and only<= br> define here new terms not listed in RFC9794.

# Given the side-channel implication, any reason why this isn’t a MUS= T?

CURRENT:
   Note that in step 4 above, both component signature processes = are
   invoked, and no indication is given about which one failed.&nb= sp; This
   SHOULD be done in a timing-invariant way to prevent side-chann= el
   attackers from learning which component algorithm failed.


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

# Abstract: regional requirement, not an absolute one

OLD:
   These combinations are tailored to meet regulatory
   guidelines.

NEW:
   These combinations are tailored to meet regulatory
   Guidelines in certain regions.

# Backward compatibility

## Usual

CURRENT:
   *APPLICATION BACKWARDS COMPATIBILITY*: The usual definition of=
   backwards compatibility, meaning whether an upgraded and non-u= pgraded
   application can successfully establish communication.

### If this is usual definition, then do we need to have a dedicated entry = for
it here?

### I suggest

NEW:
   *APPLICATION BACKWARDS COMPATIBILITY*: A property indicating w= hether an
   upgraded and non-upgraded application can successfully establi= sh
   communication.

## Section 10.2 has the following:

   The term "application backwards compatibility" is us= ed here to mean
   that existing systems as they are deployed today can interoper= ate
   with the upgraded systems of the future.

Why the definition is repeated here? is there any difference between the in= tent
here and the relevant entry in Section 1.1?

Unless there is subtlety there, I suggest to delete that text as it is
redundant with the terminology section.

## I don’t parse the following:

CURRENT:
   *PROTOCOL BACKWARDS COMPATIBILITY*: A property whereby a new f= eature
   can be added to a protocol without requiring any changes to th= e
   protocol's specification and only minimal changes to its
   implementations (such as adding new identifiers).

Adding a new feature is a change per se!

### Can we please update this definition to better reflect the intended
property?

### Do we need this term at the first place? This is only mentioned once wi= th
self-contained context.

## Internal inconsistency

Section 1:
   Backwards compatibility in the sense of upgraded systems conti= nuing
   to interoperate with legacy systems is not directly covered in= this
   specification, but is the subject of Section 10.2.

I’m having troubles to digest the intent of this sentence as it conve= ys
conflicting messages (at least for me).

## If the intent is to say that backward compatibility is not ensured then<= br> maybe reword to, e.g.:

NEW:
   Backwards compatibility in the sense of upgraded systems conti= nuing
   to interoperate with legacy systems is not directly covered in= this
   specification. Refer to Section 10.2 for more details.

# Notations

Can we please add "->" to the list of notations?

# Section 2.1: Broken reference

CURRENT:
   Given this design of Composite ML-DSA, it is possible to split= the
   pre-hashing step out from the signature generation process -- = see
   {#impl-cons-external-ph} for further discussion and sample
   algorithms.

# Section 2.1: HashML-DSA

CURRENT:
   Note that while the overall construction of Composite ML-DSA i= s
   similar to that of HashML-DSA, the ML-DSA component inside the=
   composite is "pure" ML-DSA; implementing this specif= ication does not
   require an implementation of HashML-DSA.

Shouldn’t this be more explicit that HashML-DSA is disallowed per the= same
rationale as in rfc9881#section-8.3?

# Section 3.1

CURRENT:
   Errors produced by the component KeyGen() routines MUST be for= warded
   on to the calling application.

I don’t understand the use of “forwarded” in this context= ? Isn’t the API call
internal within a system?

Maybe s/forwarded on/communicated?

# Section 3.1.1: Modified process and implications

CURRENT:
   In cases where it is desirable to have a deterministic KeyGen = of one
   or both component keys from a seed, this process MAY be modifi= ed to
   expose an interface of Composite-ML-DSA<OID>.KeyGen(seed= ) such that
   one component algorithm is generated from the seed and the oth= er from
   random, or the input seed is cryptographically expanded to pro= duce
   seeds for both components.  Implementation details and se= curity
   analysis of such a modified key generation process is outside = the
   scope of this document.

Shouldn’t this need be highlighted in the SEC or OPS cons section so = that
appropriate analysis in done before making use of a modified process?

# Section 4: Table 1

Can we please add a pointer to Section 4 of FIPS.204 to indicate the source= of
that table?

# Section 6: Obvious

CURRENT:
   Labels are represented here as ASCII strings, but implementers= MUST
   convert them to byte strings using the obvious ASCII conversio= ns
   prior to concatenating them with other byte values as describe= d in
   Section 2.2.

do we need to keep “obvious” here? If it was, then why calling = it out :-)

# Section 6: Key sizes

CURRENT:
   For all RSA key types and sizes, the exponent is RECOMMENDED t= o be
   65537.  Implementations MAY support only 65537 and reject= other
   exponent values.  Legacy RSA implementations that use oth= er values
   for the exponent MAY be used within a composite, but need to b= e
   careful when interoperating with other implementations.

Given the interoperability issues there, I suggest to add relevant operatio= nal
considerations under the OPS Cons section to cover at least the following:<= br>
* Implems need to expose which sizes they support
* Implems need to offer a configuration knob to control the size.

# Section 10: Operational Considerations

## I suggest to rename “Implementation Considerations” to ̶= 0;Operational
Considerations” as that section is more about operational guidance. T= his would
be also consistent with the approach in 9881.

## Inherit ML-DSA Operational Considerations

There are important considerations that are inherited by the composite desi= gn.
Can we please add a note to increase awareness about considerations listed = in
rfc9881#section-8?

## Hidden Operational Consideration

Section 1.3:
   Composite ML-DSA is NOT RECOMMENDED for use in
   applications where it is has not been shown that EUF-CMA is
   acceptable.

This reco is IMO hidden in the introduction part. Given the importance of t= his
reco for those who will deploy, I suggest we have this more visible as part= of
the OPS Considerations section.

Hope this helps.

Cheers,
Med



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

____________________________________________________________=
________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_PATP264MB67653A2DEE31B9961371A87988592PATP264MB6765FRAP_--