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

Question

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...

Answer 1

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).

Answer 2

(As an addendum to #CryptoGuy's answer some background on DN comparison)
The basic IETF specification on Internet X.509 Public Key Infrastructure Certificates is RFC 5280.
Rules for comparing distinguished names are specified in Section 7.1. They are:
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.
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. (Note: There is no requirement on the order of appearance of the naming attributes!)
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.
Thus, two DNs have to be considered equal even if they differ in the order of naming attributes in some matching relative distinguished name.
Unfortunately there is a relevant number of programs in the wild which fail in this respect. To play it safe, therefore, simply put but one naming attribute into each RDN.
Concerning the tree structure mentioned by #CryptoGuy in his answer, it a bit more formally is defined as follows in the same section 7.1:
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.

Answer 3

It is expected behavior. RDN attributes are parts of X.500 distinguished names, which is a tree. The tree is built starting from root node and by adding nested subnodes. For example, a subject CN=John Wayne, OU=IT Department, DC=contoso, DC=com would be built as follows:
Root/top-level node: com
Sub node within root node/domain: contoso
Organization Unit within domain: IT Department
Common name, end entity, or principal: John Wayne
this is why RDNs are placed in reverse order. For convenience, certificate viewers reverse RDN attribute ordering where principal name is displayed first.
If I create a CSR containing "/CN=CommonNameX/O=OrganizationX/..." (in this specific order), how does a CA constructs a certificate out of this?
CA will not change the RDN attribute order in the subject name because they are already reversed in the certificate request. You can open generated request file in any ASN.1 viewer to get actual order of RDN attributes in binary request.
More importantly, I would also like to know if there are different CAs using different orderings. If so, can someone point me to some available CAs?
all CAs I worked with behave as described above (use reverse ordering when encoding X.500 names).
edit: representation of distinguished names is defined in [RFC1779]
edit2 (to RDN sequence order importance question): as it was already said, it is important. When CA signs certificate, it shall place RDNs in the Issuer field in the same order as they appear in its own certificate's Subject field.

Answer 4

The primary answer to this question is accurate except for the ordering of RDNs in DER-encoded (X.690) ASN.1.
DER encoding of SET OF ASN.1 constructed types means that you HAVE TO sort all Attribute-Type-And-Value items comparing their DER encodings (shorter DER encodings have to be zero-filled while comparing).
Source: ITU-T X.690 11.6 'Set-of components'.
Please note that the vast majority of X.509v3 certificates is indeed DER-encoded today.