Bugzilla

Reporter

Comment 4

•

3 years ago

Hallo Ben, please find the requested information here:

Overview of the test websites of D-TRUST EV Root CA 1 2020
Valid: https://certdemo-ev-valid.tls.d-trust.net/
Revoked: https://certdemo-ev-revoked.tls.d-trust.net/
Expired: https://certdemo-ev-expired.tls.d-trust.net/

The results of the self assessment will follow after the updated CP, CPS and TSPS are published.

Flags: needinfo?(enrico.entschew)

Reporter

Comment 5

•

3 years ago

Attached file PKI-Structure_EV_Root-Inclusion.pdf — Details

Please find here the CA hierarchy including Root CA and Sub CAs.

Assignee

Updated

•

3 years ago

Flags: needinfo?(bwilson)

Assignee

Comment 6

•

3 years ago

Just waiting on the BR Self Assessment, and then this request can be moved to the CP/CPS review phase.

Flags: needinfo?(bwilson)

Reporter

Comment 7

•

3 years ago

Attached file D-TRUST_BR_Self_Assessment_D-TRUST_EV_Root_CA_1_2020_final.xlsx — Details

Please find attached the BR self-disclosure of the D-TRUST EV Root CA 1 2020.

Assignee

Updated

•

3 years ago

Whiteboard: [ca-verifying] → [ca-cps-review] BW 2021-08-06

Assignee

Comment 8

•

3 years ago

Attached file Mozilla Review of D-TRUST Compliance Self-Assessment — Details

Assignee

Comment 9

•

3 years ago

Root Program Review	How CA's CPS meets BR/MRSP requirements	BR/RFC 3647/EVG or MRSP Section
The CSM CPS and the Root CPS contain references to a "Section 0," which does not exist. The cross-references in the source document need to be updated and the PDFs regenerated.		General Comments

		Baseline Requirements for TLS Server Certificates
		1 INTRODUCTION
Good - Section 1.5.3 of CSM CPS	Section 1.5.3 of CSM CPS	1.1 Overview Statement of adherence to BRs and their precedence (MRSP § 2.3) (BR § 2.2) “The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and CA/Browser Forum Requirements, those Requirements take precedence.”
Good - Section 1.1.2 of the CPSes contains a chart that shows the hierarchical relationship among the policy and practice documents. Also, Figure 1 (section 1.1.3) of the CSM CPS shows the CAs covered by the CPS.		1.3.1 Certification Authorities “CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.” MRSP § 3.3.6
OK (but could be more explicit) - In section 4.2.1 of the TSPS, D-TRUST states, "Domain Control of a domain is verified solely by the TSP itself and is evidenced as follows:" The practices documentation should explicitly say that delegation or outsourcing of domain validation to any other third party (e.g. an external RA) is prohibited.	TSPS 1.3.2 - The RA identifies and authenticates subscribers or end-entities (subjects), and it collects and checks requests for different certification services. The concrete tasks and obligations of the RA as the representative of the TSP and/or CA are defined and finally set forth in the respective agreement with the RA. The RA is unambiguously identified by the TSP in this context. Registration authorities that are not operated by D TRUST are subject to the same requirements.	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).
		3. IDENTIFICATION AND AUTHENTICATION
Could be improved		3.1 Naming Also, the CA should describe its practices for handling Internationalized Domain Names (IDNs) in its CP/CPS.
OK - "Subscriber identification and application validation are subject to the requirements of [EN 319 411-1] and depending on the application, LCP, EVCP EVCP or OVCP, or the requirements of [EN 319 411-1] and [EN 319 411-2] for QCP-w or QCP-l." TSPS 4.2.1 - The customer must be identified before the certification and trust services of D-Trust GmbH can be used. The registration process and an identification method permitted for the selected product must be completed and all the required evidence must be furnished." Sections 3.1.4 of the CSM CPS and in the Root CPS reference "Postal address and Street and Number - EVCP: According to section 9.2.6 [EVGL]" But is unclear if this is done for OV certificates with street address.	CSM CPS 3.1.4 and 3.2.2, TSPS 4.2.1, and Root CPS 3.1.4 - Organizations which are either named in the certificate or in whose names certificates are issued must provide unambiguous proof of their identity. If the application is submitted on behalf of a legal entity, the representative must (in analogy to the procedure for proving affiliation with the organization according to section 3.2.3) prove his or her authorization to this effect and also furnish proof of his or her identity. The CA verifies all subject information to be included in certificates accordingly to CPS section 3.2.2. The reference to the BRs is indirectly given by the ETSI standards (EN 319 411-1; REG-6.2.2-03).	3.2.2.1 Identity If the Subject Identity Information in certificates is to include the name or address of an organization, indicate how your CP/CPS meets the requirements in this section of the BRs.
OK QCP-w, EVCP, OVCP - "The TSP takes the steps needed to ensure that, at the time of certificate issuance, the applicant has the proven right to use the brand name included in the certificate. The requirements of section 3.2.2.2 [BRG] and, if applicable, section 11.3 [EVGL] are complied with." (Section 9.5 of the CP should refer to "Intellectual Property" instead of "Industrial property")	CP 9.5 CSM CPS 3.1.6 and 3.2.2 Root CPS 3.1.6 and 3.2.2 The CA verifies the DBA or tradename with a reliable source. The CA verifies the identity and legal existence of an organization by checking with an applicable, official or reliable private register. For government entities, proof of existence by law or official seal can be accepted as well. The subscriber is liable for compliance with intellectual property rights in the application and certificate data (see CP section 9.5). The reference to the BRs is indirectly given by the ETSI standards (EN 319 411-1; REG-6.2.2-03).	3.2.2.2 DBA/Tradename If the Subject Identity Information in certificates is to include a DBA or tradename, indicate how your CP/CPS meets the requirements in this section of the BRs.
OK	TSPS 4.2.1 - D-TRUST uses one the following methods to validate domains: 3.2.2.4.2, 3.2.2.4.4, 3.2.2.4.7, 3.2.2.4.13, 3.2.2.4.14, 3.2.2.4.18 The reference to the BRs is indirectly given by the ETSI standards (EN 319 411-1; REG-6.2.2-03).	3.2.2.4 Validation of Domain Authorization or Control Indicate which of the methods of domain validation your CA uses, and where this is described in your CP/CPS. MRSP § 2.2 states: "The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with." See also MRSP § 3.3.1.
Good	D-TRUST does not support this method. The reference to the BRs is indirectly given by the ETSI standards (EN 319 411-1; REG-6.2.2-03).	3.2.2.4.1 Validating the Applicant as a Domain Contact This method SHALL NOT be used.
Need to fix - This reference to Top-Level-Domains does not make sense. Section 3.1.4 of the Root CPS and the CSM CPS say that for QCP-w, EVCP: "Wildcards are not permitted for TLS certificates." However, it is unclear whether wildcards are allowed at all for any type of certificate, and if so, how the process complies with the Baseline Requirements.	TSPS 4.2.1 -> Domain D-TRUST forbids the issuance of certificates for Top-Level-Domains. The reference to the BRs is indirectly given by the ETSI standards (EN 319 411-1; REG-6.2.2-03).	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.
OK - Section 3.2 of the Root CPS and the CSM CPS states, "A procedure is established which ensures that the data sources for the validation of certificate content are checked and released in accordance with section 3.2.2.7 [BRG]."	CSM CPS and Root CPS 3.2, 3.2.2, 3.2.3 - A procedure is established which ensures that the data sources for the validation of certificate content are checked and released in accordance with section 3.2.2.7 [BRG]. All data sources are approved by the D-TRUST organizational unit for information security. The reference to the BRs is indirectly given by the ETSI standards (EN 319 411-1; REG-6.2.2-03).	3.2.2.7 Data Source Accuracy Indicate how your CA meets the requirements in this section of the BRs.
		4. CERTIFICATE LIFE‑CYCLE OPERATIONAL REQUIREMENTS
Good - "Domain names not subject to a registration obligation, domains of the top-level domain ".int" as well as top-level domains in general and onion certificates are not permitted."	TSPS 4.2.1 -> Domain - Domain names not subject to a registration obligation are not permitted.	4.2.2. Approval or Rejection of Certificate Applications "CAs SHALL NOT issue certificates containing Internal Names."
Good - EVCP, QCP-w, OVCP, DVCP - "When issuing TLS certificates, D-Trust GmbH uses Certificate Transparency (CT) according to RFC 6962. Some browsers require publication of all TLS certificates issued by the CA in at least three auditable logs of external providers. This only applies if the product is offered with CT logging and this option was selected in the order process. For TLS certificates, pre-issuance linting is carried out."	CPS 4.3.1, TSPS 5.2, TSPS 6.1.1 - The corresponding certificates are produced in the high-security area of the trust service provider. Every certificate or signature procedure by the Root CA are authorized by CA responsible roles (see Role concept TSPS 5.2)	4.3.1. CA Actions during Certificate Issuance Pre-issuance linting (Recommended Practices) “It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences”
OK - See above.		4.3.1. CA Actions during Certificate Issuance It is presumed that for each precertificate a corresponding certificate exists. See Required or Recommended Practices. Therefore, CAs must have the means to provide OCSP and revoke the serial number for any precertificate.
Please fix - the CPS should address this Mozilla requirement with more specific language concerning RA operators (or others) who cause the issuance of end-entity certificates	TSPS 5.2.2 - Security-critical systems used for certificate issuance are generally protected by multi-factor authentication.	4.3.1. CA Actions during Certificate Issuance CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”. (MRSP § 2.1.3)
		4.3.1 CA Actions during Certificate Issuance The backdating of a certificate's notBefore date to avoid a deadline, prohibition, or code-enforced restriction is a Problematic Practice.
OK - "EVCP, OVCP, DVCP -The deadlines set out in section 4.9 of [BRG] are complied with. A certificate of a subscriber or of an issuing CA is revoked if at least one of the revocation reasons from section 4.9 of [BRG] applies."	TSPS 4.9.1, TSPS 4.9.3, TSPS 4.9.5 - The reasons and time frame for revoking a subscriber certificate according to BR section 4.9.1.1 are fully supported. Certificates can be generally revoked 24/7 by subscribers and/or their authorized representatives using the agreed online interface. Revocation at a future point in time is not offered. Revocation via the online interface becomes effective immediately.	4.9.1.1 Reasons for Revoking a Subscriber Certificate Indicate how your CA's CP/CPS lists the reasons for revoking end entity certificates and is consistent with the timeframes required by this section of the BRs.
OK - See above.	TSPS 4.9.1 - The reasons and time frame for revoking an issuing CA certificate according to BR section 4.9.1.2 are fully supported. A certificate of an issuing CA is revoked if at least one of the revocation reasons from section 4.9 of [BRG] applies. Note: D-TRUST's PKI hierarchy has three levels: root CA, issuing CA and EE certificates (see CPS 1.1.3).	4.9.1.2 Reasons for Revoking a Subordinate CA Certificate Indicate how your CA's CP/CPS lists the reasons for revoking subordinate CA certificates and is consistent with the timeframes required by this section of the BRs.
OK - "Revocation requests can be submitted 24/7 via the online interface. Revocation takes place according to section 4.9 of [BRG]."	CP 1.5.2 and CSM CPS 4.9.5 - In the case of TLS certificates, the following website is available: https://www.bundesdruckerei.de/en/Service-Support/Support/Reporting-a-certificate-problem D-TRUST complies with BR section 4.9.5.	4.9.5. Time within which CA Must Process the Revocation Request The CA shall investigate and preliminarily respond to the Subscriber and the person filing a Certificate Problem Report within 24 hours. In any case requiring revocation, the timeframe from notice to revocation shall not exceed that stated in BR § 4.9.1.1.
Good - "The difference between the nextUpdate field and the thisUpdate field does not exceed ten days."	CSM CPS 2.3 and Root CPS 2.3 and TSPS 7.2.1 - Certificate revocation lists are issued regularly and until the end of validity of the issuing CA certificate. Certificate revocation lists are issued and published immediately following certificate revocation. Even if no certificates were revoked, the TSP ensures that a new certificate revocation list is created every 12 hours. The certificate revocation lists are retained and kept for a minimum period of one year following expiration of the validity of the CA. CA revocation lists that are issued by root CAs are issued and published at least every 12 months even if no certificates were revoked.	4.9.7. CRL Issuance Frequency Indicate if your CA publishes CRLs. If yes, then please test your CA's CRLs. CRLs must be issued at least every 7 days w/ nextUpdate of not more than 10 days (MRSP § 6)
Good - QCP-w, EVCP, OVCP, DVCP, LCP - "The “nextUpdate” field is set. The difference between the nextUpdate field and the thisUpdate field does not exceed 24 hours."	CPS 4.9.9 in combination with TSPS 7.3.1 - 'An OCSP service is available for online verification. The availability of this service is indicated in the certificates in the form of a URL. OCSP v1 according to [RFC 6960] is used.	4.9.9. On-line Revocation/Status Checking Availability
		5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS
Good - "The identity, reliability and professional qualifications of employees are verified before they commence work."	TSPS 5.3, 5.3.1 - Regarding the qualification and clearance requirements of the TSP’s employees, all personnel in trusted roles and RA officers are free from any interests that may affect their impartiality regarding the TSP’s operations.	5.3.1. Qualifications, Experience, and Clearance Requirements The CA shall verify the identity and trustworthiness of persons involved in certificate management processes.
OK - "The subscriber may only submit a certificate request with a new self-generated key pair." Although the wording in this section could be improved to more clearly state that in the case of EE server certificates, the CA/TSP shall/does not generate key pairs for the subscriber.	CSM and Root CPS 6.1.1 - This section of the CPS fulfils all requirements of the BR section 6.1.1.3.	6.1.1.3 Subscriber Key Pair Generation - the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA.
Good - "The CA keys are protected by an HSM that was evaluated according to FIPS 140-2 Level 3 OR according to Common Criteria (pursuant to Protection Profile EN 419 211-5)."	TSPS 6.2 - The TSP has implemented different physical security perimeters in order to ensure the security of the certification systems. The TSP is certified against the Trusted Site Infrastructure requirements for data centre. D-TRUST complies with BR section 6.2.	6.2. Private Key Protection and Cryptographic Module Engineering Controls Protections must implemented in a manner that prevents disclosure of the Private Key.
Good	TSPS 6.2.5 - Private CA and EE keys are not archived.	6.2.5. Private Key Archival Subordinate CA private keys shall not be archived by third parties.
Good (but note that TSPS 6.2.6 also says, "The specific rules are documented in the respective CPS." And then the CPS says, "These rules are documented in the TSPS." So that additiional language in TSPS 6.2.6 should probably be removed.)	TSPS 4.9.1 and 6.2.6 - Transfers of private CA keys to or from the HSM are limited to backup and recovery purposes. Adherence to the 4-eyes principle is compulsory. Private CA keys exported to/imported from another HSM are protected by encryption.	6.2.6. Private Key Transfer into or from a Cryptographic Module If the Issuing CA generated the Private Key on behalf of the Subordinate CA, then the Issuing CA SHALL encrypt the Private Key for transport to the Subordinate CA.
OK - but CSM CPS section 6.3.2 says "QCP-w with PSD2 extension - Qualified website certificates with PSD2 extension are issued with the following validity period: 825 days max." Is that correct?	CPS 6.3.2 - D-TRUST complies with BR section 6.3.2.	6.3.2 Certificates issued SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. Indicate how your CA meets the requirements of this section.
Same comment as above - CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”. (MRSP § 2.1.3)	TSPS 5.2.2 - Security-critical systems used for certificate issuance are generally protected by multi-factor authentication.	6.5.1. Specific Computer Security Technical Requirements The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance. Indicate how your CA meets the requirements of this section.
		7. CERTIFICATE, CRL, AND OCSP PROFILES
OK - Table indicates only "keyCertSign" and "cRLSign"	TSPS 7.1.2	7.1.2.1.b Key Usage If the Root CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set.
OK - FWIW - Table indicates only "keyCertSign" and "cRLSign"	TSPS 7.1.2	7.1.2.2.e Key Usage If the CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set.
OK - But this is not specified. Please fix in TSPS 7.1.2 to reference Intermediate/Issuing CAs created after January 1, 2019 -		7.1.2.2.g Subordinate CA Certificate - Separate, EKU-constrained issuing CAs (MRSP § 5.3) Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU. Also, it is important to distinguish CAs using the appropriate serverAuth or emailProtection EKU. (See Required or Recommended Practices)
Good - QCP-w, EVCP, OVCP, DVCP: only “id-kp-serverAuth” and “id-kpclientAuth” are allowed	TSPS 7.1.2	7.1.2.3.f For TLS server certificates, either the value id-kp-serverAuth or id-kp-clientAuth or both values MUST be present. id-kp-emailProtection MAY be present. Other values SHOULD NOT be present. The value anyExtendedKeyUsage MUST NOT be present. (MRSP § 5.2)
Good - "SHA1 is not used."	CPS 7.1.3 and TSPS 7.1.3 - D-TRUST complies with BR section 7.1.3.2.	7.1.3.2 Signature AlgorithmIdentifier SHA-1 is prohibited (except in a very narrow exception case). (BR § 7.1.3.2.1) (MRSP § 5.1.3) (Also a Mozilla Forbidden Practice)
OK	CPS 3.1.4, TSPS 4.2.1, 7.1.4 - D-TRUST complies with BR section 7.1.4.2.1.	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 ("_").
Good - "EVCP, OVCP, DVCP For revoked CA certificates, D-TRUST states the reason for revocation in the reasonCode entry in the CRL."	TSPS 7.2 - D-TRUST complies with BR section 7.2 and 7.3.	7.2 and 7.3 - All OCSP and CRL responses for Subordinate CA Certificates MUST include a meaningful reason code.
Please fix - an external, public-facing document (TSPS or CPS) should commit D-TRUST to the performance of self-audits for three percent of certificates issued (and not simply refer to "internal documentation").	Internal documentation - The computers, networks and other components used for the TSP are quarterly checked, inspected and audited by an internal organization unit. The CA established a method to monitor CP, TSPS, CPS, BR and ongoing discussions. Technical quality checks in our production system ensures compliance to the requirements. Furthermore a "Linting-Tool" is implemented in certificate production systems. So we can ensure the quality of each issued certificate automatically. In addition, we follow the discussions on the MDSP and bugzilla.	8.7. Self-Audits CAs must perform "self audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued."
		For CAs seeking enablement of Email Trust bit
Should address for email trust bit		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)
Should address for email trust bit		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.)
Good	TSPS 4.9.1 "Certificates that are capable of signing or encrypting e-mails and contain an e-mail address are also subject to the revocation reasons listed in Mozilla Root Store Policy 2.7, Chapter 6.2."	SMIME Reasons for Revocation (MRSP § 6.2) “For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events …” (including "5. the CA receives notice or otherwise becomes aware of any circumstance indicating that use of the email address in the certificate is no longer legally permitted").
		For CAs seeking enablement of Extended Validation
Good	TSPS 8 - "In the event of any discrepancies with a view to applicable national law, [BRG] and [EVGL], D-TRUST will inform the CA/Browser Forum of such fact, the circumstances and the applicable national law."	EVG 8.1 - the CA shall notify the CAB Forum if a provision of the EV Guidelines is illegal under local government laws.
OK - but chart does not say that only the relevant levels of the incorporating/registering jurisdiction are filled in the certificate, as necessary.	CSM CPS 3.1.4 (jurisdictionLocalityName) (jurisdictionStateOrProvinceName) (jurisdictionCountryName) "QCP-w4, EVCP - TLS certificates contain at least the subject-DN components: “organizationName”,“commonName”, “serialNumber”, “jurisdictionCountryName” …"	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.
OK - (However, the TSPS lacks mention of an "examination" required by BR 5.3.3.)	TSPS 5.3.1, 5.3.4 - "The TSP ensures that persons employed in the area of the certification service have the knowledge, experience and skills necessary for this activity. This includes, among others, the requirements of [BRG] and [EVGL]." "The TSP trains certification service personnel at the beginning of their employment, annually and as required."	EVG 14.1.2 – the internal examination of specialists must include the EV certificate validation criteria of the EV guidelines.

Reporter

Comment 10

•

3 years ago

Dear Ben,
Thank you for the thorough analysis of our policy documents and the review of the BR self-assessment. Over the last weeks, we have discussed your comments internally and added a more detailed description of our processes in the policy documents. We have recently published them. We have also added some references and comments in column E of the Excel sheet.
The updated documents can be found in the D-Trust’s Repository: https://www.bundesdruckerei.de/en/Repository

TSPS, Version 1.3: https://www.d-trust.net/internet/files/D-TRUST_TSPS.pdf
CSM CPS, Version 3.4: https://www.d-trust.net/internet/files/D-TRUST_CSM_PKI_CPS.pdf
Root CPS, Version 3.5: https://www.d-trust.net/internet/files/D-TRUST_Root_PKI_CPS.pdf

Date of release: 14.10.2021
Effective date: 15.10.2021

Thanks,
Enrico

Reporter

Comment 11

•

3 years ago

Attached file D-TRUST_BR_Self_Assessment_D-TRUST_Mozilla_Review-D-TRUST-Response_Final.xlsx — Details

Updated BR Self Assessment

Assignee

Comment 12

•

3 years ago

Review of TSPS, v.1.3 dated 2021-10-15

Root Program Review BR/RFC 3647/EVG or MRSP Section

Baseline Requirements for TLS Server Certificates

1 INTRODUCTION

Fixed - TSPS 1.3.2 - "RA operator activities, both internal and external, take place on security-critical systems used for certificate issuance and are protected by enforced multi-factor authentication (see also section 5.2.2). TLS certificate requests are processed exclusively by D Trust’s internal RA. Domain validation is therefore carried out exclusively by D Trust itself and is generally neither delegated nor outsourced to third parties (e.g. to an external RA). The domain check within the scope of the e mail verification method in section 4.2.1 for S/MIME certificates is also carried out exclusively by D Trust itself." 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).

3. IDENTIFICATION AND AUTHENTICATION

Fixed - 4.2.1 - "In order to prevent attacks, such as the "homographic spoofing of IDNs", D-Trust has IDNs individually checked by validation specialists. The release is carried out according to the four-eyes principle. If there are any concerns, the issuance of certificates will be refused." 3.1 Naming Also, the CA should describe its practices for handling Internationalized Domain Names (IDNs) in its CP/CPS.

Fixed - TSPS 4.2.1 - "OVCP, DVCP The domain validation methods mentioned are also suitable for validating Wildcard Domain Names. In addition, the requested domain will be checked against a “public suffix list” to prevent the issuance of a wildcard certificate for a registerable portion of a Country Code Top-Level Domain Namespace. Method 3.2.2.4.18 used for domain validation of wildcard TLS certificates will be discontinued by 30 November 2021 at the latest. QCP-w, EVCP No wildcard TLS certificates are issued for this policy level. QCP-w, EVCP" 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.

4. CERTIFICATE LIFE‑CYCLE OPERATIONAL REQUIREMENTS

Good - TSPS 1.3.2: RA operator activities, both internal and external, take place on security-critical systems used for certificate issuance and are protected by enforced multi-factor authentication (see also section 5.2.2). TSPS 5.2.2 - Security-critical systems used for certificate issuance are generally protected by multi-factor authentication. See next below. 4.3.1. CA Actions during Certificate Issuance CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”. (MRSP § 2.1.3)

5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS

Good - TSPS 5.2.2 - "When validating subject data (especially TLS certificates), it is ensured that an experienced validation specialist is called upon and works according to the four-eyes principle." See previous above. 6.5.1. Specific Computer Security Technical Requirements The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance. Indicate how your CA meets the requirements of this section.

7. CERTIFICATE, CRL, AND OCSP PROFILES

Fixed - TSPS 7.1.2 - "QCP-w, EVCP, OVCP, DVCP: For sub-CA certificates, the extension "extKeyUsage" is used according to the subordinate EE certificate profiles. The anyExtendedKeyUsage KeyPurposeId is generally not used." - 7.1.2.2.g Subordinate CA Certificate - Separate, EKU-constrained issuing CAs (MRSP § 5.3) Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU. Also, it is important to distinguish CAs using the appropriate serverAuth or emailProtection EKU. (See Required or Recommended Practices)

Fixed - 8 - "Every quarter, within the framework of "self audits", randomly selected samples of at least three percent of the certificates (but at least one certificate) issued by D-Trust during such period in accordance with the requirements of the [BRG] and [EVGL] are audited and documented internally for quality assurance purposes." 8.7. Self-Audits CAs must perform "self audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued."

For CAs seeking enablement of Email Trust bit

Fixed - TSPS 4.2.1 QCP-w, EVCP, OVCP, LCP - It must be possible to unambiguously assign the domain used in a registered e-mail address to the registered organization. Control over the domain must have been proven. In this case, the domain is validated exclusively by the TSP itself using the domain validation methods according to the Baseline Requirements and the methods required or recommended by Mozilla and supported by D-Trust. If this is not the case, the TSP sends an e-mail to the e-mail address to be confirmed, and receipt of this e-mail must be confirmed (challenge-response/ exchange of secrets). The results of the enquiry are filed. 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)

Fixed - see above 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

Good - TSPS 5.3.3 - The aim is for each staff member to be thoroughly familiar with the verification tasks and for all staff members to implement the instructions in the same manner in order to detect and prevent common threats to the information verification process (including phishing and other social engineering tactics). Training covers the requirements from the company’s own certification practices as well as external applicable requirements (e.g. BRG, ETSI, BSI)." EVG 14.1.2 – the internal examination of specialists must include the EV certificate validation criteria of the EV guidelines.

Assignee

Updated

•

3 years ago

Whiteboard: [ca-cps-review] BW 2021-08-06 → [ca-ready-for-discussion 2021-10-20]

Assignee

Comment 13

•

3 years ago

Public discussion started today with a scheduled close of 28-Jan-2022: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0Ljc_EkPsiQ/m/9XLIROdXBAAJ

Assignee

Updated

•

3 years ago

Whiteboard: [ca-ready-for-discussion 2021-10-20] → [ca-in-discussion] 2022-01-06

Assignee

Comment 14

•

3 years ago

Public discussion closed without comment and with my recommendation that we include this root CA certificate in NSS with the websites trust bit and EV enabled. See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0Ljc_EkPsiQ/m/34f608EgAgAJ

Flags: needinfo?(kwilson)

Assignee

Updated

•

3 years ago

Whiteboard: [ca-in-discussion] 2022-01-06 → [ca-pending-approval] 2022-01-31

Comment 15

•

3 years ago

As per Comment #14, and on behalf of Mozilla I approve this request from D-TRUST to include the following root certificate:

** D-TRUST EV Root CA 1 2020 (Websites); enable EV

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

Flags: needinfo?(kwilson)

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

Updated

•

3 years ago

Depends on: 1754890

Updated

•

3 years ago

Depends on: 1754896

Comment 16

•

3 years ago

I have filed bug #1754890 against NSS and bug #1754896 against PSM for the actual changes.

Updated

•

3 years ago

Whiteboard: [ca-approved] - pending NSS and PSM code changes → [ca-approved] - in Firefox 100, NSS 3.77; pending EV in PSM