A few (mostly minor) comments on the Solution section. I'll continue my
review of the rest of the CSR later.
First sentence, "from the existing API ECDSA ..." should that be "API
for ECDSA"?
// example: use KeyFactory to contruct a public key
typo: construct
"This API does not standardize "EdEC" algorithm names, so the programmer
must use "EdDSA" as the algorithm name to obtain a KeyPairGenerator or
KeyFactory."
In the example, you use "Ed25519" and not "ECDSA" as the alg name for
KeyPairGenerator - which one is correct?
--Sean
On 6/27/18 12:56 PM, Adam Petcher wrote:
I'm looking for some initial feedback on the proposed JCA API for
EdDSA[2], which I have documented in a draft CSR ticket[1]. Any
comments, concerns, suggestions, etc are appreciated.
To summarize, the API for EdDSA looks a lot like the API for
X25519/X448. Like X25519/X448, it does not allow the selection of
arbitrary curve parameters. Though the API is flexible enough that it
could be extended to allow more flexibility in the future (or
immediately using provider-specific classes), if necessary.
The EdDSA API is a little bit more complicated than X25519/X448, because
public keys are points that cannot be expressed with a single
coordinate, and because the signature scheme takes additional
information related to the mode (pure, prehash, context). So we need a
couple more classes to handle these complications, but otherwise the API
is essentially the same as X25519/X448.
[1] https://bugs.openjdk.java.net/browse/JDK-8190219
[2] https://tools.ietf.org/html/rfc8032
