RFR 8171279: Support X25519 and X448 in TLS 1.3

[Adam Petcher]

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? 
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.