`CertPathValidatorUtilities.findIssuerCerts` eliminates certificates by AKID / SKID match

[Philosobyte]

RFC 4158 states that Subject Key Identifiers and Authority Key Identifiers may not be used to eliminate certificates. Here is the relevant blurb:

[3.5.12] Matching Key Identifiers (KIDs)

   May be used to eliminate certificates:  No
...

NOTE:  Although required to be present by [[RFC3280](https://www.rfc-editor.org/rfc/rfc3280)], it is extremely
   important that KIDs be used only as sorting criteria or as hints
   during certification path building.  KIDs are not required to match
   during certification path validation and cannot be used to eliminate
   certificates.  This is of critical importance for interoperating
   across domains and multi-vendor implementations where the KIDs may
   not be calculated in the same fashion.

found at: https://www.rfc-editor.org/rfc/rfc4158.html

However, various CertPathValidatorUtilities.findIssuerCerts copies I can see in this repo, as well as org.bouncycastle.jcajce.provider.CertPathValidatorUtilities in bc-fips:2.1.1, contain this block of code which eventually leads to the elimination of certificates where AKIDs and SKIDs don't match:

        try
        {
            byte[] akiExtensionValue = cert.getExtensionValue(AUTHORITY_KEY_IDENTIFIER);
            if (akiExtensionValue != null)
            {
                ASN1OctetString aki = ASN1OctetString.getInstance(akiExtensionValue);
                byte[] authorityKeyIdentifier = AuthorityKeyIdentifier.getInstance(aki.getOctets()).getKeyIdentifier();
                if (authorityKeyIdentifier != null)
                {
                    selector.setSubjectKeyIdentifier(new DEROctetString(authorityKeyIdentifier).getEncoded());
                }
            }
        }

The consequence of this is, if an end-entity certificate contains an AKID, and an intermediate certificate contains a non-matching SKID, then the intermediate certificate gets eliminated and the chain becomes untrusted.

Is this intended behavior? Why does it not match RFC 4158?

[Philosobyte]

A followup question: would the runtime behavior of BouncyCastle still be considered FIPS-compliant if org.bouncycastle.pkix.disable_certpath is set to true? Elimination does not occur when that property is set to true.

[dghgit]

Yes, it's still FIPS compliant with org.bouncycastle.pkix.disable_certpath set to true. The CertPath API outsources all the cryptography to the associated providers, so it'll still use the FIPS provider for signature verification and the like.

[dghgit]

I'm pretty sure you're correct, it's possible RFC 5280 "improved" on the recommendation, but it's obviously not the case. This will be fixed in 1.82 and 2.1.2 (as well as the other FIPS providers as we get to them). Thanks for the report.

[Philosobyte]

I'm pretty sure you're correct, it's possible RFC 5280 "improved" on the recommendation, but it's obviously not the case. This will be fixed in 1.82 and 2.1.2 (as well as the other FIPS providers as we get to them). Thanks for the report.

Hmm, it looks like RFC 5280 does mention conforming CA certs must issue certs where AKIDs and SKIDs match, but...

4.2.1.2.  Subject Key Identifier

...
   In conforming CA certificates, the value of the subject key 
   identifier MUST be the value placed in the key identifier
   field of the authority key identifier extension (Section 4.2.1.1) of
   certificates issued by the subject of this certificate.  Applications
   are not required to verify that key identifiers match when performing
   certification path validation.

Section 6.1 later recommends against implementing checks during path validation:

6.1. Basic Path Validation

...
   While the algorithm could be extended to include checks for
   conformance to the profiles in Sections 4 and 5, this profile
   RECOMMENDS against including such checks. 

Thank you for your confirmation and the upcoming fixes!

[dghgit]

Fixed in 1.82.