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

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

score 7 · Accepted Answer · edited Oct 07 '21 at 08:46

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

Thanks for your very informative answer. The last question would be, if there are CAs, which differ in their ordering style of issuers and subjects. E.g. CA "A" starts with the commonName and e.g. ends with an emailAddress and CA "B" starts with the emailAddress and ends with the commonName? — duesee, Oct 12 '15 at 17:34
That has more to do with what's required from the specifications. In general, it goes from country, organisation, OU, then CN and/or e-mail address. For things like HTTPS, e-mail addresses are rarely included. The CN would tend to be the most specialised entry. There were also debates regarding what's most "specialised", this was mostly clarified in RFC 6128. In addition, some tools (some of the OpenSSL output, but that depends on the command) would produce a text representation that's in reverse order from Java (RFC 2253) for example. — Bruno, Oct 12 '15 at 18:09
@Bruno SET is unordered only in general ASN.1. But when DER encoding is used `There is an order to the components, namely ascending order by tag.` See Section 5.14 [here](http://luca.ntop.org/Teaching/Appunti/asn1.html). — pepo, Oct 13 '15 at 07:27

score 3 · Answer 2 · edited Oct 07 '21 at 11:07

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.

Thank you for that RFC1779 Link! I've been trying to figure out how to cleanly order the structure we fall under here and that link helped greatly. The takeaway: One can have multiple 'key' instances, just keep them ordered. (CN=MyGroupName_CertPurpose, OU=CorpSiloA, OU=CorpBranchB, O=CorpName, L=MyCity, ST=MyRegonCode, C=MyCountryCode) — Reahreic, Feb 28 '23 at 13:06

score 3 · Answer 3 · edited Oct 07 '21 at 10:53

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

just for reference. IIRC, Microsoft do exact binary match when comparing distinguished names in certificates (especially, when building certificate chains). This means that attribute order is important for their validation logic. — Crypt32, Oct 12 '15 at 16:09

score 1 · Answer 4 · answered Jun 06 '19 at 20:55

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.

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

4 Answers4