Paul Hoffman 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.
It is my understanding that the target audience of this document includes CAs, WebServer Admins, Sysadmins and applications on top of TLS ... however it is a little weak in clarifying to which particular audience which particular recommendation/imperative applies. > > >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. They are independent, correct. Server endpoint identification has been performed by SSLv3 clients and TLS v1.0 (rfc-2246) clients based on CN-IDs exclusively for many years. rfc-2459 defines an EKU / KeyPurposeId for TLS Servers and TLS clients http://tools.ietf.org/html/rfc2459#page-39 while the server endpoint identification by dNSName SANs instead of CN-IDs appears to be first documented in rfc-2818. Conceptually, every extension that is added to an X.509v3 certificate further constraints its purpose/applicability (compared to not carrying the extension). There are small deviations for the BasicConstraints defined in PKIX, but basically, that's it. So a server cert with the TLS id-kp-serverAuth EKU is "limited" to TLS server auth, not "extended" to it. AFAIK there are also two private OIDs from Netscape and two from Microsoft with the same meaning as id-kp-serverAuth and id-kp-clientAuth. And I would not rely on clients being strict in checking TLS server EKUs... > > >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. EKUs primarily affect usage scenarios that are born with EKU requirements, rather than SSL&TLS clients and servers, where the EKU situation started as a big mess and the current status is fairly undetermined. > > >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. As defined by PKIX, name constraints defined for dNSName SANs do not apply to directoryNames such as a certificate subject. Some people are trying to artificially redefine the semantics of name constraints to ensure business models of CAs coming preconfigured as trusted with the software. They're asking TLS clients for a gruesome breach of the PKIX name constraints architecture to "protect" against CAs from evading "dNSName SAN name constraints" imposed by their superiorCAs by issuing server certs without dNSName SANs (and CN-IDs instead, to which dNSName SAN name constraints do no apply). I think it is an extremely bad idea to increase the complexity of CN-ID server-id-check semantics, which have been deprecated 10 years ago, by the order of a magnitude -- in particular in a BCP document, because most of the installed base does not work that way and a huge part of them is quite unlikely to ever adopt such weird CN-ID semantics. -Martin _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
