Closed Bug 1454977 Opened 6 years ago Closed 10 months ago

Add ACIN Global Trusted Sign root certificate

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: info, Assigned: bwilson)

Details

(Whiteboard: [ca-initial])

Attachments

(23 files, 4 obsolete files)

I1002_v2_EN_Audit letter eIDAS_SSL.PDF
750.02 KB, application/pdf
Details
ACIN_CA's BR Self Assessment_Final_ENG.xlsx
39.28 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
EN I994 - Verificação PAC_W_Julho 2019 Rev 1.1-1.pdf
225.65 KB, application/pdf
Details
I994 - Verificação PAC_W_Julho 2019 Rev 1.1.pdf
361.95 KB, application/pdf
Details
I1002_v2_EN_Audit letter eIDAS_SSL_10_2019.pdf
198.52 KB, application/pdf
Details
I1002_v3_EN_Audit letter eIDAS_SSL_ACIN_Jan2020.pdf
186.08 KB, application/pdf
Details
ACIN TSP_Request.pdf
935.66 KB, application/pdf
Details
ACIN - iCloud Solutions Lda-eIDAS-RECERTA-AR-24072020_CF_NCRSolvedSigned.pdf
2.90 MB, application/pdf
Details
AAL_10999698_2020_01-Rev. 03_test-btw2.pdf
390.10 KB, application/pdf
Details
AAL_10999698_2020_01-Rev. 03_test-2.pdf
272.83 KB, application/pdf
Details
AAL_10999698_2020_01-Rev. 03_test_v03.pdf
272.30 KB, application/pdf
Details
DP01_GTS_V11 - GTS ROOT Certification Practice Statement.pdf
945.42 KB, application/pdf
Details
DP02_GTS_V11 - GTS CA Certification Practice Statement.pdf
977.47 KB, application/pdf
Details
DP03_GTS_V11 - GTS TSA Certification Practice Statement.pdf
969.64 KB, application/pdf
Details
FO13_GTS_V4-Request Verification Checklist for Registry Administrators.pdf
92.14 KB, application/pdf
Details
FO58_GTS_V1 - List of Reliable Data Source for OV and EV.xlsx
17.09 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
PC03_GTS_03 - Issuance Process of Certificates for Website Authentication.pdf
303.11 KB, application/pdf
Details
PL03_GTS_V8 - EV SSL Certificate Policy.pdf
1.10 MB, application/pdf
Details
PL04_GTS_V8 - OV SSL Certificate Policy.pdf
686.16 KB, application/pdf
Details
GTS_Check-list_Corrections.xlsx
26.34 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
Check-list_Corrections_Final.xlsx
35.20 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
AAL_10999698_2021_01-Rev.00.pdf
274.43 KB, application/pdf
Details
ACIN iCloud Solutions Lda-eIDAS-SURV1_1-AR-27072021_CF_Signed.pdf
2.93 MB, application/pdf
Details 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160823121617

Steps to reproduce:

We have implemented a new PKI with own Root and SubCA


Actual results:

In August 2017 we have been audited by APCER and GNS and have been sucessfully certified.
At this moment we are already in the UE Trusted List - https://webgate.ec.europa.eu/tl-browser/#/tl/PT/0


Expected results:

To have our root included as recognize in your browser.
Acknowledging receipt of this root inclusion request. I have a huge backlog of CA updates/requests to review, so this has been added to my list. I will update this bug when I begin information verification of this request as per step #2 of our process:
https://wiki.mozilla.org/CA/Application_Process#Process_Overview

In the meantime, please attach your completed BR Self Assessment to this bug.
https://wiki.mozilla.org/CA/BR_Self-Assessment

And provide all of the information listed here:
https://wiki.mozilla.org/CA/Information_Checklist
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-verifying] - Need BR Self Assessment

The status of this request is that we are waiting for the representative of the CA to provide the required information.
https://wiki.mozilla.org/CA/Information_Checklist#Example_and_Template

QA Contact: kwilson

As requested the br requirements assessment is attached.

I am not finding this CA in the Common CA Database (CCADB), so please fill out the Application for CCADB Access form here:
https://ccadb.org/cas/request-access#application-for-ccadb-access

Whiteboard: [ca-verifying] - Need BR Self Assessment → [ca-verifying] - CA is new to CCADB

Thank you for filling in the CCADB Access form. You will receive email when the CCADB CA Community License is issued to you.

Then please create a Root Inclusion Case in the CCADB as described here:
https://wiki.mozilla.org/CA/Information_Checklist#Create_a_Root_Inclusion_Case

Hi
We submit the form in the 11-06 but until now we haven´t receive a confirmation submission or the License. The license takes how long ? should we submit the form again , just in case?
Best regards.

It appears that a license for this user was created on the same day. I just sent a password reset email - please check your bulk mail folder.

We just submitted the Root Inclusion Case as requested.

Hi ,
We just noticed that our audit letter is coming to and end, and we already ask APCER to send us a new one. We have the renew process that we attach here but it is in english, can we submit to CCAB the original audit letter in portuguese and a translated payper, our we need to wait until the new audit letter arraived to submit ??

The link below shows the CA information that needs to be provided and 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=00000463

To start with:

  1. NEED: Full audit history for both root certificates. All audit statements must list the SHA256 thumbprints for all of the root and intermediate certificates that were in scope of the audit, and must meet the requirements of Mozilla's Root Store Policy
    NEED: All audit statements must meet the requirements of sections 3.1.3 and 3.1.4 of Mozilla's Root Store Policy:
    https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

  2. NEED: Documents to be taken into consideration must be provided in English and as PDF.
    This CP URL does not seem to work:
    https://pki.globaltrustedsign.com/index.php/home_c/download/PL11_EN
    NEED DP02 in English
    https://pki.globaltrustedsign.com/index.php/home_c/download/DP02

  3. CP/CPS Structured According to RFC 3647
    NEED: CP/CPS documents must be structured according to RFC 3647. This requirement is stated in section 2.2 of the CA/Browser Forum Baseline Requirements, with the effective of 31 May 2018.
    https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647
    CAA Domains listed in CP/CPS: NEED: CA's Certificate Policy and/or Certification Practice Statement ... shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA "issue" or "issuewild" records as permitting it to issue.
    https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CAA_Domains_listed_in_CP.2FCPS
    Long-lived Certificates: 1 to 3 years, it will be revised as soon as possible.
    NEED: https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Long-lived_Certificates
    Non-Standard Email Address Prefixes for Domain Ownership Validation: This will be revised to explicity and added to DP02 13.3
    NEED: https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Non-Standard_Email_Address_Prefixes_for_Domain_Ownership_Validation

  4. NEED: Add existing intermediate certificates to the CCADB, as described here:
    https://www.ccadb.org/cas/intermediates#adding-intermediate-certificate-data

  5. NEED: URLs to the three test websites (valid, revoked, expired) whose TLS certs chain up to this root certificate. This is required per section 2.2 of the CA/Browser Forum Baseline Requirements. NEED: If you are requesting EV treatment, then the TLS cert for each test website must be EV.
    NEED: Test with http://certificate.revocationcheck.com/ make sure there aren't any errors.
    NEED: If EV treatment is being requested, then provide successful output from EV Testing as described here https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Whiteboard: [ca-verifying] - CA is new to CCADB → [ca-verifying] - KW 2019-09-17 - Comment #12
Summary: Add Global Trusted Sign root certificate → Add ACIN Global Trusted Sign root certificate

Hi
We are still waiting for the APCER issues the new audit statements as soon as we received we will sended to you.
In the CCAB we already submited the PEM info about the Root certificate and the SUbCA certificate, you can check the certificates using the following URL´s :
https://pki.globaltrustedsign.com/index.php/home_c/download/ROOT
https://pki.globaltrustedsign.com/index.php/home_c/download/SUBCA

CP/CPS
https://pki.globaltrustedsign.com/index.php/home_c/download/PL11
https://pki.globaltrustedsign.com/index.php/home_c/download/DP02

We will be updating the topic as soon as we have the other information requested.

Best Regards.

(In reply to GTS from comment #13)

In the CCAB we already submited the PEM info about the Root certificate and the SUbCA certificate, you can check the certificates using the following URL´s :
https://pki.globaltrustedsign.com/index.php/home_c/download/ROOT
https://pki.globaltrustedsign.com/index.php/home_c/download/SUBCA

I see...

This request is for the inclusion of the "Global Trusted Sign Root Certification Authority 01" root certificate which has one subordinate CA, "Global Trusted Sign Certification Authority 01".

I will move the information for the subordinate CA to an intermediate certificate record in the CCADB, and then I will delete the extra root case that had been created with the subCA information.

We will be updating the topic as soon as we have the other information requested.

Please add a comment to this bug when all of the information requested in Comment #12 has been provided.

Whiteboard: [ca-verifying] - KW 2019-09-17 - Comment #12 → [ca-verifying] - KW 2019-10-14 - Comment #14

Hi,
we send you the document that was missing from the original request.
If you need more information, please contact us

Regards

(In reply to GTS from comment #15)

Created attachment 9104912 [details]
I1002_v2_EN_Audit letter eIDAS_SSL_10_2019.pdf

This audit statement appears to only be for the subordinate CA, and does not appear to meet Mozilla's requirements.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#31-audits

We need the full history of audit statements for the root and intermediate cert, as per
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Complete_Audit_History

And those audit statements must contain the information listed here:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#314-public-audit-information

we send you the document that was missing from the original request.
If you need more information, please contact us

Please add a comment to this bug to reply to all of the items listed in Comment #12.

Also note that I ran some tests:

Revocation Tested: https://certificate.revocationcheck.com/gtsvalid.pt
http://ocsp.globaltrustedsign.com/ (GET)
Unexpected HTTP response: 400
ERROR: OCSP signing certificate does not contain the OCSP No Check extension
ERROR: Content-Type in response is not set to 'application/ocsp-response' but to 'application/ocsp-response;charset=UTF8'

Lint Tested: I ran https://crt.sh/lintcert on the SSL cert for https://gtsvalid.pt/ which resulted in these errors:
cablint ERROR BR certificates with CRL Distribution Point must include HTTP URL
zlint ERROR Subscriber certificate cRLDistributionPoints extension must contain the HTTP URL of the CA’s CRL service
The CRL URL in the cert is https://pki.globaltrustedsign.com/subca/gts_subca_crl.crl but section 7.1.2.3 of the BRs require it to be http and not https.

EV Tested: https://tls-observatory.services.mozilla.com/static/ev-checker.html
https://gtsvalid.pt/
1.3.6.1.4.1.50302.1.1.2.2.1.0
exit status 1, Stderr: GetFirstEVPolicyForCert failed: SEC_ERROR_EXTENSION_NOT_FOUND This may mean that the specified EV Policy OID was not found in the end-entity certificate.

Whiteboard: [ca-verifying] - KW 2019-10-14 - Comment #14 → [ca-verifying] - KW 2019-11-04 - Comment #16

Comment #12
Hi,
We submitting the new audit letter, for your evaluation.

Best Regards

Hi,
we still waiting for your feedback about the audit letter.
Best Regards.

We have not yet submitted this year's Audit letter because the audit has been postponed to July due to the COVID-19 crisis. Therefore, and in light of this attenuating cricumstance, we ask if it is possible to proceed with the process, and then we will submit the Audit letter after the July audit.

Attached file ACIN TSP_Request.pdf —

Hi,
we are submitting a new audit letter, witch will replace all previous versions. Therefore we ask you to validate the new one for our PKI.
We kindly remind you that we are a trusted european certificate authority, and that we require this approval from Mozilla in order to conduct business.

Hope to hear fromn you soon.

Regards

(In reply to GTS from comment #20)

Created attachment 9159373 [details]
ACIN TSP_Request.pdf

Hi,
we are submitting a new audit letter, witch will replace all previous versions. Therefore we ask you to validate the new one for our PKI.
We kindly remind you that we are a trusted european certificate authority (https://webgate.ec.europa.eu/tl-browser/#/tl/PT/7), and that we require this approval from Mozilla in order to conduct business.

Hope to hear fromn you soon.

Regards

Hi,
we send you this message to know how the all process of our admition is going.

Looking forward to hear from you

regards

Hi,
we send you this message to know how the all process of our admition is going.

Looking forward to hear from you

regards

(In reply to GTS from comment #23)

Hi,
we send you this message to know how all process of our admition is going.

Looking forward to hear from you

regards

Hi,
we send you a message to know how all the process of our admition is going.

Looking forward to hear from you

regards

Hi Ryan,
Thanks for your reply.
we re-read the process of verification again just to be sure that we had submited all the information, and we did. We would like to know what stage the verification is at, to inform our administration.

Once again thank you for your time.
Regards

You are somewhere between Steps 1 and 2 of https://wiki.mozilla.org/CA/Application_Process

Hello again,
Just keeping the thread alive, while waiting for feedback.

Thank you for your time
Best Regards

Requesting information regarding: official company name, whether EV requested, period-of-time audit dates, and 2020 CPS.

Whiteboard: [ca-verifying] - KW 2019-11-04 - Comment #16 → [ca-verifying] - BW 2020-07-30 Comment #30

Still awaiting a response to Comment #30.

The CA's audit letter makes reference to "PL03_GTS_V4 – Website authentication EV Certificates Policy" but there is not a reference to compliance with the CA/B Forum's Extended Validation Guidelines. Do you still intend to pursue EV recognition with us?

Is the name of your company "ACIN-iCloud Solutions, Lda" or "ACIN iCloud Solutions S.A."? There appears to be a mismatch between the record in the CCADB and the audit letter.

The audit dates are not clearly period-of-time dates. In other words, it is currently required that the audit state the period of time (beginning and end) for which the audit covers. This is in addition to when the auditors were actually auditing your CA with onsite visits, which is what appears in the audit letter. Then there is the third date - the date of the audit report. The ALV processing had a difficult time with the date of the audit report. I don't think it appears in the text-readable part of the letter, but is only in the digital signatures of the auditors.
If you or your auditors need additional explanation of what is needed, please let me know and I will provide a more thorough explanation.

Also, we need an updated CPS because Mozilla requires that a new one be published at least every 12 months even if there are no substantive changes.

Flags: needinfo?(info)

Hi,
we changed our repository here´s the new address https://pki.globaltrustedsign.com/.

We currently are fixing somes issues regarding the external audit and extimated to get the new and valid audit letter in october.

As soon we received we will send you, so that can be validaded by mozilla.

Best Regards,

Flags: needinfo?(info)
Assignee: kwilson → bwilson
Attached file AAL_10999698_2020_01-Rev. 01.pdf (obsolete) —

(In reply to Ben Wilson from comment #31)

Hello,
Sorry for the delay.
we submited two documents, the audit letter and the report, we also updated our policies and they are placed in https://pki.globaltrustedsign.com/en.

Thank you for your time.
Best Regards

(In reply to GTS from comment #35)

we submited two documents, the audit letter and the report, we also updated our policies and they are placed in https://pki.globaltrustedsign.com/en.
Which are the relevant policy documents that I should review for SSL/TLS certificate issuance?
I see several that are dated 2020/09/18, but nothing more recent.
Thanks.

(In reply to Ben Wilson from comment #36)
The documents related to the SSL/TLS certificates are "2020/11/05 - Certificate Policies for SSL OV v6.0.0" and "2020/11/05 - Certificate Policies for SSL EV v6.0.0".

Here are the links:
https://pki.globaltrustedsign.com/storage/docs/en/PL04_GTS.pdf
https://pki.globaltrustedsign.com/storage/docs/en/PL03_GTS.pdf

Let us know if you need something else, thanks for your time
Regards

Hello again,
Just keeping the thread alive, while waiting for feedback.

Thank you for your time
Best Regards

Flags: needinfo?(bwilson)

Hello again,
Just keeping the thread alive, while waiting for feedback.

Thank you for your time
Best Regards

Hello again,
Just keeping the thread alive, while waiting for feedback.

Thank you for your time
Best Regards and happy new year

Here are some comments based on my review today:
1 - The certificates for the test websites (gtsvalid.pt and gtsrevoked.pt) have expired (9/20/2020);
2 - The CP/CPS are not in the format required by RFC 3647;
3 - The audit/attestation letter from Bureau Veritas is not downloadable from the Bureau Veritas website; and
4 - The audit/attestation letter also fails the Automated Letter Validation (ALV) processing.

Flags: needinfo?(bwilson)
Attached file AAL_10999698_2020_01-Rev. 01_test.pdf (obsolete) —
Attached file AAL_10999698_2020_01-Rev. 02_test.pdf (obsolete) —

(In reply to Ben Wilson from comment #41)

Here are some comments based on my review today:
1 - The certificates for the test websites (gtsvalid.pt and gtsrevoked.pt) have expired (9/20/2020);
2 - The CP/CPS are not in the format required by RFC 3647;
3 - The audit/attestation letter from Bureau Veritas is not downloadable from the Bureau Veritas website; and
4 - The audit/attestation letter also fails the Automated Letter Validation (ALV) processing.

Hi
We are restructuring our documentation and we already fixed the certificates and our auditor already send you the audit letter.
Can you please tell us if all the documents have do be exatly like the RFC our can we make some changes ?
If you have encountered some erros in the certificates available please tell us , so we can fix them .

best regards

Flags: needinfo?(bwilson)
Flags: needinfo?(bwilson)
Priority: -- → P3

Hello,

Just to inform you that our CP/CPS were updated to the format required and also the test websites were updated as requested.

Regards

The test websites for revoked and expired certificates passed. The valid website certificate did not pass the tests. The error message says "leaf is revoked by OCSP responder http://ocsp.globaltrustedsign.com/". I tried checking the gtsvalid.pt website certificate with certutil, and it gave an OCSP status back of "expired" (I don't know why because I see the certificate is supposed to be valid until Nov. 9, 2021.) I suppose the next step is for me to check it with OpenSSL.

With OpenSSL I get the following response:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = PT, O = "ACIN iCloud Solutions, Lda", OU = Global Trusted Sign, CN = Global Trusted Sign Validation Authority 03
Produced At: May 26 22:07:07 2021 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: E86E86A5A136940EA28F8BA21A153857C913407B
Issuer Key Hash: E6956F012DF97922E70039198815B90A8B45998B
Serial Number: 23FAB67D606227F45FA90C61B10AE49C
Cert Status: good
This Update: May 26 22:07:07 2021 GMT
Next Update: May 26 22:17:07 2021 GMT

When I run https://certificate.revocationcheck.com/gtsvalid.pt I get an error that says, "One of the certificates in this chain could not be checked! " Please check and see if all certificates can be checked or whether they are OCSP responder certificates with a no-check extension.

(In reply to GTS from comment #45)

Hello,

Just to inform you that our CP/CPS were updated to the format required and also the test websites were updated as requested.

Regards

I'm having trouble downloading your CPSes from your website. Could you please provide the URLs to them?

Flags: needinfo?(info)

Hello,

We have updated the links, and you may now find the Issuance and management practices here:

https://pki.globaltrustedsign.com/en

Then click "EC GTS TLS/SSL", and you should find the bottom two links there:

https://pki.globaltrustedsign.com/download/doc/en/DP02_GTS.pdf
https://pki.globaltrustedsign.com/download/doc/en/DP04_GTS.pdf

Thank you for your time, anything else, please let us know.

Flags: needinfo?(info)

ACIN / Global Trusted Sign CP/CPS Review

Review of v. 7 of the GTS Website Authentication Certificate Policy (SSL Organization Validation) https://pki.globaltrustedsign.com/download/doc/en/PL04_GTS.pdf (“OV CP”) and v.7 of the Website Authentication Certificate Policy (SSL Extended Validation) https://pki.globaltrustedsign.com/download/doc/en/PL03_GTS.pdf (“EV CP”)

GTS CA Certification Practice Statement, v.10,

https://pki.globaltrustedsign.com/download/doc/en/DP02_GTS.pdf (“CPS”)

All dated May 6, 2021.

Baseline Requirements / Mozilla Root Store Policy Requirements

CP/CPS structured in accordance with RFC 3647 with no blank sections (MRSP § 3.3.5) (BR § 2.2)

OK – The CPS follows RFC 3647 without any blank sections. However, the two CPs (OV and EV) do not have all section numbers (presumably for things that would not be populated with meaningful text).

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

Adequate – Section 9.5 of the CPS states, “All intellectual property rights, including those referred to issued certificates and CRL, OID, DPC, PC, as well as any other related documents, are property of the GTS CA.” Nothing appears to contradict the license required by Mozilla, but a more permissive license for the use of the CP/CPS would be better.

Statement of adherence to BRs/EVGs and their precedence (MRSP § 2.3) (BR § 2.2 / EVG 8.3)

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

Section 8.3 of the EV Guidelines contains a similar provision – “In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document.”

OK – Section 1.3.1 of the CPS states, “In case of inconsistency between this CPS and these CA / B Forum Requirements, the latter will prevail.” However, it would be even better if there were a specific reference to the EV Guidelines when interpreting the phrase “these CA / B Forum requirements”.

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.

Should be clarified – I did not see a certificate profile or mention of allowed EKUs for issuing CAs. Presumably, the Global Trusted Sign Certification Authority 01 registered in the CCADB would have been an indication of whether or not GTS complies with this requirement, but that CA certificate was issued in 2017 and does not have any EKUs.

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 – The GTS CAs are diagrammed in section 1.3.1 of the 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.

Good – Section 1.5.3 of the CPS states, “The CPS, CPs and PDSs will be reviewed and updated annually.”

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

Should be fixed – Section 1.3.2 of the CPS says, “Global Trusted Sign does not have External Registry Authorities.” However, this needs to be more explicit, including for SMIME certificates. (See below under “CA validates domain part of all e-mail addresses“. In other words, GTS should explicitly say that it does not delegate domain validation to any third parties.

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

Needs to be fixed – Section 1.5.2 of the CPs and the CPS need to alert readers of where and how they can report “suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.”

Naming compliant with X.500, RFC5280, Baseline Requirements and EV Guidelines

The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards.

Needs to be fixed – Section 3.1 of the CPS and CPs discuss naming compliant with X.500 and RFC 5280. The tables in section 3.1 of the CPs show simplified fields for subject naming in OV and EV certificates, however there are complexities with naming for EV certificates. The EV CP should provide more detail how naming is consistent with the CA/Browser Forum’s EV Guidelines. For example, see the section below under the EV guidelines’ analysis titled “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.”

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

Needs to be fixed – I could not find in the CPs or CPS where issuance of certificates for internal or reserved IP addresses or Domain Names is prohibited.

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 by a man-in-the-middle to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]

Needs to be fixed – Please refer to section 3.2.2.4 of the CA/Brower Forum’s Baseline Requirements and explain the validation steps taken to verify a domain name / FQDN.

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

Needs to be fixed – The CPS needs to say that GTS performs a challenge-response verification for email addresses included in SMIME certificates (or at least it will validate the domain part for email addresses included in SMIME certificates issued in the context of an enterprise RA). See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response and https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control

Data sources and QIISes need to be accurate (BR § 3.2.2.7 / EVG § 11.11.5)

“[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.” If the CA intends to issue EV certificates, then the QIIS also needs to be evaluated for its reliability and accuracy. See EVG § 11.11.5.

Needs to be fixed – GTS needs to disclose its process for determining that a third-party validation source is reliable. Section 3.2.2.7 of the Baseline Requirements says, “The CA SHOULD consider the following during its evaluation:

\1. The age of the information provided,

\2. The frequency of updates to the information source,

\3. The data provider and purpose of the data collection,

\4. The public accessibility of the data availability, and

\5. The relative difficulty in falsifying or altering the data.”

Also refer to EVG § 11.11.5.

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

Needs to be fixed – Section 3.2.2 of the OV CP states, “All the information provided by the subscriber is verified.” It should actually say, “all information in the certificate is verified.” Also, according to RFC 3647, this should be found in section 3.2.4, not section 3.2.2.

Data reuse (certificate renewal) limited to 398 and 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”, and “for server certificates issued on or after October 1, 2021, each dNSName or IPAddress in a SAN or commonName MUST have been validated in accordance with section 3.2.2 of the CA/Browser Forum's Baseline Requirements within the prior 398 days.” For EV Certificates, the reuse timeframe is now 398 days instead of 13 months.

Needs clarification – It is unclear whether GTS uses any information collected from previous certificate requests. In several places in the CPS and in the CPs, it says, “[X] follows the procedures of initial identification and authentication” or “The renewal is treated like a new issuance request by the GTS CA.” This implies that all information is collected and verification is re-performed for every single rekeyed or renewed certificate. This needs to be confirmed by GTS.

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

OK – Section 4.2.1 of the CPS says, “In the certificate requests for Website Authentication, GTS also verifies the relevant CAA records when the certificate request is submitted and immediately before the certificate is issued. The CE acts in accordance with the CAA records, should they exist. The identification domain of the GTS CE in the CAA records is globaltrustedsign.com.” Many CAs provide a more detailed explanation of their CAA processing practices. Also note that “CE” is not listed in the table of acronyms in CPS section 1.6.2.

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

Needs to be fixes or called out – I could not find the phrase “multi-factor authentication” in conjunction with “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 – Pre-issuance linting does not appear to be mentioned in the CPS or CP.

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)

Needs to be fixed – Please refer to sections 4.9.1.1 and 4.9.1.2 of the Baseline Requirements. There are two parts to BR section 4.9.1.1, including mandatory 24-hour revocation for the five reasons set forth. E.g., “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”. GTS should review both section 4.9.1.1 and section 4.9.1.2 of the Baseline Requirements and ensure that it has adequately addressed the revocation reasons and timeframes.

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 … [e.g. MRSP § 6.2, ”5. 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;”]

Needs to be fixed – GTS should review MRSP section 6.2 and make sure it has covered the revocation reasons for SMIME certificates.

CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6)

Needs to be fixed – GTS should edit Section 4.9.7 of the CPS and CPs to specify the CRL issuance parameters applicable to end entity website authentication certificates.

Clearly specify methods to demonstrate private key compromise (MRSP § 6)

Needs to be fixed - Mozilla now requires that Section 4.9.12 of the CP/CPS describes the method by which any party can demonstrate private key compromise to GTS.

CA must not allow certificate suspension (BR § 4.9.13)

Good. Section 4.9.13 of the CPs state, “The certificate suspension process is not supported by the GTS CA.”

OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6)

Needs to be fixed – GTS should amend CP/CPS section 4.9.10 to disclose how often it updates OCSP responses and their validity period.

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

Should be fixed – Section 5.7.3 of the CPS says, “If any of the algorithms, or associated parameters, used by the GTS CA or its owners become insufficient for their intended purpose, the GTS CA shall: Inform all holders and other entities with which the GTS CA has agreements or other form of established relationships. Additionally, this information shall be made available for other dependent entities; [and] Schedule the revocation of any affected certificate.” GTS should ensure that its key compromise plan requires that someone immediately notify Mozilla and other root stores that have trusted the GTS PKI hierarchy. This requirement should be made clear in this section CPS.

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

Needs to be fixed – Section 6.1.1 of the CPS should say that the GTS CAs never generate key pairs for server certificates.

Must meet RSA key requirements (MRSP § 5.1)

Could be improved – CPS section 6.1.5 says, “2048 bits RSA for keys associated with the remaining certificates that are issued by GTS with the sha256RSA signature algorithm.” However, sections 6.1.5 and 6.1.6 could be improved after a review of https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#511-rsa, etc. and corresponding sections of the Baseline Requirements. Pre-issuance linting may also provide GTS with safeguards protecting it from mis-issuing server certificates.

Must meet ECC key requirements (MRSP § 5.1)

Could be improved – Sections 6.1.5 and 6.1.6 could be improved with reference to

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#512-ecdsa

and corresponding sections of the Baseline Requirements. Pre-issuance linting may also provide GTS with safeguards protecting it from mis-issuing server certificates.

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

OV CP Needs to be fixed – While section 6.3.2 of the CPS does not specify the lifetime of end entity certificates, section 7 of the EV CP says, “Certificates issued by the GTS Certification Authority: Have a validity limit (1 year), stated in its content.” However, section 7.5 of the OV CP says, “Certificates issued by the GTS Certification Authority: Have a validity limit (1, 2 or 3 years), stated in its content.” OV certificates can have a maximum validity of 398 days (397 days to be safe).

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 – Section 6.7 of the CPS states, “The GTS PKI has border protection devices, namely a firewall system. It meets the necessary requirements for identification, authentication, access control, administration, auditing and information exchange.” Compliance with the CA/Browser Forum’s Network and Certificate System Security Requirements should be ensured with incorporation of it, in its entirety, by reference. See https://cabforum.org/network-security-requirements/ .

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

Needs to be fixed – In the OV and EV Certificate profiles of the CPs, it says that the serial number is “Assigned by the GTS Certification Authority to each certificate. This is inadequate. The requirement is that the CA generates a non-sequential certificate serial number greater than zero (0) containing at least 64 bits of output from a cryptographically secure pseudorandom number generator (CSPRNG).”

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

OK – The EKUs of end entity server certificates can contain both serverAuth and clientAuth but the anyExtendedKeyUsage EKU cannot be present. Section 7.5 of the OV CP indicates these two allowed EKUs in the OV certificate profile, and Section 7.1 of the EV CP indicates these two allowed EKUs in the EV certificate profile.

Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 7.1.3.2.1)

Good – Section 7.1.3 of the CPS lists only the SHA256 algorithm as a supported algorithm and the SHA1 algorithm is not mentioned.

Any CN must also be in a SAN (BR § 7.1.4.2.2.a)

Needs to be fixed – The CPs or CPS should state that any commonName field in the certificate Subject DN has to be one of the FQDN SANs that has been validated pursuant to one of the allowed methods in BR section 3.2.2.4.

EXTENDED VALIDATION GUIDELINES

The following additional EV review is based on version 1.7.4 of the EV Guidelines.

EVG Section 8.1 - the CA shall notify the CAB Forum if a provision of the EV Guidelines is illegal under local government laws.

Needs to be fixed – GTS should add language acknowledging that if there is any inconsistency concerning its compliance with applicable domestic law and the Baseline Requirements or the EV SSL Certificate Guidelines, that the CPS may be adjusted to satisfy the requirements of such domestic laws, however the CA/Browser Forum shall be notified immediately of any such adjustment.

EVG Section 8.4 - the CA shall maintain liability insurance of US$2 million and professional liability insurance of US$5 million.

Should be fixed – Reference should be made to compliance with provisions of the EV Guidelines. Currently, section 9.2 of the CPS only refers to local legal requirements.

EVG Section 9.2.1 - the organization name must include the full legal name for the subscribing organization as listed in official records.

Needs to be fixed – The EV CP needs to detail the steps taken by GTS from validating all required information to putting that information correctly in EV certificates.

EVG Sections 9.2.3, 11.2.1 and 11.2.2 – 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"

Needs to be fixed – The EV CP needs to detail the steps taken by GTS from validating all required information to putting that information correctly in EV certificates.

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.

Needs to be fixed – The EV CP needs to provide this distinction on the level of detail for jurisdiction information for incorporating/registration agencies. Read section 9.2.4 of the EV Guidelines.

EVG Sections 9.2.4, 9.2.5, and 11.1.3 – the CA shall maintain a publicly available list of its 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.

Needs to be fixed – GTS needs to publicly disclose its QGIS and QIIS sources and indicate where that information is published.

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.

Should be fixed – GTS needs to mention what it does when a jurisdiction does not provide entity registration numbers.

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 – Please refer to section 9.2.6 of the EV Guidelines on the steps needed to verify a physical address and to include it in an EV certificate.

EVG Section 9.2.7 - the CA shall implement a process that prevents an organizational unit from including a trade name unless the CA has verified that information.

OK – Assuming the OU field is part of the subject DN, section 3.1.6 of the CPS says, “DNs issued by the GTS CA are unique for each holder and take into account the registered trademarks, not allowing the deliberate use of registered names whose entity cannot prove it has the right to the trademark, and may refuse to issue the certificate with registered trademark names if it concludes that another identification is more convenient. Before issuing the certificate, during the authentication procedure, the entity/holder shall present documents that demonstrate the right to use the requested DN.”

EVG Sections 9.2.8, 9.8.2, and Appendix H – if included in the certificate, the CA shall confirm registration references for legal entities.

Should be fixed – please refer to EVG sections 9.2.8, 9.8.2, and Appendix H

EVG Section 9.2.9 - the CA shall not include any subject attributes except as specified in section 9.2 of the EV Guidelines.

Should be fixed – While section 7.1 of the EV CP contained the EV certificate profile, I could not find a limitation on any additional kinds of subject attributes that might appear in an EV certificate issued by GTS.

EVG Sections 9.3.2 and 9.3.5 - subscriber certificates shall contain the appropriate EV policy OIDs.

Good – From the EV certificate profile in section 7.1, GTS appears to be using the EV OID of 1.3.6.1.4.1.50302.1.1.2.2.1.0 along with the CABF EV OID.

EVG Section 9.4 - the validity period for an EV certificate shall not exceed 398 days.

Good – Section 7.1 says, certificates “Have a validity limit (1 year), stated in its content.” And the EV certificate profile in Section 7.1 of the EV CP says, “1-year maximum validity “

EVG Section 9.8.1 - wildcard certificates are not allowed.

OK – The EV certificate profile in Section 7.1 of the EV CP says for SANs, “Maximum 7 Domains, other than Wildcard Domains”, however this could be made more explicit somewhere else in the CP.

EVG Section 10.1.2 - the roles of certificate requestor, certificate approver, and contract signer are required for the issuance of EV certificates.

Needs to be fixed – GTS needs to explain that these three roles are required during the application process for EV certificates.

EVG Section 11.2.2(4) – the principal individual for a “business entity” must be validated in a face-to-face setting.

Needs to be fixed – Please refer to section 11.2.2(4) of the EV Guidelines for an explanation of this requirement.

EVG Section 11.3.1 - assumed names must be verified with an appropriate government agency or a QIIS that has verified the assumed name with the appropriate government agency.

Needs to be fixed – See section 11.3.1 of the EV Guidelines for this requirement

EVG Section 11.5.1 - the CA must establish a verified method of communication with the applicant.

Needs to be fixed – I could not find in the CP/CPS any reference to the EV Guidelines’ “Verified Method of Communication”. GTS needs to explain how it complies with section 11.5 of the EV Guidelines.

EVG Section 11.6.1 - the CA must verify that the applicant has the ability to engage in business. The EV issuance process requires that the operational existence be established in one of 4 ways: “(1) Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company has been in existence for at least three years, as indicated by the records of an Incorporating Agency or Registration Agency; (2) Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company is listed in either a current QIIS or QTIS; (3) Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company has an active current Demand Deposit Account with a Regulated Financial Institution by receiving authenticated documentation of the Applicant's, Affiliate's, Parent Company's, or Subsidiary Company's Demand Deposit Account directly from a Regulated Financial Institution; or (4) Relying on a Verified Professional Letter to the effect that the Applicant has an active current Demand Deposit Account with a Regulated Financial Institution.”

Needs to be fixed – See section 11.6.1 of the EV Guidelines for this requirement. GTS needs to explain how it complies with this requirement.

EVG Section 11.7.1 - domain name verification must use a procedure from section 3.2.2.4 of the Baseline Requirements (BR)

Needs to be fixed – Section 3.2.2.4 of the EV CP should say, “For the domain validation of EV certificates, GTS does X, Y, Z [from methods listed in section 3.2.2.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 – GTS needs to explain how it verifies the name and title of the contract signer and certificate approver

EVG Section 11.9 - the CA must verify the signature on the subscriber agreement and certificate request

Needs to be fixed – GTS needs to explain how it verifies the signature on the subscriber agreement and certificate request

EVG Section 11.11.5 - the CA shall use documented processes to check the accuracy of a QIIS.

Needs to be fixed – see discussion above under Data sources and QIISes need to be accurate (BR § 3.2.2.7 / EVG § 11.11.5). GTS needs to state how it establishes the reliability and accuracy of QIISes.

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 - GTS needs to state how it checks that the applicant, contract signer, and certificate approver are not on denied persons lists (e.g. barred because of money laundering or terrorist financing).

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

Needs to be fixed - I did not find mention of a two-person approval process or “final cross-correlation and other due diligence based on the entire corpus of information.”

EVG Section 11.14.3 - validation data cannot be reused after 398 days

Unclear/Should be fixed - See my comments above under “Data reuse (certificate renewal) limited to 398 and 825 days (MRSP § 2.1.5) (BR § 4.2.1)”. It is unclear whether GTS reuses any information.

EVG Section 12 - root CA private keys must not be used to sign EV certificates

Needs to be fixed – I did not find a provision saying what Root CA private keys are allowed to be used for.

EVG Section 14.1.1 - a CA must verify the identity and trustworthiness of anyone involved in EV processes

Good – CPS sections 5.3.1 through 5.3.4 appear to satisfy this requirement.

EVG Section 14.1.2 – the internal examination of specialists must include the EV certificate validation criteria of the EV guidelines

Should be fixed – See EVG § 14.1.2 and BR § 5.3.3 for additional details.

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.

Unclear – CPS Section 5.3.7 implies that third party personnel only act as consultants under direct GTS supervision. It could be made more clear that they do not perform EV-related duties requiring special skills or training.

Whiteboard: [ca-verifying] - BW 2020-07-30 Comment #30 → [ca-verifying] - BW 2021-05-29 Comment #52

We are making the corrections requested right now and we will update the Bug as soon as possible.

Attached file AAL_10999698_2020_01-Rev. 03_test.pdf (obsolete) —
Attachment #9184174 - Attachment is obsolete: true
Attachment #9199534 - Attachment is obsolete: true
Attachment #9199535 - Attachment is obsolete: true

Testing ALV verification of audit dates (and performing other ALV checks)

Attachment #9225683 - Attachment is obsolete: true

This version, Attachment #9225720 [details], appears to pass ALV testing. One improvement that could be made is to have the SHA256 hashes for the intermediate certificate in a single line. Right now, those SHA256 hashes wrap around in the cell of the table.

Hello,
we attached the updated documentation, following your instrutions.

you can also find the documents in https://pki.globaltrustedsign.com/en

Reviewing version 8 of the CPs and version 11 of the CPS.

Whiteboard: [ca-verifying] - BW 2021-05-29 Comment #52 → [ca-verifying] - BW 2021-06-25 Comment #70
Priority: P3 → P2

Hello again,
Just keeping the thread alive, while waiting for feedback.

Thank you for your time
Best Regards

Flags: needinfo?(bwilson)

Hello Ben,
Do you have any news for us about the documentation ?
If you need extra information, please don´t hesitate to contact us.

Hello,
can you give us a feedback how its going ?
Thank you

I will take a look at your updated documentation this week.

ACIN / Global Trusted Sign - Second CP/CPS Review

Review of v.8 of the GTS Website Authentication Certificate Policy (SSL Organization Validation) (“OV CP”) - PL04, v.8 of the Website Authentication Certificate Policy (SSL Extended Validation) (“EV CP”) - PL03, and GTS CA Certification Practice Statement, v.11, (“CPS”) - DP01

All dated June 23, 2021.

Baseline Requirements / Mozilla Root Store Policy Requirements

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

Should be fixed – Section 1.3.2 of the CPS says, “Global Trusted Sign does not have External Registry Authorities.” However, this needs to be more explicit, including for SMIME certificates. (See below under “CA validates domain part of all e-mail addresses“. In other words, GTS should explicitly say that it does not delegate domain validation to any third parties.

OK - Section 4.1.2 of the OV CP says, "GTS does not use external registration entities to provide the registration service."

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

Needs to be fixed – Section 1.5.2 of the CPs and the CPS need to alert readers of where and how they can report “suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.”

OK - The CA and CPS now state in section 1.5.2, "When any of the grounds for revocation set out in point 4.9.1. is identified, it should be communicated to the above-mentioned contacts," and "Whenever any of the reasons for revocation set out in section 4.9.1. are identified, they should be communicated to the contacts above or preferably to the e-mail address for reports." However, this language could still be made more clear that revocation requests should be sent to "report@globaltrustedsign.com".

Naming compliant with X.500, RFC5280, Baseline Requirements and EV Guidelines

The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards.

Needs to be fixed – Section 3.1 of the CPS and CPs discuss naming compliant with X.500 and RFC 5280. The tables in section 3.1 of the CPs show simplified fields for subject naming in OV and EV certificates, however there are complexities with naming for EV certificates. The EV CP should provide more detail how naming is consistent with the CA/Browser Forum’s EV Guidelines. For example, see the section below under the EV guidelines’ analysis titled “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.”

Fixed - Section 3.1 of the EV CP contains a table with the appropriate EV subject fields.

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

Needs to be fixed – I could not find in the CPs or CPS where issuance of certificates for internal or reserved IP addresses or Domain Names is prohibited.

Needs to be fixed - Table in section 3.1 now states that the CN must contain the Fully Qualified Domain Name of the Web Server and that its designation via IP address or local domains is prohibited. However, there is no clear prohibition of an internal host name or reserved IP address in the Subject Alternative Name (SAN) field, at least I didn't see one.

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 by a man-in-the-middle to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]

Needs to be fixed – Please refer to section 3.2.2.4 of the CA/Brower Forum’s Baseline Requirements and explain the validation steps taken to verify a domain name / FQDN.

Needs to be fixed - Section 3.2.2 now states, "b) Domain Name / Address Validation Method "The GTS CA validates the right of use or control by the domain name applicant, which shall be listed in the Common Name and Subject Alternative Name of the certificate, using at least one of the procedures described in section 3.2.2.4 of the CA/B Forum Baseline Requirements." However, Mozilla and the Baseline Requirements require that the CA detail each separate subsection of BR section 3.2.2.4 that they use to perform domain validation. It is insufficient that the CA merely references compliance with BR section 3.2.2.4.

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

Needs to be fixed – The CPS needs to say that GTS performs a challenge-response verification for email addresses included in SMIME certificates (or at least it will validate the domain part for email addresses included in SMIME certificates issued in the context of an enterprise RA). See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response and https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control

Fixed

Data sources and QIISes need to be accurate (BR § 3.2.2.7 / EVG § 11.11.5)

“[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.” If the CA intends to issue EV certificates, then the QIIS also needs to be evaluated for its reliability and accuracy. See EVG § 11.11.5.

Needs to be fixed – GTS needs to disclose its process for determining that a third-party validation source is reliable. Section 3.2.2.7 of the Baseline Requirements says, “The CA SHOULD consider the following during its evaluation:

\1. The age of the information provided,

\2. The frequency of updates to the information source,

\3. The data provider and purpose of the data collection,

\4. The public accessibility of the data availability, and

\5. The relative difficulty in falsifying or altering the data.”

Also refer to EVG § 11.11.5.

Should be fixed - Section 3.2.2.1 states, "In the case of entities located outside the Portuguese territory, the documentation to be submitted will be that of the Official Registry of the respective country, duly apostilled and officially translated into Portuguese or English, whenever there are doubts regarding the documentation or the entity. When issuing OV / EV SSL certificates, the existence of the entity is verified in the public records (https://eportugal.gov.pt), by consulting the InformaDB data (https://www.informadb.pt/) or in the databases of the tax authority (https://www.portaldasfinancas.gov.pt/). Section 3.2.2.7 currently says, "GTS has a list of reliable sources to analyse the data prior to issuing the certificates." But the question is -- for any other data sources, how does GTS determine that the other data source is reliable in the first place? Also, see EV comment further below that GTS should explain how it maintains the list of its reliable sources, e.g. based on the age of the information provided, the frequency of updates to the information source, the data provider and purpose of the data collection, the public accessibility to the data, and the relative difficulty in falsifying or altering the data.

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

Needs to be fixed – Section 3.2.2 of the OV CP states, “All the information provided by the subscriber is verified.” It should actually say, “all information in the certificate is verified.” Also, according to RFC 3647, this should be found in section 3.2.4, not section 3.2.2.

Fixed - Section 3.2.4 of the CPS and CPs now says, "All information in the certificate is verified."

Data reuse (certificate renewal) limited to 398 and 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”, and “for server certificates issued on or after October 1, 2021, each dNSName or IPAddress in a SAN or commonName MUST have been validated in accordance with section 3.2.2 of the CA/Browser Forum's Baseline Requirements within the prior 398 days.” For EV Certificates, the reuse timeframe is now 398 days instead of 13 months.

Needs clarification – It is unclear whether GTS uses any information collected from previous certificate requests. In several places in the CPS and in the CPs, it says, “[X] follows the procedures of initial identification and authentication” or “The renewal is treated like a new issuance request by the GTS CA.” This implies that all information is collected and verification is re-performed for every single rekeyed or renewed certificate. This needs to be confirmed by GTS.

OK - Section 4.2.1 of the CPS and CPs now says, "The GTS CA limits the reuse of the supporting information for the renewal of the certificate, in accordance with point “11.14.3- Age of Validated Data” of the Guidelines for the Issuance and Management of Extended Validation Certificates do CA/Browser Forum." Similar language is in section 4.6.1.

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

Needs to be fixes or called out – I could not find the phrase “multi-factor authentication” in conjunction with “accounts capable of causing certificate issuance”.

Needs to be fixed - While section 4.3.1 now states, "The certificate issuance process is always carried out by two Registration Administrators in order to guarantee double authentication," this is not the same as multifactor authentication. In other words, this particular security control has nothing to do with implementing multi-person or dual-person controls. Multi-factor authentication means to use something stronger than a user name and password to access the RA account--two of the following--something you know, something you have, and something you are (biometric). Or you can 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."

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 – Pre-issuance linting does not appear to be mentioned in the CPS or CP.

OK - GTS is examining the use of Zlint. CAs should implement all three of these pre-issuance linters - https://github.com/certlint/certlint, https://github.com/zmap/zlint, and https://github.com/kroeckx/x509lint.

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)

Needs to be fixed – Please refer to sections 4.9.1.1 and 4.9.1.2 of the Baseline Requirements. There are two parts to BR section 4.9.1.1, including mandatory 24-hour revocation for the five reasons set forth. E.g., “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”. GTS should review both section 4.9.1.1 and section 4.9.1.2 of the Baseline Requirements and ensure that it has adequately addressed the revocation reasons and timeframes.

Fixed

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 … [e.g. MRSP § 6.2, ”5. 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;”]

Needs to be fixed – GTS should review MRSP section 6.2 and make sure it has covered the revocation reasons for SMIME certificates.

Fixed

CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6)

Needs to be fixed – GTS should edit Section 4.9.7 of the CPS and CPs to specify the CRL issuance parameters applicable to end entity website authentication certificates.

Needs to be Fixed - I did not see documentation of CRL issuance frequency.

Clearly specify methods to demonstrate private key compromise (MRSP § 6)

Needs to be fixed - Mozilla now requires that Section 4.9.12 of the CP/CPS describes the method by which any party can demonstrate private key compromise to GTS.

Needs to be Fixed - Not only does section 4.9.12 need to say where to submit a request to revoke due to key compromise, but it also must state the methodology that GTS will use to verify that the the key has been compromised.

OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6)

Needs to be fixed – GTS should amend CP/CPS section 4.9.10 to disclose how often it updates OCSP responses and their validity period.

OK - section 4.9.10 states, "The service updates OCSP responses with a periodicity of 10m as defined in the nextupdate field."

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

Should be fixed – Section 5.7.3 of the CPS says, “If any of the algorithms, or associated parameters, used by the GTS CA or its owners become insufficient for their intended purpose, the GTS CA shall: Inform all holders and other entities with which the GTS CA has agreements or other form of established relationships. Additionally, this information shall be made available for other dependent entities; [and] Schedule the revocation of any affected certificate.” GTS should ensure that its key compromise plan requires that someone immediately notify Mozilla and other root stores that have trusted the GTS PKI hierarchy. This requirement should be made clear in this section CPS.

Fixed - Section 5.7.3 of the CPS now states "Inform the Mozilla Root Repository and other root repositories that have established a trust relationship with the GTS PKI hierarchy;"

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

Needs to be fixed – Section 6.1.1 of the CPS should say that the GTS CAs never generate key pairs for server certificates.

Fixed - the CPS now states, "The GTS CA does not generate key pairs for certificates that have the EKU extension containing the KeyPurposeIds, id-kpserverAuth or anyExtendedKeyusage attributes." However, this could have been written to apply only to end entity server certificates. Arguably this language could imply that GTS cannot create intermediate CAs with the serverAuth EKU, which isn't the intent of this requirement.

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

OV CP Needs to be fixed – While section 6.3.2 of the CPS does not specify the lifetime of end entity certificates, section 7 of the EV CP says, “Certificates issued by the GTS Certification Authority: Have a validity limit (1 year), stated in its content.” However, section 7.5 of the OV CP says, “Certificates issued by the GTS Certification Authority: Have a validity limit (1, 2 or 3 years), stated in its content.” OV certificates can have a maximum validity of 398 days (397 days to be safe).

Still needs to be fixed - While section 7.1 now says, "Have a validity limit (1 year), stated in its content," still the Certificate Profile Table a) in section 7 the OV CP (PL04) says that there is a validity period of 3 years. This needs to be fixed.

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 – Section 6.7 of the CPS states, “The GTS PKI has border protection devices, namely a firewall system. It meets the necessary requirements for identification, authentication, access control, administration, auditing and information exchange.” Compliance with the CA/Browser Forum’s Network and Certificate System Security Requirements should be ensured with incorporation of it, in its entirety, by reference. See https://cabforum.org/network-security-requirements/ .

Fixed

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

Needs to be fixed – In the OV and EV Certificate profiles of the CPs, it says that the serial number is “Assigned by the GTS Certification Authority to each certificate. This is inadequate. The requirement is that the CA generates a non-sequential certificate serial number greater than zero (0) containing at least 64 bits of output from a cryptographically secure pseudorandom number generator (CSPRNG).”

Fixed

Any CN must also be in a SAN (BR § 7.1.4.2.2.a)

Needs to be fixed – The CPs or CPS should state that any commonName field in the certificate Subject DN has to be one of the FQDN SANs that has been validated pursuant to one of the allowed methods in BR section 3.2.2.4.

Fixed - Section 3.1.2 of the CPS now states "The GTS CA ensures that any Common Name field in the Subject DN of the certificate is equal to one of the Subject Alternative Names FQDN, which was validated using at least one of the procedures specified in section 3.2.2.4 of the Baseline Requirements CA/B Forum."

EXTENDED VALIDATION GUIDELINES

The following additional EV review is based on version 1.7.4 of the EV Guidelines.

EVG Section 8.1 - the CA shall notify the CAB Forum if a provision of the EV Guidelines is illegal under local government laws.

Needs to be fixed – GTS should add language acknowledging that if there is any inconsistency concerning its compliance with applicable domestic law and the Baseline Requirements or the EV SSL Certificate Guidelines, that the CPS may be adjusted to satisfy the requirements of such domestic laws, however the CA/Browser Forum shall be notified immediately of any such adjustment.

Fixed - Section 9.15 of the CPS now states, "GTS commits to notify the CA/Browser Forum about the facts, circumstances, and laws involved so that the CA/Browser Forum may reassess these Guidelines accordingly."

EVG Section 8.4 - the CA shall maintain liability insurance of US$2 million and professional liability insurance of US$5 million.

Should be fixed – Reference should be made to compliance with provisions of the EV Guidelines. Currently, section 9.2 of the CPS only refers to local legal requirements.

OK - the CPS states, "GTS has a civil liability insurance, in accordance with article 16 of Decree-Law 62/2003, of 3 April."

EVG Section 9.2.1 - the organization name must include the full legal name for the subscribing organization as listed in official records.

Needs to be fixed – The EV CP needs to detail the steps taken by GTS from validating all required information to putting that information correctly in EV certificates.

Needs to be fixed - I could not find language detailing how GTS verifies the full legal name of an organization and then includes it in the certificate. Just as an example, modification of this language in section 3.2.2.1 of the EV CP would be a good start, "When issuing OV / EV SSL certificates, the full exact legal name and the legal existence of the entity is verified in the public records (https://eportugal.gov.pt), by consulting the InformaDB data (https://www.informadb.pt/) or in the databases of the tax authority (https://www.portaldasfinancas.gov.pt/)."

EVG Sections 9.2.3, 11.2.1 and 11.2.2 – 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"

Needs to be fixed – The EV CP needs to detail the steps taken by GTS from validating all required information to putting that information correctly in EV certificates.

Satisfactory - Section 3.2.2.1 of the EV CP now states, "For EV certificates the operational activity of the entity is verified in a reliable manner, as well as to which category of entity it belongs according to the classification established in the policies defined by the CA/Browser Forum in "Guidelines for the Issuance and Management of Extended Validation Certificates" (Private Organization, Government Entity, Business Entity and Non-Commercial Entity). This verification is done through an analysis of the legal regime applicable to the applicant entity and through consultation of the records of the business activity of the market or through the physical delivery of the notarial deeds that prove all the information."

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.

Needs to be fixed – The EV CP needs to provide this distinction on the level of detail for jurisdiction information for incorporating/registration agencies. Read section 9.2.4 of the EV Guidelines.

Should be fixed - Section 9.2.4 of the EV Guidelines says, "the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency that operates at the country level MUST include the country information but MUST NOT include the state or province or locality information. Similarly, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the state or province level MUST include both country and state or province information, but MUST NOT include locality information. And, the jurisdiction for the applicable Incorporating Agency or Registration Agency at the locality level MUST include the country and state or province information, where the state or province regulates the registration of the entities at the locality level, as well as the locality information. "

EVG Sections 9.2.4, 9.2.5, and 11.1.3 – the CA shall maintain a publicly available list of its 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.

Needs to be fixed – GTS needs to publicly disclose its QGIS and QIIS sources and indicate where that information is published.

Needs to be Fixed - While GTS has provided Mozilla with its list of validation sources (see https://bugzilla.mozilla.org/attachment.cgi?id=9228700), Section 3.2 of the EV CP or of the CPS should provide the GTS repository URL for that document's location.

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 – Please refer to section 9.2.6 of the EV Guidelines on the steps needed to verify a physical address and to include it in an EV certificate.

Clarification / Needs to be fixed - Subsections d, e, f, g and h of Section 7.1.4.2.2 of the Baseline Requirements indicate whether an address field is required or optional to appear in a certificate. However, the physical address of the applicant must be verified regardless of whether it is eventually included in the EV certificate. This requirement is found in EV section 11.1.1(1)(B) and EV section 11.4.1. I did not find a description of the process used by GTS to verify a physical address in the EV CP.

EVG Sections 9.2.8, 9.8.2, and Appendix H – if included in the certificate, the CA shall confirm registration references for legal entities.

Should be fixed – please refer to EVG sections 9.2.8, 9.8.2, and Appendix H

Needs to be fixed - I reviewed the EV CP section 3.2.2, and it is still unclear whether GTS will include NTR, VAT, or PSD registration numbers in certificates as outlined in EV Guidelines section 9.2.8.

EVG Section 9.2.9 - the CA shall not include any subject attributes except as specified in section 9.2 of the EV Guidelines.

Should be fixed – While section 7.1 of the EV CP contained the EV certificate profile, I could not find a limitation on any additional kinds of subject attributes that might appear in an EV certificate issued by GTS.

Clarification / Needs to be fixed - GTS should add the following sentence somewhere in section 7 of the EV CP: "GTS does not include Subject attributes that are not specified in Section 9.2 of the EV Guidelines."

EVG Section 10.1.2 - the roles of certificate requestor, certificate approver, and contract signer are required for the issuance of EV certificates.

Needs to be fixed – GTS needs to explain that these three roles are required during the application process for EV certificates.

Still needs to be Fixed - I have reviewed section 4.1.1 of the CPS and the Issuance Process document (https://bugzilla.mozilla.org/attachment.cgi?id=9228702). These roles (requestor, approver, and contract signer) are in the subscriber's organization. They may be the same person, but they must be designated by the subscriber's organization. How are these handled? See what other CAs do or say, e.g., https://support.globalsign.com/ssl/ssl-certificates-life-cycle/role-definitions; https://sectigo.com/uploads/files/EV-Certificate-Request-standard-form-v1.1.pdf; http://eca.hinet.net/download/HiPKI-EV-TLSCA-CPS-v1.16-en.pdf.

EVG Section 11.2.2(4) – the principal individual for a “business entity” must be validated in a face-to-face setting.

Needs to be fixed – Please refer to section 11.2.2(4) of the EV Guidelines for an explanation of this requirement.

Needs clarification - in CPS section 3.2.3, I could not find where the natural person affiliated with the EV category "business entity" was required to appear in a face-to-face setting.

EVG Section 11.3.1 - assumed names must be verified with an appropriate government agency or a QIIS that has verified the assumed name with the appropriate government agency.

Needs to be fixed – See section 11.3.1 of the EV Guidelines for this requirement

Needs clarification - Section 3.2.2.2 refers to Section 3.1.6 of the CPS, which states, "not allowing the deliberate use of registered names whose entity cannot prove it has the right to the trademark, and may refuse to issue the certificate with registered trademark names if it concludes that another identification is more convenient." Is there any place in sections 3.2.2.1 to 3.2.2.7 of the CPS that say something more clear and concrete about registered fictitious names?

EVG Section 11.5.1 - the CA must establish a verified method of communication with the applicant.

Needs to be fixed – I could not find in the CP/CPS any reference to the EV Guidelines’ “Verified Method of Communication”. GTS needs to explain how it complies with section 11.5 of the EV Guidelines.

Still needs to be fixed - GTS needs to explain or say that it establishes a verified method of communication by referring to official/reliable third-party sources for contact information for the applicant/organization and does not simply rely on contact information that is provided by the natural person requesting the certificate for the organization.

EVG Section 11.6.1 - the CA must verify that the applicant has the ability to engage in business. The EV issuance process requires that the operational existence be established in one of 4 ways: “(1) Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company has been in existence for at least three years, as indicated by the records of an Incorporating Agency or Registration Agency; (2) Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company is listed in either a current QIIS or QTIS; (3) Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company has an active current Demand Deposit Account with a Regulated Financial Institution by receiving authenticated documentation of the Applicant's, Affiliate's, Parent Company's, or Subsidiary Company's Demand Deposit Account directly from a Regulated Financial Institution; or (4) Relying on a Verified Professional Letter to the effect that the Applicant has an active current Demand Deposit Account with a Regulated Financial Institution.”

Needs to be fixed – See section 11.6.1 of the EV Guidelines for this requirement. GTS needs to explain how it complies with this requirement.

OK - Section 3.2.2.1 of the CPS now says, "For EV certificates the operational activity of the entity is verified in a reliable manner"

EVG Section 11.7.1 - domain name verification must use a procedure from section 3.2.2.4 of the Baseline Requirements (BR)

Needs to be fixed – Section 3.2.2.4 of the EV CP should say, “For the domain validation of EV certificates, GTS does X, Y, Z [from methods listed in section 3.2.2.4 of the Baseline Requirements].

Better, but still needs to be fixed - see comment above regarding the need to specify the exact domain validation methods from BR 3.2.2.4 that are used by GTS.

EVG Section 11.8.1 - the CA must verify the name and title of the contract signer and certificate approver

Needs to be fixed – GTS needs to explain how it verifies the name and title of the contract signer and certificate approver

Inadequate - needs to be fixed - GTS needs to say that the name and job title of the Applicant organization's certificate approver and contract signer are independently verified (by contacting the organization's human resources department separately through a Verified Method of Communication, which has been established by relying on a trusted official source).

EVG Section 11.9 - the CA must verify the signature on the subscriber agreement and certificate request

Needs to be fixed – GTS needs to explain how it verifies the signature on the subscriber agreement and certificate request

Inadequate - needs to be fixed - GTS needs to say that it verifies the signature on the subscriber agreement and that it ensures that its agreement with the subscriber is legally binding.

EVG Section 11.11.5 - the CA shall use documented processes to check the accuracy of a QIIS.

Needs to be fixed – see discussion above under Data sources and QIISes need to be accurate (BR § 3.2.2.7 / EVG § 11.11.5). GTS needs to state how it establishes the reliability and accuracy of QIISes.

Needs to be fixed - GTS needs to say that it uses the criteria listed in BR section 3.2.2.7 to select data sources and to regularly check on the reliability and accuracy of such data sources.

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 - GTS needs to state how it checks that the applicant, contract signer, and certificate approver are not on denied persons lists (e.g. barred because of money laundering or terrorist financing).

Fixed - Section 3.2.2.1 of the CPS now states, "That they are not eradicated companies in countries where there is a government ban on doing business or on a BCFT risk related list."

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

Needs to be fixed - I did not find mention of a two-person approval process or “final cross-correlation and other due diligence based on the entire corpus of information.”

OK - Section 4.3.1 of the EV CP states, "The certificate issuance process is always carried out by two Registration Administrators in order to guarantee double authentication."

EVG Section 11.14.3 - validation data cannot be reused after 398 days

Unclear/Should be fixed - See my comments above under “Data reuse (certificate renewal) limited to 398 and 825 days (MRSP § 2.1.5) (BR § 4.2.1)”. It is unclear whether GTS reuses any information.

Good - Section 4.6.1 of the EV CP now states, "The GTS CA limits the reuse of the supporting information for the renewal of the certificate, in accordance with point “11.14.3- Age of Validated Data” of the CA/ Browser Forum Guidelines for the Issuance and Management of Extended Validation Certificates."

EVG Section 12 - root CA private keys must not be used to sign EV certificates

Needs to be fixed – I did not find a provision saying what Root CA private keys are allowed to be used for.

Fixed - Section 6.1.7 of the CPS provides that the ROOT CA GTS certificate key pair is used to sign the CA certificates, sign the Offline CRL and to sign the CRL.

EVG Section 14.1.2 – the internal examination of specialists must include the EV certificate validation criteria of the EV guidelines

Should be fixed – See EVG § 14.1.2 and BR § 5.3.3 for additional details.

Fixed - Training includes "Awareness on evaluation criteria for SSL certificates according to the CA/Forum Browser EV Guidelines"

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.

Unclear – CPS Section 5.3.7 implies that third party personnel only act as consultants under direct GTS supervision. It could be made more clear that they do not perform EV-related duties requiring special skills or training.

OK - Section 5.3.7 now states, "The access to the High Security Zone by consultants or providers of independent services, requires the continuous supervision from members of the Working Groups, being their identity confirmed through the verification of documentation issued by reliable sources."

Flags: needinfo?(bwilson)

There are some problems with your test certificates. For example, https://gtsvalid.pt/, the CRL Distribution URL and the AIA URL for the Issuer should be HTTP, not HTTPS. Also, the only key usage bits needed I believe are Digital Signature and Key Encipherment, not Data Encipherment. Although not required by Mozilla, it appears that this certificate has not been logged with Certificate Transparency (it's not found at https://crt.sh/?q=58B1F5FACCFCA608A62B469EFD4B25A50D74BE8CAC7AF6DE6D43D46F411C3460). Another error is that some python versions will not see SAN extension if it is the first extension. And then FWIW, the issuing CA has key usages of Certificate Signing and CRL Signing (CA certificates without Digital Signature do not allow direct signing of OCSP responses).

Priority: P2 → P3

Please check the error messages at the following URL and let me know when you have made progress to eliminate some of them: https://certificate.revocationcheck.com/gtsvalid.pt
Thanks.

Flags: needinfo?(info)

Hi there,
we have some doubts about the issues that you reported and our questions are in the excel file attached. Based on your analyses we found out that we need to issue a new subordinate CA to fulfil all the requirements. Since that issuance of the new subca will take some time and is necessary to have a external audit, we will also adopt the method of one CP and one CPS for all services.
Since we will issue a new subca we need to fullfill the CCAB information about the new sub or we need to open a new case ?

Flags: needinfo?(info)
Flags: needinfo?(bwilson)

AAL Updated

Hi there,
as ask we send the audit report from the last year

Flags: needinfo?(bwilson)
Severity: normal → S3
Product: NSS → CA Program

The Applicant needs to open an "Add/Update Root Request" case in the CCADB and complete all required information under the "Audits" tab, the "Policy Documents" tab, the "Root Information" tab, and the "Test Websites" tab.

Whiteboard: [ca-verifying] - BW 2021-06-25 Comment #70 → [ca-initial]

Hello Ben,
Then can we close this Root Request and create a new one? As you asked 4 months ago.
We want to re-insert all the information as clean as possible to be easier for us to identify the problems we still have.

Regards,
Thiago Costa

That will be fine. I'll close this case tomorrow. Feel free to open up a new Bugzilla case and a new CCADB case whenever is convenient to you.

Flags: needinfo?(bwilson)
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Flags: needinfo?(bwilson)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: