RE: CA Validation quality is failing

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

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"

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: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

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

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

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

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

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

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"

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

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

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

(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

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

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

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

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: Remove BR duplication: reasons for revocation

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"

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

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

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

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