Well there's an issue there. What proportion of nominal server certs go to IMAP/SMTP usage?
Probably relatively small. I suspect that most usage of IMAP/SMTP over SSL is by small sites like mine that are cost-conscious and thus aren't using commercial CAs. People doing IMAP/SMTP over internal networks (e.g., your typical corporation) don't necessarily see the use of SSL as necessary, and even if major ISPs do support IMAP/SMTP over SSL (and I think many don't) I suspect they would account for only a few certs compared to the number of certs for web sites.
MF only distributes root lists for 3 purposes: email, browsing, plugins. So those are the only categories that MF is currently interested in.
Let's clarify this: we care about root certs for three purposes:
* S/MIME signed and/or encrypted email as implemented in Thunderbird and the mail component of Mozilla. This involves certs issued to email users.
* SSL-enabled protocols, most notably HTTP/SSL as implemented in Firefox, the browser component of Mozilla, and Camino, IMAP/SSL, SMTP/SSL, and LDAP/SSL as implemented in Thunderbird and the mail component of Mozilla.
* signed code objects as implemented in Firefox, Thunderbird, and Mozilla, e.g., for extensions.
My main point is that it's misleading to call "email" and "browsing" categories, since a typical email application can encompass both S/MIME and SSL, and the category of "SSL-enabled protocols" encompasses both browsing and email-related protocols.
In particular, we might want to consider different security requirements for the HTTP/SSL case vs. the IMAP/SMTP/LDAP over SSL case (e.g., I suspect phishing is not that relevant for the latter case), but 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.
I'm curious about this - why is an ISP that provides IMAP/SMTP requiring a CA signed cert? What's the point of that? The already have a relationship with the client that is far stronger than can be established multilaterally with the CA.
I suspect people want a CA-signed cert for convenience: You don't need to tell email users to download and approve an ISP-specific root CA cert, or approve the actual ISP-generated IMAP or SMTP server certs.
But one could make a counter-argument that this is no big deal: The ISP already has to have the end user configure a bunch of ISP-specific stuff (e.g., domain name for IMAP server and SMTP server, checkbox for enabling SSL for those protocols, userid and password for IMAP and authenticated SMTP, etc.), so adding configuration of an ISP-specific root CA cert or server cert is not necessarily a big deal. (This is what I did for the private site I administer -- created a private CA.)
However I think people (including sysadmins) are so crypto-shy that people see this as a very big deal indeed. I for one am amazed that otherwise-intelligent sysadmins make elementary mistakes like reusing server keys and certs for multiple SSL-enabled servers in a company, so people have to click through warning dialogs just to use basic services.
Even many security-knowledgeable IT professionals seem to turn their brains off when it comes to crypto-enabled applications.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
