[cabfpub] Serial Number Entropy

Ryan Sleevi sleevi at google.com
Mon Aug 11 12:24:26 MST 2014


On Mon, Aug 11, 2014 at 11:53 AM, Ben Wilson <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: https://cabforum.org/pipermail/public/attachments/20140811/3c554e7c/attachment.html 


More information about the Public mailing list