> On Oct 8, 2015, at 6:27 AM, Peter Kurrasch <fhw...@gmail.com> wrote: > > I will cop to being confused about the Linux situation--I thought some issue > had been identified for one of the distros. > > 1. Impacts to specific products: I had hoped that by now we'd be able to > point to specific products that would be negatively impacted by removing the > code signing bit. For those CAs who've requested this trust bit be turned on > for their roots, do they have customers who want/need it? Even if we don't > hear from product developers it would be nice to hear something from a CA > about their wants/needs on this. > > It seems most people want to free Mozilla of code signing--I get it. That > said I do wonder how the landscape will look after it's removed. Best case: a > new entity steps in. Worst case: we find ourselves facing a bad situation > with no good options--maybe another DigiNotar or a Stuxnet?
Code Signing certificates issued by public CAs have two different uses today, as I understand it (but I’m certainly not an expert): 1) Direct signing of content distributed to broad audiences In this model, the public key in the certificate is used to sign the code which is then distributed (usually via a HTTP server, possibly over TLS) to large numbers of users. The user’s application does a signature validation and displays the results in some manner, possibly with a prompt for the user to take action. This model is used today for the following items: - Microsoft Windows Authenticode - Microsoft Silverlight - Microsoft Office (for VBA) - Oracle Java - Adobe Air - Mozilla extensions (up to some recently past version) - OpenJDK on Red Hat products, including RHEL, Fedora, and CentOS Microsoft and Oracle maintain their own trust stores with their own requirements and CA agreements. So they will not be impacted by anything Mozilla does. Adobe Air uses the system trust store and only runs on Microsoft Windows and Apple OS X. Apple maintains their own trust store. So Adobe Air will not be impacted by NSS changes. For Mozilla, the proposal here is presumably forward looking — the change to remove trust bits would be for future versions of Mozilla products. It is clear that extensions are not using code signing going forward, so there would be no impact to Mozilla products. That leaves OpenJDK on Red Hat. It was indicated in an earlier part of the thread that Red Hat may be basing their trust store on Mozilla’s trust store. This is the one defined place where there may be impact. 2) Signing to provide identity to a single relying party. In this model, the first step is the same as #1 — sign the code. However the next step is to upload the signed code to a central location controlled by a trusted party. The trusted party verifies the signature, may run additional checks, then signs the code with its own key. The code with the trusted party signature is then distributed to broad audiences. Here the only entity relying to the public certificate is the trusted party. This model is used by Microsoft for certain items (drivers, boot loaders, etc). Changes to NSS will have zero impact to Microsoft as they don’t use the Mozilla trust store. In addition to the above two models, there is the option of doing #2 with privately issued certificates. This is the Google Play and Apple model. They don’t use public CAs so are not impacted at all. Based on this, assuming I got this right, it seems that the impact of dropping code signing from the Mozilla trust store is minimal. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
