On Sat, 2010-09-25 at 05:09 +0200, Martin Rex wrote: > Matt McCutchen wrote: > > 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. > > No, it is not. If there is anything wrong, then it is the > server endpoint identification algorithm that is abusing X.509. > > Name Constraints processing, as specified by PKIX, is NONE of the > apps business. Processing of name constraints is exclusively > the task of the certificate path validation implementation > within the PKI software, and the app doesn't need to know or > care whether and which subtrees were collected while > building the certification path and later processed during > certificate path validation.
I was making an observation, not discussing blame or design. Do you deny the truth of the observation? > > > 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. > > > 10 years ago, the use of CN-ID has been deprecated by rfc-2818 and > been specified to not be used when DNSName SAN is present. Unfortunately, CN-IDs are still widely used, and the browser vendors have little power to push for their eradication. See: https://bugzilla.mozilla.org/show_bug.cgi?id=552346 > > It seems like a bad idea to massively increase the complexity > of a long deprecated server identification scheme, and in a > fashion that is not only a magnitude more complex, but > also amounts to a gruesome breach of the PKIX architecture. > > > I'm sorry for having totally missed the TLS&IETF consenus to abandon > subjectAltNames for server-id-check and to resurrect CN-IDs. > > > There may not be an API in the PKI software for returning to > the app the hierarchy of dNSName name constraints collected while > composing the cert path and processed during cert path validation, > which the app would need for a seconds constraints check > when it decides to try a CN-ID matching fallback. > > If doing DNSName constraints checking proactively during cert path > validation should be allowed, then a REALLY big warning label > would be necessary that CN AVAs must either contain a valid f.q.d.n > or be ABSENT from the server cert subject DName to prevent false > negatives (i.e. name constraints violation errors) in those > new TLS implementations that adopt this fancy logic. Or the server cert can include a dNSName SAN. In that case, the CN is not constrained because it is not used for matching anyway. > > 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. > > > I think it would be more sensible to let CN-IDs rest in peace and > simply skip the CN-ID matching fallback entirely if the CA cert, > which signed the server cert, contains a name constraints extension. That's another fine option, though it has the same problem -- Matt _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
