Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02

"Kampanakis, Panos" <kpanos@amazon.com> Fri, 27 January 2023 03:16 UTC

Return-Path: <prvs=3849a73bc=kpanos@amazon.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 967E4C157902 for <spasm@ietfa.amsl.com>; Thu, 26 Jan 2023 19:16:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.597
X-Spam-Level:
X-Spam-Status: No, score=-14.597 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_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 h_7VkzLEftgC for <spasm@ietfa.amsl.com>; Thu, 26 Jan 2023 19:16:28 -0800 (PST)
Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (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 099EBC1526FF for <spasm@ietf.org>; Thu, 26 Jan 2023 19:16:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1674789388; x=1706325388; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=7/S2fb60w2c8RpPN9DmyQSDgnYWeUDUGcUrvcFOtvJ0=; b=fB8NVmrHmpFiX7DtZ30+zCVBk+CS35LzSnydTl6HpDMuHbQrtLcyNnhV D6h5tQ88eptRtNYvgsUJfHvnceXW2DJT3Q8Zd+vyXZYP8wQpMK4mUphQk N51ZdOOsTwVbZwFC/ZE0aCgB6bTlwUq017K9FqbE3CO0dlckLF6yCfykX 0=;
X-IronPort-AV: E=Sophos;i="5.97,249,1669075200"; d="scan'208,217";a="286968762"
Thread-Topic: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02
Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-iad-1d-m6i4x-153b24bc.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-2101.iad2.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2023 03:16:15 +0000
Received: from EX13MTAUWB001.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan3.iad.amazon.com [10.40.163.38]) by email-inbound-relay-iad-1d-m6i4x-153b24bc.us-east-1.amazon.com (Postfix) with ESMTPS id 52652C1406; Fri, 27 Jan 2023 03:16:14 +0000 (UTC)
Received: from EX19D001ANA001.ant.amazon.com (10.37.240.156) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1497.45; Fri, 27 Jan 2023 03:16:12 +0000
Received: from EX19D001ANA001.ant.amazon.com (10.37.240.156) by EX19D001ANA001.ant.amazon.com (10.37.240.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1118.7; Fri, 27 Jan 2023 03:16:11 +0000
Received: from EX19D001ANA001.ant.amazon.com ([fe80::4f78:75cd:3117:8055]) by EX19D001ANA001.ant.amazon.com ([fe80::4f78:75cd:3117:8055%5]) with mapi id 15.02.1118.020; Fri, 27 Jan 2023 03:16:11 +0000
From: "Kampanakis, Panos" <kpanos@amazon.com>
To: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>, Santosh Chokhani <santosh.chokhani@gmail.com>, "spasm@ietf.org" <spasm@ietf.org>
Thread-Index: AQHZJRpl3+6nvML+yESqtOBhZMbX8K6QvH2AgAc1PYCAAJhKAIAAtdOAgAAVJ4CADN8NAIAAGLAAgAFL30CABnF9x///+nXggANYbACAAAYUgIAACzAAgAA7tnA=
Date: Fri, 27 Jan 2023 03:16:11 +0000
Message-ID: <03431b620048477182c5169f03665617@amazon.com>
References: <PH0PR00MB10003EC6A096FE0A363BBFB9F5459@PH0PR00MB1000.namprd00.prod.outlook.com> <PH0PR00MB10002A7A2850A1333B4F6C00F54A9@PH0PR00MB1000.namprd00.prod.outlook.com> <35BEB1D9-7EA5-4CD4-BADA-88CCB0E9E8F9@vigilsec.com> <6FB4E76C-0AFD-4D00-B0FC-63F244510530@vigilsec.com> <bd5a491c78c8406b8de6414aff4f5223@amazon.com> <SA0PR09MB72412D6BBBC556716B5FBDEDF1FF9@SA0PR09MB7241.namprd09.prod.outlook.com> <adfdcfcfb0f84c63b83bc60cb9a48cfa@amazon.com> <CH0PR11MB573917AD78637794B2A424249FFC9@CH0PR11MB5739.namprd11.prod.outlook.com> <ca14b6a4dc624d5a8721a76fba0e0b2f@amazon.com> <SJ0PR14MB5489CD14C3163F8DA79E948A83C49@SJ0PR14MB5489.namprd14.prod.outlook.com> <ee73c65cc85c4f2d82b6f6c444ae1ad5@amazon.com> <PH8PR09MB9294D762B0934D9746A1DEFCFCC59@PH8PR09MB9294.namprd09.prod.outlook.com> <SA0PR09MB7241E7948D0A08850295FF93F1C99@SA0PR09MB7241.namprd09.prod.outlook.com> <fde38c18356148d5bbcb26e2e3857f96@amazon.com> <0d0c01d931d3$977d1dc0$c6775940$@gmail.com> <DS7PR12MB59832EB5498E6AADF915DF26AACF9@DS7PR12MB5983.namprd12.prod.outlook.com> <CH0PR11MB573983C0342556E12BC5E33F9FCF9@CH0PR11MB5739.namprd11.prod.outlook.com>
In-Reply-To: <CH0PR11MB573983C0342556E12BC5E33F9FCF9@CH0PR11MB5739.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.37.240.200]
Content-Type: multipart/alternative; boundary="_000_03431b620048477182c5169f03665617amazoncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/Xadn17VhR1HWLcz6fEM3jeVqxwA>
Subject: Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 27 Jan 2023 03:16:30 -0000

You are proposing that two different identities can be deduced to be the same because at issuance one of the identities proved to own both keys. That is a redefinition of PKI and potentially dangerous. As a verifier, I am only talking to one identity at a time. So if my peer gives me two certs, they better be issued to the same identity I am talking to or I will fail authentication. As a CA issuing two certs to two different identities, I would be uncomfortable if I knew that cert X was validated by a verifier just because cert Y was related to it and the identity in Cert Y was correct.


From: Spasm <spasm-bounces@ietf.org> On Behalf Of Mike Ounsworth
Sent: Thursday, January 26, 2023 6:17 PM
To: Michael Markowitz <markowitz=40infoseccorp.com@dmarc.ietf.org>; Santosh Chokhani <santosh.chokhani@gmail.com>; spasm@ietf.org
Subject: RE: [EXTERNAL][lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


At the risk of getting baited into a religious war, when it comes to statements of “these two things are related”, the definition of “weak” is relative.


Name matching proves that the two keys are owned by the same entity, for some potentially weak definition of “same entity”, depending on how the PKI is operated. For example I have a driver’s license and a health card, but they are not really “connected”.

Simultaneous proof-of-possession or usage of two private keys proves that they exist together, accessible by the end entity at the same time. If I present my health driver’s license and health card together at the same time, then they start to be connected.

If the issuer validates PoP of both keys at issuance time and cross-links the two keys (via some sort of X.509 extension), then you have you have a statement from the authority which is “stronger” than name alone that these two specific certs are a pair. Like if my driver’s license and health card were issued on the same day with the same photo and have matching serial numbers.

Bonus points if you have key attestations for both keys proving that they live in the same piece of hardware. The same piece of plastic serves as driver’s license and health card.

When it comes to statements of “these two things are related”, the definition of “weak” is relative.

---
Mike Ounsworth

From: Spasm <spasm-bounces@ietf.org<mailto:spasm-bounces@ietf.org>> On Behalf Of Michael Markowitz
Sent: Thursday, January 26, 2023 4:36 PM
To: Santosh Chokhani <santosh.chokhani@gmail.com<mailto:santosh.chokhani@gmail.com>>; spasm@ietf.org<mailto:spasm@ietf.org>
Subject: [EXTERNAL] Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Santosh wrote:

>If the authors have not already done so, I would propose that there are ways the extension can provide crypto binding between/among the certificates which would be superior to simply name >matching.  Name matching is weak.

If you’re claiming *notarized* name matching is weak, I think we have to throw out the whole concept of X.509 certificates!  😊

-mjm
Any email and files/attachments transmitted with it are confidential and 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.