Re: [PATCH] keys: X.509 public key issuer lookup without AKID

[Jarkko Sakkinen <jarkko@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 <andrew.zaborowski@intel.com>

"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