Re: [lamps] Double signatures

Tim Hollebeek <tim.hollebeek@digicert.com> Sat, 22 September 2018 11:33 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 C65A3128D0C for <spasm@ietfa.amsl.com>; Sat, 22 Sep 2018 04:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ie6UCZmDQua for <spasm@ietfa.amsl.com>; Sat, 22 Sep 2018 04:33:15 -0700 (PDT)
Received: from mail1.bemta23.messagelabs.com (mail1.bemta23.messagelabs.com [67.219.246.212]) (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 63A78130DE6 for <spasm@ietf.org>; Sat, 22 Sep 2018 04:33:15 -0700 (PDT)
Received: from [67.219.246.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-b.us-east-1.aws.symcld.net id 3F/DE-23144-A7826AB5; Sat, 22 Sep 2018 11:33:14 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA2WTfUwTdxjH+d1d7w5C9SwozxhO6UQmeE2rRjF ZFv5xITPLDIn7Q3w76EEbSml6JQM1WbcEO1smLKGDVRAwpWytGjGgxvASa+J8iQbxjUjUUNQw 2BDwBRc32F1/1Wn855fPPd/v83yfu9yPJTUXmVRWrHSIdqtg0dIJ1NDyrtN81SeBAv1Y+5KcU MMsnfNsIIhyDt8uyiXzOpsa6Lz6V52qPL//b2ILuU1lthaWV+5Wmbw1IcbmfKyqrK7pYJzoZk DlRvEsxdWQ8HRccqMEVsPVEdA/5mTwwz0EFy4NMoqL5vRwu/d3QuFkbifMRyKkwiSXAc0Hmyi Fk7iV0HPoPIM9mdDc1korg5K5BgQvJs8SOC4DnK6+qEnN7YCGY3UqnPYdAx1zx6NT47lcmJ0f ijLilsDs5aMETkuBuw9bogxcMoxcv0JjXgx/jM6psH87ND8Nx+rL4IinP8ZLYbDFg5Qw4PoZO P3oCcICD1NeL4n5S/jtSg+DTYMIAidDFBayoKe3X4XZAvcnDsdMAwi6O2/EVvoIgj+OUFjoJu F6tysmpEFtxzCBBQ8DtXf+jWZrOCPUB8N0Hcr2vfV+PtlHcq0IZlq8jC/6pRbBpV8eUtj0NUS 6XhKYt8FU3yMScxb4v59nMGdDoG0iVl8Fz+qGqffrPJwdaItxOtR7RmK9q+HM3KRcZ2T+FLqM 7zvWw/5r03QrWhhE6wvt5hKTo0wwW3iDXs8bDGv4tTKt0Ql7+EJdhcSLguTgDTrhG0knVZUVW Yw6q+g4ieQ/2Wgji8+gW66SMPqAJbSL1d82tRdoFhSWG6tMgmTaZa+wiFIYpbGsFtSfZwYKNI vsYolYWWy2yNfhtQxsojZZvUCR1ZJNKJPMJVi6jDayB4erG0k20viDfE4qp4ayllvF1BR1vtL AKQ2mCuubca8v2CBampqkRnFxcZpEm2gvMzve1cdRCou0SepNypREs9XxJnVcXoiQF7rp8ysL OYT/pVQnOrTxQPHV0MX8ihmy1NC7+id9fu7MVlsjce/Df+L3nRr5dXrzugRj/WypdyrTmxnyh ztqR6tXjUayD2RMb9WURz7ea3enneirFd23/qSvtnD3iyZ8Gzx/bWoPfpa+Nj3u2PLNww/OLf OcMLhd1L4bX+wIu56XDo0t/Nng+upO19EVK0e1lGQSDFmkXRL+AzPeBGNbBAAA
X-Env-Sender: tim.hollebeek@digicert.com
X-Msg-Ref: server-25.tower-384.messagelabs.com!1537615993!4767011!1
X-Originating-IP: [216.32.180.183]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.9.15; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15682 invoked from network); 22 Sep 2018 11:33:13 -0000
Received: from mail-bn3nam01lp0183.outbound.protection.outlook.com (HELO NAM01-BN3-obe.outbound.protection.outlook.com) (216.32.180.183) by server-25.tower-384.messagelabs.com with AES256-SHA256 encrypted SMTP; 22 Sep 2018 11:33:13 -0000
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=cPkkQek4jxXr/blSjZFmzj+8bzDP/u+DOUJBB9MCS5k=; b=VbS3tx63Wm10QXNZEmxJ5xVJ8iX6j4U8eHWtEvZTVC2RyF/g/wMLrrmwAIUYmn/0gMEMFUyV9U3Wul4n8Qlbgkq8stDv+Md+nzYmsYIFEw0d66Z7CrHP7bcutoGWc+ST89x1zkkgRWpJIN4Qu7SrDogBdOc1Q9a9pmu/X1hi2y0=
Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1092.namprd14.prod.outlook.com (10.173.161.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.18; Sat, 22 Sep 2018 11:33:10 +0000
Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::29f5:b1e:c591:e5fc]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::29f5:b1e:c591:e5fc%7]) with mapi id 15.20.1143.019; Sat, 22 Sep 2018 11:33:09 +0000
From: Tim Hollebeek <tim.hollebeek@digicert.com>
To: Jim Schaad <ietf@augustcellars.com>, "'Panos Kampanakis (pkampana)'" <pkampana@cisco.com>
CC: "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: [lamps] Double signatures
Thread-Index: AdRJE8Ft784CpTSnSY6kx9oi8PdHNwACpPmAAAKWXAAAAGJ/gAAdEOUAAA5DsMAAAQ7lAAAACX/AAA0enYAAIGE3gAASdg6AAFmu0YABKMIkAAAJAhsAAEX9wAAAAm64gAAOu/qQ
Date: Sat, 22 Sep 2018 11:33:09 +0000
Message-ID: <BN6PR14MB1106A9CD5DE1142B5ACB8A4C83110@BN6PR14MB1106.namprd14.prod.outlook.com>
References: <005a01d44916$7c9cb560$75d62020$@x500.eu> <CAErg=HHhU9H-Ng8sUtXu2S+F0fr2tLOX6=8UR77gz0YLqtGyaA@mail.gmail.com> <004a01d44928$b1500d40$13f027c0$@augustcellars.com> <04ce01d4492a$39400ce0$abc026a0$@gmail.com> <003601d4499e$7c8be3b0$75a3ab10$@x500.eu> <BN6PR14MB110623B94ED97509FAE9F71283040@BN6PR14MB1106.namprd14.prod.outlook.com> <087c01d449db$c78e6350$56ab29f0$@gmail.com> <BN6PR14MB1106DBDE49673AED8E6C937383040@BN6PR14MB1106.namprd14.prod.outlook.com> <9A1A8BFC-9670-42EA-8D8D-B3DC2494CB95@cablelabs.com> <798ACAFB-7417-42F5-BF1C-6C0765606AC0@vigilsec.com> <af01c991-c052-37a8-a14e-aa432f05470d@cablelabs.com> <002001d44c42$80388fd0$80a9af70$@x500.eu> <9c5c57bdbd9b4fe4aee5040f319f46a2@XCH-ALN-010.cisco.com> <7edda3b2-7a45-83ca-b4d9-698dbb7ca8c3@openca.org> <a529b8de7dbf4402865d1253e9553969@XCH-ALN-010.cisco.com> <000001d4522b$44713c10$cd53b430$@augustcellars.com>
In-Reply-To: <000001d4522b$44713c10$cd53b430$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [12.0.200.35]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR14MB1092; 6:TThsnHfQhhK12OxKR6dHPITCGoqFtkP+24ABw2Y0gEGu/X7iR8O6Vu3QvzgXxC/HbXMxOiK+lvNoyMu7bw/DxsRJ8ThsAS7oahxPmlmUvN52B2ShjYDKiqCoFAmgvAOsc+Yc4ef8zwi0OhgSIIdjjySJoeMzqMJcAoPtdx/7WIslcDWleP0uTIPtwLMLHbHy4iBNVTpt5DyrEWh+ZZludJFw7dBTXD6LEYmtxR7dZAec8VjX2n3sQpfEHEr7wGMhhLb7DvkFiecag4Kjw669qDgIlkIem/bko55MX0VD9mxP5mrM1KRK0KDkl4cEubiyMdWQYQgx/IgWFNlTDNLH3Ml/sksD/AXCkj7dhM145SKqTDFOJ0NmEVnP4Ywvea4zunlk/eFBaSSsvYwQjj9TluxOcyYl8hQ/tTFqn/KGeE8GDQDnZnbEit+j+jcgXPdiJA5yTdXx4tw1axXd/4euTw==; 5:/jsSBDOfSPcAbpJSg9/U8mh784Ufd53G8nuadre5GPgYNe7l+jkgnMY4MW6heviJFDUAQERaMgg4pD6NHMaSyOfOT6h2yhQd/z5xfbeEPq949o0puHM4BUlJTELU7N1/n8Qrz+J2G6QVAyjDUTo9PSmOHh2lv5NBp7F1Co5HKLE=; 7:dtUbmQ1i4ds9lRAQQ4t/LKHbbx7uHjNV5JuY8bV8MNVpwqdr4MLQ38PtwxXv8zgiHn09lIQN+H/sxJk21XDR2MzuWYUb+d30F+Zju4T7/9MtY55c8SVzENOlziPeGbKlHhScVoSghzaRT0kuuADBvTt0siK/FtFwrMDShgNsry9aU7oGCmVKCojYAQIsq9h30xJdn5PMW9Peylc1g+m/wT6PRyRhSw2HLTnYDPvPWowhCzywk9jP9azpBJrRJvnT
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 9bdf606a-b891-4bb8-0558-08d6207f2c7f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1092;
x-ms-traffictypediagnostic: BN6PR14MB1092:
x-microsoft-antispam-prvs: <BN6PR14MB1092AF69DFE9D6CA7E6B0E0083110@BN6PR14MB1092.namprd14.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(95692535739014)(35073007944872)(278428928389397)(85827821059158)(120809045254105)(192374486261705)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231355)(944501410)(52105095)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051); SRVR:BN6PR14MB1092; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1092;
x-forefront-prvs: 0803A0241F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(136003)(39860400002)(346002)(366004)(189003)(199004)(53754006)(51444003)(54094003)(4326008)(53546011)(6506007)(93886005)(102836004)(25786009)(476003)(229853002)(11346002)(6246003)(2900100001)(76176011)(446003)(14444005)(256004)(486006)(16200700003)(44832011)(6436002)(33656002)(53946003)(9686003)(6306002)(54896002)(54556002)(71200400001)(236005)(97736004)(561944003)(53936002)(7696005)(186003)(8676002)(66066001)(71190400001)(733005)(5250100002)(106356001)(14454004)(86362001)(105586002)(55016002)(110136005)(68736007)(7736002)(2906002)(99936001)(99286004)(606006)(5660300001)(316002)(966005)(8936002)(6116002)(3846002)(478600001)(790700001)(81156014)(81166006)(74316002)(26005)(559001)(579004)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1092; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: zKWyzR9WqiirvPZskOi/OgtmBwzlmlBHkccUjxQo33Sf+YlC2TCBYwFarI+PuiAeyMVVlI3TO/72kInfWPuDWn0ZmL17ih2hO0G5505+h0oR0KcjIXSs5eoeCsfqTW0eoJHoMHdNUj9FyFdofm6Qtk1KkiSPrTg6oCJ3ODCfSEHoHmepX7gnPHleIW8CnlWOcEz5wsm0Rh4jFZjq3vghWkUfR+ntvuqjE2/qnZ3gzXh25elbjfPff+DPr/itIAUTa3jWFEOSdHSEnI0waeJO/wO4i5/GBw8Z3uoijGoUNvYH7i+2MXJykGspxwjBwr7hC9edJrzP6rfaMU2+uol+3umVSmu5mXrEEp/x4zFixiU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_0900_01D45246.78B12290"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9bdf606a-b891-4bb8-0558-08d6207f2c7f
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2018 11:33:09.7711 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1092
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/pZAk7vq11FrIEKbSekJIIMe70Uw>
Subject: Re: [lamps] Double signatures
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <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: Sat, 22 Sep 2018 11:33:22 -0000

How are chain/path building, AIA, and so on affected?  Alternative signatures just give alternative information that can be either be used separately or additionally to verify a particular certificate signature.  How you find valid certificates and put them together into a chain seems to me to be completely independent of how you validate a particular signature.

 

Problem 5 seems like a particularly odd objection.  I haven’t seen a proposal for separate certificates.  Indeed, that is one of the things that I think is very wise to avoid, as it has caused significant problems in the past, most recently for example with SHA1 / SHA-256 transition.  The entire point of including multiple signatures with different algorithms is to avoid the need to have separate hierarchies for the old and new ways of doing things.  

 

There seem to be some assumptions built into your list of problems that I think are important to unpack, discuss, and resolve first.

 

-Tim

 

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Jim Schaad
Sent: Saturday, September 22, 2018 12:18 AM
To: 'Panos Kampanakis (pkampana)' <pkampana@cisco.com>
Cc: spasm@ietf.org
Subject: Re: [lamps] Double signatures

 

Panos,

 

Without a really detailed analysis of your proposal and how it will interact with existing code I could not possibly support it.   A quick list of problems that I would list (without thought) are:

 

1.	Historically, lots of people cannot get DER encoding correct.  Peter Gutmann has a huge collection of certificates that were issued by CAs that were not correctly DER encoded.  
2.	Everybody who wants to support PQ algorithms is now required to add a DER encoder to their systems.  For things which only consume certificates, crls, cms objects this means that they now have enlarged code size.
3.	I have no idea what the rules are for matching CRLs and certificates in terms of signature algorithms, I would assume that you need the same protections for CRLs.
4.	You are not signing the alt signature algorithm as part of the TBS (easy to fix)
5.	How are the certificates for the issuer setup?  Are there separate certificates or the same certificate?
6.	Just how badly does this affect the path building code as it now needs to be modified to have additional inputs.
7.	Do you want to change the AKI field to make chain building better or are you going to cause non-supporting systems to potentially start downloading lots of other certificates as well.  
8.	Same issues applying to CRL distribution points – it would potentially be more efficient to have separate CRLs rather than combined ones as you could not use the extension in that case.
9.	How is AIA going to work.
10.	If you require that the same algorithms be used, what happens with OCSP responses and delegated CRL issuers?’

 

 

Jim

 

 

From: Panos Kampanakis (pkampana) <pkampana@cisco.com <mailto:pkampana@cisco.com> > 
Sent: Friday, September 21, 2018 8:08 PM
To: Dr. Pala <madwolf@openca.org <mailto:madwolf@openca.org> >; Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> >
Cc: spasm@ietf.org <mailto:spasm@ietf.org> 
Subject: RE: [lamps] Double signatures

 

Hi Max, Jim,

 

Agreed. In summary, there are too good proposals (Erik, Max’s) that can combine multiple PKs and Sigs. That would allow us to us more than one PQ algos if they are not trusted. 

 

draft-truskovsky-lamps-pq-hybrid allows for backwards compatibility by defining one only PQ key and sig as non-critical extensions.

 

I wonder if the two concepts could be merged. Meaning use the composite key + sigs can non-critical extensions. Old clients disregard the PQ extensions. New clients verify the classical  and the PQ algos defined in the composite OID contained in the non-critical extension.

 

Panos

 

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Dr. Pala
Sent: Thursday, September 20, 2018 1:44 PM
To: spasm@ietf.org <mailto:spasm@ietf.org> 
Subject: Re: [lamps] Double signatures

 

Hi Panos, all,

that is correct - since the new OIDs for the Key and the Signatures would be new, clients would fail since they do not know the "composite" algorithm :D

Although developing support for it should not be too difficult, the solution it is not meant to be backward compatible as we want applications to be able to fail if they do not even know they were supposed to generate or verify multiple signatures instead of just one.

>From a usage perspective, I am leaning towards the need for the owner of the certificates to generate signatures with all the keys, and for the entity that validates the signatures it should validate all the signatures it supports and may accept signatures even if it does not understand all the algorithms (this is more an application decision based on the risk and threat model).

As I said, this solution fits not only certificates, but also OCSP responses, CRLs, CMS, PKCS#7, etc. and that is part of what is interesting for us :D I still need to check what are the needed changes for other formats like PKCS#1/#8/#12 for storing the composite public and private keys (this part still missing), but I hope that solving that part will not be too difficult...

Cheers,
Max

 

On 9/20/18 7:26 AM, Panos Kampanakis (pkampana) wrote:

Hi Max,

To rephrase Eric’s question, would the CompositeKey+CompositeSig proposal be backwards compatible with existing systems?

I mean it gives you the change to use more than one algos in case you don’t trust all of them. But an old client wouldn’t be able to just use the traditional key+sig unless he was upgraded to understand CompositeKey+CompositeSig and its OIDs, right?

Panos

 

From: Spasm [ <mailto:spasm-bounces@ietf.org> mailto:spasm-bounces@ietf.org] On Behalf Of Erik Andersen
Sent: Friday, September 14, 2018 11:49 AM
To: 'SPASM'  <mailto:spasm@ietf.org> <spasm@ietf.org>; Directory list  <mailto:x500standard@freelists.org> <x500standard@freelists.org>
Subject: Re: [lamps] Double signatures

 

The double signature is intended as a migration tool.

 

In the normal operation, only one signature is used (the native signature). When it is realized that the signature algorithm will be too week i some future, the migration period starts and an alternative, assuming stronger signature is provided for those able to handle it.  Legacy systems will ignore this alternative signature. After the migration period, there will be no alternative signature and the new stronger signature will be the native signature.

 

Does that make sense?

 

Erik

 

Fra: Massimiliano Pala [ <mailto:m.pala@cablelabs.com> mailto:m.pala@cablelabs.com] 
Sendt: 12 September 2018 23:01
Til: Russ Housley < <mailto:housley@vigilsec.com> housley@vigilsec.com>
Cc: SPASM < <mailto:spasm@ietf.org> spasm@ietf.org>; Erik Andersen < <mailto:era@x500.eu> era@x500.eu>
Emne: Re: [lamps] Double signatures

 

Hi Russ, all,

my personal position is that the signer MUST use all the keys that have digitalSignature set, the verifier shall verify all the signatures for which it does have support for.

The rationale for this is that if I certify a public key in the certificate, you should be able to use the private key to generate the signature, therefore the approach is the same as usual: sign with your key. In this case, it just happens that to generate the signature you have to generate multiple ones and then combine them together.

For the application that verifies those signatures, it is always a question of what is the threshold that is acceptable for the application (in terms of risk) in case it does not support all of the algorithms that are used to generate the composite signature. Ideally it would verify all, but it may decide to verify less (at least one).

I also saw the other e-mail from Jim on this topic and I think it could be a good idea - the use of the two OIDs is another way to go to codify the validation process required. Technically, that makes sense to me, however I am conflicted as this approach requires that the signer has an understanding of what the verifier's capabilities are... I think that defining two OIDs for the signatures could still be useful because the signer might then decide the "recommended"/"intended" verification behavior... I can see some use-cases that might have a composite key with { RSA, EC } and the "Must-Verify-All" OID for the signature, and another use-case where we have a composite key with { RSA, HASH-BASED } and for the signature "Must-Verify-At-Least-One".

Does this make sense?

Cheers,
Max

 

On 9/12/18 6:12 AM, Russ Housley wrote:

Max: 

 

During a transition to quantum-resistant signatures, a signer wants to put a traditional signature and a quantum-resistant signature on an object.  Given your description of keyUsage and extendedKeyUsage, both would have the digitalSignature bit set.  How does a client know if just one or both signatures must be valid?

 

As Jim Schaad already said, RFC 5752 talks about this issue when a CMS SignedData contains more than one SignerInfo.

 

Russ

 

 

On Sep 11, 2018, at 4:45 PM, Max Pala < <mailto:M.Pala@cablelabs.com> M.Pala@cablelabs.com> wrote:

 

Hi All, 

 

I am working on a similar - but different - solution, in particular I solve the issue of (a) being able to combine more than one public key, (b) only one (actually two) OIDs required, and (c) simply the processing by re-utilizing the same data structures we have today.

 

I particular, I define a “composite public key” and “composite signature”.

 

The first one encodes in the key value’s BITSTRING the DER value of the SEQUENCE of public keys (each of which is a the subjectPublicKeyInfo structure) and uses a specific OID that identifies the public key type. The parameters of the compositeKey algorithm can be used to encode the keyUsage and the extendedKeyUsage for each of the keys in the composite key.

 

The same approach is used for the “Composite Signature” case where the value of the signature is the DER representation of the SEQUENCE of signatures made with each of the keys.

 

As soon as I have some spare time, I will submit the draft - maybe this could be discussed in Bangkok?

 

This simple idea allows us to have all the other procedures related to PKIs work - this means we can combine ECC with RSA or with a Quantum-Resistant algorithm (when finally available and standardized). A step forward for the deployment of hybrid-PKIs where multiple Lagos for keys can be used to authenticate data, certs, revocation data, etc... we plan to use this in our infrastructures to provide a transitional path for post-Quantum transition and to further improve the algorithm-agility capability of PKIs.

 

What do you think?

 

Cheers, 

Max

 

 

--- 

 

Cheers, 

Max

On Sep 11, 2018, at 8:38 AM, Tim Hollebeek < <mailto:tim.hollebeek@digicert.com> tim.hollebeek@digicert.com> wrote:

Unfortunately, “not every combination needs to be covered” introduces a lot of politics around choosing which combinations “need to be covered”, a subject on which inevitably not everyone agrees.  I would rather avoid all those discussions and the unnecessary work they represent.

 

I personally don’t think a single AlgID which implies a SEQUENCE of ALG IDs is an improvement over a SEQUENCE of ALG IDs, or its moral equivalent.  For simple hybrid use cases, there is also a lot of value in having the classical algorithm ID being the same as it usually is, to allow easier interoperability with older systems that don’t understand the newer algorithms (and can blissfully ignore them).

 

-Tim

 

From: Santosh Chokhani < <mailto:santosh.chokhani@gmail.com> santosh.chokhani@gmail.com> 
Sent: Tuesday, September 11, 2018 10:29 AM
To: Tim Hollebeek < <mailto:tim.hollebeek@digicert.com> tim.hollebeek@digicert.com>; 'Erik Andersen' < <mailto:era@x500.eu> era@x500.eu>; 'SPASM' < <mailto:spasm@ietf.org> spasm@ietf.org>;  <mailto:x500standard@freelists.org> x500standard@freelists.org
Subject: RE: [lamps] Double signatures

 

Thanks Tim.

 

There are ways to accommodate your concern.

 

One way to handle this is defining a single Alg ID A which implies a SEQUENCE of ALG IDs and define the relying party rules in terms of its ability to process one or all ALG IDs.

 

Another way to do this is not every combination needs to be covered and the user community defines its own  Alg ID Xi which maps to a SEQUENCE of ALG IDs.

 

From: Spasm [ <mailto:spasm-bounces@ietf.org> mailto:spasm-bounces@ietf.org] On Behalf Of Tim Hollebeek
Sent: Tuesday, September 11, 2018 10:03 AM
To: Erik Andersen < <mailto:era@x500.eu> era@x500.eu>; 'SPASM' < <mailto:spasm@ietf.org> spasm@ietf.org>;  <mailto:x500standard@freelists.org> x500standard@freelists.org
Subject: Re: [lamps] Double signatures

 

Doesn’t the combinatoric explosion render this completely impractical?

 

You need N_c x N_pq algorithm identifiers just to handle the simple hybrid use case where a single classical algorithm is being used in conjunction with a single post-quantum algorithm.

 

And there are people who want to use multiple post-quantum algorithms to hedge against potential yet to be discovered weaknesses in post-quantum algorithms.

 

I’m not really looking forward to trying to allocate or manage O(N_c x N_pq^3) algorithm identifiers…

 

-Tim

 

From: Spasm < <mailto:spasm-bounces@ietf.org> spasm-bounces@ietf.org> On Behalf Of Erik Andersen
Sent: Tuesday, September 11, 2018 3:10 AM
To: 'SPASM' < <mailto:spasm@ietf.org> spasm@ietf.org>;  <mailto:x500standard@freelists.org> x500standard@freelists.org
Subject: Re: [lamps] Double signatures

 

Hi Santosh,

 

You have proposed something like this before. It still puzzling in my brain. As I understand, it requires that we define a particular algorithm that has a parameter that includes the things you suggest. It is worthy to be analysed.

 

Erik

 

Fra: Spasm [ <mailto:spasm-bounces@ietf.org> mailto:spasm-bounces@ietf.org] På vegne af Santosh Chokhani
Sendt: 10 September 2018 19:18
Til: 'Jim Schaad' < <mailto:ietf@augustcellars.com> ietf@augustcellars.com>; 'Ryan Sleevi' < <mailto:ryan-ietf@sleevi.com> ryan-ietf@sleevi.com>;  <mailto:era@x500.eu> era@x500.eu
Cc: 'SPASM' < <mailto:spasm@ietf.org> spasm@ietf.org>;  <mailto:x500standard@freelists.org> x500standard@freelists.org
Emne: Re: [lamps] Double signatures

 

Why not let algorithm identifier dictate the number of signatures and their syntax?

 

From: Spasm [ <mailto:spasm-bounces@ietf.org> mailto:spasm-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Monday, September 10, 2018 1:07 PM
To: 'Ryan Sleevi' < <mailto:ryan-ietf@sleevi.com> ryan-ietf@sleevi.com>;  <mailto:era@x500.eu> era@x500.eu
Cc: 'SPASM' < <mailto:spasm@ietf.org> spasm@ietf.org>;  <mailto:x500standard@freelists.org> x500standard@freelists.org
Subject: Re: [lamps] Double signatures

 

Ryan,

 

The discussion in London dealt with a completely different proposal than this one.  While I think there are problems with this that need to be dealt with they are mostly not the same set.

 

Erik,

 

Why is this considered to be a preferred solution to defining a new signature algorithm which contains as the parameter the sequence of algorithm identifiers and as the signature value a sequence of signature values.  The problem with just defining the extension to SIGNED is that one needs to make sure that the set of signature algorithms and parameters are also part of the data to be signed and I am not seeing that highlighted here.

 

Jim

 

 

From: Spasm < <mailto:spasm-bounces@ietf.org> spasm-bounces@ietf.org> On Behalf Of Ryan Sleevi
Sent: Monday, September 10, 2018 8:53 AM
To:  <mailto:era@x500.eu> era@x500.eu
Cc: SPASM < <mailto:spasm@ietf.org> spasm@ietf.org>;  <mailto:x500standard@freelists.org> x500standard@freelists.org
Subject: Re: [lamps] Double signatures

 

 

On Mon, Sep 10, 2018 at 10:56 AM Erik Andersen < <mailto:era@x500.eu> era@x500.eu> wrote:

Hi Folk,

 

In ITU-T we have plans to allow for double signatures using the SIGNED parametrized data type defined in X.509 to cope with situation as described in the internet draft: “Multiple Public-Key Algorithm X.509 Certificates (draft-truskovsky-lamps-pq-hybrid-x509-01)”

 

We suggest to enhance the SIGNED data type as shown below:

 

SIGNED{ToBeSigned} ::= SEQUENCE {

  COMPONENTS OF SIGNATURE,

  ........,

  altAlgorithmIdentifier  AlgorithmIdentifier{{SupportedAlgorithms}} OPTIONAL,

  altSignature            BIT STRING OPTIONAL 

  } (WITH COMPONENTS {..., altAlgorithmIdentifier PRESENT, altSignature PRESENT } |

     WITH COMPONENTS {..., altAlgorithmIdentifier ABSENT,  altSignature ABSENT } )

 

We are open to comments. We know that IETF is not a heavy user of this data type.

 

We have no intention to use this extended data type for certificates and CRLs.

 

For your information, SIGNATURE is defined as:

 

SIGNATURE ::= SEQUENCE {

  algorithmIdentifier  AlgorithmIdentifier{{SupportedAlgorithms}},

  signature            BIT STRING,

  ....... }

 

>From the discussions in London (101), there were a number of challenges identified during the discussion -  <https://datatracker.ietf.org/meeting/101/materials/minutes-101-lamps-01.txt> https://datatracker.ietf.org/meeting/101/materials/minutes-101-lamps-01.txt - that fundamentally questioned that approach.

 

Has the ITU-T addressed or resolved those concerns? Are they not applicable for some reason specific to ITU-T? 

_______________________________________________
Spasm mailing list
 <mailto:Spasm@ietf.org> Spasm@ietf.org
 <https://www.ietf.org/mailman/listinfo/spasm> https://www.ietf.org/mailman/listinfo/spasm

 

 

-- 

Best Regards, 

Massimiliano Pala, Ph.D.


Principal Architect
Security Services, R&D

 

_______________________________________________
Spasm mailing list
Spasm@ietf.org <mailto:Spasm@ietf.org> 
https://www.ietf.org/mailman/listinfo/spasm