1647181 - Add BJCA root certificate(s)

Status: RESOLVED FIXED

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

Description

[lipeng]

Attachment: PIT_Report and BR Self-Assessment.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.100 Safari/537.36

Steps to reproduce:

BEIJING CERTIFICATE AUTHORITY Co., Ltd. is a leading information security solution provider in China, and its market share in the field of e-government is in the forefront of the industry, and it has established a market leading advantage application fields such as medical informatization, online insurance, etc. As a compliance CA in China, we conducted WebTrust audit in 2019 to 2020 and have WebTrust seals online in May 2020. 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.

BJCA has two root certificate into the Mozilla Root Store Program.
BJCA Global Root CA1
BJCA Global Root CA2

We attached the point in time audit report and BR Self-Assessment. And the links of the period of time audit reports are available in the CCADB's Root Inclusion Case For BEIJING CERTIFICATE AUTHORITY Co., Ltd. and also availalbe on our main page https://www.bjca.cn.

Please kindly review our application.

Kind regards,
BJCA team
BEIJING CERTIFICATE AUTHORITY Co., Ltd.

Actual results:

Please kindly review our application.

Expected results:

BJCA’s root certificate(s) into the Mozilla Root Store Program.

Comment 1

[lipeng]

Attachment: BJCA's BR Self Assessment

Comment 2

[lipeng]

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

Comment 3

[Ben Wilson]

What further evidence can BJCA provide for us to verify its address as listed in the CCADB as No. 68, North Fourth Ring Road West, Haidian District? For instance, is it in the Zhongguancun Book Building, the Shuangqiao Building, or some other building?

Also, Section 3.2.2.16 of the CPS says, "Verify the applicant's control over the e-mail by sending a verification e-mail to the email address." This is not sufficient email verification for Mozilla. Section 2.2 of the Mozilla Root Store Policy says that 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." The challenge-response process is described here: https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response. Then, the document provides further guidance, https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control, including that "It is not sufficient for the CP/CPS to just say that an email is sent to the customer." This change does not need to be made immediately, but eventually, that section of the CPS will need to be amended. Meanwhile, there may be additional changes that need to be made to the CPS once we have conducted our CP/CPS Review procedures, which are the next steps in the CA inclusion process.

Comment 4

[lipeng]

Hi Mozilla review team,

The office address of BJCA is located on the room 1501 of Zuoan Gongshe Building, which is located at No. 68 North Fourth Ring Road West, Haidian District, Beijing.
The address information has been registered in the business license and Dun & Bradstreet,

1. BJCA business license Num: 91110108722619411A, please visit http://www.gsxt.gov.cn, enter 91110108722619411A to check the registered address of BJCA.
2. BJCA Dun & Bradstreet Num: 421362706, please visit https://www.dnb.com, enter 421362706 to check the registered address of BJCA.

In the meantime, We will revise the CPS in a timely manner based on the Mozilla Root Store Policy and CP/CPS Review procedures feedback and suggestions.

Thanks!

Comment 5

[Ben Wilson]

You can hold off on revising the CPS until I have completed the CPS thorough review. I have moved your inclusion case into the queue for CP/CPS review. There is a backlog, so it might take a month or two to get to it.

Comment 6

[lipeng]

Thanks Ben, Looking forward to your comments based on a review of the BJCA Global CP/CPS v1.0.2 published 6-March-2020. We will combine your comments to make a plan to update CP/CPS to become fully aligned with Mozilla's Root Store Policy.

Comment 7

[Ben Wilson]

Review of Beijing Certification Authority CPS v. 1.0.2 dated March 6, 2020

https://www.bjca.cn/cps/%E5%8C%97%E4%BA%AC%E6%95%B0%E5%AD%97%E8%AE%A4%E8%AF%81%E8%82%A1%E4%BB%BD%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8%E5%85%A8%E7%90%83%E8%AE%A4%E8%AF%81%E4%BD%93%E7%B3%BB%E7%94%B5%E5%AD%90%E8%AE%A4%E8%AF%81%E4%B8%9A%E5%8A%A1%E8%A7%84%E5%88%99.pdf

Mozilla Root Store and Baseline Requirements

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

​ Good - OK

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

​ Needs to be fixed - BJCA CPS implies that no other use of CPS besides reading can be done. BJCA should acknowledge that by applying to the Mozilla Root Program, a Creative Commons license will be assumed/ recognized.

Statement of adherence to BRs and their precedence (MRSP § 2.3) (BR § 2.2)

“The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and those Requirements, those Requirements take precedence.”

​ Good - Section 1.1.2 states that in the event of any inconsistency with the provisions, the provisions issued by the CA/Browser Forum shall prevail. This would include all such requirements—Baseline Requirements, EV Guidelines, and Network and Certificate System Security 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.

​ Good - It appears that separate CAs will be used.

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 – CPS contains hierarchy diagrams and descriptions of CAs.

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 – CPS contains a version control table. Section 1.5.5 also says that the CPS is reversioned at least once per year with the effective time, even if there is no change in content.

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

​ Good – Section 1.3.2 of the CPS states that BJCA will act as the RA and that no third party will be entrusted as an RA.

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

​ Good – Section 1.5.2.1 sets for the email address for a Certificate Problem Report and also mentions the method to submit certificate revocation requests.

Naming compliant with X.500, RFC5280, BRs and EVGs

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

​ Meh – Section 3.1.1 references X.500, however the translation of either the SAN or Distinguished Name into English refers to the DN or SAN as the “topic alias”, which will likely confuse English readers. It is recommended that “topic alias” be replaced with the appropriate technical term. Also, naming should also comply with RFC 5280, the Baseline Requirements and the EV Guidelines.

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

​ OK - Section 3.1.1 states that domain names will be “the domain name owned by the organization” and that the IP address will only be the “IP of external network”. Maybe this a translation issue, but BJCA should make it clear that it will not issue to single host names or non-routable internal domain names that are not part of the external DNS. (Although the CPS does reference the allowed FQDN validation methods from section 3.2.2.4 of the Baseline Requirements – see next.)

ALL certificates must meet Mozilla/BR validation requirements

CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1) CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”. [Note: It is also recommended that CAs ensure that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]

​ Meh - Section 3.2.2.4 of the BJCA CPS describes that domain name validation is performed according to methods described in sections 3.2.2.4.2, 3.2.2.4.4, 3.2.2.2.6, and 3.2.2.4.7 of the Baseline Requirements. BJCA should be aware of weaknesses with the method from section 3.2.2.4.6 as noted here - https://github.com/cabforum/servercert/compare/main...sleevi:2020-12-01_Wildcard_Rules (method NOT suitable for issuing wildcard certificates). So the language in that section that says, “The above methods can be used for domain name validation of wildcard certificates” should be amended.

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 – Section 3.2.2.16 does not have enough explanation of the email verification process. More details need to be added. Currently, it only says, “Verify the applicant’s control over the e-mail by sending a verification e-mail to the e-mail address.” The process must include a challenge-response mechanism. The CA may also have a process that involves just verifying the domain part of the email address if the domain is validated according to BR section 3.2.2.4 and BJCA establishes that the applicant has rightful control over the email accounts. For more details, please read subsection 2 of MRSP 2.2 , 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 need to be accurate (BR § 3.2.2.7 and EVG § 11.11.5)

For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.”

For EV - “A database qualifies as a QIIS if the CA determines that: (1) Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and (2) The database provider updates its data on at least an annual basis.”

​ Good - The CPS references “an authoritative third-party database.” Section 3.2.2.7 states, “the CA shall evaluate the source for its reliability, accuracy, and resistance to alteration or falsification, taking into account the following factors: [age, frequency, purpose, public availability, and difficulty in falsifying].”

​ Needs to be fixed - The CPS does not distinguish OV from EV sources. The EV Guidelines defines a QIIS, a QGIS, and a QGTIS, but the CPS does not describe how BJCA establishes these sources of information. Also, EVG Sections 9.2.4, 9.2.5, and 11.1.3 require BJCA to 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.

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

​ Good – Section 3.2.4 of the CPS states, “non-verified information shall not be included into the certificate.” The CPS could say that all information is verified with an independent source of information. (See previous comment re: independent data sources.)

Data reuse (certificate renewal) limited to 825 days (MRSP § 2.1.5) (BR § 4.2.1)

​ Meh – For SSL/TLS server certificate issuance, BJCA needs to adopt a shorter period for certificate validity and data reuse (e.g. 397 days). See CPS sections 4.7.1 (reuse for 24 months) and 6.3.2 (Global Server Certificates for2 years). (Even though the current reuse requirement says that 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”, this language is likely to change in the near future.)

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

​ Needs to be Fixed – While Section 3.2.2.8 adequately states BJCA’s CAA validation practices, unfortunately section 2.2 of the Baseline Requirements now require that this language appear somewhere in Section 4.2 of the CPS. RFC 6844 has now been replaced by RFC 8659. This language can also be made clearer. For example, what is meant by “The CA will issue a certificate to the certificate applicant within 8 hours of the CAA record. Etc.”? I think it means to say that the CA will check the CAA record, and if it has been longer than 8 hours since that check, the CA will re-check the CAA record before issuance. (BR section 3.2.2.8 actually says, “If the CA issues, they MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater.” BJCA should review the Baseline Requirements’ updated discussions of CAA in Section 2.2, section 3.2.2.8, and Appendix A.

Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3) (BR 6.5.1)

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

​ OK – Section 6.5.1 of the CPS says that a “strict two-factor authentication is implemented for each trusted person who has the business operation authority of the system (including the CA system and the RA system) …”

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”

​ Needs to be fixed - BJCA should state in its CPS that BJCA performs pre-issuance linting to prevent formatting errors in the SSL/TLS server certificates it issues. See e.g. https://github.com/zmap/zlint

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 – Subsection (12) has been moved to a new subsection (4) in BR§4.9.1.1 making 24-hour revocation required if, “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);”. BJCA should also add reasons 10 and 11 of BR 4.9.1.1. (10. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or 11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed.) Also, BJCA should compare the 9 reasons for revocation in BR§4.9.1.2 with 6 reasons currently in section 4.9.1.2 of the BJCA CPS.

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

​ Needs to be fixed – For SMIME certificates trusted by Mozilla, they must also be revoked “[if] 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” and “[if] the certificate was issued in violation of the then-current version of the[] requirements [of the Mozilla Root Store Policy]”.

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

​ Meh – Section 4.9.7 of the CPS does not say how long the CRL is good for (nextUpdate).

CA must not allow certificate suspension (BR § 4.9.13)

​ Good – Sections 4.9.13 through 4.9.16 say “not applicable”.

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

​ Good – Section 4.9.10 of the CPS states that the OCSP is updated every 4 days and has a maximum time of 10 days.

Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7)

“Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”

​ Needs to be fixed- Mozilla and other Application Software Providers need to be notified immediately whenever BJCA suspects that there may have been a CA private key compromise. This language can be placed either somewhere in section 5.7 or in section 4.9.12.

CA must not generate Subscriber key pairs (MRSP § 5.2)

“CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.”

​ Good – Section 6.1.1.2 of the CPS says, “For Global Server Certificates and Timestamp Certificates, the subscriber key pair is generated and maintained by the subscriber.”

Must meet RSA key requirements (MRSP § 5.1) (BR §§ 6.1.5 and 6.1.6)

​ Needs to be fixed –BJCA should implement pre-issuance linting to ensure that public key parameters meet the requirements (not just rely on cryptographic module capabilities). While section 7.1.2 of the CPS illustrates that subscriber certificates need to have at least 2048-bit RSA keys and be signed by sha256, Sections 6.1.5 and 6.1.6 of the BJCA CPS do not provide sufficient assurance that RSA key pairs will comply with the above-referenced Mozilla and CA/Browser Forum requirements, which include “modulus size in bits is divisible by 8, and is at least 2048” and “rsaEncryption OID (1.2.840.113549.1.1.1) with a NULL parameter”. Please refer to sections 6.1.5 and 6.1.6 of the Baseline Requirements and update section 6.1.5 and 6.1.6 of the CPS.

Must meet ECDSA key requirements, P-256 or P-384 (MRSP § 5.1) (BR 6.1.5)

​ Meh – The Baseline Requirements allow P-256, P-384, and P-521, which is fine for the BJCA CPS, but BJCA should know that Mozilla only supports P-256 and P-384. Also, see above.

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

​ Needs to be fixed – Section 6.3.2 of the CPS needs to be updated accordingly.

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 – Currently, Section 6.7 of the CPS is too vague. While section 1.1.2 of the CPS states that BJCA follows the requirements of the Network and Certificate System Security Requirements, and section 5 of the CPS describes physical security, and 5.4.8 describes vulnerability scanning, and section 6.6.3 describes system life-cycle controls, the CPS should describe logical and network security in greater detail. Section 6.7 should be improved with statements of better commitment to the Network and Certificate System Security Requirements. Currently, section 6.7 only says that BJCA “adopts security measures, such as firewall, virus prevention, IDS, IPS, intrusion detection, vulnerability scanning, data backup, and disaster recovery” which is too vague.

Serial numbers greater than 64 bits generated by a CSPRNG (MRSP § 5.2)

“all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG.”

​ Good- CPS states that BJCA uses an 80-bit non-sequential number, greater than zero, from a CSPRNG.

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

​ Needs to be fixed – Not found in the CPS

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

​ Good – No references to SHA1 were found in the CPS.

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

​ Good – But see comment above about “topic alias”. Section 3.1.1 of the CPS states, “For SSL/TLS server certificates, all domain names or IP addresses are added to the topic alias, whereas common name must be a domain name or IP address that exists in the topic alias.”

Extended Validation-specific requirements

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

​ Needs to be fixed – The insurance section of the CPS ought to address this issue.

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 – This could be a translation issue, but these exact terms do not appear in the CPS. Instead CPS Section 3.2.2.12 appears to say that “Business Entities” cannot obtain an EV Certificate because it allows only “enterprises, institutions, societies, and government agencies.” It is unclear without using the language from the EV Guidelines, or cross-references to those sections in the EV Guidelines, whether these map to the same concepts expressed in the EV Guidelines.

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 – EV fields for “jurisdictionLocalityName,” “jurisdictionStateOrProvinceName” and “serialNumber” (Subject Registration Number) were not found in the CPS.

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.

​ Needs to be fixed – “Date of Registration” and “Date of Incorporation” were not found in the CPS.

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 – It is unclear how the EV field “streetAddress” for the physical location of the business is verified / validated.

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.

​ Needs to be fixed– While section 3.2.2.2 of the CPS states four methods for verifying the right to use a DBA or tradename. However, 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. So, a “utility bill, bank statement, government-issued tax document, or other form of identification that the CA determines to be reliable” language is not in the EV Guidelines. For EV certificates, “the CA MUST verify that: (i) the Applicant has registered its use of the assumed name with the appropriate government agency for such filings in the jurisdiction of its Place of Business (as verified in accordance with these Guidelines), and (ii) that such filing continues to be valid.”

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

​ Needs to be fixed – It is unclear how BJCA ensures that it strictly follows the content requirements of the EV Guidelines.

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

​ Good – BJCA specifies the following EV OIDs: 1.2.156.112562.2.2.11 and 2.23.140.1.1

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

​ Needs to be fixed – Section 6.3.2 lacks language regarding the validity period of an EV certificate. This needs to be added. Also, it is recommended that the validity period be set to no more than 397 days.

EVG Section 9.8.1 - wildcard certificates are not allowed.

​ Good – Section 3.1.1 of the CPS states that “topic alias cannot contain wildcards” (this should be changed to say that Common Names and Subject Alternative Names cannot contain wildcard characters).

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

​ Meh – The English translation of the CPS says that the three roles are “Approver” and Applicant” and Signatory”. The CPS would be a lot clearer if these three EV roles were translated as “Certificate Requestor,” “Certificate Approver” and “Contract Signer”.

EVG Section 11.2.2(4) - principal individuals must be validated in a face-to-face setting.

​ Needs to be fixed – CPS Section 3.2.2.12 appears to say that “Business Entities” cannot obtain an EV Certificate because it allows only “enterprises, institutions, societies, and government agencies.” The CPS sections describing identification for EV Code Signing Certificate talk about face-to-face verification, but it is unclear whether the “Principal Individual” (natural person) must personally appear as part of the certificate application process under section CPS section 3.2.2.12. However, there is a section that says “d. Authentication of the person in charge of the EV certificate Must be verified by face-to-face (video) methods.”

EVG Section 11.5.1 - the CA must establish a “Verified Method of Communication” with the applicant.

​ Needs to be fixed – How does BJCA communicate securely with the true applicant? Section 3.2.2.1 says that BJCA will “verify the applicant and its application materials through voice calls, video calls, photos, etc., to ensure that the provided information is consistent with the verification results,” but only “if necessary” will BJCA contact the applicant through a verified phone number. The CPS does not say how the endpoints of communications are initially established as trustworthy with the true organization or individual (natural person) and not a fraudster. For example, does it look up a phone number from a QIIS/QGIS and independently contact the organization? (The RA cannot use unverified, self-provided telephone number or email address from just anyone.) However, there is a sentence in section 3.2.2.12 that says, “d. Authentication of the person in charge of the EV certificate … Confirm that the applicant has been authorized to apply for an EV certificate by contacting the authorizer by calling a landline (must be a verified company phone).” This last sentence is good.

EVG Sections 11.2 and 11.6.1 - the CA must verify that the applicant legally exists and has the ability to engage in business. For example, EVG Section 11.2.2 (1) requires that the CA verify the legal existence of a “Private Organization” directly with the Incorporating Agency or Registration Agency (or from a QIIS). 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 - Clear language that maps to the EV Guidelines was not found in section 3.2.2.12 of the CPS. Subsection 1 says, “Enterprises shall meet the following conditions: … (2) Not listed in the “closed”, “invalid” or “expired” list of the regulatory body” and “(4) Have a fixed place of business”. But subsection (5) of subsection 8 says that the subscriber submits “Proof of the company’s existence (such as the invoice for enterprise telephone charges in the past three months)”. The process says, “It must be verified directly by a qualified independent source of information”, but it could be made more clear how legal existence and real physical existence are established.

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

​ Good – The CPS has domain validation provisions that mirror subsections in 3.2.2.4 of the BRs.

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

​ Needs to be fixed - I did not see in section 3.2.2.12 a description of how the CA verifies the name and title of the person fulfilling these two roles for the applicant.

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

​ Needs to be fixed - I did not see in section 3.2.2.12 a description of how the CA performs signature verification. (According to section 11.9, the CA and applicant may use “a legally valid and enforceable electronic signature (for an electronic Subscriber Agreement and/or EV Certificate Request), that binds the Applicant to the terms of each respective document.”)

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

​ Needs to be fixed – it is not clear how BJCA manages its QIISes, QGISes and QGTISes.

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 – Subsection (3) in subsection 5 in section 3.2.2.12 says that the international organization must “not [be] on any prohibited list listed by the government (such as the trade embargo)”, but additional language is needed about checking databases as to whether the applicant should be denied an EV certificate because it is a terrorist, money launderer, etc., is absent from the CPS. (In subsection 13 of section 4.9.1.1. it says a certificate can be revoked if they are on a blacklist, etc., but there needs to be language about pre-issuance screening.) In other words, a CP says “what” must be done or is allowed/prohibited, but the CPS needs to say “how” this is done.

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 looked in section 4.2 of the CPS and in other locations in the CPS for where this final approval process is described. Language about final checking of the certificate application and a two-person certificate approval process for EV certificates is needed.

EVG Section 11.14.3 - validation data cannot be reused after 13 months

​ Needs to be fixed - See previous recommendation about limiting validation reuse to 397 days.

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

​ Good – Section 6.1.7 of the CPS says that the root CA key can only be used to sign self-signed roots, subordinate CAs and OCSP responses.

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

​ Good – Section 5.3.2 of the CPS describes background check procedures.

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

​ Good – Section 5.3.3 of the CPS states that training covers standards related to EV certificates and that at least once a year there is training and assessment performed.

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.

​ Good – Section 5.3.7 of the CPS states that there is job pre-training and retraining for independent contractors.

Comment 8

[lipeng]

Attachment: BJCA's response to Mozilla's proposed revisions for CPS v1.0.2.pdf

Comment 9

[lipeng]

Hi Ben,

We have published BJCA Global CP/CPS v1.0.3 on 20-January-2021 to address your comments above.

1. Attached is BJCA's response to Mozilla's proposed revisions for CPS v1.0.2: https://bug1647181.bmoattachments.org/attachment.cgi?id=9198157
2. The updated documents can be found in our repository: https://www.bjca.cn/cps
3. Here is BJCA Global CPS v1.0.3: https://www.bjca.cn/cps/%E5%8C%97%E4%BA%AC%E6%95%B0%E5%AD%97%E8%AE%A4%E8%AF%81%E8%82%A1%E4%BB%BD%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8%E5%85%A8%E7%90%83%E8%AE%A4%E8%AF%81%E4%BD%93%E7%B3%BB%E7%94%B5%E5%AD%90%E8%AE%A4%E8%AF%81%E4%B8%9A%E5%8A%A1%E8%A7%84%E5%88%99.pdf

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

Comment 10

[lipeng]

Hi Ben,

BJCA has completed the annual WebTrust audit, the audit report and seal have been officially online:

1. Check the WebTrust seal through BJCA's official website https://www.bjca.cn
   CA：https://www.cpacanada.ca/webtrustseal?sealid=10686
   SSL：https://www.cpacanada.ca/webtrustseal?sealid=10687
   EV SSL：https://www.cpacanada.ca/webtrustseal?sealid=10688
2. CCADB's Root Store Operators may access this page via: https://ccadb.my.salesforce.com/5004o00000L5LO5AAN

Kind regards,
BJCA team

Comment 11

[lipeng]

Hi Ben,

We have released BJCA Global CP/CPS v1.0.4 on June 23, 2021.
In section 4.9.12 of the CPS, the method used by that parties to demonstrate private key compromise is clearly specified.
The updated documents can be found in our repository: https://www.bjca.cn/cps
Here is BJCA Global CPS v1.0.4: https://www.bjca.cn/cps/%E5%8C%97%E4%BA%AC%E6%95%B0%E5%AD%97%E8%AE%A4%E8%AF%81%E8%82%A1%E4%BB%BD%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8%E5%85%A8%E7%90%83%E8%AE%A4%E8%AF%81%E4%BD%93%E7%B3%BB%E7%94%B5%E5%AD%90%E8%AE%A4%E8%AF%81%E4%B8%9A%E5%8A%A1%E8%A7%84%E5%88%99.pdf

Kind regards,
BJCA team

Comment 12

[Ben Wilson]

I am having trouble downloading BJCA Global CP/CPS v1.0.4 from your site. Can you upload the PDF document as an attachment to this bug? Thanks.

Comment 13

[lipeng]

Attachment: BJCA Global CPS v1.0.4.pdf

Hi Ben, BJCA Global CPS v1.0.4 has been uploaded as an attachment to this bug, please review, Thanks.

Comment 14

[Ben Wilson]

Here is some information that might be relevant to BJCA's application for root inclusion: https://therecord.media/spyware-features-found-in-chinese-state-benefits-app/ with a full report and technical details here: https://go.recordedfuture.com/hubfs/reports/cta-2021-0729.pdf.

Comment 15

[lipeng]

Dear Ben,

We had received the security threat analysis report (CTA-CN-2021-0729) mentioning the suspected spyware problem of Beijing One Pass certificate application software. We had carried out security assessment and testing in accordance with the regulations of the Cyberspace Administration of China, and submitted the evaluation report. Here is a brief description of the evaluation report.
Key result: The software mentioned in the security threat analysis report was developed by us and is available for users to download on the pages of government agencies. It has been checked that the official release version of the software does not contain any known spyware, nor is it infected by virus programs. The issues mentioned in the security threat analysis report should be considered as the necessary technical conditions for the normal operation of the software. There are no malicious behaviors or backdoor functions when the program is running, and the software is not spyware.
The key points of technical analysis are as follows:
(1) The software is a application security suite for digital certificates, which aims to provide device driver of USB token and cross-browser cryptographic middleware for end user. The software mainly consists of four parts: certificate application component, certificate assistant, device driver and online upgrading. The software, by setting itself as self-startup program and periodical checking, discovers the USB token device promptly and ensures third-party application softwares’ trust to BJCA certificate chain by registering the Trusted Root Certificate in Windows operating system. And it also support accesing the USB token based on mass storage protocol in the browser by acting as an agent with listening to a local network port. The above behaviors are dedicated technologies for the normal operation of the software, should not be considered as malicious behaviors and backdoor functions.
(2) The software does not include the zfkeymonitor.exe program, and does not include the following suspected behaviors: disable security and backup services not related to this software, record screenshots, read clipboard data, capture and retrieve user keystrokes.
Finally, it should also be noted that the software involved in the security threat analysis report does not include the BJCA Global Root CA1 & BJCA Global Root CA2 certificate chain. We follow the requirements of the relevant guidelines of the CA/B forum for BJCA’s publicly trusted certificate chain. For better user convenience, we have applied for the Root Program of Mozilla, Microsoft, Apple, and Google.

Comment 16

[lipeng]

Hi Ben,

BJCA has completed the annual WebTrust audit, the audit report and seal have been officially online:
1.Check the WebTrust seal through BJCA's official website https://www.bjca.cn
CA：https://www.cpacanada.ca/GenericHandlers/CPACHandler.ashx?AttachmentID=389f5843-e05f-4e80-aae0-23cee8922866
BR SSL：https://www.cpacanada.ca/GenericHandlers/CPACHandler.ashx?AttachmentID=2c0c075a-0000-40f1-8a81-1ccb21268e62
EV SSL：https://www.cpacanada.ca/GenericHandlers/CPACHandler.ashx?AttachmentID=78bb08b0-7523-4011-b27c-b8a1a978433e
2.CCADB's Root Store Operators may access this page via: https://ccadb.my.salesforce.com/5008Z00001uulR6QAI

Kind regards,
BJCA team

Comment 17

[Ben Wilson]

Thanks. I will process this audit information in the CCADB and re-check your inclusion application. Also, please review this page and prepare a response. https://wiki.mozilla.org/CA/Quantifying_Value
Thanks again,
Ben

Comment 18

[Ben Wilson]

Your CPS URL specified in the CCADB (https://ccadb.force.com/5008Z00001uulR6QAI) is the same as your CP URL. Also, the older CPS link does not seem to work (https://www.bjca.cn/cps/BJCA%20Global%20CP.pdf vs. https://www.bjca.cn/cps/BJCA%20Global%20CPS.pdf). Both redirect to https://www.bjca.cn/service/down_196.html.

Comment 19

[lipeng]

Thanks. The repository path for BJCA to publish CP and CPS is https://www.bjca.cn/cps， the path is also redirected to https://www.bjca.cn/service/down_196.html For the related parties to download and view the current and historical versions of BJCA Global CP and CPS.
When we submitted CA Audit Update Request Case in CCADB (https://ccadb.force.com/5008Z00001uulR6QAI) , because the download path of CP and CPS was long, we could not input the complete path into the Policy Document Link, so we pointed the Document Link to https://www.bjca.cn/cps.
Thanks again,
BJCA team

Comment 20

[Ben Wilson]

The page https://www.bjca.cn/service/down_196.html is fine for a general reference to your document repository, but the redirects for PDFs (English versions) to https://www.bjca.cn/service/down_196.html just makes it more confusing and harder to locate the specific, current CP and CPS that I need to review. Please provide the URLs for the current English versions of the CP and CPS here so that I can find them easier and see if I can input the URLs into the CCADB.

Comment 21

[Ben Wilson]

I am assuming that the CP link is
https://www.bjca.cn/u4d/%E8%AF%81%E4%B9%A6%E7%AD%96%E7%95%A5%EF%BC%88CP%EF%BC%89/files/%E5%8C%97%E4%BA%AC%E6%95%B0%E5%AD%97%E8%AE%A4%E8%AF%81%E8%82%A1%E4%BB%BD%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8%E5%85%A8%E7%90%83%E8%AE%A4%E8%AF%81%E4%BD%93%E7%B3%BB%E8%AF%81%E4%B9%A6%E7%AD%96%E7%95%A5%20Beijing%20Certificate%20Authority%20Co.,%20Ltd.%20Global%20Certificate%20Policy.pdf
and that the CPS link is:
https://www.bjca.cn/u4d/%E7%94%B5%E5%AD%90%E8%AE%A4%E8%AF%81%E4%B8%9A%E5%8A%A1%E8%A7%84%E5%88%99%EF%BC%88CPS%EF%BC%89/files/%E5%8C%97%E4%BA%AC%E6%95%B0%E5%AD%97%E8%AE%A4%E8%AF%81%E8%82%A1%E4%BB%BD%E6%9C%89%E9%99%90%E5%85%AC%E5%8F%B8%E5%85%A8%E7%90%83%E8%AE%A4%E8%AF%81%E4%BD%93%E7%B3%BB%E7%94%B5%E5%AD%90%E8%AE%A4%E8%AF%81%E4%B8%9A%E5%8A%A1%E8%A7%84%E5%88%99%20Beijing%20Certificate%20Authority%20Co.,%20Ltd.%20Global%20Certification%20Practice%20Statement.pdf
Correct?

Comment 22

[lipeng]

Thanks. The CP and CPS links of the current English version you viewed are correct.

Comment 23

[Ben Wilson]

Attachment: Quantifying-Value--BJCA -2022.7.7.pdf

Comment 24

[Ben Wilson]

Here is my review of the BJCA CPS version 1.5

BJCA's response to Mozilla's proposed revisions for CPS V1.0.2
Mozilla's suggested revisions for CPS	BJCA's response to Mozilla's proposed revisions for CPS	Review Based on CPS Version 1.5
Naming compliant with X.500, RFC5280, BRs and EVGs The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards. Meh – Section 3.1.1 references X.500, however the translation of either the SAN or Distinguished Name into English refers to the DN or SAN as the “topic alias”, which will likely confuse English readers. It is recommended that “topic alias” be replaced with the appropriate technical term. Also, naming should also comply with RFC 5280, the Baseline Requirements and the EV Guidelines.	Revised in CPS Version 1.0.3: 1. For the SAN English translation involved throughout the CPS, revised it to Subject Alternative Name to avoid confuse English readers. 2. Added rule description in CPS Section 3.1.1: The digital certificate issued by the CA complies with X.509 standard, RFC5280 standard, CA/Browser Forum Baseline Requirements and EV Guidelines, and contains the issuing authority and the distinguished name of the certificate subscriber.	Fixed. In CPS section 9.6.1, I noticed a reference to the "subject alias extension", but that is a very minor matter.
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.” OK - Section 3.1.1 states that domain names will be “the domain name owned by the organization” and that the IP address will only be the “IP of external network”. Maybe this a translation issue, but BJCA should make it clear that it will not issue to single host names or non-routable internal domain names that are not part of the external DNS. (Although the CPS does reference the allowed FQDN validation methods from section 3.2.2.4 of the Baseline Requirements – see next.)	Revised in CPS Version 1.0.3: 1. For the “IP of external network” English translation involved throughout the CPS, revised it to public IP address to avoid confuse English readers. 2. Added rule description in CPS Section 3.2.2.5: According to the requirements of CA/Browser Forum, the CA does not issue a certificate for a Reserved IP Address marked by IANA or non-routable internal domain names.	Fixed.
ALL certificates must meet Mozilla/BR validation requirements CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1) CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”. [Note: It is also recommended that CAs ensure that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used to facilitate surreptitious interception by third parties (except with the domain registrant's permission).] Meh - Section 3.2.2.4 of the BJCA CPS describes that domain name validation is performed according to methods described in sections 3.2.2.4.2, 3.2.2.4.4, 3.2.2.2.6, and 3.2.2.4.7 of the Baseline Requirements. BJCA should be aware of weaknesses with the method from section 3.2.2.4.6 as noted here - https://github.com/cabforum/servercert/compare/main...sleevi:2020-12 -01_Wildcard_Rules (method NOT suitable for issuing wildcard certificates). So the language in that section that says, “The above methods can be used for domain name validation of wildcard certificates” should be amended.	Revised in CPS Version 1.0.3: 1. Removed the description in section 3.2.2.4 of CPS that The above methods can be used for domain name validation of wildcard certificates. 2. Added a rule description in Section 3.2.2.6 of CPS: The CA shall confirm the applicant's ownership of and control over the domain name to the right of the wildcard by using one of the validation methods in Section 3.2.2.4 domain name validation method 1, verification method 2 and verification method 4 of this CPS.	Fixed.
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 – Section 3.2.2.16 does not have enough explanation of the email verification process. More details need to be added. Currently, it only says, “Verify the applicant’s control over the e-mail by sending a verification e-mail to the e-mail address.” The process must include a challenge-response mechanism. The CA may also have a process that involves just verifying the domain part of the email address if the domain is validated according to BR section 3.2.2.4 and BJCA establishes that the applicant has rightful control over the email accounts. For more details, please read subsection 2 of MRSP 2.2 , https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Emai l_Challenge-Response, and https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verif ying_Email_Address_Control.	Revised in CPS Version 1.0.3: 1. Added Section 3.2.2.9 to CPS for email address verification and authentication, describing the email address verification process. 2. For email address involved in verification and authentication of domain name in Section 3.2.2.4 of CPS, refer to the email address verification and authentication method in Section 3.2.2.9 of CPS. 3. For email address involved in verification and authentication of an IP Address in Section 3.2.2.5 of CPS, refer to the email address verification and authentication method in Section 3.2.2.9. 4. For email address involved in authentication of S/MIME Email certificate subscriber identity in Section 3.2.2.17 of CPS, confirm the effectiveness and control of the applicant's email address by referring to the verification and authentication method of mail address in Section 3.2.2.9 of CPS.	Fixed.
Data sources need to be accurate (BR § 3.2.2.7 and EVG § 11.11.5) For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.” For EV - “A database qualifies as a QIIS if the CA determines that: (1) Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and (2) The database provider updates its data on at least an annual basis.” Good - The CPS references “an authoritative third-party database.” Section 3.2.2.7 states, “the CA shall evaluate the source for its reliability, accuracy, and resistance to alteration or falsification, taking into account the following factors: [age, frequency, purpose, public availability, and difficulty in falsifying].” Needs to be fixed - The CPS does not distinguish OV from EV sources. The EV Guidelines defines a QIIS, a QGIS, and a QGTIS, but the CPS does not describe how BJCA establishes these sources of information. Also, EVG Sections 9.2.4, 9.2.5, and 11.1.3 require BJCA to 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.	Revised in CPS Version 1.0.3: 1. CPS Section 2.1 Repositories Added Description of Authentication Data Source for EV Certificates: The CA's repository provides information services to subscribers and relying parties, and the information services include, but are not limited to, the following content: root certificates and subordinate CA certificates, current and historical versions of CP and CPS, CRLs, Authentication Data Source for EV Certificates, and information irregularly issued by BJCA. 2. Section 3.2.2.7 of Data Source Accuracy is added to CPS to describe the establishment and disclosure rules of Authentication Data Source for EV Certificates. 3. For data source accuracy increased description in Section 3.2.2.7 of CPS, comply with CA/Browser Forum Baseline Requirements section 3.2.2.7 and EV Guidelines section 11.11 for data source requirements.	Fixed.
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.” Good – Section 3.2.4 of the CPS states, “non-verified information shall not be included into the certificate.” The CPS could say that all information is verified with an independent source of information. (See previous comment re: independent data sources.)	BJCA complies with MRSP § 2.2.1 that All information in a certificate must be verified. In CPS Section 3.2.4 states that non-verified information shall not be included into the certificate.
Data reuse (certificate renewal) limited to 825 days (MRSP § 2.1.5) (BR § 4.2.1) Meh – For SSL/TLS server certificate issuance, BJCA needs to adopt a shorter period for certificate validity and data reuse (e.g. 397 days). See CPS sections 4.7.1 (reuse for 24 months) and 6.3.2 (Global Server Certificates for2 years). (Even though the current reuse requirement says that 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”, this language is likely to change in the near future.)	Revised in CPS Version 1.0.3: 1. For CPS section 4.7.1, the data reuse (certificate renewal) limit is revised from no more than 24 months to no more than the maximum validity period of such certificate as specified in Section 6.3.2 of this CPS. 2. For CPS section 6.3.2, the validity period of SSL global server certificate is revised to no more than 397 days.	Fixed.
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.” Needs to be Fixed – While Section 3.2.2.8 adequately states BJCA’s CAA validation practices, unfortunately section 2.2 of the Baseline Requirements now require that this language appear somewhere in Section 4.2 of the CPS. RFC 6844 has now been replaced by RFC 8659. This language can also be made clearer. For example, what is meant by “The CA will issue a certificate to the certificate applicant within 8 hours of the CAA record. Etc.”? I think it means to say that the CA will check the CAA record, and if it has been longer than 8 hours since that check, the CA will re-check the CAA record before issuance. (BR section 3.2.2.8 actually says, “If the CA issues, they MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater.” BJCA should review the Baseline Requirements’ updated discussions of CAA in Section 2.2, section 3.2.2.8, and Appendix A.	Revised in CPS Version 1.0.3: 1. RFC6844 in Section 3.2.2.8 of CPS is revised to RFC8659, and revised CAA records limitation that The CA will issue a certificate to the certificate applicant within the validity period of the CAA record (the TTL of the CAA record, or 8 hours, whichever is greater). If the validity period of CAA record is expired, the CA will re-check the CAA. 2. Added a description in Section 4.2.1 of the CPS: The CA will perform a CAA record check for each dNSName in the certificate Subject Alternative Name extension of a Global Server Certificate to be issued, and determine whether to approve the certificate application according to the inspection method and result in Section 3.2.2.8 of this CPS.	Fixed.
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” Needs to be fixed - BJCA should state in its CPS that BJCA performs pre-issuance linting to prevent formatting errors in the SSL/TLS server certificates it issues. See e.g. https://github.com/zmap/zlint	BJCA performed pre-issuance linting, revised in CPS Version 1.0.3: 1. Added a description in Section 4.3.1 of the CPS: For the issue of SSL Global Server Certificate, before applying for SCT data, the CA performs pre-issuance linting tools. If an error or warning is found, the issuance is held up for manual review to prevent the issuance of certificates that violate Baseline Requirements. 2. Added a description in Section 6.1.5 of the CPS: The CA use three linting tools(certlint, x509lint and zlint) to ensure that the algorithm type and key size meets the requirements of the Baseline Requirements published by the CA/Browser Forum. 3. Added a description in Section 6.1.6 of the CPS: The CA use three linting tools(certlint, x509lint and zlint) to ensure that the public key parameters meets the requirements of the Baseline Requirements published by the CA/Browser Forum.	Fixed.
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 – Subsection (12) has been moved to a new subsection (4) in BR§4.9.1.1 making 24-hour revocation required if, “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);”. BJCA should also add reasons 10 and 11 of BR 4.9.1.1. (10. Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or 11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed.) Also, BJCA should compare the 9 reasons for revocation in BR§4.9.1.2 with 6 reasons currently in section 4.9.1.2 of the BJCA CPS.	Compare the reasons for revocation in CPS with those in BR § 4.9.1.1 and BR § 4.9.1.2 and revised in CPS Version 1.0.3: 1. In section 4.9.1.1 of CPS, reasons for revocation of certificate within 24 hours are added as follows: (4) 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); (6) 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. 2. In section 4.9.1.1 of CPS, the reasons for revoking the certificate within 5 days are added as follows: (10) Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; (11) The CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed. 3. In CPS section 4.9.1.2, the reasons for revoking the subordinate CA certificate within 7 days are added: (1) The Subordinate CA requests revocation in writing; (2) The Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization; (9) Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement.	Fixed. BJCA may want to clarify its intent regarding revocation in 5 days. Right now, the CPS says "The CA shall revoke the certificate within 24 hours if one or more of the following occurs …" I think the Baseline Requirements use a "should" in this langauge of BR section 4.9.1.1.
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 …” Needs to be fixed – For SMIME certificates trusted by Mozilla, they must also be revoked “[if] 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” and “[if] the certificate was issued in violation of the then-current version of the[] requirements [of the Mozilla Root Store Policy]”.	Revised in CPS Version 1.0.3: 1. In section 4.9.1.1 of CPS, reasons for revocation of certificate within 24 hours are added as follows: (6) 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. 2. Reasons for revoking the certificate within 5 days in CPS section 4.9.1.1, reasons for revision: (1) The certificate no longer complies with the requirements of Mozilla Root Store Policy or Sections 6.1.5 and 6.1.6 of the Baseline Requirements of the CA/Browser Forum.	Fixed.
CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6) (BR § 4.9.7) Meh – Section 4.9.7 of the CPS does not say how long the CRL is good for (nextUpdate).	Revised in CPS Version 1.0.3: In CPS section 4.9.7, it is revised as follows: (1) The subscriber certificate CRLs are valid for 3 days (the value of the nextUpdate field exceeds the value of the thisUpdate field by 3 days); (2) The subordinate CA certificate CRLs are valid for 12 months (the value of the nextUpdate field exceeds the value of the thisUpdate field by 12 months).	Fixed.
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.” Needs to be fixed- Mozilla and other Application Software Providers need to be notified immediately whenever BJCA suspects that there may have been a CA private key compromise. This language can be placed either somewhere in section 5.7 or in section 4.9.12.	Revised in CPS Version 1.0.3: Added a description in section 5.7.3 of CPS: When the private key of Root CA Certificate or Subordinate CA Certificate is compromised or certificate is revoked, the CA will notify the relying party and application software supplier including Mozilla/Microsoft/Apple/Google/360, etc. through email immediately.	Fixed.
Must meet RSA key requirements (MRSP § 5.1) (BR §§ 6.1.5 and 6.1.6) Needs to be fixed –BJCA should implement pre-issuance linting to ensure that public key parameters meet the requirements (not just rely on cryptographic module capabilities). While section 7.1.2 of the CPS illustrates that subscriber certificates need to have at least 2048-bit RSA keys and be signed by sha256, Sections 6.1.5 and 6.1.6 of the BJCA CPS do not provide sufficient assurance that RSA key pairs will comply with the above-referenced Mozilla and CA/Browser Forum requirements, which include “modulus size in bits is divisible by 8, and is at least 2048” and “rsaEncryption OID (1.2.840.113549.1.1.1) with a NULL parameter”. Please refer to sections 6.1.5 and 6.1.6 of the Baseline Requirements and update section 6.1.5 and 6.1.6 of the CPS.	Revised in CPS Version 1.0.3: 1. In section 6.1.5 of CPS, it is revised as follows: (1) The key length of Root CA Certificate of RSA algorithm is 4096 bits, and the signature algorithm is sha256RSA; the key length of Root CA Certificate of ECC algorithm is 384 bits (NIST P-384), and the signature algorithm is sha384ECDSA. (2) The key length of Subordinate CA Certificate of RSA algorithm is 2048 bits, and the signature algorithm is sha256RSA; the key length of Subordinate CA Certificate of ECC algorithm is 256 bits(NIST P-256), and the signature algorithm is sha256ECDSA. (3) The key length of Subscriber Certificate of RSA algorithm is 2048 bits, and the signature algorithm is sha256RSA; the key length of Subscriber Certificate of ECC algorithm is 256 bits(NIST P-256), and the signature algorithm is sha256ECDSA. (4) The CA use three linting tools(certlint, x509lint and zlint) to ensure that the algorithm type and key size meets the requirements of the Baseline Requirements published by the CA/Browser Forum. 2. Revise in CPS section 6.1.6: The CA use three linting tools(certlint, x509lint and zlint) to ensure that the public key parameters meets the requirements of the Baseline Requirements published by the CA/Browser Forum.	Fixed.
Must meet ECDSA key requirements, P-256 or P-384 (MRSP § 5.1) (BR 6.1.5) Meh – The Baseline Requirements allow P-256, P-384, and P-521, which is fine for the BJCA CPS, but BJCA should know that Mozilla only supports P-256 and P-384. Also, see above.	Revised in CPS Version 1.0.3: In section 6.1.5 of CPS, it is revised as follows: (1) the key length of Root CA Certificate of ECC algorithm is 384 bits(NIST P-384), and the signature algorithm is sha384ECDSA. (2) the key length of Subordinate CA Certificate of ECC algorithm is 256 bits(NIST P-256), and the signature algorithm is sha256ECDSA. (3) the key length of Subscriber Certificate of ECC algorithm is 256 bits(NIST P-256), and the signature algorithm is sha256ECDSA.	Fixed.
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.” Needs to be fixed – Section 6.3.2 of the CPS needs to be updated accordingly.	Revised in CPS Version 1.0.3: For CPS section 6.3.2, the validity period of SSL global server certificate is revised to no more than 397 days.	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 – Currently, Section 6.7 of the CPS is too vague. While section 1.1.2 of the CPS states that BJCA follows the requirements of the Network and Certificate System Security Requirements, and section 5 of the CPS describes physical security, and 5.4.8 describes vulnerability scanning, and section 6.6.3 describes system life-cycle controls, the CPS should describe logical and network security in greater detail. Section 6.7 should be improved with statements of better commitment to the Network and Certificate System Security Requirements. Currently, section 6.7 only says that BJCA “adopts security measures, such as firewall, virus prevention, IDS, IPS, intrusion detection, vulnerability scanning, data backup, and disaster recovery” which is too vague.	Revised in CPS Version 1.0.3: Detailed description of CPS section 6.7 network security controls: (1) The CA adopts the protection of multi-level firewall and network control systems and implements perfect access control technology. (2) Authentication system only opens the relevant operation functions with the certificate application , checking the certificate to operate by network for users. (3) In order to ensure network security, CA's authentication system installs firewall, intrusion detection, security auditing, virus protection system, and update the version of firewall, intrusion detection, security audits, virus protection system , as much as possible to reduce the risk from the network. (4) CA's network security control complies with CA/B Forum NCSSR.	Fixed.
EKUs required in certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f) Needs to be fixed – Not found in the CPS	Revised in CPS Version 1.0.3: The SSL Global Server Certificates, Code Signing Certificates, Timestamp Certificates and S/MIME Email Certificates issued by the CA contain Extended Key Usage, In CPS section 7.1.2 the table for Extended Key Usage, the Extended Key Usage contained in subscriber certificate is stated as follows: (1) SSL Global Server certificate includes Server Authentication (1.3.6.1.5.5.7.3.1) and Client Authentication (1.3.6.1.5.5.7.3.2). (2) Code Signing certificate contains Code Signing(1.3.6.1.5.5.7.3.3). (3) Timestamp certificate contains Time stamp (1.3.6.1.5.5.7.3.8). (4) Email certificate includes Client Authentication (1.3.6.1.5.5.7.3.2) and Secure e-mail (1.3.6.1.5.5.7.3.4).	OK - but BJCA should clarify this more in its next version of the CPS. In the current CPS, the certificate profiles for subordinate certificates indicate that the EKU might be absent from the subordinate CA certificate. This is no longer allowed. All subordinate CAs created after July 1, 2020, must be populated with all applicable EKUs, according to the rules as to which EKUs are allowed to be in a CA certificate for a given CA type.
EVG Section 8.4 - the CA shall maintain liability insurance of US$2 million and professional liability insurance of US$5 million. Needs to be fixed – The insurance section of the CPS ought to address this issue.	Revised in CPS Version 1.0.3: It is stated in CPS section 9.2.3 that The CA determines its insurance policies according to its business development and the business of domestic insurance companies. The CA has undergone financial auditing provided by third party auditors, and has reserved suitable cash assets for planned customers as financial guarantee for compensation arising from certification operation.	Meh - but OK
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 – This could be a translation issue, but these exact terms do not appear in the CPS. Instead CPS Section 3.2.2.12 appears to say that “Business Entities” cannot obtain an EV Certificate because it allows only “enterprises, institutions, societies, and government agencies.” It is unclear without using the language from the EV Guidelines, or cross-references to those sections in the EV Guidelines, whether these map to the same concepts expressed in the EV Guidelines.	Revised in CPS Version 1.0.3: In CPS section 3.2.2.13 Authentication of EV SSL Global Server Certificate Subscriber Identity, the English translations of "Government Entity", "Business Entity", "Private Organization", "Non-Commercial Entity" are used, such as: If the subscriber applying for an EV SSL Global Server Certificate is an organization, it may apply to the CA or an authorized RA. The EV SSL Global Server Certificate application can only be the domain name of the WEB server, and the domain name cannot contain wildcards. The application for the IP address is not accepted. The EV SSL Global Server Certificates can include multiple domain name certificates. Applicant subscribers can only be organizations such as Government Entity, Business Entity, and Private Organization.	Fixed.
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 – EV fields for “jurisdictionLocalityName,” “jurisdictionStateOrProvinceName” and “serialNumber” (Subject Registration Number) were not found in the CPS.	Revised in CPS Version 1.0.3: The Subject DN is stated in the table for the basic domain content of the certificate structure in Section 7.1 of CPS. DN of subscriber EV SSL Certificate, including CN, OU, O, streetAddress, postalCode, L, S, C, serialNumber, businessCategory, jurisdictionLocalityName (OID: 1.3.6.1.4.1.311.60.2.1.1), jurisdictionStateOrProvinceName (OID: 1.3.6.1.4.1.311.60.2.1.2), jurisdictionCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3), The above certificate Subject Distinguished Name are consistent with the requirements of Section 9.2 of the CA/Browser Forum EV Guidelines and do not include any Subject attributes except as specified in Section 9.2.	Fixed.
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. Needs to be fixed – “Date of Registration” and “Date of Incorporation” were not found in the CPS.	1. In Authentication Data Source for EV Certificates disclosed by BJCA section 3.1Subject: serialNumber, it is stated that In mainland China, this field is generally the unified social credit code. For users in Hong Kong, China, this field is the company registry number of the Hong Kong Government Companies Registry. If the Jurisdiction of Incorporation or Registration does not provide a Registration Number, this field is the date of Incorporation or Registration. 2. The Subject DN is stated in the table for the basic domain content of the certificate structure in Section 7.1 of CPS. DN of subscriber EV SSL Certificate, including CN, OU, O, streetAddress, postalCode, L, S, C, serialNumber, businessCategory, jurisdictionLocalityName (OID: 1.3.6.1.4.1.311.60.2.1.1), jurisdictionStateOrProvinceName (OID: 1.3.6.1.4.1.311.60.2.1.2), jurisdictionCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3), The above certificate Subject Distinguished Name are consistent with the requirements of Section 9.2 of the CA/Browser Forum EV Guidelines and do not include any Subject attributes except as specified in Section 9.2.	OK
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 – It is unclear how the EV field “streetAddress” for the physical location of the business is verified / validated.	1. In Authentication Data Source for EV Certificates disclosed by BJCA section 2.4 Company Address, it is stated that through National Enterprise Credit Information Publicity System, China Organization Data Service, National Public Institution Registration Administration, Integrated Companies Registry Information System (ICRIS) (Hong Kong), cninfo, Dun & Bradstreet verification of the company's registered streetaddress. 2. Revised in CPS Version 1.0.3: In CPS section 3.2.2.13 a. Verify the legality of the applicant organization: Query the registration code (such as unified social credit code) of the applicant organization through Authentication Data Source for EV Certificates; verify the identity information and registered address of the applicant; It must be verified directly by a qualified independent source of information. In CPS section 3.2.2.13 b. Content of organization verification: Whether the identity information of the applicant organization exists; Whether the identity information of the applicant organization is accurate; Whether the business address provided by the applicant organization is consistent with the registered address in the registration document (such as business license).	Needs to be discussed with BJCA or clarified in the CPS.
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. Needs to be fixed– While section 3.2.2.2 of the CPS states four methods for verifying the right to use a DBA or tradename. However, 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. So, a “utility bill, bank statement, government-issued tax document, or other form of identification that the CA determines to be reliable” language is not in the EV Guidelines. For EV certificates, “the CA MUST verify that: (i) the Applicant has registered its use of the assumed name with the appropriate government agency for such filings in the jurisdiction of its Place of Business (as verified in accordance with these Guidelines), and (ii) that such filing continues to be valid.”	Revised in CPS Version 1.0.3: In CPS section 3.2.2.2, the CA or the authorized RA shall verify the applicant’s right to use the DBA or tradename using at least one of the following ways: (1) Valid documents provided by a government agency in the jurisdiction of the applicant’s legal creation, existence, or recognition. (2) A reliable data source. (eg: Dun & Bradstreet, Ministry of Commerce Foreign trade operator registration) (3) Other DBA/Tradename's authentication methods that the CA determines to be reliable.	Fixed.
EVG Section 9.2.9 - the CA shall not include any subject attributes except as specified in section 9.2 of the EV Guidelines. Needs to be fixed – It is unclear how BJCA ensures that it strictly follows the content requirements of the EV Guidelines.	Revised in CPS Version 1.0.3: The Subject DN is stated in the table for the basic domain content of the certificate structure in Section 7.1 of CPS. DN of subscriber EV SSL Certificate, including CN, OU, O, streetAddress, postalCode, L, S, C, serialNumber, businessCategory, jurisdictionLocalityName (OID: 1.3.6.1.4.1.311.60.2.1.1), jurisdictionStateOrProvinceName (OID: 1.3.6.1.4.1.311.60.2.1.2), jurisdictionCountryName (OID: 1.3.6.1.4.1.311.60.2.1.3), The above certificate Subject Distinguished Name are consistent with the requirements of Section 9.2 of the CA/Browser Forum EV Guidelines and do not include any Subject attributes except as specified in Section 9.2.	Fixed.
EVG Section 9.4 - the validity period for an EV certificate shall not exceed 398 days Needs to be fixed – Section 6.3.2 lacks language regarding the validity period of an EV certificate. This needs to be added. Also, it is recommended that the validity period be set to no more than 397 days.	Revised in CPS Version 1.0.3: For CPS section 6.3.2, the validity period of SSL global server certificate is revised to no more than 397 days.	Fixed
EVG Section 10.1.2 - the roles of certificate requestor, certificate approver, and contract signer are required as part of the process for issuing EV certificates. Meh – The English translation of the CPS says that the three roles are “Approver” and Applicant” and Signatory”. The CPS would be a lot clearer if these three EV roles were translated as “Certificate Requestor,” “Certificate Approver” and “Contract Signer”.	Revised in CPS Version 1.0.3: The English translation of the three EV roles in section 3.2.2.13 of CPS, namely "Approver", "Applicant" and "Signatory", is revised to "Certificate Approver", "Certificate Requestor" and "Contract Signer".	Fixed.
EVG Section 11.2.2(4) - principal individuals must be validated in a face-to-face setting. Needs to be fixed – CPS Section 3.2.2.12 appears to say that “Business Entities” cannot obtain an EV Certificate because it allows only “enterprises, institutions, societies, and government agencies.” The CPS sections describing identification for EV Code Signing Certificate talk about face-to-face verification, but it is unclear whether the “Principal Individual” (natural person) must personally appear as part of the certificate application process under section CPS section 3.2.2.12. However, there is a section that says “d. Authentication of the person in charge of the EV certificate Must be verified by face-to-face (video) methods.”	Revised in CPS Version 1.0.3: 1. “Business Entities” can obtain an EV Certificate, in CPS section 3.2.2.13 Authentication of EV SSL Global Server Certificate Subscriber Identity, the English translations of "Government Entity", "Business Entity", "Private Organization", are used, such as: Applicant subscribers can only be organizations such as Government Entity, Business Entity, and Private Organization. 2. For the "principal individual" (natural person) applicant, Approver, and Signer of EV Certificate, used the English translations "Certificate Requestor", "Certificate Approver", "Contract Signer", Revised in CPS Section 3.2.2.13 d. Authentication of EV certificate applicant's principal individual: EV certificate requestor (When individual businesses apply for EV certificate, the certificate requestor must be the operator himself) must be verified by face-to-face (video) methods; Verify identity information through the Ministry of Public Security identity verification platform; Contact the personnel department of the application organization by dialing the fixed line telephone (must be the company phone number obtained from the authentication data source) to confirm the identity and authorization of Certificate Requestor, Certificate Approver and Contract Signer.	Fixed.
EVG Section 11.5.1 - the CA must establish a “Verified Method of Communication” with the applicant. Needs to be fixed – How does BJCA communicate securely with the true applicant? Section 3.2.2.1 says that BJCA will “verify the applicant and its application materials through voice calls, video calls, photos, etc., to ensure that the provided information is consistent with the verification results,” but only “if necessary” will BJCA contact the applicant through a verified phone number. The CPS does not say how the endpoints of communications are initially established as trustworthy with the true organization or individual (natural person) and not a fraudster. For example, does it look up a phone number from a QIIS/QGIS and independently contact the organization? (The RA cannot use unverified, self-provided telephone number or email address from just anyone.) However, there is a sentence in section 3.2.2.12 that says, “d. Authentication of the person in charge of the EV certificate … Confirm that the applicant has been authorized to apply for an EV certificate by contacting the authorizer by calling a landline (must be a verified company phone).” This last sentence is good.	1. In Authentication Data Source for EV Certificates disclosed by BJCA section 2.3 Company Phone, it is stated that Verify the company phone number by dialing 114 or inquiring the National Enterprise Credit Information Publicity System or cninfo. 2. In CPS section 3.2.2.1, the description of establishing safe communication with institutions is revised: (2) Check the authorization documents authorized by the organization to the authorized representative to handle the certificate and the valid government-issued photo ID of the authorized representative to ensure that the authorized representative is authorized by the organization. The CA can contact the applicant through a telephone number obtained by Authentication Data Source to confirm the authenticity of some information of the applicant, such as verifying whether a person in the application form is an authorized representative. (3) Verify the certificate request with the certificate applicant and confirm the true intention of the applicant through SMS, bank payment postscript, etc.	OK
EVG Sections 11.2 and 11.6.1 - the CA must verify that the applicant legally exists and has the ability to engage in business. For example, EVG Section 11.2.2 (1) requires that the CA verify the legal existence of a “Private Organization” directly with the Incorporating Agency or Registration Agency (or from a QIIS). 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 - Clear language that maps to the EV Guidelines was not found in section 3.2.2.12 of the CPS. Subsection 1 says, “Enterprises shall meet the following conditions: … (2) Not listed in the “closed”, “invalid” or “expired” list of the regulatory body” and “(4) Have a fixed place of business”. But subsection (5) of subsection 8 says that the subscriber submits “Proof of the company’s existence (such as the invoice for enterprise telephone charges in the past three months)”. The process says, “It must be verified directly by a qualified independent source of information”, but it could be made more clear how legal existence and real physical existence are established.	Revised in CPS Version 1.0.3: In CPS section 3.2.2.13 c. Verify operational existence of the applicant organization: Through Authentication Data Source for EV Certificates, query the registration code of the applicant organization to verify its operational existence or query the bank capital verification report provided by the applicant organization to verify its operational existence status.	OK
EVG Section 11.8.1 - the CA must verify the name and title of the contract signer and certificate approver. Needs to be fixed - I did not see in section 3.2.2.12 a description of how the CA verifies the name and title of the person fulfilling these two roles for the applicant.	Revised in CPS Version 1.0.3: In CPS section 3.2.2.13 d. Authentication of EV certificate applicant's principal individua: EV certificate requestor (When individual businesses apply for EV certificate, the certificate requestor must be the operator himself) must be verified by face-to-face (video) methods; Verify identity information through the Ministry of Public Security identity verification platform; Contact the personnel department of the application organization by dialing the fixed line telephone (must be the company phone number obtained from the authentication data source) to confirm the identity and authorization of Certificate Requestor, Certificate Approver and Contract Signer.	Fixed.
EVG Section 11.9 - the CA must verify the signature on the subscriber agreement and certificate request Needs to be fixed - I did not see in section 3.2.2.12 a description of how the CA performs signature verification. (According to section 11.9, the CA and applicant may use “a legally valid and enforceable electronic (for an electronic Subscriber Agreement and/or EV Certificate Request), that binds the Applicant to the terms of each respective document.”)	Revised in CPS Version 1.0.3: 1. In CPS section 3.2.2.13 4.The role that the applicant organization shall have: Above roles must be employees or authorized agents of the applicant. The applicant shall confirm that the information of the application role is true and accurate, and make a statement in the way approved by CA (including but not limited to the registered official seal, registered legal person's name seal, role signature, etc.). For the false information of the application role, the CA has the right to refuse the application and withdraw the issued certificate. 2. In CPS section 3.2.2.13 d. Authentication of EV certificate applicant's principal individua: Contact the personnel department of the application organization by dialing the fixed line telephone (must be the company phone number obtained from the authentication data source) to confirm the identity and authorization of Certificate Requestor, Certificate Approver and Contract Signer.	Needs to be discussed with BJCA or clarified in the CPS.
EVG Section 11.11.5 - the CA shall use documented processes to check the accuracy of a QIIS. Needs to be fixed – it is not clear how BJCA manages its QIISes, QGISes and QGTISes.	Revised in CPS Version 1.0.3: 1. Section 3.2.2.7 of Data Source Accuracy is added to CPS to describe the establishment and disclosure rules of Authentication Data Source for EV Certificates. 2. For data source accuracy increased description in Section 3.2.2.7 of CPS, comply with CA/Browser Forum Baseline Requirements section 3.2.2.7 and EV Guidelines section 11.11 for data source requirements.	OK
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 – Subsection (3) in subsection 5 in section 3.2.2.12 says that the international organization must “not [be] on any prohibited list listed by the government (such as the trade embargo)”, but additional language is needed about checking databases as to whether the applicant should be denied an EV certificate because it is a terrorist, money launderer, etc., is absent from the CPS. (In subsection 13 of section 4.9.1.1. it says a certificate can be revoked if they are on a blacklist, etc., but there needs to be language about pre-issuance screening.) In other words, a CP says “what” must be done or is allowed/prohibited, but the CPS needs to say “how” this is done.	Revised in CPS Version 1.0.3: In CPS section 4.2.2 Approval and Rejection of Certificate Applications: (1) The CA establishes and maintains certificates high risk applicants list according to the list published by the anti-phishing Alliance, antivirus vendors or related Union, government agencies responsible for network security services, or information disclosed in public reports by media, and will check the list when accepting certificate applications. For applicants in the list, the CA will reject the application. (2) For those organizations is prohibited engaging in commercial activities or public activities by laws and regulations, national government departments, industry regulators, the CA has the right to refuse issuing an certificate. In addition, if the person (including Certificate Requestor, Certificate Approver, Contract Signer, Applicant Representative, etc.) applying for the certificate is subject to relevant laws and regulations, national or local government restrictions, the CA may refuse to accept the certificate application in which the person is involved.	Fixed.
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 looked in section 4.2 of the CPS and in other locations in the CPS for where this final approval process is described. Language about final checking of the certificate application and a two-person certificate approval process for EV certificates is needed.	Revised in CPS Version 1.0.3: 1. In CPS section 4.1.2 Enrollment Process and Responsibilities-CA: After verification and approval by two trusted persons (entry clerk and reviewer), the CA issues a certificate to the subscriber. 2. In CPS section 5.2.4 Roles Requiring Separation of Duties: In order to ensure system security and follow the principle of separation of trusted roles, the roles that the CA implement duty separation include, but are not limited to, certificate service acceptance, subscriber identity authentication, subscriber identity authentication approval, certificate or CRL issuance, system engineering and maintenance, CA key management, security audits, etc.	OK
EVG Section 11.14.3 - validation data cannot be reused after 13 months Needs to be fixed - See previous recommendation about limiting validation reuse to 397 days.	Revised in CPS Version 1.0.3: 1. For CPS section 4.7.1, the data reuse (certificate renewal) limit is revised from no more than 24 months to no more than the maximum validity period of such certificate as specified in Section 6.3.2 of this CPS. 2. For CPS section 6.3.2, the validity period of SSL global server certificate is revised to no more than 397 days.	Fixed.

Comment 25

[lipeng]

Thanks Ben, We have published BJCA Global CP/CPS v1.0.6 to address your comments above. Let me know if you have any questions or need anything else.

Comment 26

[Ben Wilson]

Attachment: BJCA Global CPS v1.0.6.pdf

Comment 27

[Ben Wilson]

In Comment #24, I noted that in section 3.2.2.13 of the CPS that it was unclear how the EV field “streetAddress” for the physical location of the business was verified.

BJCA has added to section 3.2.2.13 in CPS version 1.0.6, “Verify the business address and registered address information of the applicant organization through property bills, bank statements, government-issued tax bills, or other verification methods deemed reliable by the CA.”

I also asked for BJCA to clarify how it verified the signature on the subscriber agreement and certificate request.

BJCA has added to section 3.2.2.13 in CPS version 1.0.6, “The CA shall verify and confirm with the application role by phone, SMS, postal letter with receipt or other equivalent methods to verify the authenticity of its certificate request and subscriber agreement signature.”

I believe these are adequate to address my questions/concerns about the CPS and that this matter can proceed to the public discussion phase.

Comment 28

[Ben Wilson]

Attachment: BJCA_KGC_Report_20191219.pdf

Comment 29

[Ben Wilson]

Public discussion has started for this inclusion request - https://groups.google.com/a/ccadb.org/g/public/c/o9lbCbr92Ug/m/KJSSWiyWGQAJ. The discussion period is expected to close on or about January 11, 2023.

Comment 30

[Ben Wilson]

Attachment: Auditor Qualification_BJCA_2022.pdf

Comment 31

[Ben Wilson]

Attachment: BJCA's Compliance Self-Assessment - 2023

Comment 32

[Ben Wilson]

Attachment: BJCA Responses to Root Inclusion Considerations

These are BJCA's responses to https://wiki.mozilla.org/CA/Root_Inclusion_Considerations

Comment 33

[Ben Wilson]

I have concluded public discussion of this root inclusion request, and I am recommending that the request be approved. See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/loH2352Ik6E/m/L88XuIB5AQAJ
A one-week "last-call" period will run through 21-Feb-2023.

Comment 34

[Ben Wilson]

Mozilla has the ability to restrict domains by top-level domain. Please provide BJCA's reasons for not wanting to have such restriction. Thanks.

Comment 35

[lipeng]

Thanks Ben, We hope not to implement such restrictions, please kindly let us known your expectation or suggestion.

If you do believe such restrictions are necessary, please give full consideration to our users' needs. We believe that such restrictions may affect our global business of SSL certificates.

Firstly, as long as the ownership or control of the domain name is verified, the DV SSL certificate can be issued. In this case, there are no regional restrictions.

Secondly, the SSL certificate users we serve come from different industries (government affairs, medical care, finance, education, transportation, telecommunications, etc.), and they have domain names with different suffixes:
i. ccTLD (e.g. .cn, .cc, .co, etc.)
ii. gTLD (e.g. .com, .net, .org, .info, etc.)
iii. New gTLD (e.g. .vip, .top, .wang, .xyz, .club, .online, etc.)

In addition, the domain names that users can register through domain name registrars of China involve no less than 70 domain name suffixes, and these suffixes may be adjusted at any time with the development of the Internet.

Since it is not reasonable to force users to use a domain name with a certain suffix, we hope not to refuse issuing SSL certificates for domains legally owned by our users.

Comment 36

[Kathleen Wilson]

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

** BJCA Global Root CA1 (Email, Websites); enable EV
** BJCA Global Root CA2 (Email, Websites); enable EV

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

Comment 37

[Kathleen Wilson]

I have filed bug #1822921 against NSS and bug #1822924 against PSM for the actual changes.

Comment 38

[Kathleen Wilson]

Hi Peng Li,

Would you please check that the test websites are correctly configured?
https://demossl-rsa-valid.bjca.org.cn
https://demossl-ecc-valid.bjca.org.cn

In particular, we are seeing odd behavior where sometimes the TLS cert for https://demossl-ecc-valid.bjca.org.cn is correctly found to chain up to BJCA Global Root CA2, but other times it is found to chain up to BJCA Global Root CA1.

Sometimes https://crt.sh/test-websites shows the test websites for BJCA Global Root CA2 as passing, and other times shows the "Wrong chain" error.

And we get different responses from different machines as shown below.

❯ vfyserv demossl-ecc-valid.bjca.org.cn
Connecting to host demossl-ecc-valid.bjca.org.cn (addr 106.120.110.60) on port 443
PROBLEM WITH THE CERT CHAIN:
CERT 2. CN=BJCA Global Root CA2,O=BEIJING CERTIFICATE AUTHORITY,C=CN [Certificate Authority]:
ERROR -8172: Peer's certificate issuer has been marked as not trusted by the user.
CN=BJCA Global Root CA2,O=BEIJING CERTIFICATE AUTHORITY,C=CN
Error in function PR_Write: -8172

• Peer's certificate issuer has been marked as not trusted by the user.

And yet also:

❯ openssl s_client -connect demossl-ecc-valid.bjca.org.cn:443
CONNECTED(00000005)
depth=2 C = CN, O = BEIJING CERTIFICATE AUTHORITY, CN = BJCA Global Root CA1
verify error:num=19:self signed certificate in certificate chain
verify return:0
write W BLOCK

From different machines

Comment 39

[lipeng]

Hi Kathleen, We have checked and remediated the test websites, please review, Thanks.