1706228 - Add DigiCert root Certificates

I had closed CCADB Root Case 743 thinking that it was replaced by CCADB Root Case 772. Now I think I understand that the latter is for Apple and that the former is for Mozilla to process, so I reopened Root Case 743. Please correct me if I'm wrong. Also, please review those fields that NEED additional information. Thanks.

Ben Wilson

Assignee

Updated

•

5 years ago

Whiteboard: [ca-initial] → [ca-verifying]

Ben Wilson

Assignee

Comment 4

•

5 years ago

In processing Case 743 - https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000743, I noticed the following items need to be completed.

Baseline Requirements Self-Assessment (upload to this bug)
CA's Response to Required Practices (edit field in CCADB)
CA's Response to Forbidden Practices (edit field in CCADB)

DigiCert TLS RSA4096 Root G5

At https://tls-observatory.services.mozilla.com/static/ev-checker.html clear this error "BuildCertChain failed: SEC_ERROR_REVOKED_CERTIFICATE Peer's Certificate has been revoked"
Provide "Description of PKI Hierarchy" (edit field in CCADB)

DigiCert TLS ECC P384 Root G5

Provide "Description of PKI Hierarchy" (edit field in CCADB)

DigiCert SMIME RSA4096 Root G5

Upload S/MIME certificate example to this bug.
Provide "Description of PKI Hierarchy" (edit field in CCADB)

DigiCert SMIME ECC P384 Root G5

Upload S/MIME certificate example to this bug.
Provide "Description of PKI Hierarchy" (edit field in CCADB)

Martin Sullivan

Reporter

Comment 5

•

4 years ago

Attached file DigiCert CA Compliance Self Assessment_final.xlsx — Details

Find our self assesment attached.

Martin Sullivan

Reporter

Comment 6

•

4 years ago

Attached file ECC_testcert.cer — Details

ECC test certificate issued off this ICA
https://crt.sh/?id=4914328032

Martin Sullivan

Reporter

Comment 7

•

4 years ago

Attached file RSA_testcert.cer — Details

RSA test smime Certificate

from RSA SMIME ICA
https://crt.sh/?id=4914328038

Ben Wilson

Assignee

Comment 8

•

4 years ago

Attached file DigiCert-CPS-Review.xlsx — Details

Here is the CPS review in Excel. From this list, I'll extract the important items that need to be fixed and post them as a comment in this bug.

Ben Wilson

Assignee

Comment 9

•

4 years ago

DIGICERT SELF-ASSESSMENT	DETAILED ROOT PROGRAM REVIEW Reviewer Comments	APPLICABLE REQUIREMENTS and References from RFC 3647, the BRs, the MRSP, CCADB Policy, etc.
CPS 1.3.2	Good - all required language appears in the second paragraph, although the following is a bit confusing in the first paragraph: "Affiliates do not perform domain or IP address validation."	1.3.2. Registration Authorities Indicate whether your CA allows for Delegated Third Parties, or not. Indicate which sections of your CP/CPS specify such requirements, and how the CP/CPS meets the BR requirements for RAs (including non-delegation of domain validation to RAs per BR § 1.3.2). (This is also a Mozilla Forbidden Practice.)
CP/CPS 1.4.2	OK, (Not expressly stated in CPS 1.4.2, but OK, since this is recommended as a "Should".)	1.4.2 Prohibited Certificate Uses CAs should ensure that the domain name registrant has approved or authorized a certificate request and prohibit the use of certificate to conduct surreptitious interception by third parties (except with the domain registrant's permission).
CP/CPS 4.2.1	Good - but curious on how CAA domains are resolved when Amazon Trust Services also uses "amazon.com, amazontrust.com, awstrust.com, amazonaws.com, aws.amazon.com"	2.2 Publication of information - CAA Section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement SHALL state the CA's policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements. It shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA "issue" or "issuewild" records as permitting it to issue. The CA SHALL log all actions taken, if any, consistent with its processing practice.
CP/CPS 2.1	Good - language about annual updates to CPS is in CPS 2.3	2.3. Time or frequency of publication "The CA SHALL ... annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. The CA SHALL indicate conformance with this requirement by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document." Indicate your CA's policies/practices to ensure that the BRs are reviewed regularly, and that the CA's CP/CPS is updated annually.
CP/CPS 2.4	OK - but this is not exactly what was intended by the question.	2.4. Access controls on repositories Acknowledge that all Audit, CP, CPS documents required by Mozilla's CA Certificate Policy and the BRs will continue to be made publicly available.
		3. IDENTIFICATION AND AUTHENTICATION
CP/CPS 3.1.1	Should fix to reference compliance with X.500, RFC 5280, the BRs, and the EVGs	3.1 Naming Naming must be compliant with X.500, RFC5280 and BRs. The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards. Names for CAs should be meaningful and descriptive. See Generic Names for CAs in Potentially Problematic Practices. Also, CNs and SANs in TLS server certificates cannot contain internal names or reserved IP addresses, see § 7.1.4.2.1 below.
CP/CPS 3.2.2	Should fix - DigiCert needs to explain in greater detail the steps that DigiCert takes to verify organization identity for OV and EV certificates.	3.2.2.1 Identity If the certificate will contain Subject Identity Information (e.g. OV certificates with name or address of an organization), then indicate how your CP/CPS meets the requirements in this section of the BRs.
CP/CPS 3.1.6	OK - but why doesn't the CPS say that DigiCert uses the same process as that used for OSU Server certificates?	3.2.2.2 DBA/Tradename If the certificate will contain a DBA or tradename, then indicate how your CP/CPS meets the requirements in this section of the BRs.
CP/CPS 3.2.2	Need to fix. CPS Section 3.1.1 says "DigiCert issues EV SSL/TLS Certificates to .onion domains in accordance with Appendix F of the EV Guidelines or Appendix C of the Baseline Requirements when the FQDN contains “onion” as the rightmost label."	3.2.2.4 If the CA will issue .onion certificates, then explain how your CA validates the FQDN in accordance with Appendix B.
CPS 3.2.2	Needs clarification/removal. This section requires that DigiCert be a Registrar or affiliate of a Registrar. DigiCert cannot use an external RA for domain validation.	3.2.2.4.12 Validating Applicant as a Domain Contact "This method may only be used if the CA is also the Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name." If your CA uses this method of domain validation, then indicate where in the CP/CPS it is described, and how your CA meets the requirements in this section of the BRs.
CPS 3.2.2.2	Good - (also, there appears to be a typo in this section)	3.2.2.6 Wildcard Domain Validation If your CA allows certificates with a wildcard character in a CN or subjectAltName of type DNS‐ID, then indicate how your CA meets the requirements in this section of the BRs.
CPS 3.2.2	Could be improved - "DigiCert uses a documented internal process to check the accuracy of information sources and databases to ensure the data is acceptable, including reviewing the database provider’s terms of use."	3.2.2.7 Data Source Accuracy The CA's CP/CPS must explain how the CA determines that a third-party data source is reliable. For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.” (Additional criteria are found in BR § 3.2.2.7) For EV - “A database qualifies as a QIIS if the CA determines that: (1) Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and (2) The database provider updates its data on at least an annual basis.” (EVG § 11.11.5)
CP/CPS 3.2.4	Section 3.2.4 of the CPS says, "Unverified information is never included in a Level 2, Level, 3, Level 4, or Object Signing Certificate." Does this include server certificates and email certificates in the scope of Mozilla's Root Store Policy?	3.2.4 Non-verified subscriber information “All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.” (MRSP § 2.2.1)
CP/CPS 3.2.6	Please indicate how / where cross-certificates are disclosed.	3.2.6. Criteria for Interoperation or Certification Disclose all cross-certificates in the CA hierarchies under evaluation. (See e.g. MRSP § 5.3)
CP/CPS 3.3.1	Where is data re-use limited? It's not in this section or section 4.2.1.	3.3.1 Identification and authentication for routine re‑key For data re-use, see subsection 5 of MRSP § 2.1 and BR § 4.2.1.
CP/CPS 4.2.1	Where is data re-use limited? It's not in this section or section 3.3.1.	4.2.1. Performing Identification and Authentication Functions (MRSP § 2.1.5) Indicate how your CA identifies high risk certificate requests. Re-use of domain / IP address validation is limited to 398 days and re-use of other validation information is limited to 825 days
CP/CPS 5.4.8	OK - this section could be improved with more discussion of vulnerability testing and pentesting and the frequency that these occur	5.4.8. Vulnerability Assessments Indicate how your CA meets the requirements of this section.
CPS 6.1.2	Good - see also CPS section 6.2.5	6.1.2. Private Key Delivery to Subscriber "Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber."
CPS 6.1.6	OK - could be improved by discussing parameter checking	6.1.6. Public Key Parameters Generation and Quality Checking For RSA keys, ensure that public exponent is an odd number equal to 3 or more and in the range between 2^16 + 1 and 2^256 ‐ 1. The modulus should also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. For ECC, use either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine.
CP 6.1.7	Good - this is mentioned in CPS sections 4.3.1 and 6.1.6	6.1.7. Key Usage Purposes Private Keys corresponding to Root Certificates shall only be used for the purposes indicated (and not used to issue end entity certificates). (Mozilla Forbidden Practice)
CP/CPS 6.7	OK - The NCSSRs are mentioned in CPS section 1.1	6.7 Network Security Controls (MRSP § 2.1.2) CAs must follow industry best practices for securing their networks, for example by conforming to the CA/B Forum's Network and Certificate System Security Requirements. See also https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Network_Security_Controls
CP/CPS 7.1.4	OK - Could be improved by adding details about naming consistency with RFC 5280, X.500 and CABF requirements.	7.1.4. Name Forms
CP/CPS 7.1.2	OK - could be improved with specific discussion in CPS section 7.1.4 re: identical byte-for-byte encoding	7.1.4.1 Name Encoding Subject and Issuer Names for all possible certification paths MUST be byte-for-byte identical
CP/CPS 7.1.4	OK - could be improved by rewriting section 7.1.4	7.1.4.2.1 Subject Alternative Name Extension This extension MUST contain at least one entry. Each entry MUST be either a dNSName (FQDN) or an iPAddress of a server. CAs SHALL NOT issue certificates with a SAN or commonName containing a Reserved IP Address or Internal Name. (Also a Mozilla Forbidden Practice) Entries in the dNSName MUST be in the "preferred name syntax", as specified in RFC 5280, and thus MUST NOT contain underscore characters ("_").
CP/CPS 7.1.4	OK - could be improved by rewriting section 7.1.4 (and rephrasing language in CPS section 7.1.2 re: CN must be one of the SANs, and not vice versa)	7.1.4.2.2 Subject Distinguished Name Fields (Common Name) If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension (see Section 7.1.4.2.1).
CP/CPS 7.2 1	OK - could be improved with specific discussion in CPS section 7.2 re: matching names with identical, byte-for-byte encoding	7.2.2 CRL and CRL entry extensions The issuer name for the CRL should match the issuer name in the CA certificate byte-for-byte. See Potentially Problematic Practices.
CPS 8.2/ CP 8.1	Good (CPS is missing numbering for section 8.1)	8.1. Frequency or circumstances of assessment The period during which the CA issues Certificates SHALL be divided into an unbroken sequence of audit periods. An audit period MUST NOT exceed one year in duration. MRSP sections 3.1.3 and 7.1 require CAs to maintain a Complete Audit History from cradle to grave. For new CA Certificates: The point-in-time readiness assessment SHALL be completed no earlier than twelve months prior to issuing Publicly-Trusted Certificates and SHALL be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate. Indicate your CA's understanding of this requirement, and how your CA meets the requirements of this section.
CPS 8.3/ CP 8.2	OK -could be improved with mention of Mozilla's auditor qualification requirements	8.2. Identity/qualifications of assessor Indicate how your CA meets the requirements of this section. (Mozilla has additional requirements - https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications))
CPS 8.5/ CP8.4	OK - (section numbering needs to be fixed)	8.4. Topics covered by assessment (Mozilla has slightly different requirements. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#311-audit-criteria))
CPS 8.7/ CP8.6	OK - Could be improved by reference to CCADB requirements (to meet ALV processing requirements)	[8.6. Communication of results In addition to BR § 8.6, see also https://www.ccadb.org/policy#51-audit-statement-content "The Audit Report must contain certain information formatted in a certain way, including but not limited to: - name of the company being audited; etc.]"
		9. OTHER BUSINESS AND LEGAL MATTERS
CP/CPS 9.5.2	Needs to be fixed - Digicert should acknowledge that the CP and CPS are provided by Mozilla on a Creative-Commons basis.	9.5 Intellectual Property Rights - E.g. “CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)” (MRSP § 3.3.3)
CP/CPS 9.16.3	Should be fixed - The CP/CPS should be improved by saying somewhere that in the event that a CABF requirement is found to be illegal, that DigiCert will notify the CABF in accordance with BR 9.16.3	9.16.3. Severability In the event of a conflicting law, the CA shall include in Section 9.16.3 of the CA’s CPS a detailed reference to the Law requiring a modification of these Requirements and must immediately notify the CA/Browser Forum.
CP/CPS 3.1.1	Should fix - Section 3.1.1 needs to be updated with new cross-references to Appendix B (not C or F)	APPENDIX B - Issuance of Certificates for .onion Domain Names
		For CAs seeking enablement of Email Trust bit
CPS 3.2.3	Good - This is actually stated in the bottom of the table in CPS section 3.2.2.	The CA's CP/CPS MUST explain how the CA verifies email address control (i.e. using a challenge-response mechanism). (MRSP § 2.2.2 and https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response)
CPS 3.2.2	Good - This is in Footnote 2.	CA must validate the domain part of all e-mail addresses (MRSP § 2.2.2) - “For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address.” (This type of delegation is also a Mozilla Forbidden Practice.)
		For CAs seeking enablement of Extended Validation
CPS 9.6.1	Needs to be fixed - The CP/CPS should be improved by saying somewhere that in the event that a CABF requirement is found to be illegal, that DigiCert will notify the CABF in accordance with EVG sec. 8.1 (see also BR 9.16.3)	EVG 8.1 - the CA shall notify the CAB Forum if a provision of the EV Guidelines is illegal under local government laws.
CP/CPS 2.1	Good - This is in CPS section 1.1	EVG 8.3 - the CA shall have a statement that it conforms to the current version of the EV guidelines and that in the event of any inconsistency, the EV guidelines take precedence.
CPS 2.9.1	Good - This is in CPS section 9.2.1	EVG 8.4 - the CA shall maintain liability insurance of US$2 million and professional liability insurance of US$5 million.
CPS 3.2.2	Need to fix - The entry for EV certificates should mention compliance with EVG section 9.2.1 or quote that the O field contains the "Subject’s full legal organization name as listed in the official records of the Incorporating or Registration Agency in the Subject’s Jurisdiction of Incorporation or Registration or as otherwise verified by DigiCert."	EVG 9.2.1 - the organization name must include the full legal name for the subscribing organization as listed in official records.
CPS 3.2.2	Need to fix - The CPS should mention DigiCert verifies the legal existence of the organization and its EV category.	EVG 9.2.3, 11.2.1 and 11.2.2 – The CA must verify the Applicant’s legal existence and identity directly with the incorporating agency or registration agency and the business category field must contain one of the following: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity"
CPS 3.2.2	Need to fix - The CPS should indicate that EV certificates properly reference the jurisdiction of incorporation/registration in accordance with EVG section 9.2.4	EVG 9.2.4 - jurisdiction of incorporation/registration fields must not contain information that is not relevant to the level of the incorporating agency or registration agency.
CPS 3.1.6	Should fix - The CPS should be fixed to state what is put in the subject registration number (or the CPS should contain a certificate profile for EV certificates with an explanation for this field).	EVG 9.2.5 and 11.2.1 - subject registration number: if the jurisdiction of incorporation or registration does not provide a registration number, then the date of incorporation or registration is entered in this field.
CPS 3.2.2	Need to fix - The entry for EV certificates should mention compliance with EVG section 9.2.6 or quote that DigiCert verifies the physical address of the organization and populates the address field with that information	EVG 9.2.6 - subject physical address of place of business must contain the address of the physical location of the business.
CPS 3.1.6	Need to fix - DigiCert needs to describe in its CPS (or in an EV profile in the CPS) how it populates this registration reference field.	EVG 9.2.8, 9.8.2, and Appendix H – if included in the certificate, the CA shall confirm registration references for legal entities.
CPS 3.1.6	Need to fix - Section 9.2.9 of the EVG prohibits any other subject attributes in EV certificates. This needs to be more explicit in the CPS.	EVG 9.2.9 - the CA shall not include any subject attributes except as specified in EVG § 9.2.
CPS 3.2.2 (Wildcard is only listed under DV and its own section below, it is not permitted for EV SSL)	Needs to be fixed - The CPS needs to be more explicit that wildcards are not allowed for EV certificates.	EVG 9.8.1 - wildcard certificates are not allowed.
CPS 3.2.3	Need to fix - The table in CPS section 3.2.3 should reference EVG 11.2.2(4) in addition to EVG 11.2.1(3).	EVG 11.2.2(4) - principal individuals must be validated in a face-to-face setting.
CPS 3.2	Need to fix - CPS section 3.2.5 says that DigiCert uses a "Reliable Method of Communication" for OV certificates. But for communications with the Applicant for an EV certificate, DigiCert must use a "Verified Method of Communication". It is unclear in the CPS how DigiCert does this.	EVG 11.5.1 - the CA must establish of verified method of communication with the applicant.
CPS 9.6.1	Need to fix - The CPS should mention DigiCert verifies the legal existence of the organization and its EV category.	EVG 11.6.1 - the CA must verify that the applicant has the ability to engage in business. The EV issuance process requires that the operational existence be established in one of 4 enumerated ways: “(1) existence for at least three years, ... (2) listed in either a current QIIS or QTIS; (3) Demand Deposit Account ... by receiving authenticated documentation ... directly from a Regulated Financial Institution; or (4) ... a Verified Professional Letter ....”
CPS 3.2.2	Need to fix - The entry for EV certificates in the table in CPS section 3.2.2 should cross-reference the domain validation methods listed in the table for "DV SSL/TLS Server Certificates" similar to what it did in the table entry for IV and OV certificates.	EVG 11.7.1 - domain name verification must use a procedure from BR § 3.2.2.4
CPS 3.2.3	Need to fix - the CPS needs to say that DigiCert verifies the name and title of the contract signer and certificate approver.	EVG 11.8.1 - the CA must verify the name and title of the contract signer and certificate approver
CPS 3.2.3	Need to fix - the CPS needs to say that DigiCert verifies signatures on the subscriber agreement and certificate request	EVG 11.9 - the CA must verify the signature on the subscriber agreement and certificate request
CPS 3.2.2	Should fix - The following sentence could be improved by reference to the criteria listed in BR 3.2.2.7 and EVG 11.11.5 - "DigiCert uses a documented internal process to check the accuracy of information sources and databases to ensure the data is acceptable, including reviewing the database provider’s terms of use."	EVG 11.11.5 - the CA shall use documented processes to check the accuracy of a QIIS.
CPS 4.2.2	Good - this is also covered in CPS section 4.2.1	EVG 11.13, 14.1.3 and 16 - the CA must perform final cross-correlation and other due diligence based on the entire corpus of information and have multi-person, auditable controls to ensure separation of duties with respect to EV certificate issuance
CPS 6.3.2	Should be fixed - Data reuse limits should not appear in CPS section 6.3.2. It appears that there is a cross-reference to section 4.2.1 of the Baseline Requirements (but not to the EV Guidelines) in CPS section 4.1.2 and in footnote 1 (unclear that the reference is to the Baseline Requirements). These data reuse timeframes need to be consolidated in a single place in the CPS.	EVG 11.14.3 - validation data cannot be reused after 397 days
CPS 4.3.1	Good. (This prohibition also appears, by implication, in CPS section 6.1.6)	EVG 12 - root CA private keys must not be used to sign EV certificates.

Ben Wilson

Assignee

Updated

•

4 years ago

Whiteboard: [ca-verifying] → [ca-cps-review] BW 2022-01-28

Ben Wilson

Assignee

Comment 10

•

4 years ago

Is digicert-cps-v5-9.pdf the version that I should review and compare with Comment #9?

Flags: needinfo?(martin.sullivan)

Martin Sullivan

Reporter

Comment 11

•

4 years ago

Attached file DigiCert-CPS-Review-DC-replies-Final.xlsx — Details

Flags: needinfo?(martin.sullivan)

Martin Sullivan

Reporter

Comment 12

•

4 years ago

Please find attached our responses to this feedback.

This has been incorporated into our new CP/CPS found on our repository

https://www.digicert.com/legal-repository

https://www.digicert.com/content/dam/digicert/pdfs/legal/digicert-cp-v5-9.pdf

https://www.digicert.com/content/dam/digicert/pdfs/legal/digicert-cps-v5-9.pdf

Let me know if you have any questions.

Ben Wilson

Assignee

Comment 13

•

4 years ago

I've looked at the amendments to the CP and CPS, and I am satisfied about the changes made. I'll move this into the queue for public discussion.

Ben Wilson

Assignee

Updated

•

4 years ago

Whiteboard: [ca-cps-review] BW 2022-01-28 → [ca-ready-for-discussion 2022-02-25]

Ben Wilson

Assignee

Comment 14

•

4 years ago

Public discussion started on 2022-03-09 - https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/z3-sYPyykqc/m/RTnXIubVAgAJ. Public discussion is scheduled to close on 2022-03-31.

Whiteboard: [ca-ready-for-discussion 2022-02-25] → [ca-in-discussion] 2022-03-09

Ben Wilson

Assignee

Comment 15

•

4 years ago

Public discussion concluded today, 2022-03-31, https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/z3-sYPyykqc/m/Wyq_okkpBQAJ, with a recommendation that Mozilla approve DigiCert's inclusion request.

Flags: needinfo?(kwilson)

Whiteboard: [ca-in-discussion] 2022-03-09 → [ca-pending-approval] 2022-03-31

Kathleen Wilson

Comment 16

•

4 years ago

As per Comment #15, and on behalf of Mozilla I approve this request from DigiCert to include the following root certificates:

** DigiCert SMIME ECC P384 Root G5 (Email)
** DigiCert SMIME RSA4096 Root G5 (Email)
** DigiCert TLS ECC P384 Root G5 (Websites); enable EV
** DigiCert TLS RSA4096 Root G5 (Websites); enable EV

I will file the NSS and PSM bugs for the approved changes.

Flags: needinfo?(kwilson)

Whiteboard: [ca-pending-approval] 2022-03-31 → [ca-approved] - pending NSS and PSM code changes

Kathleen Wilson

Updated

•

4 years ago

Depends on: 1764210

Kathleen Wilson

Updated

•

4 years ago

Depends on: 1764392

Kathleen Wilson

Updated

•

4 years ago

Depends on: 1764397

Kathleen Wilson

Comment 17

•

4 years ago

I have filed bug #1764392 against NSS and bug #1764397 against PSM for the actual changes.

Kathleen Wilson

Updated

•

4 years ago

Whiteboard: [ca-approved] - pending NSS and PSM code changes → [ca-approved] - In NSS 3.80, FF 103, Pending PSM changes for EV

Kathleen Wilson

Updated

•

4 years ago

Status: ASSIGNED → RESOLVED

Closed: 4 years ago

Resolution: --- → FIXED

Whiteboard: [ca-approved] - In NSS 3.80, FF 103, Pending PSM changes for EV → [ca-approved] - In NSS 3.80, FF 103, and EV enabled in FF 104

Nobody; OK to take it and work on it

Updated

•

3 years ago

Product: NSS → CA Program

DigiCert Key Gen Indp Acct Opinion and Mgmt Assertion Jan 2021 FINAL.pdf 5 years ago Martin Sullivan 283.78 KB, application/pdf		Details
DigiCert CA Compliance Self Assessment_final.xlsx 4 years ago Martin Sullivan 47.36 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet		Details
ECC_testcert.cer 4 years ago Martin Sullivan 1.29 KB, application/x-x509-ca-cert		Details
RSA_testcert.cer 4 years ago Martin Sullivan 2.13 KB, application/x-x509-ca-cert		Details
DigiCert-CPS-Review.xlsx 4 years ago Ben Wilson 50.68 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet		Details
DigiCert-CPS-Review-DC-replies-Final.xlsx 4 years ago Martin Sullivan 55.46 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet		Details