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