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 F0C89C433DB for ; Thu, 14 Jan 2021 03:49:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AD26623877 for ; Thu, 14 Jan 2021 03:49:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726962AbhANDse (ORCPT ); Wed, 13 Jan 2021 22:48:34 -0500 Received: from mail.kernel.org ([198.145.29.99]:58702 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726904AbhANDsb (ORCPT ); Wed, 13 Jan 2021 22:48:31 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3AFA323770; Thu, 14 Jan 2021 03:47:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610596071; bh=acNzLuwOVq0Llr++4g4WBrQ/elkfDo1DKgeRtWtsGeA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YjkzeTJrC5e1vaZJff9GHluwwm67D+cTIN7ReiIXvPYq4Lgf3ynuiViY5P+EWdj/X D/mSSLXvu5d6sI1IfFUfZUviUFkjLsEzyE1/sxz5gqCxib8RX/r6d0mp9S3xcnxmLF LIJIcwDzTEI07pWaNKQ3N8KReApgPfTZ5vbHEsFTh+ulfMJrituK1OpjruC9hjuZCR pCjSsaEENQWL65RwMsuJO02nWviHLPpIeij81V3b1lb0mUiyF2QKSxGWVkN94JwuLF 5/wCNMmwOAWolVnZZ7JqUyC/wfy9Tn8UuWWpwC8qYQZZ1M+3oaxKK+O4CRlnrxFDjH QznjL868A+wfg== Date: Thu, 14 Jan 2021 05:47:46 +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: <20210113142340.1963770-1-andrew.zaborowski@intel.com> Precedence: bulk List-ID: X-Mailing-List: keyrings@vger.kernel.org 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. /Jarkko