Greetings, In response to comments from Trev and Roman, I am editing section 3.3.2 (Normative References and Incorporation by Reference), which currently reads as follows:
To avoid duplication, divergence, and staleness, incorporation by reference SHOULD be used for shared definitions and externally defined normative requirements (e.g., CA/Browser Forum Requirements, RFCs, documents incorporated by reference therein, corresponding WebTrust or ETSI audit criteria, and other applicable policies). However, incorporation by reference MUST NOT be used as a substitute for describing CA-specific implementation practices. CP/CPS Documentation MUST clearly identify incorporated documents. CP/CPS Documentation MAY reference operational, contractual, informational, repository, or technical materials maintained outside the CP/CPS Documentation by the CA operator, Root Programs, the CCADB, standards bodies, or the CA/Browser Forum (e.g., webpages, Subscriber Agreements, validation procedures, or technical appendices), provided that: - such materials are clearly identified and publicly accessible where necessary to understand the CA operator’s practices; their scope and applicability are clearly described; - the CP/CPS Documentation remains sufficiently complete and coherent for a reviewer to understand how the CA operator complies with applicable requirements; and - such references do not alter or supersede applicable requirements. See https://github.com/BenWilson-Mozilla/pkipolicy/commit/03f638b283d71a0b163056c2998e50b5cb8c6658 (lines 255-364). I'm open to further suggestions and refinements. Ben On Wed, May 13, 2026 at 1:44 AM 'Roman Fischer' via [email protected] <[email protected]> wrote: > To add to Trev's list, we have references to: > > - Our webpage, document repository and the demo webpages > - CCADB > - ETSI > > > > Regards > Roman > > > > *From:* 'Trevoli Ponds-White' via [email protected] < > [email protected]> > *Sent:* Dienstag, 12. Mai 2026 23:08 > *To:* [email protected] > *Cc:* Ben Wilson <[email protected]>; Trevoli Ponds-White < > [email protected]>; [email protected] < > [email protected]>; Martijn Katerbarg < > [email protected]> > *Subject:* Re: MRSP 3.1: Issue #s 282 and 295: CP/CPS Documentation > > > > That's fantastic Ben. Great suggestion Martijn I hadn't made that > connection yet but definitely concur. For the documents reference what > about adding this sentence: > > "*This excludes documents defined by or referenced in the Baseline > Requirements for the applicable certificate type.*" > > In practice this would mean for TLS certificates all these external > references are allowable: > > 1. Any RFC, IANA, or NIST resource referenced in the applicable BRs. > 2. Subscriber Agreement. Which is defined by in the BRs. > 3. Relying Party Agreement. Which is referenced in the BRs. (We > probably want to fix this in a cleanup ballot because in the BRs we refer > to this like a defined term but it’s not defined.) > 4. The CA/B Forum website. > 5. WebTrust Principles and Critieria. > 6. CA/B F recommended Github repos. Such as the Debian weak keys. > 7. The links for TorProject, Fermat Attack, and Public Suffix List. > > I'm don't know enough about what other types of external docs other CAs > are referencing to know how restrictive this should be. In addition to > referencing some of those listed above ours also includes a reference to a > privacy policy and the policy pages for the root programs. > > On Tuesday, May 12, 2026 at 1:38:24 PM UTC-7 Ben Wilson wrote: > > That's fine, too. I'll make that change. > > > > On Tue, May 12, 2026, 2:23 PM Martijn Katerbarg <[email protected]> > wrote: > > Ben, > > > > While this is feedback we sent on the recent survey, I’ll repeat it here: > For the effective date, is Mozilla willing to consider aligning with > Apple’s policy update proposal, targeting July of 2027? > > > > Both programs are making changes which will require extensive reviews > across multiple CP/CPSes. As we know, incorrections in a CPS can have a > large impact. As such, we worry that a “rush job” on this, is a recipe for > disaster. Additionally, several CAs are also still working on making the > documentation available in MarkDown format, and splitting our general > CP/CPSes into purpose specific CP/CPSes. > > > > I feel a careful balance of gains verses risk management is warranted > here, hence our request to align with the later date proposed by Apple. > > > > Regards, > > > > Martijn > > > > *From: *'Ben Wilson' via [email protected] < > [email protected]> > *Date: *Tuesday, 12 May 2026 at 22:05 > *To: *Trevoli Ponds-White <[email protected]> > *Cc: *[email protected] <[email protected]> > *Subject: *Re: MRSP 3.1: Issue #s 282 and 295: CP/CPS Documentation > > This Message Is From an External Sender > > This message came from outside your organization. > > Report Suspicious > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/J5K_pWsD!B8YZvmQVdwhyZt_sl1TdIKMQQB65j-Aw9mHfzsB7g4hFXqY6kvSNmqPvqb09mkqmBIZARmZaXCivEiPFrTVOOrTv5DHhyTEZD1E9BXIoQl8KUZ71TbsLAWmnSpQhGYydKQI$> > > > > Hi Trev, > > Thanks for your comments. I have revised section 3.3 of the working draft > to add an effective date of October 15, 2026, and also made other changes. > > See > https://github.com/BenWilson-Mozilla/pkipolicy/commit/c555615430fd188db394503baad6c62981e15aa8 > <https://urldefense.com/v3/__https://github.com/BenWilson-Mozilla/pkipolicy/commit/c555615430fd188db394503baad6c62981e15aa8__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyLQ3Hwdi$> > . > > Thanks again, > > Ben > > > > On Tue, May 12, 2026 at 12:58 PM 'Trevoli Ponds-White' via > [email protected] <[email protected]> wrote: > > I like the updates Ben. I have a few comments > > > > 1) 3.3.3 Implementation Commitments" should probably have a further future > date. This policy provides more clarity and people may want to edit their > CP/CPS. > > > > 2) "multiple external documents." This could use some examples or > additional clarity. For example Mozilla has a few places where CAs are > required to "communicate to subscribers" this is generally done with the > Subscriber Agreement not the CP/CPS. Is this saying we need to duplicate > the text that is also in the Subscriber Agreement into the CP/CPS with some > language like "we comply this with this by putting the following in the > Subscriber Agreement..." or is that not considered an external document and > instead some extension of the CP/CPS? > > > > Thanks! > > > > On Friday, May 8, 2026 at 11:23:54 PM UTC-7 Roman Fischer wrote: > > Hi Ben, > > > > Your suggested wording makes the intention clear to me. And section 7 is > also IMHO very clear and useful to ensure traceability over past versions > of the documents. > > > > Rgds > Roman > > > > *From:* Ben Wilson <[email protected]> > *Sent:* Freitag, 8. Mai 2026 17:46 > *To:* Roman Fischer <[email protected]> > *Cc:* [email protected] > *Subject:* Re: MRSP 3.1: Issue #s 282 and 295: CP/CPS Documentation > > > > Hi Aaron and Roman, > > Thanks for your feedback and questions. The CCADB has two fields > implicated here: > > - the “CA Document Repository” field, which identifies repository > locations and may contain multiple URLs as a semicolon-separated list; and > - the “Document Link” field(s), which identify the specific URLs for > the actual CP/CPS documents themselves. > > Because the CCADB separately tracks the specific document URLs, I am > considering emphasizing those specific document links over the "repository” > concept. In other words, the CCADB still collects the repository location, > which is a useful reference when browsing a CA operator’s website to locate > related CP/CPS documentation, but I think it's less important from a > filing/compliance perspective now that the CCADB stores direct document > links separately. > > I am currently considering abbreviating the language to something like: > > “CA operators MUST ensure that CP/CPS Documentation is made publicly > available in a structured, text-based format (e.g. Markdown, AsciiDoc, or > equivalent) and in a manner that preserves publicly accessible version > history. CA operators MUST ensure that the current location (URL) of each > CP/CPS document is accurately disclosed and maintained within the CCADB.” > > I’ve tried to avoid being overly prescriptive in order to preserve > flexibility. > > What are your thoughts? Will this approach adequately addresses your > concerns, or should we take a different one? > > Also, are your concerns related to subsection 7 (document archiving)? > Should that paragraph be edited too? > > Thanks again, > Ben > > > > On Fri, May 8, 2026 at 1:13 AM 'Roman Fischer' via > [email protected] <[email protected]> wrote: > > I'm a bit confused: Does this mean that the disclosed location should be > the repository (typically a webpage or github repo) where the current and > the archived versions are listed or the URL of the current CP/CPS document > (typically a Markdown file hosted somewhere) or an array of URLs of the > current and previous versions of the CP/CPS document? > > > > Thx > Roman > > > > *From:* 'Aaron Gable' via [email protected] < > [email protected]> > *Sent:* Mittwoch, 6. Mai 2026 04:11 > *To:* [email protected] > *Cc:* Ben Wilson <[email protected]>; Wayne <[email protected]>; > [email protected] <[email protected]>; Aaron Gable < > [email protected]> > *Subject:* Re: MRSP 3.1: Issue #s 282 and 295: CP/CPS Documentation > > > > I think that's much better. One potential issue: if a CA maintains a > separate CP and CPS (I believe still acceptable in v3.1), they could be in > different GitHub repositories. This would make disclosing a single URL in > the "Document Repository" field difficult, as it could only point to one or > the other. > > On Monday, April 27, 2026 at 1:08:54 PM UTC-10 Ben Wilson wrote: > > What about this formulation of Item 2 under MRSP section 3.3? > > 2. CA operators MUST maintain CP/CPS Documentation in a structured, > text-based format suitable for version control (e.g., Markdown, AsciiDoc, > or equivalent), host such documentation in a publicly accessible repository > or equivalent system that provides publicly accessible version history, and > ensure that the current, publicly accessible locations (URLs) of that > CP/CPS documentation are disclosed in, and kept up to date within, the > CCADB “Document Repository” field. > > > > Thanks, > > > > Ben > > > > On Sun, Apr 26, 2026 at 11:47 AM Ben Wilson <[email protected]> wrote: > > Hi Aaron, > > Thanks for these comments. > > You’re right that the draft hasn't explicitly addressed location of > documentation disclosure and archiving. > > One idea is to leverage the CCADB field “Document Repository” or to create > an adjacent field to specify archival locations. > > I am considering adding the following requirement to MRSP Section 3.3: > > “CA operators MUST ensure that the location (URL) of their CP/CPS > Documentation is disclosed and maintained in the CCADB 'Document > Repository' field.” > > However, that alone will be inadequate. We'll need to amend the CCADB > Policy and/or provide guidance for use of the “Document Repository” field > (and possibly add another field for archival locations) to clarify the use > of the(se) field(s) and ensure uniformity and consistent implementation. > For example: > > “The ‘Document Repository’ field MUST contain one or more URLs that > provide access to the CA Owner’s current CP/CPS Documentation. Where CP/CPS > Documentation is maintained in a version-controlled repository, the URL > MUST reference the repository or a stable landing page that clearly > identifies the current version and provides access to prior versions or > version history. CA Owners MUST ensure that this field is kept accurate and > up to date.” > > What are everyone's thoughts on this, and Is another CCADB field needed to > point to the archival repository (even if they are both in the same > location)? > > Ben > > > > > > On Fri, Apr 24, 2026 at 1:11 PM Aaron Gable <[email protected]> wrote: > > I concur, the changes related to CPS content seem good and don't seem > onerous. > > > > I have one minor concern: Section 3.3(2) says that CAs must keep their > CP/CPS Documentation in markdown in a public repo, but doesn't say how the > CA shall disclose the location of such. Linked from our website (as the > current version of the requirements says)? Linked from our Repository? > Disclosed in CCADB? Paragraph (7) of the same section does say that CAs > shall "maintain links to all historical versions", but it doesn't say > where, and my interpretation of that paragraph is that it is about > preventing bit-rot (i.e. old links have to continue working). > > > > Thanks, > > Aaron > > > > On Wed, Apr 22, 2026 at 12:37 PM Wayne <[email protected]> wrote: > > Having read the comparison of proposed changes nothing jumps out as a > stepback. Overall the changes seem to improve clarity, transparency, and > are overall a step forward for the industry. > > > > Thanks everyone for your hard work in getting us this far. > > > > - Wayne > > > > On Wednesday, April 22, 2026 at 8:23:40 PM UTC+1 Ben Wilson wrote: > > All, > > This thread begins discussion of proposed updates to the Mozilla Root > Store Policy (MRSP) dealing with Certificate Policy/Certification Practice > Statement (CP/CPS) Documentation. Throughout the MRSP, the term, “CP/CPS > Documentation,” will replace the phrase “CP, CPS, or combined CP/CPS”. > > Over time, CP/CPS documentation has increasingly relied on incorporation > by reference to the Baseline Requirements, which seems to reduce visibility > into CA-specific implementation details. Also, concerns have been expressed > in community discussions (e.g. the 2025 Roundtable, dev-security-policy, > and CCADB Public > <https://urldefense.com/v3/__https://groups.google.com/a/ccadb.org/g/public/c/iZg_253IZfo/m/eC8kQnOlBgAJ__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyI8p4FJk$>) > regarding the level of detail provided in CP/CPS documentation. The > proposed changes are intended to improve the extent to which CP/CPS > documentation can be used to understand and evaluate a CA operator’s actual > practices, rather than serve as a high-level, referential document. > > The proposed changes primarily address the following GitHub issues: > > - #295 > > <https://urldefense.com/v3/__https://github.com/mozilla/pkipolicy/issues/295__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyHkTdrDj$> > – > Revisions to MRSP 3.3 > - #282 > > <https://urldefense.com/v3/__https://github.com/mozilla/pkipolicy/issues/282__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyDWKAZ6o$> > – > Require Markdown/AsciiDoc for CP/CPS documentation > > Here is comparison of proposed MRSP 3.1 (as of today) vs. current MRSP v. > 3.0: > https://github.com/mozilla/pkipolicy/compare/3b7d84f5c9708cf6be9655319825d60ea338eca4...ad8e1766be6e0e9a93a64b0b71506ae923086ec5 > <https://urldefense.com/v3/__https://github.com/mozilla/pkipolicy/compare/3b7d84f5c9708cf6be9655319825d60ea338eca4...ad8e1766be6e0e9a93a64b0b71506ae923086ec5__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyKrwEy1l$> > . > > Here is the working branch for MRSP v. 3.1 (working draft, subject to > change): > https://github.com/BenWilson-Mozilla/pkipolicy/blob/3.1/rootstore/policy.md > <https://urldefense.com/v3/__https://github.com/BenWilson-Mozilla/pkipolicy/blob/3.1/rootstore/policy.md__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyNBSckQq$> > . > > > > *Overview of Proposed Changes* > > *1. Sufficiency and Clarity of Disclosure - **#295* > <https://urldefense.com/v3/__https://github.com/mozilla/pkipolicy/issues/295__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyHkTdrDj$> > > The current MRSP requires that CP/CPS documentation provide sufficient > information to determine compliance. In practice, however, many CP/CPS > documents have relied heavily on incorporation by reference (e.g., citing > Baseline Requirements sections) without clearly describing how those > requirements are satisfied with implementation. > > The proposed changes clarify that CP/CPS documentation must describe the > CA operator’s *implementation* of applicable requirements, not merely > identify them. > > Under this approach: > > - *3.3.1* CP/CPS documentation is expected to provide CA-specific > detail sufficient for a technically competent reviewer to understand how > validation, issuance, revocation, and related processes are actually > performed. > - *3.3.2* Incorporation by reference remains permissible for > normative obligations and shared definitions, but it cannot substitute for > disclosure of CA-specific practices. > - *3.3.3* Documentation must be explicit, bounded, and testable where > feasible, enabling meaningful audit, review, and comparison across CA > operators. > - *3.3.4* Reviewers should not be required to reconstruct operational > practices by correlating multiple external documents. > - *3.3.5* CP/CPS documentation must contain or clearly reference > certificate, CRL, and OCSP profiles (separate, versioned companion > documents are allowed where appropriate). > - *3.3.6* CP/CPS documentation must reflect current operations with > substantive changes traceable through version history and changelogs. > > The intent is to make CP/CPS documentation a reliable and self-contained > description of how a CA operates in practice, particularly in areas where > the Baseline Requirements or other standards allow discretion. > > *2. Documentation Format and Versioning - **#282* > <https://urldefense.com/v3/__https://github.com/mozilla/pkipolicy/issues/282__;!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyDWKAZ6o$> > > Also proposed (in Item 2 of MRSP 3.3) are requirements to maintain > publicly accessible CP/CPS documentation in a structured, text-based format > (e.g., Markdown, AsciiDoc, or similar), with version history. It is > proposed that the requirement to publish CP/CPS documentation on the CA > operator’s website be removed, to allow for alternative publication models > (e.g., version-controlled public repositories). CA operators may continue > to publish PDF versions on their websites if they choose. > > These edits are intended to promote CA operator consistency in how such > documentation is maintained and published and to support more efficient > review, comparison, and automation. Rather than prescribing a single tool > or platform, the requirement focuses on characteristics: structured text, > version control, and publicly accessible history. > > Feedback on the proposed direction and draft language is welcome. > > Thanks, > Ben Wilson > Mozilla Root Program > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/d0ce4550-b3a1-4ec6-9bb1-6984ba7da030n%40mozilla.org > <https://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/d0ce4550-b3a1-4ec6-9bb1-6984ba7da030n*40mozilla.org?utm_medium=email&utm_source=footer__;JQ!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyAXL5Kw2$> > . > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/18857592-1c83-480d-a0b5-6e071c03969cn%40mozilla.org > <https://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/18857592-1c83-480d-a0b5-6e071c03969cn*40mozilla.org?utm_medium=email&utm_source=footer__;JQ!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyEg8tR7R$> > . > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB0170793B0492FDC89EF045EDFA3D2%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM > <https://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB0170793B0492FDC89EF045EDFA3D2*40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer__;JQ!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyNm7emcS$> > . > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/5162792e-35b4-4d84-90a5-79560c9c3cc5n%40mozilla.org > <https://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/5162792e-35b4-4d84-90a5-79560c9c3cc5n*40mozilla.org?utm_medium=email&utm_source=footer__;JQ!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyExlj1WF$> > . > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYOQAP73bpC6fTzm9n%3Dqa_-x%2BEJdhvG6RzP69bPKgw%3DKQ%40mail.gmail.com > <https://urldefense.com/v3/__https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA*2B1gtaYOQAP73bpC6fTzm9n*3Dqa_-x*2BEJdhvG6RzP69bPKgw*3DKQ*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUlJSU!!J5K_pWsD!3Hn4r1DdAtKrFhqLq-5gvw1-0OT2ThG_woxugee0xEHGeLrS9Qb1_PEp2w0isN2zL-la5qxJohXZFzuTkORHL8aUaeZdyNpegXnZ$> > . > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/206640f0-2e8c-4eb9-ba96-d7031c5f5405n%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/206640f0-2e8c-4eb9-ba96-d7031c5f5405n%40mozilla.org?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB017085FF55FEECDB2C0795DBFA062%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB017085FF55FEECDB2C0795DBFA062%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZmSnZykbbrW1hqYP2uZ%2B7kBKvzLZL8ybntC-UD%2BeC%2Bpg%40mail.gmail.com.
