On 9/15/15 5:42 AM, Peter Kurrasch wrote:
So is Mozilla becoming, in effect, just a browser company? If email is de-prioritized and code signing is on life support, that would be good to know before getting too bogged down with issues that aren't necessarily important to Mozilla. I'm just trying to understand where the boundaries are.
I have always viewed my job as running the NSS root store, so if the Email trust bit is important to users of the NSS root store, then rather than removing the email trust bit, we should bolster the policies and audit requirements for it. Based on my discussions with the NSS team members last week, it sounds like consumers of the NSS root store are indeed using the email trust bit. But we can have that discussion in more detail when we talk about the Email trust bit later. I would really like to focus this discussion on the code signing trust bit.
Continuing on, I'd like to know if Mozilla has plans regarding the code signing BR that is working its way through CABF? There is some good stuff in there that would be an improvement over current policies (although it still has gaps itself).
Gerv has continuously told the CAB Forum that Mozilla is not interested in the code signing BRs.
Personally, I believe that a company that includes software from other companies in their products should have direct relationships with those companies. I don't think those companies should rely solely on a certificate issued from some other company to determine if the software can be included in their products. So, if they have a direct relationship with the software vendor, then they can also directly use any code signing certificates from the software vendor, and not rely on the cert chaining up to a root in the NSS root store.
Also it might be worthwhile to probe some of the CA's who already have the code signing trust bit enabled. They might have customers (or maybe just marketing campaigns?) who rely on a particular root precisely for code signing purposes.
Yes. My plan is to publish the DRAFT of version 2.3 of the policy and list the changes, and then send a CA Communication to be sure they are all aware of the proposed changes and give them time to respond. So, it is very possible that a change we make to the DRAFT of version 2.3 of the policy will need to be re-visited after the CA Communication.
Having said that, it would be easier for me if any such issues are raised during this discussion. There are CAs who regularly participate in this discussion forum, so I would very much like to hear from any of those CAs who actually have customers depending on certs for code signing purposes chaining up to roots in the NSS root store.
Thanks, Kathleen _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
