I haven't reviewed all of it (mainly just the standard classes), but
here are some comments so far:
- General comments
For new public classes, you don't need to start the sentence with the
name of the class since that is implied and will show up in javadoc
pages. For example, "XECKey is an interface ..." should just be "An
interface ..."
I think somewhere there should be a sentence or two on the difference
between XECKeys and ECKeys and when you would want to use each. This is
important enough that I think some detail should be in the javadoc to
help users distinguish them. Perhaps put it in the XEC class
description. Maybe more details can go in the JCA security guide.
- ECGenParameterSpec
45: s/of provider/of the provider/
- NamedParameterSpec
36: the link looks wrong, since it is for SSLContext
39: I think the @see is unnecessary
- XECKey
The description should include some basic details so someone doesn't
have to know what RFC 7748 is to understand it.
- XECPrivateKey
47: would "cannot" be a more appropriate word than "may not"? May not
sounds a bit vague. Perhaps also an example of why it cannot be
extracted would be helpful.
--Sean
On 2/6/18 1:36 PM, Adam Petcher wrote:
Webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8171277
Please review this change that adds key agreement via the X25519 and
X448 elliptic curve functions to the JCA API and SunEC provider. These
functions and related operations and encodings are described in RFC
7748[1]. This work does not include JSSE integration, which will be done
later as a separate task (not part of JEP 324). The webrev does not
include the field arithmetic code, which is being reviewed
separately[2]. This change is a part of JEP 324, so it will not be
integrated into the repo until all work for that JEP is complete and it
has been targeted to a release.
[1] https://tools.ietf.org/html/rfc7748
[2]
http://mail.openjdk.java.net/pipermail/security-dev/2018-January/016756.html
