On 06.07.2010 18:42, Peter Sylvester wrote: > X.500 defines a tree structure, the nodes are relative names put > into a hierarchie represented by a DN. a prefix of the elements in > the sequence defines thus a "subtree", and the relative name of a leaf > is the rightmost element, In a tree the most specific element a leaf > and moving backwards defined less specific. > > There is no need at all to talk about binary encoding, or DER or > whatever. A DN is a sequence of relative names forming a tree > structure when interpreted in the X.500 context. This is thus > one clear interpretation of 'most specific' (for a RDN).
I don't think that this is the issue here - it's the wording in RFC 2818 which is the source of all this... well, I'd say, mess: If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Reading "(most specific) Common Name field" as "Common Name in the most specific RDN" is one interpretation, but I'm not sure if it's the only one. And given the attention this issue received on the list so far, it also seems somewhat ironic that this "requirement" is only appearing in parentheses in an RFC which happens to be informational only, BTW... > Anyway, since there is no good reason not to put a subjectAltName, > I do not think that one shouls say anything more than > "If you use a Common Name other than in the most simple case one > may run a risk not to be interpreted correctly." A BCP document should say more that just state how implementations currently behave, I think [1]. Leaving that "most specific", peculiar requirement from RFC 2818 aside, I don't believe that there are really strong arguments against treating multiple CNs in the subject different from a subjectAltName extension with multiple dNSName entries - why not consider "a match in any one of the set[s]" acceptable...? [2] Clarifying/fixing that blurry "(most specific)" statement from RFC 2818 would be highly desirable for the new BCP, IMO. If by this we can get away with a term whose meaning isn't intuitively clear (compare this e.g. to "left-most DNS label"), then I would definitely consider that a plus. Kaspar [1] From RFC 2026: a BCP document [...] is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function." [2] I'm aware of Nelson's message at http://www.ietf.org/mail-archive/web/certid/current/msg00115.html, but am wondering to how many CAs the statement about unvetted CNs really applies. In my sample from 2009, the multi-CN certs (211 out of ~90,000) are basically limited to one of the so-called "commercial CAs", and I'm pretty sure that this CA does (/claims to) vet all CNs... what they actually do is mirror the entries from the subjectAltName extension in the subject DN. (It happens to be the same CA as the one appearing in the message referenced by Ludwig, for the sake of completeness.) _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
