Review of GLOBALTRUST CP and CPS v. 2.0g dated April 3, 2020
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 § 22.214.171.124.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 126.96.36.199 and 188.8.131.52, 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 email@example.com 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 § 184.108.40.206.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 §§ 220.127.116.11 and 18.104.22.168 (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 22.214.171.124.4 of the Baseline Requirements. For IP Address validation, the CA will use one of the methods found in sections 126.96.36.199.1, 188.8.131.52.2, or 184.108.40.206.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 § 220.127.116.11 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 §§ 18.104.22.168 and 22.214.171.124)
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§126.96.36.199 (end entity certificate revocation) with the CP's list of 16 and (2) compare the 9 reasons for revocation in BR§188.8.131.52 with the 11 reasons currently listed in section 184.108.40.206 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.1135220.127.116.11) 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 § 18.104.22.168.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 § 22.214.171.124.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 § 126.96.36.199.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 188.8.131.52.2.2 (OV) or 184.108.40.206.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 220.127.116.11 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 18.104.22.168.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.