RFR: 8317431: Implement simpler Comparator when building certification paths [v2]

[Sean Mullan]

On Thu, 11 Jan 2024 14:09:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This enhancement simplifies and improves the performance of the Comparator that the PKIX CertPathBuilder uses to sort candidate certificates.
>> 
>> [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.1) requires that certificates include authority and subject key identifiers to facilitate cert path discovery. When the certificates comply with RFC 5280, the sorting algorithm is fast and efficient. However, there may be cases where certificates do not include the proper KIDs, for legacy or other reasons. This enhancement targets those cases and has shown an increase in performance of `CertPathBuilder.build` by up to 2x in tests involving certificates that do not contain KIDs. Specific changes include:
>> 
>> - Removed and simplified some of the steps in `PKIXCertComparator.compare` method. Some of these steps were not a good representation of common certificate hierarchies and were overly expensive to perform. 
>> - Several methods in `X500Name` and `Builder` have been made obsolete and thus removed.
>> - `X500Name` has been changed to use shared secrets instead of reflection to access non-public members of `X500Principal`, and vice-versa.
>> - The `CertificateBuilder` test code has been enhanced to set reasonable defaults for serial number and validity fields of a certificate
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more comments. Remove unnecessary import.

Some additional information on this fix for future reference. I removed 3 steps from the Comparator:

     * 3) Issuer is a descendant of a trusted subject (in order of
     *    number of links to the trusted subject)
     *    a) Issuer: ou=E,ou=D,ou=C,o=B,c=A        [links=1]
     *    b) Issuer: ou=F,ou=E,ou=D,ou=C,ou=B,c=A  [links=2]
     *
     * 4) Issuer is an ancestor of a trusted subject (in order of number of
     *    links to the trusted subject)
     *    a) Issuer: ou=C,o=B,c=A [links=1]
     *    b) Issuer: o=B,c=A      [links=2]
     ...
     * 6) Issuer is an ancestor of certificate subject (in order of number
     *    of links to the certificate subject)
     *    a) Issuer:  ou=K,o=J,c=A
     *       Subject: ou=L,ou=K,o=J,c=A
     *    b) Issuer:  o=J,c=A
     *       Subject: ou=L,ou=K,0=J,c=A
     
These steps were removed because it assumes the PKI hierarchy is very rigid, and each intermediate CA is a direct child of it's parent in the DN namespace. More commonly, there is some structure, but not so exact.  For example, a CA with a subject DN of “CN=Root CA, O=OpenJDK, C=US” may issue a certificate to a sub-CA named “CN=JDK  CA, OU=JDK, O=OpenJDK, C=US”. Here the subCA is not a direct descendant of the root CA, but they both share a common namespace of "O=OpenJDK, C=US" (which will be found by step 5 which was retained).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17248#issuecomment-1887289722