Re: SHA-256 support
On 11/18/2013 07:00 AM, Gervase Markham wrote: Hi everyone, Following Microsoft's announcement re: SHA-1, some CAs are asking browser and OS vendors about the ubiquity of SHA-256 support. It would be a help to them if we could say: - Which version of NSS first supported SHA-256 Gerv, SHA-256 isn't the only algorithm of interest here. The latest Windows Root Certificate Program requirements [1] permit CAs to use SHA-256, SHA-384 and SHA-512. Unsurprisingly, these 3 functions from the SHA-2 family are what the Windows CryptoAPI actually supports (since XP SP3). On 19/11/13 02:20, Robert Relyea wrote: I think it's safe to say if your NSS ap is newer than a decade old, you have SHA-2 support. The one caveat is that SHA-224 support was added much later, but SHA-256, SHA-384, and SHA-512 have all been supported for a while. SHA-224 isn't supported by CryptoAPI, and CAs aren't permitted (by [1]) to use it anyway. Ditto for the SHA-512/224, SHA-512/256 and SHA-512/t functions that were added to the SHA-2 specification [2] last year. [1] http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx [2] http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Mon, Nov 18, 2013 at 06:47:08PM -0800, Wan-Teh Chang wrote: On Mon, Nov 18, 2013 at 4:57 PM, Brian Smith br...@briansmith.org wrote: Also, AES implementations are highly optimized, well-audited, well-tested, and are more likely to be side-channel free. Camellia doesn't get used very often. Yet, some websites (most famously, Yahoo!), prefer Camellia over AES, even when we offer AES at higher priority in the handshake. There must be a misunderstanding. NSS offers Camellia at higher priority than AES in the ClientHello. Yes, in the current stable version camellia is often negiotiated if the server supports it because it's almost always above the AES ciphers in the list. The biggest exception to that is ECDHE, because there is no camellia cipher of that. I think that the new order makes more sense, and at least in aurora the order has changed now. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SHA-256 support
On 11/19/2013 02:50 AM, Rob Stradling wrote: On 11/18/2013 07:00 AM, Gervase Markham wrote: Hi everyone, Following Microsoft's announcement re: SHA-1, some CAs are asking browser and OS vendors about the ubiquity of SHA-256 support. It would be a help to them if we could say: - Which version of NSS first supported SHA-256 Gerv, SHA-256 isn't the only algorithm of interest here. The latest Windows Root Certificate Program requirements [1] permit CAs to use SHA-256, SHA-384 and SHA-512. Unsurprisingly, these 3 functions from the SHA-2 family are what the Windows CryptoAPI actually supports (since XP SP3). My evaluation on when we supported SHA-2 covers all 3 hash functions. On 19/11/13 02:20, Robert Relyea wrote: I think it's safe to say if your NSS ap is newer than a decade old, you have SHA-2 support. The one caveat is that SHA-224 support was added much later, but SHA-256, SHA-384, and SHA-512 have all been supported for a while. SHA-224 isn't supported by CryptoAPI, and CAs aren't permitted (by [1]) to use it anyway. Ditto for the SHA-512/224, SHA-512/256 and SHA-512/t functions that were added to the SHA-2 specification [2] last year. We don't support the truncated* SHA-512 functions (other than SHA-384). SHA-224 is a truncated* SHA-256. * truncated hashes also have their own initialization vector, so SHA-224(x) != trunc(SHA-256(x)) even though SHA-224 uses the same base algorithm. [1] http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx [2] http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How do you sign a FireFox .xpi add-on file using Jarsigner?
On Monday, November 18, 2013 8:31:22 AM UTC-8, Štefan Baebler wrote: On Wednesday, November 13, 2013 11:19:45 PM UTC+1, Mike Price wrote: Does anyone know the secret to using Java's jarsigner.exe to sign a FireFox .xpi add on? I have seen a few references that seem to imply that this can be done successfully, but I can't get it to create an installable version of my .xpi file. Any particular reason for not wanting to use NSS signtool? https://developer.mozilla.org/en/docs/Signing_a_XPI lists some alternatives (jarsigner didn't make it to the list). MP: Our system can access certificate keys from our HSM when we use Jarsigner.exe. We do not currently have this same capability when using the NSS signtool.exe. Our old system supported XPISigner, but the author of this tool closed down his website a few years ago. I will look at the other alternatives mentioned on the mozilla XPI page. I can sign it with jarsigner and the verify command says the signature is valid, but it always results in a this file is corrupt message when I attempt to install the add-on into FireFox. I have followed the directions for re-arranging the contents of the archive so that zigbert.rsa is the first file in the archive, but it just doesn't work. It complains that the manifest hash is invalid which is strange since I don't do anything to change this file. Any ideas out there as to how to get this to work? This seems to be an old, known compatibility issue: http://www.jensign.com/JavaScience/www/comparejar/ Greets, Stefan Even though the link you sent was dated 2001, it shows exactly the same behavior I am seeing using JDK 1.6 now. I may try JDK 1.7 just to make sure it is still broken, but I think perhaps the other alternatives listed on the Mozilla site may ultimately better choices. Thanks, Mike -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SHA-256 support
On 11/19/2013 10:40 AM, Wan-Teh Chang wrote: Bob's answer is accurate. Note that CAs are more interested in SHA-2 based signature support rather than plain SHA-2 support. So another way to track down the NSS version is to look at the CVS history of the secvfy.c file: http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/security/nss/lib/cryptohi/secvfy.crev=HEADmark=1.30 The relevant revisions are: 1.7 nelsonb%netscape.com2002-12-11 22:05 Support SHA256, SHA384, and SHA512 hashes in NSS. 1.14 wtchang%redhat.com2005-08-12 16:50 Bugzilla Bug 296410: enlarge the buffer size for message digest so that we can generate and verify signatures that use SHA-512. 1.17 rrelyea%redhat.com2006-02-07 22:14 Bug 320583 Support for SHA256/384/512 with ECC signing So it is safe to say that by mid 2006 (NSS 3.11.1, released on 2006-05-05) the support of SHA-2 based signatures in NSS was already stable and complete, covering both RSA and ECDSA signatures. This would map to*: Firefox 2.0.0.1 Thunderbird 1.5.0.10 Mozilla 1.9a1 Seamonkey 1.0.8 Another evidence of mature support is the FIPS 140-2 validation of NSS 3.11.4 (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#814). A very conservative response would be NSS 3.11.4 (http://www-archive.mozilla.org/projects/security/pki/nss/nss-3.11.4/nss-3.11.4-release-notes.html) and later. This yields the same list (it looks like mozilla picked up 3.11.5 as the first nss 3.11 build it shipped). * Source, the cvs log for nss.h, the one file known to change for every release (because it has the NSS version numbers). Wan-Teh smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto