Request to Include Hongkong Post Root CA 3

[Wayne Thayer]

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

* BR Self Assessment is here:
https://bug1464306.bmoattachments.org/attachment.cgi?id=8980480

* Summary of Information Gathered and Verified:
https://bug1464306.bmoattachments.org/attachment.cgi?id=9004396

* Root Certificate Download URL:
https://bugzilla.mozilla.org/attachment.cgi?id=8980482

* CP/CPS:
CP: there is no CP
CPS: https://www.ecert.gov.hk/ev/e-Cert%20(Server)%20CPS-Eng-1.7.4.pdf

* This request is to include the root with the websites trust bit enabled
and EV treatment.

* EV Policy OID: 2.23.140.1.1

* Test Websites
https://valid-ev.ecert.gov.hk/
https://expired-ev.hongkongpost.gov.hk
https://revoked-ev.hongkongpost.gov.hk

* CRL URLs:
http://crl1.hongkongpost.gov.hk/crl/RootCA3ARL.crl
http://crl1.hongkongpost.gov.hk/crl/eCertESCA3-17CRL1.crl

* OCSP URL:
http://ocsp1.hongkongpost.gov.hk

* Audit: Annual audits are performed by PricewaterhouseCoopers Hong Kong
according to the WebTrust for CA, BR, and EV audit criteria.
WebTrust: https://www.cpacanada.ca/webtrustseal?sealid=2405
BR: https://www.cpacanada.ca/webtrustseal?sealid=2406
EV:
https://www.ecert.gov.hk/ev/Webtrust%20EV%20SSL%20Report%2020181219_FINAL%20(with%20Management%20Assertion%20Letter).pdf

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

[David E. Ross]

I would think that lack of a CP alone would disqualify this root.
Furthermore, the the "Meh" issues should be resolved before approval.

--
David E. Ross

Trump again proves he is a major source of fake news. He wants
to cut off disaster funds to repair the damage caused by the
Woolsey Fire in southern California because he claims the state
fails to manage its forests properly. The Woolsey Fire was NOT
a forest fire. Starting in an industrial tract, it did not burn
through any forests.

See <http://www.rossde.com/fire.html>.

[Wayne Thayer]

On Mon, Jan 14, 2019 at 5:58 PM David E. Ross via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I would think that lack of a CP alone would disqualify this root.
>

> Does it? I'm not saying that there is missing information, only that the
document is called a "CPS" rather than a "CP/CPS". Also, this concern
applies to the currently included root.

[mirro...@gmail.com]

在 2019年1月15日星期二 UTC+8上午8:58:30，David E. Ross写道：

I think it is ok to combine CP/CPS document instead of maintaining two separate documents. The following is from webtrust for ca 2.1:

Together, the CP and CPS represent a CA’s business practice disclosures. It is leading practice for the CP at a minimum be publically available to relying parties, and most CAs also make their CPS publically available. Many CAs also publish a combined CP/CPS document instead of maintaining two separate documents.

[Ian Carroll]

I do not usually comment on new CA applications, so take this with whatever
grain of salt you'd like, but from looking at [3] I think it should be a
very negative mark against a CA to have to OneCRL one of their
intermediates. If the CA is not committed to closely following web PKI
standards, it's not clear to me that they should be allowed to be trusted
in the web PKI. Combined with the lack of incident reports, I'd hope the
impact this organization could have in the future is considered.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Man Ho]

On 15-Jan-19 12:31 PM, Ian Carroll via dev-security-policy wrote:
> from looking at [3] I think it should be a
> very negative mark against a CA to have to OneCRL one of their
> intermediates.

[3] was reported and discussed three years ago. When I look at it
positively today, it does remind me that it's one of the reasons for our
decision to separate root CAs for SSL certificates and non-SSL
certificates. As far as I know, browsers and the web PKI community now
encourage or even require the separation of CAs for different usage of
certificate, e.g. time stamping, code signing, S/MIME, and SSL
certificates.  So, if there is a web PKI standard, we are actually glad
to follow.

--Man Ho

[Matt Palmer]

On Mon, Jan 14, 2019 at 05:18:18PM -0700, Wayne Thayer via dev-security-policy wrote:
> * 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.

I think that, at the very least, all incidents against existing roots should
be resolved to Mozilla's satisfaction before any new roots from the same
organisation are considered for inclusion.

- Matt

[Wayne Thayer]

> There were no unresolved incidents, but I just created one to document the
misissued certificates that were revoked in August 2018 [1]. I agree that
this should be resolved prior to approval.

I think you and David are also suggesting that the CPS for existing roots
must be updated to fix the suspension and revocation issues listed under
"bad", and to clarify the external RA concern listed under "meh".

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1520299
[2] https://www.hongkongpost.gov.hk/product/cps/ecert/img/server_cps_en3.pdf

- Matt
>
>

[Man Ho]

Thanks for all the comments. I'm preparing now to apply the relevant
changes from the "Pre-production" CPS in the current CPS to clarify
these concerns. Specifically,

1. correct the description of revocation process to fix the suspension
and revocation issue.

2. make a statement in PREAMBLE that "...HKPost to appoint Registration
Authorities (RAs) as its agents to carry out certain of the functions of
HKPost as a Recognized CA as set out in this CPS, except the functions
of domain name validation."

3. modify section 4.9.1 to include all revocation reasons required by BR
4.9.1.1

Please note that this update to the current CPS will advance the version
of current CPS from version 3 to version 4. So, the "Pre-production" CPS
will be version 5, replacing the current CPS.

If any member has other comments, you're welcome to bring it out.

[Man Ho]

I've just fill in the incident report [1], https://bugzilla.mozilla.org/show_bug.cgi?id=1520299

On 16-Jan-19 5:30 AM, Wayne Thayer via dev-security-policy wrote:

[westm...@gmail.com]

Concern is that the incident report was submitted only when it required the inclusion of the new root certificate in Mozilla Root Store...

[Man Ho]

We have applied the changes in the current CPS, please see https://www.ecert.gov.hk/product/cps/ecert/img/server_cps_en4.pdf

So, the "Pre-production" CPS will be advanced to version 5, that will replace the current CPS after Mozilla community discussion.

If any member has other comments, you're welcome to bring it out. :)

On 17-Jan-19 10:25 AM, Man Ho via dev-security-policy wrote:

Thanks for all the comments. I'm preparing now to apply the relevant
changes from the "Pre-production" CPS in the current CPS to clarify
these concerns. Specifically,

1. correct the description of revocation process to fix the suspension
and revocation issue.

2. make a statement in PREAMBLE that "...HKPost to appoint Registration
Authorities (RAs) as its agents to carry out certain of the functions of
HKPost as a Recognized CA as set out in this CPS, except the functions
of domain name validation."

3. modify section 4.9.1 to include all revocation reasons required by BR
4.9.1.1

Please note that this update to the current CPS will advance the version
of current CPS from version 3 to version 4. So, the "Pre-production" CPS
will be version 5, replacing the current CPS.

If any member has other comments, you're welcome to bring it out.

On 16-Jan-19 5:30 AM, Wayne Thayer via dev-security-policy wrote:

I think you and David are also suggesting that the CPS for existing roots
must be updated to fix the suspension and revocation issues listed under
"bad", and to clarify the external RA concern listed under "meh".

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Wayne Thayer]

I have confirmed that the problems identified with the CPS have been
corrected. [1]

Regarding the comments from Ian on the BR violations in 2016 that resulted
in adding an intermediate to OneCRL [2], this appears to have been the
result of the belief that was held by many CAs at that time that only
certificates "intended" to be used for serverAuth were subject to BR
requirements. That doesn't excuse the very serious threat that was posed by
Hongkong Post's issuance of SHA-1 certificates with sequential serial
numbers that were valid for serverAuth.

Hongkong Post has provided an incident report and answered follow-up
questions in the bug [3] documenting the failure to report misissued
certificates. Hongkong Post states that they are currently performing
post-issuance linting on a monthly basis. They plan to implement
pre-issuance linting as soon as their CA software vendor supports it. The
bug will remain open until that is completed.

I would like to make a decision next week on how to proceed with this
request. Please post any additional comments or concerns by Wednesday
20-February.

- Wayne

[1] https://www.ecert.gov.hk/product/cps/ecert/img/server_cps_en4.pdf
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1267332
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1520299

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Wayne Thayer]

Having received no further comments, I am recommending approval of Hongkong
Post's inclusion request.

As Matt suggested earlier in this thread, I would not typically approve a
request for a CA with an open compliance bug, but in this case the bug is
open awaiting implementation of pre-issuance linting, something that is not
required by our policy. Hongkong Post states that they have implemented
post-issuance linting and expect their CA system vendor to support
pre-issuance linting within a few months.

- Wayne