Bugzilla

Reporter

Comment 1

•

5 years ago

Attached file BR-Self-Assessment-HiPKI-1.0-20190704.xlsx — Details

BR-Self-Assessment.

Flags: needinfo?(realsky)

Reporter

Comment 2

•

5 years ago

The CA's documents: https://eca.hinet.net/repository-h/en/index.htm
(i) HiPKI Certificate Policy Version 1.0
https://eca.hinet.net/download/HiPKI-CP-v1.0-en.pdf
(ii) HiPKI Root Certification Authority Certification Practice Statement Version 1.0
https://eca.hinet.net/download/HiPKI-RCA-CPS-v1.0-en.pdf
(iii) HiPKI EV TLS Certification Authority Certification Practice Statement Version 1.0
https://eca.hinet.net/download/HiPKI-EV-TLSCA-CPS-v1.0-en.pdf

Reporter

Comment 3

•

5 years ago

Attached file HiPKI PKI Hierarchy with testwebsite URL — Details

Attached file is HiPKI PKI Hierarchy.

Wayne Thayer

Updated

•

5 years ago

Whiteboard: [ca-initial]

Reporter

Comment 4

•

5 years ago

The audit case #00000476 in CCADB (https://ccadb.force.com/5001J00000mGtDg) is for updating period of time audit of HiPKI Root CA-G1 and HiPKI EV TLS CA-G1 from May 1 to May 31 to keep all of our company's CAs audit reports and management's assertions in the same seal. The statement date of audit reports and management's assertions are on July 22, 2019. The start date of audit period is Feb. 23, 2019. The end date of audit period is May 31, 2019. The audit report and management's assertion of HiPKI Root CA-G1 and HiPKI EV TLS CA-G1 are in the second half part of each report.

(1) WebTrust for CA period-of-time audit https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=232565

Please read page 19 to page 30.

(2) WebTrust for CA -SSL BR and Network Security period-of-time audit https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=232566
Please read page 17 to page 26.

(3) WebTrust for CA-EV SSL period-of-time audit https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=233024

Please read page 10 to page 18.

Thank you.

Updated

•

5 years ago

Whiteboard: [ca-initial] → [ca-verifying]

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

Comment 5

•

5 years ago

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

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

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

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

Assignee: kwilson → wthayer

Whiteboard: [ca-verifying] → [ca-cps-review] - KW 2019-09-12

Updated

•

5 years ago

Type: enhancement → task

Assignee

Updated

•

4 years ago

Assignee: wthayer → bwilson

Reporter

Comment 6

•

4 years ago

Here are the English translation of
(i) HiPKI Certificate Policy Version 1.05
https://eca.hinet.net/download/HiPKI-CP-v1.05-en.pdf
(ii) HiPKI Root Certification Authority Certification Practice Statement Version 1.05
https://eca.hinet.net/download/HiPKI-RCA-CPS-v1.05-en.pdf
(iii) HiPKI EV TLS Certification Authority Certification Practice Statement Version 1.05
https://eca.hinet.net/download/HiPKI-EV-TLSCA-CPS-v1.05-en.pdf

Thank you.

Assignee

Comment 7

•

4 years ago

Chunghwa Telecom: CP/CPS Review of v.1.05 of the HiPKI Certificate Policy, the HiPKI Root CA CPS, and the HiPKI EV TLS CA CPS, published March 2, 2020.

GOOD

The CP and CPSes are organized in RFC 3647 format and have Document History tables.
1.1 Overview / 1.1.1 Certificate Policy / Certification Practice Statement
Chunghwa Telecom purports to conform to various industry requirements, including CA/Browser Forum requirements and the Mozilla Root Store Policy.
1.2 Document Name and Identification
CP and CPSes reference CA/Browser Forum policy OIDs and contain a statement that the CA/Browser Forum server certificate requirements take precedence in the event of a conflict with interpretation.
1.3.2 Registration Authorities
This section of the HiPKI EV TLS CA CPS states that domain name and IP address validation is not delegated to a third party.
1.5.2.2. Certificate Problem Report
In compliance with section 4.9.3 of the Baseline Requirements, the CPSes explain that a key compromise or other problem report may be submitted by email to report_abuse@cht.com.tw.
1.5.3 Person Determining CPS Suitability for the Policy
This section of the CP/CPSes notes that the CA must maintain a contiguous chain of annual audits.
2.2 Publication of Certification Information
This section lists the CAA issuer domain names applicable to the HiPKI. It also references the requirement to have three test websites.
2.3 Time or Frequency of Publication
The HiPKI EV TLS CA CPS is reviewed and updated annually, as required by Mozilla Root Store Policy, section 3.3.
3.1.2 Need for Names to be Meaningful
This section acknowledges that internal names and reserved IP addresses are prohibited.
3.2.2 Authentication of Organization Identity
The HiPKI RCA CPS gives a high-level overview of required FQDN / domain-name verification. The HiPKI EV TLS CA CPS gives a detailed review of the EV guideline requirements.
3.2.5 Validation of Authority
The subsections under this section 3.2.5 of the HiPKI EV TLS CA CPS identify BR sections 3.2.2.4.12 (Domain Contact / Domain Registrar), 3.2.2.4.2 (Domain Contact), 3.2.2.4.4 (Constructed Email), 3.2.2.4.6 (Agreed-Upon Change to Website), 3.2.2.4.7 (DNS Change), 3.2.2.4.13 (Email to DNS CAA Contact), and 3.2.2.4.14 (Email to DNS TXT Contact).
3.5.3 Age of Validated Data
This section states the 13-month limit on the reuse of validation data.
4.2.1.1 Authorize the CA Issuing Certificate Record
Sets forth Chunghwa Telecom’s CAA domains of pki.hinet.net and tls.hinet.net.
4.9.1 Circumstances for Revocation
The HiPKI EV TLS CA CPS and the HiPKI RCA CPS basically mirror sections 4.9.1.1. and 4.9.1.2 of the Baseline Requirements, respectively.
4.9.5 Time within Which CA Must Process the Revocation Request
This section of CPSes specifies that the period from the Certificate Problem Report or revocation-related notice to revocation will not exceed the time frame set forth in Section 4.9.1.
6.1.2 Private Key Delivery to Subscriber
This section of the HiPKI EV TLS CA CPS states that the CA shall not generate the key pairs of subscribers.
6.5.1 Specific Computer Security Technical Requirements
This section of the CP and CPSes acknowledges that multi-factor authentication is required for all accounts capable of causing certificate issuance.
7.1 Certificate Profile
Specifies that non-sequential serial numbers of at least 64 bits be generated pseudorandomly.
7.1.2.2
References Certificate Transparency

MEH (Minor)

1.4.2 Prohibited Certificate Uses
In future versions of its CP and CPSes, Chunghwa Telecom should consider adding a prohibition that certificates may not be used for man-in-the-middle TLS traffic interception (or could also put such language elsewhere as appropriate in the CP or CPS).
1.6.2 Acronyms
Minor issue in HiPKI EV TLS CA CPS, “CFO” should say “Chief Financial Officer”
2.4 Access Controls on Repositories
This section of the CPSes says that access controls should be implemented when providing access for viewing to guarantee repository security—accessibility and availability. Could you clarify the intent of this provision? I assume that access controls do not prevent viewing because normally access controls are only implemented to control write access, not read access. Is this a requirement you implement to prevent denial-of-service attacks?
3.2.1 Method to Prove Possession of Private Key
This section of the CP appears to allow the CA to generate subscriber private keys. However, section 6.1.1.1 of the HiPKI EV TLS CA CPS says that Subscribers generate private keys and section 6.1.2. says that the HiPKI EV TLS CA shall not generate the key pairs on behalf of subscribers.
3.2.5 Validation of Authority
It should be noted for the method “Email to DNS CAA Contact”, and as referenced in section 4.2.1.1 of the HiPKI EV TLS CA CPS, that RFC 6844 has been replaced by RFC 8659. Also note that BR section 3.2.2.4.6 is being replaced with BR section 3.2.2.4.18.
4.2.2 Approval or Rejection of Certificate Applications
Chunghwa Telecom should consider revising the third and fourth paragraphs of this section because now that this ICANN gTLD process is past implementation, the prior language in the Baseline Requirements concerning that process has been removed.
5.7.3 Entity Private Key Compromise Procedures
In the event of a CA private key compromise, Chunghwa Telecom must immediately notify Mozilla and the other application software suppliers.
7.1.4.2
Minor typo in cross-reference to section 3.2.2.5 (should be section 3.2.5).

BAD (Major)

None.

Whiteboard: [ca-cps-review] - KW 2019-09-12 → [ca-cps-review] - Pending Response to Comment 7

Assignee

Comment 8

•

4 years ago

The audits for 2020 for this HiPKI Root CA -G1 are due by the end of July 2020. Please make sure your auditors include the SHA2 hash of the Root CA certificate in their opinion and that they comply with all of the other formatting requirements. See https://www.ccadb.org/policy#51-audit-statement-content

Reporter

Comment 9

•

4 years ago

(In reply to Ben Wilson from comment #8)

The audits for 2020 for this HiPKI Root CA -G1 are due by the end of July 2020. Please make sure your auditors include the SHA2 hash of the Root CA certificate in their opinion and that they comply with all of the other formatting requirements. See https://www.ccadb.org/policy#51-audit-statement-content

  Thanks for Ben’s reminding.  Each SHA-256 fingerprint within the new Audit Report will NOT contain colons as last year to prevent from error of ALV.

　　And the audit report shall comply with all of the other formatting requirements as specified in January 2020 Communications and May 2020 CA Communications.

Reporter

Comment 10

•

4 years ago

Attached file CHT_03_EV SSL_2020_Sealfile.pdf — Details

WebTrust for CA-EV SSL Audit Report (Statement Date:August 24, 2020)

Reporter

Comment 11

•

4 years ago

Attached file CHT_01_WTCA_2020_Sealfile.pdf — Details

WebTrust for CA Audit Report and Management's Assertions (Statement Date: August 24, 2020).

Reporter

Comment 12

•

4 years ago

Attached file CHT_02_SSL BR_2020_Sealfile.pdf — Details

WebTrust for CA-SSL BR with Network Secuirty Audit Report and Management's Assertions (Statement Date: August 24, 2020).

Reporter

Comment 13

•

4 years ago

Here are the English translation of
(i) HiPKI Root Certification Authority Certification Practice Statement Version 1.1
https://eca.hinet.net/download/HiPKI-RCA-CPS-v1.10-en.pdf
(ii) HiPKI EV TLS Certification Authority Certification Practice Statement Version 1.1
https://eca.hinet.net/download/HiPKI-EV-TLSCA-CPS-v1.10-en.pdf

These documents in Chinese were approved for publication on July 2.

Thanks for Ben's review in Comment 7, most of them will be resolved in next version. We will offer CP/CPS after they are approved and translated to English version.

Assignee

Comment 14

•

4 years ago

Would Chunghwa Telecom be ready soon for the public discussion phase of the root inclusion process?

Reporter

Comment 15

•

4 years ago

(In reply to Ben Wilson from comment #14)

Would Chunghwa Telecom be ready soon for the public discussion phase of the root inclusion process?

We have finished the revision of our CP/CPS based on comment 7. We are still working on double-checking the CP/CPS to meet the requirements of current versions of BR, EV SSL Certificate Guidelines and System and Network and Certificate System Security Requirements; and solving the CRL/OCSP test issue. We will let you know if the above matters are completed and then we can get into the public discussion phase.

Assignee

Comment 16

•

4 years ago

What is the status now?

Flags: needinfo?(realsky)

Reporter

Comment 17

•

4 years ago

(In reply to Ben Wilson from comment #16)

What is the status now?

We have just solved the CRL/OCSP test issue (Please check https://certificate.revocationcheck.com/good.hipkig1ev.hinet.net ).
New versions of HiPKI CP/CPS are under reviewing and approving by our PMA, and the English versions is under translating as well.
Hope these matters can be completed soon and then we can get into the public discussion phase.

Flags: needinfo?(realsky)

Assignee

Updated

•

4 years ago

Priority: -- → P1

Reporter

Comment 18

•

3 years ago

Here are the English translation of
(i)HiPKI Certificate Policy Version 1.10
https://eca.hinet.net/download/HiPKI-CP-v1.1-en.pdf
(ii) HiPKI Root Certification Authority Certification Practice Statement Version 1.15
https://eca.hinet.net/download/HiPKI-RCA-CPS-v1.15-en.pdf
(iii) HiPKI EV TLS Certification Authority Certification Practice Statement Version 1.15
http://eca.hinet.net/download/HiPKI-EV-TLSCA-CPS-v1.15-en.pdf

Thank you.

Assignee

Comment 19

•

3 years ago

CP/CPS Review of v.1.15 of the Chunghwa Telecom HiPKI Certificate Policy, the HiPKI Root CA CPS, and the HiPKI EV TLS CA CPS, published April 13, 2021

(focus was primarily on the HiPKI EV TLS CA CPS because it contained most of the relevant provisions)

BASELINE REQUIREMENTS / MOZILLA ROOT STORE POLICY REVIEW

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

Good – CPS follows RFC 3647 without blank sections.

CP/CPS made available under a Creative Commons License (MRSP § 3.3.3)

“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)”

Adequate – While section 9.5 of the CPS states, “This CPS may be freely downloaded from the HiPKI EV TLS CA repository. CHT grants permission to copy (in full) and distribute this CPS on a free basis according to the Copyright Act of R.O.C., but it must be copied in full and copyright noted as being owned by CHT.”, a more permissive license for the use of the CPS would be better.

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

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

Good – Addressed in CPS section 1.2 with the following language “With regard to EV TLS/SSL certificates, if there is any inconsistency between this CPS and the EV SSL Certificate Guidelines and Baseline Requirements, then the EV SSL Certificate Guidelines and Baseline Requirements take precedence.”

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.

OK - Section 7.1.2.1.g of the CS states, “For the subordinate CA certificate that HiPKI RCA issues to HiPKI EV TLS CA, this extension is required and marked as non critical. This extension contains serverAuth and clientAuth bits; besides, the values id kp emailProtection, id kp codeSigning, id kp timeStamping, and anyExtendedKeyUsage must not be present.” This could be an issue with translation, but a period / full-stop and deleting the word “besides” might better communicate the meaning of this provision. For instance, it could say, “This extension contains serverAuth and clientAuth bits. The values id kp emailProtection, id kp codeSigning, id kp timeStamping, and anyExtendedKeyUsage must not be present.”

Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6)

“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”

Good – The root inclusion request is for “HiPKI Root CA -G1.” Section 1.1.1 of the CPS notes that the HiPKI EV TLS CA is a level-one Subordinate CA of HiPKI RCA that obtains certificates from HiPKI RCA and is responsible for the issuance and management of Extended Validation (EV) TLS/SSL certificates.

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.

OK – the CPS contains a “Document History” table that indicates it has been re-versioned at least annually. Section 2.3 states, “(1) This CPS is reviewed and updated annually, and a dated changelog is stated in the “Document History” section, even if no other changes are made to this document.“ However, section 9.12.1 says that while the CPS is reviewed annually, “an assessment is made to determine if the CPS needs to be amended to maintain its assurance level”. These latter two statements are not necessarily inconsistent, so this appears to be OK by focusing on section 2.3.

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, “HiPKI EV TLS CA does not permit any delegated third party to be the RA counter to verify the ownership or control of domain names or IP addresses.”

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.2 of the CPS specifies email addresses for filing certificate problem reports—“Subscribers, relying parties, application software suppliers, and other third parties may report private key lose, suspected private key compromise, certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to certificates by sending email to report_abuse@cht.com.tw.”.

Naming compliant with X.500, RFC5280 and BRs

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

Good – Sections 3.1.1, 3.1.2, 3.1.5, 7.1.4, and 7.1.4.2 adequately discuss naming compliant with X.500, RFC 5280 and the CA/Browser Forum requirements.

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

Good - CPS section 4.2.2 states “HiPKI EV TLS CA will not issue EV TLS/SSL certificates containing internal names or reserved IP addresses.”

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).]

Good – Section 3.2.5 of Chunghwa Telecom’s CPS sets forth its allowed domain validation processes as follows:

3.2.5.1 – corresponds to BR § 3.2.2.4.12, Validating Applicant as a Domain Contact

3.2.5.2 – corresponds to BR § 3.2.2.4.2, Email, Fax, SMS, or Postal Mail to Domain Contact

3.2.5.3 – corresponds to BR § 3.2.2.4.4, Constructed Email to Domain Contact

3.2.5.4 – corresponds to BR § 3.2.2.4.18, Agreed‐Upon Change to Website v.2

3.2.5.5 – corresponds to BR § 3.2.2.4.7, DNS Change

3.2.5.6 – corresponds to BR § 3.2.2.4.13, Email to DNS CAA Contact

3.2.5.7 – corresponds to BR § 3.2.2.4.14, Email to DNS TXT Contact

Also, section 1.4.2 prohibits the use of server certificates for “(5) Man-in-the-middle TLS traffic interception.”

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

OK- but need to review the SMIME CPS – Section 3.2.5 of the CP states, "CAs shall specify how to validate that the Applicant has the right to use or control an e-mail address to be contained in the certificate subject alternative name field that will have the ''Secure E-mail'' EKU in their CPS. For that case, CAs shall may use domain validation methods specified in the Baseline Requirements to validate that the Applicant has the ownership or control of the authorization domain name of the e-mail address to be contained in the S/MIME certificate; and then use appropriate methods to validate the applicant's right to use or control that e-mail account or authorization to apply the certificate on behalf of the owner of that e-mail account, such as (1) Sending an e-mail message containing a random value to the e-mail address and receiving a confirming response through use of the random value to indicate that the applicant and/ or organization owns or controls that e-mail address; or (2) Confirming the e-mail address from personnel database or LDAP service."

Data sources need to be accurate (BR § 3.2.2.7)

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

Good – CPS Section 3.2.7 contains the criteria that Chunghwa Telecom uses to ensure that data sources are reliable.

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

Meh – CPS section 3.2.4 says, “Not applicable.” It should say that all information in a certificate is verified. However, section 9.6.1(3) provides a warranty that “at the time of issuance, HiPKI EV TLS CA (i) implemented a procedure for verifying the accuracy of all of the information contained in the Certificate (with the exception of the subject:organizationalUnitName attribute)”.

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

CAs must “verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 825 days or less”, and “for server certificates issued on or after October 1, 2021, each dNSName or IPAddress in a SAN or commonName MUST have been validated in accordance with section 3.2.2 of the CA/Browser Forum's Baseline Requirements within the prior 398 days.”

OK – Section 3.5.3 of Chunghwa Telecom’s CPS limits reuse of validation to 13 months, consistent with version 1.7.4 of the EV Guidelines. Note that the maximum number of days was changed to 398 days by Ballot SC-42, effective as October 1, 2021.

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

Good – Sections 4.2.1.1 of the CPS state Chunghwa Telecom’s CAA checking practices.

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

CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”.

Good – Section 6.5.1 of the CPS states, “HiPKI EV TLS CA enforces multi-factor authentication for all accounts capable of directly causing certificate issuance.”

Pre-issuance linting (Recommended Practices)

“It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences.”

OK – Pre-issuance linting doesn’t appear to be mentioned in the CPS, although Chunghwa Telecom applies linters according to comments in https://bugzilla.mozilla.org/show_bug.cgi?id=1532436#c40.

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 – In section 4.9.1 Chunghwa Telecom needs to move part of subsection (10) of the five-day revocation period to the mandatory 24-hour revocation part of that section to match BR section 4.9.1.1, subsection 4, which requires 24-hour revocation 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)”.

SMIME Reasons for Revocation (MRSP § 6.2)

“For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events … [e.g. MRSP § 6.2, ”5. the CA receives notice or otherwise becomes aware of any circumstance indicating that use of the email address in the certificate is no longer legally permitted;”]

Need to review the SMIME CPS

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

Good – Section 4.9.7 specifies, “The CRL issuance frequency of HiPKI EV TLS CA is at least twice per day. Issued CRL are valid for no more than 36 hours.”

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

Needs to be fixed - Section 4.9.12 of the CPS states, “As stated in Sections 4.9.1, 4.9.2 and 4.9.3.” It needs to describe the method by which a party can demonstrate private key compromise to Chunghwa Telecom.

CA must not allow certificate suspension (BR § 4.9.13)

Good. Section 4.9.13 of the CPS states, “HiPKI EV TLS CA does not provide the service of certificate suspension.”

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

Good – CPS section 4.9.10 states, “The OCSP of Hi PKI EV TLS CA is updated at least once per hour, and the validity period of the OCSP responses is greater than or equal to 8 hours and less than 16 hours.”

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

Good – Section 5.7.3 states, “If the incident response team confirms that the CA private key of HiPKI EV TLS CA has been compromised, … (3) Notify the application software suppliers immediately.”

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.2 of the CPS states, “HiPKI EV TLS CA shall not generate the key pairs on behalf of subscribers.”

Must meet RSA key requirements (MRSP § 5.1)

Good – These are adequately addressed in CPS sections 6.1.5 and 6.1.6.

Must meet ECC key requirements, P-256 or P-384 (MRSP § 5.1)

Good – These are adequately addressed in CPS sections 6.1.5 and 6.1.6.

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

Good – Section 6.3.2.2 states that the validity period is three hundred ninety-eight (398) days for SSL/TLS Certificates.

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

Good – Section 6.6.2 of the CPS states, “HiPKI EV TLS CA references the methodologies and standards in the ISO/IEC 27001, ISO/IEC 27002, ISO/IEC 27005, ISO/IEC 31000, Baseline Requirements, EV SSL Certificate Guidelines, Network and Certificate System Security Requirements, WebTrust Principles and Criteria for Certification Authorities (WebTrust for CA), WebTrust for CA – Extended Validation SSL (WebTrust for CA – EV SSL) and WebTrust for CA – SSL BR for risk assessment, risk management and security management and control measures.” Although language in section 6.7 (Network security controls) could also be improved with reference to the CABF’s NCSSRs.

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 – Section 7.1 of the Chunghwa Telecom CPS states, “HiPKI EV TLS CA generates non-sequential certificate serial numbers greater than zero (0) containing at least 64 bits of output from a cryptographically secure pseudorandom number generator (CSPRNG).”

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

Good – Section 7.1.2.2.f. (ext key Usage) states, “For the EV TLS/SSL certificates issued by HiPKI EV TLS CA, this extension is required and marked as non-critical. The extension contains both serverAuth and clientAuth bits; besides, the value anyExtendedKeyUsage must not be present.”

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

Good – The SHA1 algorithm does not appear with the algorithms listed in CPS Section 7.1.3.

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

OK – CPS section 7.1.4.2 states, “If the commonName field in the certificate Subject appears, it will be the FQDN validated by Section 3.2.5 (if it is a multi-domain EV TLS/SSL certificate, only one FQDN will be placed). However, this wording is not as explicit as saying that the commonName field must be one of the SANs that has been validated.

EV GUIDELINES REVIEW

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

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

Good – Section 9.16.3 states, “The requirements regarding CAs under this CPS comply with the Baseline Requirements and EV SSL Certificate Guidelines; however, if there is any inconsistency between the related domestic laws followed by this CPS and the Baseline Requirements and EV SSL Certificate Guidelines, this CPS may be adjusted to satisfy the requirements of the laws, and such adjustment shall be notified to CA/Browser Forum. If the domestic laws are not applicable anymore, or CA/Browser Forum revises the contents of the Baseline Requirements and EV SSL Certificate Guidelines to be compatible with the domestic laws, this CPS will delete and amend the adjusted contents. The aforesaid actions shall be completed within 90 working days.”

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

OK – Section 9.2 of the CPS states, “If the incurred damages are not within the scope of Commercial General Liability insurance compensation coverage disclosed in Section 9.2.1, then liability for damage compensation with other assets shall conform to the EV SSL Certificate Guidelines disclosed in Section 9.2.2”

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

Good – In several places in section 3.2.2.2.1 of the CPS there is a requirement for organization name verification as follows: “Verify that the Applicant’s formal legal name as recorded with the Incorporating or Registration Agency in the Applicant’s Jurisdiction of Incorporation or Registration matches the Applicant’s name in the EV TLS/SSL Certificate Request.”

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"

Good - In numerous places throughout sections 3.2.2.2.1 and 3.2.2.2.2 of the CPS there are requirements for verification of legal existence. The definition of “legal entity” states that the organization is “A Private Organization, Government Entity, Business Entity, or Non-Commercial Entity.” Section 3.1.2 of the CPS states, “If the organization of the Applicant is a private organization, the business type must be listed as ‘Private Organization’. If it is a government organization (agency), it must be listed as ‘Government Entity’. If it is another type of business entity, it must be listed as ‘Business Entity’. If it is a non-commercial entity (international)), it must be listed as a ‘Non-Commercial Entity’), ….” Section 3.1.2.1(2) also indicates, “The attribute content can be ‘Private Organization’, ‘Government Entity’, ‘Business Entity’ and ‘Non-Commercial Entity’ to indicate whether it is a private organization, government agency (authority), other business group or non-profit international organization. Only one may be selected.”

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.

OK – CPS Section 3.1.2.2 (2) (City or Town Name of Registration Jurisdiction (jurisdictionLocalityName)) states, “The attribute is defined based on the circumstance. If the organization level of the jurisdiction of the Incorporating or Registration Agency to which the certificate subject is registered is a city or town, then the EV TLS/SSL certificate field subject not only must include the attribute ‘country code of the registration jurisdiction’ and ‘state or province name of the registration jurisdiction’ but also must include the attribute ‘City or Town Name of the registration jurisdiction’ which is used to record the city or town name in which the Incorporating or Registration Agency is located and the city or town name must be a complete name.
If the organization level of the jurisdiction of the Incorporating or Registration Agency to which the certificate subject is registered is a country or a state or province, then the attribute ‘city or town name of the registration jurisdiction’ does not need to be included.”

Sections 9.2.4, 9.2.5, and 11.1.3 – the CA shall maintain a publicly available list of its verification sources, incorporating agencies, and registration agencies (e.g. QIISes, QGISes, QGTISes). Information about where this information can be located must appear in section 3.2 of the CPS.

Good – Section 3.2.2.1 says, “The list of our verification sources, including Incorporating Agency and Registration Agency, etc, is published in the repository at https://tls.hinet.net/repository.htm.”

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.

Good – Section 3.1.2.1(4) (Identification Code (serialNumber)) states, “If not provided, then change by indicating the establishment or registration date.”

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

Good – CPS Section 3.2.2.1(1)B says, “Verify the Applicant’s physical existence (business presence at a physical address)”. Section 3.2.2.4.1 also states, “(1) Verification Requirements: To verify the applicant’s physical existence and business presence, the RA must verify that the physical address provided by the Applicant is an address where the Applicant or a Parent/Subsidiary Company conducts business operations (not, for example, a mail drop or P.O. box, or ‘care of’ (C/O) address, such as an address for an agent of the Organization), and is the address of the applicant’s place of business.”

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

Good – See CPS Section 3.2.2.3.

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

Not applicable.

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

OK – CPS Section 3.1.2 says, “According to Article 9.2 of the EV SSL Certificate Guidelines, the EV TLS/SSL certificate field ‘subject’ content can be subdivided into required attributes, optional attributes and deprecated attributes which are organized in the table below.” The table enumerates the allowed attributes.

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

Good – Section 7.1.6 states, “The certificate policies extension contains the EV SSL CP OID ({joint‐ iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) certificate‐policies(1) ev-guidelines (1)} (2.23.140.1.1)) defined by CA/Browser Forum.”

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

Good – Section 6.3.2.2. specifies a 398-day validity period for end entity certificates.

Section 9.8.1 - wildcard certificates are not allowed.

OK - Section 3.1.2.3(1) says, “Currently EV TLS/SSL certificates still do not support wildcard certificates. Therefore, wildcard domain names may not be recorded in the commonName.”

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

Good – Among other provisions in the CPS, section 3.2.2.1(4) states: “Verify the Applicant’s authorization for the EV TLS/SSL Certificate (As stated in Sections 3.2.3 and 3.2.4), including
A. Verify the name, title, and authority of the Contract Signer, Certificate Approver, and Certificate Requester,
B. Verify that a Contract Signer signed the Subscriber Agreement or that a duly authorized Applicant Representative acknowledged and agreed to the Terms of Use, and
C. Verify that a Certificate Approver has signed or otherwise approved the EV TLS/SSL Certificate Request.”

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

Good - Section 3.2.2.2.2(3) provides, “In addition, HiPKI EV TLS CA or its RA must validate the principal individual associated with the other business group pursuant to the requirements in subsection (4) below.”

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.

Good – See CPS section 3.2.2.3.1.

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

Good – See CPS section 3.2.2.5

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

Good - See CPS section 3.2.2.6.2

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

Good – see above (re: section 3.2.5 of Chunghwa Telecom’s CPS)

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

Good - See CPS section 3.2.3.1

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

Good - See CPS section 3.2.3.2

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

OK – Definition of QIIS states, “The CA shall use a documented process to check the accuracy of the database and ensure its data is acceptable”. Also see CPS section 3.2.7.

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

Good - See CPS section 3.2.8.2

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

Good - See CPS section 3.2.8.4

Section 11.14.3 - validation data cannot be reused after 13 months

Good - Section 3.5.3 of Chunghwa Telecom’s CPS limits reuse of validation to 13 months

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

Good – Section 6.1.7 of the HiPKI Root CA CPS, v. 1.15, says, “The private key corresponding to the HiPKI RCA self-signed certificate can only be used for issuing self-signed certificates, self-issued certificates, subordinate CA certificates, cross-certificates, CARLs, OCSP responder certificates, or OCSP responses.”

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

Good – Section 5.3.1(2) states, “All personnel performing certificate work shall have their qualifications reviewed at the initial time of employment to verify their trustworthiness and work capabilities.”

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

OK – CPS Section 5.3.3 requires that RA Operators be trained in:

(1) Basic knowledge of the PKI
(2) Identity authorization and information verification policies and procedures (including the EV SSL certificate guidelines, Baseline Requirements, HiPKI CP and this CPS)
(3) Common identification and information verification procedure threat (including phishing and other social engineering attacks) knowledge and skills.

See EVG § 14.1.2 and BR 5.3.3 for additional details.

Section 14.2.1 - the CA shall ensure that third-party personnel satisfy the training and skills requirements of section 14 of the EV guidelines.

OK – Section 5.3.7 states, “The duties, sanctions for unauthorized actions and required training documents of independent contractor serving a trusted role shall meet the requirements of Section 5.3.”

Reporter

Comment 20

•

3 years ago

Dear Ben

 Thank you very much for reviewing our CP and CPS. We updated our CP and CPS. 

 Here are the English translation of

(i) HiPKI Certificate Policy Version 1.15
http://eca.hinet.net/download/HiPKI-CP-v1.15-en.pdf

(ii) HiPKI Root Certification Authority Certification Practice Statement Version 1.16
https://eca.hinet.net/download/HiPKI-RCA-CPS-v1.16-en.pdf

(iii) HiPKI EV TLS Certification Authority Certification Practice Statement Version 1.16
http://eca.hinet.net/download/HiPKI-EV-TLSCA-CPS-v1.16-en.pdf

All  Chunghwa Telecom's TLS certificates will eventually be migrated to be issued from subCAs chaining to HiPKI RCA-G1 root.

We have incorporated the suggested changes from Comment #19.

Please let us know if you need any additional information for this request.

Assignee

Updated

•

3 years ago

Flags: needinfo?(bwilson)

Assignee

Updated

•

3 years ago

Flags: needinfo?(bwilson)

Whiteboard: [ca-cps-review] - Pending Response to Comment 7 → [ca-ready-for-discussion 2021-07-27]

Assignee

Comment 21

•

3 years ago

Follow-up Review of the Chunghwa Telecom HiPKI EV TLS CA CPS, published June 17, 2021

based on Comment #19
http://eca.hinet.net/download/HiPKI-EV-TLSCA-CPS-v1.16-en.pdf

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

Meh – CPS section 3.2.4 says, “Not applicable.” It should say that all information in a certificate is verified. However, section 9.6.1(3) provides a warranty that “at the time of issuance, HiPKI EV TLS CA (i) implemented a procedure for verifying the accuracy of all of the information contained in the Certificate (with the exception of the subject:organizationalUnitName attribute)”.

CPS Section 3.2.4 now states, "All information to be listed in the certificates must be verified."

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 – In section 4.9.1 Chunghwa Telecom needs to move part of subsection (10) of the five-day revocation period to the mandatory 24-hour revocation part of that section to match BR section 4.9.1.1, subsection 4, which requires 24-hour revocation 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)”.

Subsection (4) of section 4.9.1 of the CPS now states, "HiPKI EV TLS 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);"

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

Needs to be fixed - Section 4.9.12 of the CPS states, “As stated in Sections 4.9.1, 4.9.2 and 4.9.3.” It needs to describe the method by which a party can demonstrate private key compromise to Chunghwa Telecom.

Section 4.9.12 of the CPS now states, "The acceptable methods used by third parties as proof of key compromise are the following:
(1) Confirming the third party’s possession of the private key by signing a challenge provided by HiPKI EV TLS CA using the compromised private key.
(2) Submitting the private key itself."

Assignee

Comment 22

•

3 years ago

Hello Li-Chun,
Can you confirm that Chunghwa Telecom is no longer seeking Mozilla enablement of the email trust bit for this HiPKI root?
Thanks,
Ben

Flags: needinfo?(realsky)

Reporter

Comment 23

•

3 years ago

(In reply to Ben Wilson from comment #22)

Hello Li-Chun,
Can you confirm that Chunghwa Telecom is no longer seeking Mozilla enablement of the email trust bit for this HiPKI root?
Thanks,
Ben

Dear Ben,

 I confirm that Chunghwa Telecom is no longer seeking Mozilla enablement of the email trust bit for this HiPKI root as described in the newest version of HiPKI CP. We will generate a new Root CA for e-mail Trust bit for inclusion in Mozilla in the near future. Thanks for your review.  

Li-Chun

Flags: needinfo?(realsky)

Assignee

Comment 24

•

3 years ago

Today I started the public discussion of this root inclusion request with a closing date of 24-August-2021 - see https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/uvdF8RTRFPc/m/P94Q6Q5YAQAJ.

Whiteboard: [ca-ready-for-discussion 2021-07-27] → [ca-in-discussion] 2021-08-03

Assignee

Comment 25

•

3 years ago

Awaiting updated CPS - see https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/uvdF8RTRFPc/m/dznSSF4QAgAJ

Reporter

Comment 26

•

3 years ago

(In reply to Ben Wilson from comment #25)

Awaiting updated CPS - see https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/uvdF8RTRFPc/m/dznSSF4QAgAJ

Dear Ben,

  We have released the latest version of CP & CPS (HiPKI CP v1.16 and HiPKI EV TLS CA CPS v1.1.7) on our official website https://eca.hinet.net/repository-h/en/index.htm  , please kindly review them, thanks. 

  The updated HiPKI CP:  https://eca.hinet.net/download/HiPKI-CP-v1.16-en.pdf  
  The updated HiPKI EV TLS CA CPS  https://eca.hinet.net/download/HiPKI-EV-TLSCA-CPS-v1.17-en.pdf

Regards,

       Li-Chun

Assignee

Updated

•

3 years ago

Whiteboard: [ca-in-discussion] 2021-08-03 → [ca-pending-approval] 2021-09-18

Assignee

Comment 27

•

3 years ago

Today I closed public comment and recommended that Mozilla include the Chunghwa Telecom G1 root - https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/uvdF8RTRFPc/m/EBan23cWCQAJ.

Flags: needinfo?(kwilson)

Comment 28

•

3 years ago

As per Comment #27, and on behalf of Mozilla I approve this request from Chunghwa Telecom to include the following root certificate:

** HiPKI Root CA - G1 (Websites); EV

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

Flags: needinfo?(kwilson)

Whiteboard: [ca-pending-approval] 2021-09-18 → [ca-approved] - pending NSS and PSM code changes

Updated

•

3 years ago

Depends on: 1733012

Updated

•

3 years ago

Depends on: 1733014

Comment 29

•

3 years ago

I have filed bug #1733012 against NSS and bug #1733014 against PSM for the actual changes.

Summary: Add Chunghwa Telecom's HiPKI Root CA -G1 Certificate to NSS → Add Chunghwa Telecom's HiPKI Root CA -G1 Certificate