At 1:20 AM +0200 9/30/10, Stefan Santesson wrote: >My point is more that it is good practice to have serverAuth set when the CN >attribute is allowed to carry a DN.
Yes it is. However, that is irrelevant to this document. It would be relevant to a document saying how to create a well-formed server certificate for TLS. >Absent the serverAuth EKU it is hard to programmatically be sure that the CN >actually contains a DNS name. Yes you can probably be pretty sure but there >is just a slight chance for problems due to overloaded semantics. Even if the serverAuth EKU is set, you cannot be sure the CN actually contains a DNS name. The two are orthogonal. >ServerAuth provides a much cleaner indication than parsing the CN attribute >only. I see potential security problems if a CA allows you to for example >set your CN as a friendly name while other attributes such as givenName and >SureName are checked against your registered name. The friendly name may be >hard to check as it may differ from your registered name (ex Tim Polk). >Thus some not so careful implementation may have poor checks and allow you >to choose a domain name as your friendly name. This certificate may never be >intended to be used for server authentication, but following the rules of >the draft this certificate now allows spoofing and you would never detect >that. See both points above. >More importantly it has to do with name constraints processing. If you >accept the CN attribute as a domain name you need to make sure that it also >matches any name constraints set for the dNSName of the path. It is much >cleaner again to use the serverAuth as a mechanism for switching in this >logic. Then there should be a PKIX document saying this. It is not relevant to a document that tells how to match a domain name the client has in its left hand against the identities in the cert it holds in its right hand. >Absent this check, the domain name may violate name constraints and you >would never know. This is the most important point. If the TLS client is doing full certificate path validation, the certificate cannot violate name constraints. That is quite different than what you just said. --Paul Hoffman, Director --VPN Consortium _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
