Policy Update Proposal: Remove Code Signing Trust Bit

[Kathleen Wilson]

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.

Note: This proposal came out of the discussion called "Remove Roots used
for only Email and CodeSigning?"
https://groups.google.com/d/msg/mozilla.dev.security.policy/8VdIUKX5MbU/LQIOjgTIGQAJ
I am separating it out into its own discussion at this point to make it
very clear that we are discussing this proposal as a change to version
2.3 of Mozilla's CA Certificate Policy.

== The proposed changes to the policy are as follows ==

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
In First paragraph change: “The certificates included by default have
their "trust bits" set for various purposes, so that the software in
question can use the CA certificates to verify certificates for SSL
servers, S/MIME email users, and digitally-signed code objects without
having to ask users for further permission or information.”
To
“The certificates included by default have their "trust bits" set for
various purposes, so that the software in question can use the CA
certificates to verify certificates for SSL servers and S/MIME email
users without having to ask users for further permission or information.”

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
In “7. We consider verification of certificate signing requests to be
acceptable if it meets or exceeds the following requirements: …”
Delete 4th bullet point:
“for certificates to be used for digitally signing code objects, the CA
takes reasonable measures to verify that the entity submitting the
certificate signing request is the same entity referenced in the
certificate or has been authorized by the entity referenced in the
certificate to act on that entity’s behalf;”

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
In “9. We encourage CAs to technically constrain all subordinate CA
certificates. …”
Delete 3rd bullet point:
“If the certificate includes the id-kp-codeSigning extended key usage,
then the certificate MUST contain a directoryName permittedSubtrees
constraint where each permittedSubtree contains the organizationName,
localityName (where relevant), stateOrProvinceName (where relevant) and
countryName fields of an address that the issuing CA has confirmed
belongs to the subordinate CA.”

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
In “18. To request that its certificate(s) be added to the default set a
CA should submit a formal request by…”
Delete: “, or digitally-signed executable code objects;”

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
In “10. Changes may be made to root certificates that are included in
Mozilla products as follows: …””
Change “disabling a root is the act of turning off one or more of the
three trust bits (Websites, Email, Code Signing)”
To
“disabling a root certificate is the act of turning off one or more of
the two trust bits (Websites, Email)”

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/
Change “4. A certificate is disabled by turning off one or more of the
three trust bits (Websites, Email, Code Signing).”
To
“4. A certificate is disabled by turning off one or more of the two
trust bits (Websites, Email).”

===

As always, I will appreciate your thoughtful and constructive feedback
on this proposal.

Thanks,
Kathleen

[David E. Ross]

On 9/10/2015 1:20 PM, Kathleen Wilson wrote [in part]:
> 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.
>
> Note: This proposal came out of the discussion called "Remove Roots used
> for only Email and CodeSigning?"
> https://groups.google.com/d/msg/mozilla.dev.security.policy/8VdIUKX5MbU/LQIOjgTIGQAJ
> I am separating it out into its own discussion at this point to make it
> very clear that we are discussing this proposal as a change to version
> 2.3 of Mozilla's CA Certificate Policy.
>
> == The proposed changes to the policy are as follows ==
>

[snipped]

How broadly is this being announced?

--
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.

[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 Wilson Sent: Thursday, September 10, 2015 3:20 PM‎

‎

[Peter Bowen]

On Thu, Sep 10, 2015 at 3:54 PM, Peter Kurrasch <fhw...@gmail.com> 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

[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

[Moudrick M. Dadashov]

On 9/11/2015 3:23 AM, Peter Bowen wrote:
> On Thu, Sep 10, 2015 at 3:54 PM, Peter Kurrasch <fhw...@gmail.com> 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.

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.

Thanks,
M.D.

> How are embedded developers using the Code Signing key usage in NSS?
>
> Thanks,
> Peter

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[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 <fhw...@gmail.com> 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

[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

[Brian Smith]

On Thu, Sep 10, 2015 at 1:20 PM, Kathleen Wilson <kwi...@mozilla.com>

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.
>

FWIW, I think this is a great and long-overdue idea. Mozilla can't do
everything; it has to make trade-offs on what to spend its time on. And, it
makes much more sense to stop caring about code signing trust bits in NSS
to make time for solve more important issues that are more relevant to
Mozilla's mission.

Building a properly-run code signing certificate program would be a ton of
work that Mozilla simply has never done. I think some of the arguments in
this thread for keeping code signing in Mozilla's program aren't fully
informed on just how little Mozilla actually did with respect to code
signing CA trust.

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.)

Cheers,
Brian

[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

[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

[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

[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/

[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 Wilson Sent: Tuesday, September 15, 2015 10:52 AM To: mozilla-dev-s...@lists.mozilla.org Subject: Re: Policy Update Proposal: Remove Code Signing Trust Bit

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.

[Man Ho (Certizen)]

On 9/17/2015 10:26 AM, Peter Kurrasch wrote:
> As a counter exaple, consider that some in-car entertainment systems
> offer (or want to offer) "downloadable app" capabilities.

Obviously, Mozilla's position is that it should be the car
manufacturer's responsibility to maintain their own trust list, but not
shifting the responsibility to Mozilla purely because they used the NSS
module in their system.

[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?

[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

[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

[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-s...@lists.mozilla.org
Subject: Re: Policy Update Proposal: Remove Code Signing Trust Bit

[Kathleen Wilson]

On 9/18/15 5:48 AM, Peter Kurrasch wrote:
> 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.
>

I'm not sure what your last comment means. Do you think that Mozilla's
commitment to openness, open-source, and security is an argument against
removing the code signing trust bit?

Given the response so far and the summary of this discussion, it is
looking to me like the arguments for this proposal to remove the code
signing trust bit outweigh the arguments against.

This discussion is still open, so if any of you believe I have missed
anything, please speak up soon.

Thanks,
Kathleen

[Peter Kurrasch]

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.

For what it's worth I don't consider some of the arguments put forth in support of the removal to be entirely valid. I can elaborate if anyone really cares. I will, however, offer the following:

http://www.darknet.org.uk/2015/09/peinjector-mitm-pe-file-injector/

That tool is exactly the sort of situation that code signing should be able to prevent. To me this shows not only the ne‎ed and urgency for good code signing solutions but also the opportunity for Mozilla to provide a leadership role in this important (and growing) space. Well, that's my perspective anyway.

Thanks.

From: Kathleen Wilson Sent: Monday, September 21, 2015 5:57 PM‎

On 9/18/15 5:48 AM, Peter Kurrasch wrote:

> 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.
>

I'm not sure what your last comment means. Do you think that Mozilla's
commitment to openness, open-source, and security is an argument against
removing the code signing trust bit?

Given the response so far and the summary of this discussion, it is
looking to me like the arguments for this proposal to remove the code
signing trust bit outweigh the arguments against.

This discussion is still open, so if any of you believe I have missed

anything, please speak up soon.‎

[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

[Peter Bachman]

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.

[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

[Richard Barnes]

Sent from my iPhone. Please excuse brevity.

> On Sep 24, 2015, at 08:56, Richard Wang <ric...@wosign.com> 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 <ge...@mozilla.org> 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
>>
>>

[Gervase Markham]

On 24/09/15 16:53, Richard Wang wrote:
> I think FireFox plugin XPI need to be signed, this is the usage.

That is no longer the case.

Gerv

[kirk...@trendmicro.com]

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 forever.

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? Plus, 90%+ of the important issues for security for these trust bits (concerning CA infrastructure security, etc.) are covered for the CA already for SSL and audited by WebTrust and ETSI, so the remaining issues for the code signing and email trust bits really can be limited to the CA's authentication and issuance practices. Even without clear industry authentication standards such as exist for SSL in the Baseline Requirements, who can conduct this review better than Mozilla? (Answer: no one, and no one else will bother to do the review.). Without Mozilla trust bits, the trustworthiness of these types of certs will likely go down.

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 - they will freeze their trusted root stores as of 2015 when Mozilla turns off the trust bits, and never bother to update (as they have no place to go for an update). Over time, their roots stores may include CAs whose roots have been limited or revoked, but the applications may not think it's useful to update their own root stores because Mozilla is no longer maintaining the trust bits they care about. New CAs could be frozen out of these applications.

If the work it too much for Mozilla to continue - consider a less-good approach which says that if a root is trusted in the NSS root store for SSL (has current audits, etc.), its trust bits for code signing and email will automatically be turned on, and will only be turned off (removed) if the CA is found to have done something bad with its code signing and/or email certs. Trusted by default, but can lose the trust bits by bad actions.

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>

[Brian Smith]

On Wed, Sep 30, 2015 at 3:11 PM, kirk...@trendmicro.com <
kirk...@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/

[Matt Palmer]

[I'm specifically only responding in the context of code signing
certificates; that is what this thread is about, and the issues for the two
types of certificates are separate and should remain so]

On Thu, Oct 01, 2015 at 01:11:05AM +0000, kirk...@trendmicro.com wrote:
> The Mozilla NSS root store is used by some well-known applications as
> discussed

Sorry, I must have missed the part of the discussion which enumerated a list
of well-known applications. I recall only three statements regarding users of
the code signing bit, and they were:

* Now-obsolete versions of Firefox, for extension signing; and

* "embedded software"

* "Maybe Java, sometimes"

Could you point me to the message(s) that list, specifically, other
confirmed users of the code signing bit?

> but also by many unknown applications.

Until they're at least known unknowns, I don't think it's useful to use them
as reasons not to terminate the code signing trust bit.

> 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

I don't see how this is Mozilla's problem. CAs are not Mozilla's customer,
the community of users is.

> 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 forever.

How did you come to *that* conclusion? If Mozilla wished to start running a
code signing trust store again in the future, it would presumably be a
matter of reversing a few of the changes made.

> Mozilla does a sensible public review of a CA's practices for code signing
> and email certs before turning on the trust bits

As the wikipedians say, [Citation needed]. I was under the impression that
a large part of the reason this change was proposed was because Mozilla
*didn't* have anything that did a decent job of reviewing code signing
practices.

> and if Mozilla's review isn't sufficient, whose is?

Presumably, someone who saw sufficient value in a publically executed review
of CA practices around code signing certificates to develop and maintain a
process for doing so.

> Plus, 90%+ of the important issues for security for these trust bits
> (concerning CA infrastructure security, etc.) are covered for the CA
> already for SSL and audited by WebTrust and ETSI, so the remaining issues
> for the code signing and email trust bits really can be limited to the
> CA's authentication and issuance practices.

Great, so it won't be a big deal for someone who actually needs a
trustworthy source of code signing certificates to do that review.

> Even without clear industry authentication standards such as exist for SSL

> in the Baseline Requirements, who can conduct this review better than

> Mozilla? (Answer: no one, and no one else will bother to do the review.).

If no one else will bother to do the review, how important can code signing
certificates really be? Also, how is it Mozilla's responsibility to expend
resources maintaining a trust store that they don't use, just because nobody
else will do it?

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

And that would be *your* problem, as a CA issuing such certificates, *not*
Mozilla's.

> 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 - they will freeze their trusted root stores as of
> 2015 when Mozilla turns off the trust bits, and never bother to update (as
> they have no place to go for an update). Over time, their roots stores
> may include CAs whose roots have been limited or revoked, but the
> applications may not think it's useful to update their own root stores
> because Mozilla is no longer maintaining the trust bits they care about.
> New CAs could be frozen out of these applications.

It's somewhat disingenuous to suggest that out-of-date trust stores isn't
already a huge problem.

> If the work it too much for Mozilla to continue - consider a less-good
> approach which says that if a root is trusted in the NSS root store for
> SSL (has current audits, etc.), its trust bits for code signing and email
> will automatically be turned on, and will only be turned off (removed) if
> the CA is found to have done something bad with its code signing and/or

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

Because "trust by default, get spanked if you're naughty" has worked *so*
well so far to maintain a high standard of quality in the CA marketplace.
Given that Mozilla would continue to have no clear standards for code
signing, and extremely little self-interest in maintaining such a store, how
smoothly would an attempt to delist a CA for bad actions go?

> <table class="TM_EMAIL_NOTICE"><tr><td><pre>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.

Well, damn. I guess we're all naughty children. Whose MUAs parse HTML in
plain-text message parts.

- Matt

[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

[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

[Kathleen Wilson]

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

[Brian Smith]

---------- 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 <ge...@mozilla.org>
Cc: "kirk...@trendmicro.com" <kirk...@trendmicro.com>

On Wed, Sep 30, 2015 at 11:05 PM, Gervase Markham <ge...@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.)

Cheers,
Brian
--
https://briansmith.org/

--
https://briansmith.org/

[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 <ge...@mozilla.org>
> Cc: "kirk...@trendmicro.com" <kirk...@trendmicro.com>
>
>
> On Wed, Sep 30, 2015 at 11:05 PM, Gervase Markham <ge...@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.

[Joshua Cranmer 🐧]

On 10/2/2015 11:36 AM, Brian Smith 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 <ge...@mozilla.org>
> Cc: "kirk...@trendmicro.com" <kirk...@trendmicro.com>
>
>
> On Wed, Sep 30, 2015 at 11:05 PM, Gervase Markham <ge...@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.

There is demonstrably more use of S/MIME than PGP. So, by extension of
your argument, almost nobody wants to use secure email, and there is
therefore no point in supporting them. Such a position would naturally
be a gross violation of the Mozilla Manifesto, particularly the fourth
principle.

> Further, there's been actual evidence presented that Mozilla's S/MIME
> software is not trustworthy due to lack of maintenance.

There have been contributor patches to S/MIME code within Mozilla. If
there are issues in the verification or processing of S/MIME within NSS
itself, then this can only be the result of a gross dereliction of duty
of Mozilla's security team to stop supporting it (as S/MIME has
traditionally been under the purview of security, not the email team)
without bothering to even notify any potential consumers, let alone
attempting to help transition them into taking any more of a maintenance
role.

I do realize that I'm using strong language, but this does feel to me to
be part of a campaign to intentionally sabotage Thunderbird development
simply because it's not Firefox and it would detract development from
Firefox, despite the fact that Thunderbird is the second-most-used
project of Firefox (and still growing in market share!) and remains an
official Mozilla project.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

[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=6166731

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.

From: kirk...@trendmicro.com Sent: 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 forever.

...snip...

[Brian Smith]

On Fri, Oct 2, 2015 at 7:41 AM, Joshua Cranmer 🐧 <Pidg...@gmail.com>
wrote:

> On 10/2/2015 11:36 AM, Brian Smith wrote:
>

>> 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.
>>
>

> There is demonstrably more use of S/MIME than PGP. So, by extension of
> your argument, almost nobody wants to use secure email, and there is
> therefore no point in supporting them.

I think it is fair to say the empirical evidence does support the claim
that the vast majority of people don't want to, or can't, use S/MIME or GPG
as it exists today. I do think that almost everybody does want secure
email, though, if we can find a way to give it to them that they can
actually use.

> I do realize that I'm using strong language, but this does feel to me to
> be part of a campaign to intentionally sabotage Thunderbird development
> simply because it's not Firefox

It is much simpler than that: I don't want the S/MIME-related stuff to keep
getting in the way of the SSL-related stuff in Mozilla's CA inclusion
policy. People argue that the S/MIME stuff must keep being in the way of
the SSL-related stuff because of Thunderbird and other NSS-related
projects. I just want to point out that the "dereliction of duty," as you
put it, in the maintenance of that software seems to make that argument
dubious, at best.

[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

[kirk...@trendmicro.com]

My technical team was only able to identify Linux as using the NSS root store, but everyone assumes that other applications also rely on it as a trusted resource.

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. If it was the latter, then I would say the same reasons apply today – you are doing something to help the security of the internet, and maybe you should continue even if you have no immediate plan to use or recognize the trust bits in any ongoing Mozilla applications.

If you drop the trust bits, it will be very hard to start them up again in the future, and probably more time consuming to recreate the trust bits and requalify roots than if you just keep the trust bits for now. Also, I would argue that keeping the trust bits helps make Mozilla at the forefront of the industry and more relevant to the internet community compared to other browsers than if you drop them – something that may be important.

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?

So ultimately this question is part technical and part a business decision for Mozilla, and only Mozilla can decide what direction it wants to go.

From: Peter Kurrasch [mailto:fhw...@gmail.com]
Sent: Friday, October 02, 2015 9:54 PM
To: Kirk Hall (RD-US); dev-secur...@lists.mozilla.org
Subject: Re: Policy Update Proposal: Remove Code Signing Trust Bit

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=6166731

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.

From: kirk...@trendmicro.com<mailto:kirk...@trendmicro.com>
Sent: 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 forever.


...snip...

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.

[Wayne]

On 10/2/2015 12:36 PM, Brian Smith wrote:
> ...

> Further, there's been actual evidence presented that Mozilla's S/MIME
> software is not trustworthy due to lack of maintenance.

I tried to find more than just the previously cited
https://bugzilla.mozilla.org/show_bug.cgi?id=1178032 but found none. So
citations seem to be lacking.

Is the implication that 1178032 is representative of all of s/mime?
(IMO it is a very poor example)

[R Kent James]

On 10/4/2015 5:18 AM, kirk...@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

[Gervase Markham]

On 04/10/15 13:18, kirk...@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

[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

[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 Sleevi Sent: Friday, October 2, 2015 3:03 PM‎

Peter,

I can't help but read your replies and reach the conclusion that you may

be 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 an
intrinsic part of code signing. Indeed, if you actually look at the

embedded space ...

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. ...

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.

...

[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?

[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?

[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

‎

[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.

[Matt Palmer]

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

[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?

[Peter Bowen]

> 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

[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

[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

[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 Markham Sent: 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

[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