Ordering of RDN attributes in a CA's certification sign process

I have difficulties to understand the ordering of the attributes (AttributeTypeAndValue) in the RDN (RelativeDistinguishedName).

Here are the relevant ASN.1 definitions (taken from www.in2eps.com):

TBSCertificate

TBSCertificate ::= SEQUENCE {
    [...]
    subject    Name,
    [...]
}

Name

Name ::= CHOICE {
    rdnSequence RDNSequence
}

RDNSequence

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName

RelativeDistinguishedName ::= SET SIZE (1 .. MAX) OF AttributeTypeAndValue

AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {
    type AttributeType,
    value AttributeValue
}

AttributeType

AttributeType ::= OBJECT IDENTIFIER

AttributeValue

AttributeValue ::= ANY -- DEFINED BY AttributeType

If I create a CSR containing "/CN=CommonNameX/O=OrganizationX/..." (in this specific order), how does a CA constructs a certificate out of this?

How will the certificate be constructed when setting the subject to ".../O=OrganizationX/CN=CommonNameX/" (same in reversed order)?

As far as I know the ordering of the RDN attributes is important when verifying certificate chains. Therefore, I assume there must by some detailed specification available?

More importantly, I would also like to know if there are different CAs using different orderings. If so, can someone point out some CAs?

EDIT:

After reading the first answers, I realized that I was asking for something very different than intended. To cut it short: the intended question was, if the ordering of the elements in the sequence of RDNs is important.

Sorry for the confusion, I will rectify the title of the question afterwards...

If I create a CSR containing "/CN=CommonNameX/O=OrganizationX/..." (in this specific order), how does a CA constructs a certificate out of this?

A decent CA should practically ignore the DN submitted in the CSR and build the Subject DN from information it has verified. That is, usually, they'll put their own Country, Organization, OU (and so on) depending on their CA policies. They'll change the CN to be that of the host you've applied for (for example, or whatever else is relevant from the application process depending on the type of certificate). What's in the CSR is useful to keep track of the identity of the public key submitted during the application process, but it's at best useful for administrative purposes.

As far as I know the ordering of the RDN attributes is important when verifying certificate chains. Therefore, I assume there must by some detailed specification available?

Yes, the order matters RDNSequence is indeed a SEQUENCE OF RelativeDistinguishedName. Each RDN is itself a set (which is unordered) of AVAs (Attribute Value Assertion / AttributeTypeAndValue): SET SIZE (1 .. MAX) OF AttributeTypeAndValue.

The matching rules for each RDN content (the set of AVAs) and each DN (the sequence of RDNs) is defined in RFC 5280:

   Two naming attributes match if the attribute types are the same and
   the values of the attributes are an exact match after processing with
   the string preparation algorithm.  Two relative distinguished names
   RDN1 and RDN2 match if they have the same number of naming attributes
   and for each naming attribute in RDN1 there is a matching naming
   attribute in RDN2.  Two distinguished names DN1 and DN2 match if they
   have the same number of RDNs, for each RDN in DN1 there is a matching
   RDN in DN2, and the matching RDNs appear in the same order in both
   DNs.  A distinguished name DN1 is within the subtree defined by the
   distinguished name DN2 if DN1 contains at least as many RDNs as DN2,
   and DN1 and DN2 are a match when trailing RDNs in DN1 are ignored.

Essentially, RDNs in a DN need to be in the correct order (SEQUENCE is ordered), but the order of AVAs don't (SET is not ordered): "Two relative distinguished names RDN1 and RDN2 match if they have the same number of naming attributes and for each naming attribute in RDN1 there is a matching naming attribute in RDN2."

In reality, most CAs only use one attribute value pair per RDN. I wouldn't be surprised if a number of implementations (not necessarily part of the SSL/TLS stack, but say, authentication/authorisation layers on top of it) that rely on text serialisation (RFC 2253 for example) would get confused by multiple AVAs (more specifically by the fact their order doesn't matter within each RDN, so you could have two distinct text serializations that are in fact equivalent).