This appears to be related specifically to PKCS11. Specifically, PKCS11 v2.20 has some ambiguity of the representation of an EC point (which is different in the text than an ASN1 ECPoint).
This is being clarified in v2.30 with the unencoded point format (e.g.the format described in X9.62, where the first octet indicates the encoding and there are either N or 2N octets following) being the expected value, but with PKCS11 providers allowed - legacy - to accept either. One of the reasons for going that way was how the JDK PKCS11 provider had interpreted the issue and implemented its code. I don't support this fix - among other things, this fix only deals with 1/2 of the problem. The other half is related to encoding the value. Also, changing the code at decodePoint seems further into the stack than needed and may affect other uses of that method. There's an existing JDK bug on this coming at it from a different direction - 6763530 ... and there may be considerations at https://bugzilla.mozilla.org/show_bug.cgi?id=480280 that should be looked at. Also see 6779460 which is mostly a duplicate of 6763530. It's probable that the fix I suggested at 6763530 (in comments submitted 29 Nov 08) may be a better approach given the NSS fixes. I believe it will fix the keytool problem noted in the original message. Mike At 04:39 PM 9/1/2009, Joe Darcy wrote: >Andrew John Hughes wrote: >>2009/8/28 Andrew John Hughes <[email protected]>: >>>In OpenJDK6, the elliptic curve cryptography algorithms are available >>>if the PKCS11 provider is configured to point to NSS. See: >>> >>>http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider >>> >>>If NSS is configured as specified in this blog, keytool can be used to >>>generate a key as follows: > >Hello. > >Allowing keytool and friends to work in more cases if the provider is capable >seems fine to me. > >Security team, do you have concerns about this patch? > >Thanks, > >-Joe
