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

"Kampanakis, Panos" <kpanos@amazon.com> Fri, 27 January 2023 16:57 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 857EBC14F747 for <spasm@ietfa.amsl.com>; Fri, 27 Jan 2023 08:57:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.3
X-Spam-Level:
X-Spam-Status: No, score=-10.3 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=unavailable 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 JskoR1bnX5ZP for <spasm@ietfa.amsl.com>; Fri, 27 Jan 2023 08:57:35 -0800 (PST)
Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (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 D7110C14F693 for <spasm@ietf.org>; Fri, 27 Jan 2023 08:57:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1674838656; x=1706374656; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=/8gblgrn4lLPet+G8fDpInvXw1FJ3grOPEst7V94ASM=; b=d11KZ73ZK966ln3A9rDLBJFzziHftpApbNI9jHIek1/QhSTLXOwl6REe ibRsOTvTOqS73Ao7mXK/5i1PumsN2z2ip/CZpt+RXZ1Rm9OsjIh05XiYV 9uUxjYtfIJxjL/82V22UazcCZi4+I/vxUg8aPi1OWkUdZsNdmBic3GMTe s=;
X-IronPort-AV: E=Sophos;i="5.97,251,1669075200"; d="scan'208,217";a="258311365"
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-pdx-2a-m6i4x-44b6fc51.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-33001.sea14.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2023 16:57:25 +0000
Received: from EX13MTAUWB002.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-pdx-2a-m6i4x-44b6fc51.us-west-2.amazon.com (Postfix) with ESMTPS id 56BB4A7865; Fri, 27 Jan 2023 16:57:23 +0000 (UTC)
Received: from EX19D001ANA003.ant.amazon.com (10.37.240.188) by EX13MTAUWB002.ant.amazon.com (10.43.161.202) with Microsoft SMTP Server (TLS) id 15.0.1497.45; Fri, 27 Jan 2023 16:57:22 +0000
Received: from EX19D001ANA003.ant.amazon.com (10.37.240.188) by EX19D001ANA003.ant.amazon.com (10.37.240.188) 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 16:57:21 +0000
Received: from EX19D001ANA003.ant.amazon.com ([fe80::1fb7:1432:d6f7:d435]) by EX19D001ANA003.ant.amazon.com ([fe80::1fb7:1432:d6f7:d435%5]) with mapi id 15.02.1118.020; Fri, 27 Jan 2023 16:57:21 +0000
From: "Kampanakis, Panos" <kpanos@amazon.com>
To: Tim Hollebeek <tim.hollebeek=40digicert.com@dmarc.ietf.org>, "spasm@ietf.org" <spasm@ietf.org>
Thread-Index: AQHZJRpl3+6nvML+yESqtOBhZMbX8K6QvH2AgAc1PYCAAJhKAIAAtdOAgAAVJ4CADN8NAIAAGLAAgAFL30CABnF9x///+nXggANYbACAAAYUgIAACzAAgAER2QCAAAD9EA==
Date: Fri, 27 Jan 2023 16:57:21 +0000
Message-ID: <8c86cab0a2a143b1ba437888674f163a@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> <SJ0PR14MB5489C5FC04135B4F7ED8B44C83CC9@SJ0PR14MB5489.namprd14.prod.outlook.com>
In-Reply-To: <SJ0PR14MB5489C5FC04135B4F7ED8B44C83CC9@SJ0PR14MB5489.namprd14.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.106.178.17]
Content-Type: multipart/alternative; boundary="_000_8c86cab0a2a143b1ba437888674f163aamazoncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/GBnGb3GuUb1YU-Yy-fUtbctLnPg>
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 16:57:36 -0000

Understood, but I am not saying blindly doing SubjectDN check is secure. In a double peer cert scenario, the verifier could also ensure both certs follow the same policy, for example. Other checks could be possible too.

Some have been arguing that draft-becker-guthrie-cert-binding-for-multi-auth enables the following logic for the verifier: “I am talking to Y who gave me two related certs, one for X and one for Y. Oh well, I guess I will pass cert X authentication as well because X is related to Y. It probably is the same entity”. I see that as an issue, not a benefit.

Now, if the draft said that when issuing related certs the CA needs to enforce
- there is a common identity in the certs
- there is the same cert policy,
that would be acceptable. But then the argument becomes, I can perform these checks as a verifier, why do I need the related certs extension?

I think we have beat this horse enough. If there is a scenario where using the related cert extension improves things over just doing some extra check at the verifier, please let me know.
Otherwise you can put me down as opposed and the chairs can consider all the consensus call responses and finalize the decision about the draft.


From: Spasm <spasm-bounces@ietf.org> On Behalf Of Tim Hollebeek
Sent: Friday, January 27, 2023 10:37 AM
To: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>; 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.


Here’s real world example of what can go wrong:

BetterIdentities is a CA that provides identity validation services at three levels: Low, Medium, and High.  Low is a basic documents check (simple manual inspection of presented driver’s license), Medium includes additional fraud prevention checks and correlation with official government databases, and High is based on cryptographic verification via a government issued digital credential.

BetterIdentities issues each of these identities off different intermediates, each with a policy OID indicating the verification level.

In contexts like these, blindly doing SubjectDN comparisons and declaring success is a rather bad idea.

-Tim