Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ben Wilson via dev-security-policy]

This is to announce the beginning of the public discussion phase of the
Mozilla root CA inclusion process for GlobalSign.

See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
(Steps 4 through 9).

GlobalSign has four (4) new roots to include in the root store.  Two roots,
one RSA and another ECC, are to support server authentication (Bugzilla Bug
# 1570724 ) while two
other roots are for email authentication, RSA and ECC (Bugzilla Bug #
1637269 ).

Mozilla is considering approving GlobalSign’s request(s). This email begins
the 3-week comment period, after which, if no concerns are raised, we will
close the discussion and the request may proceed to the approval phase
(Step 10).

*A Summary of Information Gathered and Verified appears here in these two
CCADB cases:*

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

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

*Root Certificate Information:*

*GlobalSign Root R46 *

crt.sh -
https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9

Download - https://secure.globalsign.com/cacert/rootr46.crt

*GlobalSign Root E46*

crt.sh -
https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058

Download - https://secure.globalsign.com/cacert/roote46.crt

*GlobalSign Secure Mail Root R45 *

crt.sh -
https://crt.sh/?q=319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974

Download - https://secure.globalsign.com/cacert/smimerootr45.crt

*GlobalSign Secure Mail Root E45 *

crt.sh -
https://crt.sh/?q=5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19

Download - https://secure.globalsign.com/cacert/smimeroote45.crt


*CP/CPS:*

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

The current GlobalSign CPS is version 9.6, published 29-December-2020.

Repository location: https://www.globalsign.com/en/repository

*BR Self-Assessment* (Excel) is located here:

https://bugzilla.mozilla.org/attachment.cgi?id=9082310

*Audits:*  GlobalSign is audited annually in accordance with the WebTrust
criteria by Ernst & Young, Belgium, which found in June 2020 that
“throughout the period April 1, 2019 to March 31, 2020, GlobalSign
management’s assertion, as referred to above, is fairly stated, in all
material respects, in accordance with the WebTrust Principles and Criteria
for Certification Authorities - SSL Baseline with Network Security, Version
2.3.”  The WebTrust audit noted the following 13 Bugzilla incidents, which
had been previously reported as of that audit date:

1 Misissuance of QWAC certificates.

2 Issue with an OCSP responder status.

3 Some SSL certificates with US country code and invalid State/Prov have
been issued.

4 ICAs in CCADB, without EKU extension are listed in WTCA report but not in
WTBR report.

5 OCSP responders found to respond signed by the default CA when passed an
invalid issuer in request.

6 Wrong business category on 3 EV SSL certificates.

7 OCSP Responder returned invalid values for some precertificates.

8 Customer running an on-premise (technically-constrained) CA that chains
to a GlobalSign root, issued certificates without AIA extension.

9 Misissued 4 certificates with invalid CN.

10 Certificates with Subject Public Key Info lacking the explicit NULL
parameter.

11 Untimely revocation of TLS certificate after submission of private key
compromise.

12 Unable to revoke 2 noncompliant QWACs within 5 days.

13 Unable to revoke noncompliant ICA within 7 days



*Incident Reports / Mis-Issuances *

The following bugs/incidents remain open and are being worked on.

1667944 

Empty SingleExtension in OCSP responses


1651447 

Failure to revoke noncompliant ICA within 7 days


1591005 

ICAs in CCADB, without EKU extension are listed in WTCA report but not in
WTBR report 

1649937 

Incorrect OCSP Delegated Responder Certificate


1668007 

Invalid stateOrProvinceName value


1664328 

SHA-256 hash algorithm used with ECC P-384 key


1575880 

SSL Certificates with US country code and invalid State/Prov

Re: Policy 2.7.1: MRSP Issue #218: Clarify CRL requirements for End Entity Certificates

[Ryan Hurst via dev-security-policy]

On Thursday, January 7, 2021 at 5:00:46 PM UTC-8, Ben Wilson wrote:
> This is the last issue that I have marked for discussion in relation to 
> version 2.7.1 of the Mozilla Root Store Policy 
> .
>  
> It is identified and discussed in GitHub Issue #218 
>  for the MRSP. 
> 
> I will soon update everyone on the status of the other 13 discussion items 
> already presented, as some of them are in need of revision based on 
> comments received thus far. 
> 
> While subsection (b) of section 7.1.2.3 of the Baseline Requirements makes 
> a cRLDistributionPoint (CDP) in end entity certificates optional, Mozilla 
> still desires that CRL-based revocation information be available because 
> CRLite uses CRLs to construct its revocation filters. (Apple also uses 
> such CRL information in its certificate validation processes and, as I 
> understand, is making a similar request of CAs with respect to the new 
> CCADB field, discussed below.) 
> 
> While all such CRL information is needed, large CRLs are disfavored because 
> of the time they take to download and process. Thus, CAs shard, partition, 
> or "scope" their CRLs into smaller chunks. Section 5 of RFC 5280 explains, 
> "Each CRL has a particular scope. The CRL scope is the set of certificates 
> that could appear on a given CRL. … A complete CRL lists all unexpired 
> certificates, within its scope, that have been revoked for one of the 
> revocation reasons covered by the CRL scope. A *full and complete CRL* 
> lists all unexpired certificates issued by a CA that have been revoked for 
> any reason." (Emphasis added.) 
> 
> There is a new field in the CCADB for CAs to include information needed for 
> browsers or others to construct a "full and complete CRL", i.e. to gather 
> information from CAs that don't include the CRL path to their "full and 
> complete CRL" in end entity certificates they issue. This new CCADB field 
> is called "Full CRL Issued By This CA" and is located under the heading 
> "Pertaining to Certificates Issued by this CA." Rather than condition the 
> requirement that CAs fill in this information in the CCADB only when they 
> don't include a CDP to a full and complete CRL, I propose that this new 
> CCADB field be populated in all situations where the CA is enabled for 
> server certificate issuance. In cases where the CA shards or partitions its 
> CRL, the CA must provide a JSON-based list of CRLs that when combined are 
> the equivalent of the full and complete CRL. 
> 
> Proposed language to add to section 6 of the Mozilla Root Store Policy is 
> as follows: 
> 
> *CAs SHOULD place the URL for the associated CRL within the 
> crlDistributionPoints extension of issued certificates. A CA MAY omit the 
> crlDistributionPoint extension, if permitted by applicable requirements and 
> policies, such as the Baseline Requirements. * 
> 
> *A CA technically capable of issuing server certificates MUST ensure that 
> the CCADB field "Full CRL Issued By This CA" contains either the URL for 
> the full and complete CRL or the URL for the JSON file containing all URLs 
> for CRLs that when combined are the equivalent of the full and complete CRL* 
> . 
> 
> 
> I look forward to your comments and suggestions. 
> 
> Ben
I think this text strikes a good balance.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy