Re: Request to Include Hongkong Post Root CA 3

[Wayne Thayer via dev-security-policy]

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

On Fri, Feb 15, 2019 at 11:35 AM Wayne Thayer  wrote:

> 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
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Hongkong Post Root CA 3

[Wayne Thayer via dev-security-policy]

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


On Thu, Jan 31, 2019 at 9:47 PM Man Ho via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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-security-policy@lists.mozilla.org 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Hongkong Post Root CA 3

[Man Ho via dev-security-policy]

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

Re: Request to Include Hongkong Post Root CA 3

[westmail24--- via dev-security-policy]

Concern is that the incident report was submitted only when it required the 
inclusion of the new root certificate in Mozilla Root Store...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Hongkong Post Root CA 3

[Man Ho via dev-security-policy]

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:

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Hongkong Post Root CA 3

[Man Ho via dev-security-policy]

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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Hongkong Post Root CA 3

[Wayne Thayer via dev-security-policy]

On Mon, Jan 14, 2019 at 11:43 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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.
>
> 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
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Hongkong Post Root CA 3

[Matt Palmer via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Hongkong Post Root CA 3

[Man Ho via dev-security-policy]

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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Hongkong Post Root CA 3

[Ian Carroll via dev-security-policy]

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

Re: Request to Include Hongkong Post Root CA 3

[mirro860923--- via dev-security-policy]

在 2019年1月15日星期二 UTC+8上午8:58:30，David E. Ross写道：
> On 1/14/2019 4:18 PM, Wayne Thayer 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
> > 
> 
> I would think that lack of a CP alone would disqualify this root.

I think it is ok to combine C

Re: Request to Include Hongkong Post Root CA 3

[Wayne Thayer via dev-security-policy]

On Mon, Jan 14, 2019 at 5:58 PM David E. Ross via dev-security-policy <
dev-security-policy@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Request to Include Hongkong Post Root CA 3

[David E. Ross via dev-security-policy]

On 1/14/2019 4:18 PM, Wayne Thayer 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
> 

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

Request to Include Hongkong Post Root CA 3

[Wayne Thayer via dev-security-policy]

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