##GlobalSign CPS v. 9.5 Review **Here is a review of the GlobalSign CPS, version 9.5, dated September 30, 2020 https://www.globalsign.com/en/repository/GlobalSign_CPS_v9.5_final.pdf** **CP/CPS structured in accordance with RFC 3647 with no blank sections** ([MRSP § 3.3.5](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses)) (BR § 2.2) **Good** – Confirmed **CP/CPS made available under a Creative Commons License** ([MRSP § 3.3.3](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses)) “CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)” **Good** – no conflicting language **Statement of adherence to BRs and their precedence** ([MRSP § 2.3](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#23-baseline-requirements-conformance)) (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.” **Good** – “If there is any inconsistency between this document and the Requirements above, the Requirements take precedence over this document.” **Separate, EKU-constrained issuing CAs** ([MRSP § 5.3](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#53-intermediate-certificates)) (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** – see CPS section 1.1.1 for listing of TLS and non-TLS root CAs **Clear identification of CAs covered by CP/CPS** ([MRSP § 3.3.6](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses)) “CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.” **OK** – The GlobalSign repository https://www.globalsign.com/en/repository appears to list just one CP and CPS. **Explicit annual revision of CP/CPS w/ table of changes** ([MRSP § 3.3.4](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses)) (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. **OK** Section 1.5.3 states “… CA Governance shall review this CPS at least annually and may make revisions and updates to policies as it sees fit or as required by other circumstances.” Section 2.3 states, “GlobalSign reviews its CP and CPS at least annually and makes appropriate changes so that GlobalSign operation remains accurate, transparent and complies with external requirements listed in the “*Acknowledgements*” section of this document.” While these two sections do not say that GlobalSign re-versions its CPS at least annually, the Document History table indicates that this has been the practice. However, it is advisable / would be helpful to include language such as “GlobalSign reviews and updates its CPS annually and increments the version number and adds a dated entry to the Document History table, even if no other changes are made to the document.” **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.” **Bad** - Section 3.2.7.1 doesn’t appear to prohibit the delegation of domain validation to third parties. It also references “methods 1-11 above for validating Wildcard FQDNs” but only lists nine methods. Otherwise, maybe I missed it, but I looked through the CPS and did not see where delegation of domain validation was otherwise prohibited. **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.” **OK** – GlobalSign provides an email address and adequate instructions in sections 1.5.2 and 4.9.3 of the CPS. **Naming compliant with X.500, RFC5280 and BRs** The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards. **OK** – GlobalSign references X.500, RFC 5280 and the Baseline Requirements for naming in sections 3.1 and 7.1.4 of the CPS. **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** – In CPS section 4.2.2, GlobalSign states, “GlobalSign does not issue publicly trusted SSL Certificates to internal server name or reserved IP addresses.” **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](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices) and [MRSP § 3.3.1](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses)) 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).] **Meh** – The process descriptions for validation could be a little more detailed. Most uses of Random Values are limited to 30 days or the reuse period. Also: Is the limitation to just TXT records in CPS section 3.2.7.1.5 intentional? BR section 3.2.2.4.7 allows not just TXT but also CNAME and CAA records. BR section 3.2.2.4.13 references RFC 8659, Section 3 not RFC 6844 Section 4, as amended by Errata 5065. BR section 3.2.2.4.18 references the “/.well-known/pki-validation” directory, not the “/well-known/pki-validation” directory. How does GlobalSign determine what is an Authorization Domain Name and ensure that its validation method hasn’t erroneously approved subdomains or wildcard certificates? Only 7 methods are listed, not 11. **CA validates domain part of all e-mail addresses** ([MRSP § 2.2.2](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices)) “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.” **Bad –** Similar to the comment above regarding SSL/TLS server certificates, I did not see where delegation of the domain portion of an email address to a third party was prohibited. Section 3.2.8 also references 11 methods of domain validation. **Email Validation Process** **Good** – Section 3.2.8 of the CPS describes a process whereby the Applicant demonstrates email address control when GlobalSign sends a “Random Value to the requested email address and then receiv[es] a confirming response utilizing the Random Value” **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.” **OK** – Section 3.2.2 of the CPS mentions that GlobalSign uses “a third-party database that is periodically updated and has been evaluated by GlobalSign to determine that it is reasonably accurate and reliable”, but the CPS is not otherwise clear on how GlobalSign actually makes that determination. Although the GlobalSign repository contains a list of validation sources, which is good - https://www.globalsign.com/en/repository#jl_magic_tabs_validation_resources_gix8. **All information in a certificate must be verified** ([MRSP § 2.2.1](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices)) “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** – GlobalSign attests that it complies with CA/Browser Forum requirements. Also, in section 3.2.4 of the CPS, GlobalSign states, “GlobalSign validates all information to be included within the Subject DN of a Certificate except as stated otherwise in this section of the CPS. … Specifically for SSL Certificates and code signing Certificates, GlobalSign maintains an enrollment process which ensures that Applicants cannot add self-reported information to the subject: organizationalUnitName.” **Data reuse (certificate renewal) limited to 825 days** ([MRSP § 2.1.5](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#21-ca-operations)) (BR § 4.2.1) CAs must “verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 825 days or less”. **Good** – Section 4.1.2 of the CPS states, “GlobalSign may use the documents and data provided in Section 3.2 to verify certificate information, or may reuse previous validations themselves, provided that: … (2) On or after March 1, 2018, GlobalSign obtained the data or document from a source specified under Section 3.2 or completed the validation itself no more than 825 days prior to issuing the Certificate.” **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.” **Good** – The processing of CAA records is adequately described in section 4.2.1 of the CPS. **Accounts capable of certificate issuance must have multi-factor authentication** ([MRSP § 2.1.3](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#21-ca-operations)) 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”. **Good** – Section 4.3.1 of the CPS states, “GlobalSign shall ensure it communicates with any RA accounts capable of causing Certificate issuance using multi-factor authentication.” **Pre-issuance linting** ([Recommended Practices](https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Pre-Issuance_Linting)) “It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences” **OK** - The extent to which GlobalSign uses pre-issuance linting is unclear from the CPS. **Revocation in accordance with BR section 4.9.1** ([MRSP § 6.1](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#61-ssl)) (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) **Meh** – The 24-hour Reason #4 appears to be missing: “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);” **SMIME Reasons for Revocation** ([MRSP § 6.2](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#62-smime)) “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 …” **Note** – GlobalSign should be aware of the foregoing requirement, including revocation if it “receives notice or otherwise becomes aware of any circumstance indicating that use of the email address in the certificate is no longer legally permitted.” **CRLs at least every 7 days w/ nextUpdate not more than 10 days** ([MRSP § 6](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation)) **Good** – Section 4.9.7 of the CPS states, “If an End Entity certificate contains a CDP (CRL Distribution Point) then that CRL is updated at least every 7 days … and value of the nextUpdate field is not more than 10 days beyond the value of the thisUpdate field.” **CA must not allow certificate suspension** (BR § 4.9.13) **Meh** – Section 4.9.13 of the CPS says, “Certificate suspension will not be supported for Qualified Certificates.” This sentence should also include SSL/TLS Server Certificates. **OCSP updates every 4 days w/ max. expiration of 10 days** ([MRSP § 6](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation)) **Good** - Section 4.9.10 states, “For the status of Subscriber Certificates: GlobalSign updates information provided via an OCSP at least every four days. OCSP responses from this service will not exceed an expiration time of seven days.” **Provide Mozilla notice immediately upon private CA key compromise** ([MRSP § 7](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#7-root-store-changes)) “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.” **Good** – Section 5.7.1 of the CPS states, “GlobalSign documents business continuity and disaster recovery procedures designed to notify and reasonably protect Application Software Suppliers” (Something similar should be stated in section 5.7.3 concerning notification to Application Software Suppliers in the event of a key compromise. **CA must not generate Subscriber key pairs** ([MRSP § 5.2](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices)) “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.2 states " GlobalSign does not generate Private Keys for publicly trusted SSL Certificates.” **Must meet RSA key requirements** ([MRSP § 5.1](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#51-algorithms)) **Good** – Sections 6.1.5 and 6.1.6 appear to satisfy requirements. **Note,** however, that Section 5.1 of the MRSP states, “Root certificates in our root program, and any certificate which chains up to them, MUST use only algorithms and key sizes from the following set: RSA keys whose modulus size in bits is divisible by 8, and is at least 2048.” **Must meet ECDSA key requirements, P-256 or P-384** ([MRSP § 5.1](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#51-algorithms)) **OK** – Section 6.1.5 states that GlobalSign supports P-521. Note that Section 5.1 of the MRSP states, “Root certificates in our root program, and any certificate which chains up to them, MUST use only algorithms and key sizes from the following set: … ECDSA keys using one of the following curves: P-256, P-384. **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** – Footnote 11 states, “Certificates … issued on or after September 1, 2020 00:00 GMT/UTC will have a maximum validity period of 397 days.” **Network Security** ([MRSP § 2.1.2](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#21-ca-operations)) 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”. **Good** – GlobalSign states that its CPS “conforms” to the CA/Browser Forum’s Network and Certificate System Security Requirements. Network and certificate system security controls appear in sections 5.0, 6.5.1, 6.6.1, 6.6.2, and 6.7 of the CPS. **Serial numbers greater than 64 bits generated by a CSPRNG** ([MRSP § 5.2](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices)) “all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG.” **Good** - Section 7.1.10 of the CPS states, “Each Issuing CA must issue certificates that include a unique (within the context of the Issuer Subject DN and CA certificate serial number) non-sequential Certificate serial number greater than zero (0) containing at least 64 bits of output from a CSPRNG.” **EKUs required in certificates issued after 7-1-2020** ([MRSP § 5.2](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices)) (BR § 7.1.2.3.f) **Meh** - Similar language to that which is in the above requirements could not be found in the CPS. **Use of SHA-1 prohibited** ([MRSP § 5.1.3](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#513-sha-1)) (BR § 7.1.3.2.1) **Good** – Footnote 7 states, “SHA-1 Is used for IntranetSSL Subscriber and subordinate CA Certificates, but they are not chained to publicly trusted roots.” **Any CN must also be in a SAN** (BR § 7.1.4.2.2.a) **Meh** - Language requiring that any name in the Common Name also be in one of the SANs could not be found in the CPS.
Bug 1570724 Comment 12 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
## GlobalSign CPS v. 9.5 Review **Here is a review of the GlobalSign CPS, version 9.5, dated September 30, 2020 https://www.globalsign.com/en/repository/GlobalSign_CPS_v9.5_final.pdf** **CP/CPS structured in accordance with RFC 3647 with no blank sections** ([MRSP § 3.3.5](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses)) (BR § 2.2) **Good** – Confirmed **CP/CPS made available under a Creative Commons License** ([MRSP § 3.3.3](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses)) “CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)” **Good** – no conflicting language **Statement of adherence to BRs and their precedence** ([MRSP § 2.3](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#23-baseline-requirements-conformance)) (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.” **Good** – “If there is any inconsistency between this document and the Requirements above, the Requirements take precedence over this document.” **Separate, EKU-constrained issuing CAs** ([MRSP § 5.3](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#53-intermediate-certificates)) (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** – see CPS section 1.1.1 for listing of TLS and non-TLS root CAs **Clear identification of CAs covered by CP/CPS** ([MRSP § 3.3.6](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses)) “CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.” **OK** – The GlobalSign repository https://www.globalsign.com/en/repository appears to list just one CP and CPS. **Explicit annual revision of CP/CPS w/ table of changes** ([MRSP § 3.3.4](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses)) (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. **OK** Section 1.5.3 states “… CA Governance shall review this CPS at least annually and may make revisions and updates to policies as it sees fit or as required by other circumstances.” Section 2.3 states, “GlobalSign reviews its CP and CPS at least annually and makes appropriate changes so that GlobalSign operation remains accurate, transparent and complies with external requirements listed in the “*Acknowledgements*” section of this document.” While these two sections do not say that GlobalSign re-versions its CPS at least annually, the Document History table indicates that this has been the practice. However, it is advisable / would be helpful to include language such as “GlobalSign reviews and updates its CPS annually and increments the version number and adds a dated entry to the Document History table, even if no other changes are made to the document.” **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.” **Bad** - Section 3.2.7.1 doesn’t appear to prohibit the delegation of domain validation to third parties. It also references “methods 1-11 above for validating Wildcard FQDNs” but only lists nine methods. Otherwise, maybe I missed it, but I looked through the CPS and did not see where delegation of domain validation was otherwise prohibited. **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.” **OK** – GlobalSign provides an email address and adequate instructions in sections 1.5.2 and 4.9.3 of the CPS. **Naming compliant with X.500, RFC5280 and BRs** The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards. **OK** – GlobalSign references X.500, RFC 5280 and the Baseline Requirements for naming in sections 3.1 and 7.1.4 of the CPS. **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** – In CPS section 4.2.2, GlobalSign states, “GlobalSign does not issue publicly trusted SSL Certificates to internal server name or reserved IP addresses.” **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](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices) and [MRSP § 3.3.1](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses)) 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).] **Meh** – The process descriptions for validation could be a little more detailed. Most uses of Random Values are limited to 30 days or the reuse period. Also: Is the limitation to just TXT records in CPS section 3.2.7.1.5 intentional? BR section 3.2.2.4.7 allows not just TXT but also CNAME and CAA records. BR section 3.2.2.4.13 references RFC 8659, Section 3 not RFC 6844 Section 4, as amended by Errata 5065. BR section 3.2.2.4.18 references the “/.well-known/pki-validation” directory, not the “/well-known/pki-validation” directory. How does GlobalSign determine what is an Authorization Domain Name and ensure that its validation method hasn’t erroneously approved subdomains or wildcard certificates? Only 7 methods are listed, not 11. **CA validates domain part of all e-mail addresses** ([MRSP § 2.2.2](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices)) “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.” **Bad –** Similar to the comment above regarding SSL/TLS server certificates, I did not see where delegation of the domain portion of an email address to a third party was prohibited. Section 3.2.8 also references 11 methods of domain validation. **Email Validation Process** **Good** – Section 3.2.8 of the CPS describes a process whereby the Applicant demonstrates email address control when GlobalSign sends a “Random Value to the requested email address and then receiv[es] a confirming response utilizing the Random Value” **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.” **OK** – Section 3.2.2 of the CPS mentions that GlobalSign uses “a third-party database that is periodically updated and has been evaluated by GlobalSign to determine that it is reasonably accurate and reliable”, but the CPS is not otherwise clear on how GlobalSign actually makes that determination. Although the GlobalSign repository contains a list of validation sources, which is good - https://www.globalsign.com/en/repository#jl_magic_tabs_validation_resources_gix8. **All information in a certificate must be verified** ([MRSP § 2.2.1](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#22-validation-practices)) “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** – GlobalSign attests that it complies with CA/Browser Forum requirements. Also, in section 3.2.4 of the CPS, GlobalSign states, “GlobalSign validates all information to be included within the Subject DN of a Certificate except as stated otherwise in this section of the CPS. … Specifically for SSL Certificates and code signing Certificates, GlobalSign maintains an enrollment process which ensures that Applicants cannot add self-reported information to the subject: organizationalUnitName.” **Data reuse (certificate renewal) limited to 825 days** ([MRSP § 2.1.5](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#21-ca-operations)) (BR § 4.2.1) CAs must “verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 825 days or less”. **Good** – Section 4.1.2 of the CPS states, “GlobalSign may use the documents and data provided in Section 3.2 to verify certificate information, or may reuse previous validations themselves, provided that: … (2) On or after March 1, 2018, GlobalSign obtained the data or document from a source specified under Section 3.2 or completed the validation itself no more than 825 days prior to issuing the Certificate.” **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.” **Good** – The processing of CAA records is adequately described in section 4.2.1 of the CPS. **Accounts capable of certificate issuance must have multi-factor authentication** ([MRSP § 2.1.3](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#21-ca-operations)) 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”. **Good** – Section 4.3.1 of the CPS states, “GlobalSign shall ensure it communicates with any RA accounts capable of causing Certificate issuance using multi-factor authentication.” **Pre-issuance linting** ([Recommended Practices](https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Pre-Issuance_Linting)) “It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences” **OK** - The extent to which GlobalSign uses pre-issuance linting is unclear from the CPS. **Revocation in accordance with BR section 4.9.1** ([MRSP § 6.1](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#61-ssl)) (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) **Meh** – The 24-hour Reason #4 appears to be missing: “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);” **SMIME Reasons for Revocation** ([MRSP § 6.2](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#62-smime)) “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 …” **Note** – GlobalSign should be aware of the foregoing requirement, including revocation if it “receives notice or otherwise becomes aware of any circumstance indicating that use of the email address in the certificate is no longer legally permitted.” **CRLs at least every 7 days w/ nextUpdate not more than 10 days** ([MRSP § 6](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation)) **Good** – Section 4.9.7 of the CPS states, “If an End Entity certificate contains a CDP (CRL Distribution Point) then that CRL is updated at least every 7 days … and value of the nextUpdate field is not more than 10 days beyond the value of the thisUpdate field.” **CA must not allow certificate suspension** (BR § 4.9.13) **Meh** – Section 4.9.13 of the CPS says, “Certificate suspension will not be supported for Qualified Certificates.” This sentence should also include SSL/TLS Server Certificates. **OCSP updates every 4 days w/ max. expiration of 10 days** ([MRSP § 6](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation)) **Good** - Section 4.9.10 states, “For the status of Subscriber Certificates: GlobalSign updates information provided via an OCSP at least every four days. OCSP responses from this service will not exceed an expiration time of seven days.” **Provide Mozilla notice immediately upon private CA key compromise** ([MRSP § 7](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#7-root-store-changes)) “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.” **Good** – Section 5.7.1 of the CPS states, “GlobalSign documents business continuity and disaster recovery procedures designed to notify and reasonably protect Application Software Suppliers” (Something similar should be stated in section 5.7.3 concerning notification to Application Software Suppliers in the event of a key compromise. **CA must not generate Subscriber key pairs** ([MRSP § 5.2](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices)) “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.2 states " GlobalSign does not generate Private Keys for publicly trusted SSL Certificates.” **Must meet RSA key requirements** ([MRSP § 5.1](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#51-algorithms)) **Good** – Sections 6.1.5 and 6.1.6 appear to satisfy requirements. **Note,** however, that Section 5.1 of the MRSP states, “Root certificates in our root program, and any certificate which chains up to them, MUST use only algorithms and key sizes from the following set: RSA keys whose modulus size in bits is divisible by 8, and is at least 2048.” **Must meet ECDSA key requirements, P-256 or P-384** ([MRSP § 5.1](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#51-algorithms)) **OK** – Section 6.1.5 states that GlobalSign supports P-521. Note that Section 5.1 of the MRSP states, “Root certificates in our root program, and any certificate which chains up to them, MUST use only algorithms and key sizes from the following set: … ECDSA keys using one of the following curves: P-256, P-384. **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** – Footnote 11 states, “Certificates … issued on or after September 1, 2020 00:00 GMT/UTC will have a maximum validity period of 397 days.” **Network Security** ([MRSP § 2.1.2](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#21-ca-operations)) 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”. **Good** – GlobalSign states that its CPS “conforms” to the CA/Browser Forum’s Network and Certificate System Security Requirements. Network and certificate system security controls appear in sections 5.0, 6.5.1, 6.6.1, 6.6.2, and 6.7 of the CPS. **Serial numbers greater than 64 bits generated by a CSPRNG** ([MRSP § 5.2](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices)) “all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG.” **Good** - Section 7.1.10 of the CPS states, “Each Issuing CA must issue certificates that include a unique (within the context of the Issuer Subject DN and CA certificate serial number) non-sequential Certificate serial number greater than zero (0) containing at least 64 bits of output from a CSPRNG.” **EKUs required in certificates issued after 7-1-2020** ([MRSP § 5.2](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices)) (BR § 7.1.2.3.f) **Meh** - Similar language to that which is in the above requirements could not be found in the CPS. **Use of SHA-1 prohibited** ([MRSP § 5.1.3](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#513-sha-1)) (BR § 7.1.3.2.1) **Good** – Footnote 7 states, “SHA-1 Is used for IntranetSSL Subscriber and subordinate CA Certificates, but they are not chained to publicly trusted roots.” **Any CN must also be in a SAN** (BR § 7.1.4.2.2.a) **Meh** - Language requiring that any name in the Common Name also be in one of the SANs could not be found in the CPS.