Closed Bug 1464306 Opened 7 years ago Closed 6 years ago

Add Hongkong Post renewal root certificate "Hongkong Post Root CA 3"

Categories

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

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: manho, Assigned: kathleen.a.wilson)

References

Details

(Whiteboard: [ca-approved] - in NSS 3.43, FF 67; EV-enabled in FF 68)

Attachments

(6 files, 5 obsolete files)

CA's BR Self Assessment V1.3 (final).pdf
174.86 KB, application/pdf
Details
Root CA3 and SubCAs.zip
6.70 KB, application/x-zip-compressed
Details
Hongkong Post CA Information.pdf
356.70 KB, application/pdf
Details
1464306-CA-Information-August27-2018.pdf
125.22 KB, application/pdf
Details
e-Cert (Server) CPS-Eng-1.7.4.pdf
1.01 MB, application/pdf
Details
Webtrust EV SSL Report 20181219.pdf
378.20 KB, application/pdf
Details
Attached file Hongkong Post CA Information.pdf (obsolete) —
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36 Steps to reproduce: Hongkong Post has one root certificate (Subject CN=“Hongkong Post Root CA 1”) that has already been trusted in the Mozilla Root Certificate Program. Since it is approaching to the expiry date of this root certificate, Hongkong Post has planned to rollover this root certificate to two new root certificates (one for issuing SSL certificates and one for issuing non-SSL certificates), and alongside start issuing EV SSL certificates. Actual results: For transition of all end-entity certificates to under new PKIs, we plan to separate them into two PKIs of root certificates, i.e. subject cn=”Hongkong Post Root CA 2” (“Root CA2”) and cn=”Hongkong Post Root CA 3” (“Root CA3”). Both root certificates and their SubCA certificates have been generated. Root CA2 is used to issue SubCAs that will issue client certificates only. Root CA3 is used to issue SubCAs that will issue SSL certificates only, including one SubCA that issues SSL certificate and another SubCA that issues EV SSL certificate. Expected results: The existing root certificate will expire in 15 May 2023. Customers of our SSL certificates, mainly from Bureaux and Departments of the Government of Hong Kong SAR, are serving over 8 million people of Hong Kong. It is important to renew the existing root certificate to Root CA3 as soon as possible, or no later than the end of 2018. EV treatment for Root CA3 is also required.
EV e-Cert (Server) yet to be publicly issued, but supported by this CPS
Attached file Webtrust EV SSL Report.pdf (obsolete) —
A WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL (Point-in-time) audit as of 31 March 2018 has been completed.
It contains certificates of : Root CA certificate : cn="Hongkong Post Root CA 3" SubCA certificates : cn=“Hongkong Post e-Cert SSL CA 3-17” (for non-EV SSL), cn=“Hongkong Post e-Cert EVSSL CA 3-17” (for EV SSL) Cross-certificate signed by Hongkong Post Root CA 1 : cn="Hongkong Post Root CA 3"
Fixed a typo of EV Policy OID
Attachment #8980475 - Attachment is obsolete: true
Acknowledging receipt of this root inclusion request. I have a huge backlog of CA updates/requests to review, so this has been added to my list. I will update this bug when I begin information verification of this request as per step #2 of our process: https://wiki.mozilla.org/CA/Application_Process#Process_Overview
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-verifying]
I'm reviewing this request now... Is this request to include two new root certs? 1) "Hongkong Post Root CA 3" -- Websites trust bit, EV enable 2) "Hongkong Post Root CA 2" -- Email (S/MIME) trust bit
This request only include the root certificate "Hongkong Post Root CA 3" for website trust bit and EV treatment.
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.
Assignee: kwilson → wthayer
Whiteboard: [ca-verifying] → [ca-cps-review] - KW 2018-08-27
Note to Wayne: The new CPS that has this new "Hongkong Post Root CA 3" root has not been officially published yet, so it is attached to this bug. https://bug1464306.bmoattachments.org/attachment.cgi?id=8980476
I have begun to review this request and have some questions: 1. The EV audit is point-in-time dated March 31, 2018. When will a period-of-time EV audit be completed? EVGL section 17 requires a period-of-time audit within 90 days of issuing the first EV certificate. 2. Is there a Certificate Policy (CP)? I usually see either two documents (CP and CPS), or else the combined document is called a "CP/CPS". 3. The 'version 2' CPS attached to the bug is different than the published 'version 2' on the website. Please publish a version of the CPS containing all EV policies and all other updates. I will need this before I can complete my review. 4. Since the CPS allows external RAs, does it state that domain validation functions must not be performed by external RAs? 5. CPS section 3.4 indicates that certificates may be suspended. This would violate BR 4.9.13. Do you want to change this? 6. The heading of CPS section 4.1.2 contains a misspelling "enrolment" 7. CPS section 4.9.1 does not appear to include all of the revocation reasons required by BR 4.9.1.1 Would you like to update that?
Flags: needinfo?(manho)
Whiteboard: [ca-cps-review] - KW 2018-08-27 → [ca-cps-review] - Pending CPS Updates 2018-09-20
Hi Wayne, Thanks for your questions. 1. Yes, the EV audit was a point-in-time report because we have not yet issue any EV SSL certificates. Once Mozilla approved EV treatment of our root and EV SSL subCA certificates, we'll start issuing EV certificate ASAP. Then we'll publish a period-of-time audit report within 90 days of issuing the first EV certificate. 2. Our CP and CPS are combined into one document, CP/CPS. 3. Changes to 'version 2' that was published on our website are due to the CAB Forum ballot 218 required removal of domain validation methods BR 3.2.2.4.1 & 3.2.2.4.5. I attach a 'version 3' CPS to this bug with tracked changes for your review. 4. We may use external parties such as RA(s) appointed by Hongkong Post, or subcontractor(s) of Certizen, to carry out certain functions of Hongkong Post CA, but not domain validation. At the moment, For avoidance of doubt, we can state in CPS that domain validation functions will not be performed by external parties. Which section of CPS should this statement be placed? 5. Suspended certificates are also put in Certificate Revocation List (CRL), same effect of revocation of certificate. It is not our intention to 'un-suspend' any suspended certificate, but to disclose a procedural step prior to revocation of certificate. We may remove all descriptions of suspension of certificate in CPS, or add a statement that the effect of suspension is the same as revocation, in other words certificate status cannot be reinstated. Which way do you think is better? 6. If I understand correctly, both words 'enrolment' and 'enrollment' are correct and the same meaning. 'Enrolment' is a standard British-style English, but 'Enrollment' is an American-style English. 7.
Flags: needinfo?(manho)
7. Yes, we will review and update the CPS.
Attachment #8980476 - Attachment is obsolete: true
(In reply to Man Ho from comment #13) > Hi Wayne, > > Thanks for your questions. > Thank you for your responses. > 1. Yes, the EV audit was a point-in-time report because we have not yet > issue any EV SSL certificates. Once Mozilla approved EV treatment of our > root and EV SSL subCA certificates, we'll start issuing EV certificate ASAP. > Then we'll publish a period-of-time audit report within 90 days of issuing > the first EV certificate. You have already issued EV certificates: https://valid-ev.ecert.gov.hk/ contains policy OID 2.23.140.1.1 > 2. Our CP and CPS are combined into one document, CP/CPS. Okay. > 3. Changes to 'version 2' that was published on our website are due to the > CAB Forum ballot 218 required removal of domain validation methods BR > 3.2.2.4.1 & 3.2.2.4.5. I attach a 'version 3' CPS to this bug with tracked > changes for your review. Is there anything preventing you from publishing a version of the CPS containing the EV changes? I normally base my comments on a published version, not a draft that could later change. > 4. We may use external parties such as RA(s) appointed by Hongkong Post, or > subcontractor(s) of Certizen, to carry out certain functions of Hongkong > Post CA, but not domain validation. At the moment, For avoidance of doubt, > we can state in CPS that domain validation functions will not be performed > by external parties. Which section of CPS should this statement be placed? There is no specific best place for this statement. I recommend putting it in the section covering external RAs, domain validation, or in both sections. > 5. Suspended certificates are also put in Certificate Revocation List (CRL), > same effect of revocation of certificate. It is not our intention to > 'un-suspend' any suspended certificate, but to disclose a procedural step > prior to revocation of certificate. We may remove all descriptions of > suspension of certificate in CPS, or add a statement that the effect of > suspension is the same as revocation, in other words certificate status > cannot be reinstated. Which way do you think is better? Because the term "suspended" has a specific meaning in RFC 5280 and it is not permitted, I would suggest that you remove descriptions of "suspended" for SSL certificates. > 6. If I understand correctly, both words 'enrolment' and 'enrollment' are > correct and the same meaning. 'Enrolment' is a standard British-style > English, but 'Enrollment' is an American-style English. Okay. > 7. Yes, we will review and update the CPS. Please update this bug when the new version has been published.
(In reply to Wayne Thayer [:wayne] from comment #16) > You have already issued EV certificates: https://valid-ev.ecert.gov.hk/ > contains policy OID 2.23.140.1.1 > The domain name ecert.gov.hk is owned by us. It is created only for testing by Mozilla and general public. The respective CRL and OCSP service are continously up and running. What I mean is that we haven't issued any EV SSL certificates to our customers. Do you suggest us to prepare a period-of-time audit report covering only this certificate? > > Is there anything preventing you from publishing a version of the CPS > containing the EV changes? I normally base my comments on a published > version, not a draft that could later change. > The CPS is not yet published because we haven't started issuing EV SSL certificates to customers, not because it may be changed later. The CPS attached to this bug is ready for publish. > > > 7. Yes, we will review and update the CPS. > > Please update this bug when the new version has been published. Will do. Thanks again.
Hi Wayne, thanks you for your patience. We have updated the CPS with respect to your comments. Regarding to the period-of-time report of WebTrust for EV SSL, do you suggest that we submit the report for the period from date of certificate of eCert.gov.hk (i.e. 30 May 2018) to now, with report date on now? As I said earlier, those certificates were issued to ourselves, our own domain name eCert.gov.hk, purely for the purpose of testing by Mozilla and the community. We have not yet issued EV SSL certificates to customers.
Attachment #9011359 - Attachment is obsolete: true
(In reply to Man Ho from comment #18) > Created attachment 9018950 [details] > e-Cert (Server) CPS-Eng-7.3 (20181019).pdf > > Hi Wayne, thanks you for your patience. We have updated the CPS with respect > to your comments. > Thank you - I will review it soon. > Regarding to the period-of-time report of WebTrust for EV SSL, do you > suggest that we submit the report for the period from date of certificate of > eCert.gov.hk (i.e. 30 May 2018) to now, with report date on now? As I said > earlier, those certificates were issued to ourselves, our own domain name > eCert.gov.hk, purely for the purpose of testing by Mozilla and the > community. We have not yet issued EV SSL certificates to customers. Since the EVGLs make no distinction between issuing an EV certificate to yourself and to a customer, I would recommend that you obtain a PoT EV audit as soon as possible. However, it appears that you are already past the 90 days after PiT required by EVGL section 17.4. Because this is an area that is not well defined, I will not delay the public discussion of your request until a PoT audit is received. I am planning to publish a clearer description of the audit requirements in hopes of preventing future problems like this.
QA Contact: kwilson
I reviewed the draft CPS attached in comment #18. Section 4.9.1.1 still does not appear to be updated with all the revocation reasons required by the BRs. Otherwise this version fixes the problems listed in comment #12. I do not normally begin discussions using a draft version of the CPS. Why can't Hongkong Post publish this version of the CPS?
(In reply to Wayne Thayer [:wayne] from comment #20) > I reviewed the draft CPS attached in comment #18. Section 4.9.1.1 still does > not appear to be updated with all the revocation reasons required by the > BRs. Otherwise this version fixes the problems listed in comment #12. > Thanks you again. We can handle all the revocation reasons as required by the BRs Section 4.9.1.1, but not realize that we should copy the reasons point by point in our CPS. I shall update with more details in that section. > I do not normally begin discussions using a draft version of the CPS. Why > can't Hongkong Post publish this version of the CPS? As I said, we cannot issue EV certificate to customers until Mozilla, or at least some other root certificate programs, have granted EV treatment to our root certificate. So, we do not yet publish the CPS in order to avoid confusion to customers. However, in order not to give an impression that it is a draft version, we will publish it in Hongkong Post website for next discussion within Mozilla community. We welcome any comments that actually improve our work as a CA. I need to go through certain internal process, and will update again when it is done.
Eventually we've gone through the internal procedure. A pre-production CPS for e-Cert (Server) in Hongkong Post CA website at the web page https://www.ecert.gov.hk/product/ecert/type/server/index.html, or download the CPS directly at URL https://www.ecert.gov.hk/ev/e-Cert%20(Server)%20CPS-Eng-1.7.4.pdf. In the meantime, a period-of-time WebTrust report for Extended Validation SSL CA Operations for Hongkong Post CA is available at https://www.ecert.gov.hk/ev/Webtrust%20EV%20SSL%20Report%2020181219_FINAL%20(with%20Management%20Assertion%20Letter).pdf. Should there be any questions, please don't hesitate to let me know. I'm looking forward to the public discussion on this request.

A pre-production CPS for e-Cert (Server) of Hongkong Post CA is available at URL https://www.ecert.gov.hk/ev/e-Cert%20(Server)%20CPS-Eng-1.7.4.pdf. It is attached in this bug for easy reference.

Attachment #9018950 - Attachment is obsolete: true

A disclosure record of WebTrust for Extended Validation SSL CA Operations for HKPCA is available at URL https://www.ecert.gov.hk/ev/Webtrust%20EV%20SSL%20Report%2020181219_FINAL%20(with%20Management%20Assertion%20Letter).pdf. It is also attached in this bug for easy reference.

Attachment #8980478 - Attachment is obsolete: true

Hi Wayne, I'm sorry to say that we are under immense time pressure to issue our e-Cert (Server) by the renewed root certificate. FYI, we have already announced a root CA rollover plan at Hongkong Post CA website https://www.ecert.gov.hk/news/press/85.html. It's very important to proceed on this bug as soon as possible, so that if there is any other comments, we still have time to respond to them. Thanks you very much.

Flags: needinfo?(wthayer)

Why did the OID change to 1.3.6.1.4.1.16030.1.7.4 in the most recent draft? Will this EV CPS replace the current e-Cert Server CPS when it is published?

Also, please be aware that I will be pointing out the BR issues that remain in the current published e-Cert Server CPS (version 3) - missing revocation reasons in section 4.9.1.1, and support for certificate suspension.

Flags: needinfo?(wthayer) → needinfo?(manho)

The last arc number of the OID indicates the version of CPS. The current CPS (version 3) jumped in because we have to update the period of our outsourcing contract with Hongkong Post, see section 1.2 of the CPS. In other words, this EV CPS will be the version 4 of our CPS, replacing the current CPS (version 3). And this EV CPS will contain major changes for disclosure of revocation reasons as required by BRs section 4.9.1.1, skipping out the procedural step of suspension when handling revocation request and any other comments...etc from Mozilla community. Our deadline for production of this EV CPS is 1 July 2019.

Since we have already made these changes to this EV CPS, I believe that it'll be more productive for the community to discuss this EV CPS rather than the current (but yet-to-be replaced) CPS. Anyway, while you point out the BR issues that remain in the current CPS (version 3), may I emphasize that we currently can handle all the revocation reasons as required by the BRs Section 4.9.1.1, and we do not "un-suspend" certificate as the suspension is only a procedural step prior to revocation of certificate.

Flags: needinfo?(manho)

this EV CPS will contain major changes for disclosure of revocation reasons as required by BRs section 4.9.1.1, skipping out the procedural step of suspension

My typo error, "skipping out" ---> "skipping over"

Began the discussion at https://groups.google.com/d/msg/mozilla.dev.security.policy/xdiyOa5ruao/6caGQ98TDgAJ with the following post:

This request is for inclusion of the Government of Hong Kong, Hongkong
Post, Certizen Hongkong Post Root CA 3 trust anchor as documented in the
following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1464306

I’ve reviewed the CPS, BR Self Assessment, and related information for
inclusion of the Certizen Hongkong Post Root CA 3 that is being tracked in
this bug and have the following comments:

==Good==
This root is relatively new, has continuous BR audit coverage, and appears
to have only signed certificates for the required test websites.

==Meh==

  • The first EV audit was a point-in-time dated March 31, 2018 [1]. Given
    that EV certificates for the test sites were issued in May 2018, one can
    argue that EVGL section 17.4 required a period-of-time audit to have been
    completed in October rather than December as was the case. However, it has
    been common for CAs to argue that certificates for test websites don’t
    count and I have not yet published clear guidance on this issue.
  • There is no document referenced as a CP. Hongkong Post says that the
    document is a combined CP/CPS.
  • In 2016, it was discovered that Hongkong Post was issuing SHA-1
    certificates with non-random serial numbers that could be used for TLS in
    Firefox [2] [3]. The problem was resolved by adding the problematic
    intermediate certificate to OneCRL.
  • The CPS permits external RAs, but according to Appendix E, there are none
    at present. I would prefer that the CPS clearly state that domain
    validation functions are never delegated.
  • Hongkong Post has attached unpublished versions 2 and 3 of their CPS to
    the bug that differ from the published versions 2 and 3 in their
    repository. The latest version “4” is marked as a “Pre-production CPS”.
    They state that “…we cannot issue EV certificate to customers until
    Mozilla, or at least some other root certificate programs, have granted EV
    treatment to our root certificate. So, we do not yet publish the CPS in
    order to avoid confusion to customers.”

==Bad==

  • Fairly recent misissuance under the currently included Hong Kong Post
    Root CA 1: O and OU fields too long [4]. These certificates have all been
    revoked, but no incident report was ever filed.
  • CPS section 3.4 indicates that certificates may be suspended. This would
    violate BR 4.9.13. This has been corrected in the “Pre-production” CPS but
    not the current CPS for their existing root [5].
  • CPS section 4.9.1 does not appear to include all the revocation reasons
    required by BR 4.9.1.1. This has been corrected in the “Pre-production” CPS
    but not the current CPS for their existing root [5].

This begins the 3-week comment period for this request [6].

I will greatly appreciate your thoughtful and constructive feedback on the
acceptance of this root into the Mozilla CA program.

  • Wayne

[1] https://bug1464306.bmoattachments.org/attachment.cgi?id=8980478
[2]
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/Ng99HcqhZtI/bkcimGlECAAJ
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1267332
[4]
https://crt.sh/?caid=7319&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[5] https://www.ecert.gov.hk/product/cps/ecert/img/server_cps_en3.pdf
[6] https://wiki.mozilla.org/CA/Application_Process

Whiteboard: [ca-cps-review] - Pending CPS Updates 2018-09-20 → [ca-in-discussion] - ends after 04-February 2019

Note that the information currently in the CCADB for this request is here:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000314

Hi Wayne,

I think this root inclusion request had been in public discussion phase for some time. I thank you and the Mozilla community for the comments.

Would you consider moving on to next stage of the process?

  • Man
Flags: needinfo?(wthayer)

I summarized the status and requested any final public comments by 20-February.

Flags: needinfo?(wthayer)

As there is no further questions from the community, can we proceed to next stage?

I'm hoping that this Hongkong Post Root CA 3 with website trust bit enabled, and EV treatment (EV Policy OID: 2.23.140.1.1), could catch up the next release of Firefox, if possible.

Thanks you very much.

Flags: needinfo?(wthayer)

The discussion for this request is here: https://groups.google.com/d/msg/mozilla.dev.security.policy/xdiyOa5ruao/6caGQ98TDgAJ

I recommend approval of this inclusion request.

Assignee: wthayer → kwilson
Whiteboard: [ca-in-discussion] - ends after 04-February 2019 → [ca-pending-approval]
Flags: needinfo?(wthayer)

This request is now in step 10: intent to approve has been stated, last call before approval.
https://wiki.mozilla.org/CA/Application_Process#Process_Overview

The information for this request is here:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000314

On behalf of Mozilla, I approve this request from Hongkong Post Certification Authority (HKPCA) to include the following root certificate:

** 'Hongkong Post Root CA 3' (Websites); EV

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

Whiteboard: [ca-pending-approval] → [ca-approved] - Pending NSS and PSM code changes
Depends on: 1532753
Depends on: 1532757

I have filed bug #1532753 against NSS and bug #1532757 against PSM for the actual changes.

Whiteboard: [ca-approved] - Pending NSS and PSM code changes → [ca-approved] - in NSS 3.43, FF 67; pending PSM code changes
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [ca-approved] - in NSS 3.43, FF 67; pending PSM code changes → [ca-approved] - in NSS 3.43, FF 67; EV-enabled in FF 68
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: