1570724 - Add GlobalSign Root Certificates R46/E46

Status: RESOLVED FIXED

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

Description

[Julie Olson]

Attachment: GobalSign BR Self Assessment 07292019.xlsx

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

GlobalSign would like to add two new roots to NSS/Mozilla Root Store. Self-assessment checklist, and a copy of the details provided to CCADB are attached to this bug report.

Comment 1

[Julie Olson]

Attachment: GlobalSign R46-E46 Root Embedding Questionnaire.docx

Comment 2

[Kathleen Wilson]

The link below shows the CA information that has been verified. Search in the page for the word "NEED" to see where further clarification is requested.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000469

In particular, for each root:

1. Provide 3 test websites (valid, expired, revoked) whose EV TLS cert chains up to the root and works as expected. Currently the provided test websites are timing out. You can also see this here: https://crt.sh/test-websites
   Then perform testing when the EV test websites are available
   a) Test with http://certificate.revocationcheck.com/ make sure there aren't any errors.
   b) Perform lint testing for the certs in the CA hierarchy.
   c) Provide successful output from EV Testing as described here https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

2. Add records for the existing intermediate certs to the CCADB as described here:
   https://ccadb.org/cas/intermediates#adding-intermediate-certificate-data

Comment 3

[Julie Olson]

Hi Kathleen,

I have gone through the "NEED"s of the above linked case and your comment and have addressed all of them:

• Intermediate records have been added to both roots
  • https://ccadb.force.com/0011J00001TkR60QAF
  • https://ccadb.force.com/0011J00001TkR4sQAF
• We did revocation checking at http://certificate.revocationcheck.com/ of both Valid test sites, but encountered a bug with OCSP responses. It appears the tool is putting a nonsense serial number in the OCSP GET request but not in the POST. We have confirmed our OCSP settings are configured correctly.
• Lint testing was performed through crt.sh
  • https://crt.sh/?id=1730335161&opt=x509lint
  • https://crt.sh/?id=1730333109&opt=x509lint
• EV tests yielded successful results (screenshots attached)

Please let me know if you need anything else. Thanks!
Julie.

Comment 4

[Julie Olson]

Attachment: E46 EV check.png

Comment 5

[Julie Olson]

Attachment: R46 EV check.png

Comment 6

[Julie Olson]

Hi Kathleen,

I'm curious where this root inclusion request is in your queue?

Thanks!

Comment 7

[Ryan Sleevi]

You can see the queue at https://wiki.mozilla.org/CA/Dashboard

Comment 8

[Ben Wilson]

I ran a test on the two test websites for R46 and E46 and there are revoked CA certificates in the chains. These will need to be fixed before we can proceed.

Comment 9

[Julie Olson]

Hi Ben and Kathleen,

New certificates have been issued to these roots' test pages, please review and apologies for the inconvenience/holding up the show.

I'm attaching proof of successful EV issuance to this ticket.

Comment 10

[Julie Olson]

Attachment: R46 EV check 082720.png

Comment 11

[Julie Olson]

Attachment: E46 EV check 082720.png

Comment 12

[Ben Wilson]

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) (BR § 2.2)

     Good – Confirmed

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)”

     Good – no conflicting language

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

     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) (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)

“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) (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 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).]

     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)

“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)

“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) (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)

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)

“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) (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)

“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)

     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)

     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)

“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)

“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)

     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)

     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)

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)

“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) (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) (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.

Comment 13

[Julie Olson]

Thank you Ben. We are reviewing your comments and will apply any bad/meh items to an upcoming CPS update. Please let me know if any actions are needed from us before we proceed.

Comment 14

[Julie Olson]

Hi Ben,

We have published a new version of our CP/CPS that should address most of your meh/bad comments above. The updated documents can be found in our repository: https://www.globalsign.com/en/repository

Let me know if you have any questions or need anything else. Thanks!

Comment 15

[Ben Wilson]

GlobalSign CPS v. 9.6 Review

Here is a review of the GlobalSign CPS, version 9.6, dated December 29, 2020

https://www.globalsign.com/en/repository/GlobalSign_CPS_v9.6_final.pdf

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.

Fixed. The language at the end of section 3.2.7.1 has been changed. Also, the following language appears in section 1.3.2: "Validation of domain authorization or control, authentication for IP addresses or email addresses included in SSL and S/MIME certificate subject fields is not delegated."

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

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.

Fixed. The following language appears in section 1.3.2: "Validation of domain authorization or control, authentication for IP addresses or email addresses included in SSL and S/MIME certificate subject fields is not delegated."

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)

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);”

Fixed. Section 4.9.1 now has a subsection 4: "GlobalSign 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)

“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.”

Fixed. Subsection 13 in section 4.9.1 now reads, "GlobalSign receives notice or otherwise becomes aware of any circumstance indicating that use of the email address in the Certificate is no longer legally permitted;"

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.

Fixed. Section 4.9.13 now says, "Certificate suspension is not supported for SSL or Qualified Certificates."

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

Meh - Similar language to that which is in the above requirements could not be found in the CPS.

Fixed. Section 7.1.2 reads, "Subordinate CA and end entity certificates include an Extended Key Usage extension containing KeyPurposeId(s) describing the intended usage(s) of the certificate. The KeyPurposeId anyExtendedKeyUsage is not included in publicly trusted certificates."

Comment 16

[Ben Wilson]

Discussion period announced on the m.d.s.p. list - https://groups.google.com/g/mozilla.dev.security.policy/c/Lq0WgPiQJPk
Scheduled to close on 2-2-2021.

Comment 17

[Kathleen Wilson]

Ben closed the discussion yesterday and stated Mozilla's intent to approve this request.
https://groups.google.com/g/mozilla.dev.security.policy/c/Lq0WgPiQJPk/m/lpZ2X_5aBAAJ

According to Step 10 in https://wiki.mozilla.org/CA/Application_Process#Process_Overview, "After one week, if no further questions or concerns are raised, then a representative of Mozilla may approve the request, by stating so in the bug."

Comment 18

[Rob Stradling]

Kathleen, Ben,
Bug #1690807 seems like it might qualify as a "further concern".

Comment 19

[Ben Wilson]

Thanks, Rob. That incident does appear to create a further concern that should be mentioned on the m.d.s.p. list.

Comment 20

[Ben Wilson]

GlobalSign has provided a detailed report, and we have had an additional period to gather comments on the mdsp list (https://groups.google.com/g/mozilla.dev.security.policy/c/Lq0WgPiQJPk/m/MAhw-yrKAQAJ). Those discussions having concluded, we should now proceed with the root inclusion process for these four roots. (GlobalSign should address in Bug #1690807 whether the infrastructure for these new roots has similar problems that led to that incident. See https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c8.)

Comment 21

[Kathleen Wilson]

GlobalSign has provided a detailed and informative incident report, and is promptly responding to questions in Bug #1690807, so I agree that we may proceed with this root inclusion request.

Comment 22

[Kathleen Wilson]

As per Comment #17, and on behalf of Mozilla I approve this request from GlobalSign nv-sa to include the following root certificates:

• 'GlobalSign Root R46' (Websites); EV
• 'GlobalSign Root E46' (Websites); EV

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

Comment 23

[Kathleen Wilson]

I have filed bug #1693173 against NSS and bug #1693175 against PSM for the actual changes.