Peter Saint-Andre wrote: > > In version -05 we had the following text: > > Domain Components (DCs) are unordered. Therefore the following two > sets of DCs would be equivalent: > > dc=com, dc=example, dc=cn > > dc=cn, dc=example, dc=com > > Because com.example.cn is presumably different from cn.example.com, > representing or verifying an application server's DNS domain name > based on domain components would open a serious security hole. As a > result, certificate issuers and application clients MUST NOT use DCs. > > Someone objected that in fact domain components are not unordered, only > that they can be misinterpreted (as everything else can, see ongoing > discussion of RDNs and AVAs). Therefore we pulled out the quoted text.
I'm sorry, but this example is completely bogus. * If you look at the examples of DC= usage in rfc-5280, they contain only >>domain<< names. There is never a mentioning of a hostname, and therefore the server endpoint identification does not apply. * Some of the examples in rfc-5280 clearly combine DC= componentes with a CN= of a regular user ! It would be a terribly bad idea to newly introduce a concept of matching server endpoint identities that were supposed to be used for informational purposes in regular user certificates. I would really appreciate a "MUST not use DC-ID for server endpoint identification", which also happens to be the current practice and what had previously been specified. rfc-2818 doesn't mention DC= at all. -Martin _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
