Closed Bug 367577 Opened 16 years ago Closed 9 years ago

Only require NSS_ENABLE_ECC to allow signing data with EC keys


(NSS :: Libraries, defect, P2)



(Not tracked)



(Reporter: mozbgz, Assigned: wtc)




(Whiteboard: [SMIME-ECC])


(1 file, 1 obsolete file)

In nss/lib/cryptohi/secsign.c, using an EC key for signing is currently ifdef'ed by NSS_ECC_MORE_THAN_SUITE_B:

 93     if (key->keyType == ecKey) {
 95         return 0;
 96     }
 97 #endif


I believe this should be changed to #ifndef NSS_ENABLE_ECC, as proposed by the attached patch.

Otherwise, several certutil commands don't work for ECC certificates / certificate requests (e.g. -R, cf. the recent thread "ECDSA certs?" on, or mod_nss can't really be configured to work with ECDHE_ECDSA (NSS_Initialize() will fail).
I have verified that certutil with using the supported ECDSA does not work without this patch and that the patch seems to at least allow cert requests to be written.
Assignee: nobody → julien.pierre.boogz
Attachment #252152 - Flags: superreview?(nelson)
Attachment #252152 - Flags: review+
Ever confirmed: true
There is a disagreement among some of the contributors to NSS concerning
what operations may be done with ECC without infringing on certain ECC
patents.  Based on ,
some of the contributors have chosen to believe that all uses of ECC, 
except the uses defined in the RFCs for TLS and IPSec, are potentially 
patent infringing.  Consequently, the "Basic ECC" builds that are used in 
all Mozilla clients, use ECC only in the TLS protocol itself, and in cert
signature verification, and use only the curves named in that document.

I expect that one of the developers who holds that position will resolve
this bug WONTFIX.  (I expected that months ago, and still do.)

Any who disagree with that position are free to take it up with the NSS
contributors who hold that position, but NOT IN THIS BUG.  
Comment on attachment 252152 [details] [diff] [review]
Patch to enable signing with EC keys when NSS is compiled for Basic ECC

I find no technical fault with this patch, but I will not give it sr+ while
the controversy remains in dispute, to keep the peace.
Attachment #252152 - Flags: superreview?(nelson)
I am not advocating whether or not Certicom's patent(s) cover a particular use of ECC or what Mozilla should do about it. However:
Based on ,
some of the contributors have chosen to believe that all uses of ECC, 
except the uses defined in the RFCs for TLS and IPSec, are potentially 
patent infringing.
To me, that IPR statement says that Certicom believes that some of the uses of ECC in TLS and IPsec would infringe on thir patent(s) and that Certicom may take action against organizations that disagree with them. I am not sure how to read the statement in any other way.
Bob, people are calling for this in the newsgroup again.
There's a reviewed patch.  At this point, I believe RH is holding it up.
I think you agreed to revisit this issue.  Please do.
Assignee: julien.pierre.boogz → rrelyea
Version: trunk → 3.11.1
I think this should be given priority. Without this change, ECC certificates basically don't work in libssl. In particular, you cannot use a ECC client cetificate and you cannot use ECDHE_ECDSA mode.

Also, it is impossible to successfully run the test suite with NSS_ENABLE_ECC unless the testsuite is hacked so that certutil uses its own private copy of softoken built with NSS_ECC_MORE_THAN_SUITE_B. (certutil creates ECC certificates that are used to test the rest of the ECC code.)
May we ask Certicom for clarification, would ECC signing infringe their patents ?
I don't have any opinion on what is or is not infringed by any given patent or on whether any given patent license is compatible with the license(s) under which NSS is distributed, but have Certicom's more recent IPR disclosures been considered with respect to this issue?  Certicom has posted a lot of IPR disclosures to the IETF web site ( since June 2007, and these more recent disclosures mention many more protocols than were mentioned in
The above referenced Certicom document is now updated by (referenced from

It's a similar document to the previous one, the important part is that *it* *extends* the royalty free patent license to the use of ECC inside CMS (and SSH).

AFAIK the only actual use of signature in Mozilla products is in Thunderbird for CMS signing, so that is clearly no more a problem. We might need to find a way to warn other users of NSS wishing to use signature for a different usage than CMS.
Please do not discuss any of those non-technical issues in this bug, in any other bug in bugzilla outside of the Legal component (which you might not be able to access, in which case nobody reading this bug can do anything about it), in any Mozilla mailing list other than, or in any (private) email to engineers. We are not the ones that deal with that kind of stuff. I don't mean to be unfriendly and I appreciate that you are trying to help, but such comments need to be directed to the appropriate channels. Thanks!
Whiteboard: [SMIME-ECC]
The patch in 838778 is more correct, so I'm closing this bug as a dup of 838778 even though this bug is older.
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 838778
I got Bob's verbal approval for this change.
Attachment #252152 - Attachment is obsolete: true
Attachment #733429 - Flags: review?(rrelyea)
Attachment #733429 - Flags: checked-in+
Bob: sorry about the mid-air collision.  I was moving my patch
to this bug and converting bug 838778 to a tracking bug.
Assignee: rrelyea → wtc
Blocks: 838778
Priority: -- → P2
Target Milestone: --- → 3.15
Comment on attachment 733429 [details] [diff] [review]
Patch to enable signing with EC keys when NSS is compiled for Basic ECC, v2

r+ rrelyea, though I believe I've r+ an idential patch today in another but.
Attachment #733429 - Flags: review?(rrelyea) → review+
You need to log in before you can comment on or make changes to this bug.