RFR 8171279: Support X25519 and X448 in TLS 1.3

[Xuelei Fan]

On 9/7/2018 9:03 AM, Adam Petcher wrote:
> This is more clear, thanks. See below.
> 
> 
> On 9/7/2018 11:34 AM, Xuelei Fan wrote:
>> EncodedKeySpec keySpec = ... // find a way to construct the keySpec
>>                              // at least, we can use:
>>                              //    new EncodedKeySpec(byte[]);
>>                              // But please check if there's a better one
> 
> Do you mean X509EncodedKeySpec, or some class that is specific to XDH? 
I did not search the spec definitions.  At least we can use the 
EncodedKeySpec class.   It's nice if you can find a better one, or 
define a new one for XDH.

Your following comments make sense to me.

Thanks,
Xuelei

> An X509EncodedKeySpec would probably work---we would just need to put 
> the key into a SubjectPublicKeyInfo, which means I need the OID. Is it 
> okay for me to put the OID in JSSE? I could put it in the NamedGroup 
> enum, like this:
> 
>      X25519      (0x001D, "x25519", true, "x25519", "1.3.101.110",
>          ProtocolVersion.PROTOCOLS_TO_13),
>      X448        (0x001E, "x448", true, "x448", "1.3.101.111",
>          ProtocolVersion.PROTOCOLS_TO_13),
> 
> I'm not sure if the second x25519/x448 strings (for algorithm and 
> NamedParameterSpec names) would still be needed, since I can use the OID 
> in some of these places. If it's not needed, then perhaps I can remove 
> it and only use the OID to interact with the JCA provider.
> 
> We don't have a type for XDH encoded public keys. It would be nice to be 
> able to do something simple like:
> 
> byte[] keyBytes = ...
> NamedParameterSpec paramSpec = new NamedParameterSpec("X25519");
> XECEncodedPublicKeySpec keySpec = new XECEncodedKeySpec(paramSpec, 
> keyBytes);
> 
> and then give keySpec to the "XDH" key factory. But this 
> XECEncodedKeySpec type does not exist, so this would require an 
> enhancement to the API.