Closed Bug 1532436 Opened 5 years ago Closed 4 years ago

Chunghwa Telecom: Test certificate with unregistered domain name

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: wthayer, Assigned: realsky)

Details

(Whiteboard: [ca-compliance] [ov-misissuance])

Attachments

(3 files)

a decoding problem of WHOIS Protocol screen shot
14.93 KB, image/png
Details
CHT_01_WTCA_2020_Sealfile.pdf
1.10 MB, application/pdf
Details
CHT's SSL BR_2020_Sealfile
1.41 MB, application/pdf
Details

Li-Chun Chen submitted the following incident report to the mozilla.dev.security.policy mailing list:

  1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

Ans:
One of our staffs in PKI group was taking samples of the issued certificates from crt.sh database for some reasons and found a mis-issued certificate which has a test (unregistered) FQDN on February 15, 2019 at 1:55 (UTC). He then notified us (Public CA) of the incident. We decide to make an initial investigation and found another mis-issued certificate which also has a test FQDN on February 15, 2019 at 2:30 (UTC).

  1. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

Ans:
Timeline (all times are UTC):
15 February 2019 1:55: Find a mis-issued certificate with a FQDN www.raotest.com.tw
15 February 2019 1:59: Revoke the first mis-issued certificate
15 February 2019 2:07: Public CA starts an action plan and initial investigation
15 February 2019 2:17: Further certificate issuing suspended
15 February 2019 2:30: Find another mis-issued certificate with a FQDN publicca.rao.com.tw
15 February 2019 4:10: Initial investigation completed
15 February 2019 4:25: Certificate issuing restarted
15 February 2019 4:40: Hold an investigation meeting

  1. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

Ans:
Yes, we had stopped issuing certificates before we investigated and revoked any certificate with an unregistered FQDN. We have asked our CA system vendor to include an automatic FQDN-checking function in the hotfix which will be released not after 30 March 2019 to avoid making the same mistakes.

  1. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

Ans:
Number of certs: 2
First cert: issued on Nov 12, 2018 at 11:53:02 (UTC)
Last cert: issued on Jan 29, 2019 at 06:43:59 (UTC)

  1. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

Ans:
https://crt.sh/?id=1153958924 with FQDN www.raotest.com.tw
https://crt.sh/?id=940459864 with FQDN publicca.rao.com.tw

  1. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

Ans:
For the certificate with FQDN www.raotest.com.tw:
One of our RAOs intended to take a screenshot of certificate application process for training material in test environment, but she was not aware that she is in the formal environment. After the certificate was issued, the RAO forgot to revoke it.

For the certificate with FQDN publicca.rao.com.tw:
The same as the former cause, but the mis-issued certificate had been revoked immediately without notifying Public CA.

The mistakes have not been detected (even by our internal self-audit) because the amount of mis-issued certificates is minor. The RAO involved in this incident has been verbally warned and needs to undergo a retraining process in accordance with our employment contract.

  1. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

Ans:
To avoid making the same mistakes, the following steps will newly be introduced:

Step 1. Implementation of a two-stage manual verification by different RAOs. Effective 26/02/2019.

Step 2. Implementation of an automatic FQDN-checking function prior to issuing certificates. Effective 30/03/2019.

Step 3. Implementation of a scheduling program to periodically and automatically check the newly-issued certificates from our repository. Effective 30/05/2019.

Assignee: wthayer → realsky
Status: NEW → ASSIGNED
Summary: Chunghwa Telecom: → Chunghwa Telecom: Test certificate with unregistered domain name

The automatic FQDN-checking function has been implemented and enforced in Public CA on March 15.
The issuance of any cert with unregistered FQDN can no longer be carried out now.

Whiteboard: [ca-compliance] - Next Update - 01-April 2019 → [ca-compliance] - Next Update - 01-June 2019
  1. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

Ans:
To avoid making the same mistakes, the following steps will newly be introduced:

Step 1. Implementation of a two-stage manual verification by different RAOs. Effective 26/02/2019.

Step 2. Implementation of an automatic FQDN-checking function prior to issuing certificates. Effective 30/03/2019.

Step 3. Implementation of a scheduling program to periodically and automatically check the newly-issued certificates from our repository. Effective 30/05/2019.

The scheduling program that can periodically and automatically check the newly-issued certificates from our repository has been implemented on May 6th.

To avoid the same problem happened in those previously-issued certificates, we scanned the whole repository and found that some FQDNs in the issued certificates are inaccurate due to a change to domain’s ownership, or a relevant licensing or services agreement between the Domain Name Registrar and our customers has terminated. For the former case, we have revoked the certs immediately according to the provisions in Section 4.9.1 of our CP/CPS. For the latter case, we have asked our customers who still want to have the certificate to renew their certificates; otherwise, we will revoke these certs within 5 days according to the provisions in Section 4.9.1 of our CP/CPS.

Thanks for the update, and for taking the appropriate steps to adhere to your CP/CPS with respect to domain ownership changes. Given that the Subscriber Agreement requires Subscribers to notify the CA of such changes, have any steps been taken to examine other certificates from those Subscribers? Have any steps been taken to notify those Subscribers - or all Subscribers - of their obligations under their existing Subscriber Agreements of Terms of Use?

Can you provide further technical details about what the automatic FQDN-checking function does, and what the scheduling program does? Please provide a meaningful overview of the logic and tasks that these systems do.

Flags: needinfo?(realsky)

(In reply to Ryan Sleevi from comment #3)

Thanks for the update, and for taking the appropriate steps to adhere to your CP/CPS with respect to domain ownership changes. Given that the Subscriber Agreement requires Subscribers to notify the CA of such changes, have any steps been taken to examine other certificates from those Subscribers? Have any steps been taken to notify those Subscribers - or all Subscribers - of their obligations under their existing Subscriber Agreements of Terms of Use?

The scheduling program can help us to find the issued TLS/SSL certs with unreliable FQDNs caused by domain ownership changes or a relevant licensing or services agreement between the Domain Name Registrar and the subscribers has terminated, not only focus on a specific subscriber.

As to the obligations of the subscribers which we have claimed in the Subscriber Agreements or
Terms of Use, they must adhere to our CP/CPS and shall own or be authorized to use the domain names listed in the certs during use. If there is a violation, the issuing CA may revoke the certs without any notification; or the issuing CA may give the subscribers a grace period and ask them who still want to have the certs to renew their certs. In this case (please refer to the recent report), we had informed our customers about this matter and the effect of revoking their certs upon we scanned the whole repository.

Can you provide further technical details about what the automatic FQDN-checking function does, and what the scheduling program does?
Please provide a meaningful overview of the logic and tasks that these systems do.

With regard to the automatic FQDN-checking function, it can help us to check whether a FQDN listed in a cert to be issued is registered prior to issuing that cert.

The logic and tasks of this program do are as follows:

Part I. Checking the Name Server or IP Address of the FQDN using Dig instruction
(1) Ask the NS record from a DNS to check is there a record of the (parent) domain? If the answer is no, go to (2); if the answer is yes, then the program continues to Part II.
(2) Ask the A record from a DNS to check is there a record of its IP? If the answer is yes, the program continues to Part II; otherwise, the program stops the issuance of the cert.

Part II. RAOs manually check the FQDN, if everything is ok, then the cert is issued.

With regard to the scheduling program which we have stated above, this program is an extension of the FQDN-function but aiming at all issued and valid (not expired and revoked) TLS/SSL certs, which can be enforced periodically.

Flags: needinfo?(realsky)

Wayne: Is there anything further that you'd like with this bug?

The described algorithm seems that it will require more work of the CA - legitimate changes of IP addresses may require additional review, while changes to WHOIS information may go undetected - but on the balance, over-triggering instead of under-triggering seems preferable?

Flags: needinfo?(wthayer)

Li-Chun: How was an RAO able to issue two certificates without performing domain control validation (which is impossible if the name isn't registered)? Based on your description of the automatic FQDN checking system, I am assuming that the RAO must still manually verify that the Subscriber controls the domain name? If so, I think there is still a very significant opportunity for human error that is only partially addressed by the two-stage manual process. Is there an opportunity to automatically check both the existence of the domain and that domain control has been properly verified?

Flags: needinfo?(wthayer) → needinfo?(realsky)
Whiteboard: [ca-compliance] - Next Update - 01-June 2019 → [ca-compliance]

(In reply to Wayne Thayer [:wayne] from comment #6)

How was an RAO able to issue two certificates without performing domain control validation?

Ans: That’s why we implement the automatic FQDN-checking function. Actually, the program executed once during Part I (checking the Name Server or IP Address of the FQDN using Dig instruction) and it would execute once again after Part II at the time that a RAO performs the action of approving certificate request (prior to issuing certs of the CA ). As we said before, the issuance of any cert with unregistered FQDN can no longer be carried out after the automatic FQDN-checking function is implemented and enforced.

Is there an opportunity to automatically check both the existence of the domain and that domain control has been properly verified?

Ans: Yes, of course we can ask our CA system vendor to include this function that can automatically check the existence of the domain name and validate the domain control rights. However, our company’s security policy does not allow us to do the part regarding the automatically validation of the domain control rights. Because the CA system has to send a request to the domain to be verified and the firewall’s policy must set to any policy accordingly which will increase the chances of our company’s network being attacked. About this part, we are still seeking a better solution and may implement this function within three months.

 Thanks.
Flags: needinfo?(realsky)

Thank you for the reply Li-Chun,

(In reply to Li-Chun CHEN from comment #7)

(In reply to Wayne Thayer [:wayne] from comment #6)

How was an RAO able to issue two certificates without performing domain control validation?

Ans: That’s why we implement the automatic FQDN-checking function.

From your description, I do not think that the automatic FQDN-checking function solves the problem of an RAO being able to approve a registered domain that is not controlled by the requestor.

Actually, the program executed once during Part I (checking the Name Server or IP Address of the FQDN using Dig instruction) and it would execute once again after Part II at the time that a RAO performs the action of approving certificate request (prior to issuing certs of the CA ). As we said before, the issuance of any cert with unregistered FQDN can no longer be carried out after the automatic FQDN-checking function is implemented and enforced.

Is there an opportunity to automatically check both the existence of the domain and that domain control has been properly verified?

Ans: Yes, of course we can ask our CA system vendor to include this function that can automatically check the existence of the domain name and validate the domain control rights. However, our company’s security policy does not allow us to do the part regarding the automatically validation of the domain control rights. Because the CA system has to send a request to the domain to be verified and the firewall’s policy must set to any policy accordingly which will increase the chances of our company’s network being attacked. About this part, we are still seeking a better solution and may implement this function within three months.

Please update this bug when a solution has been identified.

 Thanks.

Setting a Needs-Info. Li-Chun, it would be good to provide weekly updates, per https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed , until concrete timelines are identified and discussed. We want to ensure timely progress on issues and the proposed solutions.

Flags: needinfo?(realsky)

After discussed with our colleagues and CA system vendor, we made the following conclusions:

(1) As specified in our CPS, Public CA allow subscribers to submit their OV applications in writing. Note that the previous two mis-issued certs are OV certs not DV certs. In comparison to DV certs application which only needs to verify the applicant’s domain control, OV certs application sometimes needs additional review work like the information listed on the written application (where non-automated processes are still needed for organization identity authentication) that cannot be automatically performed by a program but can only be done by our RAOs. Therefore, as discussed in the following IETF link, we think that a program to automatically check both the existence of the domain and that domain control has been properly verified is only applicable to DV certs. (https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html)

(2) To solve the problem of an RAO may be able to approve a registered domain that is not controlled by the requestor, we have asked our CA system vendor to include the two validation methods specified in BR 3.2.2.4.6 (Agreed-Upon Change to Website) and 3.2.2.4.7 (DNS Change) for validation of authority in the hotfix within three months. After implemented the new checking function, our CA system will automatically check both the existence of the domain and that domain control prior to issuing OV certs.

Flags: needinfo?(realsky)

(In reply to Li-Chun CHEN from comment #10)

After discussed with our colleagues and CA system vendor, we made the following conclusions:

(1) As specified in our CPS, Public CA allow subscribers to submit their OV applications in writing. Note that the previous two mis-issued certs are OV certs not DV certs. In comparison to DV certs application which only needs to verify the applicant’s domain control, OV certs application sometimes needs additional review work like the information listed on the written application (where non-automated processes are still needed for organization identity authentication) that cannot be automatically performed by a program but can only be done by our RAOs. Therefore, as discussed in the following IETF link, we think that a program to automatically check both the existence of the domain and that domain control has been properly verified is only applicable to DV certs. (https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html)

I do not understand this response. While OV certificates require additional checks that may be difficult to fully automate, they also require the same domain control checks performed for DV certificates.

(2) To solve the problem of an RAO may be able to approve a registered domain that is not controlled by the requestor, we have asked our CA system vendor to include the two validation methods specified in BR 3.2.2.4.6 (Agreed-Upon Change to Website) and 3.2.2.4.7 (DNS Change) for validation of authority in the hotfix within three months. After implemented the new checking function, our CA system will automatically check both the existence of the domain and that domain control prior to issuing OV certs.

This is good to hear. Please update us when this functionality is in place, and if anything happens to delay it. I have set the 'next update' for this bug to 3 months from now.

Whiteboard: [ca-compliance] → [ca-compliance] - 14-October 2019

(In reply to Wayne Thayer [:wayne] from comment #11)

(1) As specified in our CPS, Public CA allow subscribers to submit their OV applications in writing. Note that the previous two mis-issued certs are OV certs not DV certs. In comparison to DV certs application which only needs to verify the applicant’s domain control, OV certs application sometimes needs additional review work like the information listed on the written application (where non-automated processes are still needed for organization identity authentication) that cannot be automatically performed by a program but can only be done by our RAOs. Therefore, as discussed in the following IETF link, we think that a program to automatically check both the existence of the domain and that domain control has been properly verified is only applicable to DV certs. (https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html)

I do not understand this response. While OV certificates require additional checks that may be difficult to fully automate, they also require the same domain control checks performed for DV certificates.

I also don't quite understand this. Note that ACME is specified as RFC 8555. ACME's design permits CAs to add additional steps during the verification process, whether they be requiring explicit approval by the account holder or additional validation of other certificate fields (consistent with the RA/CA processes). This is why handling such as "External Account Binding" or "Responding to Challenges" exist, allowing clients to associate with their OV account and to allow requests to be in "pending" states while the CA performs additional validations.

To be clear: ACME can be used with DV, OV, EV, QWAC, or virtually any certificate.

Li-Chun: Please respond to the questions in comments 11 and 12, and provide an update on the status of the new checking functionality.

Also, please explain why Chunghwa Telecom has not provided any updates on this issue for 6 months. Mozilla expects weekly updates (https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed).

Flags: needinfo?(realsky)

(In reply to Wayne Thayer [:wayne] from comment #13)

Li-Chun: Please respond to the questions in comments 11 and 12, and provide an update on the status of the new checking functionality.

Also, please explain why Chunghwa Telecom has not provided any updates on this issue for 6 months. Mozilla expects weekly updates (https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed).

I am sorry for the late response.

 We agree with Wayne's and Ryan's comments in 11 and 12 and have told with our CA system vendor.

 Our CA system vendor will include five validation methods specified in BR including 3.2.2.4.6 (Agreed-Upon Change to Website), 3.2.2.4.7 (DNS Change - DNX.TXT), 3.2.2.4.2 Email Domain Contact, 3.2.2.4.4 Constructed Email to Domain Contact and 3.2.2.4.12 Validating the Applicant as a Domain Contact in the hotfix. Our CA system vendor adds three More methods for automatic domain name check function than last July's plan after discussion.

 The lunar New Year in Taiwan is from January 23 to January 30. After fixing some bugs that we tested before the lunar New Year national holidays. We estimate above automatic domain name check function in SSL RA plus the function of issuing ECC SSL certificates will go live around February 18.

Thank you.
Flags: needinfo?(realsky)

Therefore, as discussed in the following IETF link, we think that a program to automatically check both the existence of the domain and that domain control has been properly verified is only applicable to DV certs. (https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html)

Given the lack of response to questions about this statement from Chunghwa Telecom, my conclusion is that Chunghwa agrees that it is incorrect.

I'm setting the Next Update to 19-February. Li-Chun, please ensure that an update is provided here by that date.

Flags: needinfo?(realsky)
Whiteboard: [ca-compliance] - 14-October 2019 → [ca-compliance] - 19-February 2020

Right, I believe Li-Chun addressed the agreement with Comment #11 and Comment #12 in Comment #14.

However, the question raised in Comment #13 is still unaddressed:

Also, please explain why Chunghwa Telecom has not provided any updates on this issue for 6 months. Mozilla expects weekly updates (https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed).

I think that will be an important part of the answer, preferably sooner than the deployment of the new CA software.

(In reply to Wayne Thayer from comment #15)

Therefore, as discussed in the following IETF link, we think that a program to automatically check both the existence of the domain and that domain control has been properly verified is only applicable to DV certs. (https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html)

Given the lack of response to questions about this statement from Chunghwa Telecom, my conclusion is that Chunghwa agrees that it is incorrect.

I'm setting the Next Update to 19-February. Li-Chun, please ensure that an update is provided here by that date.

Regarding automatically checking the domain existence and the domain control, we did misunderstand the content of ACME. As Ryan mentioned in comment 12, ACME can be used with DV, OV, EV and QWAC certificates.

Also we agree that "while OV certificates require additional checks that may be difficult to fully automate, they also require the same domain control checks performed for DV certificates."

Flags: needinfo?(realsky)

(In reply to Ryan Sleevi from comment #16)

Right, I believe Li-Chun addressed the agreement with Comment #11 and Comment #12 in Comment #14.

However, the question raised in Comment #13 is still unaddressed:

Also, please explain why Chunghwa Telecom has not provided any updates on this issue for 6 months. Mozilla expects weekly updates (https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed).

I think that will be an important part of the answer, preferably sooner than the deployment of the new CA software.

In fact, the CA system vendor already provided us with a first version hotfix in last early October. But we ask them to add three More methods for automatic domain name validation (actually, there are more extra matters) and the function of issuing ECC SSL certs than last July’s plan to comply with our CPS, so we postponed our original plan. We already have completed some tests (which take times and cause the delay in response) and estimate that the aforementioned functions can be enforced around February 18, 2020. Thanks.

Li-Chun: Thanks for the explanation about what Chunghwa Telecom was doing then. This is very useful and important information.

However, the question being asked is understanding why Chunghwa Telecom wasn't notifying this bug about these details as they became available. As mentioned in Responding to an Incident, the expectation is that the CA provides timely updates for issues, and does not delay for more than a week unless previously agreed by a Module Owner or Peer.

This is a question about Chunghwa Telecom's processes for keeping root stores informed of issues and plans, why they failed (that is, why no one from Chunghwa Telecom updated this bug), and what's being done to prevent future failures.

I'm hesitant to set a Next-Update of 18-February, without understanding what Chunghwa Telecom has done and changed to make sure it will provide a timely update.

We have several colleagues assigned and responsible for tracing the discussions on Bugzilla. We apologize for making a wrong decision that we did not reply regularly and thought it would be adequate to report the status after the functionality goes live. During that period, we got many projects need to complete and we did misunderstand the comments proposed by the Module Owner or Peer. We were dedicated on” how to make the Domain Name verification of OV SSL certificates automatic” and discussing possible development methods with our CA system vendor at that time; and planned to reply the status to this matter when the functionality that we promised are completed and the test cases are sufficient. But in fact, we also have to reply the status if anything happens to delay it (as mentioned by Wayne in Comment 11), we apologize again for the misconception and we guarantee that we will reply the status weekly.

This week’s update: The CA system vendor will complete the development of automatic validation for the method “Agreed‐Upon Change to Website” mentioned in Section 3.2.5.4 of our CPS on this Friday.

This week’s update: Our CA system vendor had completed the automatic validation functionality for the method “Agreed‐Upon Change to Website”, and we are currently testing this functionality in our testing environment.

Thanks.

This week's update: Still under testing and modifying of the automatic validation functionality for the method “Agreed‐Upon Change to Website”, and will be go lived in our CA system this afternoon.

This week's update: UI interface adjustment and correction of WHOIS API connection issues.
Thank you.

This week's update: Correction of WHOIS API connection issues.

This week's update: Seeking a stable WHOIS API.

This week's update:The same as last week.

Li-Chun: Thanks for making sure to update this weekly. That's definitely an improvement.

It's unclear whether the changes went live in Comment #22. It's also unclear what is meant by a "WHOIS API" in Comment #23 - Comment #26.

The CA is responsible for performing the WHOIS themselves. That is, it would not be acceptable to use a third-party source to perform the WHOIS lookup, since that would be delegating domain validation functions to a Delegated Third Party. Could you explain a bit more?

Flags: needinfo?(realsky)

Ryan:

  1. The changes in Comment #22 had went live.
  2. As to “Whois API” in Comment #23 - Comment #26, our CA system vendor responses that the response of the WHOIS protocol has a decoding problem for Chinese company name when performing the WHOIS lookup. Please see the attachment.

Therefore, they can only use the WHOIS API for now to achieve automatic domain name validation.
If a third-party source (e.g., whoisjson.com) is not allowed, then our RAOs may need to manually perform the WHOIS lookup for identity validation of OV certs applicants.

  1. This week's update: The same as last week.

Thanks.

Flags: needinfo?(realsky)

The Baseline Requirements do not permit you to use whoisjson.com, because that would make them a Delegated Third Party, and that is forbidden. They would have to design their systems in compliance with the BRs, and be part of the scope of CHT’s audit, for that to be permitted. That’s why I wanted to flag this, because it would be a BR violation if you have used this data source.

CHT requests SSL RAOs still use manual WHOIS Look UP to reserve the vetting trails and check the performance and result of automatic domain name check function until now. So there is not a violation of BR for SSL RAOs. We have requested CA system vendor to solve the decoding problem for using WHOIS protocol to check those source. Thanks for Ryan's reminding.

We still ask our RAOs to manually use WHOIS look up and reserve the vetting trails after the automatic validation functionality went lived on February 18.

Weekly Update:
Solving the Chinese decoding problem of parsed rawdata obtained by using WHOIS protocol.

Weekly Update: Solving the Chinese decoding problem of parsed rawdata obtained by using WHOIS protocol.

Weekly Update: the Chinese decoding problem of parsed raw data obtained by using WHOIS protocol is solved.

Weekly Update: parsing raw data obtained by using WHOIS protocol.

Weekly Update: The same as last week.

Weekly Update: The same as last week.

Weekly Update: The same as last week.

Weekly Update: The same as last week.

Li-Chun: Thank you for your commitment to providing weekly updates here. This really is a positive example of a CA following the procedure.

I had some questions, to make sure where we stand on things:

  • Comment #6 flagged the human risk factors involved, and suggested support for automated validation
  • Comment #10 identified domain control validation was necessary and not consistently being followed for OV, but in response 3.2.2.4.6 and 3.2.2.4.7 method support was added
  • Comment #14 identified you were adding 3.2.2.4.2, 3.2.2.4.4, 3.2.2.4.12

If I'm understanding Comment #18, these were largely implemented then, which Comment #31 seems to support (that things were implemented February 18)

If I understand, your follow-up steps have been validating to make sure you don't find any issues with the automated validation, is that correct based on Comment #30? Or are the remaining issues with supporting 3.2.2.4.2?

To confirm:

  • CHT now supports 3.2.2.4.2, 3.2.2.4.4, 3.2.2.4.6, 3.2.2.4.7, 3.2.2.4.12
  • CHT has confirmed all certificate profiles are verified with technical controls, as implemented by your CA software vendor
  • The remaining activity is a manual confirmation via WHOIS of those technical controls
Flags: needinfo?(realsky)

(In reply to Ryan Sleevi from comment #39)

Li-Chun: Thank you for your commitment to providing weekly updates here. This really is a positive example of a CA following the procedure.

I had some questions, to make sure where we stand on things:

  • Comment #6 flagged the human risk factors involved, and suggested support for automated validation
  • Comment #10 identified domain control validation was necessary and not consistently being followed for OV, but in response 3.2.2.4.6 and 3.2.2.4.7 method support was added
  • Comment #14 identified you were adding 3.2.2.4.2, 3.2.2.4.4, 3.2.2.4.12

If I'm understanding Comment #18, these were largely implemented then, which Comment #31 seems to support (that things were implemented February 18)

If I understand, your follow-up steps have been validating to make sure you don't find any issues with the automated validation, is that correct based on Comment #30? Or are the remaining issues with supporting 3.2.2.4.2?

We had been validating our CA system during these weeks to make sure that there has no issue with the automated validation via WHOIS protocol, and just in case (to avoid inaccurate cases discussed in bugzilla), we still ask our RAOs to reserve the vetting trails before the system is stable.

To confirm:

  • CHT now supports 3.2.2.4.2, 3.2.2.4.4, 3.2.2.4.6, 3.2.2.4.7, 3.2.2.4.12

 Our CA system now supports 3.2.2.4.4, 3.2.2.4.6, 3.2.2.4.7 and 3.2.2.4.12, and 3.2.2.4.2 is under developing.

  • CHT has confirmed all certificate profiles are verified with technical controls, as implemented by your CA software vendor
	Yes, we had confirmed that our CA system vendor had implement preissuance linters in compliance with the guidelines of RFC and CABF. We also ask them to continue to pay attention to the latest news of other Lint programs on M.D.S.P, e.g., CABLint (https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/RH5oRS8ZbXo0) and Zlint (https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/WEr2M6Pp18k).
  • The remaining activity is a manual confirmation via WHOIS of those technical controls

 Due to GDPR, the details of some domains shared via WHOIS are masked. To solve this matter, we asked our CA system vendor to develop 3.2.2.4.13 and 3.2.2.4.14, and expect that the automated validation methods of 3.2.2.4.2, 3.2.2.4.13 and 3.2.2.4.14 can go live before June 18.

Flags: needinfo?(realsky)

Weekly Update: developing 3.2.2.4.2, 3.2.2.4.13 and 3.2.2.4.14.

Thanks for the update! I'm seeing if Wayne has further questions here, as I want to make sure I'm not missing things.

(In reply to Li-Chun CHEN from comment #40)

If I understand, your follow-up steps have been validating to make sure you don't find any issues with the automated validation, is that correct based on Comment #30? Or are the remaining issues with supporting 3.2.2.4.2?

We had been validating our CA system during these weeks to make sure that there has no issue with the automated validation via WHOIS protocol, and just in case (to avoid inaccurate cases discussed in bugzilla), we still ask our RAOs to reserve the vetting trails before the system is stable.

Just to make sure: The WHOIS validation method will require you preserve the validation trail for 7 years anyways, per Section 5.4.1 of the BRs (specifically, 2(b) ). I wasn't sure how to understand "we still ask", since that will always be a requirement, both during development and during production.

Flags: needinfo?(wthayer)

No questions here. I'm just waiting for confirmation that the 3 additional validation methods have been deployed.

Flags: needinfo?(wthayer)
Whiteboard: [ca-compliance] - 19-February 2020 → [ca-compliance]

(In reply to Ryan Sleevi from comment #42)

Thanks for the update! I'm seeing if Wayne has further questions here, as I want to make sure I'm not missing things.

(In reply to Li-Chun CHEN from comment #40)

If I understand, your follow-up steps have been validating to make sure you don't find any issues with the automated validation, is that correct based on Comment #30? Or are the remaining issues with supporting 3.2.2.4.2?

We had been validating our CA system during these weeks to make sure that there has no issue with the automated validation via WHOIS protocol, and just in case (to avoid inaccurate cases discussed in bugzilla), we still ask our RAOs to reserve the vetting trails before the system is stable.

Just to make sure: The WHOIS validation method will require you preserve the validation trail for 7 years anyways, per Section 5.4.1 of the BRs (specifically, 2(b) ). I wasn't sure how to understand "we still ask", since that will always be a requirement, both during development and during production.

Of course our CA system preserved the validation trail for 7 years, per the BRs during development and during production. As to "we still ask", that means we also keep the validation trail manually as well.

Weekly update: 3.2.2.4.13 is under testing and debugging.

Weekly update: 3.2.2.4.14 is under testing and debugging.

Weekly update: 3.2.2.4.13 and 3.2.2.4.14 go live.

3.2.2.4.2 is under testing and debugging and will go live within a few days.

Weekly update: 3.2.2.4.2 has went live.

Are there additional remediation items that need to be addressed? Also, I note that Chunghwa Telecom's most recent audit period ended on 31-May-2020, so I suspect we'll be seeing audit reports shortly. The audit report should acknowledge this bug and that the auditor was aware of it (i.e. that Chunghwa Telecom discloses it to the auditor). If Chunghwa need examples of this language, I will provide it with WebTrust audit letters from Entrust, Digicert, etc.

(In reply to Ben Wilson from comment #50)

Are there additional remediation items that need to be addressed? Also, I note that Chunghwa Telecom's most recent audit period ended on 31-May-2020, so I suspect we'll be seeing audit reports shortly. The audit report should acknowledge this bug and that the auditor was aware of it (i.e. that Chunghwa Telecom discloses it to the auditor). If Chunghwa need examples of this language, I will provide it with WebTrust audit letters from Entrust, Digicert, etc.

  1. Let we summarize the ins and outs of this incident report first:
    On February 15, 2019, our CA system had issued a test certificate with unregistered domain name due to human reasoning. We then reported the incident and revoked the mis-issued certs immediately at that time. To avoid the same problem happened, we enforced the automatic FQDN checking function a few months later, and then further to improve our CA system with automatic validation that can automatically check both the existence of the domain and that domain control. The issuance of any cert with unregistered FQDN can no longer be carried out now, even an RAO being able to approve a registered domain that is not controlled by the requestor.

  2. We had informed the auditor when we found the incident and had synchronized every bugzilla replies with them.

  3. As to the automatic validation, 3.2.2.4.2, 3.2.2.4.13 and 3.2.2.4.14 are just went live for days. After accumulating enough use-cases and confirming that the whole system is work properly, we will made a report here soon. In addition, as we mentioned in comment#44, we still keep the validation trail manually.

Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 31-July 2020

We are still in the annual audit process conducted by our qualified auditor. As to the use-cases, there are more than 67 use-cases for 3.2.2.4.2 but none for 3.2.2.4.13 and 3.2.2.4.14 since the time that these methods go lived. However, we have validated these methods by simulating enough use-cases in our test environment and of course synchronized every method-testing status with our qualified auditor.

By the way, the validating result of these three new validation methods will not be include in scope of the annual audit report this time due to these methods go lived after mid-June and the audit period this time is from 1-June-2019 to 31-May-2020.

Whiteboard: [ca-compliance] - Next Update - 31-July 2020 → [ca-compliance]
QA Contact: wthayer → bwilson

CHT's WTCA_2020_Sealfile

CHT's SSL BR with Network Security Seal File.

Ben: I'm encouraged to see the details in Appendix C and Appendix D of the reports on Comment #53. I'm not sure if you had follow-up questions, based on Comment #50

Flags: needinfo?(bwilson)

I will close this bug on or about 9-October-2020 unless there are additional comments or questions.

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [ov-misissuance]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: