Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8140422

Add mechanism to allow non default root CAs to be not subject to algorithm restrictions

    Details

    • Subcomponent:
    • Resolved In Build:
      b117
    • Verification:
      Verified

      Backports

        Description

        We should provide a mechanism or option to distinguish certificates that chain to the default root CAs that are included in the cacerts file in the JRE from those that are added subsequently or otherwise not in the default set (e.g., private CAs used within an enterprise) when enforcing the algorithm restrictions in the jdk.certpath.disabledAlgorithms security property.

        This allows certificates that are issued by private CAs to be treated differently with respect to algorithm restrictions. These CAs may not yet be compliant with standard recommendations on weak algorithms and/or may need more time to conform to the restrictions.

          Issue Links

            Activity

            Hide
            mullan Sean Mullan added a comment - - edited
            When enforcing constraints via the CertPath API, the PKIX implementation is provided with the certificate chain, and a set of trust anchors. It does not necessarily know if the trust anchor (or root CA) is public or non-public, or it may not know the keystore they came from (the caller can specify the anchors as a Set<TrustAnchor> or a KeyStore).

            We need a mechanism that allows us to check if the anchor is a root CA that is included in the cacerts file shipped with the JDK.

            Additionally, we need to add an option (e.g. jdkCA) to the jdk.certpath.disabledAlgorithms property to toggle this behavior, e.g.:

            jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA

            This would mean the constraints for MD2 and MD5 are applied to all certs but for SHA-1 they are only applied to certs chaining back to the default set of cacerts in the JDK (it does not include any that are subsequently added to cacerts by a user/admin).
            Show
            mullan Sean Mullan added a comment - - edited When enforcing constraints via the CertPath API, the PKIX implementation is provided with the certificate chain, and a set of trust anchors. It does not necessarily know if the trust anchor (or root CA) is public or non-public, or it may not know the keystore they came from (the caller can specify the anchors as a Set<TrustAnchor> or a KeyStore). We need a mechanism that allows us to check if the anchor is a root CA that is included in the cacerts file shipped with the JDK. Additionally, we need to add an option (e.g. jdkCA) to the jdk.certpath.disabledAlgorithms property to toggle this behavior, e.g.: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA This would mean the constraints for MD2 and MD5 are applied to all certs but for SHA-1 they are only applied to certs chaining back to the default set of cacerts in the JDK (it does not include any that are subsequently added to cacerts by a user/admin).
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8fc301b7b8f8
            User: ascarpino
            Date: 2016-05-03 00:06:22 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8fc301b7b8f8 User: ascarpino Date: 2016-05-03 00:06:22 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8fc301b7b8f8
            User: lana
            Date: 2016-05-04 18:39:50 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8fc301b7b8f8 User: lana Date: 2016-05-04 18:39:50 +0000
            Hide
            afomin Alexander Fomin (Inactive) added a comment -
            UR SQE OK to take the enhancement to CPU17_01
            Show
            afomin Alexander Fomin (Inactive) added a comment - UR SQE OK to take the enhancement to CPU17_01

              People

              • Assignee:
                ascarpino Anthony Scarpino
                Reporter:
                mullan Sean Mullan
              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Due:
                  Created:
                  Updated:
                  Resolved: