Welcome Ben Wilson to Mozilla!

Thanks, Kathleen I'm really excited to begin working with all of you! Cheers and stay safe, Ben Wilson On Mon, Apr 13, 2020 at 11:07 AM Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > All, > > I am pleased to announce that Ben Wilson has joined Mozill

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

Dear Sándor, I have a couple of follow-up questions for Microsec. There were some responses during the recent public discussion in which Microsec indicated it would update its CPS(es). When do you anticipate that this will occur? Also, it is also unclear from the quoted thread below whether suc

COVID-19 Policy (especially EKU Deadline of 1-July-2020)

Dear MDSP community, As you are aware from past discussions on this list, there has been a concern about the impact of COVID-19 on CA operations. COVID-19 continues to impact certain areas of the world more severely than others. For example, there has been a recent resurgence of COVID-19 in Japan

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

Dear Andrew, The purpose of my email was to alert the Mozilla community of a COVID-19 concern as it arose and to start/continue a dialogue on these COVID-19 matters. I was hoping to get some general feedback to help guide our COVID-19 policy. I appreciate the feedback so far. As mentioned in the

Request to Include certSIGN Root CA G2 certificate

This request is for inclusion of the certSIGN Root CA G2 certificate and to turn on the Websites trust bit and for EV treatment. The request is documented in Bugzilla and in the CCADB as follows: https://bugzilla.mozilla.org/show_bug.cgi?id=1403453 https://ccadb-public.secure.force.com/mozilla/

Re: Mozilla's Expectations for OCSP Incident Reporting

Just an FYI - I've also started a thread on the CA/Browser Forum list to see about establishing OCSP uptime requirements in the Baseline Requirements. On Mon, May 11, 2020 at 5:45 AM Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2020-05-08 21:03, Wayne T

Re: Digicert issued certificate with let's encrypts public key

Thanks, Corey. I've added this as a matter to consider in a future version of the Root Store Policy. https://github.com/mozilla/pkipolicy/issues/215 On Thu, May 21, 2020 at 7:23 PM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > While I realize the current

Re: Request to Include certSIGN Root CA G2 certificate

tificates shall be created under, at least, dual control. > > > > I'd like to see an explanation of these non-conformities and the > > remediation from certSIGN, and confirmation from LSTI that they have been > > fixed. > > > > - Wayne > > &g

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

In accordance with the CA inclusion process,[1] this is a summary of the public discussion of Microsec’s application for inclusion of the e-Szigno Root CA 2017 into the Mozilla root store, and to EV enable it and the currently-included e-Szigno Root CA 2009. The request is documented in Bugzilla #1

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

I have now reviewed Microsec's updated CPS for OV and DV. I am not going to hold up approval of the inclusion of this root for the following reasons, which I believe are relatively minor, but Microsec should be aware that: - section 3.1.1 of Microsec's "eIDAS conform Certificate for Website

CA Configuration and Operation

Often CA configurations and settings are complex and can be difficult to manage. We would like to remind CA operators that they need to be familiar with the configuration and operation of all aspects of CA software and ensure that they have adequate documentation and training. For example, in Apri

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

Having received no further comments, I have recommended approval of this request in bug 1445364 - Ben On Tue, Jun 2, 2020 at 1:57 PM Ben Wilson wrote: > I have now reviewed Microsec's updated CPS for OV and DV. I am not going > to hold up

Re: Request to Include certSIGN Root CA G2 certificate

ll be improved >> > -CSS-6.3.10-13–Documentation shall be improved >> > >> > I'm particularly concerned about GEN-6.5.1-04: The CA key pair used for >> > signing certificates shall be created under, at least, dual control. >> > >> > I'd like t

Updated Language in CA Incident Report Template

All, I have updated the wiki page containing the CA incident report template. See https://wiki.mozilla.org/CA/Responding_To_An_Incident The purpose of this update is to place more emphasis on the level of detail that CAs should provide, espe

Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert

All, Thank you to Ryan for identifying this problem, and to all of you who are earnestly investigating what this problem means and the impact to your CA hierarchies. Mozilla::pkix requires that an OCSP responder certificate be an end entity certificate, so we believe that Firefox and Thunderbird

New Blog Post on 398-Day Certificate Lifetimes

All, This is just to let everyone know that I posted a new Mozilla Security blog post this morning. Here is the link> https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/ As I note at the end of the blog post, we continue to seek safeguarding secure browsing

Re: New Blog Post on 398-Day Certificate Lifetimes

Thanks, Paul, for your comments and concerns regarding our reasons 2 and 3, and the costs vs. benefits of going to a 398-day certificate lifetime. We'll keep those in mind as we move forward. In response, the security of our users is the primary concern for Mozilla. So while we recognize there migh

Re: New Blog Post on 398-Day Certificate Lifetimes

Some people have asked whether two-year certificates existing on August 31 would remain valid. The answer is yes. Those certificates will remain valid until they expire. The change only applies to certificates issued on or after Sept. 1, 2020. ___ dev-se

Re: New Blog Post on 398-Day Certificate Lifetimes

Yes, that's right. On Fri, Jul 10, 2020 at 12:11 PM Doug Beattie wrote: > Ben, > > For the avoidance of doubt, I assume this means Sept 1, 00:00 UTC. > > > -Original Message- > From: dev-security-policy > On > Behalf Of Ben Wilson via dev-security-poli

EV-enablement Request of Identrust

This is a request to EV-enable the IdenTrust Commercial Root CA 1, as documented here: https://bugzilla.mozilla.org/show_bug.cgi?id=1551703 * Summary of Information Gathered and Verified: https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0417 * SHA2 hash for Root C

Re: New Blog Post on 398-Day Certificate Lifetimes

Christian Felsing via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Am 09.07.2020 um 17:46 schrieb Ben Wilson via dev-security-policy: > > > https://blog.mozilla.org/security/2020/07/09/reducing-tls-certificate-lifespans-to-398-days/ > > Hi, > > blog

Re: EV-enablement Request of Identrust

Today is the close of the comment period for the Identrust EV enablement request. I don't believe we have received any comments, and I intend to recommend that this request be approved unless there are any reasons why the request should be denied. Thanks, Ben On Fri, Jul 10, 2020 at 4:05 PM Ben Wi

Re: EV-enablement Request of Identrust

Based on the record in Bugzilla Case 1551703 and the CCADB Case 417 ( https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0417) , and receiving no further comments, I have recommended approval of this request to EV-enable the Identrust Commercial Root CA 1. See https://bu

SecureTrust: Root Certificates Inclusion Request

This email announces an intent to include the following three (3) root certificates as trust anchors with the websites and email trust bits enabled, and to enable each root for EV as documented in the following Bugzilla case: https://bugzilla.mozilla.org/show_bug.cgi?id=1528369 This email commenc

Temporary WebTrust Seal for COVID Issues

All, Some CAs have inquired about Mozilla's acceptance of WebTrust's temporary, 6-month seal related to COVID19 issues. See https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services According to that WebTrust webpage, the temporary seal will b

Re: New Blog Post on 398-Day Certificate Lifetimes

that chain up to > built-in > > roots. > > Thanks, > > Ben > > On Mon, Jul 13, 2020 at 10:37 PM Christian Felsing via > dev-security-policy < > > dev-secur...@lists.mozilla.org> wrote: > > > > > Am 09.07.2020 um 17:46 schrieb Ben Wilson via

Re: SecureTrust: Root Certificates Inclusion Request

Dear All, The public discussion period for the three SecureTrust roots ended yesterday, and I don't believe that we received any comments. I intend to recommend that this request be approved unless there are any reasons why the request should be denied. Thanks, Ben On Mon, Aug 3, 2020 at 1:24 PM

Re: Verifying Auditor Qualifications

In a draft template for audit attestations, provided by the ACAB'c, the template would provide a URL to the NAB's certification of the CAB with a statement that the NAB had certified the CAB to perform "certification of trust services according to 'EN ISO/IEC 17065:2012' and 'ETSI EN 319 403 V2.2.2

Policy 2.7.1 Issues to be Considered

Below is a list of issues that I propose be addressed in the next version (2.7.1) of the Mozilla Root Store Policy (MRSP). There are currently 73 issues related to the MRSP listed here: https://github.com/mozilla/pkipolicy/issues. So far, I have identified 13 items to consider for this policy updat

Sectigo to Be Acquired by GI Partners

As announced previously by Rob Stradling, there is an agreement for private investment firm GI Partners, out of San Francisco, CA, to acquire Sectigo. Press release: https://sectigo.com/resource-library/sectigo-to-be-acquired-by-gi-partners. I am treating this as a change of legal ownership cove

Re: Policy 2.7.1 Issues to be Considered

updates would become > effective, and specifically this item: > >https://github.com/mozilla/pkipolicy/issues/206 > > Doug > > -Original Message- > From: dev-security-policy > On Behalf Of Ben Wilson via dev-security-policy > Sent: Thursday, October 1, 20

MRSP Issue #139: Audits required even if not issuing

Here is the first issue for discussion here on the m.d.s.p. list relative to the next version of the Mozilla Root Store Policy (v.2.7.1). #139 - Audits are required even if no longer issuing - Clarify that audits are required until the CA certific

MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

#147 - Require EV audits for certificates capable of issuing EV certificates – Clarify that EV audits are required for all intermediate certificates that are technically capable of issuing EV certificates, even when not currently issuing EV certifi

Re: Policy 2.7.1 Issues to be Considered

52 would be a > useful clarification alongside issue 147, as it will better define the > parameters that determine if a given intermediate is “EV capable”. > > Thanks, > Corey > -- > *From:* dev-security-policy > on behalf of Ben Wilson via dev-

NAVER: Public Discussion of Root Inclusion Request

Dear All, This is to announce the beginning of the public discussion phase of the Mozilla root CA inclusion process, https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 through 9). Mozilla is considering approval of NAVER Business Platform Corp.’s request to include the NAVE

Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

This issue is presented for resolution in the next version of the Mozilla Root Store Policy. It is related to Issue #147 (previously posted for discussion on this list on 6-Oct-2020). Possible language is presented here: https://github.com/BenWils

Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

This issue #153, listed here: https://github.com/mozilla/pkipolicy/issues/153, is proposed for resolution with version 2.7.1 of the Mozilla Root Store Policy. It is related to Issue 139 (audits required even if not issuing). The first paragraph of

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

e. Also, I haven't mapped out how this might affect CAs that we sometimes add to the root store without EV enablement and with the suggestion that they apply later for it. On Sat, Oct 17, 2020 at 12:26 AM Ryan Sleevi wrote: > > > On Thu, Oct 15, 2020 at 4:36 PM Ben Wilson via dev-

Re: NAVER: Public Discussion of Root Inclusion Request

city. > > > > ‐‐‐ Original Message ‐‐‐ > On Friday, 9 October 2020 23:09, Ben Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Dear All, > > > > This is to announce the beginning of the public discussion

Policy 2.7.1: MRSP Issue #154: Require Management Assertions to list Non-compliance

The purpose of this email is to begin public discussion on an addition to section 2.4 of the Mozilla Root Store Policy. Issue #154 in GitHub proposes to require that management assertions (CA disclosures to auditors) provide written mention of all i

Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports

The purpose of this email is to begin public discussion on the addition of a subsection 11 to section 3.1.4 of the Mozilla Root Store Policy. Issue #187 in GitHub proposes to require audit reports to list all incidents occurring (or open) during th

Policy 2.7.1: MRSP Issue #173: Strengthen requirement for newly included roots to meet all current requirements

The current language of MRSP section 7.1 says, "Before being included, CAs MUST provide evidence that their CA certificates have continually, from the time of creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements." If an older root were to be submitted for in

Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

Issue #186 in Github deals with the disclosure of CA certificates that directly or transitively chain up to an already-trusted, Mozilla-included root. A common scenario for the situation discussed in Issue #186 is when a CA creates a second (or thir

Re: NAVER: Public Discussion of Root Inclusion Request

ed. The ST field should probably be the "Gyeonggi-do" as > the "Seongnam-si" entered is a city. > > > > > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐ > > On Friday, 9 October 2020 23:09, Ben Wilson via dev-security-policy < > dev-secur...@lists.moz

Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

Historically, Mozilla Policy required that CAs "provide attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the CA's internal operations." https://wiki.mozilla.org/CA:Certificat

Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

This email begins discussion of a potential change to section 6 of the Mozilla Root Store Policy . The method by which a person may provide a CA with proof of private key compromise has been an issu

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

Hi Dimitris, I intend to introduce the remaining discussion topics over the next three weeks. I did not announce an end to the discussion period on purpose, so that we can have as full of a discussion as possible. Also, in the next three weeks, I intend to start summarizing the discussions and com

Re: NAVER: Public Discussion of Root Inclusion Request

> > > Minor but it seems like all certificates with a stateOrProvinceName > > > field are misissued. The ST field should probably be the "Gyeonggi-do" > as > > > the "Seongnam-si" entered is a city. > > > > > > > > >

Policy 2.7.1: Process Overview

Re-posting this email to start it with its own subject line and to start a new thread: There have been questions about the process being followed and the comment period. Here is where it now stands. I intend to introduce the remaining discussion topics over the next three weeks. I did not annou

Re: NAVER: Public Discussion of Root Inclusion Request

x27;d like Naver >> to >> > provide any further final comments and give anyone else an opportunity >> to >> > comment through this Thursday, and then I will proceed with Steps 6-10 >> > (summarize matters, note any remaining items, and make a last call for >> &g

Re: Policy 2.7.1: Process Overview

I believe that this is where we are so far. I have not received any comments on issues 139, 147, 154, 173, or 205. I have not sent an email out yet for issues 206, 207, 211 or 218. *Issue* *When Announced; Status* #139 - Audits are required even

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

Here is an attempt to address the comments received thus far. In Github, here is a markup: https://github.com/BenWilson-Mozilla/pkipolicy/commit/ee19ee89c6101c3a6943956b91574826e34c4932 This sentence would be deleted: "These requirements include all cross-certificates which chain to a certificate

Re: MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

On Thu, Nov 12, 2020 at 2:03 AM Dimitris Zacharopoulos via dev-security-policy wrote: > I see that this is related to > https://github.com/mozilla/pkipolicy/issues/152, so I guess Mozilla > Firefox does not enable "EV Treatment" if an Intermediate CA Certificate > does not assert the anyPolicy or

Re: Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

On Thu, Nov 12, 2020 at 2:57 AM Dimitris Zacharopoulos wrote: > > I believe this information should be the "minimum" accepted methods of > proving that a Private Key is compromised. We should allow CAs to accept > other methods without the need to first update their CP/CPS. Do people > think that

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

Jakob, On Thu, Nov 12, 2020 at 10:39 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > How would that phrasing cover doppelgangers of intermediary SubCAs under > an included root CA? > > > To clarify, the title of section 5.3 is "Intermediate Certificates".

FNMT: Public Discussion of Root Inclusion Request

All, This is to announce the beginning of the public discussion phase of the Mozilla root CA inclusion process for Fábrica Nacional de Moneda y Timbre (FNMT)’s request to include the AC RAIZ FNMT-RCM SERVIDORES SEGUROS in the root store. See https://wiki.mozilla.org/CA/Application_Process#Process_

Re: FNMT: Public Discussion of Root Inclusion Request

FNMT provided the following clarification regarding its audits: *Audits:* Annual audits are performed by AENOR Internacional. The most recent audit was completed by AENOR, for the period ending January 12, 2020, according to ETSI EN 319 411-1 audit criteria (OVCP: Organizational Validation Certif

Re: CCADB Proposal: Add field called Full CRL Issued By This CA

FWIW - Here is a recent post on this issue from JC Jones - https://github.com/mozilla/crlite/issues/43#issuecomment-726493990 On Thu, Nov 19, 2020 at 4:00 PM Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, November 18, 2020 at 8:26:50 PM UTC-8,

Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

The purpose of this email is to begin public discussion on a modification to subsection 5 in section 2.1 of the Mozilla Root Store Policy. Issue #206 in GitHub discusses the need to bring the reuse period for domain validation in line with the cer

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

ng tail for this change, and existing domains/customers should not be affected until then. Cheers, Ben > > Doug > > -Original Message- > From: dev-security-policy > On Behalf Of Ben Wilson via dev-security-policy > Sent: Monday, November 30, 2020 2:27 PM > To: mozilla-d

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

See my responses inline below. On Tue, Dec 1, 2020 at 1:34 PM Ryan Sleevi wrote: > > > On Tue, Dec 1, 2020 at 2:22 PM Ben Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> See responses inline below: >> >> On Tu

Re: Policy 2.7.1: MRSP Issue #206: Limit re-use of domain name verification to 398 days

ot addressed in this update, adding clarification on > domain verification reuse for SMIME would be a good improvement on the > existing policy. > > -Original Message- > From: dev-security-policy > On Behalf Of Ben Wilson via dev-security-policy > Sent: Wednesday, Decembe

Re: FNMT: Public Discussion of Root Inclusion Request

ribió: > > > On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy, > > > wrote: > > > > > > > > [...] > > > > > > > > *CP/CPS:* > > > > > > > > > https://www.sede.fnmt.gob.es/documents/10445900/1053

Summary of Camerfirma's Compliance Issues

All, We have prepared an issues list as a summary of Camerfirma's compliance issues over the past several years. The purpose of the list is to collect and document all issues and responses in one place so that an overall picture can be seen by the community. The document is on the Mozilla wiki: h

Re: FNMT: Public Discussion of Root Inclusion Request

/dpcs/ac-servidores-seguros-tipo-2 ? > (They both lead to the same CPS v. 1.6 document.) > > > Ben > > > > > > On Wed, Dec 2, 2020 at 7:15 AM Matthias van de Meent via > dev-security-policy wrote: > > >> > > >> On Fri, 27 Nov 2020 at 11:19,

Re: FNMT: Public Discussion of Root Inclusion Request

ow where to look, I'll probably check the contents more >> > thoroughly sometime in the following weekend, at first glance they >> > already looked much better. >> > >> > -Matthias >> > >> > [1] >> https://www.sede.fnmt.gob.es/en/no

Policy 2.7.1: MRSP Issue #207: Require audit statements to provide information about which CA Locations were audited

All, This email is part of the discussion for the next version of the Mozilla Root Store Policy (MSRP), version 2.7.1, to be published during of Q1-2021. For audit delays, we currently require that audit statements disclose the locations that were and were not audited, but that requirement has no

Policy 2.7.1: MRSP Issue #211: Align OCSP requirements in Mozilla's policy with the BRs

This discussion is related to Issue #211 on GitHub . Effective September 30, 2020, as a result of the Browser Alignment Ballot , section 4.9.10 of the CA/Browser Forum’s BaselineRequire

Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

This is the last issue that I have marked for discussion in relation to version 2.7.1 of the Mozilla Root Store Policy . It is identified and discussed in GitHub Issue #218

Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

This is to announce the beginning of the public discussion phase of the Mozilla root CA inclusion process for GlobalSign. See https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 through 9). GlobalSign has four (4) new roots to include in the root store. Two roots, one RSA

Re: Policy 2.7.1: MRSP Issue #207: Require audit statements to provide information about which CA Locations were audited

Thanks, Jeff. These are useful comments, and I will take them into consideration in revising our proposal. On Tue, Jan 12, 2021 at 8:38 AM Jeff Ward via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Sunday, January 3, 2021 at 8:38:05 AM UTC-6, Jeff Ward wrote: > > On T

Policy 2.7.1: MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

I've updated the subject line for this thread so that it is consistent with the other issues. Also, as an update to what we are considering to address this issue, we are looking at pointing to existing language here: https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable. On Thu, Nov 12

Policy 2.7.1: MRSP Issue #139: Audits required even if not issuing

I've updated this subject line for consistency with the other issues. On Tue, Oct 6, 2020 at 2:31 PM Ben Wilson wrote: > Here is the first issue for discussion here on the m.d.s.p. list relative > to the next version of the Mozilla Root Store Policy (v.2.7.1). > > #139

Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

d to..." (rather than "All > CAs..."). > > Technically-constrained intermediate certs don't have to be disclosed to > CCADB, but "in all situations where the CA is enabled for server > certificate issuance" clearly includes technically-constrained >

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

I agree that we should add language that makes it more clear that the key destruction exception for audit only applies to the CA certificates whose key has been destroyed. I'm also hoping that a CAO wouldn't destroy a Root CA key if there were still valid subordinate CAs that the CAO might need to

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

As proposed, changes to section 3.1.3 of the MRSP do not make any distinction between root CAs and subordinates. Nonetheless, what if we added this sentence to MRSP section 3.1.3, "This cradle-to-grave audit requirement applies equally to subordinate CAs as it does to root CAs."? If that does not

Re: MRSP Issue #147 - Require EV audits for certificates capable of issuing EV certificates

In addition to the original proposal, I propose that we hyperlink "capable of issuing EV certificates" to https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable. On Thu, Nov 12, 2020 at 11:23 AM Ben Wilson wrote: > > On Thu, Nov 12, 2020 at 2:03 AM Dimitris Zacharopoulos via > dev-secu

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

In line with the proposed hyperlink to https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable from "capable of issuing EV certificates" (see Issue #147), then I don't think the proposed parenthetical is necessary anymore, and I think this issue can be considered resolved without needing t

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

As an alternative for this addition to MRSP section 5.3, please consider and comment on: Thus, the operator of a CA certificate trusted in Mozilla’s CA Certificate Program MUST disclose in the CCADB all non-technically constrained CA certificates they issue that chain up to that CA certificate tru

Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports

All, Based on the comments received, I am inclined to clarify the proposed language under Issues #154 and #187 with reference to a CA's Bugzilla compliance bugs rather than "incidents". The existing language in section 2.4 of the MRSP already requires the CA to promptly file an Incident Report in

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

Here is my attempt to reword section 3.2 based on combining MRSP version 2.4.1 with version 2.7. My approach was to align the concepts of "competent", "independent" and "qualified" with their more-accepted meanings. Version 2.4.1 and earlier versions of the Mozilla Root Store Policy mixed some of t

Mozilla's Response to Camerfirma's Compliance Issues

Dear All, We appreciate your comments and participation in the discussion about the Summary of Camerfirma's Compliance Issues, https://wiki.mozilla.org/CA:Camerfirma_Issues. Mozilla has not yet made a decision about Camerfirma's continuation in our root store. We intend to continue with our publi

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

Thanks, Clemens. I'll take a look. Also, apparently my redlining was lost when my message was saved to the newsgroup. I'll see if I can re-post without the text formatting of strikeouts and underlines. On Tue, Jan 26, 2021 at 10:24 AM Clemens Wanko via dev-security-policy < dev-security-policy@l

Re: Mozilla's Response to Camerfirma's Compliance Issues

All, So far there have been several good comments. Please keep them coming. I want to take this opportunity just to clarify a few of things. First, it has been Mozilla's long-standing position that, "We believe that the best approach to safeguarding secure browsing is to work with CAs as partne

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On second thought, I think that Mozilla can accomplish what we want without modifying the MRSP (which says audits MUST be performed by a Qualified Auditor, as defined in the Baseline Requirements sect

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Thu, Jan 28, 2021 at 12:44 PM Ryan Sleevi wrote: > > > On Thu, Jan 28, 2021 at 1:43 PM Ben Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On second thought, I think that Mozilla can accomplish what we want >>

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

This is a reminder that I will close discussion on this tomorrow. On Mon, Jan 11, 2021 at 5:59 PM Ben Wilson wrote: > This is to announce the beginning of the public discussion phase of the > Mozilla root CA inclusion process for GlobalSign. > > See https://wiki.mozilla.org/CA/Application_Proces

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

On January 11, 2021, we began the public discussion period [Step 4 of the Mozilla Root Store CA Application Process ] for the above-referenced GlobalSign inclusion request. *Summary of Discussion and Completion of Action Items [Steps 5-8]:* Recentl

Action on Camerfirma Root CAs

All, Thank you for your continued participation in this discussion, and for those of you who have provided very thoughtful comments. As many of you have pointed out, there do not appear to be remediation actions that Camerfirma can take at this time to sufficiently reduce the risk of continuing

Public Discussion for Inclusion of e-commerce monitoring's GLOBALTRUST 2020 Root

This is to announce the beginning of the public discussion phase ( https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 through 9)) of the Mozilla root CA inclusion process for e-commerce monitoring GmbH’s GLOBALTRUST 2020 Root CA. e-commerce monitoring operates as "GlobalTru

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

All, Under Step 10 of the https://wiki.mozilla.org/CA/Application_Process, this is notice of a "further question or concern" that has arisen concerning GlobalSign's issuance of a 1024-bit RSA certificate. See https://bugzilla.mozilla.org/show_bug.cgi?id=1690807. GlobalSign has indicated that it wil

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

All, GlobalSign has provided a very detailed incident report in Bugzilla - see https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2. There are a few remaining questions that still need to be answered, so this email is just to keep you aware. Hopefully later this week I'll be able to come back an

Re: Policy 2.7.1: MRSP Issue #186: Requirement to Disclose Self-signed Certificates

In the Github document, which I'm using to track proposed language, I've added "This applies to all non-technically constrained CA certificates, including those that share the same key pair whether they are self-signed, doppelgänger, reissued, cross-signed, or other roots." https://github.com/BenWi

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

All, I've modified the proposed change to MRSP section 3.2 so that it would now insert a middle paragraph that would read: "A Qualified Auditor MUST have relevant IT Security experience, or have audited a number of CAs, and be independent and not conflicted. Individuals have competence, partnersh

Policy 2.7.1: MRSP Issue #221: Wrong hyperlink for "Material Change" in MRSP Section 8

All, I am proposing for v. 2.7.1 a minor change that corrects a hyperlink issue in MRSP section 8. The link to "material change" here redirects to "alteration of instruments" - https://legal-dictionary.thefreedictionary.com/Material+Changes, which is altogether wrong since we're talking about a "m

Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports

" - which would include those that occurred or were open - at any time during the audit period. Additional guidance and interpretation of the above would be available on the wiki. On Thu, Jan 28, 2021 at 2:05 PM Ryan Sleevi wrote: > > > On Sun, Jan 24, 2021 at 11:33 PM Ben Wilson vi

Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports

I'm fine with that suggestion. On Fri, Feb 12, 2021 at 5:06 AM malcol...--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, 11 February 2021 at 21:14:13 UTC, Ben Wilson wrote: > > 11. all incidents (as defined in section 2.4), including those reported > in >

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

curity-policy > > On > > Behalf Of Nick Lamb via dev-security-policy > > Sent: donderdag 11 februari 2021 19:12 > > To: dev-security-policy@lists.mozilla.org > > Cc: Ben Wilson > > Subject: Re: Public Discussion of GlobalSign's CA Inclusion Request for >

Re: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

All, The proposed change currently reads, "Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually from the time of CA key pair generation until the CA certificate is no longer trusted by Mozilla's root store or until all c

Re: Policy 2.7.1: MRSP Issue #207: Require audit statements to provide information about which CA Locations were audited

The current proposed draft of changes is at https://github.com/BenWilson-Mozilla/pkipolicy/commit/443b4c5d5155942a216322480f3a6a273ea2 Right now, I'm considering having subsection of MRSP section 3.1.4 say, "the CA locations that were or were not audited" - with a hyperlink to https://wiki.moz

  1   2   >