Skip to Content.
Sympa Menu

assurance - RE: [Assurance] SHA-2 Update

Subject: Assurance

List archive

RE: [Assurance] SHA-2 Update


Chronological Thread 
  • From: "Capehart,Jeffrey D" <>
  • To: "" <>
  • Subject: RE: [Assurance] SHA-2 Update
  • Date: Thu, 5 Sep 2013 20:57:55 +0000
  • Accept-language: en-US

Hopefully the CA/B forum announcement isn't news to anyone, but how does it factor into the SHA-1 or SHA-2? 

 

Since SHA-1 is still ok for legacy use in digital signature verification after 2013, and since the SSL certificates would have been generated before the end-of-life date, would they still be ok to use?

 

From:  http://www.incommon.org/certificates/doc/2048-bit-Certificates.pdf

2048 Bit Keys – The Official Line

 

NIST Recommendation

The National Institute of Standards and Technology (NIST) of the US Government has stated that certificates signed with 1024 bit RSA keys should not be used to protect data after 2010. They recommend that all root certificates after this date should be of at least 2048 bit key length.

 

CA/B Forum

The Certificate Authority/Browser (CA/B) forum has mandated that all Extended Validation (EV) certificates with a life-cycle past December 31st , 2010 be 2048-bit.

 

 

--Jeff C.

 

From: [mailto:] On Behalf Of David Langenberg
Sent: Thursday, September 05, 2013 4:53 PM
To:
Subject: Re: [Assurance] SHA-2 Update

 

Well, my concern is more about Protected Channels and TLS.  After Dec 31, SHA1 is no good for the digital signatures used in TLS.  Even if you don't consider HMAC to be a "digital signature" you still wind up with the problem of SP 800-131A listing SHA1 as 80 bit and 80 bit for HMAC generation expires Dec 31.  Therefore, your TLS Connection by the user-agent to the Identity Provider needs to be using at least TLS1.2 with a SHA2 HMAC which in my testing wasn't available wide-spread in browsers until just this summer.  The result of us not being able to still use TLSv1 after Dec 31 will mean massive breakage of users who are not running recent browsers.  

 

Dave

 

On Thu, Sep 5, 2013 at 2:42 PM, Ann West <> wrote:

Hence your concern of the matter. ;)

 

Thanks for asking about this, Dave.

 

From: David Langenberg <>
Reply-To: "" <>
Date: Thursday, September 5, 2013 4:39 PM
To: "" <>
Subject: Re: [Assurance] SHA-2 Update

 

Heh, I could've told you we'd fail that test miserably.  IIRC only the most recent release of RHEL had the proper openssl libs in place to handle SHA-2.  In our implementation just about every unix machine that needed to have "Protected Channels" got it's own custom build of OpenSSL installed.


Dave

 

On Thu, Sep 5, 2013 at 2:22 PM, Ann West <> wrote:

Per our Assurance call yesterday, below is an update on the SHA-2 issue.  

 

The InCommon Assurance Advisory and Technical Advisory Committees are investigating state of SP support of SHA 256 per the NIST requirement which calls for discontinuing use of the SHA-1 digest function or hash algorithm in digital signatures effective January 1, 2014 and recommends using any of the digest functions known collectively as SHA-2 for use in digital signatures. For initial background and early thoughts on the issue, see: https://spaces.internet2.edu/display/InCAssurance/Transition+to+SHA-2 

 

Tom Scavo, InCommon Ops, is working with Tom Barton of the AAC/TAC and  several campus testers to probe federation SPs. (For investigation methodology, see:

 

The campuses  testers include:

  • University of Iowa
  • Virginia Tech
  • UW-Milwaukee
  • University of Nebraska

Given early results, the TAC observed that the majority of outright failures come from three organizations:

 

1. Carnegie Mellon (30)

2. University of Chicago (21)

3. Highwire Press (19)

 

Further testing demonstrated a direct link between older versions of openssl and SHA-2 incompatibility. Tom is  now refining his script to iterate over all SP and their endpoints to allow deeper probing. Stay tuned for final outcomes and recommendations. 

 

Ann West

Assistant Director,

InCommon Assurance and Community

Internet2 based at Michigan Tech

 

office: +1.906.487.1726 



 

--
David Langenberg

Identity & Access Management

The University of Chicago



 

--
David Langenberg

Identity & Access Management

The University of Chicago




Archive powered by MHonArc 2.6.16.

Top of Page