[security-dev 01547]: Re: PING: [PATCH FOR REVIEW]: 6763530: Fix breakage of NSS-based Elliptic Curve Cryptography in OpenJDK6

Sun Jun 27 23:17:03 UTC 2010

On 27 June 2010 23:45, Michael StJohns <mstjohns at comcast.net> wrote:
> PS - I know this is the openjdk list - but I thought this one was getting back ported.
>
> Mike
>
>
> At 05:37 PM 6/27/2010, Michael StJohns wrote:
>>Hi guys -
>>
>>I see from the Mercurial logs that this went in to both the jdk6 and jdk7 repositories.  For jdk6 - it's rev 302 which looks like this should have ended up in the _19 release
>>
>>But all the files in lib/ext/sunpkcs11.jar  for _20 are all tagged as 1 September 2009....
>>
>>Is the sunpkcs11.jar provider not getting regenerated and rebundled during the release process?
>>
>>Mike
>>
>>
>>
>>At 01:28 PM 1/21/2010, Michael StJohns wrote:
>>>At 05:12 AM 1/21/2010, Vincent Ryan wrote:
>>>>I hear ya. Sorry for the delay on this. I'll push the fix for OpenJDK today.
>>>
>>>
>>>
>>>>On 21/01/2010 07:44, Tomas Gustavsson wrote:
>>>>>
>>>>> Now it has one more vote.
>>>>>
>>>>> /Tomas
>>>>>
>>>>> Andrew John Hughes wrote:
>>>>>> 2010/1/20 Tomas Gustavsson <tomas at primekey.se>:
>>>>>>> I'll second this request. This is a critical patch and many production
>>>>>>> installations have to live with this manually patched now.
>>>>>>>
>>>>>>> I know of no pkcs11 implementation that works with the current code.
>>>>>>>
>>>>>>
>>>>>> It has four votes:
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6763530
>>>>>> I don't know how many they need to wake up and review the patch.
>>>>>>
>>>>>> The new release of IcedTea6 1.7 is imminent and will include the fix
>>>>>> so it should at least be resolved on the next version shipping with
>>>>>> most GNU/Linux distributions.
>>>>>>
>>>>>>> Regards,
>>>>>>> Tomas Gustavsson
>>>>>>> PrimeKey Solutions AB
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 20 Jan 2010, Michael StJohns wrote:
>>>>>>>
>>>>>>>> Hi - this seems to have stalled out again.  Any chance of revival?
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>>
>>>>>>>> At 12:33 PM 9/24/2009, Vincent Ryan wrote:
>>>>>>>>> Hello Andrew,
>>>>>>>>>
>>>>>>>>> I'll need a little more time to come up to speed on this fix. I'm
>>>>>>>>> concerned that
>>>>>>>>> there may be interoperability or backwards compatibility issues.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Andrew John Hughes wrote:
>>>>>>>>>> 2009/9/2 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>>>>>>>>>>> 2009/9/2 Michael StJohns <mstjohns at comcast.net>:
>>>>>>>>>>>> At 09:38 PM 9/1/2009, Andrew John Hughes wrote:
>>>>>>>>>>>>> 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'.
>>>>>>>>>>>> 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 <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
>>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>> Ping! Security developers, any thoughts on this patch:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~andrew/6763530/webrev.02/
>>>>>>>>>>
>>>>>>>>>> Does it look ok to push?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>>
>
>
>

It has been:

$ hg log -R jdk -k 6763530
changeset:   302:82b80660cac3
user:        vinnie
date:        Thu Jan 21 23:59:41 2010 +0000
summary:     6763530: Cannot decode PublicKey (Proider SunPKCS11,
curve prime256v1)

and certainly is present on IcedTea6's builds.
-- 
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