Some feedback on this bug as I worked on it from the RH side.
* The OpenJDK Java code for elliptic curve support in SSL uses a list of curves based on the in-tree code used by Oracle.
* The actual curves supported by the system version of NSS used on most distributions is much shorter; it's basically three approved NIST curves. I assume this is for legal reasons which I won't try and go into further.
* This bug comes about because of the mismatch between the two. The Java code says it supports one set of curves, but in practice, the underlying provider code doesn't.
* This is true whether the combination of NSS with the PKCS11 provider is used (the Ubuntu setup above and what Red Hat were trying in its bug) or with the SunEC provider (support for this is coming in IcedTea 2.5.0).
The next set of releases (2.4.8, 2.5.0) will include a patch which fixes the list of curves on the Java side to match the list used by system NSS. This bug should then be properly resolved and the above workaround will not be needed.
Looking to the future, the SunEC provider may be a better solution for providing elliptic curve support - it matches what Oracle use in their packages - but doing so with a system NSS will require 3.16.1, in order to expose necessary APIs. Even then, it is necessary to link against a static NSS library at build-time.
Some feedback on this bug as I worked on it from the RH side.
* The OpenJDK Java code for elliptic curve support in SSL uses a list of curves based on the in-tree code used by Oracle.
* The actual curves supported by the system version of NSS used on most distributions is much shorter; it's basically three approved NIST curves. I assume this is for legal reasons which I won't try and go into further.
* This bug comes about because of the mismatch between the two. The Java code says it supports one set of curves, but in practice, the underlying provider code doesn't.
* This is true whether the combination of NSS with the PKCS11 provider is used (the Ubuntu setup above and what Red Hat were trying in its bug) or with the SunEC provider (support for this is coming in IcedTea 2.5.0).
The next set of releases (2.4.8, 2.5.0) will include a patch which fixes the list of curves on the Java side to match the list used by system NSS. This bug should then be properly resolved and the above workaround will not be needed.
Looking to the future, the SunEC provider may be a better solution for providing elliptic curve support - it matches what Oracle use in their packages - but doing so with a system NSS will require 3.16.1, in order to expose necessary APIs. Even then, it is necessary to link against a static NSS library at build-time.