Tom Gindin wrote:
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.
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, aDirectory 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 rulesmay 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.
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.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.
Tom Gindin Peter Sylvester <Peter.Sylvester@xxxxxxxxxx> Sent by: owner-ietf-pkix@xxxxxxxxxxxx 04/04/2006 12:58 PMTo: ietf-pkix@xxxxxxx cc: Subject: order of name attributes in certificates, suggestion for 3280 bisHi, 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
--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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature