[RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider
Langer, Christoph
christoph.langer at sap.com
Sun Jul 9 05:57:20 UTC 2017
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/AlgorithmChecker.java Wed Feb 15 12:11:03 2017 -0800
+++ b/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.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