Also, for the actual attack, the ordering of extensions will not work as
long as the certificate size does not change. If you look at the actual
attack, collision block in the real certificate is up to the SPKI. The
extension values from the real certificate are simply copied in the
tumor of the rogue certificate.
Given the property that if H(M) = H (M') then H(M | X) = H (M' | X), the
attacker simply copies the extensions from actual certificate in the
tumor.
-----Original Message-----
From: saag-bounces(_at_)ietf(_dot_)org
[mailto:saag-bounces(_at_)ietf(_dot_)org] On Behalf Of
Peter Gutmann
Sent: Thursday, January 01, 2009 6:18 AM
To: ietf-pkix(_at_)imc(_dot_)org; mike-list(_at_)pobox(_dot_)com
Cc: ietf-smime(_at_)imc(_dot_)org; cfrg(_at_)irtf(_dot_)org;
saag(_at_)ietf(_dot_)org
Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue
CAcertificate
Mike <mike-list(_at_)pobox(_dot_)com> writes:
We are simply not vigilant enough. This issue has been on our plate
since 2004.
SHA-1 is next and neither the client side vendors nor the big
Enterprises have pushed to move to SHA-256.
There is a simple fix -- a CA can just reorder the extensions prior to
issuing a certificate.
That's actually a nice fix, but unfortunately not universally
applicable: for
some types of signed data (e.g. S/MIME attributes) the DER rules require
sorting the encoded extensions, so there's only one valid order for them
(and
some applications actually check for this, so you have to do it or sig
checks
will start failing).
Peter.
_______________________________________________
saag mailing list
saag(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/saag