Ian Clelland said, > It makes sense, though, that a company should be able to issue > certificates for servers belonging to various departments within the > company. The organisation knows its own internals far better than RSA/Verisign/whoever ... ... > What root CAs are good at, and what they should be doing, is > authenticating the organisation itself. They can verify that the > organisation exists as described, and that the private key really is
Agreed. But... > This shouldn't be a problem, as long as the signing certificate can > only be used to sign certificates within that organisation. ... >... I don't know enough about the format of X.509 certs to say for sure >that this is true. 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 ?). Anyway, the validation is up to the browser - it is _not_ part of the SSL/TLS functionality. 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). 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). 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. BTW, I find Eric Rescola's book `SSL and TLS` coverage of the use of X.509 in SSL/TLS and browsers very informative and readable. I also cover this in my PKI and SSL lectures from the site below (but I have only a very early PKI chapter in the site and haven't begun on the SSL chapter, so for text please see Eric's book). Regards, Amir Herzberg See http://amir.herzberg.name/book.html for lectures and draft-chapters from book-in-progress, `secure communication and commerce using cryptography`; feedback appreciated! --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
