Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Kathleen Wilson]

All,

Thank you for your patience throughout this long discussion. I 
appreciate all of your thoughtful and constructive input.


I feel confident now that we should do the following:
1) Remove reference to the code signing trust bit from version 2.3 of 
Mozilla's CA Certificate Policy.
2) When version 2.3 is published, also remove reference to the code 
signing trust bit from CA-program related wiki pages.
3) After version 2.3 of the policy is published and the change has been 
properly communicated (CA Communication, security blog, press regarding 
the policy update), turn off the Code Signing trust bits for included 
root certs, and remove any root certs that are left will all trust bits 
turned off.


Thanks,
Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Peter Kurrasch]

  I can't think of a case either. What I'm advocating would be an expansion of Mozilla's role in the security space--something that may or may not be appropriate for me to do, with pros and cons either way.   From: Gervase MarkhamSent: Monday, October 12, 2015 10:56 AM‎On 08/10/15 14:27, Peter Kurrasch wrote:> 2. Loss of visibility/consistency/input:  If Mozilla decides to exit the> code signing world, the security community loses a place to share> experiences, establish policies, discuss and evaluate bad acts and bad> actors, and so forthI've never seen this go on in a Mozilla context with regard tocode-signing - have you?Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Gervase Markham]

On 08/10/15 14:27, Peter Kurrasch wrote:
> 2. Loss of visibility/consistency/input:  If Mozilla decides to exit the
> code signing world, the security community loses a place to share
> experiences, establish policies, discuss and evaluate bad acts and bad
> actors, and so forth

I've never seen this go on in a Mozilla context with regard to
code-signing - have you?

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Gervase Markham]

On 08/10/15 17:20, Peter Bowen wrote:
> 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.

It seems to me that, insofar as Red Hat's choices diverge from Oracle's,
this would lead to compatibility issues. Would it not make more sense
for Red Hat to use a trust store which matches Oracle's Java one?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Peter Kurrasch]

  ‎I will cop to being confused about the Linux situation--I thought some issue had been identified for one of the distros.At this point, please allow me to take a step back and try to articulate my current views on removing the code sign trust bit: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? Are CAs just looking to improve their marketing? 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.2. Loss of visibility/consistency/input:  If Mozilla decides to exit the code signing world, the security community loses a place to share experiences, establish policies, discuss and evaluate bad acts and bad actors, and so forth--all the little things that I think are to the benefit of the TLS world. Perhaps a new venue would be set up (or is already set up?) but only time will tell if it happens and how well it works.3. ‎Signature compromise and code revocation:  As most in this forum already understand, revoking something is sometimes as difficult as issuing it in the first place, and this is equally true for code signing as TLS (perhaps more so?). All code signing approaches have their drawbacks in this regard so the point is not to advocate for any particular solution so much as it is to acknowledge that the problem exists. In a way this is a follow-on to the previous item (where will we talk about revocation issues?) but I wanted to call it out separately.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?From: Matt PalmerSent: Wednesday, October 7, 2015 12:40 AM‎On Tue, Oct 06, 2015 at 01:05:52PM -0500, Peter Kurrasch wrote:> Actually, what is the plan for Linux after the code signing trust bit is> dropped?What would change, such that Linux would have to make plans?- Matt___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Peter Bowen]

> On Oct 8, 2015, at 6:27 AM, Peter Kurrasch  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

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Daniel Micay]

On 06/10/15 02:05 PM, Peter Kurrasch wrote:
> Erwann--I checked and Mozilla has a very strict "No Kissing" policy in the 
> forums, so maybe a handshake will have to suffice.
> 
> I believe Tesla is using a (older?) Ubuntu release in its cars‎. Does anyone 
> here know if they make any use of the NSS capabilities in that distro?
> 
> Actually, what is the plan for Linux after the code signing trust bit is 
> dropped?

What gives you the impression that any Linux distribution is using the
CA model for code signing? That would be a disaster.



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Peter Kurrasch]

Erwann--I checked and Mozilla has a very strict "No Kissing" policy in the 
forums, so maybe a handshake will have to suffice.

I believe Tesla is using a (older?) Ubuntu release in its cars‎. Does anyone 
here know if they make any use of the NSS capabilities in that distro?

Actually, what is the plan for Linux after the code signing trust bit is 
dropped?

  Original Message  
From: Erwann Abalea
Sent: Monday, October 5, 2015 3:17 PM


Le lundi 5 octobre 2015 19:36:03 UTC+2, Peter Kurrasch a écrit :
> TL;DR... [...Peter and Ryan more than disagree...]

Please, stay cool, kiss each other.
‎
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Rick Andrews]

Kathleen, I'll admit that I'm discouraged from contributing. Can you tell us 
what if anything is being done to keep the discourse at a more respectable 
level?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Peter Kurrasch]

  ‎TL;DR...that is until I saw you calling me a concern troll. You make it abundantly clear you believe I am far too ignorant to participate meaningfully in this discussion ‎but I wish you had the humility to ask questions when you don't understand something instead of donning the mantle of intellectual superiority and giving a dressing-down to all you deem inferior. The latter has become quite tiresome.Now, with regards to the iOS and Android ecosystem approach, I understand that model and its strengths and weaknesses. With regards to routers and other autonomous devices, I understand that model, too, and its strengths and weaknesses. With regards to the need for interoperability, well here we have a problem. Your insistence that no such need exists betrays your shortsightedness.Let's consider a (hypothetical) situation where I'm a manufacturer of anti-lock braking systems that go into cars made by 5 different companies. If I need to update the controller software for thousands of cars already on the road, it can be a pretty complicated task but it would be good to know I at least have a straightforward means to do it. Viewing this as an ecosystem isn't all that great since I could have 5 (maybe more?) such ecosystems to deal with. Viewing this as an autonomous system gets complicated since there are other systems on the car that my anti-lock braking module needs to work with and there's no clear delineation to be made.How the auto industry should solve a problem like this is not for me to say. In fact I would suggest it's the height of arrogance for anyone in this forum to dictate the ways in which these manufacturers may solve problems. My contention is that we should allow viable solutions to remain viable, and a Mozilla-maintained trust store is a component of one possible solution.As an extra bonus to those still reading, suppose you go to the dealership to get the oil changed in your car ‎and you end up driving away with a anti-lock braking systems that no longer functions properly because it's been compromised by malware:    ‎http://www.wired.com/2015/10/car-hacking-tool-turns-repair-shops-malware-brothels/Finally, I'm deliberately not connecting all the dots in this email to avoid straying too far off topic. If clarification is needed just let me know.From: Ryan SleeviSent: Friday, October 2, 2015 3:03 PM‎Peter,I can't help but read your replies and reach the conclusion that you maybe fundamentally confused about code signing. ..‎Both Apple and the Android ecosystems demonstrate this - both have strong notions of code signing, ...We also know it's not necessary for identity information to be anintrinsic part of code signing. Indeed, if you actually look at theembedded space ...What you're arguing for - which I'd go as far as to suggest it was aactive strawman if I wasn't convinced you just earnestly misunderstand -is the specific need for third-party mediated identity information as partof a code-signing ecosystem. ...But I do want to emphasize that code signing is decidedly NOT equivalentto TLS, and this is not a case where you need to interoperate withexisting systems, thus necessitating doing 'whatever is necessary'.Codesigning itself is necessarily green field - when you integrate codesigning in a product, you HAVE to make a variety of choices about format,signature schemes, validation, etc - and there is zero need tointeroperateI do hope you can see why the arguments you present are easilymisinterprable as concern trolling; save for the fact that you'veparticipated in past discussions and shown far more consideration, thearguments you've presented for code signing are somewhat indistinguishable from that. I can only hope it was based on a misunderstanding of how both modern and historic systems have deployed code signing, and perhaps confusion over the terminology, rather than deeply held beliefs in spite of that knowledge.Best,Ryan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Gervase Markham]

On 04/10/15 13:18, kirk_h...@trendmicro.com wrote:
> As to whether or not to remove the trust bits for code signing and
> email, I guess I would ask: Why did Mozilla include/create the trust
> bits in the first place?

You would need to ask Netscape :-)

> Was it only to support Mozilla applications
> like Thunderbird?  Or was it to serve as a public resource, beyond
> Mozilla applications?

This is an interesting question of history, but not particularly useful
in the current discussion, because whether or not we had a good reason
back then, the real question is whether we have one _now_ :-)

> I don’t think it’s realistic to expect every application that is
> dependent on code signing and/or email certs to maintain its own
> individual trusted root store.  Perhaps they will default to the
> Windows root store instead of the Mozilla NSS root store – is that
> good for Mozilla’s future?

Again, separating code and email, we are still looking for actual real
examples of applications using the NSS code-signing bit.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Gervase Markham]

On 04/10/15 23:02, R Kent James wrote:
> You seem to be implying that Thunderbird is no longer a Mozilla
> application. Where do you get this idea?

No need to get upset, Kent - Kirk's head is in the CA world, not the
Mozilla world. Your points about Thunderbird's role are reasonable ones,
but let's aim them in the right direction.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Erwann Abalea]

Le lundi 5 octobre 2015 19:36:03 UTC+2, Peter Kurrasch a écrit :
> TL;DR... [...Peter and Ryan more than disagree...]

Please, stay cool, kiss each other.

> Let's consider a (hypothetical) situation where I'm a manufacturer of 
> anti-lock braking systems that go into cars made by 5 different companies. If 
> I need to update the controller software for thousands of cars already on the 
> road, it can be a pretty complicated task but it would be good to know I at 
> least have a straightforward means to do it. Viewing this as an ecosystem 
> isn't all that great since I could have 5 (maybe more?) such ecosystems to 
> deal with. Viewing this as an autonomous system gets complicated since there 
> are other systems on the car that my anti-lock braking module needs to work 
> with and there's no clear delineation to be made.
> 
> How the auto industry should solve a problem like this is not for me to say. 
> In fact I would suggest it's the height of arrogance for anyone in this forum 
> to dictate the ways in which these manufacturers may solve problems. My 
> contention is that we should allow viable solutions to remain viable, and a 
> Mozilla-maintained trust store is a component of one possible solution.

In that case, the car manufacturer cannot trust ANY controller software update 
signed by a CA linked to the Mozilla trust store. This software update must be 
originating from the anti-lock braking manufacturer only. Mozilla doesn't play 
any role here (Microsoft or any other third party either), the authenticity and 
integrity of the software update doesn't necessarily involve an asymetric 
signature, and the binding between the signer's identity and its key doesn't 
need to be an X.509 certificate (the automotive industry is currently defining 
at least 2 certificate formats, and at least 2 different PKI models, one for US 
and EU).

This is not representative of what a Mozilla-operated trust store can play a 
role in.

I appreciate the public reviews, public announcements, public disclosure, etc, 
as Mozilla runs its program. I hope this hypothetic car manufacturer will take 
similar measures to ensure everything's going right. But all this is time 
consuming, and if there's no benefit for Mozilla or Mozilla's users, why should 
it be Mozilla's burden?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[R Kent James]

On 10/4/2015 5:18 AM, kirk_h...@trendmicro.com wrote:

As to whether or not to remove the trust bits for code signing and email, I 
guess I would ask: Why did Mozilla include/create the trust bits in the first 
place?  Was it only to support Mozilla applications like Thunderbird?  Or was 
it to serve as a public resource, beyond Mozilla applications?

If the former, and if Mozilla no longer has any code signing or email 
certificate dependent applications, then I suppose you can drop the trust bits.


You seem to be implying that Thunderbird is no longer a Mozilla 
application. Where do you get this idea? Thunderbird is very much an 
active Mozilla application. As far as I understand it, we are still the 
#2 Mozilla application in terms of number of users. Do users matter?


We have many active volunteers who thought they were Mozillians. Are 
volunteer Mozillians irrelevant? Are we no longer "One Mozilla"?


Mozilla is quite confused these days about who they are. Is Mozilla just 
the MoCo Firefox business, earning search revenue to pay good salaries 
to managers, staff, and other insiders? Or is it the Mozilla Foundation 
with all of its lofty goals?


If Mozilla is just the Firefox business, then why do we care about 
things like radical participation? What right do we have to expect 
people to volunteer and radically participate in just some business? The 
Mozilla I thought I was part of was more than just a money making 
machine that makes so-called "business decisions".


I just got a widely-distributed email from Mark Surman entitled, "Stand 
up for strong security". In that, he said:


"Encryption turns private information like emails and credit card 
information into garbled letters and numbers so that only authorized 
people can translate the messages back to their original form."


How can the Mozilla Foundation be talking about the importance of email 
encryption, when we are here talking about removing the email 
code-signing bit which is a critical contribution that Mozilla is 
currently making toward encryption, and is critical to the primary 
application that Mozilla has that promotes email encryption?


OK m.d.s.policy, "stand up for strong security" and quit talking about 
deprecating the email signing bit! If it's not working as well as you 
would like, then "stand up for strong security" and let's work together 
to get it fixed.



R. Kent James
Chair, Thunderbird Council
@rkentjames
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Phillip Hallam-Baker]

On Fri, Oct 2, 2015 at 12:36 PM, Brian Smith <br...@briansmith.org> wrote:

> -- Forwarded message --
> From: Brian Smith <br...@briansmith.org>
> Date: Thu, Oct 1, 2015 at 7:15 AM
> Subject: Re: Policy Update Proposal: Remove Code Signing Trust Bit
> To: Gervase Markham <g...@mozilla.org>
> Cc: "kirk_h...@trendmicro.com" <kirk_h...@trendmicro.com>
>
>
> On Wed, Sep 30, 2015 at 11:05 PM, Gervase Markham <g...@mozilla.org>
> 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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Peter Kurrasch]

  Hi Kirk--Would it be possible to provide some specific examples of the applications you have in mind? Or maybe some use cases that would be relevant here (in the context of code signing)? My contention has been a significant need exists for code signing and that it matters to everyone. Unfortunately the discussion has been long on opinion (including my own) and short on good examples.I think there is general agreement that the current Mozilla practices need improvement so ‎the question becomes does Mozilla want to take on that work or just bow out altogether. I would hasten to add that just because a security feature/solution has shortcomings does not necessarily mean it's better to do nothing to avoid any "false sense of security". Such thinking can be problematic--citation provided:‎     https://news.ycombinator.com/item?id=6166731One final comment: in terms of the embedded space, without publicly vetted roots I think it's safe to say that most products will include whatever root is necessary just to make the product work and that security concerns might not play much of a role, if any, in the decision making. I don't think that's such a great outcome. Again, an opinion but one based on first-hand experience.   From: kirk_h...@trendmicro.comSent: Wednesday, September 30, 2015 8:11 PM‎I checked with our team, and we think it would be a mistake for Mozilla to remove the trust bits for either code signing or email certs.The Mozilla NSS root store is used by some well-known applications as discussed, but also by many unknown applications.  If the trust bits are removed, CAs who issue code signing or email certs may find multiple environments dependent on the NSS root store where the CA's products will no longer work - and we don't have a list of those environments today.In the future, there may be even greater use of and need for the trust bits for these certs than there is today (as the use of code signing and email certs, and maybe related future products, may increase)  - but once the trust bits are gone from the NSS root store, they are gone foreversnip...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Ryan Sleevi]

On Fri, October 2, 2015 11:53 am, Peter Kurrasch wrote:
>One final comment: in terms of the embedded space, without publicly
>  vetted roots I think it's safe to say that most products will include
>  whatever root is necessary just to make the product work and that security
>  concerns might not play much of a role, if any, in the decision making. I
>  don't think that's such a great outcome. Again, an opinion but one based
>  on first-hand experience.

Peter,

I can't help but read your replies and reach the conclusion that you may
be fundamentally confused about code signing. At the least, you're arguing
for a strawman that is neither practical nor, in modern terms, secure.

To be clear, this proposal is not an argument against the notion of signed
code. I think there's a strong interest in ensuring code that runs is
cryptographically verified - to avoid modification and ensure provenance.
But what you're arguing for, perhaps operating under incomplete
information or incorrect conclusions, is that there is a need to have a
set of third-parties mediate identity information about the provenance of
that code.

We know this is not a necessary condition for "code signing" as a concept.
Both Apple and the Android ecosystems demonstrate this - both have strong
notions of code signing, but there, identity is based on first-party
assertions (Apple/Google and their relationship with the particular
developer), rather than outsourcing that to arbitrary third parties and
systems.

We also know it's not necessary for identity information to be an
intrinsic part of code signing. Indeed, if you actually look at the
embedded space - the home wireless routers, thermostats, smart
refridgerators, etc - what you see is a desire to make sure the code comes
from authorized parties, regardless of who they are. That authorization is
determined by pre-existing relationships. For example, the WiFi router
vendor will bake their vendor key into the device, and all future firmware
updates will be signed by that vendor. This is a system that scales not
just the embedded space, but you can see it equally in places like signed
bootloaders for Android and ChromeOS devices. Again, establishing that you
can have code-signing without the involvement of the PKI.

What you're arguing for - which I'd go as far as to suggest it was a
active strawman if I wasn't convinced you just earnestly misunderstand -
is the specific need for third-party mediated identity information as part
of a code-signing ecosystem. That has a tremendous number of tradeoffs,
and in light of the already many failures of the commercial CA PKI, is
arguably not worth the security hassle compared with mediating a
first-party relationship (as in the Google and Android case).
Organizations that do decide to rely on third-party CAs for codesigning
have already ceded their security, independence, and control of their
product's destiny, which is so bad an outcome that 'grabbing any root
necessary' is not a significant issue.

But I do want to emphasize that code signing is decidedly NOT equivalent
to TLS, and this is not a case where you need to interoperate with
existing systems, thus necessitating doing 'whatever is necessary'.
Codesigning itself is necessarily green field - when you integrate code
signing in a product, you HAVE to make a variety of choices about format,
signature schemes, validation, etc - and there is zero need to
interoperate.

The only 'possible' exception to the above is the case for Microsoft
Windows, Oracle's Java, or Adobe's AIR framework. Each of these systems
decided to abdicate their security responsibilities and thus outsource
customer-relationship management to third-party CAs and standards (such as
Webtrust) so big you can drive a truck through and provide little
reasonable assurances compared to what can be accomplished with a
first-party system. But even in these cases, 'interoperability' is
achieved by acting with the primary vendor's root store - of which they
all maintain one - not forking one.

I do hope you can see why the arguments you present are easily
misinterprable as concern trolling; save for the fact that you've
participated in past discussions and shown far more consideration, the
arguments you've presented for code signing are somewhat indistinguishable
from that. I can only hope it was based on a misunderstanding of how both
modern and historic systems have deployed code signing, and perhaps
confusion over the terminology, rather than deeply held beliefs in spite
of that knowledge.

Best,
Ryan

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Kathleen Wilson]

On 10/1/15 2:05 AM, Gervase Markham wrote:

On 01/10/15 02:43, Brian Smith wrote:


I wish you would have led with these completely ridiculous suggestion
instead of the only-slightly-less ridiculous stuff that preceded it.


This kind of language, while it does follow the rule of criticising
ideas rather than people, is not particularly constructive.




This kind of language is not constructive at all. Worse, it discourages 
people from participating in discussions in mozilla.dev.security.policy.


I would very much like to hear from more CAs when we talk about changes 
to Mozilla's CA Certificate Policy. So, please do not make such 
non-constructive comments.


Kirk, thank you for taking the time to share your thoughts on this 
discussion. I greatly appreciate it!


Kathleen




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Kurt Roeckx]

On 2015-10-01 11:05, Gervase Markham 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.


This is what Microsoft is doing for things like drivers.  For Windows 10 
it started with only 1 CA, but there seem to be 4 now.



Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Gervase Markham]

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?

> I wish you would have led with these completely ridiculous suggestion
> instead of the only-slightly-less ridiculous stuff that preceded it.

This kind of language, while it does follow the rule of criticising
ideas rather than people, is not particularly constructive.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Brian Smith]

On Wed, Sep 30, 2015 at 3:11 PM, kirk_h...@trendmicro.com <
kirk_h...@trendmicro.com> wrote:

> The Mozilla NSS root store is used by some well-known applications as
> discussed, but also by many unknown applications.  If the trust bits are
> removed, CAs who issue code signing or email certs may find multiple
> environments dependent on the NSS root store where the CA's products will
> no longer work - and we don't have a list of those environments today.
>

That's OK.


> Mozilla does a sensible public review of a CA's practices for code signing
> and email certs before turning on the trust bits - and if Mozilla's review
> isn't sufficient, whose is?


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.


> Who can conduct this review better than Mozilla?  (Answer: no one, and no
> one else will bother to do the review.).


If nobody will do it then that means nobody thinks it is important enough
to invest in. Why should Mozilla bother doing it if nobody cares enough to
invest in it?


> Without Mozilla trust bits, the trustworthiness of these types of certs
> will likely go down.
>

Isn't that a good thing? If the issuing policies have been insufficiently
reviewed, then that means Mozilla's current endorsement of these CAs is
misleading people into trusting these certs more than they should be.
Dropping these trust bits would be a clear sign that trust in these certs
should be re-evaluated, which is a good thing.


> Finally, if the trust bits are turned off, I'm concerned that some
> applications that use code signing and email certs will just go static on
> their trusted roots


A vendor that does that is a bad vendor with bad judgement and you should
probably not trust any of their products.


> Trusted by default, but can lose the trust bits by bad actions.
>

I wish you would have led with these completely ridiculous suggestion
instead of the only-slightly-less ridiculous stuff that preceded it.

Cheers,
Brian
-- 
https://briansmith.org/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Gervase Markham]

On 24/09/15 02:58, Peter Kurrasch wrote:
> I suppose my comment was not as clear as I intended but, yes, I think
> Mozilla's commitment to openness is a reason to keep the code sign bit
> and continue to review CA inclusion requests for their code signing
> roots. I'm not aware of another organization who is in a similar
> position as Mozilla with a similar commitment to openness who could
> carry this work forward if the decision is made to remove the code
> signing trust bit.

But that argument carries very little weight if no-one actually pays
attention to our code-signing trust bit. Does anyone?

If it's not useful to anyone, why keep it?

Gerv


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Kathleen Wilson]

On 9/24/15 6:07 AM, Peter Bachman wrote:

When the thread starts on the separate S/MIME policy update thread let me know, 
I work on a project that relies on S/MIME for transferring medical files and 
want to keep open the FOSS component of that. While that project has a strong 
server reference implementation, the private keys are held at the sever, which 
creates a MITM risk that is mitigated if the peer to peer is done correctly for 
end to end.



It is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/atSYV_QPPFA/M6OpyA5FBAAJ


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Richard Barnes]

Sent from my iPhone.  Please excuse brevity.

> On Sep 24, 2015, at 08:56, Richard Wang  wrote:
>
> I think FireFox plugin XPI need to be signed, this is the usage.

Those are signed with a specific Mozilla-owned authority, which is
independent of the root program.  XPI signing does not rely on the
code signing trust bit.

>
>
> Regards,
>
> Richard
>
>>> On Sep 24, 2015, at 20:53, Gervase Markham  wrote:
>>>
>>> On 24/09/15 02:58, Peter Kurrasch wrote:
>>> I suppose my comment was not as clear as I intended but, yes, I think
>>> Mozilla's commitment to openness is a reason to keep the code sign bit
>>> and continue to review CA inclusion requests for their code signing
>>> roots. I'm not aware of another organization who is in a similar
>>> position as Mozilla with a similar commitment to openness who could
>>> carry this work forward if the decision is made to remove the code
>>> signing trust bit.
>>
>> But that argument carries very little weight if no-one actually pays
>> attention to our code-signing trust bit. Does anyone?
>>
>> If it's not useful to anyone, why keep it?
>>
>> Gerv
>>
>>
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Richard Wang]

I think FireFox plugin XPI need to be signed, this is the usage.


Regards,

Richard

> On Sep 24, 2015, at 20:53, Gervase Markham  wrote:
> 
>> On 24/09/15 02:58, Peter Kurrasch wrote:
>> I suppose my comment was not as clear as I intended but, yes, I think
>> Mozilla's commitment to openness is a reason to keep the code sign bit
>> and continue to review CA inclusion requests for their code signing
>> roots. I'm not aware of another organization who is in a similar
>> position as Mozilla with a similar commitment to openness who could
>> carry this work forward if the decision is made to remove the code
>> signing trust bit.
> 
> But that argument carries very little weight if no-one actually pays
> attention to our code-signing trust bit. Does anyone?
> 
> If it's not useful to anyone, why keep it?
> 
> Gerv
> 
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Peter Kurrasch]

Hi Kathleen, 

This summary looks pretty good. I think you could add the point raised by Man 
Ho which essentially asks the question of who should/can/will evaluate the 
trustworthiness of root certs. There are pros and cons either way on that one.

One last comment I'll make is that, among other things, I've been approaching 
this from the standpoint of Mozilla's commitment to openness, open-souce, and 
security. Perhaps that's a bit rosy but I'll offer it up for whatever it may be 
worth.

Thanks.

  Original Message  
From: Kathleen Wilson
Sent: Thursday, September 17, 2015 6:26 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Policy Update Proposal: Remove Code Signing Trust Bit

Thanks to all of you for your thoughtful and constructive input in this 
discussion.

Here is a summary of this discussion so far.

Proposal: Remove references to code signing from Mozilla's CA 
Certificate Policy, then turn off all Code Signing trust bits for root 
certificates included in the NSS root store. This essentially means that 
Mozilla will stop saying that root certificates in the NSS root store 
can be trusted for code signing.

Arguments against this proposal:
- Code signing is very important in the embedded space
- Removing the code signing trust bit sends a message that Mozilla does 
not want to (and will not) participate in this space
- The loss of Mozilla’s support could be a setback to the embedded 
space; i.e. innovation in embedded software could suffer.
- We should not presume that the embedded space is any more amenable to 
a one-size-fits-all solution any more than the SSL space is.


Arguments for this proposal:
- The only situation in which this change will impact an embedded vendor 
is if they allow anyone with a public (i.e. chaining to a root cert in 
NSS) code-signing certificate to run code on their device.
- A public (i.e. chaining to a root cert in NSS) code-signing cert is 
basically a cert that identifies an individual or organization. This 
alone is insufficient for a manufacturer to decide to embed another 
vendor's software in their products.
- If a manufacturer has a direct relationship with the vendors of the 
software they embed, then they can directly trust code-signing 
certificates provided by the vendor, and not rely on the certificates 
chaining up to a root cert in the NSS root store.
- The manufacturer should maintain their own trust list, and not shift 
the responsibility to Mozilla purely because they used the NSS root 
store in their system.
- Mozilla already requires that all plugins be signed by Mozilla, so 
Mozilla is not depending on the NSS root store for code-signing purposes.
- Mozilla currently does not have robust policies around verifying the 
acceptability of root certificates for the purposes of code signing.
- Building a properly run code signing certificate program would be a 
ton of work that Mozilla has never done, and is not prepared to do.
- If the decision makers are not well versed in the use cases behind 
code signing, then they should not be making decisions regarding root 
inclusion/exclusion for code signing.


Other:
- If the decision were made to proceed with the removal of the code 
signing trust bit, Mozilla would need to broadly publicize the change, 
as there may be smaller consumers of these capabilities who will need to 
explore other solutions.


Please let me know if I missed anything or misrepresented any of your 
input.

Is there any other input/feedback we should consider?

Thanks,
Kathleen


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Kathleen Wilson]

On 9/16/15 8:53 PM, David E. Ross wrote:

On 9/15/2015 8:51 AM, Kathleen Wilson wrote [in part]:


Yes. My plan is to publish the DRAFT of version 2.3 of the policy and
list the changes, and then send a CA Communication to be sure they are
all aware of the proposed changes and give them time to respond. So, it
is very possible that a change we make to the DRAFT of version 2.3 of
the policy will need to be re-visited after the CA Communication.

Having said that, it would be easier for me if any such issues are
raised during this discussion. There are CAs who regularly participate
in this discussion forum, so I would very much like to hear from any of
those CAs who actually have customers depending on certs for code
signing purposes chaining up to roots in the NSS root store.


I will ask again:  How broadly is this being announced?


It is not currently being broadly announced -- just here, and in 
discussions with CAB Forum members. I don't want to go through 
press/news stuff for every single item we're going to be discussing. I 
prefer to do the broad announcement when we have a full proposed DRAFT 
of version 2.3 of the policy. And I expect it will take a few months to 
get through all of the topics.




Will a news
release be sent to Slash.dot, ZDNet, or any other external news
services?



When we send the CA Communication for final input on the DRAFT of 
version 2.3 of the policy, we will also work with Mozilla communications 
folks to share the information with external news services. I'm sure it 
will get decent external news attention, as has happened for previous CA 
Communications and policy updates.


This proposed change to remove code signing from Mozilla's CA Cert 
Policy is just one of the many changes we will be discussing, as per 
https://wiki.mozilla.org/CA:CertificatePolicyV2.3
So, the plan is to make all of the proposed changes in the DRAFT of 
Version 2.3 based on discussions here, and then when we have a DRAFT 
ready for final review we will make it very clear what the proposed 
changes are, and make sure it is properly communicated to CAs and 
external news services.



Or will this be announced only within Mozilla's media?


When we publish the full DRAFT for final review, then we will work with 
Mozilla communications folks to make sure it gets shared in other media 
as well.


Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Kathleen Wilson]

Thanks to all of you for your thoughtful and constructive input in this 
discussion.


Here is a summary of this discussion so far.

Proposal: Remove references to code signing from Mozilla's CA 
Certificate Policy, then turn off all Code Signing trust bits for root 
certificates included in the NSS root store. This essentially means that 
Mozilla will stop saying that root certificates in the NSS root store 
can be trusted for code signing.


Arguments against this proposal:
- Code signing is very important in the embedded space
- Removing the code signing trust bit sends a message that Mozilla does 
not want to (and will not) participate in this space
- The loss of Mozilla’s support could be a setback to the embedded 
space; i.e. innovation in embedded software could suffer.
- We should not presume that the embedded space is any more amenable to 
a one-size-fits-all solution any more than the SSL space is.



Arguments for this proposal:
- The only situation in which this change will impact an embedded vendor 
is if they allow anyone with a public (i.e. chaining to a root cert in 
NSS) code-signing certificate to run code on their device.
- A public (i.e. chaining to a root cert in NSS) code-signing cert is 
basically a cert that identifies an individual or organization. This 
alone is insufficient for a manufacturer to decide to embed another 
vendor's software in their products.
- If a manufacturer has a direct relationship with the vendors of the 
software they embed, then they can directly trust code-signing 
certificates provided by the vendor, and not rely on the certificates 
chaining up to a root cert in the NSS root store.
- The manufacturer should maintain their own trust list, and not shift 
the responsibility to Mozilla purely because they used the NSS root 
store in their system.
- Mozilla already requires that all plugins be signed by Mozilla, so 
Mozilla is not depending on the NSS root store for code-signing purposes.
- Mozilla currently does not have robust policies around verifying the 
acceptability of root certificates for the purposes of code signing.
- Building a properly run code signing certificate program would be a 
ton of work that Mozilla has never done, and is not prepared to do.
- If the decision makers are not well versed in the use cases behind 
code signing, then they should not be making decisions regarding root 
inclusion/exclusion for code signing.



Other:
- If the decision were made to proceed with the removal of the code 
signing trust bit, Mozilla would need to broadly publicize the change, 
as there may be smaller consumers of these capabilities who will need to 
explore other solutions.



Please let me know if I missed anything or misrepresented any of your 
input.


Is there any other input/feedback we should consider?

Thanks,
Kathleen


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[David E. Ross]

On 9/15/2015 8:51 AM, Kathleen Wilson wrote [in part]:

> Yes. My plan is to publish the DRAFT of version 2.3 of the policy and 
> list the changes, and then send a CA Communication to be sure they are 
> all aware of the proposed changes and give them time to respond. So, it 
> is very possible that a change we make to the DRAFT of version 2.3 of 
> the policy will need to be re-visited after the CA Communication.
> 
> Having said that, it would be easier for me if any such issues are 
> raised during this discussion. There are CAs who regularly participate 
> in this discussion forum, so I would very much like to hear from any of 
> those CAs who actually have customers depending on certs for code 
> signing purposes chaining up to roots in the NSS root store.

I will ask again:  How broadly is this being announced?  Will a news
release be sent to Slash.dot, ZDNet, or any other external news
services?  Or will this be announced only within Mozilla's media?

-- 
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See .
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Peter Kurrasch]

  ‎It sounds as though the decision has been made, then: the code sign trust bit is out as are the pertinent certs. With Gerv giving a repeated "best regards" to the BR I don't think any other conclusion could be drawn? I'll admit to being a little torn on this. On the one hand I'm not interested in fighting a one-man, losing battle. On the other hand I don't think Mozilla and other browser developers are making an informed decision. At the same time if the decision makers are not well-versed the use cases behind code signing then perhaps they should not be making ‎decisions regarding root inclusion/exclusion. And yet, I can't help but feel the loss of Mozilla's support would be a setback to the embedded space (to use modern day buzzwords, innovation in embedded software would suffer).I'm not sure I entirely understood the example mentioned below but I would nonetheless argue that we should not presume that the embedded space is any more amenable to a one-size-fits-all solution any more than the SSL space is. As a counter exaple, consider that some in-car entertainment systems offer (or want to offer) "downloadable app" capabilities. Regardless of the wisdom of that, it does raise several issues regarding what code should be signed and by whom--issues that are best resolved by the developers of those products.At any rate, if removing the bit/certs is done, it's done. The embedded space folks will have to just do the best they can until another organization of Mozilla's stature can take the reins and move things forward. My intention is not to come across as a passive-aggressive creep but really just sharing my concerns about how this action might play out.From: Kathleen WilsonSent: Tuesday, September 15, 2015 10:52 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Policy Update Proposal: Remove Code Signing Trust BitOn 9/15/15 5:42 AM, Peter Kurrasch wrote:> So is Mozilla becoming, in effect, just a browser company?‎ If email is de-prioritized and code signing is on life support, that would be good to know before getting too bogged down with issues that aren't necessarily important to Mozilla. I'm just trying to understand where the boundaries are.>I have always viewed my job as running the NSS root store, so if the Email trust bit is important to users of the NSS root store, then rather than removing the email trust bit, we should bolster the policies and audit requirements for it. Based on my discussions with the NSS team members last week, it sounds like consumers of the NSS root store are indeed using the email trust bit. But we can have that discussion in more detail when we talk about the Email trust bit later. I would really like to focus this discussion on the code signing trust bit.> Continuing on, I'd like to know if Mozilla has plans regarding the code signing BR that is working its way through CABF? There is some good stuff in there that would be an improvement over current policies (although it still has gaps itself).>Gerv has continuously told the CAB Forum that Mozilla is not interested in the code signing BRs.Personally, I believe that a company that includes software from other companies in their products should have direct relationships with those companies. I don't think those companies should rely solely on a certificate issued from some other company to determine if the software can be included in their products. So, if they have a direct relationship with the software vendor, then they can also directly use any code signing certificates from the software vendor, and not rely on the cert chaining up to a root in the NSS root store.> Also it might be worthwhile to probe some of the CA's who already have the code signing trust bit enabled. They might have customers (or maybe just marketing campaigns?) who rely on a particular root precisely for code signing purposes.>Yes. My plan is to publish the DRAFT of version 2.3 of the policy and list the changes, and then send a CA Communication to be sure they are all aware of the proposed changes and give them time to respond. So, it is very possible that a change we make to the DRAFT of version 2.3 of the policy will need to be re-visited after the CA Communication.Having said that, it would be easier for me if any such issues are raised during this discussion. There are CAs who regularly participate in this discussion 

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[R Kent James]

On 9/14/2015 9:47 AM, Kathleen Wilson wrote:

Anyways, let's not discuss the Email trust bit in this particular
discussion thread. I would like to keep this particular discussion
focused on the policy proposal to remove the Code Signing trust bit.

We will have a separate discussion about the Email trust bit later


Several people kindly pointed out to me this ongoing discussion, and I 
was prepared to make a comment on the Email trust bit issue, but I'll 
defer that to the new discussion when it occurs. What do I have to do to 
make sure that I know about this upcoming discussion of the Email trust 
bit? Is following this newsgroup sufficient?


R. Kent James
Chair, Thunderbird Council

P.S. Various post-Snowden email security initiatives are now coming to a 
head, and this is likely to me a much-increased priority of Thunderbird 
in the future. We are currently talking about closely aligning with one 
such initiative. See comments to 
https://blog.mozilla.org/thunderbird/2015/08/thunderbird-and-end-to-end-email-encryption-should-this-be-a-priority/

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Kathleen Wilson]

On 9/15/15 5:42 AM, Peter Kurrasch wrote:

So is Mozilla becoming, in effect, just a browser company?‎ If email is 
de-prioritized and code signing is on life support, that would be good to know 
before getting too bogged down with issues that aren't necessarily important to 
Mozilla. I'm just trying to understand where the boundaries are.




I have always viewed my job as running the NSS root store, so if the 
Email trust bit is important to users of the NSS root store, then rather 
than removing the email trust bit, we should bolster the policies and 
audit requirements for it. Based on my discussions with the NSS team 
members last week, it sounds like consumers of the NSS root store are 
indeed using the email trust bit. But we can have that discussion in 
more detail when we talk about the Email trust bit later. I would really 
like to focus this discussion on the code signing trust bit.




Continuing on, I'd like to know if Mozilla has plans regarding the code signing 
BR that is working its way through CABF? There is some good stuff in there that 
would be an improvement over current policies (although it still has gaps 
itself).



Gerv has continuously told the CAB Forum that Mozilla is not interested 
in the code signing BRs.


Personally, I believe that a company that includes software from other 
companies in their products should have direct relationships with those 
companies. I don't think those companies should rely solely on a 
certificate issued from some other company to determine if the software 
can be included in their products. So, if they have a direct 
relationship with the software vendor, then they can also directly use 
any code signing certificates from the software vendor, and not rely on 
the cert chaining up to a root in the NSS root store.




Also it might be worthwhile to probe some of the CA's who already have the code 
signing trust bit enabled. They might have customers (or maybe just marketing 
campaigns?) who rely on a particular root precisely for code signing purposes.



Yes. My plan is to publish the DRAFT of version 2.3 of the policy and 
list the changes, and then send a CA Communication to be sure they are 
all aware of the proposed changes and give them time to respond. So, it 
is very possible that a change we make to the DRAFT of version 2.3 of 
the policy will need to be re-visited after the CA Communication.


Having said that, it would be easier for me if any such issues are 
raised during this discussion. There are CAs who regularly participate 
in this discussion forum, so I would very much like to hear from any of 
those CAs who actually have customers depending on certs for code 
signing purposes chaining up to roots in the NSS root store.


Thanks,
Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Peter Kurrasch]

So is Mozilla becoming, in effect, just a browser company?‎ If email is 
de-prioritized and code signing is on life support, that would be good to know 
before getting too bogged down with issues that aren't necessarily important to 
Mozilla. I'm just trying to understand where the boundaries are.

Continuing on, I'd like to know if Mozilla has plans regarding the code signing 
BR that is working its way through CABF? There is some good stuff in there that 
would be an improvement over current policies (although it still has gaps 
itself).

Also it might be worthwhile to probe some of the CA's who already have the code 
signing trust bit enabled. They might have customers (or maybe just marketing 
campaigns?) who rely on a particular root precisely for code signing purposes.



  Original Message  
From: Kathleen Wilson
Sent: Monday, September 14, 2015 11:47 AM‎

On 9/11/15 10:55 AM, Brian Smith wrote:
> The same argument applies to email. Nobody wants to admit that Thunderbird
> is dead, it is uncomfortable to know that the S/MIME handling in
> Thunderbird has been unmaintained for at least half a decade, and it's a
> little embarrassing to admit that the model we use for deciding which CAs
> get the SSL trust bit works even less well for S/MIME and that basically
> nobody cares about the S/MIME or code signing bits. But that's all true.
> It's my professional opinion that if you actually care about S/MIME
> security then it would be a mistake to use Thunderbird. (Sorry, people
> volunteering to keep Thunderbird going.)


I still use Thunderbird, so I appreciate the volunteers who continue to 
support it!

Anyways, let's not discuss the Email trust bit in this particular 
discussion thread. I would like to keep this particular discussion 
focused on the policy proposal to remove the Code Signing trust bit.

We will have a separate discussion about the Email trust bit later when 
we talk about the following item:

https://wiki.mozilla.org/CA:CertificatePolicyV2.3#General_Policy_Cleanup
-- (D27) Clarify which audit criteria are required depending on which 
trust bits are set. In particular, root certs with only the S/MIME trust 
bit set will have different audit criteria requirements than root certs 
with the Websites trust bit set.

When we have that discussion, please feel free to re-voice your opinion 
about completely removing the Email trust bit, and I can also clarify 
what checks we currently do when a CA asks for the Email trust bit.

Thanks,
Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Kathleen Wilson]

On 9/11/15 10:55 AM, Brian Smith wrote:

The same argument applies to email. Nobody wants to admit that Thunderbird
is dead, it is uncomfortable to know that the S/MIME handling in
Thunderbird has been unmaintained for at least half a decade, and it's a
little embarrassing to admit that the model we use for deciding which CAs
get the SSL trust bit works even less well for S/MIME and that basically
nobody cares about the S/MIME or code signing bits. But that's all true.
It's my professional opinion that if you actually care about S/MIME
security then it would be a mistake to use Thunderbird. (Sorry, people
volunteering to keep Thunderbird going.)



I still use Thunderbird, so I appreciate the volunteers who continue to 
support it!


Anyways, let's not discuss the Email trust bit in this particular 
discussion thread. I would like to keep this particular discussion 
focused on the policy proposal to remove the Code Signing trust bit.


We will have a separate discussion about the Email trust bit later when 
we talk about the following item:


https://wiki.mozilla.org/CA:CertificatePolicyV2.3#General_Policy_Cleanup
-- (D27) Clarify which audit criteria are required depending on which 
trust bits are set. In particular, root certs with only the S/MIME trust 
bit set will have different audit criteria requirements than root certs 
with the Websites trust bit set.


When we have that discussion, please feel free to re-voice your opinion 
about completely removing the Email trust bit, and I can also clarify 
what checks we currently do when a CA asks for the Email trust bit.


Thanks,
Kathleen



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Kurt Roeckx]

On Thu, Sep 10, 2015 at 01:20:02PM -0700, Kathleen Wilson wrote:
> Proposal for version 2.3 of Mozilla's CA Certificate Policy:
> 
> Remove the code signing trust bit.
> 
> If this proposal is accepted, then there would be follow-up action items
> that would need to happen after version 2.3 of the policy is published:
> 1) Remove any root certificates that do not have the Websites and/or Email
> trust bit set.
> 2) Remove references to Code Signing trust bits from Mozilla's wiki pages.

I guess I would like to go the other way by making it more strict
what is required to be included.  I would for instance only want
to see EV for code signing certificates, and a requirement for
timestamping.  I would like to see requirements equivalent to the
those for SSL certificates.

I would have no problem that all code signing trust settings are
removed until we're ready to accept them, and I expect that to
take a long time.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Matt Palmer]

On Thu, Sep 10, 2015 at 05:54:22PM -0500, Peter Kurrasch wrote:
>It should be understood that code signing is very important in the
>embedded space--just ask Tesla or Jeep/Chrysler or Nest or other IoT
>product developers. If we accept that premise, the question immediately
>becomes: How do we put together a good code-signing system and how does
>(should?) Mozilla products factor in to that system?

Which embedded vendors are using the Mozilla root store to validate code
signatures?  Heck, which embedded vendors are using the X.509 PKI model of
code signatures in their products?

>If the decision is made to remove the code signing trust bit it sends a
>message that Mozilla does not want to (and will not) participate in
>this space.

How so?  Mozilla is sending a very clear signal that is wants to participate
in the code signing space, by making all plugins be signed by Mozilla.

What Mozilla is signalling with *this* proposed change is that Mozilla
currently does not have robust policies around verifying the acceptability
of root certificates for the purposes of code signing, and feels it would be
better to stop pretending that they do.

> I think it would be a mistake to do so and that technology development
> would be worse off for it.  (Probably even web and desktop app development
> would suffer.)

As the Wikipedians say, [citation needed].  In what plausible way will
technology development be worse off because Mozilla stops saying, "these
root certificates are trusted for code signing"?

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Peter Bowen]

On Thu, Sep 10, 2015 at 3:54 PM, Peter Kurrasch  wrote:

> It seems to me that the benefits of this proposed change are minimal while
> the negative impacts to embedded systems ‎are significant. Perhaps I've
> missed something?
>
> It should be understood that code signing is very important in the
> embedded space--just ask Tesla or Jeep/Chrysler or Nest or other IoT
> product developers. If we accept that premise, the question immediately
> becomes: How do we put together a good code-signing system and how does
> (should?) Mozilla products factor in to that system?
>

I'm not that familiar with the embedded space, but I'm not clear how public
code signing certificates help these companies.  A public code signing
certificate is basically an IV/OV/EV certificate without any DNS Names or
IP Addresses in the SAN extension.  It is an identity certificate, which
identifies either an individual or an organization.

The value that it brings is that a relying party can use it to establish
their own trust policy.  They can choose to trust software signed by
"Example Corp Inc." but not "FooCorp LLC".

In the embedded space, I would assume there is no human to make these
decisions, so I'm not clear on the value of a code signing certificate.

How are embedded developers using the Code Signing key usage in NSS?

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Peter Kurrasch]

  It seems to me that the benefits of this proposed change are minimal while the negative impacts to embedded systems ‎are significant. Perhaps I've missed something? It should be understood that code signing is very important in the embedded space--just ask Tesla or Jeep/Chrysler or Nest or other IoT product developers. If we accept that premise, the question immediately becomes: How do we put together a good code-signing system and how does (should?) Mozilla products factor in to that system?If the decision is made to remove the code signing trust bit it sends a message that Mozilla does not want to (and will not) participate in this space. I think it would be a mistake to do so and that technology development would be worse off for it. (Probably even web and desktop app development would suffer.)However, if the decision is made to proceed with the removal I would recommend that Mozilla broadly publicize this change. There are no doubt many smaller consumers of these capabilities who will need to explore other solutions.    From: Kathleen WilsonSent: Thursday, September 10, 2015 3:20 PM‎Proposal for version 2.3 of Mozilla's CA Certificate Policy:Remove the code signing trust bit.If this proposal is accepted, then there would be follow-up action items that would need to happen after version 2.3 of the policy is published:1) Remove any root certificates that do not have the Websites and/or Email trust bit set.2) Remove references to Code Signing trust bits from Mozilla’s wiki pages.‎
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Matt Palmer]

On Fri, Sep 11, 2015 at 06:56:49AM +0300, Moudrick M. Dadashov wrote:
> On 9/11/2015 3:23 AM, Peter Bowen wrote:
> >On Thu, Sep 10, 2015 at 3:54 PM, Peter Kurrasch  wrote:
> >>It should be understood that code signing is very important in the
> >>embedded space--just ask Tesla or Jeep/Chrysler or Nest or other IoT
> >>product developers. If we accept that premise, the question immediately
> >>becomes: How do we put together a good code-signing system and how does
> >>(should?) Mozilla products factor in to that system?
> >
> >I'm not that familiar with the embedded space, but I'm not clear how public
> >code signing certificates help these companies.  A public code signing
> >certificate is basically an IV/OV/EV certificate without any DNS Names or
> >IP Addresses in the SAN extension.  It is an identity certificate, which
> >identifies either an individual or an organization.
> >
> >In the embedded space, I would assume there is no human to make these
> >decisions, so I'm not clear on the value of a code signing certificate.
>
> Even if there is a human to make these decisions, in the embedded space the
> decision actually is made by the manufacturer of a device at the embedding
> time. So indeed no choice for the human to challenge the decision which is
> relies on a particular code signing certificate. I'm not sure if this
> reliance is static or assumes regular online status check.

If the device relies on a *single* code-signing certificate (or a small
number of them), then this change won't have any effect: this is for
removing the trust bit on *root* CA certificates.  The only situation in
which this change is going to impact an embedded vendor is if they allow
anyone with an issued code signing cert to run code on their device.

If there are any devices out there that are relying on the Mozilla root
program's list of code-signing trust anchors, I'd love to know who they are. 

Further, even if Mozilla stops managing the code-signing trust bit in NSS,
it won't have any practical impact on anyone out there.  Mozilla applies no
meaningful, applicable, specific checks to requests for inclusion for
code-signing.  There is no value in Mozilla managing this, over and above an
embedded vendor or consortium managing this themselves.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy