2009/9/2 Michael StJohns <[email protected]>: > At 09:38 PM 9/1/2009, Andrew John Hughes wrote: >>2009/9/2 Michael StJohns <[email protected]>: >>>  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. >>> >> >>That's really too vague to be of much help in improving the patch. >>You seem to be saying little more than 'I don't like it'. > > Sorry about that. My point was that your patch didn't completely solve the > problem and that the point at where you were fixing it could have some bad > side effects for anyone calling decodePoint directly. > > >>> 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 >>> >> >>It seems likely that's the NSS change that causes the current failure. >> The fix I submitted here is based on the way this is handle in NSS. >>In fact, the code is similar enough to suggest that one was developed >>from the other. >> >>>  that should be looked at. >> >>The JDK bug is not really 'from a different direction', it's reporting >>exactly the same error but from a less trivial example (I get the same >>failure while trying to create an example key, while this seems to >>require specific hardware if I'm reading it correctly). > > Not exactly. You're using the NSS as a PKCS11 module - this problem would > occur with any PKCS11 module that implements EC stuff. > > >>Also see 6779460 which is mostly a duplicate of >>> 6763530. >>> >> >>The patch on 6779460 seems wrong. It means that the method will >>return a DER-encoded value where it would either have returned an >>uncompressed value before or failed. > > My point exactly as I mentioned in the comments. :-) > > >>> >>> 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. >>> >> >>Ok, I can see the logic in the fix and it would appear to work, though >>I haven't tested it. >>Given the patch was written nine months ago, why has it not been >>applied? If it had, it would have saved me hours having to debug this >>same issue again. > > Yup. I did do a search for PKCS11 related bugs when I encountered the same > problem and did find the original error. > >>Do you have an SCA with Sun? If so, I'll create a webrev based on your >>patch and we can finally get this fixed. Without it, NSS support is >>completely broken in OpenJDK6 which makes me wonder why this is a low >>priority bug! > > I do have an SCA on file. Note that the recommendation from the NSS guys was > to raise the priority. > > The reason I haven't submitted this is because I submitted a different EC fix > https://bugs.openjdk.java.net/show_bug.cgi?id=100048 per the documented > process > and was waiting on progress there before continuing. I've got a number of > EC and PKCS11 related fixes I'd like to submit, but I was trying for a worked > example before proceeding. And then I got busy with some other things... > > Mike > > > > > >>> 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 >>> >> >> >> >>-- >>Andrew :-) >> >>Free Java Software Engineer >>Red Hat, Inc. (http://www.redhat.com) >> >>Support Free Java! >>Contribute to GNU Classpath and the OpenJDK >>http://www.gnu.org/software/classpath >>http://openjdk.java.net >> >>PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > > >
Ok here is a new webrev: http://cr.openjdk.java.net/~andrew/6763530/webrev.02/ with a slightly revised version of your change (you can't throw a PKCS11Exception which only takes a long ID from the native code, so I changed this to an IllegalArgumentException). Security team, does this look ok to push? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
