JDK-8038084 : CertStore needs a way to add new CertStore types
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-03-21
  • Updated: 2017-05-17
  • Resolved: 2015-05-15
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 9
9 b65Fixed
Related Reports
Relates :  
JDK-8134708 - Certpath validation fails to load certs and CRLs if AIA and CRLDP extensions point to LDAP resources
Relates :  
JDK-6889552 - Sun provider should not require LDAP CertStore to be present
Relates :  
JDK-8075902 - Update security provider docs for changes under 8038084 and 7191662
Description
This bug requests that the means to support CertStore types beyond "Collection" be re-examined so that it will work cleanly with modules.

As things currently stand (early JDK 9) then reflection is used to load LDAPCertStoreHelper, if that succeeds then the "LDAP" type is supported, if it doesn't then the LDAP type is not supported. This approach is okay for Compact Profiles in JDK 8 but is problematic for modules because LDAPCertStoreHelper will not be exported by the JNDI/LDAP module.

One approach to consider is using ServiceLoader so that additional CertStore type can be added by deploying the appropriate service provider. If there are security concerns then the service type could be a type that is not exported -- see sun.util.xml.PlatformXmlPropertiesProvider for one example.
Comments
Yes, the additional LDAP data can be handled by adding additional constructors to LDAPCertStoreParameters. This means that separate LDAPCertStore object have to used if different LDAP data were to be used though. This can be addressed by caching inside existing LDAP certstore impl. However, there is concern that existing 3rd party LDAP certstore impls may not be aware of this new additional info in this enhanced LDAPCertStoreParameters and thus would return incorrect results. There are two other solutions besides enhancing the existing LDAPCertStoreParameters class: 1) add new LDAP-specific X509Cert/CRLSelector classes which holds the ldap entry info. 2) add a new and more general cert store parameters, e.g. URICertStoreParameters class. Both have their pros and cons. Currently, 2) seems to have a slight advantage since it will be auto-rejected by existing LDAP certstore impls due to its new type. Also that conceptually, ldap entry info may not belongs to be part of Cert/CRLSelector. So, we will go with the URICertStoreParameters approach.
03-04-2015
If it can be made to work with the current provider mechanism then that would be great. Does that mean that the java.naming module will provide an implementation of CertStoreSpi? I think we should try to avoid hacks, the java.naming module should not need to export cert store implementation classes to java.base.
24-02-2015
> If it can be made to work with the current provider mechanism then that would be great. > Does that mean that the java.naming module will provide an implementation of CertStoreSpi? It is looking like the best solution at this point. It may require some additional standard API methods or classes to pass in LDAP specific data that was previously handled internally.
24-02-2015
Ah yes, I remember this now. If the current code could be disentangled then it would be great (there is history here in JDK 7 where we had an attempt in this direction).
11-02-2015
Alan, unless I'm misunderstanding your comment, CertStore has a standard spi already: http://docs.oracle.com/javase/8/docs/api/java/security/cert/CertStoreSpi.html
11-02-2015
I think it makes sense for java.naming to provide a CertStore implementation that supports LDAP. One thing that I'm not sure about is whether there should be a standard provider interface for CertStore implementations or whether the provider interface is JDK-specific.
11-02-2015
Valerie, I am assigning this to you to investigate more thoroughly as part of the modularization of JCE providers work.
24-03-2014
In earlier work on jigsaw, I had changed the JCE provider lookup implementation to use ServiceLoader. Wouldn't that fix this issue? See: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-August/003101.html for more info.
21-03-2014
We will need to move the JCE provider mechanism to ServiceLoader anyway. If this means that we can remove the current reflection use to load the LDAPCertStoreHelper then it will address the issue.
21-03-2014