Subject: Re: order of name attributes in certificates, suggestion for 3280 bis

From: Tom Gindin <[email-masked]>
Date: Tue, 4 Apr 2006 21:40:49 -0400

Peter:

        Section 4.1.2.4 describes the "Name" field as hierarchical, in the 
context of the Issuer (first text sentence on p. 19 of RFC 3280).  Section 
4.1.2.6 for Subject points back to 4.1.2.4.  What else should be added? It 
wouldn't hurt, I suppose, if we pointed out that the order of the 
attributes is highest-order first, and thus that country always precedes 
state, organization always precedes OU, and common name, serial number or 
the personal name fields normally follow any of those four attributes (or 
locality) which are present.
        I wonder if putting this in 3280-bis would accomplish much, 
though.  Do you think that the absence of a note about the order of 
attributes in the Issuer definition of RFC 3280 is a major reason for CA's 
creating DN's with arbitrarily ordered attributes?  This is especially 
doubtful since RFC 3280 C.2 and C.3 currently give sample certificates 
with both the Issuer and Subject having attributes in an appropriate order 
(C, O, OU, and CN in the Subject) although the text description gives them 
in reverse order.  3280-bis uses only DC and CN, but again CN is last.

                Tom Gindin

Peter Sylvester <[email-masked]>
Sent by: [email-masked]
04/04/2006 12:58 PM
 
        To:     [email-masked]
        cc: 
        Subject:        order of name attributes in certificates, 
suggestion for 3280 bis

Hi,

It seems that many people regularily put RDNs in in the wrong direction
or sometimes almost arbitrary order into certificate DNs.

One of the reasons are different textual representaion that are used by
different tools and protocol (like LDAP)

When reading 3280 it is not obvious that people are aware the hierarchical
nature of the name, the only indication may be the specification of the
permitted/excluded name tree.

Would it be possible to include a reminder to 3280bis in some way?

Peter

--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

#### smime.p7s has been removed from this note on April 04, 2006 by Tom 
Gindin

---

From: Alicia da Conceicao <[email-masked]>
Date: Wed, 5 Apr 2006 03:46:35 -0400 (EDT)

> in reverse order.  3280-bis uses only DC and CN, but again CN is last.

There are many X500 attributes that can be included in the RDN's of an
arbitary Name field.  As Peter mentioned, the Directory Information
Tree hierarchy specified in X500 can be used to order some of these
attributes.

But there needs to be specific references to rigid sorting rules that
can be applied to arbitary attributes.  Should surName (2.5.4.4) be
specified before countryName(2.5.4.6)?  Should givenName (2.5.4.42)
which is a subtype of surName be specified before the organizationName
(2.5.4.10)?

Most crypto applications (web-browsers, S/MIME e-mail clients, IKE
servers, etc.) do not seem to care about the ordering of attributes
in the Name field for a certificate subject.  From what I can tell,
only a few LDAP applications, which do a DER to text rendering of
the Name field, are affected by the ordering of attributes.

So is important to stress ordering and reiterate rigid sorting rules
for arbitary attributes, if you want people to sort them consistantly.

Alicia.

---

From: Tom Gindin <[email-masked]>
Date: Thu, 6 Apr 2006 23:44:18 -0400

Alicia:

        The ordering rules which apply to DN's cannot be applied to 
arbitrary attributes.  I think there are some fairly widely agreed 
heuristics which cover most actual names, but that's it.  Although the 
following is not exhaustive, here's much of what I know, in a relatively 
simple form:
        Most practical DN's have a high-order section (a group of 
consecutive RDN's beginning with the DN's first RDN) in one of the 
following formats:
        a)      Location specifier, with countryName the highest order 
attribute and the only mandatory one.  stateOrProvinceName is next when it 
is present, then localityName.  All attributes in the Location specifier 
occur only in single-valued RDN's, and they typically occur only once. 
Although streetAddress, for example, can be considered a location 
attribute it does not have to be part of a high-order section.
        b)      Organization specifier, with organizationName the highest 
order attribute and the only mandatory one.   OrganizationalUnitName is 
the other major attribute.  All attributes in the Organization specifier 
occur only in single-valued RDN's, and only organizationalUnitName occurs 
more than once.  The order of multiple organizationalUnitName's is 
significant.
        c)      Mixed location & organization specifier.  In this case, 
although the order of attributes within each specifier is mandatory, the 
order in which the two sorted lists of RDN's are merged is not. 
CountryName is usually higher-order than OrganizationName when both are 
present, but not always.
        d)      Domain specifier.  The only attribute occurring is 
domainComponent, typically more than once.  It occurs only in a 
single-valued RDN, and its order is the reverse order of a standard 
Internet domain name.  The TLD, such as "com" or "ca", comes first.

        A person's name, when present, can easily be represented either by 
commonName or by a multi-valued RDN containing surname and one or more of 
givenName, generationQualifier, and initials.  The order of attributes 
within a multi-valued RDN is determined by the DER sorting rules, which 
give well-defined but counterintuitive results (effectively, the length of 
the total encoding is the primary sort key, then the length of the object 
identifier, then the value of the object identifier).
        Other common attributes also come after those in the high-order 
specifiers.  The rules for their ordering are not as clear as the ones I 
have given above.

                Tom Gindin

Alicia da Conceicao <[email-masked]>
Sent by: [email-masked]
04/05/2006 03:46 AM
 
        To:     [email-masked]
        cc: 
        Subject:        Re: order of name attributes in certificates, 
suggestion for 3280 bis

Alicia.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 07 Apr 2006 15:30:05 +0200

X.521 suggests a Directory Information Tree structure. a/b/c are almost a
subset of this, if country name occurs, it is always the first attribut, 
locality and organisation
can be in any order (with or without a country before them). under 
Locality you
can have a residential person class and nothre lese or branch into the 
organisation
or oragn,isational units where you can add either an organistional 
person or role as
a leaf.

Furthermore, each prefix of a DN is also a possible entry in the 
directory which
is hierarchically superior in some sense.

> more than once.  The order of multiple organizationalUnitName's is 
You can have residential persons, they have a (country) locality and 
address/name.
> CountryName is usually higher-order than OrganizationName when both are 
In X521 country is always first. A country cannot be part of an 
organisation.
The attributes have a semantics. If you want to have the different 
counry branches
of an organisation, these should be organisational units, well, unless your
organisation is the "world company" :-)
> identifier, then the value of the object identifier).
Strictly speaking, there is no order defined between elements inside an 
RDN since it is a SET.
it is only the encoding in DER that is indeed not very intuitive but 
noone prohibits
an interface to show the set elements in a display always in a fixed 
order based on
the oids for example.

I have also seem examples where there a common as well as surname given 
in one RDN.

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorite'; 
die Liste mit zuru"ckgerufenen Zertifikaten finden Sie da auch.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 07 Apr 2006 17:59:18 +0200

> locality) which are present.
Where is said "in the context of the CA?"

Yes,  such kind of  hint  is what I am thinking about. The term hierarchical
is a bit easy to overlook. A reference to X.521 may be also useful.
where is said "in the context of the CA?"

A 'Name' type describes a name composed of  attributes.  The rdnSequence is
a hierarchy where the first component as the highest in the hierarchy. X.521
suggest a particular structure of names in the context of the directory, a
Directory Information Tree structure. When using the same attributes as  
in the
suggested structure, it is RECOMMENDED to follow the rules in X.521
in order to respect the semantics of each attribute. Not following the rules
may make it impossible to the extensions for permitted and excluded 
subtrees
(not only in cross certification environments).

As an example, when a name has a country attribute, this occurs in the
first element in the sequence.  Having a CommonName as the first
element may probably only useful for the Dalai Lama (with only this attribut
in the Name).

Users should be aware that different tools may not should the rdnSequence
in the same order. Since displaying a certificate shows (in general) the
Issuer and Subject, an inverted order in one of the names is easy to detect.

   Some of this could also be in an appendix similar to the ASN.1 notes.

> in reverse order.  3280-bis uses only DC and CN, but again CN is last.
The major error that I see all the time is that the order is inverse. 
since it is not clear
in which order things are displayed by tools, or better it is not clear 
depending
of the cultural whether 'first displayed' is highest or lowest.

An example of how to drive on the right side doesn't mean that it is 
forbidden
to drive on the wrong side.

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 8 Apr 2006 23:00:05 +0200

TG wrote:
>attribute and the only mandatory one.

Since RFC 3739 says this attribute MAY be present, I think that at least
from a PKIX horizon, there are no mandatory DN attributes at all. 
For this particular attribute it is worth mentioning that it can indicate
anything from citizenship, to that the CA has some kind of association
to that country.  I.e. this is only specified in certificate policy documents.

What attributes  you actually use and their order is in an enterprise PKI,
probably highly dependent on the directory schema used.   For TTP issued citizen
certificates like the ones used in many EU countries, the order of attributes
is of little importance, what is though really important is that they are properly
documented since they are to be interpreted by numerous independent
organizations and applications.

But it does not hurt to follow a convention but that is not the same thing
as calling it a standard.

Since the exact location of an organizationName attribute varies between
certificates, application software anyway have to traverse the entire subject
structure if they are not going to fail every now and then. As you already noted,
common PKI clients such as Internet Explorer and Firefox do very few assumptions
on attribute order.  I accidentally happened to reverse the DN attributes once,
but things continued to work exactly as good (or bad) anyway!

ADC wrote:
>for arbitrary attributes, if you want people to sort them consistently.

To change this is in 3280 bis may be possible but the effect of that on real
implementations would probably be limited.  To add such advices after
10 years of PKI deployment is a bit late IMHO.

The fact is that most PKI applications except for enterprise login,
actually only care about (and extract) a single attribute, alternatively
regard the entire DN string as a "blob".  This is also the reason why
there is no problem to solve unless we are talking about human RPs.
The latter may though be more helped by the logotype extension.

Anders Rundgren

---

From: Tom Gindin <[email-masked]>
Date: Tue, 11 Apr 2006 23:11:02 -0400

Anders:

        First, my suggestion was that if you have a Location specifier, 
countryName is mandatory, rather than that it is mandatory for all DN's. 
That is, you should never have either stateOrProvinceName or localityName 
without countryName.  Have you ever seen a DN which did?  Second, this 
advice is intended for CA's which are establishing naming conventions.  As 
you point out, most RP's should and do either treat DN's as binary blobs 
or convert them to character format and treat them as strings.  It is also 
common enough to verify one or two attributes in a DN, as S/MIME and 
SSL/TLS support (although oddly the only real reference to TLS' common use 
of validation I can find is in HTTPS - RFC 2818 section 3.1).  Does anyone 
know of common protocols which verify the order of DN attributes?

                Tom Gindin

"Anders Rundgren" <[email-masked]>
04/08/2006 05:00 PM
 
        To:     "Alicia da Conceicao" <[email-masked]>, Tom 
Gindin/Watson/IBM@IBMUS
        cc:     <[email-masked]>
        Subject:        Re: order of name attributes in certificates, 
suggestion for 3280 bis

to that country.  I.e. this is only specified in certificate policy 
documents.

What attributes  you actually use and their order is in an enterprise PKI,
probably highly dependent on the directory schema used.   For TTP issued 
citizen
certificates like the ones used in many EU countries, the order of 
attributes
is of little importance, what is though really important is that they are 
properly
documented since they are to be interpreted by numerous independent
organizations and applications.

Since the exact location of an organizationName attribute varies between
certificates, application software anyway have to traverse the entire 
subject
structure if they are not going to fail every now and then. As you already 
noted,
common PKI clients such as Internet Explorer and Firefox do very few 
assumptions
on attribute order.  I accidentally happened to reverse the DN attributes 
once,
but things continued to work exactly as good (or bad) anyway!

>for arbitrary attributes, if you want people to sort them consistently.

To change this is in 3280 bis may be possible but the effect of that on 
real
implementations would probably be limited.  To add such advices after
10 years of PKI deployment is a bit late IMHO.

Anders Rundgren

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 13 Apr 2006 07:08:40 +0200

Tom,
 
>without countryName.  Have you ever seen a DN which did?

No,  but "mandatory" is a new constraint that I guess is closest to MUST.
If you don't intend to "outlaw" RFC 3739, you may at best specify
RECOMMENDED.

Should I interpret this such as that you are you supporting the idea that a
DN attribute style guide should be augmented to 3280 bis?

The authors should then consult the undisputed authority on such, that is,
Peter Guttman. http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt

I would personally abstain of adding new attribute text as the confusion has
already gone beyond the point of repair.

It is similar to the situation regarding KeyUsage and "signatures"; everybody
(with some self-respect), have their own interpretation on what is "right".

This is BTW a much worse problem for implementers of generic PKI client SW.
Give my [still unanswered] signature certificate question a shot, and you will see why.

Anders

----- Original Message ----- 
From: "Tom Gindin" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>
Cc: "Alicia da Conceicao" <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 12, 2006 05:11
Subject: Re: order of name attributes in certificates, suggestion for 3280 bis

        Anders:

                Tom Gindin

Anders Rundgren

---

From: Michael Ströder <[email-masked]>
Date: Tue, 25 Apr 2006 11:19:52 +0200

Tom Gindin wrote:
> most RP's should and do either treat DN's as binary blobs 
> or convert them to character format and treat them as strings.

Well, but the "character format" should be clearly specified - IMO it's not.

Especially RFC3280bis should have a normative reference to the DN string
representation used for the example DNs in appendix C which defines:
- order
- character set
- defined RDN separator
- multi-valued RDNs

Semicolons as RDN separators like used in appendix C are today not
widely known to implementors and disallowed in LDAPv3 (see RFC 2253).
I'd think this needs clarification. Also character set of string
representation should be clearly specified (UTF-8 in RFC 2253).

=> use a normative reference to RFC 2253 (or its upcoming successor
draft-ietf-ldapbis-dn) and correct examples in appendix C accordingly.

>  It is also 

Examples: Not really protocols but think of textual configuration files:
- containing certificate profiles or
- regular expressions mapping the subject DNs to a user identity
...

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 25 Apr 2006 11:22:06 +0200

> of the cultural whether 'first displayed' is highest or lowest.

IMHO RFC3280 does not clearly specify how to read the DN
strings in appendix C.

Ciao, Michael.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 26 Apr 2006 14:57:16 -0400

>representation used for the example DNs in appendix C which defines:
I do not believe that 3280bis should include a normative reference to 
RFC 2253, although I don't see any problem including an informative 
reference.  The IETF describes normative references as follows:

    Normative references specify documents that must be read to 
understand or
    implement the technology in the new RFC, or whose technology must be 
present
    for the technology in the new RFC to work.

The only places that I can find string representations of DNs in 3280bis 
are in the examples of LDAP URIs and in Appendix C.  The rules for LDAP 
URIs, including the rules for distinguishedName portion of the URI, are 
specified in RFC 2255, which is already listed as a normative 
reference.  The string representation of DNs in Appendix C are simply 
used to describe sample certificates, and I see no reason that the 
inclusion of these examples would result in the need to list RFC 2253 as 
a normative reference.

>widely known to implementors and disallowed in LDAPv3 (see RFC 2253).
I can't find any place in 3280bis were semicolons are used as RDN 
separators.  If there are any string representations of DNs in 3280bis 
that do not conform to RFC 2253, please specify where they are and I 
will correct them.

>representation should be clearly specified (UTF-8 in RFC 2253).
I will add a note in Appendix C indicating that all string 
representations of DNs are encoded in accordance with RFC 2253.

>draft-ietf-ldapbis-dn) and correct examples in appendix C accordingly.
I will add an informative reference.  If any of the examples are 
incorrect, please specify where they are since do not see any.

Dave

---

From: Michael Ströder <[email-masked]>
Date: Wed, 26 Apr 2006 22:52:32 +0200

David A. Cooper wrote:
> reference.

Informative reference is ok for me too. Maybe a small hint that the
order in the string representation is reversed RDNSequence. I'm pretty
sure PKI implementors will not read RFC 2253, section 2.1 when looking
at 3280bis.

> separators.

Sorry, I still looked at RFC 3280. My fault.

Ciao, Michael.