Len Sassaman <Len(_dot_)Sassaman(_at_)esat(_dot_)kuleuven(_dot_)be> writes:
On Thu, 10 Jun 2010, Simon Josefsson wrote:
I don't see how that gains you anything: you still need to make clients
place trust in the new CA, and if the attacker has that ability, all
bets are off.
The clients trust the new CA because it is an intermediate CA chained
to the original, MD2-signed top-level CA. The intermediate cert is
then treated with the same validity as *any* intermediate cert
generated by that top-level cert -- since the top-level cert's
signature verifies correctly on the intermediate cert, of course.
Do you understand the attack now?
Yes, I do, but that attack is not caused by a MD2 root. The attack is
caused by software trusting MD2 to verify digital signatures. I believe
the latter has been resolved in most security libraries already (it
certainly has been resolved in GnuTLS, since January 2009, which treats
both MD2 and MD5 as insecure).
The former case (a MD2 root) is not a problem by itself, as far as I can
tell, which is what I originally stated.
As long as MD2 roots have not been shown to be a problem, by themselves,
protocols and software will need to continue implement MD2 for
operational reasons. There are still several MD2 roots in recently
shipping operating systems. For example, my Ubuntu 10.04 LTS system has
these RSA-MD2 roots:
./mozilla/Verisign_Class_1_Public_Primary_Certification_Authority.crt:
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 1 Public Primary Certification
Authority
./mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification
Authority
./mozilla/Verisign_RSA_Secure_Server_CA.crt
Issuer: C=US,O=RSA Data Security\, Inc.,OU=Secure Server Certification
Authority
./mozilla/Verisign_Class_2_Public_Primary_Certification_Authority.crt
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 2 Public Primary Certification
Authority
Right now, I think my preference would be to update RFC 1319 with
something like Sean's document, to alert everyone of the security
issues, but let the status of the algorithm description remain
Informational.
/Simon
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime