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

Langer, Christoph christoph.langer at sap.com
Tue Jul 11 19:10:10 UTC 2017


Hi Sean,

thanks for coming back on this.

> > I'd like to ping you again upon that question. In the meanwhile I have
> produced a standalone test case and could verify that changing to x509Cert
> vs. the original cert for obtaining the SigAlgName would be a fix. I can share
> the test with you, however, you'll need the security provider 'IAIK' which is
> not OpenSource but can be obtained for free for educational/research
> purposes here [1].
> >
> > Shall I open a Bug for that and propose a fix? Or is using the x509Cert at this
> place the wrong thing to do here for reasons? I'd appreciate some feedback.
> 
> Technically, I don't think this is a bug. IAIK is using a non-standard
> algorithm for the signature algorithm of the certificate. The Standard
> Algorithm Names specification [1] says that "SHA1withRSA" is the correct
> name.
> 
> The JDK algorithm constraints implementation should not have to
> accommodate non-compliant certificates.
> 
> Tony and I don't quite recall why this change was made as part of
> JDK-8174849, but in general the conversion to
> sun.security.x509.X509CertImpl is done so that we can access parts of
> the certificate in a more performance friendly manner or if they are not
> accessible via the standard APIs. This is not one of those cases.
> However, I can't think of any specific reason right now we could not use
> X509CertImpl instead but would like to think about it some more.
> 
> Have you asked IAIK about their non-compliance?
> 
> [1]
> http://download.java.net/java/jdk9/docs/specs/security/standard-
> names.html#signature-algorithms

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.

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?

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?

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