[cabfpub] Serial Number Entropy

Ben Wilson ben.wilson at digicert.com
Mon Aug 11 19:46:03 UTC 2014


Thanks, Ryan.  I wasn’t trying to raise resurrect MD5 (or SHA1), I’m just saying that we ought to revisit what we say about serial number entropy and the reasons for it.  I had forgotten that CAs were told not to place entropy into the Date fields—someone on this other call (Federal PKI) suggested that it was a better place to embed entropy.  As you note, there are more sophisticated methods to address this—which leads to my underlying intent – is the CA/B Forum ready to tackle a more sophisticated or complex formulation of the entropy requirement that takes into account current information and hashing algorithm strengths?  Or should we hold off on discussing this until after January 2016 when SHA1 certificates are no longer issued ?

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Monday, August 11, 2014 1:24 PM
To: Ben Wilson
Cc: CABFPub
Subject: Re: [cabfpub] Serial Number Entropy



On Mon, Aug 11, 2014 at 11:53 AM, Ben Wilson <ben.wilson at digicert.com<mailto:ben.wilson at digicert.com>> wrote:
The purpose of this email is just to place a reminder for us or get the conversation going if anyone wants to discuss this suggestion from a call I was on today –

Could the CA/B Forum (and Browser root programs) revise/update its response to the 2008 Sotirov MD5 pre-image attack?

I'm not sure what you expect from the Browser Root Programs, or what call you were on, but
- OS X / Safari (and Chrome on OS X) - Has disabled MD5 support since OS X 10.9 - http://support.apple.com/kb/HT6011
- Chrome (on all platforms) - Treats MD5 the same as untrusted root / any other cert with errors since Chrome 18 (aka December 2011) - https://code.google.com/p/chromium/issues/detail?id=101123
- Firefox (on all platforms, except where a distro/sys admin overrides) - Disallows MD5 in signatures since FF16 -  https://bugzilla.mozilla.org/show_bug.cgi?id=650355
- IE - As of February 2014, Windows Vista+ won't allow MD5 for signatures for CAs in their root program - https://technet.microsoft.com/library/security/2862973


The commenter’s point was that today there are other ways to reduce the risk of this pre-image attack in addition to 20-bit entropy in serial numbers (which we specify in the Baseline Requirements for SSL and the Code Signing draft).  Those include-  variable issuance/expiration times (e.g. minutes, seconds, etc.) and better hash algorithms (not SHA1).

Sure. But MD5 is dead. Why would the commenter wish to revive it?

As a reminder for CAs, SHA-1 is also not long for this world. While there may be attempts to prolong it's life, it's better to start transitioning away. For example, it's highly likely that a future version of Chrome will treat certificates with validity periods (measured by NotAfter) beyond the hard sunset date (1/1/2017) that Microsoft has proposed as certificates with errors, warning the user and treating such resources as mixed content (requiring user interaction).

Let's also keep in mind that these mitigations are not sanctioned by the root programs. For example, 20-bits of entropy is insufficient for the Microsoft Root Program ( http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx ) , which requires 64-bits (eight bytes)

In the same section, Microsoft also makes it clear that CAs are no longer allowed to place entropy into the Date fields. See http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx#_edn12 for a further discussion.

So really, the ONLY acceptable mitigation is move to better hash algorithms, and if you're doing that, it SHOULD be SHA-256, not SHA-1.

As a final reminder, the Baseline Requirements state SHA-1 "MAY be used with RSA keys until SHA-256 is widely supported by browsers used by a substantial portion of relying-parties worldwide". Given that Windows XP, a historical complaint from CAs, supports SHA-256 since SP3, I think the burden is on CAs to demonstrate that there exists a population sizeable enough that SHA-256 support cannot be called "substantial".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140811/baf3ca7b/attachment-0003.html>


More information about the Public mailing list