Launchpad has imported 20 comments from the remote bug at http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=356.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2009-06-25T14:26:48+00:00 Matthias Klose wrote: IcedTea6-1.5: keytool error: java.security.NoSuchAlgorithmException: SHA384withECDSA Signature not available error adding /etc/ssl/certs/COMODO_ECC_Certification_Authority.pem Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/2 ------------------------------------------------------------------------ On 2009-07-06T18:39:23+00:00 Pantelis Koukousoulas wrote: Created attachment 240 A small testcase that illustrates the missing SHA384withECDSA Signature Algorithm problem. Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/13 ------------------------------------------------------------------------ On 2009-07-07T15:26:00+00:00 ankostis wrote: * Needed to add a suitable for 'SHA384withECDSA' provider into 'java.security' config-file. * Supposedly SHA384withECDSA provided by sun.security.pkcs11.SunPKCS11 with NSS as the native backend, as described in: http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider with the following config-file: name = NSS nssLibraryDirectory = /opt/tests/nss/lib nssDbMode = noDb attributes = compatibility * In fedora needed to install nss-devel-3.12.3-4.fc11.i586 due to a missing NSS lib. * Debug java-prop: java.security.debug={all|provider|sunpkcs11} * But NSS does *NOT* by default compile ECC! according to: http://www.mozilla.org/projects/security/pki/nss/nss-3.11/nss-3.11-algorithms.html * BUT Testcrypto.java TestCase also fails in sun's jdk!! Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/392104/comments/14 ------------------------------------------------------------------------ On 2009-07-07T16:35:10+00:00 ankostis wrote: Managed to import COMODO's ECC certificate. This bug is present also in sun's JDK and it gets fixed as prescribed by Andreas Sterbenz: http://blogs.sun.com/andreas/entry/the_java_pkcs_11_provider We need to add the 'sun.security.pkcs11.SunPKCS11' provider with a single config-arg pointing to a file containing the following properties: name = NSS nssLibraryDirectory = /usr/lib nssDbMode = noDb attributes = compatibility Tested on: * Gentoo, needs devlibs/nss installed and a minor config modification: nssLibraryDirectory=/usr/lib/nss and it works ok. * Debian just needs libnss3-1d installed, and it also works ok. * Fedora's NSS, by default is compiled most probably *without* ECC! So it fails. (see: http://www.mozilla.org/projects/security/pki/nss/nss-3.11/nss-3.11-algorithms.html) Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/392104/comments/15 ------------------------------------------------------------------------ On 2009-07-14T20:47:45+00:00 Jon-vanalten wrote: I'll be the first to admit I know little about nss, but it looks like you're absolutely correct as some others have had similar issues: https://bugzilla.redhat.com/show_bug.cgi?id=492124 May I suggest that you post these details (or simply a link to this bug) in a new nss bug on the Red Hat bugzilla: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora I'd do so myself but it's not my itch to scratch :D (more importantly, someone with more intimate knowledge of the issue could contribute more meaningfully to the report). >From the above convo and the bits I've read elsewhere on the subject it seems this is not an IcedTea bug, so I'm closing this. Feel free to reopen if I am mistaken. Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/16 ------------------------------------------------------------------------ On 2009-07-14T21:05:21+00:00 Matthias Klose wrote: are you sure about closing the report? At least java.security needs to be aware of the new security provider. One possibility would be a configure check in IcedTea, and modification of the java.security file. Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/392104/comments/17 ------------------------------------------------------------------------ On 2009-07-14T21:46:29+00:00 Jon-vanalten wrote: Fairly sure. From Andreas Sterbenz's 2006 blog posting linked by Kostis in comment #2 and #3, programs wishing to use this (not new) provider should add it (ie "Security.insertProviderAt(nss, 1);" at runtime, and set up config file as described. So unless I have misunderstood completely, this is not a build or configure issue for IcedTea. Furthermore, http://blogs.sun.com/andreas/entry/elliptic_curve_cryptography_in_java indicates that the use of ECC depends on NSS library specifically compiled with ECC support. All signs point to Fedora's NSS library not being compiled as such. Thus the recommendation to open Red Hat bug wrt the nss (really I should say nss-devel) package. If you know something I don't (which is entirely likely), please reopen the report and add info as required. Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/18 ------------------------------------------------------------------------ On 2009-07-14T22:04:44+00:00 Matthias Klose wrote: it's keytool from OpenJDK which does need this support to add the certificate to the keystore, and read it again. Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/392104/comments/19 ------------------------------------------------------------------------ On 2009-07-14T23:43:47+00:00 Gnu-andrew-n wrote: I don't think keytool needs to be altered. We could however have NSS support enabled out of the box. We are in a better position than Sun in that we are not distributing proprietary standalone binaries, and can instead depend on NSS. Thus, it seems, from reading these blogs, that we could detect NSS using autoconf and generate the configuration, rather than leaving it to the end user. The other issue is that Fedora's NSS doesn't have elliptic curve support. This needs fixing in Fedora with the bug Jon mentioned. You'll be glad to know that a pure Java implementation of elliptic curve cryptography is slated for JDK7; http://openjdk.java.net/projects/jdk7/features/#f73 Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/20 ------------------------------------------------------------------------ On 2009-07-15T15:31:39+00:00 Jon-vanalten wrote: oic. After looking some at sun/security/tools/KeyTool.java and sun/security/pkcs11/SunPKCS11.java, I agree that changes to KeyTool would not be the best approach here. There are a number of provider types in the JDK, they are not given any special treatment by KeyTool. Similary not all providers are known in java.security. A couple of questions come to mind about the possibility of generating a NSS config file (depending on detection of nss library). First: how would we know whether the local library is built with ECC support? It is not afaik a default build option, Fedora may not be the only distro not building with that option. Second: folks wishing to use this provider would need to know the location of the config file to pass as an arg when specifying this provider to keytool. Either that or we need to patch SunPKCS11.java so that default constructor looks to some location for config file rather than failing. Do other providers require config files, and is there already some location where such files are put by default? Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/21 ------------------------------------------------------------------------ On 2009-08-03T08:41:21+00:00 ankostis wrote: (In reply to comment #9) > A couple of questions come to mind about the possibility of generating a NSS > config file (depending on detection of nss library). > First: how would we know whether the local library is built > with ECC support? > It is not afaik a default build option, > Fedora may not be the only distro not building with that option. As listed in #3, i had verified that: * gentoo[1] and * debian/ubuntu[2] build NSS with ECC by default. Also linked this bug to fedora's relevant bug[3] as suggested. [1] http://bugs.gentoo.org/247221 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490826 [3] https://bugzilla.redhat.com/show_bug.cgi?id=492124 Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/23 ------------------------------------------------------------------------ On 2009-08-21T17:19:41+00:00 Gnu-andrew-n wrote: OpenJDK7 just gained native ECC support: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6840752 http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/1ff7163fc5f7 >From reading the changeset it seems they import the Mozilla NSS code. So we may actually need to patch this back out in IcedTea... sigh. Jon, for 6 I think we would need to patch java.security to include that provider if NSS is available. Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/24 ------------------------------------------------------------------------ On 2009-08-24T19:26:29+00:00 Gnu-andrew-n wrote: I've queried this inclusion of NSS on the security-dev list: http://mail.openjdk.java.net/pipermail/security- dev/2009-August/001115.html Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/25 ------------------------------------------------------------------------ On 2009-08-27T16:33:50+00:00 Gnu-andrew-n wrote: Just tried adding this on Gentoo and I'm getting: java.lang.RuntimeException: Could not parse key values at sun.security.pkcs11.P11Key$P11ECPublicKey.fetchValues(P11Key.java:1026) at sun.security.pkcs11.P11Key$P11ECPublicKey.getEncodedInternal(P11Key.java:1036) at sun.security.pkcs11.P11Key.getEncoded(P11Key.java:126) at sun.security.x509.CertificateX509Key.encode(CertificateX509Key.java:105) at sun.security.x509.X509CertInfo.emit(X509CertInfo.java:819) at sun.security.x509.X509CertInfo.encode(X509CertInfo.java:189) at sun.security.x509.X509CertImpl.sign(X509CertImpl.java:528) at sun.security.x509.X509CertImpl.sign(X509CertImpl.java:486) at sun.security.x509.CertAndKeyGen.getSelfCertificate(CertAndKeyGen.java:288) at sun.security.tools.KeyTool.doGenKeyPair(KeyTool.java:1223) at sun.security.tools.KeyTool.doCommands(KeyTool.java:827) at sun.security.tools.KeyTool.run(KeyTool.java:194) at sun.security.tools.KeyTool.main(KeyTool.java:188) Caused by: java.io.IOException: Point does not match field size at sun.security.ec.ECParameters.decodePoint(ECParameters.java:92) at sun.security.pkcs11.P11ECKeyFactory.decodePoint(P11ECKeyFactory.java:78) at sun.security.pkcs11.P11Key$P11ECPublicKey.fetchValues(P11Key.java:1023) ... 12 more This is with dev-libs/nss-3.12.3-r1 Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/26 ------------------------------------------------------------------------ On 2009-08-27T16:36:49+00:00 Gnu-andrew-n wrote: To replicate, you need an IcedTea6 build in ${java.home}. Then create ${java.home}/jre/lib/security/nss.cfg as follows: name = NSS nssLibraryDirectory = ${nsslibdir} nssDbMode = noDb attributes = compatibility where nsslibdir can be found by running pkg-config --variable=libdir nss You then link this in by adding the following line to ${java.home}/jre/lib/security/java.security: security.provider.9=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg Then run: ${java.home}/bin/keytool -v -genkeypair -keyalg EC -keysize 256 -keystore ectest.jks -storepass test12 -dname "CN=ECC Test" Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/27 ------------------------------------------------------------------------ On 2009-08-27T17:18:07+00:00 Gnu-andrew-n wrote: A little debugging finds that: array length: 67 field size: 256 n = 32 array: [4, 65, 4, -26, -5, 56, -82, -53, -122, 32, 102, -86, -64, -59, 84, 5, 110, 1, -49, 38, -7, 3, -97, 122, -36, -18, 99, -126, -83, 83, 34, 12, -38, -84, 43, 83, -38, -25, -58, 9, -30, -37, 108, -43, 35, -118, -15, 53, 104, -26, -45, -51, 3, -83, 100, -119, -108, 25, 75, -37, 39, 9, 50, -121, 105, 68, 96] The check that throws the exception is the failure of array length to equal (n*2)+1 (65) in this case. The array returned by NSS has two extra bytes. n is calculated from the field size of 256 by adding 7 and shifting right 3. If the field size was 257, it would thus match the array size but this is not a legal EC key size. Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/28 ------------------------------------------------------------------------ On 2009-08-27T18:30:03+00:00 Gnu-andrew-n wrote: The problem is that the Java code doesn't support an DER encoded key. >From mozilla/security/nss/lib/softoken/pkcs11.c in NSS: /* special note: We can't just use the first byte to determine * between these 2 cases because both EC_POINT_FORM_UNCOMPRESSED * and SEC_ASN1_OCTET_STRING are 0x04 */ /* handle the non-DER encoded case (UNCOMPRESSED only) */ if (pubKey->u.ec.publicValue.data[0] == EC_POINT_FORM_UNCOMPRESSED && pubKey->u.ec.publicValue.len == keyLen) { break; /* key was not DER encoded, no need to unwrap */ } /* if we ever support compressed, handle it here */ /* handle the encoded case */ if ((pubKey->u.ec.publicValue.data[0] == SEC_ASN1_OCTET_STRING) && pubKey->u.ec.publicValue.len > keyLen) { SECItem publicValue; SECStatus rv; rv = SEC_QuickDERDecodeItem(arena, &publicValue, SEC_ASN1_GET(SEC_OctetStringTemplate), &pubKey->u.ec.publicValue); /* nope, didn't decode correctly */ if ((rv != SECSuccess) || (publicValue.data[0] != EC_POINT_FORM_UNCOMPRESSED) || (publicValue.len != keyLen)) { crv = CKR_ATTRIBUTE_VALUE_INVALID; break; } /* replace our previous with the decoded key */ pubKey->u.ec.publicValue = publicValue; break; } Reply at: https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+bug/392104/comments/29 ------------------------------------------------------------------------ On 2009-08-27T23:20:19+00:00 Gnu-andrew-n wrote: Tracked this bug down to a lack of DER decoding in ECParameters: http://mail.openjdk.java.net/pipermail/jdk6-dev/2009-August/000708.html Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/30 ------------------------------------------------------------------------ On 2009-09-28T18:50:53+00:00 Gnu-andrew-n wrote: Fixed in IcedTea6 HEAD: http://icedtea.classpath.org/hg/icedtea6/rev/b387a64caa08 As noted earlier, for ECC support NSS must be built with ECC support. Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/31 ------------------------------------------------------------------------ On 2010-03-15T18:43:03+00:00 Gnu-andrew-n wrote: Fixed in 1.7. Reply at: https://bugs.launchpad.net/ubuntu/+source/ca- certificates/+bug/392104/comments/33 ** Bug watch added: Red Hat Bugzilla #492124 https://bugzilla.redhat.com/show_bug.cgi?id=492124 ** Bug watch added: Debian Bug tracker #490826 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490826 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/392104 Title: [Karmic] Update to ca-certificates 20090624 prevents ca-certificates- java from installing To manage notifications about this bug go to: https://bugs.launchpad.net/icedtea/+bug/392104/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs