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