Such an archive would allow CAs to go back and look for requests which conformed in some way to known attack data, after an attack was discovered. As it stands, they have no way of knowing how many MD5 collision certs have been maliciously signed before this flaw was announced.

One rule of thumb I use when evaluating protocols is that a signer should always know exactly what he is signing. The more random fields or user-specified fields provided, the more “wiggle room” for an attacker to add potentially malicious data. Conversely, adding random data to a server-controlled area can help increase the attacker uncertainty.

What crypto designers should do is pay more attention to implementation details, including adding defense-in-depth from the beginning. A lot of SSL accelerator implementers complained about having to implement two different hash functions, and it did seem silly at the time. A theoretician who didn’t care about implementation details would never have done this hack, since you should “just use a secure hash function”. However, my credit card is never transmitted over theoretical algorithms, it’s sent over SSL/TLS implementations running on x86 hardware.

As you have so rightly pointed out in the past, bad crypto happens when you start to rely on assumptions, and it should not be necessary for a serial number to perform any other function than that of a unique identifier. Being unpredictable was never part of the deal.

Of course, the fundamental problem is that MD5 is broken, and should not be used. That is a given. However, as the researchers point out in their presentation, we need defense in depth. Having non-user assigned, unpredictable data in the cert would at least provide us with some time to switch from a broken hash to something better, if (for example) a devastating chosen prefix attack on SHA1 is published tomorrow.

I find it interesting as well that the attack appears to rely on the fact that the CA being used issued the certificate exactly 6 seconds after issuing the CSR (otherwise they could not predict the certificate expiry, which is set to one year after the issue time according to the presentation). The devil in me can’t help but wonder if this was to prevent timing attacks, and their implementation has just exposed another weakness. If they had implemented random delays instead, this attack would quite possibly be impractical, depending on the size of the delay.

However, in the real world, things tend not to change if there is not a ‘real and present danger’ in the form of a demonstrable attack. This research proves this point, which you correctly note. So maybe even defense in depth is of no use; it is in the nature of (some) people to ignore possible until it is the practical.