RE: CA Validation quality is failing

2017-05-01 Thread Jeremy Rowley via dev-security-policy
Certainly happy to share more info. The search was for all EV and OV certs. Of the 4000 certificates detected, 101 certificates are EV. Of these EV certificates, 17 would be included in the proposed revocation. The rest have the “N/A” issue. This is just the locality/state/zip. The jurisdiction

Re: Policy 2.5 Proposal: Incorporate Root Transfer Policy

2017-05-01 Thread Peter Kurrasch via dev-security-policy
Hi Gerv,Your updates look good! One small quibble: The bottom of the Physical Relocation section mentions the code signing trust bit, but I think that is irrelevant now?Would you feel comfortable mandating that,

Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

2017-05-01 Thread Peter Kurrasch via dev-security-policy
I was thinking that fraud takes many forms generally speaking and that the PKI space is no different. Given that Mozilla (and everyone else) work very hard to preserve the integrity of the global PKI and that the

Re: CA Validation quality is failing

2017-05-01 Thread Ryan Sleevi via dev-security-policy
On Mon, May 1, 2017 at 3:41 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > There isn't anything in our CPS directly. However, we state that we follow > the baseline requirements in the CPS. The baseline requirements give a > profile for the state

Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

2017-05-01 Thread Ryan Sleevi via dev-security-policy
On Mon, May 1, 2017 at 5:02 PM, Lee via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Maybe it's because I've worked with some incredibly bad auditors, but > the way I read the proposal, doing anything other than one of those > exact 10 methods is risking an audit

Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

2017-05-01 Thread Lee via dev-security-policy
On 5/1/17, Ryan Sleevi wrote: > On Mon, May 1, 2017 at 1:53 PM, Lee via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 5/1/17, Gervase Markham via dev-security-policy >> wrote: >> > The last CA Communication

RE: CA Validation quality is failing

2017-05-01 Thread Jeremy Rowley via dev-security-policy
There isn't anything in our CPS directly. However, we state that we follow the baseline requirements in the CPS. The baseline requirements give a profile for the state field. We weren't sure this was strictly followed. We finished our validation review over the weekend. There are about 3000

Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

2017-05-01 Thread Ryan Sleevi via dev-security-policy
On Mon, May 1, 2017 at 1:53 PM, Lee via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 5/1/17, Gervase Markham via dev-security-policy > wrote: > > The last CA Communication laid down our policy of only permitting the 10 > >

Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

2017-05-01 Thread Lee via dev-security-policy
On 5/1/17, Gervase Markham via dev-security-policy wrote: > The last CA Communication laid down our policy of only permitting the 10 > Blessed Methods of domain validation. A CA Communication is an official > vehicle for Mozilla Policy so this is now policy,

Re: Symantec: Draft Proposal

2017-05-01 Thread Alex Gaynor via dev-security-policy
Hi Gerv, One idea that occurred to me (maybe novel, though I doubt it), is requiring mandatory _timely_ CT submission for intermediates/cross signatures. That is, to be compliant an issuers's (SCT-timestamp - cert-not-before) must be less than some period, perhaps 3 days. This would ensure rapid

Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

2017-05-01 Thread Gervase Markham via dev-security-policy
On 01/05/17 16:28, Peter Kurrasch wrote: > Gerv, does this leave the Mozilla policy with no position statement regarding > fraud in the global PKI? What do you mean by "in"? Gerv ___ dev-security-policy mailing list

Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

2017-05-01 Thread Peter Kurrasch via dev-security-policy
Gerv, does this leave the Mozilla policy with no position statement regarding fraud in the global PKI?   Original Message   From: Gervase Markham via dev-security-policy Sent: Monday, May 1, 2017 3:36 AM To: mozilla-dev-security-pol...@lists.mozilla.org Reply To: Gervase Markham Subject: Re:

Re: StartCom continues to sell untrusted certificates

2017-05-01 Thread Henri Sivonen via dev-security-policy
On Mon, May 1, 2017 at 11:31 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 01/05/17 07:52, Percy wrote: >> It seems that StartCom continues to sell untrusted certs. Neither their home page https://www.startcomca.com/ nor their announcement page

Symantec: Draft Proposal

2017-05-01 Thread Gervase Markham via dev-security-policy
Here is my analysis and proposal for what actions the Mozilla CA Certificates module owner should take in respect of Symantec. https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit# Please discuss the document here in mozilla.dev.security.policy. A good timeframe

Re: Symantec Conclusions and Next Steps

2017-05-01 Thread Alex Gaynor via dev-security-policy
(I work for Mozilla, but this email doesn't necessarily reflect the views of Mozilla). Hi Steve, I appreciate Symantec taking the time to put this together. There's a lot of unpack here, so I wanted to zoom in on one portion of it. When discussing the feedback you received from enterprise

Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

2017-05-01 Thread Gervase Markham via dev-security-policy
The last CA Communication laid down our policy of only permitting the 10 Blessed Methods of domain validation. A CA Communication is an official vehicle for Mozilla Policy so this is now policy, but it's not reflected in the main policy doc. I was planning to wait until the latest version of the

Policy 2.5 Proposal: New version of WebTrust Criteria -- v2.2

2017-05-01 Thread Gervase Markham via dev-security-policy
There is a new version of the WebTrust criteria, version 2.2, which references version 1.4.2 of the BRs (although the BRs themselves say that audits should be to the latest version). We should update our policy to reference this new version. This simply involves changing a "2.0" to "2.2" in

Policy 2.5 Proposal: Incorporate Root Transfer Policy

2017-05-01 Thread Gervase Markham via dev-security-policy
Mozilla has a Root Transfer Policy which sets out our expectations regarding how roots are transferred between organizations, or what happens when one company buys another, based on a recognition that trust is not always transferable. https://wiki.mozilla.org/CA:RootTransferPolicy It has been

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

2017-05-01 Thread Gervase Markham via dev-security-policy
Does anyone have any thoughts about this issue, below? I sent out a message saying that I had adopted this change as proposed, but that was an error. It has not yet been adopted, because I am concerned about the below. The first option is simpler, because it does not need to get into the details

Re: Policy 2.5 Proposal: Merge Mozilla CCADB policy into main Root Store policy

2017-05-01 Thread Gervase Markham via dev-security-policy
On 20/04/17 14:32, Gervase Markham wrote: > We should consider whether we can just put that stuff into the CCADB > section of the main policy (section 4), and reduce the number of > documents people have to juggle. This suggestion was so exciting it attracted no comments whatsoever. Done as

Re: Policy 2.5 Proposal: Remove BR duplication: reasons for revocation

2017-05-01 Thread Gervase Markham via dev-security-policy
On 20/04/17 14:46, Gervase Markham wrote: > So, proposed new text: > > "CAs MUST revoke Certificates that they have issued upon the > occurrence of any event listed in the appropriate subsection of section > 4.9.1 of the Baseline Requirements (for email certificates, not > including those events

Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

2017-05-01 Thread Gervase Markham via dev-security-policy
On 20/04/17 14:39, Gervase Markham wrote: > So I propose removing it, and reformatting the section accordingly. Edit made as proposed. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: StartCom continues to sell untrusted certificates

2017-05-01 Thread Gervase Markham via dev-security-policy
On 01/05/17 07:52, Percy wrote: > It seems that StartCom continues to sell untrusted certs. Neither their home > page https://www.startcomca.com/ nor their announcement page > https://www.startcomca.com/index/news mentions that those certs are not > trusted. Why is this something that Mozilla

Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

2017-05-01 Thread Gervase Markham via dev-security-policy
On 20/04/17 14:02, Gervase Markham wrote: > I propose this section be removed from the document. This section has now been removed. Regardless of other points raised, the issuing of wildcard certs /per se/ is not a Problematic Practice. Gerv ___

StartCom continues to sell untrusted certificates

2017-05-01 Thread Percy via dev-security-policy
It seems that StartCom continues to sell untrusted certs. Neither their home page https://www.startcomca.com/ nor their announcement page https://www.startcomca.com/index/news mentions that those certs are not trusted. ___ dev-security-policy mailing