RFR 8171279: Support X25519 and X448 in TLS 1.3

[Xuelei Fan]

I think I suggested to use NamedParameterSpec, which is a public API.

    NamedParameterSpec -> name "x25519"
        -> key size is the key size of x25519.

Please let me know if the logic is wrong.

 > Also, why do you object to having XECParameters in java.base?
Please read my previous comments.

 > ... similar classes like ECParameters and CurveDB.
Previously, there is no NamedParameterSpec, so we have to workaround to 
use ECParameters.  Now, we don't have to do the ugly thing any more if I 
did not miss something.

Thanks,
Xuelei

On 9/6/2018 12:13 PM, Adam Petcher wrote:
> On 9/6/2018 1:55 PM, Xuelei Fan wrote:
> 
>>> Yes, the key sizes are fixed. All we need in ECUtil is a mapping from 
>>> curve name to this (fixed) size. Are you suggesting some other 
>>> solution, other than using the XECParameters to map curve names to 
>>> key sizes?
>> Using name only (NamedParameterSpec?) and have the JCE provider handle 
>> it, then you don't need to move XECParameters into java.base module.
>>
> Do you have a specific suggestion on how I can do that? I don't think 
> there is anything in the JCE API for XDH that allows a lookup from name 
> to key length. Are you proposing that I enhance the public API to avoid 
> using XECParameters here?
> 
> Also, why do you object to having XECParameters in java.base? Most of 
> the crypto code is in java.base, including similar classes like 
> ECParameters and CurveDB. I admit that it is unfortunate that 
> XECParameters is used directly here, instead of going over JCE---is that 
> what you object to?
>