ECDSA support in Thunderbird

[harn...@gmail.com]

Is ECDSA S/MIME signature generation available in Thunderbird? [using one of the Suite B curves]

I've tried using a PKCS#11 module that I am developing and ran into trouble with Thunderbird erroring out w/ "Unable to sign message. Please check that the certificates .... are valid and trusted." (which they are according to the certificate dialog which lists them as valid for Email Signing...)

I have successfully performed ECDSA-based client-authentication in the latest Firefox release, but the code flow is quite different.

[Robert Relyea]

Whether or not ECC works is a function of the version of NSS you have. If built by Mozilla, ECC works for signature verification and client auth out of the box. The NSS built by red hat will not do any ECC unless you supply your own ECC PKCS #11 module. In the latter case, then all the ECC functions work. Instructions for building NSS like redhat can be found here: http://pki.fedoraproject.org/wiki/ECC_Capable_NSS

bob

> --
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>

[Thomas Harning]

On Tuesday, February 26, 2013 5:05:07 PM UTC-5, Robert Relyea wrote:
> Whether or not ECC works is a function of the version of NSS you have. If built by Mozilla, ECC works for signature verification and client auth out of the box. The NSS built by red hat will not do any ECC unless you supply your own ECC PKCS #11 module. In the latter case, then all the ECC functions work. Instructions for building NSS like redhat can be found here: http://pki.fedoraproject.org/wiki/ECC_Capable_NSS
>

So for signature verification and client-auth... not S/MIME email signing? I take it this would also mean ECDH-based S/MIME would also not work.

[Robert Relyea]

----- Original Message -----

> On Tue, 2013-02-26 at 17:05 -0500, Robert Relyea wrote:
> > Whether or not ECC works is a function of the version of NSS you
> > have.
> > If built by Mozilla, ECC works for signature verification and
> > client
> > auth out of the box. The NSS built by red hat will not do any ECC
> > unless you supply your own ECC PKCS #11 module. In the latter case,
> > then all the ECC functions work. Instructions for building NSS like
> > redhat can be found here:
> > http://pki.fedoraproject.org/wiki/ECC_Capable_NSS
>

> Isn't it about time Red Hat started shipping non-crippled versions?
>
> RFC 6090 is two years old now...

It's never been a technical issue, and that's pretty much all I can say about the issue:(,

bob
>
> --
> dwmw2

[Thomas Harning]

On Tuesday, February 26, 2013 5:05:07 PM UTC-5, Robert Relyea wrote:

> Whether or not ECC works is a function of the version of NSS you have. If built by Mozilla, ECC works for signature verification and client auth out of the box. The NSS built by red hat will not do any ECC unless you supply your own ECC PKCS #11 module. In the latter case, then all the ECC functions work. Instructions for building NSS like redhat can be found here: http://pki.fedoraproject.org/wiki/ECC_Capable_NSS
>

[Jean-Marc Desperrier]

Robert Relyea a écrit :

> ----- Original Message -----
>> On Tue, 2013-02-26 at 17:05 -0500, Robert Relyea wrote:
> >> http://pki.fedoraproject.org/wiki/ECC_Capable_NSS
>>
>> Isn't it about time Red Hat started shipping non-crippled versions?
>>
>> RFC 6090 is two years old now...
>
> It's never been a technical issue, and that's pretty much all I can say about the issue:(,

Isn't it about time Red Hat reads the W3C Security Patent Advisory Group
conclusions about Certicom's claims on the Elliptic Curve DSA & DH
algorithms ?
http://www.w3.org/2011/xmlsec-pag/pagreport.html

Certicom is a member of W3C. Their membership made it, in the context of
the PAG, mandatory to fully disclose all the IP they owned that was
relevant to implementation of Elliptic Curve DSA in the XML Security
standard (but not being member of the XML Security WG made it
non-mandatory for them to provide a compliant license, see
http://lists.w3.org/Archives/Public/public-xmlsec-comments/2011Jan/0000.html
)

The caveat is however that the conclusions of the PAG (If you base
yourself on RFC 6090, *the lawyers* say you're safe from Certicom's IP)
don't necessarily apply to the use of elliptic curves outside of the
specific algorithms used by XML Security.

Which means not outside of :
- ECDSA as described in
http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-20/#sec-ECDSA
- ECDH and ECDH key agreement as described in
http://www.w3.org/TR/xmlenc-core1/#sec-ECCKeyValue