JDK-8140422 : Add mechanism to allow non default root CAs to be not subject to algorithm restrictions
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-10-23
  • Updated: 2019-05-31
  • Resolved: 2016-05-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9 Other
8u152Fixed 9 b117Fixed openjdk7uFixed
Related Reports
Blocks :  
JDK-8154570 - Add algorithm constraint that specifies the restriction date
Blocks :  
JDK-8149555 - JEP 288: Disable SHA-1 Certificates
Blocks :  
JDK-8154568 - Add algorithm constraint that specifies the restriction date
Blocks :  
JDK-8154569 - Add algorithm constraint that specifies the restriction date
Relates :  
JDK-8153776 - Implement jdkCA constraint
Relates :  
JDK-8225099 - Tagging jdkCA certs in pkcs12 keystore differently
Relates :  
JDK-8170131 - Certificates not being blocked by jdk.tls.disabledAlgorithms property
Relates :  
JDK-8166362 - [TEST_BUG] test sun/net/www/http/HttpClient/B8025710.java failing with cert error in 8u121 b01
Relates :  
JDK-8165101 - AnchorCertificates throws NPE when cacerts file not found
Relates :  
JDK-8150455 - Reduce synchronization in DisabledAlgorithmConstraints
Sub Tasks
JDK-8171464 :  
Release Note: Add mechanism to allow non default root CAs to not be subject to algorithm restrictions - Closed
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.
Comments
UR SQE OK to take the enhancement to CPU17_01
26-09-2016
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).
11-04-2016