On Tue, Sep 22, 2015 at 4:47 AM, Brian Smith <[email protected]> wrote:
> Kathleen Wilson <[email protected]> wrote: > > > Arguments for removing the Email trust bit: > > - Mozilla's policies regarding Email certificates are not currently > > sufficient. > > - What else? > > > > > * It isn't clear that S/MIME using certificates from publicly-trusted CAs > is a model of email security that is worth supporting. Alternatives with > different models exist, such a GPG and TextSecure. IMO, the TextSecure > model is more in line with what Mozilla is about that the S/MIME model. > The idea that there is one trust model that meets every need is completely wrong. Hierarchical trust models meet the needs of hierarchical organizations very well. When I last did a survey I was rather surprised to find that there are actually the same number of CA issued S/MIME certs as on the OpenPGP servers. And that ignores a huge deployment in the US military that isn't visible to us. Governments and many enterprises are hierarchical. Which makes that the preferred trust model for government and business uses. If I get an email from my broker I really want it to be from someone who is still a Fidelity employee. Hierarchical is not sufficient by itself which is why email clients should not be limited to a single trust model. It should be possible to specify S/MIME keys directly by fingerprint. * It is better to spend energy improving TLS-related work than > S/MIME-related stuff. The S/MIME stuff distracts too much from the TLS > work. > The TLS model is server side authentication. Saying client side authentication distracts from server side makes no sense to me. > * We can simplify the policy and tighten up the policy language more if the > policy only has to deal with TLS certificates. > You could save even more time if you stopped supporting Thunderbird. If Mozilla isn't going to do Thunderbird right and keep it up to date, that might be the right choice of course. * Mozilla's S/MIME processing isn't well supported. Large parts of it are > out of date and the people who maintain the certificate validation logic > aren't required to keeping S/MIME stuff working. In particular, it is OK > according to current development policies for us to change Gecko's > certificate validation logic so that it works for SSL but doesn't > (completely) work for S/MIME. So, basically, Mozilla doesn't implement > software that can properly use S/MIME certificates, as far as we know. > Just to make sure people understand the last point: I think it is great > that people try to maintain Thunderbird. But, it was a huge burden on Gecko > developers to maintain Thunderbird on top of maintaining Firefox, and some > of us (including me, when I worked at Mozilla) lobbied for a policy change > that let us do our work without consideration for Thunderbird. Thus, when > we completely replaced the certificate verification logic in Gecko last > year, we didn't check how it affected Thunderbird's S/MIME processing. > Somebody from the Thunderbird maintenance team was supposed to do so, but I > doubt anybody actually did. So, it would be prudent to assume that > Thunderbird's S/MIME certificate validation is broken. > The Internet has two killer applications, Mail and the Web. I invented WebMail (no really we had a court case with a patent troll and it turns out that I did) and I don't think it is the right answer. Right now there are problems with the specs for OpenPGP, and with S/MIME. Both are examples of 90/10 engineering from the days when that was sufficient. Today they just don't make the grade. If people want to have an email infrastructure that is end-to-end secure, offers all the capabilities of OpenPGP, and S/MIME is fully backwards compatible and makes email and the Web easier to use then I have an architecture that does exactly that. If someone was willing to work with me and help me to integrate with Thunderbird in the same way that I currently integrate with Windows Live Mail (and Outlook to come) then we could open with support for all the major desktop email clients. At some point, I can do the same thing for WebMail, but it isn't possible to meet all my goals there until we can move to ECC. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
