On Jan 2, 2009, at 3:29 PM, Joe Greco wrote:
* Joe Greco:
It seems that part of the proposed solution is to get people to move from MD5-signed to SHA1-signed. There will be a certain amount of resistance. What I was suggesting was the use of the revocation mechanism as part of the "stick" (think carrot-and-stick) in a campaign to replace MD5- based certs. If there is a credible threat to MD5-signed certs, then forcing their retirement would seem to be a reasonable reaction, but everyone here knows how successful "voluntary" conversion strategies typically are.
A CA statement that they won't issue MD5-signed certificates in the future should be sufficient. There's no need to reissue old certificates, unless the CA thinks other customers have attacked it.
That would seem to be at odds with what the people who documented this problem believe.
I do not wish to be rude, so don't think that's my intent--however, clarification is required here I believe. From section 7 of http://www.win.tue.nl/hashclash/rogue-ca/ : "An interesting question is whether CAs should revoke existing certificates signed using MD5. One may argue that the present attack scenario has in principle been possible since May 2007, and that therefore all certificates (or all CA certificates) signed with MD5 that have been issued after this date may have been compromised. Whether they really have been compromised is not relevant. What is relevant is that the relying party who needs to trust the certificate does not have a proper way of checking whether the certificate is to be trusted or not. One may even argue that all older certificates based on MD5 should be revoked, as for an attacker constructing rogue certificates it is easy to backdate them to any date in the past he likes, so any MD5-based certificate may be a forgery. On the other hand, one may argue that the likelihood of these scenarios is quite small, and that the cost of replacing many MD5- based certificates may be substantial, so that therefore the risks of continued use of existing MD5-based certificates may be seen as acceptable. Regardless, MD5 should no longer be used for new certificates." Note that they aren't actually recommending that all certs with MD5 signatures be replaced. The authors present two sides of the argument. The only absolute statement is that MD5 should not be used to sign _new_ certificates. This is because the attack doesn't allow the impersonation of the vulnerable CA; the attack merely creates a new intermediate CA that maintains the "chain of trust", so that certificates issued by the rogue intermediate CA will be trusted by most browsers. The weakness isn't that the vulnerable CA root certificate is signed by MD5, the weakness is that it uses MD5 to sign CSRs. Since I'm probably not explaining this very well, a picture is worth a thousand words: http://www.win.tue.nl/hashclash/rogue-ca/images/certificate4.png Additionally, from second 8: "Question. Are all digital certificates/signatures broken? Answer. No. When digital certificates and signatures are based on secure cryptographic hash functions, our work yields no reason to doubt their security. Our result only applies when digital certificates are signed using the hash function MD5, which is known to be broken. With our method it is only possible to copy digital signatures based on MD5 between two specially constructed digital certificates. It is not possible to copy digital signatures based on MD5 from digital certificates unless the certificates are specially constructed. Even so, our result shows that MD5 is NOT suited for digital signatures. Certification Authorities should stop using the known broken MD5 and move to the widely available, more secure alternatives, such as SHA-2." and "Question. What should websites do that have digital certificates signed with MD5? Answer. Nothing at this point. Digital certificates legitimately obtained from all CAs can be believed to be secure and trusted, even if they were signed with MD5. Our method required the purchase of a specially crafted digital certificate from a CA and does not affect certificates issued to any other regular website." My apologies if you were commenting on some other aspect, or if my understand is in some way flawed. -- bk CA cert: http://www.smtps.net/pub/smtps-dot-net-ca-2.pem