Closed Bug 1627552 Opened 1 year ago Closed 2 months ago

Add e-commerce monitoring's GLOBALTRUST 2020 root certificate

Categories

(NSS :: CA Certificate Root Program, task, P1)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ca, Assigned: bwilson)

References

Details

(Whiteboard: [ca-approved] - In NSS 3.66, FF 90; EV enabled in FF 90)

Attachments

(8 files, 4 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0

Attached file Full Audit Report 2020
Attached file GLOBALTRUST Certificate Policy V 2.0g (obsolete) —

Thank you for creating a Root Inclusion Case and filing this bug to request inclusion of the GLOBALTRUST 2020 root certificate.

I have not worked on Information Verification for root inclusion requests since mid December, but I hope that I will be able to begin that work again soon. It will take me a while to catch up.

Status: UNCONFIRMED → ASSIGNED
Type: enhancement → task
Ever confirmed: true
Whiteboard: [ca-verifying]

Among other things, I need to confirm that the Applicant is "e-commerce monitoring GmbH" and not "Austrian Society for Data Protection (Arge Daten)". The applicant needs to clarify this, and then the CCADB record will need to be updated accordingly. The addresses for the two organizations are different, too. The GlobalTrust website indicates the address is Büroadresse: 1020 Wien, Handelskai 388 Top 621 (Eingang Wehlistraße 299).

Flags: needinfo?(ca)
Whiteboard: [ca-verifying] → [ca-verifying] BW 2020-07-31

Dear Ben,

As i wrote more detailly via email, I confirm e-commerce monitoring GmbH is the root owner.

Both of these lergal entities have the same registered headquarter, "Handelskai 388 Top 621 (Eingang Wehlistraße 299)." is just a "store" of e-commerce monitoring gmbh.

I hope I copuld contribute to clarification and I am looking forward to the detailed CP/CPS review phase.

Best Regards,
Daniel

Flags: needinfo?(ca)
Flags: needinfo?(bwilson)
Assignee: kwilson → bwilson
Flags: needinfo?(bwilson)
Whiteboard: [ca-verifying] BW 2020-07-31 → [ca-cps-review] - BW 2020-10-22

Review of GLOBALTRUST CP and CPS v. 2.0g dated April 3, 2020

http://service.globaltrust.eu/static/globaltrust-certificate-policy.pdf

http://service.globaltrust.eu/static/globaltrust-certificate-practice-statement.pdf

Mozilla Root Store and Baseline Requirements

CP/CPS structured in accordance with RFC 3647 with no blank sections (MRSP § 3.3.5) (BR § 2.2)

       Good - OK

CP/CPS made available under a Creative Commons License (MRSP § 3.3.3)

"CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)"

       Meh - The title page to the CPS says, "The document is subject to copyright and is only made available in the context of certification services. An additional application, full or partial transmission to a third party or the publication of the document by a third party requires the prior consent of the author(s) and the CA."

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 those Requirements, those Requirements take precedence."

       Meh – CP Section 8 states that in the event of any inconsistency with the CP/CPS "d) in all other cases, the requirements of the conformity documents have priority."

Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.)

Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU.

       Good – CP Section 1 states, "X509v3 Extended Key Usage: mandatory at least one entry, e.g. TLS Web Server Authentication and/or TLS Web Client Authentication AnyExtendedKeyUsage is not used." It also states, "CA-certificates (with the exception of root certifcates), created on or after 1st January 2019, contain a least one X509v3 Extended Key Usage entry that indicates the permitted EKU-entries in end user certificates. The anyExtendedKeyUsage must not be used. Id-kp-serverAuth and id-kp-emailProtection must not be combined in the same CA-certificate."

Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6)

"CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates."

       Good – CPS section 1.2 specifically mentions the root CA being requested for inclusion – GLOBALTRUST 2020.

Explicit annual revision of CP/CPS w/ table of changes (MRSP § 3.3.4) (BR § 2.3)

"CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document." Also, a version history table provides evidence of compliance and good change management practices.

       Good –Sections 1.2 in the CP and CPS contain "History of changes".

       Meh – Regarding the CP and CPS, section 9.12.1 of the CP says, "The review take place at least once a year." However, it does not say that the documents are reversioned and re-dated every year even if there are no changes. However, the history of changes indicates that this has happened over the last three years (since 2017).

Statement of Non-Delegation for Domain Validation (BR § 1.3.2)

"With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2."

       OK – Section 5.3.7 of the CP states, " Domain validation, including validation of the domain portain [sic] of an eMail address, and the authentication for an IP address are in any case conducted by the operator itself and may not be transferred to a contractor."

Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3)

"The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS."

       Good – Sections 1.5.2 of the CP and CPS state, "Requests for revocation should be sent as soon as possible via https://www.globaltrust.eu/revocation.html. Alternatively, revocations can also be requested by email to revocation@globaltrust.eu or by phone. In any case, sufficient revocation authorization must be demonstrated, for example through online authentication."

Naming compliant with X.500, RFC5280, BRs and EVGs

The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards.

       Meh – Section 3.1, 3.1.4, or 7.1.4 doesn't expressly acknowledge the importance of following X.500, RFC 5280, the Baseline Requirements and the EV Guidelines for naming.

No internal names or reserved IP addresses (BR § 7.1.4.2.1)

"CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name."

       Good – CP section 7.1.2 states, "The commonName or subjectAltName extension field of a server certificate never contains an IP adress that the IANA has marked as reserved, or a Domain name that can not be seen as globallly unique because it does not end with a Top Level Domain that has been registered with the IANA Root Zone Database."

ALL certificates must meet Mozilla/BR validation requirements

CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1) CP/CPS must be sufficient "for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests". [Note: It is also recommended that CAs ensure that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]

       Good - Section 4.2 of the CPS describes that domain name validation is performed solely according to method described in section 3.2.2.4.4 of the Baseline Requirements. For IP Address validation, the CA will use one of the methods found in sections 3.2.2.5.1, 3.2.2.5.2, or 3.2.2.5.3 of the Baseline Requirements.

CA validates 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."

       Good – CP section 4.2 says that if the "certificate can be used to sign emails, all email addresses entered in the certificate will be checked as to whether the applicant has control of these addresses or is authorised to use them by their owner. This can take place through sending a randomly generated 18-digit value to these addresses and obtaining a confirming response of the applicant, containing the value." Also, Section 5.3.7 of the CP states, " Domain validation, including validation of the domain portain [sic] of an eMail address, and the authentication for an IP address are in any case conducted by the operator itself and may not be transferred to a contractor."

Data sources need to be accurate (BR § 3.2.2.7 and EVG § 11.11.5)

For OV – "[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification."

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."

       Needs to be fixed – Among other mentions of reliable data sources in the CP and CPS, are the following: CPS section 3.2.5 states, "at least one agency should be named as a suitable source of information on the organisation (eg. a chamber the organisation belongs to, commercial register, an authority in charge of associations...). If the organisations are established according to the law, the legal provisions providing for their establishment should be named in place of an information source." And section 4.2 of the CPS states, " Qualified, authoritative sources of information can be called upon to verify information on the organisation, in particular, the official telephone book or official directory." Also, CP section 4.2 refers to "Examination of the organisation and trademarks used by the organisation (according to credible certificates submitted by the applicant, as per disclosure (inc. requests to databases) from a qualified official source of information or with the assistance of a qualified independent source of information, especially the databases of trustworthy third parties)".

       However, neither the CP or the CPS explains how the CA establishes that the sources are inherently more reliable than other data sources. The CA needs to disclose the criteria or process used to designate a "reliable data source" and a QIIS, which are two different kinds of sources – one for OV and the other for EV.

       Also, EVG Sections 9.2.4, 9.2.5, and 11.1.3 require the publication of e-commerce monitoring's verification sources, incorporating agencies, and registration agencies (e.g. QIISes, QGISes, QGTISes). Information about where this information can be located must appear in section 3.2 of the CPS.

All information in a certificate must be verified (MRSP § 2.2.1)

"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."

       OK – Sections 3.2.4 of the CP and CPS sufficiently acknowledge that "non-verified" information should not be included in certificates.

Data reuse (certificate renewal) limited to 825 days (MRSP § 2.1.5) (BR § 4.2.1)

       Good – Section 4.2 states that "For certificates issued on or after 1st September 2020, this verification will take place at least every 397 days." This is in accordance with Mozilla's proposed revisions to the Mozilla Root Store Policy, v. 2.7.1.

CAA record checking and recognized domain names in section 4.2 (BR § 2.2)

"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."

       Meh – Section 4.2 of the CPS adequately states the CAA validation practices. The description of processes used by e-commerce monitoring could be more detailed. Note, also, that RFC 6844 has now been replaced by RFC 8659.

Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3) (BR 6.5.1)

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".

       OK – Section 5.2.3 of the CP says, "Authorised employees identify themselves to the certification system using multi-factor-autentication, at least a hardware token (with an identification key) and a password." (But I don't think it highlights "all accounts capable of causing 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"

       Should be fixed – e-commerce monitoring should state in its CPS that it performs pre-issuance linting to prevent formatting and content errors in the SSL/TLS server certificates it issues. See e.g. https://github.com/zmap/zlint

Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2)

24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)

       Needs to be fixed - CP section 4.9.5 states, "The maximum duration permitted between receiving the request and performing it depends on the current legal conditions, but is less than 24 hours." CP section 4.9.1 contains two lists of revocation circumstances. The first contains 16 reasons. Presumably, if any of these 16 situations arises, then the certificate would be revoked within 24 hours. The Baseline Requirements only list five reasons for 24-hour revocation—including key compromise and "[if] The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys)." e-commerce monitoring should (1) compare the two lists in BR§4.9.1.1 (end entity certificate revocation) with the CP's list of 16 and (2) compare the 9 reasons for revocation in BR§4.9.1.2 with the 11 reasons currently listed in section 4.9.1.2 of the CPS.

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 …"

       Needs to be fixed – For SMIME certificates trusted by Mozilla, they must also be revoked "[if] 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" and "[if] the certificate was issued in violation of the then-current version of the[] requirements [of the Mozilla Root Store Policy]".

CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6) (BR § 4.9.7)

       Good – Section 4.9.7 of the CP says, "Revocation and suspension lists for server-certificates (EV included) are valid for a maximum of 10 days (and updated at least every 7 days)."

CA must not allow certificate suspension (BR § 4.9.13)

       Needs to be fixed – Sections 4.9.13 says, "6. The operator receives notice that the subscriber is no longer legally authorised to use a name that has been entered into the certificate, especially a domain name or an IP address. 7. The operator receives notice that a wild card certificate has been used to authenticate a subdomain with fraudulent intent or intent to deceive."

OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6)

       Good – Section 4.9.7 of the CP states, "OCSP answers are valid for 10 days (the data for which is updated every 4 days)."

Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7)

"Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla."

       Needs to be fixed- Mozilla and other Application Software Providers must be notified immediately whenever e-commerce monitoring suspects that there may have been any CA private key compromise. This language can be placed in section 5.7.

CA must not generate Subscriber key pairs (MRSP § 5.2)

"CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage."

       Good – Section 6.1.1 of the CP says, " In case of server certificates, the key generation has to be performed by the subscriber."

Must meet RSA key requirements (MRSP § 5.1) (BR §§ 6.1.5 and 6.1.6)

       Needs to be fixed – The CP states RSA keys must be at least 2048 bits, but there are other parameters that must be checked. e-commerce monitoring should implement pre-issuance linting to ensure that public key parameters (and certificates) meet the requirements. For example, the above-referenced Mozilla and CA/Browser Forum requirements include "modulus size in bits is divisible by 8", "rsaEncryption OID (1.2.840.113549.1.1.1) with a NULL parameter", etc.

Must meet ECDSA key requirements, P-256 or P-384 (MRSP § 5.1) (BR 6.1.5)

       Meh – Section 7.1 of the CP states that elliptical curve keys must have a minimum length of 256 bits. The Baseline Requirements allow NIST P-256, P-384, and P-521, which is fine, but e-commerce monitoring should know that Mozilla currently only supports P-256 and P-384. Linting should be implemented.

Certificate lifetimes limited to 398 days (BR § 6.3.2)

"Subscriber Certificates … SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days."

       Good – Section 6.3.2 of the CP states that the maximum validity period is 397 days.

Network Security (MRSP § 2.1.2)

CAs must "follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document".

       Needs to be fixed – Currently, Section 6.7 of the CP only says, "The necessary security controls are documented in the GLOBALTRUST® Certificate Security Policy." The CA/B Forum's Network and Certificate System Security Requirements is only mentioned as item number 27 in Appendix A.

Serial numbers greater than 64 bits generated by a CSPRNG (MRSP § 5.2)

"all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG."

       Good- CP section 7.1 states that serial numbers are comprised of 64 bits of entropy from a CSPRNG.

EKUs required in end user certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f)

       Should be fixed – The discussion of EKUs in section 7.1 is a little confusing because it references the "enduser-sub-certificate" and not the contents for an "End user certificate". EKUs for "end user certificates" should be specified.

Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 7.1.3.2.1)

       Good – Only one references was found to a SHA1 root CA certificate in the CP (but is that root CA certificate still in use)?

Any CN must also be in a SAN (BR § 7.1.4.2.2.a)

       Good – CP section 7.1.2 states, "If the subject contains the field commonName, its content is always an entry (domain name or IP address) from subjectAltName."

Extended Validation-specific requirements

EVG Section 8.4 - the CA shall maintain liability insurance of US$2 million and professional liability insurance of US$5 million.

       Needs to be fixed – Section 9.2 of the CP or CPS should address this EV requirement.

EVG Sections 9.2.3, 11.2.1, 11.2.2, and 11.6.1 – 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"

       Good – Section 7.1 of the CP states that "the subject string contains the field businessCategory with the content "Private Organization", "Government Entity" or "Non-Commercial Entity", depending on the categorisation of the organisation of the Applicant." Section 4.2 of the CPS notes that for a private organization, "the information source" is consulted validity. Existence and identity is checked. Verification is considered successful if QGIS information matches. Also, "If the verified registration of the organisation is younger than three years old" e-commerce monitoring verifies the operational existence. (CPS section 4.2)

EVG Section 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.

       Good – Section 7.1 of the CP states, "the subject string contains a selection of fields jurisdictionOfIncorporationLocalityName, jurisdictionOfIncorporationStateOrProvinceName, jurisdictionOfIncorporationCountryName. The selection is defined by the jurisdiction of the organisation registration."

EVG Sections 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.

       Needs to be fixed – It appears there is a typo in the translation. Instead of "Date of Registration" it says "the data of registration".

EVG Section 9.2.6 - subject physical address of place of business must contain the address of the physical location of the business.

       Needs to be fixed / Clarified – If the optional EV field of "streetAddress" for the physical location of the business is verified / validated, it is unclear how that is verified. Also, how are the other mandatory address fields verified for all four types of EV entities? It appears from Section 4.2 of the CPS that some verification steps take place " It is verified as to whether the address given is the actual business address of the applicant organisation or a mother/daughter company (and not just a postbox). The telephone number of the business address is verified."

EVG Sections 9.2.7 and 11.3.1 - the CA shall implement a process that prevents a trade name / DBA in the O or OU field unless the CA has verified that information.

       Meh/Should be fixed– Section 3.1.6 of the CP currently only states, "It is permitted to enter a publically registered trademark as the name of an organisation, provided that the applicant can demonstrate that the trademark may be used and that the official name of the company holding the trademark is given afterwards in brackets." More information in this area of validation/information-verification is needed.

EVG Section 9.2.9 - the CA shall not include any subject attributes except as specified in section 9.2 of the EV Guidelines.

       Needs to be fixed – It is unclear how e-commerce monitoring ensures that it strictly follows the certificate-content requirements of the EV Guidelines.

EVG Sections 9.3.2 and 9.3.5 - subscriber certificates shall contain the appropriate EV policy OIDs.

       Good – Section 7.1.6 of the CP states, "Server certificates contain the additional OID entry 2.23.140.1.2.2 (OV) or 2.23.140.1.1 (EV)."

EVG Section 9.4 - the validity period for an EV certificate shall not exceed 398 days

       Good – Section 6.3.2 of the CP states that the maximum validity period is 397 days.

EVG Section 9.8.1 - wildcard certificates are not allowed.

       Good – Section 7.1 of the CP and section 4.2 of the CPS state that wildcards are not allowed in EV certificates.

EVG Section 10.1.2 - the roles of certificate requestor, certificate approver, and contract signer are required as part of the process for issuing EV certificates.

       Meh – Section 4.2 of the CPS states, "Applications for EV certificates must be made, checked, authorised and a legally binding contract must be confirmed by one or more sufficiently authorised person(s) designated by the applicant organisation. The signatures on the certificate application and the subscriber agreement are checked for sufficient plausibility and that they come from the correct persons. The name, title, relationship to the organisation making the application and the relevant authorisation to represent the organisation of the persons involved is verified." The CP and CPS are not entirely clear on how these roles are called upon to act during the EV issuance process.

EVG Section 11.2.2(4) - principal individuals must be validated in a face-to-face setting.

       Good – CPS Section 4.2 states, "In case of a Business Entity, whose legal existence was not created by a filing with an Incorporating Agency, the identity of a Principal Individual is checked in a face-to-face-meeting."

EVG Section 11.5.1 - the CA must establish a "Verified Method of Communication" with the applicant.

       Needs to be fixed – How does e-commerce monitoring communicate securely with the true applicant? Section 4.2 of the CPS states, " The telephone number of the business address is verified. Sources for the telephone number are information from the telephone operator or an appropriate information source ('qualified independent information source, QIIS or a 'qualified governmental information source', QGIS), or a verified 'legal opinion' or the 'confirmation of an auditor'." Other than that, the CPS does not say how this establishes a Verified Method of Communication to ensure that the CA is dealing with the true organization or authorized representative and not a fraudster. Certainly, the RA cannot use an unverified, self-provided telephone number or email address from just anyone. Maybe this language is in the CP/CPS, but I did not see how the CA verifies that the certificate request is authentic.

EVG Section 11.7.1 - domain name verification must use a procedure from section 3.2.2.4 of the Baseline Requirements (BR)

       Good – Section 4.2 of the CPS describes that domain name validation is performed solely according to method described in section 3.2.2.4.4 of the Baseline Requirements.

EVG Section 11.8.1 - the CA must verify the name and title of the contract signer and certificate approver.

       Needs to be fixed – The only language I found was in section 4.1.2 of the CP and section 4.2 of the CPS which set forth that e-commerce monitoring identifies a person authorized to represent the organization, but not specifically that person's title. Also, the roles of contract signer and certificate approver are not called out.

EVG Section 11.9 - the CA must verify the signature on the subscriber agreement and certificate request

       Good – Section 4.2 of the CPS says, "The signatures on the certificate application and the subscriber agreement are checked for sufficient plausibility and that they come from the correct persons."

EVG Section 11.11.5 - the CA shall use documented processes to check the accuracy of a QIIS.

       Needs to be fixed – it is not clear how e-commerce monitoring manages its QIISes, QGISes and QGTISes.

EVG Section 11.12.2 - the CA must check whether the applicant, contract signer, or certificate approver is on denied persons lists, etc.

       Needs to be fixed – Language is needed in the CP or CPS to indicate that, prior to certificate issuance, e-commerce monitoring checks databases to make sure the organization and authorized representatives are not on "denied-persons" lists as terrorists, money launderers, etc.

EVG Sections 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.

       Good – Section 4.2 of the CPS states, " Before an EV certificate is issued, all necessary information is verified by an authorised person who has not collected the information."

EVG Section 11.14.3 - validation data cannot be reused after 13 months

       Good – CP Sections 4.2 and 4.6.3 limit data reuse to 397 days.

EVG Section 12 - root CA private keys must not be used to sign EV certificates.

       Good – Section 1 of the CP says, " Root certificates are used only to sign CA certificates and revocation lists of the certification operations. Other uses are not allowed by the processes of the CA."

EVG Section 14.1.1 - a CA must verify the identity and trustworthiness of anyone involved in EV processes.

       Good – Section 5.3.1 of the CP states, "The CA does not employee persons who have committed prosecutable acts that indicate that they would be unsuitable for a position of trust. The identity and trustworthiness of all people involved in the operation of certification services is checked before they are employed. The identity of employees, others contracted by the operator and persons involved in the issuance of certificates is checked."

EVG Section 14.1.2 – the internal examination of specialists must include the EV certificate validation criteria of the EV guidelines.

       Needs to be fixed – Section 5.3.3 of the CP does not set forth annual training and examination validation specialists covering the standards related to the issuance and management of EV certificates.

EVG Section 14.2.1 - the CA shall ensure that third-party personnel satisfy the training and skills requirements of section 14 of the EV guidelines.

       OK – Section 5.3.7 of the CP states, "If the contractor is involved in the issuance of server certificates, the operator conducts an annual internal examination as to whether the contractor is complying with the requirements of [CABROWSER-BASE]." However, this is also required by the EV Guidelines.

EVG Section 17.5 and BR section 8.7 – Both provisions require that CAs self-audit at least three percent (3%) of the server certificates issued since the last audit.

       Good – CPS section 5.4 provides that self-audits are carried out on at least 3% of all certificates issued since the that last self-audit.

Whiteboard: [ca-cps-review] - BW 2020-10-22 → [ca-cps-review] - BW 2020-12-22 Comment #13

Dear Ben.

Thank you very much for your detailed review.
We will adress every item and get back to you in the next few days.

Have a nice christmas.

BR
Daniel

Dear Ben,

I am sending you our statement below on all the points you have marked as Meh or need to fix. As an attachment to this bug you will find redlined drafts of CP and CPS. If no further concerns arise, these versions will come into force on 15.1.2021 without further changes.

Mozilla Root Store and Baseline Requirements

CP/CPS made available under a Creative Commons License (MRSP § 3.3.3)
"CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)"

   Meh - The title page to the CPS says, "The document is subject to copyright and is only made available in the context of certification services. An additional application, full or partial transmission to a third party or the publication of the document by a third party requires the prior consent of the author(s) and the CA."

DZ: License statement added to main title

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 those Requirements, those Requirements take precedence."

   Meh – CP Section 8 states that in the event of any inconsistency with the CP/CPS "d) in all other cases, the requirements of the conformity documents have priority."

DZ: GCP 8 now uses the term „take precedence“ instead of „have priority“; GCP 1.6. defines „Conformity Documents“

Explicit annual revision of CP/CPS w/ table of changes (MRSP § 3.3.4) (BR § 2.3)

"CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document." Also, a version history table provides evidence of compliance and good change management practices.

   Good –Sections 1.2 in the CP and CPS contain "History of changes".
   Meh – Regarding the CP and CPS, section 9.12.1 of the CP says, "The review take place at least once a year." However, it does not say that the documents are reversioned and re-dated every year even if there are no changes. However, the history of changes indicates that this has happened over the last three years (since 2017).

DZ: GCP 9.12.1 amended

Statement of Non-Delegation for Domain Validation (BR § 1.3.2)

"With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2."

   OK – Section 5.3.7 of the CP states, " Domain validation, including validation of the domain portain [sic] of an eMail address, and the authentication for an IP address are in any case conducted by the operator itself and may not be transferred to a contractor."

DZ: now „portion“, thank you

Naming compliant with X.500, RFC5280, BRs and EVGs

The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards.

   Meh – Section 3.1, 3.1.4, or 7.1.4 doesn't expressly acknowledge the importance of following X.500, RFC 5280, the Baseline Requirements and the EV Guidelines for naming.

DZ: naming clarified in GCP 7.1.4

Data sources need to be accurate (BR § 3.2.2.7 and EVG § 11.11.5)

For OV – "[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification."
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."

   Needs to be fixed – Among other mentions of reliable data sources in the CP and CPS, are the following: CPS section 3.2.5 states, "at least one agency should be named as a suitable source of information on the organisation (eg. a chamber the organisation belongs to, commercial register, an authority in charge of associations...). If the organisations are established according to the law, the legal provisions providing for their establishment should be named in place of an information source." And section 4.2 of the CPS states, " Qualified, authoritative sources of information can be called upon to verify information on the organisation, in particular, the official telephone book or official directory." Also, CP section 4.2 refers to "Examination of the organisation and trademarks used by the organisation (according to credible certificates submitted by the applicant, as per disclosure (inc. requests to databases) from a qualified official source of information or with the assistance of a qualified independent source of information, especially the databases of trustworthy third parties)".
   However, neither the CP or the CPS explains how the CA establishes that the sources are inherently more reliable than other data sources. The CA needs to disclose the criteria or process used to designate a "reliable data source" and a QIIS, which are two different kinds of sources – one for OV and the other for EV.
   Also, EVG Sections 9.2.4, 9.2.5, and 11.1.3 require the publication of e-commerce monitoring's verification sources, incorporating agencies, and registration agencies (e.g. QIISes, QGISes, QGTISes). Information about where this information can be located must appear in section 3.2 of the CPS.

DZ: GCP 4.2 now clarifying; GCP 3.2.2 points to the dicslosure of verification sources.

CAA record checking and recognized domain names in section 4.2 (BR § 2.2)
"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."

   Meh – Section 4.2 of the CPS adequately states the CAA validation practices. The description of processes used by e-commerce monitoring could be more detailed. Note, also, that RFC 6844 has now been replaced by RFC 8659.

DZ: GCPS 4.2 is more detailed now, RFC reference updated

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"

   Should be fixed – e-commerce monitoring should state in its CPS that it performs pre-issuance linting to prevent formatting and content errors in the SSL/TLS server certificates it issues. See e.g. https://github.com/zmap/zlint

DZ: e-commerce monitoring gmbh uses a pre issuance linting process (currently self developed with zlint and others under consideration), this is adressed by GCP 4.3. („reviewed and approved“ is intended to mean automatic checks as well as human four eyes principle at the same time). GCP 4.3 contains now a clarification, that "reviewed" means also technical implemented checks.

Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2)
24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)

   Needs to be fixed - CP section 4.9.5 states, "The maximum duration permitted between receiving the request and performing it depends on the current legal conditions, but is less than 24 hours." CP section 4.9.1 contains two lists of revocation circumstances. The first contains 16 reasons. Presumably, if any of these 16 situations arises, then the certificate would be revoked within 24 hours. The Baseline Requirements only list five reasons for 24-hour revocation—including key compromise and "[if] The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys)." e-commerce monitoring should (1) compare the two lists in BR§4.9.1.1 (end entity certificate revocation) with the CP's list of 16 and (2) compare the 9 reasons for revocation in BR§4.9.1.2 with the 11 reasons currently listed in section 4.9.1.2 of the CPS.

DZ: No need to fix – As the BR began to differ between 5 days and 24 hours, It was decided to follow the stricter 24h hours for all revocation reasons

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 …"

   Needs to be fixed – For SMIME certificates trusted by Mozilla, they must also be revoked "[if] 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" and "[if] the certificate was issued in violation of the then-current version of the[] requirements [of the Mozilla Root Store Policy]".

DZ: No need to fix, these are already covered by GCP 4.9.1 bullet 6 and 16

CA must not allow certificate suspension (BR § 4.9.13)

   Needs to be fixed – Sections 4.9.13 says, "6. The operator receives notice that the subscriber is no longer legally authorised to use a name that has been entered into the certificate, especially a domain name or an IP address. 7. The operator receives notice that a wild card certificate has been used to authenticate a subdomain with fraudulent intent or intent to deceive."

DZ: Fixed, thank you. Please note that according to GCP 4.9., suspension had already been fobidden for ssl certificates. GCP 4.9.3 was missed to align.

Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7)

"Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla."

   Needs to be fixed- Mozilla and other Application Software Providers must be notified immediately whenever e-commerce monitoring suspects that there may have been any CA private key compromise. This language can be placed in section 5.7.

DZ: This was already covered by GCP 5.7 („organisations with whom the CA has relevant agreements”) Maybe this text was unclear, now you find the browser vendors in brackets.

Must meet RSA key requirements (MRSP § 5.1) (BR §§ 6.1.5 and 6.1.6)

   Needs to be fixed – The CP states RSA keys must be at least 2048 bits, but there are other parameters that must be checked. e-commerce monitoring should implement pre-issuance linting to ensure that public key parameters (and certificates) meet the requirements. For example, the above-referenced Mozilla and CA/Browser Forum requirements include "modulus size in bits is divisible by 8", "rsaEncryption OID (1.2.840.113549.1.1.1) with a NULL parameter", etc.

DZ: clarified in GCP 7.1.2

Must meet ECDSA key requirements, P-256 or P-384 (MRSP § 5.1) (BR 6.1.5)

   Meh – Section 7.1 of the CP states that elliptical curve keys must have a minimum length of 256 bits. The Baseline Requirements allow NIST P-256, P-384, and P-521, which is fine, but e-commerce monitoring should know that Mozilla currently only supports P-256 and P-384. Linting should be implemented.

DZ: OK thank you, linting is implemented.

Network Security (MRSP § 2.1.2)

CAs must "follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document".

   Needs to be fixed – Currently, Section 6.7 of the CP only says, "The necessary security controls are documented in the GLOBALTRUST® Certificate Security Policy." The CA/B Forum's Network and Certificate System Security Requirements is only mentioned as item number 27 in Appendix A.

DZ: added to the „Conformity Documents“ in GCP 8

EKUs required in end user certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f)

   Should be fixed – The discussion of EKUs in section 7.1 is a little confusing because it references the "enduser-sub-certificate" and not the contents for an "End user certificate". EKUs for "end user certificates" should be specified.

DZ: Definitions in GCP 1.6 items „simple certificate“ and „qualified certificate“ already contain that (paragraph „Further information in the certificate”)

Extended Validation-specific requirements

EVG Section 8.4 - the CA shall maintain liability insurance of US$2 million and professional liability insurance of US$5 million.

   Needs to be fixed – Section 9.2 of the CP or CPS should address this EV requirement.

DZ: GCP 9.2 references the EV Guidelines now

EVG Sections 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.

   Needs to be fixed – It appears there is a typo in the translation. Instead of "Date of Registration" it says "the data of registration".

DZ: Typo fixed, thank you

EVG Section 9.2.6 - subject physical address of place of business must contain the address of the physical location of the business.

   Needs to be fixed / Clarified – If the optional EV field of "streetAddress" for the physical location of the business is verified / validated, it is unclear how that is verified. Also, how are the other mandatory address fields verified for all four types of EV entities? It appears from Section 4.2 of the CPS that some verification steps take place " It is verified as to whether the address given is the actual business address of the applicant organisation or a mother/daughter company (and not just a postbox). The telephone number of the business address is verified."

DZ: In all the countries where we have served clients so far, there has never been a case where you could not have verified this information from a QIIS/QGIS/QTIS. Of course we are aware that this does not always have to be the case, I can only speak for the preparation for the EV and the practice so far (e.g. for qualified eIDAS signature certificates). Europe, and in particular the German-speaking countries, have a very well-developed register system.

EVG Sections 9.2.7 and 11.3.1 - the CA shall implement a process that prevents a trade name / DBA in the O or OU field unless the CA has verified that information.

   Meh/Should be fixed– Section 3.1.6 of the CP currently only states, "It is permitted to enter a publically registered trademark as the name of an organisation, provided that the applicant can demonstrate that the trademark may be used and that the official name of the company holding the trademark is given afterwards in brackets." More information in this area of validation/information-verification is needed.

DZ: GCP 3.1.2 already adresses the trade name and its verification. GCP 3.2.4 adresses the same problem in a general way.

EVG Section 9.2.9 - the CA shall not include any subject attributes except as specified in section 9.2 of the EV Guidelines.

   Needs to be fixed – It is unclear how e-commerce monitoring ensures that it strictly follows the certificate-content requirements of the EV Guidelines.

DZ: now clarified in GCP 7.1 paragraph „In addition, the following applies for EV and qualified server certificates:”

EVG Section 10.1.2 - the roles of certificate requestor, certificate approver, and contract signer are required as part of the process for issuing EV certificates.

   Meh – Section 4.2 of the CPS states, "Applications for EV certificates must be made, checked, authorised and a legally binding contract must be confirmed by one or more sufficiently authorised person(s) designated by the applicant organisation. The signatures on the certificate application and the subscriber agreement are checked for sufficient plausibility and that they come from the correct persons. The name, title, relationship to the organisation making the application and the relevant authorisation to represent the organisation of the persons involved is verified." The CP and CPS are not entirely clear on how these roles are called upon to act during the EV issuance process.

DZ: Definitions of the roles added to GCP 1.3.3, clarification of GCP 4.1.1

EVG Section 11.5.1 - the CA must establish a "Verified Method of Communication" with the applicant.

   Needs to be fixed – How does e-commerce monitoring communicate securely with the true applicant? Section 4.2 of the CPS states, " The telephone number of the business address is verified. Sources for the telephone number are information from the telephone operator or an appropriate information source ('qualified independent information source, QIIS or a 'qualified governmental information source', QGIS), or a verified 'legal opinion' or the 'confirmation of an auditor'." Other than that, the CPS does not say how this establishes a Verified Method of Communication to ensure that the CA is dealing with the true organization or authorized representative and not a fraudster. Certainly, the RA cannot use an unverified, self-provided telephone number or email address from just anyone. Maybe this language is in the CP/CPS, but I did not see how the CA verifies that the certificate request is authentic.

DZ: Verification through a call only missed in the english part, thank you

EVG Section 11.8.1 - the CA must verify the name and title of the contract signer and certificate approver.

   Needs to be fixed – The only language I found was in section 4.1.2 of the CP and section 4.2 of the CPS which set forth that e-commerce monitoring identifies a person authorized to represent the organization, but not specifically that person's title. Also, the roles of contract signer and certificate approver are not called out.

DZ: Also covered now by the definition of the roles in 1.3.3

EVG Section 11.11.5 - the CA shall use documented processes to check the accuracy of a QIIS.

   Needs to be fixed – it is not clear how e-commerce monitoring manages its QIISes, QGISes and QGTISes.

DZ: GCP 4.2 improved

EVG Section 11.12.2 - the CA must check whether the applicant, contract signer, or certificate approver is on denied persons lists, etc.

   Needs to be fixed – Language is needed in the CP or CPS to indicate that, prior to certificate issuance, e-commerce monitoring checks databases to make sure the organization and authorized representatives are not on "denied-persons" lists as terrorists, money launderers, etc.

DZ: GCP 4.2.2 last paragraph

EVG Section 14.1.2 – the internal examination of specialists must include the EV certificate validation criteria of the EV guidelines.

   Needs to be fixed – Section 5.3.3 of the CP does not set forth annual training and examination validation specialists covering the standards related to the issuance and management of EV certificates.

DZ: GCP 5.3.3. improved

EVG Section 14.2.1 - the CA shall ensure that third-party personnel satisfy the training and skills requirements of section 14 of the EV guidelines.

   OK – Section 5.3.7 of the CP states, "If the contractor is involved in the issuance of server certificates, the operator conducts an annual internal examination as to whether the contractor is complying with the requirements of [CABROWSER-BASE]." However, this is also required by the EV Guidelines.

DZ: Fixed, thank you

Attached file GCP V2.0h draft redlined (obsolete) —
Attached file GCPS V2.0h draft redlined (obsolete) —

Review of Globaltrust CP and CPS v. 2.0h (draft/redlined)
Dated 15-January-2021

Mozilla Root Store and Baseline Requirements

CP/CPS made available under a Creative Commons License (MRSP § 3.3.3)
"CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)"

Meh - The title page to the CPS says, "The document is subject to copyright and is only made available in the context of certification services. An additional application, full or partial transmission to a third party or the publication of the document by a third party requires the prior consent of the author(s) and the CA."

DZ: License statement added to main title

Fixed

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 those Requirements, those Requirements take precedence."

Meh – CP Section 8 states that in the event of any inconsistency with the CP/CPS "d) in all other cases, the requirements of the conformity documents have priority."

DZ: GCP 8 now uses the term „take precedence“ instead of „have priority“; GCP 1.6. defines „Conformity Documents“

Fixed

Explicit annual revision of CP/CPS w/ table of changes (MRSP § 3.3.4) (BR § 2.3)

"CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document." Also, a version history table provides evidence of compliance and good change management practices.

Good –Sections 1.2 in the CP and CPS contain "History of changes".
Meh – Regarding the CP and CPS, section 9.12.1 of the CP says, "The review take place at least once a year." However, it does not say that the documents are reversioned and re-dated every year even if there are no changes. However, the history of changes indicates that this has happened over the last three years (since 2017).

DZ: GCP 9.12.1 amended

Fixed

Statement of Non-Delegation for Domain Validation (BR § 1.3.2)

"With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2."

OK – Section 5.3.7 of the CP states, " Domain validation, including validation of the domain portain [sic] of an eMail address, and the authentication for an IP address are in any case conducted by the operator itself and may not be transferred to a contractor."

DZ: now „portion“, thank you

Fixed

Naming compliant with X.500, RFC5280, BRs and EVGs

The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards.

Meh – Section 3.1, 3.1.4, or 7.1.4 doesn't expressly acknowledge the importance of following X.500, RFC 5280, the Baseline Requirements and the EV Guidelines for naming.

DZ: naming clarified in GCP 7.1.4

Fixed

Data sources need to be accurate (BR § 3.2.2.7 and EVG § 11.11.5)

For OV – "[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification."
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."

Needs to be fixed – Among other mentions of reliable data sources in the CP and CPS, are the following: CPS section 3.2.5 states, "at least one agency should be named as a suitable source of information on the organisation (eg. a chamber the organisation belongs to, commercial register, an authority in charge of associations...). If the organisations are established according to the law, the legal provisions providing for their establishment should be named in place of an information source." And section 4.2 of the CPS states, " Qualified, authoritative sources of information can be called upon to verify information on the organisation, in particular, the official telephone book or official directory." Also, CP section 4.2 refers to "Examination of the organisation and trademarks used by the organisation (according to credible certificates submitted by the applicant, as per disclosure (inc. requests to databases) from a qualified official source of information or with the assistance of a qualified independent source of information, especially the databases of trustworthy third parties)".
However, neither the CP or the CPS explains how the CA establishes that the sources are inherently more reliable than other data sources. The CA needs to disclose the criteria or process used to designate a "reliable data source" and a QIIS, which are two different kinds of sources – one for OV and the other for EV.
Also, EVG Sections 9.2.4, 9.2.5, and 11.1.3 require the publication of e-commerce monitoring's verification sources, incorporating agencies, and registration agencies (e.g. QIISes, QGISes, QGTISes). Information about where this information can be located must appear in section 3.2 of the CPS.

DZ: GCP 4.2 now clarifying; GCP 3.2.2 points to the disclosure of verification sources.

Fixed (subject to verification of listing at https://www.globaltrust.eu/certificate-policy.html)

CAA record checking and recognized domain names in section 4.2 (BR § 2.2)
"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."

Meh – Section 4.2 of the CPS adequately states the CAA validation practices. The description of processes used by e-commerce monitoring could be more detailed. Note, also, that RFC 6844 has now been replaced by RFC 8659.

DZ: GCPS 4.2 is more detailed now, RFC reference updated

Fixed

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"

Should be fixed – e-commerce monitoring should state in its CPS that it performs pre-issuance linting to prevent formatting and content errors in the SSL/TLS server certificates it issues. See e.g. https://github.com/zmap/zlint

DZ: e-commerce monitoring gmbh uses a pre issuance linting process (currently self developed with zlint and others under consideration), this is adressed by GCP 4.3. („reviewed and approved“ is intended to mean automatic checks as well as human four eyes principle at the same time). GCP 4.3 contains now a clarification, that "reviewed" means also technical implemented checks.

Good

Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2)
24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)

Needs to be fixed - CP section 4.9.5 states, "The maximum duration permitted between receiving the request and performing it depends on the current legal conditions, but is less than 24 hours." CP section 4.9.1 contains two lists of revocation circumstances. The first contains 16 reasons. Presumably, if any of these 16 situations arises, then the certificate would be revoked within 24 hours. The Baseline Requirements only list five reasons for 24-hour revocation—including key compromise and "[if] The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys)." e-commerce monitoring should (1) compare the two lists in BR§4.9.1.1 (end entity certificate revocation) with the CP's list of 16 and (2) compare the 9 reasons for revocation in BR§4.9.1.2 with the 11 reasons currently listed in section 4.9.1.2 of the CPS.

DZ: No need to fix – As the BR began to differ between 5 days and 24 hours, It was decided to follow the stricter 24h hours for all revocation reasons

Good

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 …"

Needs to be fixed – For SMIME certificates trusted by Mozilla, they must also be revoked "[if] 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" and "[if] the certificate was issued in violation of the then-current version of the[] requirements [of the Mozilla Root Store Policy]".

DZ: No need to fix, these are already covered by GCP 4.9.1 bullet 6 and 16

Good

CA must not allow certificate suspension (BR § 4.9.13)

Needs to be fixed – Sections 4.9.13 says, "6. The operator receives notice that the subscriber is no longer legally authorised to use a name that has been entered into the certificate, especially a domain name or an IP address. 7. The operator receives notice that a wild card certificate has been used to authenticate a subdomain with fraudulent intent or intent to deceive."

DZ: Fixed, thank you. Please note that according to GCP 4.9., suspension had already been forbidden for ssl certificates. GCP 4.9.3 was missed to align.

Fixed

Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7)

"Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla."

Needs to be fixed- Mozilla and other Application Software Providers must be notified immediately whenever e-commerce monitoring suspects that there may have been any CA private key compromise. This language can be placed in section 5.7.

DZ: This was already covered by GCP 5.7 („organisations with whom the CA has relevant agreements”) Maybe this text was unclear, now you find the browser vendors in brackets.

Good/Fixed

Must meet RSA key requirements (MRSP § 5.1) (BR §§ 6.1.5 and 6.1.6)

Needs to be fixed – The CP states RSA keys must be at least 2048 bits, but there are other parameters that must be checked. e-commerce monitoring should implement pre-issuance linting to ensure that public key parameters (and certificates) meet the requirements. For example, the above-referenced Mozilla and CA/Browser Forum requirements include "modulus size in bits is divisible by 8", "rsaEncryption OID (1.2.840.113549.1.1.1) with a NULL parameter", etc.

DZ: clarified in GCP 7.1.2

**OK - Fixed in CP section 7.1.3 **

Must meet ECDSA key requirements, P-256 or P-384 (MRSP § 5.1) (BR 6.1.5)

Meh – Section 7.1 of the CP states that elliptical curve keys must have a minimum length of 256 bits. The Baseline Requirements allow NIST P-256, P-384, and P-521, which is fine, but e-commerce monitoring should know that Mozilla currently only supports P-256 and P-384. Linting should be implemented.

DZ: OK thank you, linting is implemented.

OK

Network Security (MRSP § 2.1.2)

CAs must "follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document".

Needs to be fixed – Currently, Section 6.7 of the CP only says, "The necessary security controls are documented in the GLOBALTRUST® Certificate Security Policy." The CA/B Forum's Network and Certificate System Security Requirements is only mentioned as item number 27 in Appendix A.

DZ: added to the „Conformity Documents“ in GCP 8

Good

EKUs required in end user certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f)

Should be fixed – The discussion of EKUs in section 7.1 is a little confusing because it references the "enduser-sub-certificate" and not the contents for an "End user certificate". EKUs for "end user certificates" should be specified.

DZ: Definitions in GCP 1.6 items „simple certificate“ and „qualified certificate“ already contain that (paragraph „Further information in the certificate”)

OK

Extended Validation-specific requirements

EVG Section 8.4 - the CA shall maintain liability insurance of US$2 million and professional liability insurance of US$5 million.

Needs to be fixed – Section 9.2 of the CP or CPS should address this EV requirement.

DZ: GCP 9.2 references the EV Guidelines now

Fixed

EVG Sections 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.

Needs to be fixed – It appears there is a typo in the translation. Instead of "Date of Registration" it says "the data of registration".

DZ: Typo fixed, thank you

OK (But there is still a typo in GCP 7.1 - it says "dat of registration" in the version I reviewed)

EVG Section 9.2.6 - subject physical address of place of business must contain the address of the physical location of the business.

Needs to be fixed / Clarified – If the optional EV field of "streetAddress" for the physical location of the business is verified / validated, it is unclear how that is verified. Also, how are the other mandatory address fields verified for all four types of EV entities? It appears from Section 4.2 of the CPS that some verification steps take place " It is verified as to whether the address given is the actual business address of the applicant organisation or a mother/daughter company (and not just a postbox). The telephone number of the business address is verified."

DZ: In all the countries where we have served clients so far, there has never been a case where you could not have verified this information from a QIIS/QGIS/QTIS. Of course we are aware that this does not always have to be the case, I can only speak for the preparation for the EV and the practice so far (e.g. for qualified eIDAS signature certificates). Europe, and in particular the German-speaking countries, have a very well-developed register system.

OK

EVG Sections 9.2.7 and 11.3.1 - the CA shall implement a process that prevents a trade name / DBA in the O or OU field unless the CA has verified that information.

Meh/Should be fixed– Section 3.1.6 of the CP currently only states, "It is permitted to enter a publically registered trademark as the name of an organisation, provided that the applicant can demonstrate that the trademark may be used and that the official name of the company holding the trademark is given afterwards in brackets." More information in this area of validation/information-verification is needed.

DZ: GCP 3.1.2 already addresses the trade name and its verification. GCP 3.2.4 addresses the same problem in a general way.

OK

EVG Section 9.2.9 - the CA shall not include any subject attributes except as specified in section 9.2 of the EV Guidelines.

Needs to be fixed – It is unclear how e-commerce monitoring ensures that it strictly follows the certificate-content requirements of the EV Guidelines.

DZ: now clarified in GCP 7.1 paragraph „In addition, the following applies for EV and qualified server certificates:”

OK

EVG Section 10.1.2 - the roles of certificate requestor, certificate approver, and contract signer are required as part of the process for issuing EV certificates.

Meh – Section 4.2 of the CPS states, "Applications for EV certificates must be made, checked, authorised and a legally binding contract must be confirmed by one or more sufficiently authorised person(s) designated by the applicant organisation. The signatures on the certificate application and the subscriber agreement are checked for sufficient plausibility and that they come from the correct persons. The name, title, relationship to the organisation making the application and the relevant authorisation to represent the organisation of the persons involved is verified." The CP and CPS are not entirely clear on how these roles are called upon to act during the EV issuance process.

DZ: Definitions of the roles added to GCP 1.3.3, clarification of GCP 4.1.1

Fixed

EVG Section 11.5.1 - the CA must establish a "Verified Method of Communication" with the applicant.

Needs to be fixed – How does e-commerce monitoring communicate securely with the true applicant? Section 4.2 of the CPS states, " The telephone number of the business address is verified. Sources for the telephone number are information from the telephone operator or an appropriate information source ('qualified independent information source, QIIS or a 'qualified governmental information source', QGIS), or a verified 'legal opinion' or the 'confirmation of an auditor'." Other than that, the CPS does not say how this establishes a Verified Method of Communication to ensure that the CA is dealing with the true organization or authorized representative and not a fraudster. Certainly, the RA cannot use an unverified, self-provided telephone number or email address from just anyone. Maybe this language is in the CP/CPS, but I did not see how the CA verifies that the certificate request is authentic.

DZ: Verification through a call only missed in the english part, thank you

Fixed

EVG Section 11.8.1 - the CA must verify the name and title of the contract signer and certificate approver.

Needs to be fixed – The only language I found was in section 4.1.2 of the CP and section 4.2 of the CPS which set forth that e-commerce monitoring identifies a person authorized to represent the organization, but not specifically that person's title. Also, the roles of contract signer and certificate approver are not called out.

DZ: Also covered now by the definition of the roles in 1.3.3

Fixed

EVG Section 11.11.5 - the CA shall use documented processes to check the accuracy of a QIIS.

Needs to be fixed – it is not clear how e-commerce monitoring manages its QIISes, QGISes and QGTISes.

DZ: GCP 4.2 improved

Fixed

EVG Section 11.12.2 - the CA must check whether the applicant, contract signer, or certificate approver is on denied persons lists, etc.

Needs to be fixed – Language is needed in the CP or CPS to indicate that, prior to certificate issuance, e-commerce monitoring checks databases to make sure the organization and authorized representatives are not on "denied-persons" lists as terrorists, money launderers, etc.

DZ: GCP 4.2.2 last paragraph

Fixed

EVG Section 14.1.2 – the internal examination of specialists must include the EV certificate validation criteria of the EV guidelines.

Needs to be fixed – Section 5.3.3 of the CP does not set forth annual training and examination validation specialists covering the standards related to the issuance and management of EV certificates.

DZ: GCP 5.3.3. improved

Fixed

EVG Section 14.2.1 - the CA shall ensure that third-party personnel satisfy the training and skills requirements of section 14 of the EV guidelines.

OK – Section 5.3.7 of the CP states, "If the contractor is involved in the issuance of server certificates, the operator conducts an annual internal examination as to whether the contractor is complying with the requirements of [CABROWSER-BASE]." However, this is also required by the EV Guidelines.

DZ: Fixed, thank you

Fixed

Whiteboard: [ca-cps-review] - BW 2020-12-22 Comment #13 → [ca-ready-for-discussion 2021-01-08]
Attachment #9138396 - Attachment is obsolete: true
Attachment #9138397 - Attachment is obsolete: true
Attachment #9196094 - Attachment is obsolete: true
Attachment #9196095 - Attachment is obsolete: true

Dear Ben,

Thank you very much for the quick response.
Could you please start the public discussion?

BR
Daniel

This was moved into public discussion today with a close of public discussion scheduled for 26-Feb-2021. See https://groups.google.com/g/mozilla.dev.security.policy/c/FEWqChGgSjo/m/raJbB2T0BAAJ

Whiteboard: [ca-ready-for-discussion 2021-01-08] → [ca-in-discussion] - 2021-02-04

Public discussion completed on 26-Feb-2021 without comment. I am recommending that we include the GLOBAL TRUST 2020 Root in NSS with the websites trust bit (and EV) and the email trust bit enabled. Here is a link to the email that announced this on the m.d.s.p. list:
https://groups.google.com/g/mozilla.dev.security.policy/c/FEWqChGgSjo/m/h67TND3MBQAJ

Flags: needinfo?(kwilson)
Summary: Add GLOBALTRUST 2020 root certificate → Add e-commerce monitoring's GLOBALTRUST 2020 root certificate
Whiteboard: [ca-in-discussion] - 2021-02-04 → [ca-pending-approval] - 2021-02-27

As per Comment #23, and on behalf of Mozilla I approve this request from e-commerce monitoring GmbH to include the following root certificate:

** CN=GLOBALTRUST 2020; O=e-commerce monitoring GmbH; C=AT (Email, Websites); EV

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

Flags: needinfo?(kwilson)
Whiteboard: [ca-pending-approval] - 2021-02-27 → [ca-approved] - pending NSS and PSM code changes
Depends on: 1697071
Depends on: 1697074

I have filed bug #1697071 against NSS and bug #1697074 against PSM for the actual changes.

Dear Kathleen and Ben,

Thank you for guiding us through the application.

Best regards,
Daniel

Priority: -- → P1
Whiteboard: [ca-approved] - pending NSS and PSM code changes → [ca-approved] - In NSS 3.66, FF 90; pending PSM changes for EV
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Whiteboard: [ca-approved] - In NSS 3.66, FF 90; pending PSM changes for EV → [ca-approved] - In NSS 3.66, FF 90; EV enabled in FF 91
Whiteboard: [ca-approved] - In NSS 3.66, FF 90; EV enabled in FF 91 → [ca-approved] - In NSS 3.66, FF 90; EV enabled in FF 90
You need to log in before you can comment on or make changes to this bug.