[lamps] Re: [EXTERNAL] Responding to ISSUE #5
Tim Hollebeek <tim.hollebeek@digicert.com> Wed, 14 August 2024 17:52 UTC
Return-Path: <tim.hollebeek@digicert.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB53AC151981 for <spasm@ietfa.amsl.com>; Wed, 14 Aug 2024 10:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.253
X-Spam-Level:
X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=digicert.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aQd1Wngfu_f for <spasm@ietfa.amsl.com>; Wed, 14 Aug 2024 10:52:27 -0700 (PDT)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2138.outbound.protection.outlook.com [40.107.220.138]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD602C1519A0 for <spasm@ietf.org>; Wed, 14 Aug 2024 10:52:27 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=y/3oO/cNx8vZyfZBGUcfjuOxlJHN0VvcojJBFIlyUfsCRGWmyJrseoWlXCkM5ARZt8iuvSOk/DGP/HkdqoFQB6n9j6YqnVDXTCKzN2Ub9Gpjk9fICgoAVhk1edIqsqixhg2Ou5FCfLVjSaG1hhh7h7kfIf5WS7UFjH5LJvtSQ+zhLQv6lNBfGDB8V8hT0Y2bcrKaRGI+qwCtiweU4/XrrFCuhwqR4mUA8AisnTt7ITWgs3SKl2irzOqFYyTf7djbtZBCJy2ycZ7taqv6OshyoA4ewoBqKHmbYoK6L2Mz1hd81y/vm8RY/lhvcBqgt05v22CLg+gix2ztm5bA+tDpXA==
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=oSALK/dROfsiq8xZ1FHV7cAXmWsxu4U/ikrbDuaZECk=; b=gJZthQss53rsYrYr/kXzft+NqZ2x7kzamteMpIXAdQyOKmrhUfc30QPbhd/HOLcfycGb3BDhJHkeEz4yjvwVB+VZyos5eE6TP3n+wpYq6pGVCanqaXt2ZOnk94tdCtqQhvPB9UB6xvNXMiB46eACtyM5gvkfjqsRAGs23pYhZLh9wlIL7l7oZ0ksV97mxuahzKDtZZqD3IAAPrImv7neeagSBVJj/14O4oPkNsTFneFoTWvJMJb35o4LHbXigr17kvKBIX5Q7lDlIAPnL1mPgXiIVvLMH9AF87yFAGAEs33JgURTnehVp35QijK5aOsOgz7U50S924S1+KXN5pLqcw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=digicert.com; dmarc=pass action=none header.from=digicert.com; dkim=pass header.d=digicert.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oSALK/dROfsiq8xZ1FHV7cAXmWsxu4U/ikrbDuaZECk=; b=L7Kdi1LOWPLbnHZH6D8wtF3W+wAll951guOBMv/Hk29JszILJj1AivzuWtb0c3czaGuIeWosudmVpcbtLOYzIcozRCG/D4LVHXnBkXjfstQ4EKk/b9jzOzEO+YKDBkxnWuNMc/Fa99zrliElYOeygDmDF0Z3iFoc8VXhELkUSAw0VyP1xTntooBCUZ7un6o8WeOsNjeTkYlpNrar70dlCPuN8Rsg/bHmOSe9U4f6G3BcD1MxlXqFsDttZ3cjXQdziA6EFKdvkRBQysdSrvfh1IZbcAZm4GSFc4LqHZBBTyeqRjLOVgsocQY09zs7cEREVod3ZUKTAxM3eLPhr6EjZQ==
Received: from SN7PR14MB6492.namprd14.prod.outlook.com (2603:10b6:806:328::17) by DM6PR14MB3837.namprd14.prod.outlook.com (2603:10b6:5:1ba::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7875.18; Wed, 14 Aug 2024 17:52:24 +0000
Received: from SN7PR14MB6492.namprd14.prod.outlook.com ([fe80::4659:3696:6ad:2630]) by SN7PR14MB6492.namprd14.prod.outlook.com ([fe80::4659:3696:6ad:2630%5]) with mapi id 15.20.7849.019; Wed, 14 Aug 2024 17:52:24 +0000
From: Tim Hollebeek <tim.hollebeek@digicert.com>
To: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>, Piotr Popis <piotr.popis=40enigma.com.pl@dmarc.ietf.org>, 'John Gray' <John.Gray=40entrust.com@dmarc.ietf.org>, "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: [lamps] Re: [EXTERNAL] Responding to ISSUE #5
Thread-Index: AQHa7lddDtNh/NscB0CU/Oo3mOhvMrInA3rQ
Date: Wed, 14 Aug 2024 17:52:24 +0000
Message-ID: <SN7PR14MB649202EDCEABDEDFDA54A34183872@SN7PR14MB6492.namprd14.prod.outlook.com>
References: <01a801dae4ba$c5dfcf00$519f6d00$@enigma.com.pl> <CH0PR11MB57394FCDB757B76712CCB2599F872@CH0PR11MB5739.namprd11.prod.outlook.com>
In-Reply-To: <CH0PR11MB57394FCDB757B76712CCB2599F872@CH0PR11MB5739.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=digicert.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SN7PR14MB6492:EE_|DM6PR14MB3837:EE_
x-ms-office365-filtering-correlation-id: 9bddecba-7e18-46f1-9b3f-08dcbc89da86
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|38070700018;
x-microsoft-antispam-message-info: Ca4vnYvS1U1dp1Wm2JeRWqpWmbKa5EOp6eU02vdZyJDlsvgkh3+GKnGnez/Mm5rU6ECczCGNXMpgnLAle69FoqXf0LFwmkDgYYGbmNO8XOzP4RQoK1iCrUzjtQ18NL9pL3/T1fqmqnlPzcLqCHch79rWpfcf+mq3lliWDoOiJzoHKyTlaNXdoJOYk9x0EAEffI7uT6vNaPda/NCZtqI6IvUWvEh/YK55OH2svsf3zPqyb0qtHjQ1g/5iKeCChEP3/Hiszxqb8jhEoupwUnEg9KTyUQUOh2UgOY6ULjEZQ1vxQMsRTiH5w1FuV3o58A1jao2rtEZc/PEGNURlMIMrrDt8oMZwBWMzeyexc2tSWXgdDLwse8813ukw+PjTiMIjLLwT6aSB9jub9WHYZH3QstK1qY+nfuY3G+u7K1QWzH4n9HYqyS0ka1d0n+2GU/2aPAMsIAkHU+yd2fHV0Mv/Y93JM7n71NtNOVM+3vCqcslClW1c3VT20mYXqF65zNpUYvdRaF3k2JkaxlR/Npj8v4gn6g3fVg0e3iTCD+OyQ8qPioXvqbjS6dLn+koAacquCgqnvzPzwJk1WxeWMMdsBnOwMvl2Rev5Z5OufdcJLNqTmfHfy4n8owYshhgQKGTX1ay1biEXWlT8FmFC0Q9A3HKzbufo3GH8w8CPPmku4nWdP6tGElKjvFUVLtxAtSoC4rI4bPfWpVEkw7l6TPUf1JNBvmnQAP5Fk2ABVFk8oDqaFHKBTYGr9etlD32EwjE5UE5FBrrL014wFJjTLbq3flwaAOf1BZg2UZBKWRrmvlckjSe0XXRJJWt7SdDXPR1B9WR9lZ0yGmg2xafDXinK7Kx7oTtSEMY/Iqo8DSDMDYnHAzZB3wzlBhbIPFVkARdYmsyqIgK3vyge/IIHzrPM4XNiYhsV3kZnrw3VEq/Pov+56u9WJJjpWWAyQA6VIaE7zOkmmXrjbODbuDPAXmH2ZbrJ66tzIC1NM8kJD8Z5BiMKy7Kfavhls9Hr5T910mUBUdYRJg7eDbbNb2ULgeQqM8/WnL9tE1+Da3PpR6M9w87aa33l9O9GsCgidIekJxWlvuljKjxMY8gAoKnGEbh25ohY4l2wzHumHCHt/LeYBYp49SrQMxfPLDOB2NlhFCBzxWxR6OYxEvclcRVnxizOwAOW+Bpts1ucpft4KBWTNN+AZeqR/87NXrhhMTALVo0HAbO0yhGLdO+DqxUkcl2YrnlcsOMqNv532vJEgAPtxnutSHI+cKV4hVjNeF4lgC7nBL6Jhm2N3QIMtLf2QC8i2n3b7fUhCBgVrGS2srpt+hAeWlJK2urJHJhjPocA61r92klKnvANvpnWMZEBwwg43Zegyzea4hnRq9P2A5tcvHg=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SN7PR14MB6492.namprd14.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(38070700018);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: KflrvCqeuRV06z6qAGkzJDfIWZYtuIEKR8CoCuy5PCMYcLpg9fMKOvPHfT7jRQIwVoySWx+jBrBJU+ixFNhKKXqtNnvITsGknhPkOKopxZY0i5S60EcoWbnA78oS3GEd9DMySkf0QAVbAVQhow1F1dEbnqCUC/3IMTK0kb56k5AquIul2JrvLoOfdqCqCY595ZHJtPj13O/a3ucUslGLif+ckC8zexkbE1hWCVsG4OfXkl9pvZVjCyqh38tyHjeMqOh7uaBsLH5Q6NtLhoB4uBWW/NmBGKUQcKGnz4sqlYUZnZhaWTXvjyKnMLApVgax1n2/yBsRCSXUIjcKmHDtQThkznFVs3gN1vCrLW329tb+Aill+ulQGIT87Rt7CLkS0tLziLW8dhIRUgeQX9Vt2N59ak/FY4zgEjYyOgvmareS5YxlnvIX8lUM7vYw4IqY8PET/RNDRrJh4+hLk2Maszhxi9ieS0UKMN1+Nno5WZk6yBD8t4Ojsox9o5V9ViV3x74fzYK/2RdfVm5ndBbf9Br2Bs5BkZRuXZdcxgsgxz3Cik5BNdFeowqE/LixX5ytKp3F1FHcQMoecvMZKSddItfG98rhsK42dTVNGNeyDpQRUc1wXxQW9CwVaZMHRpDOnmMONjqfZ/O/V5fEeFmawlHCSKfODdCFzoD+D1FCLvqDoI+ma12pnVSfUTy4J+LXmPWw/KXFsz25L0ItCdeJrkopyN5FqgHWC4tihkbW1dU2G9QusK8hSkJPcAlfT0gPYzAzyjpYD7DNVxyr2a3W6vAv36wToFy9TdMmaZRCQC6t3txesMu3kZ66R/8VA332GKipxbHJrCSpnxVvKELmtUJV4+uaRtpJW3LmlvG1Ooc1/TjnS6YGDkjQ81b5rigCKsaMd+tsbxUwc1tDRpw8qyZ7M1GBB0VE/bdpEzJvJWSdUbaxhI0/XHiMvLbztsR2WPeAAEeWVOZmLL02qset2W3DoGUzKAEeL0QOaipb6nNDgsVRuP2Ux+k3bBZxWGlZk2uCyUvKPG3APoGjVxPRYFxVAKNaN1UrTZmMtrBxi5ARdLDiNu7TPpgIRehktNflwdFNNJ2YHeb9Bxy9TPEDan+g8wp+umTRv24WFqKhZbTfn1Yoqy7+HK3o9UTOgk18zzX3NqxyZBcwhknVGBSOVgbYs0gvdtbuLjITrwmnzQEOEFJvmOUh6jkxLI7bDi//QjlB7a6qXT0pieYSHogoNuGrS/YWTkSgkNmEkglw0rQkK3VziW9mtmVtCJZltKK1Y4cnDJDDwqI4Hf/1yGCRbUy4P2PTV+drJrM8LY/DJ4ZHKrC+vosTlB1rOxNbdih1Dn7WAs8Uk85T8iVb3Osnp4R+Co8HrqOgS+V8G4DrUHaAbW4mDecCDlKPf4FtGj/59ZT82A8sQnbnnhTDtghP4xn0FZ0dbvHAEriyJeI1Jis3fyWGRe/ymVj8ClSRbPdp8fCedi1BYeH+12pIzsz0EZLTGuWKxBNfMsXBdIbSXJnwVFwCbF3UIUeRtIlQilGbkMM5aaGa6HnS23U33eUNbSh1LhQLFdRRHCufx696zVXZzGsqkwgWtYUiKD6GDeZ6CQ/41wwCynQpcLloBJIjZQ==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_003C_01DAEE51.4BE12960"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SN7PR14MB6492.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9bddecba-7e18-46f1-9b3f-08dcbc89da86
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2024 17:52:24.2016 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LfMKtgPysEYu2cx6cFt6QJG2Qw+Ay5L2w6jTdjZFCHkaprEviz0lyBMLiWRRNTXTgcyUQarDaDgdFyIJ4AMOxxzKjWLgj4WlxDJloGsDRLM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR14MB3837
Message-ID-Hash: 4VWSLTO6KS4VNAMXFFSIL4ZMSSR5RVKW
X-Message-ID-Hash: 4VWSLTO6KS4VNAMXFFSIL4ZMSSR5RVKW
X-MailFrom: tim.hollebeek@digicert.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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [lamps] Re: [EXTERNAL] Responding to ISSUE #5
List-Id: This is the mail list for the LAMPS Working Group <spasm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/s0wPyhHpaxKsSKMwLBypagm4iL0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Owner: <mailto:spasm-owner@ietf.org>
List-Post: <mailto:spasm@ietf.org>
List-Subscribe: <mailto:spasm-join@ietf.org>
List-Unsubscribe: <mailto:spasm-leave@ietf.org>
It’s stronger, not weaker, right? The entire point of composite signatures is you have to be able to forge both, right, not just one? You’re only as strong as the weakest link, except when you’re using defense in depth, in which case you’re slightly stronger than the strongest link, but no one ever remembers that because defense in depth always gets axed as unnecessary during budget cuts 😊 C = Classical component strength against classical computers P = Post-quantum strength against classical computers C* = Classical strength against classical computers assisted by quantum computers = 0 P* = Post-quantum strength against classical computers assisted by quantum computers No CRQC CRQC Baseline Max(C,P) Max(0,P*)=P* Lattice Broken C 0 RSA Broken P P* QCs and AI team up to rule planet 0 0 So you can do the analysis and write it up, but it doesn’t say much more than the obvious, which is that the strength is the strength of the hardest to forge signature. It perhaps should be the sum, C+P, instead of Max(C,P), because you have to do the work to forge both. However since the orders of magnitudes are probably dissimilar, it’s roughly the same thing anyway. And I just wanted to say hi to Max. Hi Max! -Tim From: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org> Sent: Wednesday, August 14, 2024 10:36 AM To: Piotr Popis <piotr.popis=40enigma.com.pl@dmarc.ietf.org>; 'John Gray' <John.Gray=40entrust.com@dmarc.ietf.org>; spasm@ietf.org Subject: [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Hi Piotr, > “In addition, it might be appropriate to add a column, for example, in Table 6 (or even better, in a new table in Section 11.1) indicating the "overall" Security strength, which would take into account the weakest element.” While I agree that this will be useful to a reader, I think that coming up with a single “overall security strength” for a composite will be difficult. For example, are you considering before or after your adversary has a CRQC? Perhaps the best we could do is to have two columns for “Classical security” and “PQ Security” and list different numbers in each column. Is this worth doing? Tracked in github: https://github.com/lamps-wg/draft-composite-sigs/issues/29 --- Mike Ounsworth From: Piotr Popis <piotr.popis=40enigma.com.pl@dmarc.ietf.org <mailto:piotr.popis=40enigma.com.pl@dmarc.ietf.org> > Sent: Friday, August 2, 2024 4:03 AM To: 'John Gray' <John.Gray=40entrust.com@dmarc.ietf.org <mailto:John.Gray=40entrust.com@dmarc.ietf.org> >; spasm@ietf.org <mailto:spasm@ietf.org> Subject: [EXTERNAL] [lamps] Responding to ISSUE #5 Hi All My suggestion is to drop the RSA key size from the OID at all. However, if the group decided otherwise, that's not a problem for me. But in such a case, I recommend that the relevant cryptographic compositions be as close as possible Hi All My suggestion is to drop the RSA key size from the OID at all. However, if the group decided otherwise, that's not a problem for me. But in such a case, I recommend that the relevant cryptographic compositions be as close as possible to NIST Security strength/Security Category. For example, as suggested by Mike, RSA 4096 we should pair it with the same cipher suites as the RSA-3072 combo. In addition, it might be appropriate to add a column, for example, in Table 6 (or even better, in a new table in Section 11.1) indicating the "overall" Security strength, which would take into account the weakest element. ---- Piotr Popis From: John Gray <John.Gray=40entrust.com@dmarc.ietf.org <mailto:John.Gray=40entrust.com@dmarc.ietf.org> > Sent: Thursday, August 1, 2024 11:41 PM To: spasm@ietf.org <mailto:spasm@ietf.org> Subject: [lamps] Composite Signatures and KEM open issues that need feedback Hello Lamps. Thanks for the feedback at IETF 120 for composite signatures and composite KEMs. We the authors have compiled together all the currently open questions about composites into one email (sorry it is so long). Feedback on-list is great. Discussion directly on the linked github issue is better. If you’re going to comment on the mailing list. Please carefully tag which issue you are discussing so that it stays somewhat orderly … “Responding to ISSUE #3”. Open Questions on Composite Signatures: ISSUE #1 (Github issue: https://github.com/lamps-wg/draft-composite-sigs/issues/9 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-sigs/issues/9__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmYPi07FMA$> ) The ML-DSA public key should be an unwrapped BIT STRING with no ASN.1 type around them. Currently the ML-DSA draft draft-ietf-lamps-dilithium-certificates uses this: pk-MLDSA PUBLIC-KEY ::= { IDENTIFIER id-MLDSA -- KEY no ASN.1 wrapping -- PARAMS ARE absent CERT-KEY-USAGE { nonRepudiation, digitalSignature, keyCertSign, cRLSign } --- PRIVATE-KEY no ASN.1 wrapping -- } We could try using something like an ENCODED BY id-rawkey as in: id-raw-key ::= SOME OBJECT IDENTIFIER pk-CompositeSignature {OBJECT IDENTIFIER:id, FirstPublicKeyType,SecondPublicKeyType } PUBLIC-KEY ::= { IDENTIFIER id KEY SEQUENCE { firstPublicKey BIT STRING (CONTAINING FirstPublicKeyType | ENCODED BY id-raw-key), secondPublicKey BIT STRING (CONTAINING SecondPublicKeyType | ENCODED BY id-raw-key) } PARAMS ARE absent CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign} } Or just have some text that explains the BIT STRING is a raw key without the extra ASN.1 type wrapping. Does the working group have a preference on this matter? The authors think adding some explanatory text should be sufficient. ISSUE #2 (Github Issue: https://github.com/lamps-wg/draft-composite-sigs/issues/19 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-sigs/issues/19__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmaZiH08cw$> ) Do we make the Domain separator Hash (DER (OID)) instead of just DER(OID)? The one advantage is we end up with a fixed length Domain separator. The authors don’t think this is required, but are willing to make the change if the working group would like to see this done. ISSUE #3 (Github issue: https://github.com/lamps-wg/draft-composite-sigs/issues/6 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-sigs/issues/6__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZgDz_4qQ$> ) Should we consider compacting the CompositeSignaturePrivateKey format? For example, today it is: CompositeSignaturePrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey We could compact it to: CompositeSignaturePrivateKey ::= SEQUENCE SIZE (2) OF OCTET STRING Then implementations would need to recompose the OneAsymmetricKey using the combination of settings give by the OID. This removes the redundant information from the CompositeSignaturePrivateKey because it is now carried in the OID representation itself. The authors don’t have strong opinion on whether this should be changed. The two benefits: 1. Smaller private keys (maybe a couple percent) 2. Aligns with the compact format used in the public key. 3. It makes it a bit more difficult for implementors (but not too much). --------- Open Issues affect both Composite Signatures and Composite KEM: ISSUE #4 Timing. Does LAMPS have an official or unofficial milestone for publishing? Answer could be different for KEMs and Sigs. Obviously, there’s going to be a flurry of PQC drafts from LAMPS and others once FIPS 203, 204, 205 are out. Are we trying to get these into that wave, or not? In particular, should we wait X years for CFRG to finish their KEM Combiners activity, or should we publish this and fix it later if we need to? (The authors and the general feel at LAMPS 120 was to publish-now-fix-later). ISSUE #5 (Github issues: <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/37__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmYIjqiuAg$> https://github.com/lamps-wg/draft-composite-kem/issues/37 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-sigs/issues/24__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZOtTBM-Q$> https://github.com/lamps-wg/draft-composite-sigs/issues/24 https://github.com/lamps-wg/draft-composite-sigs/issues/23 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-sigs/issues/23__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZJ8ofuUw$> Should the RSA key size be specified by the OID, or left free? Related sub question: if specified, which RSA key sizes should we support? Currently we have {2048, 3072}, but we’ve been asked by an implementer to add 4096. Should it then be {2048, 4096}? Jan is advocating for having all three RSA sizes. Arguments for removing the key size restriction: it completely avoids that related sub question. Arguments against: we probably should provide guidance on how to pair RSA key sizes with the ML-KEM and KDF parameter. Removing the RSA key size does not shorten the current list; you need a minimum of 4 RSA combos to hit: MLDSA44+PSS, MLDSA44+PKCS1, MLDSA65+PSS, MLDSA65+PKCS1, and the equivalents on the KEM side. Reminder: having both L1/2, and L3 with RSA is sort of about matching security levels (although we would be quite happy to call all levels of RSA “NIST PQC L1”), but it’s more about people trying to add PQ to an RSA deployment and they only want to implement one size of ML-*. Maybe this is a weak argument? But then if we only go with one PQ level, then which ML-DSA and which ML-KEM is “the one”? For signature the authors are intending to add two new combinations with RSA 4096. We suggest: id-MLDSA65-RSA4096-PSS-SHA512 id-MLDSA65-RSA4096-PKCS15-SHA512 For KEM we are intended to add id-MLKEM512-RSA4096 ----------- Open Issues affecting Composite KEM ISSUE #6 (Github: https://github.com/lamps-wg/draft-composite-kem/issues/40 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/40__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZEJCYVSQ$> ) Combiner construction. We’re on-path to align with OpenPGP and X-Wing. We greatly appreciate the interaction with Quynh Dang to make sure this is FIPS-compliant. Sorry for the confusing notation on the slides and in draft-04. The intention is to get as close to the OpenPGP construction as we can, which is: SHA3-*( mlkemSS || tradSS || tradCT || tradPK || domSep ) Note: X-wing puts its spaceship ascii art domain separator first, which we believe will not pass SP800.56Cr2; We believe it has to be at the end to fit 56Cr2’s FixedInfo. The authors will work with the authors of draft-openpgp-pqc, X-Wing, and the forthcoming KEM Combiners draft at CFRG to align hopefully to the point of binary compatibility. I don’t think we actually need any WG feedback, unless there are objections. <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/40__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZEJCYVSQ$> https://github.com/lamps-wg/draft-composite-kem/issues/40 https://github.com/lamps-wg/draft-composite-kem/issues/45 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/45__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmawI8QXbA$> ISSUE #7 (Github: https://github.com/lamps-wg/draft-composite-kem/issues/54 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/54__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZqgIhVvw$> ) For a security proof of the ML-KEM + ECDH combos, we can point to the X-Wing paper. We should have a similar proof for the RSA-OAEP combos. Not sure how to go about attracting someone to help with this, or if we should attempt proof-writing ourselves. ISSUE #8 (Github: https://github.com/lamps-wg/draft-composite-kem/issues/52 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/52__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmYPtzonQQ$> ) KEM domain separators. Currently we are using DER(OID) as the domain separator. We think it is desirable that a shared secret derived for CMS cannot be swapped into, for example, an OpenPGP or HPKE context. But maybe that does not need to be handled at the KEM algorithm level, maybe it is already handled at the protocol level (CMS KEMRI, for example), and so we should align on domain separators with OpenPGP? For X-Wing in particular, for that one we could take the “\.//^\”, but as mentioned above, that wouldn’t give binary compatability anyway since they put it at the beginning, and we have to put it at the end for FIPS reasons. Do we want binary compatibility with OpenPGP KEM and XWing. If this is true then shouldn’t we have one composite KEM primitive draft, and then drafts that specify usage in OpenPGP and CMS. We also need to think about the encoding of the public key. ISSUE #9 (Github: https://github.com/lamps-wg/draft-composite-kem/issues/48 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/48__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmbTfMJ7xA$> ) The term “DHKEM” and “RSAOAEPKEM”. Are those registered and already used? In particular, does RFC 9180 have a monopoly on the term “DHKEM”? If so, the authors are happy to take suggestions for what to call our abstract pseudocode in 2.3.3. <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/48__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmbTfMJ7xA$> https://github.com/lamps-wg/draft-composite-kem/issues/48. Are we worried about name collisions of Pseudo code in RFC’s. What do we rename it to? ISSUE #10 (Github: https://github.com/lamps-wg/draft-composite-kem/issues/50 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/50__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmbzKCrDyw$> https://github.com/lamps-wg/draft-composite-kem/issues/49 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/49__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmYTa0CmGw$> ) Binding public keys in the KDF. Basically, CMS is used by a lot of embedded and hardware things – a smartcard applet that decrypts S/MIME is an example here. It’s never been true in the past that the device needs the public key in order to do a decryption. Are we asking for trouble if we suddenly make that a requirement of the RSA / ECC side of the hybrid? Note that we only need it at the combiner level, not inside the RSA / ECC decryption routine, which remains unmodified. The authors vote is that this is an ok thing to prescribe, but: 1) We are not embedded hardware vendors, and 2) we’ve been asking this question for a while and have received zero community feedback on it. If we think this is needed in composite, it will have to added. As an example, in <https://urldefense.com/v3/__https:/docs.oracle.com/javacard/3.0.5/api/javacard/security/ECPrivateKey.html__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZPOkjhhA$> https://docs.oracle.com/javacard/3.0.5/api/javacard/security/ECPrivateKey.html does not contain the public key. ISSUE #11 (Github: https://github.com/lamps-wg/draft-composite-kem/issues/51 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/51__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmaztQipkQ$> ) KDF = SHA3 … what about SHA2. This question should probably have the same answer as Dan van Geest’s related question about draft-cms-kyber. The argument for is that even though ML-KEM needs SHA3 internally, this may not always be available to the layer of code doing the combiner, or the CMS EnvelopedData. Just a note, because the KDF is part of the composite OID, adding HKDF-SHA2 will 2x the size of the list. If the WG wants us to do this, great, but please don’t complain at us about the size of the list. The authors suggest, rather than 2x'ing the whole list, we do the following: All RSA combinations use HKDF-SHA2. Each of the P256 and brainpoolP256 combinations are offered with both SHA3 (to align with X-Wing), and HKDF-SHA2. The new list would then be: | Composite KEM | KDF | |--------- | -------- | | id-MLKEM512-ECDH-P256 | SHA3-256 | | id-MLKEM512-ECDH-P256 | HKDF-SHA2 | | id-MLKEM512-ECDH-brainpoolP256r1 | SHA3-256 | | id-MLKEM512-ECDH-brainpoolP256r1 | HKDF-SHA2 | | id-MLKEM512-X25519 | SHA3-256 | | id-MLKEM512-RSA2048 | HKDF-SHA2 | | id-MLKEM512-RSA3072 | HKDF-SHA2 | | id-MLKEM512-RSA4096 | HKDF-SHA2 | | id-MLKEM768-ECDH-P256 | SHA3-384 | | id-MLKEM768-ECDH-P256 | HKDF-SHA2 | | id-MLKEM768-ECDH-brainpoolP256r1 | SHA3-384 | | id-MLKEM768-ECDH-brainpoolP256r1 | HKDF-SHA2 | | id-MLKEM768-X25519 | SHA3-384 | | id-MLKEM1024-ECDH-P384 | SHA3-512 | | id-MLKEM1024-ECDH-brainpoolP384r1 | SHA3-512 | | id-MLKEM1024-X448 | SHA3-512 | {: #tab-kem-algs title="Composite KEM key types"} ISSUE #12 (Github: https://github.com/lamps-wg/draft-composite-kem/issues/47 <https://urldefense.com/v3/__https:/github.com/lamps-wg/draft-composite-kem/issues/47__;!!FJ-Y8qCqXTj2!dMdIjqsPL1q3R2Id8EA2I0a_P18dTjGENAIIStUQ4WelWt7GEPdO57e9P4Btj9-PJv_2_aYSyGnK15TQWrjHqIe_su2kRiy8HmZqOxcd6Q$> ) Should we remove ML-KEM512 and only offer 768 and 1024? Thanks in advance for all your feedback to move these drafts forward, The Composite Signature and KEM authors Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
- [lamps] Responding to ISSUE #5 Piotr Popis
- [lamps] Re: Responding to ISSUE #5 Carl Wallace
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Mike Ounsworth
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Tim Hollebeek
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Tim Hollebeek
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Mike Ounsworth
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Mike Ounsworth
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 John Gray
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Michael Richardson
- [lamps] Re: [EXTERNAL] Responding to ISSUE #5 Tim Hollebeek
- [lamps] Re: External email: RE: [EXTERNAL] Respon… Piotr Popis
- [lamps] Re: External email: RE: [EXTERNAL] Respon… Mike Ounsworth
- [lamps] Re: External email: RE: [EXTERNAL] Respon… Dang, Quynh H. (Fed)
- [lamps] Re: External email: RE: Re: External emai… Piotr Popis
- [lamps] Re: External email: RE: Re: External emai… Mike Ounsworth
- [lamps] Re: [EXT] Re: External email: RE: Re: Ext… Blumenthal, Uri - 0553 - MITLL
- [lamps] Re: [EXT] Re: External email: RE: Re: Ext… Mike Ounsworth
- [lamps] Re: [EXT] Re: External email: RE: Re: Ext… Piotr Popis
- [lamps] Re: [EXT] Re: External email: RE: Re: Ext… Mike Ounsworth
- [lamps] Re: [EXT] Re: External email: RE: Re: Ext… Piotr Popis
- [lamps] Re: [EXT] Re: External email: RE: Re: Ext… Phillip Hallam-Baker