On Fri, 2010-09-24 at 04:39 +0200, Martin Rex wrote: > Matt McCutchen wrote: > > > > > A CA with name constraints for DNSName SANs (required critical according > > > to rfc5280, mind you) in its own CA certificate that issues TLS server > > > certificates without dNSName SANs yields "fubar" on my scorecard. > > > > But if by doing that they can issue certificates that clients will > > accept for server names the superior CA did not intend, that's a big > > security problem. > > No, there is absolutely no security problem involved. > > This is a plain and simple liability issue. If the superior CA > can not manage the risk appropriately so that the issuing CA will > not do this, then either the superior CA MUST NOT certify that > issuing CA, or the clients MUST NOT trust the superior CA.
Name constraints are designed to support secure delegation of the ability to issue certificates for a portion of the namespace. Why wouldn't CAs use them for that purpose? Just because you said so? A certificate that violates a name constraint is invalid, and under any sane contract or legal system, the superior CA will not be liable to anyone who relies on an invalid certificate. > Btw. is it completely ridiculous to put Constraints into > certificates for a resource that is managed aribraritly on a > first-come, first-served basis such as DNS hostnames and > think of it as a security feature. What exact use case do you speak of? The typical use case is to give the owner of a DNS zone the ability to issue certificates for names within that zone that will validate for the duration of the ownership. > What some entirely fail to understand is that this is about > a backwards compatibility issue with the installed base, > and no amount of praying, cursing and issuing of new Specs with > MUST NOTs in them will change the behaviour of the installed base > in any way or form. > > New specs affect only new stuff (implementations and CAs), > and to a very limited amount patches into the installed base, > under the condition that the change DOES NOT BREAK existing > productive usage scenarios. Matching a reference server name against a CN-ID that violates a dNSName constraint defeats the purpose of name constraints. With respect to clients willing to do this, a name constraint is a security no-op. In general, IETF seeks to make the features that it introduces work as intended. So it makes complete sense to me that secure handling of name constraints would be a condition of conformance to the server-id-check standard. Old clients that take a useless interpretation of name constraints can continue to exist, they just can't claim conformance to the standard, and that's their problem. NSS now enforces name constraints on the CN-ID (https://bugzilla.mozilla.org/show_bug.cgi?id=394919) and remains backward compatible with the web by virtue of the fact that the public CAs aren't using name constraints yet. If the CAs start doing so, all an inferior CA has to do for things to work is to include a dNSName SAN, which is a SHOULD anyway. > NameConstraints are ill-designed to support what some people > intend to do with them. In what way are they ill-designed to support secure delegation of the ability to issue certificates for a portion of the namespace? > They're specify to constrain only > name components that are present, not name components that > are absent. What do you mean? > Go kick the PKIX folks if you don't like how it is spec'ed, > but leave the apps folks alone. I believe that asking the apps > folks to regurgitate and re-chew stuff that the PKIX part didn't > process to someone's satisfaction is an _extremely_ bad idea. server-id-check is built on PKIX, not vice versa, so server-id-check is responsible for the security consequences of the CN-ID that it defines for the name constraints defined by PKIX. It has the option to solve the problem or say "this breaks the security of name constraints and we know it", which would be laughable for a standard. > As far as Joe Average User is concerned, which of the CAs shipping > in current Browsers does have the alleged security problem anyway? None; obviously the CAs won't use a feature that presents a security problem. The relevant question is whether they would start using it if the problem were solved, and that I can't answer. Those that charge for each end-entity certificate would certainly charge through the roof to delegate an entire domain. > The way they're specified, NameConstraints are not a security feature, > but rather a means to enforce a business model, because NameConstraints > can no longer securely if there is more than one trust anchor. > TLS as used on the internet is approaching 100 seperate trust anchors... No. All name constraints do is constrain sub-CAs, and they are secure for that purpose. PKIX assumes you trust your trust anchors. If you don't, that's a problem that has to be solved by other means. > > The idea is that by including a dNSName SAN, the CA opts out of the > > backward compatibility. I don't think anyone issues certificates with > > both dNSName SAN and CN with the intent that the CN be honored as a > > server name. > > Well no, this is another absolute nonsense, because again it > completely ignores the (behaviour of) the installed base. > The only way to opt out of CN-ID matching is to issue server > certs entirely without CN AVAs in the subject name. > Anything else than CN=f.q.d.n or NO CN AVA is non-sensical. I'm not sure what installed base you are talking about, but the interpretation I described is stated in RFC 2818 and followed by all major browsers. server-id-check is right to choose it. But this is a separate issue from name constraints on the CN-ID. > I'm not aware of a reasonable justification for the existance > of PolicyConstraints and NameConstraints in certificates other > than governmental agencies and military would like to use it > eventually and still be able to procure on the commodity market. I gave one above. A public CAs can give a DNS zone owner the ability to issue certificates within the zone without posing a risk to anyone else. -- Matt _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
