Re: PEM of root certs in Mozilla's root store

[Ryan Sleevi via dev-security-policy]

It seems like there should be a link to
https://wiki.mozilla.org/CA/FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F
there

I realize there’s a tension between making this easily consumable, and the
fact that “easily consumed” doesn’t and can’t relieve an organization of
having to be responsible and being aware of the issues and discussions here
about protecting their users.

I do worry this is going to encourage one of the things that can make it
more difficult for Mozilla to protect Mozilla users, which is when vendors
blindly using/build a PEM file and bake it into a device they never update.
We know from countless CA incidents that when vendors do that, and aren’t
using these for “the web”, that it makes it more difficult for site
operators to replace these certificates. It also makes it harder for
Mozilla to fix bugs in implementations or policies and otherwise take
actions that minimize any disruption for users. At the same time, Mozilla
running a public and transparent root program does indeed mean it’s better
for users than these vendors doing nothing at all, which is what would
likely happen if there were too many roadblocks.

While personally, I want to believe it’s “not ideal” to make it so easy, I
realize the reality is plenty of folks already repackage the Mozilla store
for just this reason, totally ignoring the above link, and make it easy for
others to pull in. At least this way, you could reiterate that this list
doesn’t really absolve these vendors of having to keep users up to date and
protected and be able to update their root stores for their products, by
linking to
https://wiki.mozilla.org/CA/FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F

On Tue, Oct 6, 2020 at 5:47 PM Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> All,
>
> I've been asked to publish Mozilla's root store in a way that is easy to
> consume by downstreams, so I have added the following to
> https://wiki.mozilla.org/CA/Included_Certificates
>
> CCADB Data Usage Terms
> 
>
> PEM of Root Certificates in Mozilla's Root Store with the Websites
> (TLS/SSL) Trust Bit Enabled (CSV)
> <
> https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEM?TrustBitsInclude=Websites
> >
>
> PEM of Root Certificates in Mozilla's Root Store with the Email (S/MIME)
> Trust Bit Enabled (CSV)
> <
> https://ccadb-public.secure.force.com/mozilla/IncludedRootsPEM?TrustBitsInclude=Email
> >
>
>
> Please let me know if you have feedback or recommendations about this.
>
> Thanks,
> Kathleen
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Let's Encrypt: 302 total OCSP responses served beyond acceptable timelines

[Jacob Hoffman-Andrews via dev-security-policy]

On Sat, Sep 26, 2020 at 9:09 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Let's Encrypt provides a community mutual assistance site (with
> contributions from staff) on which a large volume of messages are
> posted each day.
>
> https://community.letsencrypt.org/
>
> Once the problem was identified did you check to see if any messages to
> that site were likely related to this issue? I guess it's not very
> likely with a small number of deviations.
>

We did not check the Let's Encrypt community site for reports about this
issue. There's more detail in the linked Bugzilla issue: the nature of the
bug was that it would only occur for certificates that never made it into
users' hands, so no one would have seen OCSP errors. Additionally, the OCSP
responses did not exceed their NotAfter date, so they would not have
produced errors even if they were fetched by user agents.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

PEM of root certs in Mozilla's root store

[Kathleen Wilson via dev-security-policy]

All,

I've been asked to publish Mozilla's root store in a way that is easy to 
consume by downstreams, so I have added the following to 
https://wiki.mozilla.org/CA/Included_Certificates


CCADB Data Usage Terms


PEM of Root Certificates in Mozilla's Root Store with the Websites 
(TLS/SSL) Trust Bit Enabled (CSV)



PEM of Root Certificates in Mozilla's Root Store with the Email (S/MIME) 
Trust Bit Enabled (CSV)




Please let me know if you have feedback or recommendations about this.

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1 Issues to be Considered

[Ben Wilson via dev-security-policy]

Corey,
We will add this to the 2.7.1 batch of proposed changes. I've started
discussion of Issue 147, so we can discuss it there, or I can create a
separate email thread for it.

On Fri, Oct 2, 2020 at 5:16 AM Corey Bonnell  wrote:

> Including https://github.com/mozilla/pkipolicy/issues/152 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-security-policy <
> dev-security-policy@lists.mozilla.org>
> *Sent:* Thursday, October 1, 2020 4:21:48 PM
> *To:* mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> *Subject:* 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279585097&sdata=GZ8%2F%2FJg0sa%2FKAPcRes4w1tWPtQrXfd3xAdjoEY62gBQ%3D&reserved=0.
> So far, I have identified 13
> items to consider for this policy update; which are tagged as v.2.7.1 in
> GitHub (
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Flabels%2F2.7.1&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279585097&sdata=fNzV%2FEjnNTWKsA%2BNMJo08ESzNttlkIHINUr23jRy%2F5E%3D&reserved=0).
> I will
> appreciate your input on this list as to whether there are issues that
> should be added or removed. Then, based on the list, I will start a
> separate discussion thread in mozilla.dev.security.policy for each issue.
>
> #139 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F139&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279585097&sdata=7xarPFNWPfgfEcddgA%2BsVk23dViiNv9QRxpEoqjp1vk%3D&reserved=0>
> - Audits are
> required even if no longer issuing - Clarify that audits are required until
> the CA certificate is revoked, expired, or removed. Related to Issue #153.
>
> #147 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F147&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279595092&sdata=kt7ywgVE5S6VqWB47cNsTf943OyNzdtSEbqA14%2F4TYo%3D&reserved=0>
> - 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
> certificates.
>
> #153 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F153&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279595092&sdata=FToJiGI1xtCsEBHmmRsB2P%2Fv%2B8SFqze5HouMkmsJ8lc%3D&reserved=0>
> – Cradle-to-Grave
> Contiguous Audits – Specify the audits that are required from Root key
> generation ceremony until expiration or removal from Mozilla’s root store.
> Related to Issue #139.
>
> #154 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F154&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279595092&sdata=qEnD7LC%2FXsEF3Hs7u68fxA4fNAPFaP7rGLox7GvIjn4%3D&reserved=0>
> - Require Management
> Assertions to list Non-compliance – Add to MRSP 2.4 “If being audited to
> the WebTrust criteria, the Management Assertion letter MUST include all
> known incidents that occurred or were still open/unresolved at any time
> during the audit period.”
>
> #173 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F173&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279595092&sdata=THxcETFV6slWGx4h3Y9E9l4OVcRvCf43iPjtoqqpIzc%3D&reserved=0>
> - Strengthen
> requirement for newly included roots to meet all past and present
> requirements – Add language to MRSP 7.1 so that it is clear that before
> being included CAs must comply and have complied with past and present
> Mozilla Root Store Policy and Baseline Requirements.
>
> #186 <
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fpkipolicy%2Fissues%2F186&data=02%7C01%7C%7C3ef02764f0b14af6998e08d86647ab2e%7C84df9e7fe9f640afb435%7C1%7C0%7C637371805279595092&sdata=dh6vJtrZyl627lpZkxM9yracHtNbZQ4T1G9cP4tmh6U%3D&reserved=0>
> - Clarify MR

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

[Ben Wilson via dev-security-policy]

 #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
certificates.

This issue is presented for resolution in the next version of the Mozilla
Root Store Policy.

Suggested language is presented here:
https://github.com/BenWilson-Mozilla/pkipolicy/commit/a83eca6d7d8bf2a3b30529775cb55b0c8a5f982b


The proposal is to replace "if issuing EV certificates" with "if capable of
issuing EV certificates" in two places -- for WebTrust and ETSI audits.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

MRSP Issue #139: Audits required even if not issuing

[Ben Wilson via dev-security-policy]

 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 certificate is revoked, expired, or removed. Related to Issue #153
.

Seven (7) comments are listed so far for this issue in GitHub, including
discussion re: whether auditors can provide reports when a CA isn't being
used to issue certificates.

I made an initial attempt to address this with some language in line 272 in
the following commit in my GitHub repository -
https://github.com/BenWilson-Mozilla/pkipolicy/commit/888dc139d196b02707d228583ac20564ddb27b35
(related changes also appear below in that commit).

The suggested language would amend the first paragraph of section 3.1.3 of
the MRSP to read, "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 copies of the CA
private key have been completely destroyed, as evidenced by a Qualified
Auditor's key destruction report, whichever occurs sooner. Successive
period-of-time audits MUST be contiguous (no gaps)."

We will need to discuss scope and timing for implementing this requirement.

Thanks in advance for your contributions and suggestions.

Ben
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1 Issues to be Considered

[Ben Wilson via dev-security-policy]

Doug,
I don't have any preconceived notions. I was hoping that by discussing the
implementation issues for each issue we could determine appropriate
timeframes.
Ben

On Tue, Oct 6, 2020 at 12:19 PM Doug Beattie 
wrote:

> Ben,
>
> When, approximately, do you think this proposed 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, 2020 4:22 PM
> To: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: 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 update; which are tagged as v.2.7.1 in
> GitHub (https://github.com/mozilla/pkipolicy/labels/2.7.1). I will
> appreciate your input on this list as to whether there are issues that
> should be added or removed. Then, based on the list, I will start a
> separate discussion thread in mozilla.dev.security.policy for each issue.
>
> #139  - Audits are
> required even if no longer issuing - Clarify that audits are required until
> the CA certificate is revoked, expired, or removed. Related to Issue #153.
>
> #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 certificates.
>
> #153  – Cradle-to-Grave
> Contiguous Audits – Specify the audits that are required from Root key
> generation ceremony until expiration or removal from Mozilla’s root store.
> Related to Issue #139.
>
> #154  - Require
> Management Assertions to list Non-compliance – Add to MRSP 2.4 “If being
> audited to the WebTrust criteria, the Management Assertion letter MUST
> include all known incidents that occurred or were still open/unresolved at
> any time during the audit period.”
>
> #173  - Strengthen
> requirement for newly included roots to meet all past and present
> requirements – Add language to MRSP 7.1 so that it is clear that before
> being included CAs must comply and have complied with past and present
> Mozilla Root Store Policy and Baseline Requirements.
>
> #186  - Clarify MRSP 5.3
> Requirement to Disclose Self-signed Certificates – Clarify that self-signed
> certificates with the same key pair as an existing root meets MRSP 5.3’s
> definition of an intermediate certificate that must be disclosed in the
> CCADB.
>
> #187  - Require
> disclosure of incidents in Audit Reports –  To MRSP 3.1.4 “The
> publicly-available documentation relating to each audit MUST contain at
> least the following clearly-labelled information: “ add “11. all incidents
> (as defined in section 2.4) that occurred or were still open/unresolved at
> any time during the audit period, or a statement that the auditor is
> unaware of any;”
>
> #192  - Require
> information about auditor qualifications in the audit report – Require
> audit statements to be accompanied by documentation of the auditor’s
> qualifications demonstrating the auditor’s competence and experience.
>
> #205  - Require CAs to
> publish accepted methods for proving key compromise – Require CAs to
> disclose their acceptable methods for proving key compromise in section
> 4.9.12 of their CPS.
>
> #206  - Limit re-use of
> domain name verification to 395 days – Amend item 5 in MRSP 2.1 with “and
> verify ownership/control of each dNSName and iPAddress in the certificate's
> subjectAltName at intervals of 398 days or less;”
>
> #207  - Require audit
> statements to provide information about which CA Locations were and were
> not audited, and the extent to which they were (or were not) audited
>
> #211  - Align OCSP
> requirements in Mozilla's policy with the section 4.9.10 of the Baseline
> Requirements
> #218  Clarify CRL
> requirements for End Entity Certificates – For CRLite, Mozilla would like
> to ensure that it has full lists of revoked certificates. If the CA uses
> partial CRLs, then requi

RE: Policy 2.7.1 Issues to be Considered

[Doug Beattie via dev-security-policy]

Ben,

When, approximately, do you think this proposed 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, 2020 4:22 PM
To: mozilla-dev-security-policy 
Subject: 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 update; which are tagged as v.2.7.1 in GitHub 
(https://github.com/mozilla/pkipolicy/labels/2.7.1). I will appreciate your 
input on this list as to whether there are issues that should be added or 
removed. Then, based on the list, I will start a separate discussion thread in 
mozilla.dev.security.policy for each issue.

#139  - Audits are required 
even if no longer issuing - Clarify that audits are required until the CA 
certificate is revoked, expired, or removed. Related to Issue #153.

#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 certificates.

#153  – Cradle-to-Grave 
Contiguous Audits – Specify the audits that are required from Root key 
generation ceremony until expiration or removal from Mozilla’s root store.
Related to Issue #139.

#154  - Require Management 
Assertions to list Non-compliance – Add to MRSP 2.4 “If being audited to the 
WebTrust criteria, the Management Assertion letter MUST include all known 
incidents that occurred or were still open/unresolved at any time during the 
audit period.”

#173  - Strengthen requirement 
for newly included roots to meet all past and present requirements – Add 
language to MRSP 7.1 so that it is clear that before being included CAs must 
comply and have complied with past and present Mozilla Root Store Policy and 
Baseline Requirements.

#186  - Clarify MRSP 5.3 
Requirement to Disclose Self-signed Certificates – Clarify that self-signed 
certificates with the same key pair as an existing root meets MRSP 5.3’s 
definition of an intermediate certificate that must be disclosed in the CCADB.

#187  - Require disclosure of 
incidents in Audit Reports –  To MRSP 3.1.4 “The publicly-available 
documentation relating to each audit MUST contain at least the following 
clearly-labelled information: “ add “11. all incidents (as defined in section 
2.4) that occurred or were still open/unresolved at any time during the audit 
period, or a statement that the auditor is unaware of any;”

#192  - Require information 
about auditor qualifications in the audit report – Require audit statements to 
be accompanied by documentation of the auditor’s qualifications demonstrating 
the auditor’s competence and experience.

#205  - Require CAs to publish 
accepted methods for proving key compromise – Require CAs to disclose their 
acceptable methods for proving key compromise in section
4.9.12 of their CPS.

#206  - Limit re-use of domain 
name verification to 395 days – Amend item 5 in MRSP 2.1 with “and verify 
ownership/control of each dNSName and iPAddress in the certificate's 
subjectAltName at intervals of 398 days or less;”

#207  - Require audit 
statements to provide information about which CA Locations were and were not 
audited, and the extent to which they were (or were not) audited

#211  - Align OCSP 
requirements in Mozilla's policy with the section 4.9.10 of the Baseline 
Requirements
#218  Clarify CRL requirements 
for End Entity Certificates – For CRLite, Mozilla would like to ensure that it 
has full lists of revoked certificates. If the CA uses partial CRLs, then 
require CAs to provide the URL location of their full and complete CRL in the 
CCADB.

Ben Wilson
Mozilla Root Program Manager
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
_

Re: Audit Reminders for Intermediate Certs

[Kathleen Wilson via dev-security-policy]

 Forwarded Message 
Subject: Summary of October 2020 Outdated Audit Statements for 
Intermediate Certs

Date: Tue, 6 Oct 2020 14:00:25 + (GMT)


CA Owner: Government of The Netherlands, PKIoverheid (Logius)
   - Certificate Name: QuoVadis PKIoverheid Organisatie Server CA - G3
SHA-256 Fingerprint: 
CE2332390208742A1ACA6513974C4C9DB2691EAF4568B533E4A17ED5DDA973E6

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: QuoVadis PKIoverheid Server CA 2020
SHA-256 Fingerprint: 
EB2C2A806C69FC963C4E24A5BBEA20ED4E3B86AE798730BB4EEA51BF9DE33325

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: QuoVadis PKIoverheid Organisatie Persoon CA - G3
SHA-256 Fingerprint: 
15073C6BBDC74699A88518C27A57C956E5E23D6CA9619E521A468C7873DE4F8A

Standard Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: QuoVadis PKIoverheid Organisatie Services CA - G3
SHA-256 Fingerprint: 
BECFDE124CEDD344D925CB55EDDA662D9A9C0688FA9A0870CE3DBB6DA4313E4E

Standard Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: QuoVadis PKIoverheid Organisatie Server CA - G3
SHA-256 Fingerprint: 
85363A24CB1B66E6CF6244E87D243DBB8306F607357C614CB9C4C224A0E04358

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019


Bug Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1669518



CA Owner: DigiCert
   - Certificate Name: thawte Primary Transition Root
SHA-256 Fingerprint: 
DBA1097710F3C629943C23DC7503AC82B9142825EF049F1C26538DB36B480549

Standard Audit Period End Date (mm/dd/): 05/31/2019
BR Audit Period End Date (mm/dd/): 05/31/2019

   - Certificate Name: TrustWise G3
SHA-256 Fingerprint: 
DD563A271590588CC055685E368CB02F6DED343186358B3A3814B2AA97005525

Standard Audit Period End Date (mm/dd/): 06/21/2019

   - Certificate Name: Government of Malta e-Mail Certificate Service CA G3
SHA-256 Fingerprint: 
0054DD53C74523CD542979850828F0F3CD18228687D4ED4AE345B5FEADE1FC9C

Standard Audit Period End Date (mm/dd/): 06/21/2019





CA Owner: Asseco Data Systems S.A. (previously Unizeto Certum)
   - Certificate Name: SSL.com Root Certification Authority RSA
SHA-256 Fingerprint: 
ACF718DF838E640051777D1947F51620E8D804BA186553AE52FC9811B5D34B8B

Standard Audit Period End Date (mm/dd/): 06/30/2019
Code Signing Audit Period End Date (mm/dd/): 06/30/2019
BR Audit Period End Date (mm/dd/): 06/30/2019
EV SSL Audit Period End Date (mm/dd/): 06/30/2019

   - Certificate Name: SSL.com EV Root Certification Authority RSA R2
SHA-256 Fingerprint: 
B97176F21B6ED64609267B2D1A2A9FAF0C4DEBD44644DC85EB6AE986FC867D56

Standard Audit Period End Date (mm/dd/): 06/30/2019
Code Signing Audit Period End Date (mm/dd/): 06/30/2019
BR Audit Period End Date (mm/dd/): 06/30/2019
EV SSL Audit Period End Date (mm/dd/): 06/30/2019






___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy