On Mon, 24 Jun 2002, Amir Herzberg wrote:
> This is not as simple as one may expect. X.509 has a hierarchy mechanism > designed for allowing organizations issue (or at least control) > certificates of departments and employees - the Distinguished Name (DN) > and its keywords. However, browsers normally identify the server by its > DNS name, which is usually included in the dNSName attribute in the > subjectAltName extension, rather than in the X.509 DN. DNS names do not > have a completely well defined structure, which makes it difficult to > limit the organization's CA to issuing certs only to its employees and > departments (e.g. would IBM's CA be able to issue certs for > www.ibm.co.uk ?). As Eric noted, despite the addition of subjectAltName to X509v3 many years ago precisely so that Internet-style DNS-based names could be used instead of those funky X.500 DNs, in fact subjectAltName (and issuerAltName, even more, or less, so) have traditionally hardly ever been used by the public CAs, or anyone else for that matter, as far as I can tell. Look in SSL certs you get from webservers and see. The DNS host name is almost always in the CN attribute of the Subject DN, which typically has O and OU attributes also, and may or may not have location-based C, L, ST etc attributes. Note that this mixing makes things far worse. What are the expressable name constraints on a DN, one of whose components has a value that is a DNS name? If DNS-based altNames were used, name constraints would be much easier (not easy, but easier). > Anyway, the validation is up to the browser - it is _not_ part of the > SSL/TLS functionality. Well, if an implementation of SSL/TLS is intended to be compliant with the relevant ITU and IETF standards, then it has to implement name constraints as described in those standards, which includes precisely the validation we're talking about here. So it is certainly part of the specified certificate validation functionality. Whether it is so in practice is another story. > Furthermore, while X.509 and PKIX have mechanisms to allow a root CA to > restrict the scope of certificates issued by a root CA, these mechanisms > seem to focus on restricting the distinguished names in the issued > certificates, rather than the subjectAltName (and in particular the DNS > name). I don't know why you say this. The relevant section of RFC 3280 says, among other things: 4.2.1.11 Name Constraints The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. Restrictions apply to the subject distinguished name and apply to subject alternative names. The section then goes on to give numerous examples of DNS-style constraints. > So my bet is that all or most browsers will not reject certificates with > arbitrary DNS names issues by a corporation with a CA certified by RSA > (or any other root CA). I agree, but not because the technology is unspecified, but because it is inherently extremely complicated. Anyone putting name constraints into a cert today would be taking a huge risk of that cert failing to work at all on the deployed base of browsers and other verifiers. Name constraints won't be exercised until cert issuers start putting them into certs. Chicken and egg. > The problem here is not with the decentralized certification, IMHO; the > problem is with the overly simplistic view of trust. The relying parties > (e.g. browsers) should have tools that map each issuer of certificates > to a `role` defining what it is trusted for. There have been lots of > research in this direction (including a bit of my own) but it was not > yet deployed in mainstream products such as browsers and web servers. This is undoubtedly true, but at least for the near term this makes a complex problem even more complex (what's a "role"? who defines them?), not less so. - RL "Bob" --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
