DSA with keylength > 1024 no longer accepted (solved)

[Peter Haraldson]

I just want to confirm that this applies only to RedHat:s patched version.
In their release "java-1.7.0-openjdk-1.7.0.71-2.5.3.2.el6_6", which 
basically is OpenJDK 7, they added a patch that included this rule.

I will turn to RedHat for further discussions.
Thanks for your help!

Regards
peter


>
> Message: 1
> Date: Mon, 19 Jan 2015 15:50:13 +0000
> From: Se?n Coffey <sean.coffey at oracle.com>
> To: Peter Haraldson <peter at certitrade.net>,
> 	"jdk7u-dev at openjdk.java.net" <jdk7u-dev at openjdk.java.net>
> Cc: "security-dev at openjdk.java.net" <security-dev at openjdk.java.net>
> Subject: Re: DSA with keylength > 1024 no longer accepted (jdk7u-dev
> 	Digest,	Vol 43, Issue 8)
> Message-ID: <54BD27B5.4030906 at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Peter,
>
> the issue you reference isn't a problem in jdk7u. - for the Oracle JDK
> at least. The code snippet your refer to is from jdk8 source code. The
> key length restriction was initially introduced as a side effect of this
> fix in JDK 8 https://bugs.openjdk.java.net/browse/JDK-7044060
>
> That said, the version string you pasted makes it look like you're
> running IcedTea from Redhat. My earlier assumptions were that you were
> running OpenJDK binary based on the jdk7u sources
> (http://hg.openjdk.java.net/jdk7u/jdk7u/jdk) - If IcedTea has ported
> JDK-7044060 to their code base, you might have to contact them. Best to
> follow up on distro-pkg-dev at openjdk.java.net
>
> regards,
> Sean.
>
> On 19/01/15 15:21, Peter Haraldson wrote:
>>
>>
>> Thanks, I have now subscribed to security-dev as well. To keep the
>> thread intact I still reply here.
>>
>> Our java version would be JDK 7 I suppose - reported java version
>> "1.7.0_65".
>>
>> I checked your link, and I can see this issue will be resolved in JDK
>> 8 & 9, but I could not find anything about this issue with JDK 7.
>> If it's not to be fixed in JDK 7 then we will need to upgrade.
>>
>> Kind regards
>> Peter
>>
>>
>>>
>>> Message: 3
>>> Date: Thu, 15 Jan 2015 10:28:46 +0000
>>> From: Se?n Coffey <sean.coffey at oracle.com>
>>> To: Peter Haraldson <peter at certitrade.net>
>>> Cc: Security OpenJDK <security-dev at openjdk.java.net>
>>> Subject: Re: DSA with keylength > 1024 no longer accepted
>>> Message-ID: <54B7965E.8010109 at oracle.com>
>>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>>
>>> Hi Peter,
>>>
>>> security-dev is best mailing list to discuss this issue, I'm cc'ing that
>>> list and bcc'ing off jdk7u-dev.
>>>
>>> Are you hitting this issue with JDK 8 and later ? (I'll assume so) -
>>> You've hit https://bugs.openjdk.java.net/browse/JDK-8039921
>>> To aid compatibility, it's been decided to relax that restriction from
>>> 8u60 and later. See comments in bug report around use of SHA1 and SHA2
>>> and the length of keys that should be used in each operation.
>>>
>>> Hope that helps.
>>> regards,
>>> Sean.
>>>
>>> On 15/01/2015 10:10, Peter Haraldson wrote:
>>>> Hi
>>>> First, I'm not quite sure if this is the correct list for this issue,
>>>> please excuse & correct me if it's not.
>>>>
>>>> Our problem is that in latest openjdk a check is added that makes our
>>>> certificates with DSA & Keylength 2048 unusable. In file
>>>> "sun.security.provider.DSA" line 484-489:
>>>>        protected void checkKey(DSAParams params) throws
>>>> InvalidKeyException {
>>>>               int valueL = params.getP().bitLength();
>>>>               if (valueL > 1024) {
>>>>                   throw new InvalidKeyException("Key is too long for
>>>> this algorithm");
>>>>               }
>>>>           }
>>>> This is new, these certificates worked fine before. I don't know the
>>>> reason for not accepting longer keys than 1024, not allowing too short
>>>> keys would make sense to me but not allowing long keys?
>>>>
>>>> We need to find a permanent solution, as for now we can't update our
>>>> production servers because of this. We have several certificates
>>>> issued by MasterCard, it is a very tedious job to change them all.
>>>> Is there a way we could bypass this, could this check be abandoned in
>>>> next update?
>>>>
>>>> Our system:
>>>> java version "1.7.0_65" (not affected)
>>>> OpenJDK Runtime Environment (rhel-2.5.1.2.el6_5-x86_64 u65-b17)
>>>> OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
>>>> OS: RedHat 6.6
>>>>
>>>> Regards Peter
>>>