Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

On March 10, 2021, we began the public discussion period [Step 4 of the Mozilla Root Store CA Application Process ] for ANF’s inclusion request. One commenter recounted some of ANF's certificate misissuance events and expressed concern that CAs

Mozilla Root Store Policy MRSP 2.7.1 Update

All, Version 2.7.1 of the Mozilla Root Store Policy (MRSP) is now saved in Mozilla's GitHub repository with an effective date of May 1, 2021. See https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md Here is the redline: https://github.com/mozilla/pkipolicy/pull/223/files Soon we

Providing Auditor Qualifications (was Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications)

All, Here, for your review and comment, is the final version of the wiki page guidance on providing auditor qualifications. I appreciate the input we received from ETSI and WebTrust audit groups on this current version.

Re: Prioritization of Root CA Inclusion Requests

For future reference, this is now posted here: https://wiki.mozilla.org/CA/Prioritization. On Wed, Mar 24, 2021 at 4:49 PM Ben Wilson wrote: > All, > > I'd like to have you review the prioritization proposal below, which will > help us as we process CA inclusion requests. ( >

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

All, As discussed previously, here is a draft amendment to the Audit Statements wiki page for your review and comment: https://wiki.mozilla.org/CA/Audit_Statements#Providing_Auditor_Qualifications Sincerely yours, Ben ___ dev-security-policy mailing list

Prioritization of Root CA Inclusion Requests

All, I'd like to have you review the prioritization proposal below, which will help us as we process CA inclusion requests. ( https://wiki.mozilla.org/CA/Application_Process) Thanks, Ben --- Prioritization of CA Root Inclusion Requests will be based on the factors described

Public Discussion of Asseco's Root Inclusion Request

Dear All, This is to announce the beginning of the public discussion phase of the Mozilla root CA inclusion process for the *Certum Trusted Root CA* and the *Certum EC-384 CA*. See https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 through 9). These two (2) new root CA

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

5.1. for server certificates issued on or after October 1, 2021, >> verify each dNSName or IPAddress in a SAN or commonName at an interval of >> 398 days or less;" >> >> Can we say: >> "5.1. for server certificates issued on or after October 1, 2021, each >>

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

;> "5.1. for server certificates issued on or after October 1, 2021, each >> dNSName or IPAddress in a SAN or commonName MUST have been validated > accordance with the CABF Baseline Requirements?> within the prior 398 days. >> >> >> >> -Original Messag

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

erver certificates issued on or after October 1, 2021, each > dNSName or IPAddress in a SAN or commonName MUST have been validated accordance with the CABF Baseline Requirements?> within the prior 398 days. > > > > -----Original Message- > From: dev-security-policy > On Beh

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

Bruce, The answer would be yes because we check the validity of the root CA certificate and other CA certificates. Ben On Thu, Mar 11, 2021 at 10:33 AM Ben Wilson wrote: > Hi Bruce, > I think the answer is yes. A CA certificate is no longer trusted once it > has expired or been revoked (or

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

Hi Bruce, I think the answer is yes. A CA certificate is no longer trusted once it has expired or been revoked (or added to OneCRL for subCAs) or removed (roots). But I'm double-checking on the case of certificates with validity periods that extend past the expiration of the root. Ben On Thu, Mar

Re: Public Discussion re: Inclusion of the ANF Secure Server Root CA

Here you go: https://testvalidsslev.anf.es https://testrevokedsslev.anf.es https://testexpiredsslev.anf.es On Thu, Mar 11, 2021 at 6:38 AM Andrey West Siberia via dev-security-policy wrote: > Hello, > I can't find the test URIs for this root certificate... >

Re: Synopsis of Proposed Changes to MRSP v. 2.7.1

Thanks, Ryan I'll work on incorporating your suggestions into the draft we're working on. Ben On Wed, Mar 10, 2021 at 9:10 AM Ryan Sleevi wrote: > > > On Mon, Mar 8, 2021 at 7:08 PM Ben Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >

Public Discussion re: Inclusion of the ANF Secure Server Root CA

All, This is to announce the beginning of the public discussion phase of the Mozilla root CA inclusion process for the ANF Secure Server Root CA. See https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 through 9). The ANF Secure Server Root CA is operated by ANF AC, a

Synopsis of Proposed Changes to MRSP v. 2.7.1

All, Below are the summaries of the proposed resolutions of the issues slated to be addressed by version 2.7.1 of the Mozilla Root Store Policy. A full redline of the proposed changes can be seen here by clicking on the "Files changed" tab:

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

fully age CRLs out once there is no possibility for a revocation >> status update for any certificate in their scope. >> >> Aaron >> >> On Sun, Jan 24, 2021 at 10:22 AM Ben Wilson via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote:

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

All, Here is the currently proposed wording for subsection 5.1 of MRSP section 2.1: " 5.1. for server certificates issued on or after October 1, 2021, verify each dNSName or IPAddress in a SAN or commonName at an interval of 398 days or less;" Ben On Fri, Feb 26, 2021 at 9:48 AM Ryan Sleevi

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

All, Kathleen and I discussed the language of this proposal and have modified it for MRSP section 3.2 as follows: "A Qualified Auditor MUST have relevant IT Security experience, or have audited a number of CAs, and be independent. Each Audit Report MUST be accompanied by documentation provided to

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

Kathleen and I edited the proposed language ( https://github.com/BenWilson-Mozilla/pkipolicy/commit/a69aa03fb92d1b0c3f74fd560dffefdeed934b45) to now read: "The publicly-available documentation relating to each audit MUST contain at least the following clearly-labelled information: ... 11. all

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

Also, I neglected to mention it before, but this issue is also related to Issue #173. While section 7.1 already states that CAs must provide evidence of CA compliance from "creation," the Issue #173 proposal is that section 7.1 be amended to say, "Before being included, CAs MUST provide evidence

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

Thanks, Bruce, for raising the issue of pre-generated, yet unassigned keys. The intent was to cover this scenario. We are aware that CAs might generate 1000s of keys in a partition and then years later assign a few of them as CA keys, others as OCSP responder keys, etc., and some might never be

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

On February 4, 2021, the public discussion period [Step 4 of the Mozilla Root Store CA Application Process ] began on e-commerce monitoring’s inclusion request. No questions or concerns have been raised and there are no open action items for

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

for server certificates issued on or after Feb 1, 2022, each dNSName > or IPAddress in a SAN must have been validated within the prior 398 days > > Is that a compromise you could consider? > > Doug > > > -----Original Message- > From: dev-security-policy > On Behalf Of B

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

I haven't seen any response to my question about whether there is still a concern over the language "as evidenced by a Qualified Auditor's key destruction report". I did add "This cradle-to-grave audit requirement applies equally to subordinate CAs as it does to root CAs" to address the scenarios

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

-security-pol...@lists.mozilla.org> >> Subject: 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: >> >> > >> &g

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

vocation > status update for any certificate in their scope. > > Aaron > > On Sun, Jan 24, 2021 at 10:22 AM Ben Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> All, >> >> Another suggestion came in for clarification that h

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

Just a reminder that discussion is ongoing and scheduled to close this Friday, 26-Feb-2021. On Thu, Feb 4, 2021 at 4:39 PM Ben Wilson wrote: > This is to announce the beginning of the public discussion phase ( > https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps > 4

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

All, I have edited the proposed resolution of Issue #192 as follows: Subsection 3 of MRSP Section 3.1.4. would read: "The publicly-available documentation relating to each audit MUST contain at

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

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

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

y-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 > R46, >

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: 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

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

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,

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."

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

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

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

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

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]:*

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

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: 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

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

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 <

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

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

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

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

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

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 >

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: 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

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

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

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

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

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

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

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

Re: FNMT: Public Discussion of Root Inclusion Request

thoroughly sometime in the following weekend, at first glance they >> > already looked much better. >> > >> > -Matthias >> > >> > [1] >> https://www.sede.fnmt.gob.es/en/normativa/declaracion-de-practicas-de-certificacion >> > On Wed, 2 D

Re: FNMT: Public Discussion of Root Inclusion Request

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, Santiago Brox via dev-security-policy < > > >> dev-secu

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:

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

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

s not 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, December 2,

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

mains/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-dev-security-policy < > mozilla-dev

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

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,

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

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

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

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

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

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

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

Re: NAVER: Public Discussion of Root Inclusion Request

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 >> > objections). >> > On

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

Re: NAVER: Public Discussion of Root Inclusion Request

ike 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. > > > > > > > > > > > > > > > > ‐‐‐

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

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

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."

Re: NAVER: Public Discussion of Root Inclusion Request

he 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.mozilla.

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

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

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

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

Re: NAVER: Public Discussion of Root Inclusion Request

; > > > ‐‐‐ 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 phase 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-secur

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

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:

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

Re: Policy 2.7.1 Issues to be Considered

uld 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-secur

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

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

Re: Policy 2.7.1 Issues to be Considered

tes 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, 2020 4:

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

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

  1   2   >