Closed Bug 1554846 Opened 6 years ago Closed 3 years ago

Add iTrusChina root certificate(s)

Categories

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

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: vTrus_contact, Assigned: bwilson, NeedInfo)

References

Details

(Whiteboard: [ca-approved] - In NSS 3.74, FF 97; EV enabled in FF 97)

Attachments

(28 files, 1 obsolete file)

iTrusChina_ CA Information.pdf
533.82 KB, application/pdf
Details
iTrusChina CA Hierarchy.pdf
297.73 KB, application/pdf
Details
BR-Self-Assessment_Related to CPS1.3.pdf
280.92 KB, application/pdf
Details
Audit Report for iTrusChina_point_in_time.zip
5.27 MB, application/x-zip-compressed
Details
OCSP Testing Results.pdf
287.52 KB, application/pdf
Details
iTrusChina Certification Practice Statement v1.3.1.pdf
898.58 KB, application/pdf
Details
Test Preliminary Audit Statements
396.78 KB, application/pdf
Details
Test Preliminary Audit Statements
603.73 KB, application/pdf
Details
Test Preliminary Audit Statements_SSL BR
728.44 KB, application/pdf
Details
Test Preliminary Audit Statements_CA
731.59 KB, application/pdf
Details
Test Preliminary Audit Statements_EV
717.86 KB, application/pdf
Details
iTrusChina Audit report-2020.04.zip
2.20 MB, application/x-zip-compressed
Details
BR-Self-Assessment_Related to CPS1.4.1.pdf
457.05 KB, application/pdf
Details
iTrusChina Certification Practice Statement v1.4.2.pdf
903.14 KB, application/pdf
Details
iTrusChina Certificate Policy v1.4.2.pdf
787.77 KB, application/pdf
Details
BR Self Assessment_Related to CPS 1.4.4.pdf
212.24 KB, application/pdf
Details
Preliminary Audit Reports-BR-period of time_20210318.pdf
115.62 KB, application/pdf
Details
Preliminary Audit Reports-CA-period of time_20210318.pdf
113.85 KB, application/pdf
Details
Preliminary Audit Reports-EV-period of time_20210318.pdf
115.40 KB, application/pdf
Details
Preliminary Audit Reports-CA-period of time_20210318.pdf
232.87 KB, application/pdf
Details
Preliminary Audit Reports-BR-period of time_20210318.pdf
196.93 KB, application/pdf
Details
Preliminary Audit Reports-EV-period of time_20210318.pdf
186.86 KB, application/pdf
Details
Quantifying Value -iTrusChina.pdf
196.46 KB, application/pdf
Details
Budget list-iTrusChina.pdf
47.93 KB, application/pdf
Details
Newly generated ICA
1.45 KB, application/x-x509-ca-cert
Details
iTrusChina Audit report and management assertion-EV SSL period of time.pdf
599.45 KB, application/pdf
Details
iTrusChina Audit report and management assertion-SSL BR period of time.pdf
616.93 KB, application/pdf
Details
iTrusChina Audit report and management assertion-WebTrust for CA period of time.pdf
615.65 KB, application/pdf
Details

iTrusChina Co.,Ltd. is the first company who bring SSL product into China in 2000, and the largest SSL reseller in China during the past 18 years. As a compliance CA in China, we conducted WebTrust audit in 2018-2019 and have WebTrust seals online in May 2019. We apply to include our root into the Mozilla Root Store Program, plan to provide public trusted certificate issued by our Root to our customer.

According to requirements of Mozilla root program, we provide the iTrusChina_ CA Information.pdf and BR Self-Assessment.

iTrusChina has two root certificate.
vTrus Root CA
vTrus ECC Root CA
For details, please see the attatch file iTrusChina CA Hierarchy.pdf.

We attached the point in time audit report. And the links of the period of time audit reports are available in the iTrusChina_ CA Information.pdf and also availalbe on our main page https://www.itrus.com.cn.

Please kindly review our application.

Kind regards,
vTrus team
iTrusChina Co., Ltd.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #9067932 - Attachment is obsolete: true

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] - CA is new to CCADB

(In reply to Kathleen Wilson from comment #5)

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

Hi Kathleen
Thanks for your notice. We have filled the Application form, please review it.
Cheers,
vTrus Team

(In reply to iTrusChina Co.,Ltd. from comment #6)

We have filled the Application form, please review it.

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

We have created the CCADB Case according to the instruction.

Mozilla Root Inclusion Case Information: https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000431

For further information needed by Mozilla, please check the attachment iTrusChina_ CA Information.pdf.
vTrus RSA Root CA URL http://wtca-cafiles.itrus.com.cn/ca/vTrusRootCA.cer
vTrus ECC Root CA URL http://wtca-cafiles.itrus.com.cn/ca/vTrusECCRootCA.cer

We got some problems during the AVL process. The AVL showed thumbprint FAILED flags in the CA and EV reports, but not in the BR SSL report. And audit start, end and statement date FAILED flages in the CA and BR SSL report, not in the EV reports. We have contacted the PWC auditor to make sure they used the same audit report form and the dates and thumbprints are correctly showed in the reports.

Please proceed the case and add comments below, thanks.

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

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

In particular:

  1. The valid test website must have an EV TLS cert when you are requesting EV treatment.

  2. Resolve errors listed here https://certificate.revocationcheck.com/validrsa.itrus.cn
    ERROR: NextUpdate not set (RFC 5019, section 2.2.4)
    Regarding the timeout errors, ITrusChina is able to test successfully, as described here: https://bug1554846.bmoattachments.org/attachment.cgi?id=9067929. So unclear if the timeout errors shown by revocationcheck.com will happen normally.

  3. Resolve errors listed here https://certificate.revocationcheck.com/validecc.itrus.cn
    ERROR: NextUpdate not set (RFC 5019, section 2.2.4)
    Error making OCSP request: Post http://wtocsp-cdn.itrus.com.cn/ocsp/ocsp/ocsp: EOF
    Unexpected HTTP response: 500 Internal Server Error

  4. Does iTrusChina need to be able to issue certs outside of *.cn?
    Mozilla has the ability to name constrain root certs; e.g. to *.gov or *.mil. CAs should consider if such constraints may be applied to their root certs.

Whiteboard: [ca-verifying] - CA is new to CCADB → [ca-verifying] - KW 2019-06-18 - Comment #9

(In reply to Kathleen Wilson from comment #9)

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

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

In particular:

  1. The valid test website must have an EV TLS cert when you are requesting EV treatment.
    At present, we have a EV test website(https://evtest.itrus.cn/) for RSA root already tested with Mozilla EV-Readiness Check.
    We will prepare a EV test website for ECC root in 1 week.

  1. Resolve errors listed here https://certificate.revocationcheck.com/validrsa.itrus.cn
    ERROR: NextUpdate not set (RFC 5019, section 2.2.4)
    Regarding the timeout errors, ITrusChina is able to test successfully, as described here: https://bug1554846.bmoattachments.org/attachment.cgi?id=9067929. So unclear if the timeout errors shown by revocationcheck.com will happen normally.

  2. Resolve errors listed here https://certificate.revocationcheck.com/validecc.itrus.cn
    ERROR: NextUpdate not set (RFC 5019, section 2.2.4)
    Error making OCSP request: Post http://wtocsp-cdn.itrus.com.cn/ocsp/ocsp/ocsp: EOF
    Unexpected HTTP response: 500 Internal Server Error
    Regarding the "NextUpdate not set" issue, iTrusChina developed OCSP conform to RFC6960 and deployed in Real-Time mode which means our OCSP service will generate new response for each query. NextUpdate is optional as described in RFC6960, If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time.
    iTrusChina have plan to develop and deploy OCSP server in "cache mode" conform to RFC5019， our R&D team is working on it.

  1. Does iTrusChina need to be able to issue certs outside of *.cn?
    Mozilla has the ability to name constrain root certs; e.g. to *.gov or *.mil. CAs should consider if such constraints may be applied to their root certs.
    Yes, iTrusChina need to be able to issue certs outside of *.cn.

Kindly Regards,
vTrus Team
iTrusChina Co., Ltd.

(In reply to Kathleen Wilson from comment #9)

  1. Resolve errors listed here https://certificate.revocationcheck.com/validrsa.itrus.cn
    ERROR: NextUpdate not set (RFC 5019, section 2.2.4)
    Regarding the timeout errors, ITrusChina is able to test successfully, as described here: https://bug1554846.bmoattachments.org/attachment.cgi?id=9067929. So unclear if the timeout errors shown by revocationcheck.com will happen normally.

  2. Resolve errors listed here https://certificate.revocationcheck.com/validecc.itrus.cn
    ERROR: NextUpdate not set (RFC 5019, section 2.2.4)
    Error making OCSP request: Post http://wtocsp-cdn.itrus.com.cn/ocsp/ocsp/ocsp: EOF
    Unexpected HTTP response: 500 Internal Server Error

For the timeout issue, it happens most of the time in our side with https://certificate.revocationcheck.com/validrsa.itrus.cn.
With our own coding test, it both works with validecc.itrus.cn and validrsa.itrus.cn as listed in OCSP Testing Results.pdf.
Our R&D team is checking logs for the resolving the 500 internal server Error and the timeout error.

Kindly Regards,
vTrus Team
iTrusChina Co., Ltd.

Type: enhancement → task

(In reply to Kathleen Wilson from comment #9)

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

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

In particular:

  1. The valid test website must have an EV TLS cert when you are requesting EV treatment.
    https://evtest.itrus.cn
  1. Resolve errors listed here https://certificate.revocationcheck.com/validrsa.itrus.cn
    ERROR: NextUpdate not set (RFC 5019, section 2.2.4)
    Regarding the timeout errors, ITrusChina is able to test successfully, as described here: https://bug1554846.bmoattachments.org/attachment.cgi?id=9067929. So unclear if the timeout errors shown by revocationcheck.com will happen normally.
  2. Resolve errors listed here https://certificate.revocationcheck.com/validecc.itrus.cn
    ERROR: NextUpdate not set (RFC 5019, section 2.2.4)
    Error making OCSP request: Post http://wtocsp-cdn.itrus.com.cn/ocsp/ocsp/ocsp: EOF
    Unexpected HTTP response: 500 Internal Server Error

iTrusChina updated OCSP server and resolved above issue.

  1. Does iTrusChina need to be able to issue certs outside of *.cn?
    Mozilla has the ability to name constrain root certs; e.g. to *.gov or *.mil. CAs should consider if such constraints may be applied to their root certs.

Yes, iTrusChina need to be able to issue certs outside of *.cn.

iTrusChina CPS is updated to version 1.3.1 (attached). https://www.itrus.com.cn/repository

Please help to process the inclusion request.

Regards,
vTrus Team
iTrusChina Co., Ltd.

(In reply to iTrusChina Co.,Ltd. from comment #10)

  1. The valid test website must have an EV TLS cert when you are requesting EV treatment.
    At present, we have a EV test website(https://evtest.itrus.cn/) for RSA root already tested with Mozilla EV-Readiness Check.
    We will prepare a EV test website for ECC root in 1 week.

Please provide the EV test website for the ECC root cert.

Whiteboard: [ca-verifying] - KW 2019-06-18 - Comment #9 → [ca-verifying] - KW 2019-11-13 - Comment #14

(In reply to Kathleen Wilson from comment #15)

(In reply to iTrusChina Co.,Ltd. from comment #10)

  1. The valid test website must have an EV TLS cert when you are requesting EV treatment.
    At present, we have a EV test website(https://evtest.itrus.cn/) for RSA root already tested with Mozilla EV-Readiness Check.
    We will prepare a EV test website for ECC root in 1 week.

Please provide the EV test website for the ECC root cert.

Hi Kathleen,

ECC EV test website deployed and tested follow the https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
https://eccevtest.itrus.cn

Regards,
vTrus Team
iTrusChina Co., Ltd.

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

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

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

There is a queue waiting for detailed CP/CPS reviews:
https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review

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

Assignee: kwilson → wthayer
Whiteboard: [ca-verifying] - KW 2019-11-13 - Comment #14 → [ca-cps-review] - KW 2019-11-18

iTrusChina has implemented this year's WebTrust audit in January, and has updated the audit report to CCADB.
The audit report has also been updated on Bugzilla.

iTrusChina updated CP and CPS to version 1.4 and published on official website.
https://www.itrus.com.cn/repository

Regards,
vTrus Team
iTrusChina Co., Ltd.

Assignee: wthayer → bwilson

iTrusChina updated CP and CPS to version 1.4.1 and published on official website.
https://www.itrus.com.cn/repository
And iTrusChina completed this year's BR Self Assessment based on BR1.7.0 and CP / CPS1.4.1, please find in the attachment.

Hello Kathleen and Ben，

It’s been 9 months since we entered the CPS Review session, but we still haven’t received any response.
We would like to know how long it will take mozilla to update the results of the iTrusChina CP/CPS review.

your feedback will be appreciated.

I am just completing a CP/CPS review of AC RAIZ FNMT. After FNMT, I will review your CP/CPS.

I have begun review of the iTrusChina CP/CPS.

Whiteboard: [ca-cps-review] - KW 2019-11-18 → [ca-cps-review] - BW 2020-08-25 In review

Here are the results of my initial CPS review.

iTrus China CPS Review

Based on v. 1.4.1, effective May 20, 2020

https://www.itrus.com.cn/uploads/soft/200622/2-2006221Q327.pdf

General Comments

The CPS has a version control table, which is evidence of good change management. A review of the Table of Contents indicates that the CPS is structured in accordance with RFC 3647 as required by section 3.3 of the Mozilla Root Store Policy. A scan of the CPS indicated that there were no blank sections and no inappropriate use of “No Stipulation”.

Use of the word “audit” in a few instances was confusing – maybe it is a translation issue. In 3.2.2.6, “If necessary, iTrusChina needs to adopt other independent auditing means to confirm the ownership of a domain name.”; section 3.2.3 “2. iTrusChina verifies the authenticity of information such as identity materials, etc. by face-to-face audit or by telephone, post, etc.”; and in Section 4.1.2 “iTrusChina is responsible for the corresponding audit.”

Also, maybe this is another translation issue for the SAN extension. Instead of referring to it in several places as the “alias”, I would recommend referring to it as the Subject Alternative Name or SAN extension.

Good

1.1.2

There is a statement of adherence to requirements of the CA/Browser Forum and that they take precedence in the event of a conflict.

1.1.3

End entity certificates are not issued directly from the root CA certificate. There is also a good structure to have 3 separate issuing CAs for EV, OV and DV. However, I believe that iTrusChina is requesting enablement of the secure email trust bit (and issuance of an email certificate is discussed in section 3.2.3). So, what are iTrusChina’s plan for issuing SMIME certificates? An Issuing CA isn’t presented in this hierarchy. Will this occur under additional yet-to-be-created CAs?

1.2

Policy Object Identifiers (OIDs) are listed. Note that use of the CAB Forum OIDs will now be required by section 7.1.6.4 of the Baseline Requirements and that your own OIDs can still be used.

1.5.4 and 2.3

These sections provide that the “CPS has been annually revised according to … the latest versions of Baseline Requirements, EV Guidelines and NCSSR published in CA/Browser Forum” and that “iTrusChina publishes CP and CPS at least once a year.” These are good because this is also required by subsection 4 of section 3.3. of the Mozilla Root Store Policy.

3.2.2.4 and 3.2.2.5 - Good

“iTrusChina will verify the ownership of all domain names listed in a certificate. According to the requirements on the CAB Forum, iTrusChina does not issue a certificate for the internal name of the application. For the verification of domain names, the verified entity can be a parent company, a subsidiary company or an affiliate company of the subscriber. iTrusChina shall confirm the domain name permission in the following ways: [allowed methods]”

“According to the requirements of CAB Forum, iTrusChina does not issue a certificate for the Reserved IP marked by IANA. For all IP address listed in a certificate, iTrusChina confirms the control over the IP by following methods: [allowed methods]

3.2.2.5

“According to the requirements of CAB Forum, iTrusChina does not issue a certificate for the Reserved IP marked by IANA”

4.1.2 and 6.1.1.2

“Subscribers shall generate key pairs by themselves, generate PKCS#10 certificate request file, submit to iTrusChina and pay any applicable fee.” And “iTrusChina does not generate key pairs for Subscribers.” This is good.

4.2

CAA Names are listed in section 2.2, along with practices in section 3.2.2.8. Cross-reference is made also in section 4.2 to iTrusChina’s CAA practices. “iTrusChina will perform a CAA record check for each dNSName in the certificate extension alias extension, and determine whether to approve the certificate application according to the inspection method and result in 3.2.2.8.”

4.2.1

Good that data reuse is limited to 398 days.

4.9.7 (and 2.3)

“iTrusChina publishes CRL of subscriber certificates at least once in 96 hours”

4.9.10

When receiving a request for status of a certificate that has not been issued, iTrusChina does not respond with a "good" status.

4.9.13

Does not allow certificate suspension - good

7.1

“iTrusChina generates a non-sequential certificate serial number containing at least 64 bits from a CSPRNG.”

9.16.3

“Prior to issuing a certificate under the modified requirement, iTrusChina will notify the CA/Browser Forum of the relevant information newly added to its CP and CPS by sending a message to question@cabforum.org and receiving confirmation that it has been posted to and is indexed in the Public Mailing List (https://cabforum.org/pipermail/ public/).”

“Any modification to iTrusChina practice enabled under this section must be discontinued if and when the law no longer applies, or the Baseline Requirements of the CA/B forum are modified to make it possible to comply with both BR and the law simultaneously. An appropriate change in practice, modification to iTrusChina's CPS and a notice to the CA/B forum, as outlined above, must be made within 90 days.”

10 Annex

Indicates the CAs to which the CPS applies – this is good.

Meh – Causes Concern

1.1.3

External third party CAs are mentioned. If they are operated externally, then the Mozilla Program is concerned with root CAs that intend to issue external subordinate CA certificates. Often there is inadequate control over those external third-party CAs and this exposes the root CA to potential distrust and removal from the Mozilla program.

1.2

I have a slight concern about “If there is any inconsistency or conflict between the English version and the Chinese version, the Chinese version will prevail.” Which prevails the Chinese version or the Baseline Requirements? Except as otherwise set forth in the BRs, then the Chinese version can prevail.

1.3.2 and 3.2.2.1

These two sections could be made a little more clear about roles and responsibilities. Section 1.3.2 states that “no external RA will be established separately”, but then in section 3.2.2.1 it says that on-site verifications performed by iTrusChina or a trusted third-party organization entrusted by iTrusChina. Are these third parties then double-checked by iTrusChina? Would they be Local RAs (LRAs) or independent third parties? There is always concern about the accuracy of third-party information and a CA is still held fully responsible for mistakes, errors and omissions of such third parties.

1.4.1

This section is silent about email certificates.

1.4.3

This section is silent about prohibiting the use of certificates for man-in-the-middle attacks. Some CAs include the following language in their CPS: “Certificates shall not be used for man-in-the-middle (MITM) or traffic management of domain names or IPs that the certificate holder does not legitimately own or control. Such certificate usage is expressly prohibited.”

1.5.2

This section could be more clear that it is procedure to request revocation. The PDF form could also be made so that it is text-fillable in some PDF programs. Has iTrustChina had some experience using the form yet? Some of our Mozilla stakeholders might complain that this process slows them down in the case of mass problem-reporting submissions or revocation requests. Is an email to support@itrus.com.cn that contains all of the information requested in the form sufficient? If so, then this section 1.5.2 should make it clear that using the form is optional.

3.1.1

“Digital certificates issued by iTrusChina meet X.509 Standard, and distinguished names assigned for certificate holders adopt the X.500 standard naming method. Regarding SSL server certificates issued by iTrusChina, all their domain names or IP addresses are added to subject alias; meanwhile, a common name is a primary domain name or IP address, which should be a domain name or IP address that exists in subject alias”

iTrusChina should also assert that its naming practices are compliant with RFC 5280, the Baseline Requirements, and the EV Guidelines.

3.1.6

“Subject Distinguished Names of certificates issued by iTrusChina do not contain trademark names.” I doubt that this is correct. Trademarked names are so widely used that I don’t think iTrusChina can say that subject DNs absolutely don’t or won’t include trademarked names. I’d suggest that iTrusChina use language similar to what some other CAs say here.

3.2.2

This section says that “iTrusChina shall implement different methods of identity authentication based on different types of certificates applied by subscribers. A higher level of the certificate asks for a higher level of required security, a stricter authentication method as well as more comprehensive authentication contents.” Why not reference the Baseline Requirements and the EV Guidelines?

3.2.2.3

iTrusChina says that it will “Confirm the host country based on the organization proof information provided by the applicant as specified in 3.2.2.1.” Can this be explained in greater detail here? Could it also base verification of country on additional information, such as the domain name registration or tracking of IP address? Do any of the processes in section 3.2.2.4 help establish country? Learning the practices of other CAs may help here.

3.2.2.7

Should also assert compliance with “Reliable Data Source” as used in section 3.2.2.7 of the CABF Baseline Requirements and “Qualified Information Sources” as used in section 11.11 and elsewhere in the EV Guidelines.

3.2.2.8

ICANN root is misspelled as “ICNNA root”

3.2.3

“iTrusChina also defines other authentication methods and materials required according to the authentication of individual identity of customers.” Please specify what these “other authentication methods and materials” are.

3.2.4

Mozilla Root Store Policy section 2.2 requires that all information in a certificate must be verified. This section language is contrary to that concept -- “In general, apart from the identity information required to be verified clearly and reliably for the type of a certificate, iTrusChina does not promise the authenticity of the subscriber’s information that is not required to be verified and bears no legal responsibility.” Instead, this section should say that no unverified information is placed in a certificate.

4.2.2.2.

The following language is unnecessary because actual domain validation must now be performed under one of the approved methods listed in section 3.2.2.4: “5) the certificate to be applied for contains a new gTLD (top-level domain name) under the consideration of ICANN (The Internet Corporation for Assigned Names and Numbers”.

4.6.1

This section states, “The subscriber’s certificates issued by iTrusChina can be renewed 90 days ahead of the certificate expiry date.” What if a Subscriber wants to change its certificate and renew 100 days ahead of the certificate expiry date? This appears to prohibit that, which would be a problem for quick, frequent certificate rollovers. This needs to be reworded to say what the practice is or what is allowed.

5.5.5

Even though time-stamping service isn’t used, audit logs and records will have some type of consistent time associated with them. I think that is all that is required. So you might want to re-word this to say that event times are consistently recorded, or something to that effect, rather than saying “iTrusChina doesn’t adopt the time-stamping technology for logs.”

6.7

iTrusChina should say here that it complies with the CA/Browser Forum’s Network and Certificate System Security Requirements.

6.8

Time stamping description here seems to collide with section 5.5.5.

7.1.2

An EKU is required for subordinate certificates. See section 7.1.2.2.g. of the current Baseline Requirements.

Also, KeyEncipherment key usage is only for RSA keys, not ECC keys. (KeyAgreement is allowed for ECC keys.)

7.2.2

A reason code is required now for ARLs (CRLs for CAs) – see section 7.2.2 of the most recent version of the Baseline Requirements.

9.5

Note that under subsection 3 of section 3.3 of the Mozilla Policy, “CPs and CPSes are made available to Mozilla under [a] Creative Commons license[].”

9.8

I did not see where iTrusChina incorporates the EV warranty of section 18 of the EV Guidelines – “CAs MAY limit their liability as described in Section [9.8] of the Baseline Requirements except that a CA MAY NOT limit its liability to Subscribers or Relying Parties for legally recognized and provable claims to a monetary amount less than two thousand US dollars per Subscriber or Relying Party per EV Certificate.”

Bad

3.2.2.4

This section can be made more clear that iTrusChina does not and shall never delegate the performance of domain validation to a third party. Maybe this was lost in translation, but I did not find any language in the CPS concerning non-delegation. Similarly, Mozilla prohibits delegation of the domain part of email address validation. Subsection 2 of section 2.2 of Mozilla Policy says, “The CA SHALL NOT delegate validation of the domain portion of an email address. The CA MAY rely on validation the CA has performed for an Authorization Domain Name (as specified in the Baseline Requirements) as being valid for subdomains of that Authorization Domain Name. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification.”

3.2.3

The following method of domain validation is no longer permitted: “6. Regarding a certificate application in which a domain name, a device name or an email address is used as the certificate subject content, iTrusChina shall verify whether the individual applicant has the right or not, for example, asking the applicant to submit the domain name ownership document, ownership proof document or the applicant’s written commitment to the ownership, etc.”

The iTrusChina CPS does not adequately specify the email verification process. See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control

Also refer to the challenge-response process to verify an email address: https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response

4.9.3.2

Subsection 3) of section 4.9.3.2 states that “iTrusChina shall organize an investigation and determine whether to revoke the certificate according to the investigation result”. (Section 4.9.5. is similar – it says “Within 24 hours upon the receipt of a certificate problem report, iTrusChina shall investigate contents of the certificate problem report to decide whether to revoke the certificate or take other proper actions.”)

iTrusChina should be on alert that in certain circumstances listed in 4.9.1.1 (for example, key compromise), revocation must occur within 24 hours because section 4.9.5 of the Baseline Requirements also says, “The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1.”.

5.7.3

Mozilla should be provided notice immediately upon discovery or suspicion of CA private key compromise. Currently the CPS only says, “3) When the private key of iTrusChina root CA or subordinate CA is compromised, iTrusChina will handle the emergency according to key emergency plan, and notify the relying party through various ways.”

Multi-Factor Authentication

Finally, I did not see a statement that Multi-Factor Authentication (MFA) is used for accounts capable of certificate issuance as required by subsection 3 of section 2.1 of Mozilla Policy.

(In reply to Ben Wilson from comment #30)
Thank you for your detailed review. For all issues, iTrusChina will revise CP/CPS after internal rectification within 2 weeks.

For your questions, the explanation is as follows:

Meh – Causes Concern

1.1.3

External third party CAs are mentioned. If they are operated externally, then the Mozilla Program is concerned with root CAs that intend to issue external subordinate CA certificates. Often there is inadequate control over those external third-party CAs and this exposes the root CA to potential distrust and removal from the Mozilla program.

Issuing external subordinate CA certificates will be prohibted. We will adjust CP/CPS more clear about this.

1.2

I have a slight concern about “If there is any inconsistency or conflict between the English version and the Chinese version, the Chinese version will prevail.” Which prevails the Chinese version or the Baseline Requirements? Except as otherwise set forth in the BRs, then the Chinese version can prevail.

We have declared in 1.1.2 that if this CPS and the terms in the relevant standards and specifications issued by CA/Browser Forum are inconsistent, the specifications issued by CA/Browser Forum will prevail.

1.3.2 and 3.2.2.1

These two sections could be made a little more clear about roles and responsibilities. Section 1.3.2 states that “no external RA will be established separately”, but then in section 3.2.2.1 it says that on-site verifications performed by iTrusChina or a trusted third-party organization entrusted by iTrusChina. Are these third parties then double-checked by iTrusChina? Would they be Local RAs (LRAs) or independent third parties? There is always concern about the accuracy of third-party information and a CA is still held fully responsible for mistakes, errors and omissions of such third parties.

iTrusChina does not entrust a third party to perform on-site verification. The description in 3.2.2.1 will be modified.

1.4.1

This section is silent about email certificates.

iTrusChina does not issue email certificates at this stage.
However，iTrusChina may issue an intermediate certificate for the purpose of SMIME next year, and CP/CPS will be adjusted before the issuance.

3.2.3

“iTrusChina also defines other authentication methods and materials required according to the authentication of individual identity of customers.” Please specify what these “other authentication methods and materials” are.

For applications of personal identity certificates, iTrusChina may require applicants to provide documents such as credit card bills, water and electricity payment records for verification.
In fact, we currently only issue SSL certificates, so we will rewrite chapter 3.2.3.

3.2.4

Mozilla Root Store Policy section 2.2 requires that all information in a certificate must be verified. This section language is contrary to that concept -- “In general, apart from the identity information required to be verified clearly and reliably for the type of a certificate, iTrusChina does not promise the authenticity of the subscriber’s information that is not required to be verified and bears no legal responsibility.” Instead, this section should say that no unverified information is placed in a certificate.

For the subscriber certificate issued by iTrusChina, all the information written in the certificate has been verified.

4.6.1

This section states, “The subscriber’s certificates issued by iTrusChina can be renewed 90 days ahead of the certificate expiry date.” What if a Subscriber wants to change its certificate and renew 100 days ahead of the certificate expiry date? This appears to prohibit that, which would be a problem for quick, frequent certificate rollovers. This needs to be reworded to say what the practice is or what is allowed.

The situation described in this chapter is to renewal the certificate without changing the content of the certificate at all. If the content of the certificate changes, perform the 4.8 Certificate Modification process.

5.5.5

Even though time-stamping service isn’t used, audit logs and records will have some type of consistent time associated with them. I think that is all that is required. So you might want to re-word this to say that event times are consistently recorded, or something to that effect, rather than saying “iTrusChina doesn’t adopt the time-stamping technology for logs.”

The Chinese version of section 6.8 describes iTrusChina's log files all contain time records, but we do not use time stamp technology.
This section has some translation issues, we will adjust the CP/CPS English version.

Bad

3.2.2.4

This section can be made more clear that iTrusChina does not and shall never delegate the performance of domain validation to a third party. Maybe this was lost in translation, but I did not find any language in the CPS concerning non-delegation. Similarly, Mozilla prohibits delegation of the domain part of email address validation. Subsection 2 of section 2.2 of Mozilla Policy says, “The CA SHALL NOT delegate validation of the domain portion of an email address. The CA MAY rely on validation the CA has performed for an Authorization Domain Name (as specified in the Baseline Requirements) as being valid for subdomains of that Authorization Domain Name. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification.”

iTrusChina does not delegate the performance of domain validation to any third party. We will describe this clearly in our CPS.

3.2.3

The following method of domain validation is no longer permitted: “6. Regarding a certificate application in which a domain name, a device name or an email address is used as the certificate subject content, iTrusChina shall verify whether the individual applicant has the right or not, for example, asking the applicant to submit the domain name ownership document, ownership proof document or the applicant’s written commitment to the ownership, etc.”

The iTrusChina CPS does not adequately specify the email verification process. See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control

Also refer to the challenge-response process to verify an email address: https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response

We currently only issue SSL certificates, so we will rewrite chapter 3.2.3.

4.9.3.2

Subsection 3) of section 4.9.3.2 states that “iTrusChina shall organize an investigation and determine whether to revoke the certificate according to the investigation result”. (Section 4.9.5. is similar – it says “Within 24 hours upon the receipt of a certificate problem report, iTrusChina shall investigate contents of the certificate problem report to decide whether to revoke the certificate or take other proper actions.”)

iTrusChina should be on alert that in certain circumstances listed in 4.9.1.1 (for example, key compromise), revocation must occur within 24 hours because section 4.9.5 of the Baseline Requirements also says, “The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1.”.

We will describe this clearly that we will revoke the certificates in certain circumstance listed in 4.9.1.1 within 24 hours.

5.7.3

Mozilla should be provided notice immediately upon discovery or suspicion of CA private key compromise. Currently the CPS only says, “3) When the private key of iTrusChina root CA or subordinate CA is compromised, iTrusChina will handle the emergency according to key emergency plan, and notify the relying party through various ways.”

we will modify the description to we will notify the relying party and application software supplier such as Mozilla/Microsoft/360 through various ways.

Multi-Factor Authentication

Finally, I did not see a statement that Multi-Factor Authentication (MFA) is used for accounts capable of certificate issuance as required by subsection 3 of section 2.1 of Mozilla Policy.
iTrusChina adopted multi-factor authentication for all accounts capable for certificate issuance system, we will described it in section 6.7.

Whiteboard: [ca-cps-review] - BW 2020-08-25 In review → [ca-cps-review] - BW 2020-09-16 Comment #30

Hi Ben，
Oct 1th-8th is Chinese National Day and we will be out of work, so the publication of our revised CP/CPS will be delayed until October 16th.

iTrusChina updated CP/CPS to v1.4.2

Hi Ben，

iTrusChina updated CP and CPS to version 1.4.4 and published on official website：https://www.itrus.com.cn/repository ,
Please review this version, thanks.

(In reply to iTrusChina Co.,Ltd. from comment #31)

(In reply to Ben Wilson from comment #30)

CPS review of iTrus China CPS v. 1.4.4 dated 19-Dec-2020
https://www.itrus.com.cn/uploads/soft/201223/2-201223110436.pdf

Meh – Causes Concern

1.1.3

External third party CAs are mentioned. If they are operated externally, then the Mozilla Program is concerned with root CAs that intend to issue external subordinate CA certificates. Often there is inadequate control over those external third-party CAs and this exposes the root CA to potential distrust and removal from the Mozilla program.

Issuing external subordinate CA certificates will be prohibted. We will adjust CP/CPS more clear about this.

Fixed

1.2

I have a slight concern about “If there is any inconsistency or conflict between the English version and the Chinese version, the Chinese version will prevail.” Which prevails the Chinese version or the Baseline Requirements? Except as otherwise set forth in the BRs, then the Chinese version can prevail.

We have declared in 1.1.2 that if this CPS and the terms in the relevant standards and specifications issued by CA/Browser Forum are inconsistent, the specifications issued by CA/Browser Forum will prevail.

OK

1.3.2 and 3.2.2.1

These two sections could be made a little more clear about roles and responsibilities. Section 1.3.2 states that “no external RA will be established separately”, but then in section 3.2.2.1 it says that on-site verifications performed by iTrusChina or a trusted third-party organization entrusted by iTrusChina. Are these third parties then double-checked by iTrusChina? Would they be Local RAs (LRAs) or independent third parties? There is always concern about the accuracy of third-party information and a CA is still held fully responsible for mistakes, errors and omissions of such third parties.

iTrusChina does not entrust a third party to perform on-site verification. The description in 3.2.2.1 will be modified.

Fixed

1.4.1

This section is silent about email certificates.

iTrusChina does not issue email certificates at this stage.
However，iTrusChina may issue an intermediate certificate for the purpose of SMIME next year, and CP/CPS will be adjusted before the issuance.

iTrusChina is currently asking Mozilla for enablement of the email trust bit. We'll modify the CCADB to indicate that email/SMIME is no longer requested. iTrusChina can subsequently request enablement of the trust bit when the CP and CPS are updated in the future.

3.2.3

“iTrusChina also defines other authentication methods and materials required according to the authentication of individual identity of customers.” Please specify what these “other authentication methods and materials” are.

For applications of personal identity certificates, iTrusChina may require applicants to provide documents such as credit card bills, water and electricity payment records for verification.
In fact, we currently only issue SSL certificates, so we will rewrite chapter 3.2.3.

Fixed

3.2.4

Mozilla Root Store Policy section 2.2 requires that all information in a certificate must be verified. This section language is contrary to that concept -- “In general, apart from the identity information required to be verified clearly and reliably for the type of a certificate, iTrusChina does not promise the authenticity of the subscriber’s information that is not required to be verified and bears no legal responsibility.” Instead, this section should say that no unverified information is placed in a certificate.

For the subscriber certificate issued by iTrusChina, all the information written in the certificate has been verified.

OK

4.6.1

This section states, “The subscriber’s certificates issued by iTrusChina can be renewed 90 days ahead of the certificate expiry date.” What if a Subscriber wants to change its certificate and renew 100 days ahead of the certificate expiry date? This appears to prohibit that, which would be a problem for quick, frequent certificate rollovers. This needs to be reworded to say what the practice is or what is allowed.

The situation described in this chapter is to renewal the certificate without changing the content of the certificate at all. If the content of the certificate changes, perform the 4.8 Certificate Modification process.

OK

5.5.5

Even though time-stamping service isn’t used, audit logs and records will have some type of consistent time associated with them. I think that is all that is required. So you might want to re-word this to say that event times are consistently recorded, or something to that effect, rather than saying “iTrusChina doesn’t adopt the time-stamping technology for logs.”

The Chinese version of section 6.8 describes iTrusChina's log files all contain time records, but we do not use time stamp technology.
This section has some translation issues, we will adjust the CP/CPS English version.

Fixed

Bad

3.2.2.4

This section can be made more clear that iTrusChina does not and shall never delegate the performance of domain validation to a third party. Maybe this was lost in translation, but I did not find any language in the CPS concerning non-delegation. Similarly, Mozilla prohibits delegation of the domain part of email address validation. Subsection 2 of section 2.2 of Mozilla Policy says, “The CA SHALL NOT delegate validation of the domain portion of an email address. The CA MAY rely on validation the CA has performed for an Authorization Domain Name (as specified in the Baseline Requirements) as being valid for subdomains of that Authorization Domain Name. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification.”

iTrusChina does not delegate the performance of domain validation to any third party. We will describe this clearly in our CPS.

Fixed - Section 3.2.2.4 states, "[iTrusChina] will not delegate the performance of domain verification to a third-party"

3.2.3

The following method of domain validation is no longer permitted: “6. Regarding a certificate application in which a domain name, a device name or an email address is used as the certificate subject content, iTrusChina shall verify whether the individual applicant has the right or not, for example, asking the applicant to submit the domain name ownership document, ownership proof document or the applicant’s written commitment to the ownership, etc.”

The iTrusChina CPS does not adequately specify the email verification process. See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control

Also refer to the challenge-response process to verify an email address: https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response

We currently only issue SSL certificates, so we will rewrite chapter 3.2.3.

Fixed

4.9.3.2

Subsection 3) of section 4.9.3.2 states that “iTrusChina shall organize an investigation and determine whether to revoke the certificate according to the investigation result”. (Section 4.9.5. is similar – it says “Within 24 hours upon the receipt of a certificate problem report, iTrusChina shall investigate contents of the certificate problem report to decide whether to revoke the certificate or take other proper actions.”)

iTrusChina should be on alert that in certain circumstances listed in 4.9.1.1 (for example, key compromise), revocation must occur within 24 hours because section 4.9.5 of the Baseline Requirements also says, “The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1.”.

We will describe this clearly that we will revoke the certificates in certain circumstance listed in 4.9.1.1 within 24 hours.

Fixed

5.7.3

Mozilla should be provided notice immediately upon discovery or suspicion of CA private key compromise. Currently the CPS only says, “3) When the private key of iTrusChina root CA or subordinate CA is compromised, iTrusChina will handle the emergency according to key emergency plan, and notify the relying party through various ways.”

we will modify the description to we will notify the relying party and application software supplier such as Mozilla/Microsoft/360 through various ways.

Fixed - Section 5.7.3 of the CPS now states that iTrusChina will notify "application software supplier including Mozilla/Microsoft/Apple/Google/360 through email immediately."

Multi-Factor Authentication

Finally, I did not see a statement that Multi-Factor Authentication (MFA) is used for accounts capable of certificate issuance as required by subsection 3 of section 2.1 of Mozilla Policy.
iTrusChina adopted multi-factor authentication for all accounts capable for certificate issuance system, we will described it in section 6.7.

Fixed - Section 6.7 states that "All systems of iTrusChina related to certificate issuance adopt multi-factor authentication."

Whiteboard: [ca-cps-review] - BW 2020-09-16 Comment #30 → [ca-ready-for-discussion 2021-03-15]

Hi，Ben

iTrusChina has just completed this year's BR self-assessment.
Thank you very much for reviewing our CP/CPS, we are ready for the public discussion.

Priority: -- → P3

Hi Ben，

iTrusChina has completed the annual WebTrust audit，and the audit report and seal is officially online:
https://www.itrus.com.cn/
CA：https://www.cpacanada.ca/webtrustseal?sealid=10638
SSL：https://www.cpacanada.ca/webtrustseal?sealid=10639
EV：https://www.cpacanada.ca/webtrustseal?sealid=10640

Regards，
vTrus team

Whiteboard: [ca-ready-for-discussion 2021-03-15] → [ca-in-discussion] 2021-04-07

This was moved into public discussion today with a close of public discussion scheduled for 30-Apr-2021.
During the public discussion period, iTrusChina is expected to respond to questions and comments from the Mozilla community.
See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/4bWqkOwhzCc/m/a8dDrSjSBQAJ

Public discussion was extended on April 20, 2021 https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/4bWqkOwhzCc/m/0xjkC8JNAwAJ for iTrusChina to provide a value justification in line with this guidance - https://wiki.mozilla.org/CA/Quantifying_Value.

Hi All，

iTrusChina submitted a document to answer a series of questions in Quantifying Value.

Regards,
vTrus team

Flags: needinfo?(bwilson)

Hi All，

iTrusChina submitted a document on the budget 2018-2021.

Regards,
vTrus team

Flags: needinfo?(bwilson)

Hi Ben,

We have released the latest version of CP/CPS (CP v1.4.5, CPS v1.4.6) on our official website https://www.itrus.com.cn/repository/, please kindly review it, thanks.

Regards，
vTrus Team

EV Guidelines Review of the iTrusChina CPS, version 1.4.6, based on version 1.7.8 of the CABF EV Guidelines

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

Section 8.1 states, “If a court or government body with jurisdiction over the activities covered by these Guidelines determines that the performance of any mandatory requirement is illegal, then such requirement is considered reformed to the minimum extent necessary to make the requirement valid and legal. This applies only to operations or certificate issuances that are subject to the laws of that jurisdiction. The parties involved SHALL notify the CA / Browser Forum of the facts, circumstances, and law(s) involved, so that the CA/Browser Forum may revise these Guidelines accordingly.”

Please fix. iTrusChina should include a statement in its CPS that it will notify the Forum if a court or government body states that a requirement of the EV Guidelines is illegal.

EVG Sections 8.2.1, 8.2.2, and Mozilla Root Store Policy – the CA must publicly disclose its business practices and update its CP/CPS on at least an annual basis (and re-versions the CP/CPS, even if there are no other changes). The CP/CPS must be formatted according to RFC 3647.

Good

EVG Section 8.3 – the CA shall have a statement that it conforms to the current version of the EV guidelines and that in the event of any inconsistency, the EV guidelines take precedence.

Good. Section 1.1.2 of the CPS states, “If this CPS and the terms in the relevant standards and specifications issued by CA/Browser Forum are inconsistent, the specifications issued by CA/Browser Forum will prevail.”

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

Please fix. iTrusChina should state that it maintains at least the equivalent of commercial general liability insurance of US$2 million and professional liability or errors-and-omissions insurance of US$5 million.

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

Please fix. I could not find in section 3.2.2.1 or Annex A of the CPS where it states that, or describes how, the organization’s official name and DBA are verified and transcribed into the EV certificate.

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"

Please fix. Legal existence and identity are mentioned briefly in section 3.2.2.1 and Annex A of the CPS, but I did not see the same English terms mentioned for the EV business categories. (Reference is made in section 3.2.2.1 to “government organizations, enterprises and public organizations, etc.”).

EVG Section 9.2.4, 9.2.5 and 11.2.1 - jurisdiction of incorporation/registration fields must not contain information that is not relevant to the level of the incorporating agency or registration agency (and 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).

Please fix. The CPS does not describe how special EV fields (jurisdictions of incorporation/registration and registration numbers) are verified and included in EV certificates.

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.

Good. Section 3.2.2.7.1 of the CPS states, “iTrusChina publicly discloses the source of the authentication data (Incorporating Agency /Registration Agency, etc.) on the official website. If necessary, please visit https://www.itrus.com.cn/repository.”

EVG Section 9.2.6 - subject physical address of place of business must contain the address of the physical location of the business.

Please fix. While the CPS mentions verifying the address of the organization in section 3.2.2.1, there is no mention of this verification step in Annex A, and it is unclear whether the actual physical presence of the organization is verified according to EVG section 9.2.6.

EVG Sections 9.2.7 and 11.3.1 - the CA shall implement a process that prevents an organizational unit from including a trade name unless the CA has verified that information AND assumed names must be verified with an appropriate government agency or a QIIS that has verified the assumed name with the appropriate government agency.

Please fix. It is unclear how iTrusChina handles DBAs and tradenames, as well as OU fields.

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

Please fix. Language should be added to section 7.1.2 of the CPS to the effect that iTrusChina uses only those subject attributes specified in section 9.2 of the EV Guidelines. Currently, the CPS only says “EV certificate: be consistent with Section 9.2 in EVGL in CAB Forum,” which I don’t believe says the same thing adequately enough.

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

Good. Section 1.2 says, “iTrusChina also uses the policy object identifier reserved by CA/B Forum. 1) EV SSL Certificate Policy Object Identifier 2.23.140.1.1;”

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

Good. Section 6.3.2 of the CPS says, “the subscriber SSL certificate is valid for a maximum of 398 days.”

EVG Section 9.8.1 - wildcard certificates are not allowed.

Please fix. The CPS (e.g. section 3.2.2.6) should state that wildcards are not allowed for EV certificates.

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

Please fix. The roles of certificate requestor, certificate approver, and contract signer are integral to a compliant implementation of the EV Guidelines (see sections 11.8 and 11.9 below), and they need to be described in the CPS.

EVG Section 11.2.2(4) – “principal individuals” of “business entities” must be validated in a face-to-face setting.

Please fix. The CPS does not discuss the concepts of “business entity” and “principal individual” and, therefore, does not describe the verification steps needed for issuing an EV certificate to a “business entity”. This needs to be fixed.

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

Please fix. While section 3.2.5 of the CPS states that “iTrusChina shall verify the reliability of the communication information using the sources listed in 3.2.2.1”, iTrusChina should make a direct reference to EVG section 11.5 and use the phrase “Verified Method of Communication,” which is a defined term in the EV Guidelines.

EVG Section 11.4 and 11.6 - Establishing legal existence, operational existence, and physical existence are three core concepts involved in issuing EV certificates (EVG § 11.1.1). This includes business operations or operational existence. Section 11.6 requires that the CA verify that the applicant has at least the ability to engage in business or a similar type of operations. 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.”

Please fix. The CPS does not discuss the steps taken to establish business or operational existence.

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

Good. Section 3.2.2.4 describes the domain verification steps that are allowed by BR section 3.2.2.4.

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

Please fix. The CPS needs to state how the CA will verify the name and title of the person(s) who are the contract signer and certificate approver.

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

Please fix. The CPS needs to state how the CA will verify the signature on the subscriber agreement and on the certificate request.

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

Good. Section 3.2.2.7.2 of the CPS states that iTrusChina “evaluate[s] the source for its reliability, accuracy and resistance for alteration or falsification, comply with CAB Forum BR section 3.2.2.7 and EV Guidelines section 11.11 for data source requirements”.

EVG Section 11.12.2 - the CA must check whether the applicant, contract signer, or certificate approver is on denied persons lists, etc.

Please fix. While Annex A says that iTrusChina will “[m]ake queries of the entity’s existence and business’ existence through third-party information queries or query channels provided by the official government, and not on the list prohibited by local government laws and regulations,” it does not say that it will do this for individuals who are the applicant, contract signer, or certificate approver.

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.

Please fix. The CPS does not contemplate that there will be two people involved with a second person performing 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

Good. Section 4.8.1 acknowledges that “if the certificate application materials are within the valid period (398 days for OV and EV certificate application materials) and can be directly used. If the above certificate application materials have expired, iTrusChina will re-authenticate and re-verify all the information.”

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

Good. Section 6.1.7 of the CPS states, “The root CA key is generally used to issue the following certificates and CRL:
1 self-signed certificate representing the root CA;
2 subordinate CA certificate and cross certificate;
3 the CRL (ARL) of the root CA and the subordinate CA;
4 PKI system function certificates for specific purposes (such as OCSP certificates).”

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

Good. Sections 5.3.1 and 5.3.2 of the CPS adequately address this requirement.

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

Please fix. Section 5.3.3 of the CPS does not discuss training that will ensure compliance with the Baseline Requirements and the 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.

OK – While section 5.3.7 of the CPS states, “iTrusChina doesn’t hire external personnel engaged in the work related to certificate validation for now,” at any time in the future, the CPS will have to be amended before iTrusChina can engage any non-employee to conduct any CA or RA work.

Hi Ben,

We have revised a new version of CPS based on your comments and are going through the internal release process, which will be updated to our official website for review within a week.
Regarding the issue of the EV certificate insurance policy, iTrusChina decides its insurance policies based on its business development and the business development of Chinese insurance companies. For the EV certificate, iTrusChina has passed the financial audit of a third-party audit company and has reserved the relevant insurance amount for the planned EV customers. Currently iTrusChina does not purchase relevant commercial insurance.

Regards，
vTrus Team

Hi Ben,

We have released the latest version of CPS (CPS v1.4.7) on our official website https://www.itrus.com.cn/repository/, This time we added a chapter 3.2.2.1.1 to describe the requirements and identity authentication process of EV SSL. At the same time, we have corrected some inaccurate descriptions you pointed out in chapters 1.1.2, 3.2.5, 5.3.3, 7.1.2, 9.2.1 and Annex A, please kindly review it, thanks.

Regarding the EKUs of intermediate CA certificates, you mentioned that it must only be serverAuth and clientAuth. In the future, we have plans to generate document signing, timestamping or SMIME intermediate certificates under the RSA root, and these intermediate CAs cannot only include serverAuth and clientAuth EKUs, so we didn't add this description in the CPS released this time.

Regards，
vTrus Team

Review of the iTrusChina CPS, version 1.4.7, based on the CABF EV Guidelines

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

Fixed - Section 1.1.2 of the CPS now states, "iTrusChina will notify the CA/B Forum If a court or government body in China with jurisdiction over the activities covered by the EV Guidelines determines that the performance of any mandatory requirement is illegal."

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

OK - Section 9.2.1 of the CPS now states, "iTrusChina decides its insurance strategy based on its business development and the business development of Chinese insurance companies. For the EV certificate, iTrusChina has passed the financial audit of a third-party audit company, and has reserved the relevant insurance amount for the planned EV customers."

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

Fixed - Section 3.2.2.1.1 of the CPS now states, "The subject:organizationName (OID 2.5.4.10) field contains the applicant’s full legal organization name authenticated by the method in 3.2.2.1."

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"

Fixed - Section 3.2.2.1.1 of the CPS now states, "The subject:businessCategory (OID: 2.5.4.15) field contains one of the following strings: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity"; "

EVG Section 9.2.4, 9.2.5 and 11.2.1 - jurisdiction of incorporation/registration fields must not contain information that is not relevant to the level of the incorporating agency or registration agency (and 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).

OK - Section 3.2.2.1.1 of the CPS now states, "The subject:jurisdictionLocalityName (OID: 1.3.6.1.4.1.311.60.2.1.1), subject:jurisdictionStateOrProvinceName (OID: 1.3.6.1.4.1.311.60.2.1.2), subject:jurisdictionCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3) field contains the jurisdiction level of the registration authority. iTrusChina has disclosed the values in these fields in the latest public verification data source on the official website; The subject:serialNumber (OID: 2.5.4.5) field contains a unified social credit code. iTrusChina has disclosed the acceptable registration number format in this field in the latest public verification data source on the official website;".

EVG Section 9.2.6 - subject physical address of place of business must contain the address of the physical location of the business.

Fixed - Section 7.1.2 of the CPS, for EV Subject in the certificate profile, says, “EV certificate: Including country, organization, common name, zip code, registration number, physical address, registered address, be consistent with Section 9.2 in EVGL in CAB Forum, ...."

EVG Sections 9.2.7 and 11.3.1 - the CA shall implement a process that prevents an organizational unit from including a trade name unless the CA has verified that information AND assumed names must be verified with an appropriate government agency or a QIIS that has verified the assumed name with the appropriate government agency.

Fixed - Section 3.2.2.1.1 of the CPS now states, "The EV SSL certificate issued by iTrusChina does not contain the OU field and does not contain a DBA."

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

Fixed - Section 7.1.2 of the CPS, for EV Subject in the certificate profile, says, “EV certificate: ... does not include any subject attributes except as specified in section 9.2 of the EV Guidelines."

EVG Section 9.8.1 - wildcard certificates are not allowed.

Fixed - Section 3.2.2.1.1 of the CPS now states, "The EV SSL certificate application can only be the domain name of a WEB server, IP address application is not accepted, and the domain name cannot contain wildcards."

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

Fixed - Section 3.2.2.1.1 of the CPS now states, "The applicant organization must have the following roles:

Certificate Requester: the handling personnel of the applying unit;

Certificate Approver: the person in charge of the applicant unit;

Contract Signer: The signer of the application agreement."

EVG Section 11.2.2(4) – “principal individuals” of “business entities” must be validated in a face-to-face setting.

OK - Section 3.2.2.1.1 of the CPS now states, "When the content in the subject:businessCategory (OID: 2.5.4.15) field is "Business Entity", the subject of the certificate is an individual business operator, then the certificate applicant must be the operator himself, and must be verified in a "face-to-face" (video) way".

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

Fixed - Section 3.2.2.1.1 of the CPS now states, "The certificate application organization can authorize one or more people to complete all roles. iTrusChina will contact the applicant organization by calling (the company phone number obtained through reliable data sources in 3.2.2.7) to determine the Certificate Requester, Certificate Approver, and Contract Signer personnel name, title and authorization. iTrusChina will use the same method to verify that the signature on the certificate application and subscriber agreement is true and valid."

EVG Section 11.4 and 11.6 - Establishing legal existence, operational existence, and physical existence are three core concepts involved in issuing EV certificates (EVG § 11.1.1). This includes business operations or operational existence. Section 11.6 requires that the CA verify that the applicant has at least the ability to engage in business or a similar type of operations. 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.”

OK (but could be improved in a subsequent CPS) - Section 3.2.2.1.1 of the CPS states, "iTrusChina verifies the Applicant’s legal existence and identity directly with the incorporating agency or registration agency: Verify the applicant’s identity information, business address, and registered address by querying the applicant’s social unified credit code, Corporate Annual Report and business license." And, Annex A, section 10.1 of the CPS says, "iTrusChina will verify the physical address and registered ad dress of the applicant's business place in accordance with the method in this CPS 3.2.2.1." A future version of the CPS should also specify verification of "operational existence," use that term, and explain how iTrusChina complies with EVG section 11.6.

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

Fixed - Section 3.2.2.1.1 of the CPS now states, "iTrusChina will contact the applicant organization by calling (the company phone number obtained through reliable data sources in 3.2.2.7) to determine the Certificate Requester, Certificate Approver, and Contract Signer personnel name, title and authorization. iTrusChina will use the same method to verify that the signature on the certificate application and subscriber agreement is true and valid."

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

Fixed - Section 3.2.2.1.1 of the CPS now states, "iTrusChina will contact the applicant organization by calling (the company phone number obtained through reliable data sources in 3.2.2.7) to determine the Certificate Requester, Certificate Approver, and Contract Signer personnel name, title and authorization. iTrusChina will use the same method to verify that the signature on the certificate application and subscriber agreement is true and valid."

EVG Section 11.12.2 - the CA must check whether the applicant, contract signer, or certificate approver is on denied persons lists, etc.

Fixed - Annex A, section 10.1 of the CPS, now says "iTrusChina will compare the information of the subscriber's organization and applicant, etc. with the known high risk application library and black list maintained by iTrusChina itself, and check whether the Certificate Requester, Certificate Approver and Contract Signer is on the list of denied persons." And "If the subscriber's certificate request information is on the blacklist, Or the Certificate Requester, Certificate Approver and Contract Signer is on the list of denied persons, the certificate request will not be approved;"

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.

Fixed - Section 3.2.2.1.1 of the CPS now states, "After all verification processes and procedures are completed, iTrusChina will have a person who is not responsible for collecting information to review all the information and documents collected to support the EV certificate application, and approve the issuance of the EV SSL certificate."

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

Fixed. Section 5.3.3 of the CPS states that training material includes "BR and EV Guidelines compliance training".

Today, I closed the public discussion period with a recommendation/ announcement of intent to approve the iTrusChina inclusion request. See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/4bWqkOwhzCc/m/-J3JVeydAQAJ . The one-week period for last call will end on 3-November-2021.

Flags: needinfo?(kwilson)
Whiteboard: [ca-in-discussion] 2021-04-07 → [ca-pending-approval] 2021-10-27
Attached file Newly generated ICA —

iTrusChina generated two ICAs (Time Stamping ICA and Adobe Document Signing ICA) at 10 am Beijing time on October 14th.
The entire process strictly followed the script process and was witnessed by the qualified auditor of PWC.
We have released the new CP/CPS and disclosed our two newly generated intermediate CAs on the official website https://www.itrus.com.cn/repository/.

As per Comment #56, and on behalf of Mozilla I approve this request from iTrusChina Co., Ltd. to include the following root certificates:

** vTrus Root CA (Websites); EV
** vTrus ECC Root CA (Websites); EV

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

Flags: needinfo?(kwilson)
Whiteboard: [ca-pending-approval] 2021-10-27 → [ca-approved] - pending NSS and PSM code changes
Depends on: 1740095
Depends on: 1740099

I have filed bug #1740095 against NSS and bug #1740099 against PSM for the actual changes.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Whiteboard: [ca-approved] - pending NSS and PSM code changes → [ca-approved] - In NSS 3.74, FF 97; EV enabled in FF 97
Product: NSS → CA Program
Flags: needinfo?(vTrus_contact)
Flags: needinfo?(vTrus_contact)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: