Filed at blord's request: It would be nice to make the NSS that is required by Dogtag one that is built according to the ECC directions (http://pki.fedoraproject.org/wiki/ECC_Capable_NSS), or have 2 different packages that could satisfy the NSS dependency. Apparently building NSS in the manner described will leave the RSA/DSA functionality working the same so why not have everyone use the same build? Dogtag out of the box has EC referenced all through the GUI, config files, etc and it's quite misleading to the user. Additionally, if you hand-build NSS and then update the system and an NSS update comes down, it will overwrite your EC-enabled NSS. Hilarity^H^H^H^H^H^H^H^HSobbing ensues.
This bug prevents the 'keytool' of both sun's java and IcedTea from importing Comodo's CA ECC certificate.
It's on this list: http://fedoraproject.org/wiki/User:Peter/Disabled_applications so I guess this may be an issue for fedora-legal to resolve.
I suppose I could have been a little more detailed with the original request. The directions linked to on the Dogtag wiki tell the reader how to build an EC "aware" NSS. Sun's current JDK 6 knows about EC and has algorithm names and interfaces defined to work with it, but no implementation (which is reportedly about to change with Java 7). If you want to use EC you'll need to add in a 3rd party crypto provider such as BouncyCastle or IAIK. Following the link above you'll end up with an NSS the same way. The softtoken gets excluded from the EC build so there isn't any actual EC implementation compiled in, but the rest of the toolkit knows how to deal with EC and you can plug in a 3rd party PKCS#11 module that implements the EC algorithms. Yeah, it would be nice to one day be able to use NSS's built-in token to do the EC (maybe use the same implementation that Sun is using for Java 7?) but in the mean time, I think the above would go a long way to lowering the EC barrier of entry as well as ongoing maintenance of Dogtag.
I've already gone into most of the general OpenJDK issues here: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=356 and there's a patch currently posted for review on the IcedTea mailing list. When applied, IcedTea can be configured with the additional option --enable-nss. configure then searches for a system NSS, and, if found, will add the necessary configuration to the JDK being built so that EC works out of the box. This assumes that the system NSS has EC support which is not currently the case for Fedora and hence this bug. However, if OpenJDK is built with this support enabled, then EC support will work if the system NSS is later replaced with one that includes it. The OpenJDK7 changes have gone in and, to my disappointment, are a regression. Although they originally planned to implement EC (which has its own issues), this direction was abandoned due to legal issues. What we have in 7 is basically NSS... in the source tree. I'm sure I don't have to point out to distro packagers the downsides of having a duplicate library inside an application and the consequent effects on security maintenance for it. They already do this with libjpeg, libpng and zlib and we rip this out in IcedTea, using the system libraries instead (it's also the case for lcms, but due to local modifications we can't use the system copy). It looks like we'll also have to do this for NSS now, especially if there are legal issues with shipping it in Fedora. So, yeah, all they've done is create more work for us. Enabling NSS support in OpenJDK6 is fairly trivial by comparison, it's only a problem for Sun because they can't depend on system libraries with their stock proprietary builds.