Kyle Hamilton wrote: > What do I want? > > I want a use-case which expresses why the certificate validation > policies (as implemented by NSS) must be so draconian. > > I want a use-case which expresses, clearly, why certificate validation > problems have to be modal and completely disrupt the user's workflow. > > I want a use-case which expresses why certificates from unknown CAs > have to show up as certificate validation errors in situations where > there are no forms to harvest private information.
This isn't a CA policy issue per se, it's a Firefox/PSM UI issue. For the record I was/am sympathetic to the idea of being more permissive with self-signed SSL certs. However the developers and UI people made the decision that for typical users the better approach was to throw an error on any "nonstandard" SSL configurations. Per my previous comments in my response to Eddy, I think a move to more "opportunistic" crypto (including use of an SSH-like model) is much more likely to occur in new applications than in the traditional SSL web server context. > I want a user interface which allows me -- at a minimum -- to see what > CA signed a given certificate, how that CA is in my store (whether it > was provided by Mozilla or the administrator or through my own > action), the subject of the certificate, and the validity period of > the certificate without having to click on "more information" and then > scroll through the byzantine hierarchy of certificate fields. Again, the Firefox/PSM developers decided that the current UI was simpler for typical users, and that stuff like this was mainly of interest to power users. The Firefox approach to satisfying the needs of power users has been to rely on third-party Firefox extensions, and then to move functionality into core Firefox if it proves popular. If you want to see this info easily available, I suggest trying to persuade one to write one. > I want a policy in place which prevents situations such as the > transition from Thawte CPS version 1 (which did not allow for > domain-validated certificates) to Thawte CPS version 2 (which did > allow for domain-validated certificates) without a new CA being > created and vetted. This brings up a point that was implied by my previous comments in response to Eddy, but that I want to make explicit: IMO the reason why we have a CA policy is *not* because the Mozilla Foundation wants to be or needs to be the "CA police", tracking down and punishing bad deeds of CAs, and motivating them to behave better. We have a CA policy because SSL sites exist and are accessed by typical Mozilla users, because those SSL sites require CAs to issue them certificates, and because we need some sort of baseline policy by which we can balance inclusion of CA root certs (to make SSL "work") against potential security concerns of doing so. In the thawte case you cite, thawte changed its practices to start issuing DV certs from a CA hierarchy not previously used for that, but its practices were still within boundaries outlined in our policy (which does allow issuance of DV certs). So I don't really see a security issue here in terms of how this would affect typical users. Frank -- Frank Hecker [EMAIL PROTECTED] _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
