The second part: "we're forced to treat these two cases the same because they *are* the same as far as both the CAs and the implementations are concerned."
No. That doesn't follow. The fact that CAs do something stupid and not in the interests of their customers does not mean that MF should follow suit. The fact that the applications also badly handle the security is no reason to go along, either!
OK, let me further clarify what I meant by my statement that HTTP/SSL and IMAP/SMTP/LDAP/SSL are not distinguishable as far as the CAs and the implementations are concerned. I don't mean that they aren't distinguishable in theory, given appropriate action on the part of CAs and implementors, I meant that a) the two cases aren't distinguishable today, and b) distinguishing them would require action on the part of *both* CAs and implementors.
To expand on this:
A certificate issued for use with HTTP/SSL is (at present) indistinguishable from a certificate issued for use with IMAP/SSL, etc., in the sense that there is nothing in the certificate itself that marks the certificate for use in the context of a particular SSL-enabled protocol. Thus a user could apply for a certificate claiming it was to be used for HTTP/SSL, and use the issued cert for IMAP/SSL instead, or vice versa. (They could even use the same certificate and private key for both HTTP/SSL and IMAP/SSL; I do this myself.) Thus at present it would be pointless for CAs to treat applications for HTTP/SSL certs different from applications for IMAP/SSL certs.
In order to change this situation CAs would have to mark the certificates as being intended for a particular use (e.g., HTTP/SSL vs. IMAP/SSL), using a certificate extension or some other method. And then the implementations would have to recognize those extensions and take appropriate action based on them (e.g., aborting an attempted IMAP/SSL connection if the IMAP server presented a cert marked for use with HTTP only).
In the absence of such action by both CAs and implementors we have no choice but to treat HTTP/SSL, IMAP/SSL, etc., as equivalent cases in terms of the requirements we make on CAs -- it's all subsumed under "SSL certs".
Frank
P.S. Looking back it's interesting that back in the early days of SSL Netscape introduced the use of new certificate extensions to mark certificates as to their intended use; see for example the "netscape-cert-type" extension as implemented in Netscape Navigator 3.x:
http://wp.netscape.com/eng/security/cert-exts.html
The netscape-cert-type extension didn't distinguish between different types of SSL servers, e.g., HTTP vs. IMAP, but there's no reason it couldn't have.
Eventually the Netscape-proprietary certificate extensions were deprecated in favor of using standard X.509v3 extensions (e.g., keyUsage); see for example
http://wp.netscape.com/eng/security/comm4-cert-exts.html
(which applies to Netscape Communicator 4.x).
One could argue in hindsight that this was a mistake, and an example of the tail wagging the dog, given that SSL use on the web was by far the major driver of X.509v3 certificate usage. In essence people attempted to shoehorn the real-life use cases of SSL, etc., into the pre-existing X.509v3 model, and IMO it has not been the best of fits (to put it mildly).
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
