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

[Jarkko Sakkinen <jarkko.sakkinen@iki.fi>]

On Thu, 2021-11-04 at 14:03 +0000, David Howells wrote:
> Andrew Zaborowski <andrew.zaborowski@intel.com> wrote:
> 
> > There are non-root X.509 v3 certificates in use out there that contain
> > no Authority Key Identifier extension (RFC5280 section 4.2.1.1).  For
> > trust verification purposes the kernel asymmetric key type keeps two
> > struct asymmetric_key_id instances that the key can be looked up by,
> > and another two to look up the key's issuer.  The x509 public key type
> > and the PKCS7 type generate them from the SKID and AKID extensions in
> > the certificate.  In effect current code has no way to look up the
> > issuer certificate for verification without the AKID.
> > 
> > To remedy this, add a third asymmetric_key_id blob to the arrays in
> > both asymmetric_key_id's (for certficate subject) and in the
> > public_keys_signature's auth_ids (for issuer lookup), using just raw
> > subject and issuer DNs from the certificate.  Adapt
> > asymmetric_key_ids() and its callers to use the third ID for lookups
> > when none of the other two are available.  Attempt to keep the logic
> > intact when they are, to minimise behaviour changes.  Adapt the
> > restrict functions' NULL-checks to include that ID too.  Do not modify
> > the lookup logic in pkcs7_verify.c, the AKID extensions are still
> > required there.
> > 
> > Internally use a new "dn:" prefix to the search specifier string
> > generated for the key lookup in find_asymmetric_key().  This tells
> > asymmetric_key_match_preparse to only match the data against the raw
> > DN in the third ID and shouldn't conflict with search specifiers
> > already in use.
> > 
> > In effect implement what (2) in the struct asymmetric_key_id comment
> > (include/keys/asymmetric-type.h) is probably talking about already, so
> > do not modify that comment.  It is also how "openssl verify" looks up
> > issuer certificates without the AKID available.  Lookups by the raw
> > DN are unambiguous only provided that the CAs respect the condition in
> > RFC5280 4.2.1.1 that the AKID may only be omitted if the CA uses
> > a single signing key.
> > 
> > The following is an example of two things that this change enables.
> > A self-signed ceritficate is generated following the example from
> > https://letsencrypt.org/docs/certificates-for-localhost/, and can be
> > looked up by an identifier and verified against itself by linking to a
> > restricted keyring -- both things not possible before due to the missing
> > AKID extension:
> > 
> > $ openssl req -x509 -out localhost.crt -outform DER -keyout localhost.key \
> >   -newkey rsa:2048 -nodes -sha256 \
> >   -subj '/CN=localhost' -extensions EXT -config <( \
> >    echo -e "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\n" \
> >           "subjectAltName=DNS:localhost\nkeyUsage=digitalSignature\n" \
> >           "extendedKeyUsage=serverAuth")
> > $ keyring=`keyctl newring test @u`
> > $ trusted=`keyctl padd asymmetric trusted $keyring < localhost.crt`; \
> >   echo $trusted
> > 39726322
> > $ keyctl search $keyring asymmetric dn:3112301006035504030c096c6f63616c686f7374
> > 39726322
> > $ keyctl restrict_keyring $keyring asymmetric key_or_keyring:$trusted
> > $ keyctl padd asymmetric verified $keyring < localhost.crt
> > 
> > Signed-off-by: Andrew Zaborowski <andrew.zaborowski@intel.com>
> > Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> > ...
> > +                        * 3rd are the fallbacks. If excatly one of
> 
> "exactly".
> 
> But, apart from that:
> 
> Acked-by: David Howells <dhowells@redhat.com>

Thanks, I'll pick this up for my rc2 PR for v5.16.

/Jarkko