On 6/11/10 6:12 PM, Paul Hoffman wrote: >> 6. The certificate SHOULD NOT represent the server's >> fully-qualified DNS domain name by means of a DC-ID, i.e., a series >> of Domain Component (DC) attributes in the certificate subject, >> with one RDN per domain label and one DC in each RDN. Although >> (for example) <dc=www,dc=example,dc=com> could be used to >> represent the DNS domain name "www.example.com", given the fact >> that the DNS-ID can be used instead, the DC-ID is NOT RECOMMENDED. > > This should be a MUST NOT. And the reason for the prohibition is not > "DNS-ID can be used instead", but rather "this is insecure because > you can interpret the series of RDNs incorrectly".
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. Corrections are welcome. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
