On 12/14/2012 12:24 PM, Michael StJohns wrote:
> At 10:48 PM 12/13/2012, Xuelei Fan wrote:
>> We cannot go that far in crypto libraries because of compatibilities.
>> Applications need to take the responsibilities to use proper strength.
>> In crypto library level, we are only able to enforce very weak
>> algorithms and key sizes restrictions, as MD2 and RSA-512.  Otherwise,
>> those applications that still need to use RSA-1024, SHA1/MD5 will run
>> into serious compatibility issues.
> 
> I agree.  But I'd still disable EC < 160 and DSA < 1024 in the same place 
> where you disable RSA < 1024 in this patch.
> 
That's a very good practice!  I recommend that applications always use
the stronger strength according to NIST recommendation, or other
recommendations.

> I'd also probably consider updating the release notes to note that the 
> default could change again in 2013 or 2014 to the even stronger values (and 
> SHA1 removed) and how to re-enable the weaker strengths.
> 
Good point.

Thanks,
Xuelei

> Thanks - Mike
> 
> 
> 
> 
>> Xuelei
>>
>> On 12/14/2012 11:21 AM, Michael StJohns wrote:
>>> Does this go far enough?
>>>
>>> If you're going with NIST recommendations, anything less that 112 bits of 
>>> strength is now considered weak.  The guidance is those strengths are 
>>> deprecated now, and prohibited after the end of 2013.  In addition, SHA1 is 
>>> deprecated now and prohibited after 2013 for signatures (still acceptable 
>>> for other things).
>>>
>>> RSA 1024 bits is about 80 bits of security so the relative key bit lengths 
>>> are DSA and RSA < 1024 and EC < 160 should probably be disabled in this 
>>> pass.
>>>
>>> After the end of next year, DSA and RSA < 2048 and EC < 224  as well as 
>>> SHA1 for signatures should be disabled.
>>>
>>> Mike
>>>
>>>
>>> At 08:12 PM 12/11/2012, Xuelei Fan wrote:
>>>> Hi,
>>>>
>>>> Please review the update for JDK-7109274, Consider disabling support for
>>>> X.509 certificates with RSA keys less than 1024 bits.
>>>>
>>>> Webrev: http://cr.openjdk.java.net./~xuelei/7109274/webrev.00/
>>>>
>>>> The bug description is not available at bugs.sun.com at present. The
>>>> purpose of this update is to disable the support of X.509 certificates
>>>> with RSA keys less than 1024 bits.
>>>>
>>>> The key length is an important security parameter to determine the
>>>> strength of public key based cryptographic algorithms. RSA keys less
>>>> than 1024 bits are considered breakable [1][2].
>>>>
>>>> In this update, we are proposing to restrict the use of certificates
>>>> with RSA keys less than 1024 bits in length.  This restriction is
>>>> applied via the Java Security property,
>>>> "jdk.certpath.disabledAlgorithms" [1].  This will impact providers that
>>>> adhere to this security property, for example, the Sun provider and the
>>>> SunJSSE provider.
>>>>
>>>> The security property, "jdk.certpath.disabledAlgorithms", also covers
>>>> the use of the static keys (the key in X.509 certificate) used in TLS.
>>>> Therefore, we don't need to add any further restrictions to the
>>>> "jdk.tls.disabledAlgorithms" security property.
>>>>
>>>> With this key size restriction, those who use X.509 certificates based
>>>> on RSA keys less than 1024 bits will encounter compatibility issues with
>>>> certification path building and validation.  This key size restriction
>>>> also impacts JDK components that validate X.509 certificates, for
>>>> example signed JAR verification, SSL/TLS transportation, HTTPS
>>>> connections, etc.
>>>>
>>>> In order to avoid the compatibility issue, users who use X.509
>>>> certificates with RSA keys less than 1024 bits are recommended to renew
>>>> their certificates with stronger keys.  As a workaround, at their own
>>>> risks, users can adjust the key size restriction security property
>>>> ("jdk.certpath.disabledAlgorithms") or use the
>>>> java.security.AlgorithmConstraints (introduced in JDK 7) to permit
>>>> smaller key sizes.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>> [1]: http://blogs.rsa.com/rsa-768-factored/
>>>> [2]: http://technet.microsoft.com/en-us/security/advisory/2661254
>>>
>>>
> 
> 

Reply via email to