Re: SHA-256 support

2013-11-19 Thread Rob Stradling

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

2013-11-19 Thread Kurt Roeckx
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

2013-11-19 Thread Robert Relyea
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?

2013-11-19 Thread mikeprice . mail
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

2013-11-19 Thread Robert Relyea
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