<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 11, 2014 at 11:53 AM, Ben Wilson <span dir="ltr"><<a href="mailto:ben.wilson@digicert.com" target="_blank">ben.wilson@digicert.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">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 –
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Could the CA/B Forum (and Browser root programs) revise/update its response to the 2008 Sotirov MD5 pre-image attack? </p></div></div></blockquote><div><br></div><div>I'm not sure what you expect from the Browser Root Programs, or what call you were on, but</div>
<div>- OS X / Safari (and Chrome on OS X) - Has disabled MD5 support since OS X 10.9 - <a href="http://support.apple.com/kb/HT6011">http://support.apple.com/kb/HT6011</a></div><div>- Chrome (on all platforms) - Treats MD5 the same as untrusted root / any other cert with errors since Chrome 18 (aka December 2011) - <a href="https://code.google.com/p/chromium/issues/detail?id=101123">https://code.google.com/p/chromium/issues/detail?id=101123</a></div>
<div>- Firefox (on all platforms, except where a distro/sys admin overrides) - Disallows MD5 in signatures since FF16 -  <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=650355">https://bugzilla.mozilla.org/show_bug.cgi?id=650355</a></div>
<div>- IE - As of February 2014, Windows Vista+ won't allow MD5 for signatures for CAs in their root program - <a href="https://technet.microsoft.com/library/security/2862973">https://technet.microsoft.com/library/security/2862973</a></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple">
<div><p class="MsoNormal">
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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).</p></div></div></blockquote><div><br></div><div>Sure. But MD5 is dead. Why would the commenter wish to revive it?</div>
<div><br></div><div>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 <b>hard</b> 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). </div>
<div><br></div><div>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 ( <a href="http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx">http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx</a> ) , which requires 64-bits (eight bytes)</div>
<div><br></div><div>In the same section, Microsoft also makes it clear that CAs are no longer allowed to place entropy into the Date fields. See <a href="http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx#_edn12">http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx#_edn12</a> for a further discussion.</div>
<div><br></div><div>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.</div><div><br></div><div>As a final reminder, the Baseline Requirements state SHA-1 "MAY be used with RSA keys until SHA-256 is widely supported by <b>browsers</b> 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".</div>
</div></div></div>