Hi, 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. Thanks & Best regards Christoph [1] http://jcewww.iaik.tu-graz.ac.at/sic/Products/Core_Crypto_Toolkits/JCA_JCE > -----Original Message----- > From: Langer, Christoph > Sent: Sonntag, 9. Juli 2017 07:57 > To: 'Anthony Scarpino' <anthony.scarp...@oracle.com>; 'Sean Mullan' > <sean.mul...@oracle.com> > Cc: OpenJDK Security <security-dev@openjdk.java.net>; 'Dieter Bratko' > <dieter.bra...@iaik.tugraz.at> > Subject: RE: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd > party JCE provider > > Hi Tony et. al., > > I'm wondering why in the commit for 8174849 > (http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d911fe42d2da) this line > sneaked in: > > --- > a/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChe > cker.java Wed Feb 15 12:11:03 2017 -0800 > +++ > b/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmCh > ecker.java Wed Feb 15 12:55:20 2017 -0800 > @@ -276,7 +276,7 @@ > AlgorithmParameters currSigAlgParams = algorithmId.getParameters(); > PublicKey currPubKey = cert.getPublicKey(); > - String currSigAlg = x509Cert.getSigAlgName(); > + String currSigAlg = ((X509Certificate)cert).getSigAlgName(); > > // Check the signature algorithm and parameters against constraints. > if (!constraints.permits(SIGNATURE_PRIMITIVE_SET, currSigAlg, > > The proposed webrev only contains the change to java.security and there is > no other hint on that anywhere public. > > I'm asking because I'm seeing an issue with a 3rd party JCE provider at the > moment. There is an "SHA1withRSA" certificate involved but the provider in > use at my customer returns the String "SHA1/RSA" as SigAlgName. Don't > know how much this conforms with the spec, but it is as it is. So the permits > check will fail with that String. I believe, if the SigAlgName would be taken > from the converted x509Cert as before, we'd get SHA1withRSA and would be > fine, though I didn't test that yet. So, what speaks against that line being > reverted? > > Thanks & Best regards > Christoph > > > -----Original Message----- > > From: security-dev [mailto:security-dev-boun...@openjdk.java.net] On > > Behalf Of Anthony Scarpino > > Sent: Montag, 13. Februar 2017 22:48 > > To: OpenJDK Security <security-dev@openjdk.java.net> > > Subject: [RFR] 8174849: Change SHA1 certpath restrictions > > > > Hi, > > > > I need a quick review on a simple certpath config change. > > > > http://cr.openjdk.java.net/~ascarpino/8174849/webrev/ > > > > thanks > > > > Tony
