[RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Sean Mullan sean.mullan at oracle.com
Wed Jul 12 14:45:16 UTC 2017


On 7/11/17 3:10 PM, Langer, Christoph wrote:
> Well, probably you are right that it is not a bug - at least when you look at the documentation of Java9 (the link that you have cited).
> 
> However, if we look at the documentation of X509Certificate, it's not that clear, resp. it wasn't for pre JDK9 releases. JDK9 mentions in [1] an algorithm name example of "SHA256withRSA". However, the documentation for 8 [2] and probably all older JDKs talks about an example of "SHA-1/DSA". So this older type of algorithm names must have existed at some time - and it used to work with JDKs <= 8. However, the security standard names documentation already existed for JDK8 and probably earlier.

Right, as Dieter pointed out in his reply, this seems to go way back to 
the early days of Java when the standard algorithm names were still 
evolving.

> As for the reason why IAIK has not changed that (yet), maybe Dieter on cc can comment. He mentioned to me that some discussion about that had been done within IAIK but the change was never really dared.
> 
> So, I guess I would be fine if this could at least be changed for JDKs <= 8 for compatibility reasons. I can understand if for JDK >= 9 we say this is a new release and the standard algorithm names shall be enforced. Wouldn't that be a good compromise?

Yes. In fact I think the most robust solution (even for 9 and later) is 
to look at the encoded AlgorithmId in the X.509 certificate to determine 
what signature algorithm is being used, and this would eliminate the 
compatibility risk with third party providers using non-standard Java 
names. This is exactly what X509CertImpl.getSigAlgName() is doing.
> In any case, from what you are saying, I take that I can safely patch our JDK distribution with this change without doing a bad thing to security in general, wouldn't you agree?

Yes, I agree.

Also, note that you can probably also workaround this issue by adding a 
specific "SHA1/RSA" constraint to the jdk.certpath.disabledAlgorithms 
security property.

--Sean

> 
> Thanks & best regards
> Christoph
> 
> [1]http://download.java.net/java/jdk9/docs/api/java/security/cert/X509Certificate.html#getSigAlgName--
> [2]https://docs.oracle.com/javase/8/docs/api/javax/security/cert/X509Certificate.html#getSigAlgName--


More information about the security-dev mailing list