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

Dieter Bratko dieter.bratko at iaik.tugraz.at
Wed Jul 12 10:30:08 UTC 2017


Hello Sean, Christoph,

To explain the reason for our non-compliance to the JCA "<hash>withRSA" signature standard name notation I have to get back to the very beginning. Namely to JDK 1.1.8 which used the "<hash>/RSA" notation as standard names for RSA-PKCSv1.5 signature algorithms (see attachment; I have found a JCK1.1.8 CryptoSpec in our archives : -).
IAIK followed this recommendation and later - as SUN has changed to the <hash>withRSA notation we changed it too -- but then had to turn back since too many users already relied on the "/" slash in the signature algorithm name -- I think for parsing the hash algorithm from it. The problem was not the Signature engine (where getAlgorithm() returns what has been specified when calling Signature.getInstance()), but the names used for ASN.1 AlgorithmIdentifiers (as used by X.509 certificates). So we had to stay with the original JCA standard name notation for our AlgorithmID implementation (but added the possibility allowing users to change the name settings). 
However, we again will check if we can change to the <hash>withRSA notation. Nevertheless, since the CertPath AlgorithmChecker already converts the X509CertImpl it might be more safe to call getSigAlgName() on it -- for Algorithms it knows of (and therefore also knows which names it expects). 

Best Regards,
Dieter

-----Original Message-----
Von: Sean Mullan [mailto:sean.mullan at oracle.com] 
Gesendet: Dienstag, 11. Juli 2017 19:21
An: Langer, Christoph <christoph.langer at sap.com>; Anthony Scarpino <anthony.scarpino at oracle.com>
Cc: OpenJDK Security <security-dev at openjdk.java.net>; Dieter Bratko <dieter.bratko at iaik.tugraz.at>
Betreff: Re: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider

Hi Christoph,

On 7/11/17 5:43 AM, Langer, Christoph wrote:
> 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.

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?

Thanks,
Sean

[1]
http://download.java.net/java/jdk9/docs/specs/security/standard-names.html#signature-algorithms

> 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20170712/898e50c2/CryptoSpec-0001.html>


More information about the security-dev mailing list