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. It is really as simple as that. 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 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. NameConstraints are ill-designed to support what some people intend to do with them. They're specify to constrain only name components that are present, not name components that are absent. 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. As far as Joe Average User is concerned, which of the CAs shipping in current Browsers does have the alleged security problem anyway? 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... > > > Those that need the backwards compatibility will _not_ disable > > the matching fallback if DNSName SANs are present, > > NSS doesn't: > > https://mxr.mozilla.org/mozilla/ident?i=CERT_VerifyCertName > > 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. The only problem with CN-less subject names is, that it might create serious usability issues with a number of existing certificate maintenance UIs... > > > and they're > > even more unlikely to adopt such a weird name constraints > > processing of a fallback they shouldn't be doing in the > > first place and keep doing only to not interfere with > > installed base. > > Those that need backwards compatibility, name constraints, and security > need to do something about this issue. 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. The situation for ECC crypto is similar. Although there may be some usefulness in having alternative algorithm to RSA at some point in the future when all of the annoying patents have expired. -Martin _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
