[security-dev 01165]: Re: PING 1: [PATCH FOR REVIEW]: Elliptic Curve Cryptography in OpenJDK6 with NSS

[Andrew John Hughes]

2009/9/2 Michael StJohns <mstjohns at comcast.net>:
>  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'.

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

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.

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

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!

> Mike
>
>
>
>
>
> At 04:39 PM 9/1/2009, Joe Darcy wrote:
>
> Andrew John Hughes wrote:
>
> 2009/8/28 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>
> 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