Hi Doug, I can make changes in section 7.5 to explicitly exempt OCSP Signing Certificates by adding something like, "OCSP signing certificates, while technically considered end-entity certificates, are exempt from this EKU restriction and instead MUST include only the id-kp-OCSPSigning EKU."
On the other allowed EKUs for S/MIME certificates, I took the language straight from the S/MIME BRs because there were concerns about how different phrasing might affect the continued use of multipurpose S/MIME certificates. On the transition to dedicated roots and deprecation of trust bits, I can add a cross-reference to the root CA lifecycle section of the MRSP to make this more clear. Just to clarify, Mozilla's approach to root CA lifecycles <https://wiki.mozilla.org/CA/Root_CA_Lifecycles>, based on comments we received last year, is to use trust bit removal for roots with the websites trust bit enabled and "distrust after" for S/MIME. Trust bit removal signifies that no certificates under the root, regardless of issuance date, will be trusted for that purpose (i.e. serverAuthentication) after the date in the schedule. The schedule specifies that "Distrust for S/MIME After Date" will be used for roots with the email trust bit enabled. This allows certificates issued before the specified date to remain trusted until their expiration. I appreciate your concerns about timelines and also desire to facilitate root store planning re: dedicated roots. I understand that Google Chrome has released an updated root store policy, which I need to review and determine where there is common ground. We're certainly open to suggestions on how we might make these transitions easier to navigate. Thanks, Ben On Thu, Jan 16, 2025 at 7:46 AM Doug Beattie <[email protected]> wrote: > Hey Ben, > > > > Just a minor suggestion. In sections 7.5.1 and 7.5.2, we’re saying that > all CA and “end entity certificates” must contain the applicable EKU. How > do we classify OCSP signing certificates, are they “end entity > certificates”? If so, then we should make a carve out for those, correct? > Are there any other types of certificates that CAs need to issue under > dedicated roots like this? I can’t think of any. > > > > For my own educational benefit… In section 7.5.2, what EKUs other than > id-kp-emailProtection > and perhaps id-kp-clientAuth would ever be needed in an S/MIME dedicated > hierarchy? RFC5280 has specific requirements around the hierarchical > aspects of Certificate Policy (In a CA certificate, these policy > information terms limit the set of policies for certification paths that > include this certificate.), but there is no similar requirement around > EKUs. Is there ever a need to supply EKUs outside of the set that browsers > and root programs have applied this hierarchical rule to (basically the > list that is in the current section)? If not, then I would change this: > > - They MAY include other extendedKeyUsages, but they MUST NOT include > extendedKeyUsages of id-kp-serverAuth, id-kp-codeSigning, > id-kp-timeStamping, or anyExtendedKeyUsage. > > To this: > > - They MAY include id-kp-clientAuth. All other values are prohibited > > > > Lastly, in section 7.5.3, can you say what happens when the trust bits are > disabled in 2026 or 2028? Is this when CAs must stop issuing certificates, > or is this when any certificate under that hierarchy is no longer trusted > no matter when it was issued? Historically this is when they won’t be > trusted in Mozilla while Chrome uses the SCTNotAfter date that aligns with > when the certificate was issued. It’s hard to merge Mozilla and Chrom > requirements into a CA action plan when this happens. It would be awesome > if the Mozilla and Chrome policies aligned so it would be easier to > understand all of these applicable milestones. And if Apple and Microsoft > have similar plans, it would be great if they also pick up the same > timelines for moving to dedicated roots. One timeline with the same rules > per root type. > > > Doug > > > > > > > > Doug > > > > *From:* 'Ben Wilson' via [email protected] < > [email protected]> > *Sent:* Wednesday, January 15, 2025 1:38 PM > *To:* [email protected] > *Subject:* Re: MRSP 3.0: Issue #279: TLS-specific and S/MIME-specific > Root CAs > > > > Here is another version: > > > > *7.5 Dedicated Root Certificates* > > All root CA certificates added to Mozilla's Root Store after January 1, > 2025, will only be trusted for either TLS server authentication (websites > trust bit) or S/MIME email protection (email trust bit). Existing root CA > certificates that do not comply with this requirement MUST transition to > one or the other prior to December 31, 2028, i.e., by having one of their > trust bits (websites or email) removed. > > *7.5.1 Server Authentication Hierarchies* > > Subordinate CA and end entity certificates issued under a Root CA > certificate added after January 1, 2025, with the websites trust bit > enabled MUST include an extendedKeyUsage extension that asserts only > id-kp-serverAuth or both id-kp-serverAuth and id-kp-clientAuth. > > *7.5.2 S/MIME Hierarchies* > > Subordinate CA and end entity certificates issued under a Root CA > certificate added after January 1, 2025, with the email trust bit enabled > MUST include an extendedKeyUsage extension that asserts > id-kp-emailProtection. They MAY include other extendedKeyUsages, but they > MUST NOT include extendedKeyUsages of id-kp-serverAuth, id-kp-codeSigning, > id-kp-timeStamping, or anyExtendedKeyUsage. > > *7.5.3 Transition Plan for Existing Roots* > > Root CA certificates included in Mozilla's Root Store as of January 1, > 2025, that have both the websites and the email trust bits enabled MAY > remain trusted after April 15, 2026, if the CA operator has submitted a > transition plan by April 15, 2026, to migrate to dedicated hierarchies by > December 31, 2028. > > Transition plans MAY include: > > 1. Submission of requests for inclusion of single-purpose roots; > 2. Requests to remove the websites trust bit or the email trust bit > from a dual-purpose root; > 3. Timelines for phasing out conflicting uses of the root (e.g. dates > by which inconsistent certificates will expire or issuance will cease); and > 4. Revocation or replacement of certificates that do not meet the > requirements of Sections 7.5.1 or 7.5.2. > > > > > > On Fri, Jan 10, 2025 at 3:54 PM Ben Wilson <[email protected]> wrote: > > Thanks, Martijn > > I'll change that. > > Ben > > > > On Fri, Jan 10, 2025 at 1:01 PM 'Martijn Katerbarg' via > [email protected] <[email protected]> wrote: > > Ben, > > > > > They MUST NOT share a public key with any certificate that asserts any > other extendedKeyUsage values. > > > > In the updated proposal, to me this reads as "If CA Owner A issues an > S/MIME leaf certificate with public key A as the subject's public key, then > CA Owner B is not allowed to issue a TLS certificate with the same public > key as subject.". I assume that's not the actual intent here, and this > restiction on public keys and associated EKUs should rather be scoped to > Root CA and Subordinate CA Certificates, not leaf certificates? > > > > Regards, > > Martijn > > > > Op vrijdag 10 januari 2025 om 19:03:51 UTC+1 schreef Ben Wilson: > > For your consideration and comment, here is another iteration. I've > changed the transition dates and the allowed EKUs for the S/MIME > hierarchy. > > (Also, note that per > https://wiki.mozilla.org/CA/Root_CA_Lifecycles#Transition_Schedule > <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.mozilla.org%2FCA%2FRoot_CA_Lifecycles%23Transition_Schedule&data=05%7C02%7Cdoug.beattie%40globalsign.com%7C4df0c43e297043f5bd1708dd3593cddb%7C8fff67c182814635b62f93106cb7a9a8%7C0%7C0%7C638725632942520611%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=cDqi%2FoU0VOx9%2BEYYZwFf1xRAGtjpAdFIetEvmbEUMJs%3D&reserved=0>, > any root created before 2012 will have its websites trust bit removed prior > to April 15, 2028, in any event.) > > > > *7.5 Dedicated Root Certificates* > > All root CA certificates added to Mozilla's Root Store after January 1, > 2025, will only be trusted for either TLS server authentication (websites > trust bit) or S/MIME email protection (email trust bit). Existing root CA > certificates that do not comply with this requirement MUST transition to > one or the other prior to December 31, 2028, i.e., by having one of their > trust bits (websites or email) removed. > > *7.5.1 TLS Server Authentication Roots* > > Subordinate CA and end entity certificates issued under a Root CA > certificate added after January 1, 2025, with the websites trust bit > enabled, MUST include an extendedKeyUsage extension that asserts only > id-kp-serverAuth or both id-kp-serverAuth and id-kp-clientAuth. They MUST > NOT share a public key with any certificate that asserts any other > extendedKeyUsage values. > > *7.5.2 S/MIME Roots* > > Subordinate CA and end entity certificates issued under a Root CA > certificate added after January 1, 2025, with the email trust bit enabled > MUST include an extendedKeyUsage extension that asserts > id-kp-emailProtection. They MAY include other extendedKeyUsages, but they > MUST NOT include extendedKeyUsages of id-kp-serverAuth, id-kp-codeSigning, > id-kp-timeStamping, or anyExtendedKeyUsage. They MUST NOT share a public > key with any certificate that asserts any other extendedKeyUsage values. > > *7.5.3 Transition Plan for Existing Roots* > > Root CA certificates included in Mozilla's Root Store as of January 1, > 2025, that have both the websites and the email trust bits enabled MAY > remain trusted after April 15, 2026, if the CA operator has submitted a > transition plan by April 15, 2026, to migrate to dedicated hierarchies by > December 31, 2028. > > Transition plans MAY include: > > 1. Submission of requests for inclusion of single-purpose roots; > 2. Requests to remove the websites trust bit or the email trust bit > from a dual-purpose root; > 3. Timelines for phasing out conflicting uses of the root (e.g. dates > by which inconsistent certificates will expire or issuance will cease); and > 4. Revocation or re-issuance of certificates that do not meet the > requirements of Sections 7.5.1 or 7.5.2. > > > > > > On Fri, Dec 27, 2024 at 4:49 PM Ben Wilson <[email protected]> wrote: > > Thanks, Martijn, Jeremy, and others who have commented on Issue #279 thus > far. > > I am thinking that I should conduct a CA survey to determine the S/MIME > use cases and the reasons for ensuring the validity of multipurpose S/MIME > certificates into the 2029 timeframe. I also need to take a closer look at > the logistics of removing trust bits vs. adding distrust-after dates, and > I'll get back to you on this. > > Thanks again, > > Ben > > > > On Mon, Dec 23, 2024 at 3:11 AM 'Martijn Katerbarg' via > [email protected] <[email protected]> wrote: > > Ben, > > > > As Jeremy also pointed out, the proposed deadline seems too strict for > S/MIME purposes. > > > > I’m assuming this will be done the same way as with the root deprecation > based on key creation date, in that Mozilla will disable trust bits for > roots on or after January 1, 2027. If so, S/MIME is already in trouble. > > > > Even for the Multipurpose and Strict profiles, which allow issuance for 2 > years (825 days). Any certificate issued based on those profiles today for > the maximum term, would expire in 2027, i.e. past the stated deadline. > > > > Regards, > > Martijn Katerbarg > Sectigo > > > > > > *From: *[email protected] <[email protected]> on behalf of > Jeremy Rowley <[email protected]> > *Date: *Friday, 20 December 2024 at 17:13 > *To: *[email protected] <[email protected]> > *Subject: *Re: MRSP 3.0: Issue #279: TLS-specific and S/MIME-specific > Root CAs > > One additional thought I had on this is that it moves SMIME to strict > profiles faster than previously intended. From the SMIME BRs: Strict: > id-kp-emailProtection SHALL be present. Other values SHALL NOT be present. > Multipurpose and Legacy: id-kp-emailProtection > > One additional thought I had on this is that it moves SMIME to strict > profiles faster than previously intended. > > From the SMIME BRs: > > > Strict: id-kp-emailProtection SHALL be present. Other values SHALL NOT be > present. > > Multipurpose and Legacy: id-kp-emailProtection SHALL be present. Other > values MAY be present. The values id-kp-serverAuth, id-kp-codeSigning, > id-kp-timeStamping, and anyExtendedKeyUsage SHALL NOT be present. > > > > Moving to strict instead of multi-purpose is fine IMO, except we should do > a survey to find out what will break. IIRC, there were a few Microsoft > products that required Microsoft EKUs to work properly. I'd put the burden > on the CAs to provide information about what will break with moving to > strict instead of multi-purpose full chain certificates, but I would like > to know what will break by restricting SMIME more than the CABF does. > > On Thursday, December 19, 2024 at 11:19:44 AM UTC-7 Jeremy Rowley wrote: > > The extensions look right to me. I think that's a short timeline for email > certificates considering the legacy profile is still allowed. Do you want > to split it into two? A timeline for TLS compared to email? > > > > On Thu, Dec 19, 2024 at 6:12 AM Mike Shaver <[email protected]> wrote: > > I can’t speak to the extension-value details, but I agree with it being a > good change. > > > > Mike > > > > On Thu, Dec 19, 2024 at 12:17 AM 'Ben Wilson' via [email protected] > <[email protected]> wrote: > > All, > > Here for comment is a first draft of a proposal to phase-out multi-purpose > root CA certificates. This is tied to GitHub Issue #279 > <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F279__%3B!!J5K_pWsD!1Pdh6wrUwVs1p_vQImAzmKTvk4z0U40gmrfAgYmGph9pnBDs-fdFKfOyAYMNQPuEr7pmQF1G5dPM6o1vlIiEa_ry%24&data=05%7C02%7Cdoug.beattie%40globalsign.com%7C4df0c43e297043f5bd1708dd3593cddb%7C8fff67c182814635b62f93106cb7a9a8%7C0%7C0%7C638725632942539330%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=ryibxrgNKei4po6Hjzxn%2BFlth7pALKTqP3HiJ1pW2dM%3D&reserved=0>, > referenced in the subject line above. > > This proposal is that a new Section 7.5 be added to the Mozilla Root Store > Policy (MRSP). Other conforming changes would be made elsewhere in the MRSP > to remove any implication that a root CA certificate could have both the > websites trust bit and the email-protection trust bit after January 1, 2027. > > Please provide any comments or suggestions you might have to improve or > change this proposal. > > Thanks, > > Ben > > > > *7.5 Dedicated Root Certificates* > > Effective immediately, all root CA certificates being considered for > inclusion in Mozilla's Root Store MUST be dedicated either to TLS server > authentication or to S/MIME email protection. Existing root CA certificates > that do not comply with this requirement MUST be replaced or transition to > a dedicated hierarchy prior to January 1, 2027. > > *7.5.1 TLS Server Authentication Roots* > > Root CA certificates dedicated to TLS server authentication with the > websites trust bit enabled MUST meet the following criteria: > > 1. All subordinate CA certificates MUST: > > > - Include the extendedKeyUsage extension and assert only: > > > - id-kp-serverAuth; or > - Both id-kp-serverAuth and id-kp-clientAuth. > > > - Not share a public key with any certificate that asserts a different > extendedKeyUsage value. > > > 2. All end-entity certificates issued MUST: > > > - Include the extendedKeyUsage extension and assert only: > > > - id-kp-serverAuth; or > - Both id-kp-serverAuth and id-kp-clientAuth. > > *7.5.2 S/MIME Roots* > > Root CA certificates dedicated to S/MIME with the email protection trust > bit enabled MUST meet the following criteria: > > 1. All subordinate CA certificates MUST: > > > - Include the extendedKeyUsage extension and assert only: > > > - id-kp-emailProtection; or > - Both id-kp-emailProtection and id-kp-clientAuth. > > > - Not share a public key with any certificate that asserts a different > extendedKeyUsage value. > > > 2. All end-entity certificates issued MUST: > > > - Include the extendedKeyUsage extension and assert only: > > > - id-kp-emailProtection; or > - Both id-kp-emailProtection and id-kp-clientAuth. > > *7.5.3 Transition Plan for Existing Multi-Purpose Roots* > > Root CA certificates included in Mozilla's Root Store as of January 1, > 2025, with both the websites and the email trust bits enabled, MAY continue > to be trusted after January 1, 2026, if by such date the CA operator has > submitted a transition plan that demonstrates a feasible migration to a > dedicated hierarchy that will be completed prior to January 1, 2027. > > Transition plans MUST address the following: > > 1. Existing submissions of requests for inclusion of new > single-purpose roots; > 2. Requests to remove the websites trust bit or the email trust bit > from a multi-purpose root; and > 3. Timelines for phasing out multiple uses of the root--dates by which > certificates that do not meet the requirements of Sections 7.5.1 or 7.5.2 > will be revoked, expire, be replaced, or for which issuance will cease. > > > > -- > 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%2B1gtaYWFREw%2B0KOU61bVgjZXxHZuvQyXmQDSbMgMZqVk18FTQ%40mail.gmail.com > <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FCA*2B1gtaYWFREw*2B0KOU61bVgjZXxHZuvQyXmQDSbMgMZqVk18FTQ*40mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter__%3BJSUl!!J5K_pWsD!1Pdh6wrUwVs1p_vQImAzmKTvk4z0U40gmrfAgYmGph9pnBDs-fdFKfOyAYMNQPuEr7pmQF1G5dPM6o1vlNAu95UW%24&data=05%7C02%7Cdoug.beattie%40globalsign.com%7C4df0c43e297043f5bd1708dd3593cddb%7C8fff67c182814635b62f93106cb7a9a8%7C0%7C0%7C638725632942553969%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=n%2BWuSSRnwin9Br0oBBGJcgiXF3rIgE34zyRLdLrugFo%3D&reserved=0> > . > > -- > 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/CADQzZqt_NZxJQ8L8ZX7UxDqKPsHTvNMSZTmedJoJ6r3g98kvhQ%40mail.gmail.com > <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FCADQzZqt_NZxJQ8L8ZX7UxDqKPsHTvNMSZTmedJoJ6r3g98kvhQ*40mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter__%3BJQ!!J5K_pWsD!1Pdh6wrUwVs1p_vQImAzmKTvk4z0U40gmrfAgYmGph9pnBDs-fdFKfOyAYMNQPuEr7pmQF1G5dPM6o1vlL83ozSc%24&data=05%7C02%7Cdoug.beattie%40globalsign.com%7C4df0c43e297043f5bd1708dd3593cddb%7C8fff67c182814635b62f93106cb7a9a8%7C0%7C0%7C638725632942567646%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=DsdKbPXphA8%2FYe13IKkicOxg%2Bni4NVHDBQxqWabntIU%3D&reserved=0> > . > > -- > 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/83193857-0c75-4935-8002-1b846d560552n%40mozilla.org > <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2F83193857-0c75-4935-8002-1b846d560552n*40mozilla.org%3Futm_medium%3Demail%26utm_source%3Dfooter__%3BJQ!!J5K_pWsD!1Pdh6wrUwVs1p_vQImAzmKTvk4z0U40gmrfAgYmGph9pnBDs-fdFKfOyAYMNQPuEr7pmQF1G5dPM6o1vlDzq4b4J%24&data=05%7C02%7Cdoug.beattie%40globalsign.com%7C4df0c43e297043f5bd1708dd3593cddb%7C8fff67c182814635b62f93106cb7a9a8%7C0%7C0%7C638725632942581036%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=zM7Uteilxy7dObl%2Bob%2F6JYXVC7bmsUT34V%2BOUjBPb9k%3D&reserved=0> > . > > -- > 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/SA1PR17MB6503D26602094A482EBEC3D5E3022%40SA1PR17MB6503.namprd17.prod.outlook.com > <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FSA1PR17MB6503D26602094A482EBEC3D5E3022%2540SA1PR17MB6503.namprd17.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C02%7Cdoug.beattie%40globalsign.com%7C4df0c43e297043f5bd1708dd3593cddb%7C8fff67c182814635b62f93106cb7a9a8%7C0%7C0%7C638725632942594565%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=h4T9aANDJztUN6epp4mIyaBxsQnYxFt8AMRQyTuWsnw%3D&reserved=0> > . > > -- > 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/cefa00db-a7cd-4ea9-83b0-006c01ec5e3dn%40mozilla.org > <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2Fcefa00db-a7cd-4ea9-83b0-006c01ec5e3dn%2540mozilla.org%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C02%7Cdoug.beattie%40globalsign.com%7C4df0c43e297043f5bd1708dd3593cddb%7C8fff67c182814635b62f93106cb7a9a8%7C0%7C0%7C638725632942608887%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=LURe%2BrW%2BCTW4%2BxtJCfzPBwS92ea6BiJIKmmjzFa%2BhCA%3D&reserved=0> > . > > -- > 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%2B1gtabCKk-svZ2%2BsXnyqo7z%2BEQdpvUFSgMPj45hs48wgCq2JA%40mail.gmail.com > <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FCA%252B1gtabCKk-svZ2%252BsXnyqo7z%252BEQdpvUFSgMPj45hs48wgCq2JA%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C02%7Cdoug.beattie%40globalsign.com%7C4df0c43e297043f5bd1708dd3593cddb%7C8fff67c182814635b62f93106cb7a9a8%7C0%7C0%7C638725632942622297%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=jx7MTtu2n8Fmn3t7tPEbGVjUcFzDCsM4v%2Bqsfcl%2F%2Fo4%3D&reserved=0> > . > -- 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%2B1gtabZn%3DH%2BjCx5tJoBJJVw7ZK93GBiEFuEoovehDLprsEGMw%40mail.gmail.com.
