Nelson B Bolyard wrote: > > On 2010/05/31 08:18 PDT, Martin Rex wrote: > > > While there have been few implementations checking for multiple > > CN= parts, the guideline in rfc-2818 for subjectAltNames seems > > to be much clearer, that there can be more than one, and more > > than one needs to be checked. > > That is precisely what it says NOT to do. It says > > > 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. > > The phrease "the (most specific) Common Name field in the subject field" > is not plural. There is at most one Common Name attribute in the name > that is *the* most specific one. The words "most specific" refer to its > position in the list of RDNs, which are arranged (as encoded in the > certificate Name field) from most general (first) to most specific > (last). So, the most specific Common Name is the last of the Common > Name attributes in the sequence of RDNs, as encoded in the certificate.
I am perfectly well aware of the wording in rfc-2818. But security-wise an X.509 Cert containing CN=host1.example.com, CN=host2.example.com, CN=host3.example.com is significantly less dangerous that an X.509 Cert containing CN=*.example.com and therefore this wording in rfc-2818 is unreasonable in several aspects and I chose to completely and deliberately ignore it in my implementation. Btw. I did not understand the meaning of "most specific" anyway, so I considered it unlikely that this could be interoperably implement by only matching a single CN= entry. While the initial definition of distinguished names might have had a hierarchical directory structure in mind, one does find distinguished names in "unusal" ordering out there, as well as distinguished names entirely without country AVA, even ones with only CN= -Martin _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
