New webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.01/
On 3/8/2018 1:51 PM, Sean Mullan wrote:
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 ..."
fixed.
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.
I added a sentence to the comments in XECKey, but I'm not sure how much
we should say here. I don't know if we should get into mathematical
details. Take a look at the new wording and let me know if I should add
more information.
- ECGenParameterSpec
45: s/of provider/of the provider/
fixed
- NamedParameterSpec
36: the link looks wrong, since it is for SSLContext
Oops. I changed the section to "parameter-spec-names" which will be a
new section that I'll add to this document.
39: I think the @see is unnecessary
removed.
- XECKey
The description should include some basic details so someone doesn't
have to know what RFC 7748 is to understand it.
Similar response to a previous comment. I added some more information,
but I don't know if it is enough. Let me know.
- 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.
I changed it to "cannot" and added the example.
--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
