On Fri, Oct 2, 2015 at 12:36 PM, Brian Smith <[email protected]> wrote:
> ---------- Forwarded message ---------- > From: Brian Smith <[email protected]> > Date: Thu, Oct 1, 2015 at 7:15 AM > Subject: Re: Policy Update Proposal: Remove Code Signing Trust Bit > To: Gervase Markham <[email protected]> > Cc: "[email protected]" <[email protected]> > > > On Wed, Sep 30, 2015 at 11:05 PM, Gervase Markham <[email protected]> > wrote: > > > On 01/10/15 02:43, Brian Smith wrote: > > > Perhaps nobody's is, and the whole idea of using publicly-trusted CAs > for > > > code signing and email certs is flawed and so nobody should do this. > > > > I think we should divide code-signing and email here. I can see how one > > might make an argument that using Mozilla's list for code-signing is not > > a good idea; a vendor trusting code-signing certs on their platform > > should choose which CAs they trust themselves. > > > > But if there is no widely-trusted set of email roots, what will that do > > for S/MIME interoperability? > > > > First of all, there is a widely-trusted set of email roots: Microsoft's. > Secondly, there's no indication that having a widely-trusted set of email > roots *even makes sense*. Nobody has shown any credible evidence that it > even makes sense to use publicly-trusted CAs for S/MIME. History has shown > that almost nobody wants to use publicly-trusted CAs for S/MIME, or even > S/MIME at all. > > Further, there's been actual evidence presented that Mozilla's S/MIME > software is not trustworthy due to lack of maintenance. And, really, what > does Mozilla even know about S/MIME? IIRC, most of the S/MIME stuff in > Mozilla products was made by Sun Microsystems. (Note: Oracle acquired Sun > Microsystems in January 2010. But, I don't remember any Oracle > contributions related to S/MIME. So, yes, I really mean Sun Microsystems > that hasn't even existed for almost 6 years.) > While working on PRISMPROOF email (details on that next week hopefully) I asked round and was surprised to discover that the number of CA issued S/MIME certs is about the same as the number of OpenPGP keys on the key servers. Further the S/MIME users are paying for the cert which suggests it is rather more likely they are using them. And this does not count the DoD deployment or the parts of the GSA deployment that are not outsourced. One of the reasons it has been so hard to deploy end-to-end mail has been the scorched earth policy of the advocates of both sides and a refusal to accept that the other side actually had a use case. If people are serious about trust models and not just posturing for the sake of it, they are going to describe the model they use to evaluate the trust provided. PKI uses cryptography but that is never the weakest link for a well designed system and usually not the weakest link even in a badly designed one. The model I have used for the past 20 years is to consider the work factor for creating a bogus certificate. That is the model I used when we built the WebPKI. The Web PKI is predicated on the costs associated with acquiring a certificate being greater than the value to an attacker. Requiring a corporate registration is not an insuperable obstacle but it imposes a known cost and doing that on a repeated basis without being caught or leaving a tell-tale signal is expensive. The point of revocation was to reduce the window of vulnerability for use of a bogus certificate so as to limit the value to the attacker. Now one of the problems in that system was that it worked too well. And so people who should have known better decided they could shut off the controls I and others had predicated the security model on. Then they blamed us for the consequences. There has only been one occasion when the WebPKI has not worked within the design parameters and that was the DigiNotar attack. Two years ago I extended my model to consider time. Because one of the astonishing things about notary hash chains is that it is actually quite easy to build one with a work factor for a backdating attack that can be considered infinite. I am aware of the limitations of the PKIX trust model for the general trust problem but it does work well within the organizations that it is designed to serve and who do in fact use it on a substantial scale. Most people who are serious about OpenPGP and not merely playing editor wars accept the fact that the Web Of Trust model does not scale. The Moore bound problem prevents WOT alone achieving global scale. If however you combine the CA issued cert model, the WOT model and notary hash chains, it is not only possible to establish a robust, scaleable email PKI, it is reasonably straightforward. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
