Closed Bug 1528369 Opened 5 years ago Closed 3 years ago

Add SecureTrust Root Certificates

Categories

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

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: fcorday, Assigned: kwilson)

References

Details

(Whiteboard: [ca-approved] - In NSS 3.57, FF 82; EV-enabled in FF 84)

Attachments

(2 files)

338.55 KB, application/pdf
Details
40.10 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details

Root inclusion information supplied in CCADB root inclusion case.

The information for this request is here:

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

Frank, Thank you for using the new process to file your root inclusion request. I will review it as soon as possible. (I returned from vacation today.)

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

Frank, Please add a comment to this bug when you are ready for me to review your updated root inclusion request data.

Whiteboard: [ca-verifying] → [ca-verifying] - KW 2019-04-01 - Comment #2

(In reply to fcorday from comment #3)

Kathleen,
We expect to have all documents and information in place 3 weeks from today. Thank you for all your help.

This request is to include the following 3 root certificates, and for all of them enable the email (S/MIME) and websites (TLS) trust bits and also enable EV treatment.

  • Trustwave Global Certification Authority
  • Trustwave Global ECC P256 Certification Authority
  • Trustwave Global ECC P384 Certification Authority

This CA already has the following root certificates included in Mozilla's root store:

  • Secure Global CA (Email; Websites) EV
  • SecureTrust CA (Websites) EV
  • XRamp Global Certification Authority (Email; Websites) EV

The details about this root inclusion request are here:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000392

Frank, Please search for the word "NEED" in the document above to see where further information or action is requested.

In particular, for each of the new root certs:

  1. Explain why this root cert needs to be included in the root store, rather than being signed by another CA’s root certificate that is already included.
    Explain the unique function of this root, especially if requesting inclusion of multiple roots.

  2. Enter the existing intermediate certificates for this root into the CCADB, as per
    https://ccadb.org/cas/intermediates

Please add a comment to this bug when both items have been completed.

Whiteboard: [ca-verifying] - KW 2019-04-01 - Comment #2 → [ca-verifying] - KW 2019-05-15 - Comment #7

Hello Kathleen,

The items you requested are completed.

The information for this root inclusion request is available at the following URL.

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

This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

There is a queue waiting for detailed CP/CPS reviews:

https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review

It takes significant time and concentration to do a detailed CP/CPS review, so please be patient. In the meantime, I recommend looking at the results of the detailed CP/CPS reviews that have been previously completed.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21

Assignee: kwilson → wthayer
Whiteboard: [ca-verifying] - KW 2019-05-15 - Comment #7 → [ca-cps-review] - KW 2019-05-17
Assignee: wthayer → bwilson

Here are my comments based on a review of the SecureTrust CP/CPS v. 6.1 published 18-March-2020

https://certs.securetrust.com/CA/SecureTrustCPS_61.pdf

Section 1

The name for the EV Guidelines is “Guidelines for the Issuance and Management of Extended Validation Certificates”, and the “Minimum Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates” has been renamed to the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates”. (#17 in section 1.6.3 needs to be updated, too.)

1.2.1

Revisions table – good

1.3.1

In several places throughout the CP/CPS it refers to “a SecureTrust CA”, “SecureTrust CAs”, or “any SecureTrust CA”. It is confusing to reference the CA operator as “SecureTrust CA” e.g. “The only Certification Authority specifically governed by this document is the SecureTrust CA” when the CN for one of the CAs is “SecureTrust CA” and there are other CA certificates. I would suggest that you go through the document and replace the “SecureTrust CA” with simply “SecureTrust” or something else.

1.3.2

Good statements about non-delegation of domain validation, but note that SecureTrust must also validate the domain part of all email addresses in accordance with Mozilla Root Store Policy section 2.2.2.

1.4.2

Consider adding language that certificates may not be used for illegal interception or decryption of encrypted communications (MITM), deep packet inspection, etc.

1.5.2

Notice required by BR 4.9.3 should say that “Subscribers, Relying Parties, Application Software Suppliers, and other third parties shall contact SecureTrust using the email address above to report suspected Private Key Compromise, Certificate misuse, ….”

1.5.4

You might want to state that the CPS is revised annually, even if there are no changes. E.g. “The CA Operational Committee performs a complete CP/CPS review at least on an annual basis, and the CPS is updated annually, even if there are no substantive changes.” This could also go in section 2.3.

1.6

CICA has been renamed CPA Canada. In the US, CPA standards for Certified Public Accountant. In Canada it means Chartered Professional Accountant. The AICPA is no longer a participant in WebTrust.

2.2

Good list of test websites

3.1

Naming should also comply with RFC 5280 and CA/Browser Forum requirements (BRs, EVGs). Also, it might be good to state that SecureTrust does not issue certificates with internal names, in accordance with BR 4.2.2.

3.1.1.2.5

Should refer to the “Common” Name

3.2.2.4.13

Keep an eye on the corresponding BR requirement because RFC 6844 has been superseded by RFC 8659.

3.2.2.8

This section is good in that it contains the information required by section 2.2 of the Baseline Requirements. However, section 2.2 of the BRs states, “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 ….”

3.2.3.4

Good explanation of challenge-response method of confirming email address

4.1.2.1

Section states that one person may be authorized to fill all three roles, except 4 roles are described.

4.2.1.1

The word “than” is more appropriate than “then” in “organizational information may be validated in a different fashion and at a different time then the domain name information.”

4.3.1

Does SecureTrust perform any pre-issuance linting? https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Pre-Issuance_Linting

4.4.2

The use of the words “may not” in this sentence is ambiguous - “Issued certificates not included in Google’s Certificate Transparency mandate may not be published in global directories.” Does it mean that they are not, will not, or shall not be published? Also, which global directories are meant here?

4.9.1.1.

Good because it includes reasons and timelines from section 4.9.1.1 of the Baseline Requirements

For SMIME certificates, consider adding this reason from Mozilla Root Store Policy section 6.2.2 “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” https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#62-smime

4.9.1.2

Good because it includes reasons and timelines from section 4.9.1.2 of the Baseline Requirements

4.9.3

Good explanation of revocation process

4.9.5

Consider adding language to make revocation more certain in case of key compromise and other reasons 1-4 of section 4.9.1.1. As currently written, this language: “SecureTrust will decide whether revocation or other appropriate action is warranted … 1. The nature of the alleged problem;” might lead SecureTrust to violate section 4.9.1.1 of the Baseline Requirements.

4.9.6

Section says “revoked or suspended,” but section 4.9.13 says that suspension won’t happen, so you should delete “or suspended”.

4.9.7

Section 6 of the Mozilla Root Store Policy (Revocation) https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation applies equally to CAs issuing SMIME certificates.

4.9.8

Maximum latency of 24 hours is too long for a CRL that is issued every 24 hours.

5.4.8

Good language concerning annual risk assessments, quarterly vulnerability scanning, and annual penetration testing.

5.7.1-5.7.4 and 5.8

Under what circumstances will SecureTrust notify Mozilla and other Application Software Vendors? Also, throughout the CP/CPS SecureTrust should be consistent with the term “Application Software Vendor” (sometimes it says “Application Software Supplier”).

6.1

Why does this section discuss key compromise? Shouldn’t this language be in section 5.7.3?

6.1.1.1 and 6.2.6 (and 5.5.2)

Although this isn’t yet a written requirement, CA Key Ceremony records should be kept for as long as the CA is valid (not expired or revoked), and not just 7 years. Mozilla wants assurance that “CA certificates have continually, from the time of creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements.” See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Complete_Audit_History . At some point, I expect that this will become a stated requirement.

6.1.5

Mozilla Policy 5.1 states that the modulus size in bits must be divisible by 8, and at least 2048. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#51-algorithms

6.1.7

The “nonRepudiation” bit is a keyUsage bit, not an EKU.

6.4

I think it should be “m out of n”

6.5.1

Good – Mozilla requires that accounts capable of causing certificate issuance require multi-factor authentication

7.1.2.2

EKU is not optional for subordinate CAs created after January 1, 2019 https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#53-intermediate-certificates

7.2

“CAs MAY sign SHA-1 hashes over CRLs for roots and intermediates only if they have issued SHA-1 certificates.”

9.6.2

Subsection 2 of section 9.6.2 should probably say that RAs warrant that “2. there are no errors in the information within the Certificates caused by their failure to exercise reasonable care in performing their RA duties or functions.”

9.8

Section 18 of the EV Guidelines says that a CA may not “limit its liability to Subscribers or Relying Parties for legally recognized and provable claims to a monetary amount less than two thousand US dollars per Subscriber or Relying Party per EV Certificate.” Section 9.8 of the CP/CPS says, “IN NO EVENT SHALL THE CUMULATIVE OR AGGREGATE LIABILITY OF TRUSTWAVE TO ANY PARTY … EXCEED TWO THOUSAND U.S. DOLLARS ($2,000.00 USD).” The SecureTrust language states the opposite of the EVGs and does not meet the requirements of section 18.

9.10.2

There is a typo - “replace” should be “replaced”. “This CPS and the CPs, as may be amended from time to time, are effective until replaced by a new version, which shall be published in SecureTrust’s Repository.”

Whiteboard: [ca-cps-review] - KW 2019-05-17 → [ca-cps-review] - Pending CA Response to Comment 10

I have reviewed the audit history for these three roots and determined that there is complete continuity -- all three roots have been included continuously in WebTrust Standard, BR and EV audits since CA generation.

Minor issues were found by BDO International, Ltd., as part of the 2019 Baseline Requirements audit.[1] These issues have already been addressed in [2], which is closed.

I ran misissuance reports with linting to look for issuance errors and didn’t find any linting errors below these three roots.

I also reviewed the Incident Dashboard [3] and didn’t see any open issues for SecureTrust.

On the list of Closed Incidents [4] there were only three closed incidents besides the one mentioned above [2] -- [5], [6], and [7].

I believe that this matter is ready for public discussion, pending response from SecureTrust on the CP/CPS comments made in Comment #10.

[1] https://certs.securetrust.com/CA/2%20-%20SecureTrust%202019%20SSL%20BL%20Report.pdf
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1606031
[3] https://wiki.mozilla.org/CA/Incident_Dashboard
[4] https://wiki.mozilla.org/CA/Closed_Incidents
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1546776
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1551374
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1600844

Ben, thank you for the thorough CPS review. We will evaluate your feedback and provide a response within the next two weeks.

We have reviewed Ben’s comments on the CPS review and are currently in the process of incorporating this feedback into the next version of our CPS to state our compliance more clearly with the Baseline Requirements and Mozilla Root Policy. Our current practices and operations are in alignment with the Baseline Requirements and Mozilla Root Policy, but as Ben noted, there are several areas for improvement where we can better clarify this in the CPS. We expect to have this next version finalized, approved, and published to our Repository in early July. We would like to request that the public discussion phase begin after the new CPS is published.

There were several items in the feedback that we did not incorporate directly into the next version of our CPS, but rather we note them here in the event there is further discussion:

4.3.1
While we have an industry-standard linting tool integrated into the issuance pipeline of one of our testing environments for pre-issuance linting and have an extensive suite of pre-issuance tests that verify the technical correctness of the field values to be embedded in the certificate implemented in production, we do not currently have pre-issuance linting using an industry-standard tool implemented in production. We recognize the value of integrating such tooling into our production issuance pipeline as additional assurance of our compliance to the relevant standards and requirements. Therefore, we currently have work planned for later this quarter to start implementing our pre-issuance linting solution. We anticipate that we will have at least one industry-standard linting tool integrated into our production issuance pipeline as a pre-issuance check in Q3 of this calendar year.

5.7.1-5.7.4 and 5.8
We have replaced “Application Software Vendor” with the Baseline Requirements Defined Term of “Application Software Supplier”.

6.4
We went back and forth on this term internally and decided upon using “n out of m”, as the section name for 6.2.2 as defined in RFC 3647 uses “n out of m”. We will change it if Mozilla feels strongly about using the term “m out of n”.

9.8
We believe our current language complies with the minimum liability limits specified in EVG Section 18, as a value of $2,000 would satisfy both the liability limit in our CPS and EVG Section 18.

We have recently published v6.2 of our CP/CPS to our Repository: https://certs.securetrust.com/CA/SecureTrustCPS_62.pdf, which addresses Ben's comments above.

Absent any concerns from Mozilla on this updated CPS, we would like to proceed with the root inclusion request.

I am going to provide notice of 3-week public discussion today.

Whiteboard: [ca-cps-review] - Pending CA Response to Comment 10 → [ca-in-discussion] - 2020-08-03

I just sent notice on the m.d.s.p. list that the 3-week public discussion period closed yesterday and asked again if there were any objections to the intent to approve this request. I'll change the status of this request tomorrow here and in the CCADB if we don't receive any further comments.

Hi Kathleen,
The three-week public discussion period for this request to include the three SecureTrust CAs concluded this past week without comment.
I published a notice of intent to approve on mdsp, https://groups.google.com/g/mozilla.dev.security.policy/c/lc6P-6LUM8w/m/m9nIxdQ7CQAJ, in which I stated, "I intend to recommend that this request be approved..."
I hereby recommend that we include the requested roots in the Mozilla root store with the email (S/MIME) and websites (TLS) trust bits enabled and also enablement for EV.
Thanks,
Ben

Flags: needinfo?(kwilson)
Whiteboard: [ca-in-discussion] - 2020-08-03 → [ca-approved]
Flags: needinfo?(kwilson)
Whiteboard: [ca-approved] → [ca-pending-approval] - 2020-08-28

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

** 'Trustwave Global Certification Authority' (Email, Websites), enable EV
** 'Trustwave Global ECC P256 Certification Authority' (Email, Websites), enable EV
** 'Trustwave Global ECC P384 Certification Authority' (Email, Websites), enable EV

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

Assignee: bwilson → kwilson
Whiteboard: [ca-pending-approval] - 2020-08-28 → [ca-approved] - pending inclusion and EV
Depends on: 1663049
Depends on: 1663052

I have filed bug #1663049 against NSS and bug #1663052 against PSM for the actual changes.

Whiteboard: [ca-approved] - pending inclusion and EV → [ca-approved] - In NSS 3.57, FF 82; Pending EV treatment
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Whiteboard: [ca-approved] - In NSS 3.57, FF 82; Pending EV treatment → [ca-approved] - In NSS 3.57, FF 82; EV-enabled in FF 84
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: