[cabfpub] Serial Number Entropy

Erwann Abalea erwann.abalea at opentrust.com
Tue Aug 12 01:20:46 MST 2014

That was a collision attack, not a pre-image one (MD5 is still pre-image 
resistant -- or not a useful enough target anymore).

notBefore/notAfter isn't a good place to add entropy to: 16bits max for 
time components of one of notBefore/notAfter, if a CA is allowed to play 
with the date part, it is then implicitely allowed to play with 
information that will be compared to effective and hard sunset dates; 
something already known to be problematic.

The necessary entropy was added to mitigate collision attacks while 
allowing legacy hash functions as a transition. That raised the 
attacker's bar from "collision attack" to "random prefix collision 
attack". It's strictly not necessary *while* the hash function is 
collision resistant. Nevertheless, I think it's best to be conservative 
and keep this requirement, and let browsers set sunset dates for 
declining crypto functions/parameters (<2048 bits RSA, MD5/SHA1, ...) 
based on theoretical results.

(If we allow for Ed25519 or similar schemes, we'll have this "collision 
protection" for free, AIUI.)


Le 11/08/2014 21:46, Ben Wilson a écrit :
> 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".
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140812/aaa21047/attachment-0001.html 

More information about the Public mailing list