Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-composite-sigs-11
Tim Hollebeek <tim.hollebeek@digicert.com> Tue, 13 February 2024 21:13 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 07AFCC151531 for <spasm@ietfa.amsl.com>; Tue, 13 Feb 2024 13:13:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 GdUtgDRmhCKJ for <spasm@ietfa.amsl.com>; Tue, 13 Feb 2024 13:12:58 -0800 (PST)
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2125.outbound.protection.outlook.com [40.107.94.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BE0C14F739 for <spasm@ietf.org>; Tue, 13 Feb 2024 13:12:57 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EZObdpDzWq5jfavUvG5ujpVziEJyA+GRGy/PPcRCCJuy4xrdyYxqtvMo6SFlxy1X8anG2eUrzO1yiGgXAAVCZPOpN9Yk4I58Uc9k51eWB4Hi2CS46TwH/V7n9RNwCHatDO1RsCVUTLNDJhIlItjqcp7gpnAef7ArDGHmPxWXPS7Op5fFB6uJDADSpT5gMDTitbYXVUtZxXXaowfZPyAo3stJb/q3IEmeYm4V+Sf0R6aKBPEwu70jQzJ3SQWV/9IBb1F/bh56VJdFUokROxzwJIAM8mXZvldVItpmmjlb4H+W09C83FAC8HyQiZ6pXMMWSysh/0iW6Ym7EKnBFCvIeA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=TprJofMMxQVCQmUxmRKogs7dnZvPtK4J+urlNSry/Hk=; b=IaihA4ptb/XCx5IitGBL5Do6Hw3BL9Es5e5kQi5Regr6G/Q/lwlFJuB01CDoo6pQOTmFlHNeVhhiVxZWX8j474XZ5XdAEgExO/VoKElubtqHHhvdqMwGodvrz9suoIl46tHy97l/CI3vfqhiTJ76aT73eZvyXeczJiBUz1i/BwQZVtMOXUfQ5cpum6s6X+xy0yFZ5/L3flGD0+lRS3aEXQqDZ8EHdsjiXZ38oqcDBMi/5qa+VUFE5bdjkpYiAcbREyS8S0ICAz1HYV6qBM7RB4QSQ9qE9n5BAW9x/liyQLmHcYeFxbAhtcoWb8OPDPm8hJ4fTCPGz2z7WoTUvbRaRA==
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=TprJofMMxQVCQmUxmRKogs7dnZvPtK4J+urlNSry/Hk=; b=zr2RnyU6qpbPYJgkQjKNy/REHJDo7OoC+mvoYZdufcVYVhEAvw7GAlWSiVj4yFOeBe69XEByX2U9Kf6OGhHNAxd+Z9LrgKk+BtmFtLDdEnxLWWwubDW2xgnBOIUn6o+1xsZCdnkRYC6MQYhaOrrD+JkMUmj/IJkfxIQVnucPL+/QMBBTrxXtI19r7xnnVETCGG7dLuw5y2b+Y/PfPUtG+NS4bk75IrN7tQWmEUJe9a698lwu9h6OqviiW9cTFpF1KZ23ARA8ZgC7wZx+zR246lF4P3V3UW8tFxrtUP2r75bCvFUEv/h+tj2yK1dvQNpMFLpB48mpG8J+g+3WvqZKeQ==
Received: from SN7PR14MB6492.namprd14.prod.outlook.com (2603:10b6:806:328::17) by IA1PR14MB6269.namprd14.prod.outlook.com (2603:10b6:208:42a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7270.24; Tue, 13 Feb 2024 21:12:53 +0000
Received: from SN7PR14MB6492.namprd14.prod.outlook.com ([fe80::7342:6ba1:7470:6412]) by SN7PR14MB6492.namprd14.prod.outlook.com ([fe80::7342:6ba1:7470:6412%5]) with mapi id 15.20.7270.025; Tue, 13 Feb 2024 21:12:53 +0000
From: Tim Hollebeek <tim.hollebeek@digicert.com>
To: Tomas Gustavsson <Tomas.Gustavsson@keyfactor.com>, Jan Klaußner <jan@klaussner.biz>, "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-composite-sigs-11
Thread-Index: AQHaW3pLXJsjtsg8uEag2+Vy9hNQ/bECaCiAgAADiQCABJuQgIAAByoAgAFbn4CAAAzxAIAASu4AgAAHAACAAAIk4A==
Date: Tue, 13 Feb 2024 21:12:53 +0000
Message-ID: <SN7PR14MB6492C847F5BC0341F6E19F90834F2@SN7PR14MB6492.namprd14.prod.outlook.com>
References: <1751D067-A337-4611-A638-02DB5F90394A@amongbytes.com> <d3abe6ed-4150-43fb-b6f4-d3402ae41599@cs.tcd.ie> <CH0PR11MB5739F82A580E1B892DF90DF69F442@CH0PR11MB5739.namprd11.prod.outlook.com> <FAF0B5DB-2638-499D-A2B2-2C3F6335B34F@ll.mit.edu> <CH0PR11MB5739D5ABF77D4B8DCAE484379F442@CH0PR11MB5739.namprd11.prod.outlook.com> <SN7PR14MB6492A3CF89BA48471C7088CC834B2@SN7PR14MB6492.namprd14.prod.outlook.com> <5222b88f-565b-489c-abc6-4c053950b4c0@redhat.com> <0f104c7c-b764-4cc5-88fa-59c05a7a1eb2@cs.tcd.ie> <33DC2C85-D34B-44E7-870D-618ADA4FCF3D@ll.mit.edu> <4c730c23-c00f-493f-b6a7-003379a4589b@klaussner.biz> <A9412BAF-F77D-49CC-98E8-97B9085D11A7@ll.mit.edu> <f992273c-ce9f-4f40-b5f2-744970b2457b@klaussner.biz> <DU0PR03MB8696C64F62317E3FE08EDBBF864F2@DU0PR03MB8696.eurprd03.prod.outlook.com> <SN7PR14MB6492C7E938DE496AB683B9BB834F2@SN7PR14MB6492.namprd14.prod.outlook.com> <DU0PR03MB869658D6A4BDC65782B9790E864F2@DU0PR03MB8696.eurprd03.prod.outlook.com>
In-Reply-To: <DU0PR03MB869658D6A4BDC65782B9790E864F2@DU0PR03MB8696.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
msip_labels:
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_|IA1PR14MB6269:EE_
x-ms-office365-filtering-correlation-id: b4452627-96e7-4d6e-9ce3-08dc2cd88ad8
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hi4uPro9RPN/7paUyWuOokLglCy0dzkLo0zuRMnpjKTGdga3sHSvD04SS1XvLq61dwL0Av23FjSYucE4l6VLlnvDwDEJZE0Z5120qIcWEx2vXbhSWG+KxLlLiRsah/H9O1wGArBrWZsu/+RjB5HX2bC37wAL1ZODbxi0DHeeYPuz/Dol/9JosJk/euh1xkgcZPvWKUTtKkkOSIwc7Ph/rYl810hOY8GZrJsuwOAUcP9NYE0BwIXhqxZRkHvSJ4BTFnnB5zfmouDZ5X0qWVFpdRfKN36koK80Clt8CETICFboRXbTmBBp7T64l+KvvIpf8bfnDiEikolB3uWTNRKi/Q6/USOaUIH4PLxkv8690ER18oCzZVEH8kfKsFUO4ZvVq90w9IAJThhUohRgVl0eUMZIV+GAi8q+XhBGK6QJNXZRBVZYmEq5kxDO13j6fTCQqO8q9nyUBpAx2rsYQm3FXFyGMhTIdW/iIUwvwvWnG7hlfEMNMqSkIcKM+C9G8+yc/RqBVcA2szzGg9bG+TjfgN7TIevvPi/5tpSUH6rdOvuMzE21rP19fGM7YfDx9BUZen7KB8yqbQOPbDu78SRKWip6036FMjHcVpvnIG+g9oI=
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:(13230031)(366004)(396003)(136003)(39860400002)(376002)(346002)(84040400005)(230273577357003)(230922051799003)(64100799003)(1800799012)(186009)(451199024)(55016003)(966005)(478600001)(41300700001)(9686003)(8676002)(110136005)(44832011)(8936002)(52536014)(5660300002)(2906002)(66574015)(64756008)(76116006)(66946007)(66476007)(53546011)(7696005)(86362001)(316002)(71200400001)(6506007)(66446008)(66556008)(83380400001)(26005)(33656002)(166002)(99936003)(38070700009)(38100700002)(122000001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: zPOYDB6spBJ4cJlUD5tous5n2BeUXTQUi2aYPGsV8to5ECLOb4UsaC44RU2PKL484yGfC2unZuvJmVU4+z5jisKgz40I2U38GkslV98sOpu5zJvFw4ZgL7kt9I6/CIqyKvG7abTGXklmnB+ZzTpm8qHQXbRb4xv7N/QuDoUTgrs4T8csryiW0d1DTlgEXe6mMDoOFmMQPejYyX1avkTMBEyC41BjJx5Zzc/juyet3lqNq9SGiiSB1B18ln5vnD5NUvUVqSGMRIkBU5KbeIZMR9eho6aMzFtZbPaqOPMNswNsvzuC8S2nazciVqbeWyMAXu3BycP5sZf4NpZ4f5/5/8aRkqw1iobqc8+DGU67fw2r9IvIK2/YoBpZLyX7Cs+u8a4nDYvLaZgJJAY2d5NAVD2NLtEDbNDr8IGj6mHoJ6a8I+7lI/oJPWKGR8Iv2Zxzd3/rfkRD7B6EBRZSu506kIoTVyxzf5UP7ovruTiiEiSH36uLdiTM1m4Kyc+GeNPFBaYAnjRIh3fPUgEnHUWxvARMEXKw7thSKIIR7ighbOY7CB0Qssw694ZJDsqQFnG+Xk71NneA2cZpxUFJadKflYTpmxze2Rk1r+fRRy49Eojl5H+4d7uhlU0o+BnT4cjrpgLF8Eif9wsyVpihj0FEhJlU1bgaLWJE6PM480z77Qrji4YJ5lSbv+kbHMeV4f5QU52/16PZfThrdzFz+9wZCqVJUnQmBADSNF6hDkHFx1XIqCP7W25TFoF8XsuvIAPvNd1ZXz85bvxOfEBbsR7Yjn6+Hah2G7SDZ5DNy4vuN/ypcZWYvtUdmLZzGZn2Rqj/qyinRFlU8OgZcKBEA0Z+kUWHWIWsAykcPLYNe3Xyy8tM7klX9BlooekGTeKT6tc7IbXZWpp0UKgdt4q4pOJ7XOla1pbW/IPe1XjTJ584sWtIByfDqyWwoHM4E0/h1tJgf4ZS/YZ39gtYvFZMeBNEJKVOaA/SCCJRDwwVfiAzZ61POr/sVrxXZnmNtVLalms9MZmKdjrAv/Pu6xHG523mLPG7JgSjXXy7gb0mEAqwkUZ7ZzlUrrHp0nl9FwVMH4vdFIElHZHokCoIRGEwJKmfVveGEs1uY+rW4qORUczJLr3yyaLQQpIAasHI5TSofbsHvMvUTachjNzD6wR073fwb5kb+tqYXtATjisVjS1Q2qan7L7dAUXt3kOroXyP/vpSmq+eM8tI2HxYyBLrSY4LIN/f4kcdLzmXz0a9ChxecXWUFizBFRDlQbAx9n3yrYlHlsQKLO7ZWvtXl5Me56dl7IsTPLxfQS3WsihS2WMpc9T97PsKXY68/MpRwh7srWwGDHH0dUu0z4ncbcAn2F7+ohYskIE/RnAptjlusujaHyeL13Ox3TK38+4yU0rIdk4BkVYYyN0nH3uGL53NbcKulL7tYITPL6Kli6c2HtirwWKxjmlH6oi6/o+nFaB3uBq7ZgX7Z3znF164YX8uGstfJO7wxu+Vd3clsjohM+kWw0a7JdFOB5w0jo5WfrukJd2puib2Kq27P75EBn1RMdkU9dVxZroNFB4ovtAfoyF7/JhEPg4mxmgl8DuqeB6IPRF2D/PKr4nsEksRaicGKTBEkA==
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_060A_01DA5E97.7F225500"
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: b4452627-96e7-4d6e-9ce3-08dc2cd88ad8
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2024 21:12:53.3641 (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: Q4W6ZeAifBY0nxxvSxqBxJpervdoH02IwsWdZv9A/RTLrG7/ZmFeXrIR08/sbfaemomvEhwGG/HHGOvKOTRjkMAbsv++IzG78P8Is/YqdLk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR14MB6269
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/5S9F_eOmzDtKoUT42lAkT7woO40>
Subject: Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-composite-sigs-11
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: This is the mail list for the LAMPS Working Group <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Feb 2024 21:13:03 -0000
Yes, I’m very active at X9 as well, and have been contributing to X9.146 for precisely the reason you mention. I’m doing my best to try to help keep everyone on the same page. -Tim From: Tomas Gustavsson <Tomas.Gustavsson@keyfactor.com> Sent: Tuesday, February 13, 2024 4:02 PM To: Tim Hollebeek <tim.hollebeek@digicert.com>; Jan Klaußner <jan@klaussner.biz>; Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu>; spasm@ietf.org Subject: Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-composite-sigs-11 Are you present in x9 Tim? I hope it has been debated there as well. It would indeed be good with harmonization between standards bodies in this important topic. Bloat is also one of the biggest causes of vulnerabiliies. Cheers, Tomas _____ From: Tim Hollebeek <tim.hollebeek@digicert.com <mailto:tim.hollebeek@digicert.com> > Sent: Tuesday, February 13, 2024 9:41:22 pm To: Tomas Gustavsson <Tomas.Gustavsson@keyfactor.com <mailto:Tomas.Gustavsson@keyfactor.com> >; Jan Klaußner <jan@klaussner.biz <mailto:jan@klaussner.biz> >; Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu <mailto:uri@ll.mit.edu> >; spasm@ietf.org <mailto:spasm@ietf.org> <spasm@ietf.org <mailto:spasm@ietf.org> > Subject: RE: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-composite-sigs-11 If a CA is considering using such a solution, they should be aware that it has already been debated by IETF and found lacking: https://datatracker.ietf.org/doc/draft-truskovsky-lamps-pq-hybrid-x509/ Anyone attempting to use a “backwards compatible” dual signature model needs to think very carefully about downgrade attacks. -Tim From: Spasm <spasm-bounces@ietf.org <mailto:spasm-bounces@ietf.org> > On Behalf Of Tomas Gustavsson Sent: Tuesday, February 13, 2024 11:09 AM To: Jan Klaußner <jan@klaussner.biz <mailto:jan@klaussner.biz> >; Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu <mailto:uri@ll.mit.edu> >; spasm@ietf.org <mailto:spasm@ietf.org> Subject: Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-composite-sigs-11 > Hypothetical case: you used ML-DSA for your certificate chain now and 3 > years later its broken. Now somebody comes with a document with your > signature (that he forged) saying you owe him 1000€. Its hard to prove > him wrong that in this case. Using composites he would be forced to also > present the second signature that he can not forge. I don't like this example. This forgery would likely not be valid in any jurisdiction today. Just as with physical signatures there is a lot more to it. Shouldn't i.e. eIDAS define what is required for (qualified) signature creation and validation, much as it does today. We give such legislators tools to use of course, be it composites or multiple signatures, or just single signatures depending on the risk assumed for different use cases. I'm more afraid of my digital id that I use to login and sign on-line transactions (banking) be broken. In this case the sender application and receiver is part of the same eco system playing by the same rules. It's a complex risk/benefit analysis for sure. A CA may choose to use a backwards compatible hybrid solution. I.e. X.509 alternative keys/sigs as discussed in X9.146 draft (who knows where that will move, but may as well bring it up as another standardization organization working on hybrids). Cheers, Tomas _____ From: Spasm <spasm-bounces@ietf.org <mailto:spasm-bounces@ietf.org> > on behalf of Jan Klaußner <jan@klaussner.biz <mailto:jan@klaussner.biz> > Sent: Tuesday, February 13, 2024 4:22 PM To: Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu <mailto:uri@ll.mit.edu> >; spasm@ietf.org <mailto:spasm@ietf.org> <spasm@ietf.org <mailto:spasm@ietf.org> > Subject: Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-composite-sigs-11 Hi Uri, answers inline br Jan Am 12. 02. 24 um 19: 38 schrieb Blumenthal, Uri - 0553 - MITLL: > I disagree in 2 points: > > 1. ) "[. . . ] The only use case for multiple signatures that I see is non-repudiation of documents [. . ]" > > Hi Uri, answers inline br Jan Am 12.02.24 um 19:38 schrieb Blumenthal, Uri - 0553 - MITLL: > I disagree in 2 points: > > 1.) "[...] The only use case for multiple signatures that I see is non-repudiation of documents [..]" > > It also covers weak (root) keys due to bugs nicely. Imagine a TSP produced its RSA root keys using the vulnerable secure elements affected by the ROCA attack. Until you exchanged all certificates, smart cards and informed users valuable time passes, not to speak of costs and reputation. And chances of implementation bugs are much higher for the upcoming algorithms. Composites would give a second floor also in this case beyond the question if the algorithm holds. > > In short, I don’t think the above is reasonable. And it places bets on correctness of Classic algorithms implementations – which IMHO is a risky bet. Can you elaborate on why it is not reasonable? And why do you think composites relies on the correctness of classic algorithm implementations? (I interpreted your sentence that way, correct me if I am wrong). Composites try to distribute the risk of implementation faults and algorithm weaknesses on two independent pillars. It allows failures in both of them since failing of both at the same time is much more unikely. > > 2."[...] Multiple signatures address it nicely. [...]" > > Multiple signatures would mean also multiple PKIs that need to be operated separately, which is a non-negligible cost factor, let alone keeping them in sync. Also handling these multiple signatures in applications needs to be tought of. What is a user supposed to think if one signature of the same signer fails and the other succeeds? I think its no obvious. This needs to be handled in all applications out there which will be also error prone. Composites have in my view the advantage that, in order to support them, they need to be implemented in only a few components/crypto libs by people who are sensitive of security. > > Composite signatures have no advantage over multiple ones in this context. The policy that governs the receiver will rule, and it trivially straightforward: > The policy states whether a subset of the signatures (separate, or parts of composite), or the entire set must verify for the overall validation to succeed; > That receiver policy may state that only certain signatures (e.g., made with ML-DSA) are “valuable”, and others can be ignored – in which case it doesn’t matter how much the sender is beating his chest demanding that all the provided signatures are validated. > If signatures are composite – it would force the PKI to support multiple algorithms, which (a) at least some CA may not want, and (b) would create additional unnecessary attack surfaces to worry about. But for those PKI/CA that want to support multiple algorithms, multiple signatures would not pose a problem. Thus, a clear win. For authentication I agree, the receiver can do what he wants, its his risk. For non-repudiation it is quite important for the signer to tell at signing time under which conditions he accepts obligations arising from his signature. This is also true for a CA. Therefore a receiver should better check both signatures to be safe he can make such a claim later if needed. Hypothetical case: you used ML-DSA for your certificate chain now and 3 years later its broken. Now somebody comes with a document with your signature (that he forged) saying you owe him 1000€. Its hard to prove him wrong that in this case. Using composites he would be forced to also present the second signature that he can not forge. To spin this scenario even further, if an attacker can forge CA signatures, he can completely make up your signing certificate. So even for a CA it would be better to use composites in order to avoid such issues. Even multiple signatures on documents would not help here, because where it is enforced that you need to sign twice? If CAs decide against it, its their business risk, but nobody forces them with this draft. But a CA failing in this would also damage the whole ecosystem, hence the recommendations from ANSSI and BSI. As for the attack surface, I think handling multiple sgnatures in application along with all the certificate stuff poses a greater risk of misconfiguration, misuse, condusion and ignorance on the user side that will exceed that of composites. With composites, all applications can handle this as long as the crypto lib understands the OID, which is a small attack surface that is quite controlable. And repeating myself, operating multiple PKIs for the same purpose is a quite relevant cost factor. > > > > > > > > Am 09.02.24 um 20:51 schrieb Blumenthal, Uri - 0553 - MITLL: > For asynchronous protocols (CMS, code signing, etc.) there are much > stronger arguments for hybrid signatures > > Could someone walk me though a code-signing scenario that > needs hybrid signature algs? I can see wanting both kinds > of sig, but not why those can't be separate. > > I don't think there's any valid scenario or use case for hybrid/combined signatures vs. multiple separate signatures. > > The only use case for multiple signatures that I see is non-repudiation of documents created at date X that could require validation at date Y >> X, with a potential of CRQC falsifying a signature sometime between X and Y. Multiple signatures address it nicely. > > > > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org <mailto:Spasm@ietf.org> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!BjbSd3t9V7AnTp3tuV-82YaK!3Sf65v2jtKFwe44v240wELSdCuElQvFyY47oDJn_lQXbZpYEngvdrAXHdVOJPuwbfNjclGymViRHSUao6rc0JHjb$ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!BjbSd3t9V7AnTp3tuV-82YaK!3Sf65v2jtKFwe44v240wELSdCuElQvFyY47oDJn_lQXbZpYEngvdrAXHdVOJPuwbfNjclGymViRHSUao6rc0JHjb$> > > _______________________________________________ Spasm mailing list Spasm@ietf.org <mailto:Spasm@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!BjbSd3t9V7AnTp3tuV-82YaK!3Sf65v2jtKFwe44v240wELSdCuElQvFyY47oDJn_lQXbZpYEngvdrAXHdVOJPuwbfNjclGymViRHSUao6rc0JHjb$ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!BjbSd3t9V7AnTp3tuV-82YaK!3Sf65v2jtKFwe44v240wELSdCuElQvFyY47oDJn_lQXbZpYEngvdrAXHdVOJPuwbfNjclGymViRHSUao6rc0JHjb$>
- [lamps] draft-ounsworth-pq-composite-sigs-11 Kris Kwiatkowski
- Re: [lamps] draft-ounsworth-pq-composite-sigs-11 Stephen Farrell
- Re: [lamps] draft-ounsworth-pq-composite-sigs-11 Tim Hollebeek
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Mike Ounsworth
- Re: [lamps] [EXT] Re: [EXTERNAL] Re: draft-ounswo… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] [EXT] Re: [EXTERNAL] Re: draft-ounswo… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Stephen Farrell
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Stephen Farrell
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Scott Fluhrer (sfluhrer)
- Re: [lamps] draft-ounsworth-pq-composite-sigs-11 Mike Ounsworth
- Re: [lamps] [EXTERNAL] draft-ounsworth-pq-composi… Mike Ounsworth
- Re: [lamps] draft-ounsworth-pq-composite-sigs-11 Kousidis, Stavros
- Re: [lamps] draft-ounsworth-pq-composite-sigs-11 Tim Hollebeek
- Re: [lamps] [EXT] Re: [EXTERNAL] Re: draft-ounswo… Tim Hollebeek
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Hubert Kario
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Stephen Farrell
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Stephen Farrell
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Mike Ounsworth
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Hubert Kario
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Stephen Farrell
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Mike Ounsworth
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Stephen Farrell
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Stephen Farrell
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Stephen Farrell
- Re: [lamps] [EXT] Re: [EXTERNAL] Re: draft-ounswo… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Michael Richardson
- Re: [lamps] [EXT] Re: [EXTERNAL] Re: draft-ounswo… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Michael Richardson
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Jan Klaußner
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Tim Hollebeek
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] [EXT] Re: [EXTERNAL] Re: draft-ounswo… Tim Hollebeek
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Russ Housley
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Stephen Farrell
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Jan Klaußner
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Russ Housley
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Stephen Farrell
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Jan Klaußner
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Tomas Gustavsson
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Stephen Farrell
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Stephen Farrell
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… John Gray
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Tim Hollebeek
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Stephen Farrell
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Tomas Gustavsson
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Tim Hollebeek
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Jan Klaußner
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Tomas Gustavsson
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… John Gray
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Kousidis, Stavros
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… John Gray
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Ilari Liusvaara
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Carl Wallace
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Carl Wallace
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Jan Klaußner
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Stephen Farrell
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Ilari Liusvaara
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Jan Klaußner
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Falko Strenzke
- Re: [lamps] [EXTERNAL] Re: draft-ounsworth-pq-com… Mike Ounsworth
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Stephen Farrell
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Mike Ounsworth
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Falko Strenzke
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Michael Richardson
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Jan Klaußner
- Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-c… Russ Housley