On 2017-08-04 21:33, Michael StJohns wrote:
On 8/4/2017 3:05 PM, Anders Rundgren wrote:
https://lists.oasis-open.org/archives/pkcs11/201708/msg00006.html
C'mon (Oracle) Guys, what's *your* plan; is JDK open source or not? :-)
Yeah, I know that open source <> open ideas but the world needs a
direction.
Feel completely free dismissing OKP, it is the silence that's killing us.
Cheers,
Anders
https://github.com/cyberphone/java-cfrg-spec
Anders asked me to take a look at this a while back and I haven't
actually had much time. However, I think the approach he's crafted for
OKP is probably wrong for Java.
"Wrong" is hardly the right word here; the proposals simply have quite
different objectives.
I (FWIW) didn't give internal operations and structures much considerations;
the emphasis was on clarity and conformance with other related specs.
Your proposal focuses on reuse by finding similar patterns which of course isn't
"wrong" either.
In terms of code size I believe the difference will turn out to be
insignificant but that's of course at this stage just a guess.
However, documentation- and support-wise OKP has a clear advantage. Maybe
Oracle should start there and see where it leads...
Anders
What I think I would do instead is create
java.security.spec.ECFieldMontgomery and
java.security.spec.ECFieldEdwards. I'd place the indication of whether
the curves are for Signature or Key Agreement at the field level - maybe
as a sub interface or marker interface.
For the ECPoint data I'd leave Y as a NULL - Y does exists and can be
calculated, but all of these appear to use a compressed encoding. I'd
encode the public and private data as BigIntegers - this would mean
converting from little endian to big endian and back again when doing
the PKCS8 encoding stuff, but a lot easier than adding a whole new class
of top level interfaces.
As far as I can tell, it should be possible to represent the four curves
using the current API (minus the field info) and I'd suggest doing
exactly that. Tagging the ECField differently will isolate the changes
without breaking previous implementations. I think this is then also
extensible as other curves come along.
My thoughts - Mike
