Re: Policy Update Proposal: Remove Code Signing Trust Bit

From: Matt PalmerSent: Wednesday, October 7, 2015 12:40 AM‎On Tue, Oct 06, 2015 at 01:

Re: Policy Update Proposal: Remove Code Signing Trust Bit

y, what is the plan for Linux after the code signing trust bit is dropped?   Original Message   From: Erwann Abalea Sent: Monday, October 5, 2015 3:17 PM Le lundi 5 octobre 2015 19:36:03 UTC+2, Peter Kurrasch a écrit : > TL;DR... [...Peter and Ryan more than disagree...] Please, stay cool, ki

Re: Policy Update Proposal: Remove Code Signing Trust Bit

‎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 qu

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

Re: Policy Update Proposal: Remove Code Signing Trust Bit

perspective anyway.Thanks. From: Kathleen WilsonSent: Monday, September 21, 2015 5:57 PM‎On 9/18/15 5:48 AM, Peter Kurrasch wrote:> Hi Kathleen,>> This summary looks

Re: Policy Update Proposal: Remove Code Signing Trust Bit

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 t

Re: Policy Update Proposal: Remove Code Signing Trust Bit

Tuesday, September 15, 2015 10:52 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Policy Update Proposal: Remove Code Signing Trust BitOn 9/15/15 5:42 AM, Peter Kurrasch wrote:> So is Mozilla becoming, in effect, just a browser company?‎ If email is de-prioritized and code signi

Re: Policy Update Proposal: Remove Code Signing Trust Bit

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.

Re: Policy Update Proposal: Remove Code Signing Trust Bit

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 ver

EU Trust-lists (was: Letter from US House of Representatives)

‎This is an interesting topic. Setting aside politics and technical considerations and instead focusing on just security implications I'd like to share the following thoughts. I admit readily that I have not done

Re: Letter from US House of Representatives

Thanks for sharing this correspondence, Richard. I'm not sure the committee fully appreciates the scope of the problem but it's good to see them make an effort. I was actually surprised that the committee seems to understand as much as they do so perhaps this will be just a first step in a proce

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

I'm glad to see discussions of tools. Some points to consider: 1) How to exclude domains from the search? For example I want to find gmail certs but exclude something like "eggmail" which could be a false positive. 2) ‎How to address wild cards? For example can I bypass these detection tools by

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

can get away with, so it seems I don't have to worry about CT because, as it turns out, I can get away with quite a lot.   Original Message   From: Chris Palmer Sent: Monday, June 8, 2015 1:38 PM On Fri, Jun 5, 2015 at 8:04 AM, Peter Kurrasch wrote:‎ >> Certificate Transparency get

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

You have a lot of ideas in here, Richard! Asking the question "what is the increased risk we face by introducing new CA's and new roots into the trust store?" is a good idea. How we go about answering that gets tricky. It might be helpful to articulate some threat models facing CA's, both gover

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

‎...snip... > Certificate Transparency gets us what we want, I think. CT works > globally, and is safer, and significantly changes the trust equation: > ‎ > * Reduces to marginal/effectively destroys the attack value of mis-issuance Please clarify this statement because, as written, this is plain

Re: Policy about root cert transfers

‎Further to David's points, I'm wondering how far Mozilla would be willing to go when a controversial transfer is proposed. Is removal from the trust store on the table?  For example suppose DigiNotar wants to get back in the cert business and buys up GoDaddy, what would we do then?   Origina

Re: Requirements for CNNIC re-application

I see this question (new root cert/private key or continue with the existing one)‎ as being less about security and more about what got us here in the first place. From Ryan's reply: 1) Certificates that violate policy (such as the one that lead to CNNIC's quasi-removal) may have been issued th

Re: Name-constraining government CAs, or not

‎‎Returning to your original post, Gerv> Questions> => ‎> The key questions I would like to discuss to begin with are:> > 1) "Is the security analysis relating to government CAs, as a class,> different to that relating to commercial CAs? If so, how exactly?"I'll start by offering up 2 d

Re: Policy about root cert transfers

I don't think a transfer action by a CA should be treated as an automatic accept ‎by the security community. The purpose of the root certs and thus the CA program is to establish and maintain trust in an organization and it's policies and procedures. From my perspective this means the transfer r

Re: What is the security benefit of certificate transparency?

hance that nobody will figure it out. Follow-up question: how much time must transpire from the time a cert is issued to when a browser is expected to start accepting it?   Original Message   From: Chris Palmer Sent: Tuesday, April 14, 2015 1:09 PM To: Peter Kurrasch Cc: Rob Stradling; dev-secur

Re: What is the security benefit of certificate transparency?

to pick on you guys--just looking to use some real examples.)   Original Message   From: Rob Stradling Sent: Tuesday, April 14, 2015 8:14 AM To: Peter Kurrasch; dev-security-policy@lists.mozilla.org Subject: Re: What is the security benefit of certificate transparency? Peter, CT is a detection me

What is the security benefit of certificate transparency?

6:15:52PM -0500, Peter Kurrasch wrote: > Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov > and let's further suppose that CNNIC includes this cert in the CT data > since they have agreed to do that. What happens next?  > > Where I'm going with this

Re: Requirements for CNNIC re-application

Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov and let's further suppose that CNNIC includes this cert in the CT data since they have agreed to do that. What happens next?  Where I'm going with this is that I'm trying to figure out if agreeing to support CT is a hollow

Re: Consequences of mis-issuance under CNNIC

Your's is certainly one viewpoint, Daniel. Just the same, there is nothing wrong with more nuanced perspectives.From: Daniel Micay Date: Mon Mar 30 2015 21:29:04 GMT-0500 (Central Daylight Time)On 30/03/

Re: Consequences of mis-issuance under CNNIC

Perhaps there is a middle ground of remedies. For consideration: 1) Mozilla could refuse to validate any intermediate cert which CNNIC has issued to a subordinate CA. (Note: I'm not sure that's the technically precise term here.) Basically, CNNIC may issue intermediates for itself but those path

Re: Name Constraints

much appetite Mozilla has to change the status quo.  So, how much work does Mozilla feel like doing?   Original Message   From: Gervase Markham Sent: Thursday, March 26, 2015 5:07 AM‎ On 26/03/15 03:59, Peter Kurrasch wrote: > Perhaps I chose my words poorly because my intention actually was

Re: Name Constraints

ually be quite an accomplishment if we could get every CA to just agree to that much.   Original Message   From: Gervase Markham Sent: Wednesday, March 25, 2015 6:54 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Name Constraints On 24/03/15 21:12, Peter Kurrasch wrote: > A

Re: Consequences of mis-issuance under CNNIC

eter Bowen Sent: Wednesday, March 25, 2015 8:26 PM To: Peter Kurrasch Cc: Daniel Micay; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Consequences of mis-issuance under CNNIC On Wed, Mar 25, 2015 at 6:24 PM, Peter Kurrasch wrote: > ‎Someone correct me if I'm wrong, but my underst

Re: Consequences of mis-issuance under CNNIC

‎Someone correct me if I'm wrong, but my understanding of the Superfish debacle is that sites that have EV certs would get the green bar treatment on other devices but not on the Lenovo devices where Superfish was installed. The implication, then, is that the green bar provides no improvement in

Re: Name Constraints

of an impact. It's a giant risk/reward calculation. Hopefully this better explains where I'm coming from. From: Gervase MarkhamSe

Re: Name Constraints

I'm confused because it sounds like you're advocating for the status quo but I didn't think that was your position?   Original Message   From: Gervase Markham Sent: Tuesday, March 24, 2015 4:25 AM To: Peter Kurrasch; Richard Barnes; mozilla-dev-security-pol...@lists.mozilla.

Re: Name Constraints

From: Gervase MarkhamSent: Thursday, March 19, 2015 8:53 AMTo: Peter Kurrasch; Richard Barnes; mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Name Constraint

Re: Consequences of mis-issuance under CNNIC

Hi Richard,  Is the proposal to limit CNNIC roots to only .cn domains or would others be allowed? I'm curious to know what CNNIC's perspective is on this proposal, so will a representative be replying in this forum? Thanks.   Original Message   From: Richard Barnes Sent: Monday, March 23, 201

Re: Propose Removal of E-Guven root

arnesSent: Friday, March 20, 2015 10:44 AMTo: ryan-mozdevsecpol...@sleevi.comCc: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.org; Kathleen WilsonSubject: Re: Propose Removal of E-Guven rootOn Fri, Mar 20, 2015 at 10:37 AM, Ryan Sleevi <ryan-mozdevsecpol...@sleevi.com> wrote:On Th

Re: Propose Removal of E-Guven root

ilsonSent: Thursday, March 19, 2015 2:51 PMTo: mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Propose Removal of E-Guven rootOn 3/19/15 11:51 AM, Peter Kurrasch wrote:> Would it be an option to remove the trust bits on the root first and then later on remove it from the store entire

Re: Propose Removal of E-Guven root

Would it be an option to remove the trust bits on the root first and then later on remove it from the store entirely?  While I agree that action is warranted my concern is that the consequence of any action taken will be borne out by the customers of this CA and their users. We are essentially

Re: Name Constraints

‎I think some good work has been done here but the proposed solution is the wrong way to go since it establishes boundaries for CA's that are "locked in" at the browser, either in the form of a special table or in the trusted root store itself. While a method is provided for making changes to the b

Re: TurkTrust Root Renewal Request

Hi Volkan,  Thanks for your response. I think it addresses my concerns though I would like one final clarification: The "OSC intermediate" cert is, as I understand it, to be used exclusively for OSC end certs. Will this intermediate chain directly to the "H5" root or will there be other interme

Comments and discussion on code signing certs

‎As suggested by others, I submitted comments to CABF questions email address regarding the code signing cert requirements. I'm including them below in the event there is any interest in the wider Mozilla community in discussing the issues further in a public forum. Thanks.  == Submitted

Re: Tightening up after the Lenovo and Comodo MITM certificates.

them ourselves? From: Tyler SzaboSent: Tuesday, February 24, 2015 7:31 PMTo: Peter Kurras

Re: TurkTrust Root Renewal Request

e is present, the CA MUST have a business agreement with a Platform vendor requiring that EKU in order to issue a Platform-specific code signing certificate with that EKU. This extension SHOULD be marked non-critical. The CA MUST set all other fields and extensions in accordance to RFC 5280. Steve &

Re: Tightening up after the Lenovo and Comodo MITM certificates.

I think focusing on the trusted root store as a way to resolve this problem is (or will be) less than ideal.‎ I understand the desire to look there but I don't think it will necessarily end well. That said I don't have a great alternative myself but I do have some questions: 1) I saw a quote at

Re: TurkTrust Root Renewal Request

regarding these EKU's?   Original Message   From: Steve Roylance Sent: Wednesday, February 18, 2015 4:36 PM To: Peter Kurrasch Cc: Kathleen Wilson; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: TurkTrust Root Renewal Request > On 18 Feb 2015, at 22:01, Peter Kurrasch wrote: >

Re: TurkTrust Root Renewal Request

at ‎CAs are allowed to submit.   Original Message   From: Steve Roylance Sent: Wednesday, February 18, 2015 9:18 AM To: Peter Kurrasch Cc: Kathleen Wilson; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: TurkTrust Root Renewal Request Hi Peter, In general this would be true if issuan

Re: TurkTrust Root Renewal Request

‎Allowing a single cert to be used for both websites and code signing is a dangerous proposition. What is the current thinking among the community?   Original Message   From: Kathleen Wilson Sent: Thursday, February 12, 2015 12:31 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Tur

<    1   2