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.
On Mon, Jan 14, 2019 at 4:19 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
