On 9/30/10 12:36 AM, Stefan Santesson wrote: > > > > On 10-09-30 2:13 AM, "Paul Hoffman" <[email protected]> wrote: > >> 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. > > You are correct. But IF you accept the domain name from the CN attribute and > the serverAuth, you do at least know that the certificate is issued to a TLS > server endpoint. It thus holds the name of a TLS server.
Right, you are interpreting the contents of the CN as a domain name. The question is: should the name constraints that apply to dNSName also apply to the contents of the CN (which are conventionally interpreted as a domain name if they have a "." somewhere in the middle)? >>> 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. >> > See point above. > > You can't possibly mean that the risk of spoofing is the same regardless of > whether serverAuth is checked. > >>> 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. >> > > AFAIK there is no PKIX document supporting the use of CN to carry a domain > name. This is a non standard practice. Agreed. >>> 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. >> > > That is just a game with words Paul. Of course the certificate does not > violate name constraints. It is the USE of the certificate that violates the > name constraints of the path. > > CA-X in the path has stated "You can only rely on this CA certificate to > validate claims about domain names within the example.com namespace" > > If the end certificate holds the domain name "foo.com" in the CN, But no > dNSName SAN, and you accept this claim then you are in fact trusting the > CA-X certificate beyond its declared scope. > > This document is about best current practice right? > > I'm not an advocate for hopelessly rigid requirements and I do respect > legacy. But I think it is reasonable to at least recommend clients to check > any domain name against dNSName name constraints regardless of what > attribute they pulled that information from. I also think it would be good > practice to not blindly accept domain names from any attribute unless you > have some indication that it is likely to hold a domain name. > > A large percentage of installed TLS clients perform these checks, so it is > not taken from nowhere. > > I don't think we can create perfect, but we could limit the risks with > reasonable recommendations. In current practice, people are treating certain kinds of strings from the CN as domain names. Whether that is *best* current practice is another matter. :) Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
