From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6EC2CC433E0 for ; Thu, 14 Jan 2021 03:49:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3527A23356 for ; Thu, 14 Jan 2021 03:49:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726640AbhANDt3 (ORCPT ); Wed, 13 Jan 2021 22:49:29 -0500 Received: from mail.kernel.org ([198.145.29.99]:58774 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726198AbhANDt3 (ORCPT ); Wed, 13 Jan 2021 22:49:29 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2825A23770; Thu, 14 Jan 2021 03:48:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610596129; bh=YLDxx75rtbyofQI8VmaGROQIihfZGQpBPgO+jsQ4Nbk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ie7egbdPyeTpWnv3tNw7RUAVHsEWp59Q+r80EtPtFPddqVphdsdllw1vNpQ4WWR83 47Qx1ZjUgXkg4NRSKVUj3fPXg57bFY7MbxM9FnZJ7yGqBOx4hw9QpQcwSxpfr47xgu QngwV7dopKU6+GzoVOo6LZIpX6kIo0mUF9+8cufhITV9/tsMAWa3IPhsSfJ9SQPxPq y8re2hXxh+TSImCPpw8HQ1kMUutqaS4wrKqveSGI8TUpZfC0fcmT0G/hoPaacju7Ta ZCKrZvgBfd3zNRD6RraRkavn+WGUBHsf+2eJox425GY1GdKRsy9ZUT7YWYpx/z9hI5 IGjc3sj2ua5tw== Date: Thu, 14 Jan 2021 05:48:44 +0200 From: Jarkko Sakkinen To: Andrew Zaborowski Cc: keyrings@vger.kernel.org, David Howells Subject: Re: [PATCH] keys: X.509 public key issuer lookup without AKID Message-ID: References: <20210113142340.1963770-1-andrew.zaborowski@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: keyrings@vger.kernel.org On Thu, Jan 14, 2021 at 05:47:51AM +0200, Jarkko Sakkinen wrote: > On Wed, Jan 13, 2021 at 03:23:40PM +0100, Andrew Zaborowski wrote: > > There are non-root X.509 v3 certificates in use there that contain no > > Authority Key Identifier extension (RFC5280 section 4.2.1.1) which the > > kernel asymmetric key code relies on for any lookup and verification. > > Such certificates are generated by openssl if you don't explicitly tell > > it to include the extension. > > > > Looking at RFC5280 4.2.1.1 it says: > > > > "This extension is used where an issuer has multiple signing keys [...]" > > > > making it sound like the extension is optional if the issuer uses only > > one signing key. It also says: > > > > "The keyIdentifier field of the authorityKeyIdentifier extension MUST > > be included in all certificates [...]" > > > > now making it sound like it's mandatory for everyone. It doesn't say it > > as explicitly as it does for the Subject Key Identifier extension though > > (4.2.1.2). Openssl offers no code comments explaining why neither of > > the two is included by default. It marks a certificate as V3 as soon as > > *any* extension is included. > > > > In this patch I add lookups by just the Distinguished Names in the > > certificate to handle this, I believe this is what (2) in the struct > > asymmetric_key_id (include/keys/asymmetric-type.h) talks about. I add a > > third key ID in asymmetric_key_ids and I attempt to keep the logic > > intact whenever either of the first two IDs is present in the subject > > key (the ones derived from the AKID in the case of the the x509 public > > key subtype.) > > Please use imperative form ("Add" instead of "I add"). > > > Lookups are still unambiguous provided that the CAs respect the condition > > that the AKID may only be omitted if they use a single signing key. > > I didn't apply the third ID logic to the certificate chain veritification > > in pkcs7_verify.c, the AKID extensions is still required there. > > > > Signed-off-by: Andrew Zaborowski > > "I'm not sure if these certificates are generated by > openssl with a special setting or by some other software." > > I'll give you a test case: > > https://letsencrypt.org/docs/certificates-for-localhost/ > > As can been seen: > > $ cat > get_x509_extensions.py > from OpenSSL import crypto > import sys > cert = crypto.load_certificate(crypto.FILETYPE_PEM, open(sys.argv[1]).read()) > for i in range(0, cert.get_extension_count()): > ext = cert.get_extension(i) > print(ext.get_short_name().decode('utf-8')) > > $ python3 get_x509_extensions.py localhost.crt > subjectAltName > keyUsage > extendedKeyUsage > > You could remove the discussion about whether specs allow this > or not, and just use this certificate to demonstrate it. And > focus only on details how you've implemented your solution. > > Just random example: the commit message lacks an explanation > how you've changed ID matching. I.e. you do make a case why something needs to be done, but you are lacking details on why this is the right way to sort it out. /Jarkko