Actually, you can buy any of the prizes at Chuck E Cheese-- they charge you $.01 per ticket!

Ben, Thanks for the positive review. I know the book has pissed some people off, especially when I take on their particular sacred cows (e.g., intrusion detection). But, the Schneier chapter isn't meant to piss him off, I have no beef with him whatsoever. I just think the fanboys do the world a disservice by not thinking for themselves, especially when they draw from material that's a decade old. John

For most people, this will put them at MORE risk than selectively blacklisting rogue certs as they are identified:

1. It is very likely that no bad guys will ever get a chance to use this attack. For them to use the next MD5 attack they would need to be able to predict a sequence number several months in advance, instead of several days.
2. Any attack of this type will be pretty obvious from the CA's logs. CAs that sign with MD5 will need to invest some man power in manual validation, but this is not a huge cost. This is how you find the unknown certs, if there are any (which is highly likely).
3. Since many legitimate web sites use SSL/TLS certs from RapidSSL, taking your advice for remediation will just give them pop-ups on some legitimate sites, which is likely to desensitize them. When people get enough pop-ups for stuff that isn't a risk, it's well known that they start just clicking through, so this would put the average person more at risk.

The relative security between MD5 and SHA1 is currently more or less linear to the digest size, though more work has been done on practical applications on MD5, so it is a little weaker relatively. For cases where the birthday paradox applies, you lose 1/2 your bit length in the brute force case.

There's some confusion here. I'll try to clear it up. Let's imagine that you've got FredCA that got its CA credentials from Verisign. Let's say FredCA is perfectly legitimate. That means that they have a cert with a signature on it from Verisign. Let's say that Citibank wants to get a leigitimate certificate and they go to FredCA. The certificate they get back is signed by FredCA.

When your browser goes to Citibank, it gets to see the entire certificate chain (the server sends back a PKCS blob of the entire chain). It validates not only that the Citibank cert was signed by FredCA, but it also validates the signature on FredCA's certificate. If it trusts Verisign, then it makes sure that the certificate is definitely one it knows maps to verisign, and then everything is trusted.

A lot of people here seem to believe that the attack is that a bad guy can take the cert that FredCA endorsed for CitiBank or the cert that Verisign endorsed for FredCA (as long as the signature uses MD5), and steal the signature for their own certificate. If that were true, then we could not trust any certificate signed by MD5. Good thing that most certs have been issued via SHA1 for a while.

But, that is not true. In this attack, the bad guy can generate a pair of certificates, one that the CA signs, and another for which the same signature happens to be valid. You cannot do this to any cert on the internet, the pair of certificates have to be specially crafted.

In this attack, the bad guy gets FredCA to sign a certificate for DummyOrg, but when the bad guy created the DummyOrg cert, he created a matching cert for his own CA, call it EvilCA. Since the certs were created together in a particular way, the bad guy can take the signature off the DummyOrg cert and paste it onto the EvilCA cert and everything will work.

With the EvilCA cert, he can create certificates that claim to be from any site on the internet, even though they are not. When they get to the browser, the browser looks at the whole chain, and it looks good, even though FredCA never signed the EvilCA certificate. However, once we blacklist the signature for the DummyOrg cert, we will immediately blacklist everything endorsed by EvilCA, because when a browser goes to validate the whole chain, they'll see that the certs are issued by a blacklisted CA, and thus would know that the certificate is fake.

Also, note that there's a good reason to believe this hole will be closed well before any bad guys actually try the attack. At most, the world will have to blacklist a small handful of rogue CA certs.

Additionally, for the CAs other than RapidSSL, it's not clear they can be attacked easily. As far as I know, they all usually sign with SHA1. I don't know how you would get them to choose MD5, but I suspect none of them will do it anymore after this. And, even if they did, you would need to know how to predict their sequence number and the date values they add to the certificate. With RapidSSL that was all automated and very predictable. It could be with the other CAs, but it isn't necessarily the case.

Hope this helps.