RFR 8171279: Support X25519 and X448 in TLS 1.3

[Xuelei Fan]

 > 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.
I see your points.  However, we may want to think if third party wants 
to implement a JSSE provider, whether the JCE providers are sufficient 
for them and how the JCE provider could be used for them.  Using OID 
works, but it is not as straightforward as a name.  We should document 
the names in the Standard Names document.  So using OIDs might not be as 
good as using names.

I guess we have documented the 'x25519" algorithm name for JDK 11?  If 
it is true, then we should be able to use them.

Xuelei


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