Changing the order of extensions does not change their meaning.
Actually, a CA could put the extensions in random order for various
certificates. The attack will still work if the certificate size does
not change.
-----Original Message-----
From: cfrg-bounces(_at_)irtf(_dot_)org
[mailto:cfrg-bounces(_at_)irtf(_dot_)org] On Behalf Of
Ben Laurie
Sent: Thursday, January 01, 2009 10:06 AM
To: Peter Gutmann
Cc: ietf-pkix(_at_)imc(_dot_)org; mike-list(_at_)pobox(_dot_)com;
cfrg(_at_)irtf(_dot_)org;
saag(_at_)ietf(_dot_)org; ietf-smime(_at_)imc(_dot_)org
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate
On Thu, Jan 1, 2009 at 11:17 AM, Peter Gutmann
<pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz> wrote:
Mike <mike-list(_at_)pobox(_dot_)com> writes:
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).
Surely the whole point of DER is that there's only one correct way to
encode any particular certificate?
So, either extensions must be sorted, or changing their order changes
their meaning. Either way, nothing can be reordered.
_______________________________________________
Cfrg mailing list
Cfrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/cfrg