[RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider
Langer, Christoph
christoph.langer at sap.com
Tue Jul 11 09:43:08 UTC 2017
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.scarpino at oracle.com>; 'Sean Mullan'
> <sean.mullan at oracle.com>
> Cc: OpenJDK Security <security-dev at openjdk.java.net>; 'Dieter Bratko'
> <dieter.bratko at 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-bounces at openjdk.java.net] On
> > Behalf Of Anthony Scarpino
> > Sent: Montag, 13. Februar 2017 22:48
> > To: OpenJDK Security <security-dev at 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
More information about the security-dev
mailing list