Frank Hecker wrote:
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.
OK, so that is one application: email.
* 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.
That's one-point-five applications, browsing, and some
link-level mail components.
(Either way, drawing from my earlier mail to Duane,
how or what each of those applications requires is
totally distinct when it comes to cryptosecurity models.)
* signed code objects as implemented in Firefox, Thunderbird, and
Mozilla, e.g., for extensions.
Right. Now is where it gets murky. That's a component,
within three different applications. For example, if
Firefox implemented a strong sandbox and was a sort
of random 'games' platform, whereas Thunderbird
was a homogeneous finance platform that drove inter-
bank trades, one could easily see that there was no way
one 'category' or one 'policy' could cover the needs of
both applications.
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.
Yes, I think we're in agreement. At one level we have
3 root lists. At another level we have half a dozen apps.
There may or may not be any easy relationship between
them, in the micro level, but at the macro level, it will
be impractical to designate a policy based on the root
lists.
Which, dragging back to the *discussion at hand*, means
that ... it is not going to help to 'tighten up' on the way
in which CAs vet their customers. Are we all in agreement
on that?
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.
The first part: "we might want to consider different
security requirements..." Exactly!
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!
This doesn't mean that MF should do something different,
either. It just means that the CAs do not sell an appropriate
product for those security markets, and the applications
need to do some work to re-consider security models.
Which all leads back to the posted policy. There is no
point in tightening up on the CAs if they are doing the
wrong thing anyway. Until the *applications* take
charge of their security model, no real change to
security is going to take place. But, a real change
in usability and reachability could take place if an
inappropriate tightening was put in place.
[snipped the questions on IMAP/SMTP as leading off
topic, to follow under other letter]
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
