RFR [14] JDK-8226374 Restrict signature algorithms and named groups

[Xuelei Fan]

The latest webrev:
     http://cr.openjdk.java.net/~xuelei/8226374/webrev.04/

Updated the java.security to use the right document for standard names.

Xuelei


On 7/29/2019 8:55 AM, Xuelei Fan wrote:
> 
> 
> On 7/29/2019 7:57 AM, Sean Mullan wrote:
>> On 7/28/19 1:42 PM, Xuelei Fan wrote:
>>> On 7/26/2019 7:08 AM, Xuelei Fan wrote:
>>>> New webrev:
>>>> http://cr.openjdk.java.net/~xuelei/8226374/webrev.03/
>>>>
>>>
>>>>
>>>>> * 
>>>>> src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java 
>>>>>
>>>>>
>>>>> 114             if ((namedGroup == null) || 
>>>>> (!namedGroup.isAvailable)) {
>>>>>
>>>>> You don't do this check for null and isAvailable in other places, 
>>>>> for example 
>>>>> ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() - 
>>>>> should you?
>>>>>
>>>> Good point!  Currently, the restriction is only checked for the 
>>>> supported group extension.  I should add more check points in other 
>>>> places where named groups are used, for example client key exchange 
>>>> and certificate.  Stay tune for the next webrev.
>>>>
>>> The ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() 
>>> should be fine as the namedGroup has been checked in the previous 
>>> steps 
>>> (X509Authentication.X509PossessionGenerator.createServerPossession()).
>>>
>>> However, I missed the check for certificate.  The consumer of 
>>> certificate should check the named groups to make sure the supported 
>>> named group is used.  It was not a problem in the past as the 
>>> supported named groups are used to indicate the EC curve or DH group 
>>> is able to be handled in both side.
>>>
>>> It could be a problem now when we want to restrict named groups.  The 
>>> named groups used in a certificate should be checked in key manager 
>>> and trust manager for TLS 1.2 and prior versions.  Similar to the 
>>> signature schemes for TLS 1.3.  As may required new APIs 
>>> (SSLParameters.getPeerSupportedNamedGroups()) for a generic solution.
>>>
>>> Would you mind if I file a new RFE and make the improvement in JDK 14 
>>> later?
>>
>> Ok. I had a comment/question on the CSR [1]. In the Solution section, 
>> you list the legacy signature schemes as:
>>
>> dsa_sha256
>> ecdsa_sha224
>> rsa_sha224
>> dsa_sha224
>> ecdsa_sha1
>> rsa_pkcs1_sha1
>> dsa_sha1
>> rsa_md5
>>
>> However, the IANA registry for TLS defines them differently: 
>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 
>>
>>
>> Can you clarify why we have this difference and how the JDK uses these 
>> legacy algorithms?
> I added some description above these legacy signature schemes.
> 
>      https://bugs.openjdk.java.net/browse/JDK-8227445
> 
>> I don't want to define them as standard names unless I can reference a 
>> TLS specification.
>>
> These names should not be used for future applications.  It's fine to me 
> if they are not part of the standard names.
> 
> Thanks,
> Xuelei