On 7/7/10 12:41 AM, Kaspar Brand wrote: > 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...
Is there a good security reason for this "requirement"? I don't see one. >> 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]. For sure. > 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] That seems eminently sensible to me. (Whether any given CA would issue such a certificate is a matter of CA policy...) > 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. Would removing all mention of "(most specific)" qualify as clarification? > 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. Yes, I think that's what is happening in the example cited. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
