Let us leave the trust anchors alone. Your challenge of protecting
trust anchors does not change even if you use SHA 512 or next generation
hash function yet to be determined.
[mailto:saag-bounces(_at_)ietf(_dot_)org] On Behalf Of
Sent: Tuesday, December 30, 2008 5:02 PM
To: RL 'Bob' Morgan
Cc: ietf-pkix(_at_)imc(_dot_)org; ietf-smime(_at_)imc(_dot_)org;
Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate
Regardless of that, the authors of the MD5 paper are correct: trust
anchors signed with MD5 are highly questionable as of today (well,
actually, since they published their last paper). Hopefully, the
maintainers of the popular trust anchor repositories (Microsoft,
Mozilla, etc.) will yank out the trust anchors signed with MD5 (and
MD2!) as soon as possible.
This is a different claim than "CAs should stop issuing certs with
MD5 signatures", which is what I as an amateur take away from a
quick scan of the material. Obviously MD5 is suspect in various
ways, but does this new work lead to the conclusion that MD5-signed
roots are untrustworthy today?
Replacing a root is a much bigger deal then changing signing
- RL "Bob"
CAs should have stopped issuing certs with MD5 signatures 4 years ago,
when the first practical attacks on MD5 were published.
Now it would be more correct to say that "relying parties should treat
as invalid any certificate chain that contains an MD5 (or MD2, MD4)
Since in the HTTPS context the relying parties are the browsers, it
falls to the vendors (if Microsoft leads, everyone will follow) to, as
Paul said, yank the trust anchors.
It should be noted, though, that yanking the trust anchors is not
enough. You really should change the relying party to not recognize
this algorithm. Otherwise, it's perfectly valid for a CA whose
certificate is signed with SHA1 to sign an intermediate CA certificate
with MD5 (although they usually don't do that, I hope)
Email secured by Check Point
saag mailing list