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 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 550BFC433DB for ; Thu, 14 Jan 2021 03:24:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 11002236F9 for ; Thu, 14 Jan 2021 03:24:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726725AbhANDXv (ORCPT ); Wed, 13 Jan 2021 22:23:51 -0500 Received: from mail.kernel.org ([198.145.29.99]:55422 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726492AbhANDXu (ORCPT ); Wed, 13 Jan 2021 22:23:50 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3ABE1235FA; Thu, 14 Jan 2021 03:23:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610594590; bh=AdcW8UhVJhhFDlGMLak6Qruj8jmCq+3ZBF4Jpcb8v+E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZFVfHnGtzuIzqvrNZv5WC0SLEQbzCz+RlzzLTZfwWxyF43NMrmHGG4hdYxGauCJgg CizmelI1Rgm5Zf4UdR0weUaLM8xiSWP1IGaG5Rgf4El0Kw8l6Ga49ChekeLUZ1A5Ku lTJLepQS8otGEXCp4WpVnVMfPXbX+JRITFFWviAytd019TxFM79vcxrMXzKUeyPzG2 r91YlPx7jOD85NEg89zhqGiUiisvMfN20S8EqOxALI/5IWQOU581utuom9cfTmhtM1 /HeEJRLlOWJg9EOMcl9kHZ93bxhHtIvAD4Z3lrClb29afDZuwM2H2aUDswvPUU5zfo GyhQ6SvLJa6Ng== Date: Thu, 14 Jan 2021 05:23:06 +0200 From: Jarkko Sakkinen To: Andrew Zaborowski , konstantin@linuxfoundation.org, David Howells Cc: keyrings@vger.kernel.org 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.) > > 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 David, Konstantin, any ideas why the patchwork is jammed, and how to get it up and running again. https://patchwork.kernel.org/project/keyrings/list/ I mainly would like to have it working because of git-pw, which is really nice tool for applying patches for testing. /Jarkko