Request to Include SHECA UCA Global G2 Root and UCA Extended Validation Root

[Wayne Thayer]

This request is for inclusion of the Shanghai Electronic Certification
Authority Co., Ltd.
UCA Global G2 Root and UCA Extended Validation Root as documented in the
following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1309797

* BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8872017

* Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8963421

* Root Certificate Download URL:
Global G2 Root:http://www.sheca.com/download/getdownloadforpdf/126
Extended Validation Root: http://www.sheca.com/download/getdownloadforpdf/73

* CP/CPS:
CP:
https://assets-cdn.sheca.com/documents/unitrust-certificate-policy-en-v1.4.pdf
CPS:
https://assets-cdn.sheca.com/documents/sheca-certification-practice-statement-en-v3.6.2.pdf
EV CP:
https://assets-cdn.sheca.com/documents/unitrust-ev-certificate-policy-en-v1.5.pdf
EV CPS:
https://assets-cdn.sheca.com/documents/unitrust-ev-certification-practice-statement-en-v1.4.2.pdf

* This request is to include both roots with websites and email trust bits
enabled for the Global G2 Root, and the websites trust bit and EV treatment
for the Extended Validation Root.

* EV Policy OID: 2.23.140.1.1

* Test Websites
** Global G2 Root:
https://rsaovg3.good.sheca.com/
https://rsaovg3.revoked.sheca.com/
https://rsaovg3.expired.sheca.com/
** Extended Validation Root:
https://rsaevg1.good.sheca.com/
https://rsaevg1.revoked.sheca.com/
https://rsaevg1.expired.sheca.com/

* CRL URLs:
** Global G2 Root:
http://ldap2.sheca.com/root/ucaglobalg2.crl
http://ldap2.sheca.com/CA10011/RA12050100/CRL23844.crl
** Extended Validation Root:
http://ldap2.sheca.com/root/ucaevsub.crl
http://ldap2.sheca.com/CA81/RA12050100/CRL28438.crl

* OCSP URLs:
** Global G2 Root:
http://ocsp3.sheca.com/ucaglobalg2root/ucaglobalg2root.ocsp
http://ocsp3.sheca.com/ocsp/sheca/sheca.ocsp
** Extended Validation Root:
http://ocsp3.sheca.com/evroot/ev.ocsp
http://ocsp3.sheca.com/ocsp/sheca/sheca.ocsp

* Audit: Annual audits are performed by PricewaterhouseCoopers Zhong Tian
according to the WebTrust for CA, BR, and EV audit criteria.
WebTrust: https://cert.webtrust.org/ViewSeal?id=2470
BR: https://cert.webtrust.org/ViewSeal?id=2471
EV: https://cert.webtrust.org/ViewSeal?id=2472

I’ve reviewed the CPs, CPSs, BR Self Assessment, and related information
for inclusion of the two SHECA roots that is being tracked in this bug and
have the following comments:

==Good==
* SHECA plans to issue code signing and TLS certificates from separate
intermediate certificates.
* While the non-EV CP permits external RAs, it expressly prohibits using
them to issue SSL certificates.

==Meh==
* Issuance of SHA-1 certs after the CA/Browser Forum deadline [1][2] This
issuance was under an older root that is not part of the current request.
* Non-EV CPS section 7.1.2 states that serial numbers are random but does
not specify the entropy requirement in BR section 7.1. The EV CP and CPS do
not contain any information about serial numbers.
* On 8-August, both root CRLs showed a “Next update” of 29-June 2018 when
tested from revocationcheck.com [3], meaning they were expired. Neither
SHECA or I were able to reproduce this problem at a later date.
* For reference, an older root inclusion request that SHECA ultimately
decided to replace with the current request is at
https://bugzilla.mozilla.org/show_bug.cgi?id=566310

==Bad==
* A few unrevoked certificates with IP Addresses encoded as DNSName type in
the SAN [4]. I reported these to SHECA in this bug and they said that they
would revoke them, but as of this writing they are still valid.
* Common name not in SAN and multiple CN entries in one unrevoked cert [5].
I reported these to SHECA in this bug and they filed an incident report and
revoked them.
* The SHECA Global G3 Code Signing subordinate [6] and the SHECA Extended
Validation Code Signing CA [7] are not constrained to code signing and are
not named on the most recent BR audit. I reported these to SHECA in this
bug and they chose to revoke them.
* Improper encoding of 17 EV certificates [8][9]. I reported these to SHECA
in this bug and they filed an incident report and revoked them.
* Section 4.2 of all policy docs was missing the recognized CAA domain
names. The EV CP and/or CPS did not state SHECA’s CAA processing policies.
I reported these to SHECA in this bug and they updated both CPS documents.
* Global G2 Root CPS section 3.2.5 did not document the BR methods used to
perform domain validation as recommended by Mozilla policy section 2.2(3),
nor did it “clearly specify” the procedures used. I reported this to SHECA
in the bug and they updated both CPS documents.
* Version 1.3 of the Global G2 Root CP and version 3.6 of the Global G2
Root CPS were published more than a year after the prior versions in
violation of Mozilla policy section 3.3.
* Non-EV CP section 3.2.4 seemed to state that an email address included in
a certificate will not be verified. SHECA responded that they do verify
email addresses in SSL certificates, and they clarified this section of the
CP.
* Section 4.6 of the non-EV CP/CPS seemed to permit certificate renewal
without revalidation, even when the information is more than 825 days old.
SHECA updated the CPS to clarify that SSL renewal is treated as a new
application.
* EV CP/CPS section 4.9.1.1 did not include all BR required revocations
reasons, such as (6). SHECA has fixed this in the latest version of the EV
CPS.
* The CP/CPS documents contain version histories, but they didn’t describe
what changed in each version. SHECA began including this information in the
latest versions of these documents.
* The non-EV CP and CPS section 6.1 seem to permit CA generation of key
pairs for SSL certificates in violation of section 5.2 of Mozilla policy.
SHECA states that they have never generated key pairs for Subscribers and
revised this section of the CPS, but my interpretation is that the revision
does not forbid SHECA from generating subscriber key pairs.

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

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

- Wayne

[1] https://crt.sh/?cablint=211&iCAID=505&minNotBefore=2016-01-01
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/771PAebFAQAJ
[3] https://certificate.revocationcheck.com/rsaovg3.expired.sheca.com
[4]
https://crt.sh/?CAID=40266&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[5] https://crt.sh/?id=329498950&opt=cablint
[6] https://crt.sh/?id=154596200
[7] https://crt.sh/?id=154596198
[8]
https://crt.sh/?caid=40251&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[9]
https://crt.sh/?caid=83252&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[10] https://wiki.mozilla.org/CA/Application_Process

[David E. Ross]

On 8/31/2018 4:19 PM, Wayne Thayer wrote [in part]:
> * A few unrevoked certificates with IP Addresses encoded as DNSName type in
> the SAN [4]. I reported these to SHECA in this bug and they said that they
> would revoke them, but as of this writing they are still valid.

This public comment period should be extended until the affected
certificates are indeed revoked.

> * Version 1.3 of the Global G2 Root CP and version 3.6 of the Global G2
> Root CPS were published more than a year after the prior versions in
> violation of Mozilla policy section 3.3.

How do we know this will not happen again?

> * The CP/CPS documents contain version histories, but they didn’t describe
> what changed in each version. SHECA began including this information in the
> latest versions of these documents.

Have the version histories been fixed to include all prior changes? How
do we know this will not happen again?

> * The non-EV CP and CPS section 6.1 seem to permit CA generation of key
> pairs for SSL certificates in violation of section 5.2 of Mozilla policy.
> SHECA states that they have never generated key pairs for Subscribers and
> revised this section of the CPS, but my interpretation is that the revision
> does not forbid SHECA from generating subscriber key pairs.

This public comment period should be extended until the affected
documents make this clear enough to support an audit that verifies key
pairs are not be generated. No, I am not suggesting that such an audit
is required at this time. I am merely saying that the documents must
provide clear, objective statements against which an auditor can
determine if the Mozilla policy is being followed.

--
David E. Ross
<http://www.rossde.com>

Too often, Twitter is a source of verbal vomit. Examples include Donald
Trump, Roseanne Barr, and Elon Musk.

[chenxi...@sheca.com]

在 2018年9月1日星期六 UTC+8上午10:24:35，David E. Ross写道：

> On 8/31/2018 4:19 PM, Wayne Thayer wrote [in part]:
> > * A few unrevoked certificates with IP Addresses encoded as DNSName type in
> > the SAN [4]. I reported these to SHECA in this bug and they said that they
> > would revoke them, but as of this writing they are still valid.
>
> This public comment period should be extended until the affected
> certificates are indeed revoked.

SHECA has evaluated the affect and security risk, we conducted an Delayed Revocation Report. I will update the report and communication evidence on Monday(don't have them on my hand now).

basically, the subscriber of these certificates is a financial institution, their coding and system update workflow is very strict and complicated. We have informed them repeatedly that the certificates have security risk, and need to be revoked and replaced by updated ones according to CABF requirement. They claim that revocation can only be done during system update or there will be important affect to their service operation.

As of this comment, the subscriber still has not taken any action to upgrade their system. SHECA is planning to send a final notification letter next week, if they don't have update plan in one week, we will directly take revocation action.

>
> > * Version 1.3 of the Global G2 Root CP and version 3.6 of the Global G2
> > Root CPS were published more than a year after the prior versions in
> > violation of Mozilla policy section 3.3.
>
> How do we know this will not happen again?

While we do maintain CP/CPS update at least once annually but this time we ignorant the 365 days gap limitation between each version.
To avoid this issue happen again, we are now adding this limitation into SHECA CP/CPS periodical review checklist. SHECA will publish CP/CPS Review Report in the repository (https://www.sheca.com/repository) of SHECA’s official website semi-annually.

>
> > * The CP/CPS documents contain version histories, but they didn’t describe
> > what changed in each version. SHECA began including this information in the
> > latest versions of these documents.
>
> Have the version histories been fixed to include all prior changes? How
> do we know this will not happen again?

We only include changes description of the latest version now. While we will add the prior changes description in next week.
In addition, SHECA keep the historical versions CP/CPS accessible on our official website.
All the previous version can be got in Previous Documents part in this link: https://www.sheca.com/repository

>
>
> > * The non-EV CP and CPS section 6.1 seem to permit CA generation of key
> > pairs for SSL certificates in violation of section 5.2 of Mozilla policy.
> > SHECA states that they have never generated key pairs for Subscribers and
> > revised this section of the CPS, but my interpretation is that the revision
> > does not forbid SHECA from generating subscriber key pairs.
>
> This public comment period should be extended until the affected
> documents make this clear enough to support an audit that verifies key
> pairs are not be generated. No, I am not suggesting that such an audit
> is required at this time. I am merely saying that the documents must
> provide clear, objective statements against which an auditor can
> determine if the Mozilla policy is being followed.
>

We definitely mean that SHECA don’t generate key pairs for subscribers by stating “Generation of subscriber signing key pair should be performed by subscribers” in section 6.1.1 of latest version. So as for the interpretation problem mentioned by Wayne, We can revise our CPS, emphasizing “For certificates issued by UCA Global G2 Root and UCA Extended Validation Root, SHECA must not generate key pair for subscribers.”
Also we will clearly, objectively state in CP/CPS that the WebTrust auditor can determine that CA didn’t generate key pair of SSL certificate during every Audit Period (for SHECA, is May, last year to April，next Year), according to the CABF requirement.


Regards,
Toria Chen
----------------
Chen Xiaotong Dept. of Strategic Development
Shanghai Electronic Certificate Authority Center Co.,Ltd.

[chenxi...@sheca.com]

Below is the full text of Revocation Delay Report, according to the Mozilla Policy[1].
____________________________________________________________________________
Revocation Delay Report
Process
- Informed of the problematic certificate
During the CP/CPS review period, Wayne informed SHECA about the problematic certificates.

-Informing subscriber
SHECA checked out the subscriber, informed them immediately.
These two certificates belong to a same financial service institution, which has very strict risk control requirement. These two certificates are used in their website of main business.

-Communication
Subscriber agree to replace these two certificate, but strongly urge the revocation can only be done during the system update window in holiday. Since revocation and replacement of these two certificates cause affect to their service operation.
We understand their concern and try our best to minimize the effect to subscriber. So we start to evaluate the risk and forming a delay revocation plan.

-Evaluation
SHECA performed a research of the reason, and conducted an incident report.
The issue of these two certificates is IP Addresses encoded as DNS Name type in the SAN, this is a manual mi-soperation. The risk is much lower than risk of weak key, private key compromise etc. But this issue still not compliant with requirement of CABF and may cause risk to the security level of the certificate.
We informed subscriber of the Risk Evaluation result, but subscriber insist the priority level is not high enough, and won’t stop the system operation only for revoking the problematic certificates.

-Plan
SHECA should notify subscriber of the risk repeatedly every week and ask for agree of revocation.
Concerning the risk of relying parties and operation risk of SHECA, SHECA plan to send final notification in early September and revoke in one week after sending the notification.
_________________________________________________________________________

SHECA performed all these process since informed of the issue, we try very hard to convince the subscriber to co-operate without effect their business.
We sent the final notification today and received reply this afternoon.
The subscriber finally agree to revoke the certificate this week, we will update the status once it’s revoked.

[1] https://wiki.mozilla.org/CA/Responding_To_An_Incident

[chenxi...@sheca.com]

在 2018年9月1日星期六 UTC+8上午7:19:49，Wayne Thayer写道：

> ==Bad==
> * A few unrevoked certificates with IP Addresses encoded as DNSName type in
> the SAN [4]. I reported these to SHECA in this bug and they said that they
> would revoke them, but as of this writing they are still valid.

SHECA revoked both prolematic certificates, pls kindly check.

[Wayne Thayer]

On Sun, Sep 9, 2018 at 7:31 PM chenxiaotong--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> 在 2018年9月1日星期六 UTC+8上午7:19:49，Wayne Thayer写道：
>

> > ==Bad==
> > * A few unrevoked certificates with IP Addresses encoded as DNSName type
> in
> > the SAN [4]. I reported these to SHECA in this bug and they said that
> they
> > would revoke them, but as of this writing they are still valid.
>

> SHECA revoked both prolematic certificates, pls kindly check.
>

> Thank you. I confirmed that these two certificates have been revoked.

[chenxi...@sheca.com]

在 2018年9月1日星期六 UTC+8上午7:19:49，Wayne Thayer写道：

> * The CP/CPS documents contain version histories, but they didn’t describe
> what changed in each version. SHECA began including this information in the
> latest versions of these documents.
> * The non-EV CP and CPS section 6.1 seem to permit CA generation of key
> pairs for SSL certificates in violation of section 5.2 of Mozilla policy.
> SHECA states that they have never generated key pairs for Subscribers and
> revised this section of the CPS, but my interpretation is that the revision
> does not forbid SHECA from generating subscriber key pairs.

Hello,

SHECA just published the new CP/CPS, which added the changes description of all historical veresions, as well as stated that for certificates issued by UCA Global G2 Root and UCA Extended Validation Root, SHECA must not generate key pair for subscribers.
Please refer to links below for details:
Non-EV CP https://assets-cdn.sheca.com/documents/unitrust-certificate-policy-en-v1.4.1.pdf
Non-EV CPS https://assets-cdn.sheca.com/documents/sheca-certification-practice-statement-en-v3.6.3.pdf
EV-CP https://assets-cdn.sheca.com/documents/unitrust-ev-certificate-policy-en-v1.6.pdf
EV-CPS https://assets-cdn.sheca.com/documents/unitrust-ev-certification-practice-statement-en-v1.4.3.pdf

Thanks.
Toria Chen

[Wayne Thayer]

Thank you Toria.

On Tue, Sep 11, 2018 at 7:32 AM chenxiaotong--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> 在 2018年9月1日星期六 UTC+8上午7:19:49，Wayne Thayer写道：
>
>

> > * The CP/CPS documents contain version histories, but they didn’t
> describe
> > what changed in each version. SHECA began including this information in
> the
> > latest versions of these documents.
>
>

I confirmed that the current CP/CPS documents now contain full version
histories.

>

> > * The non-EV CP and CPS section 6.1 seem to permit CA generation of key
> > pairs for SSL certificates in violation of section 5.2 of Mozilla policy.
> > SHECA states that they have never generated key pairs for Subscribers and
> > revised this section of the CPS, but my interpretation is that the
> revision
> > does not forbid SHECA from generating subscriber key pairs.
>
> >

I am satisfied by the following statement that was added: "For certificates

[westm...@gmail.com]

Quote:

* Root Certificate Download URL:

Extended Validation Root: http://www.sheca.com/download/getdownloadforpdf/73

Hello,
At this URL - 404 Not found.

Sincerely,
Andrew.

[chenxi...@sheca.com]

在 2018年9月13日星期四 UTC+8上午9:16:13，westm...@gmail.com写道：

Hi Andrew， pls download here:
http://www.sheca.com/download/getdownloadforpdf/191;
or
https://www.sheca.com/repository/certs/uca-extended-validation-root.cer.

We updated the address in the request bug one year ago.

[Wayne Thayer]

I believe that SHECA has addressed all the concerns raised during the
discussion period. I am now closing the discussion with a recommendation to
approve this inclusion request. Any further comments should be added
directly to the bug [1].

I would like to thank everyone who contributed to this discussion.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1309797

On Wed, Sep 12, 2018 at 6:43 PM chenxiaotong--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> 在 2018年9月13日星期四 UTC+8上午9:16:13，westm...@gmail.com写道：

> Hi Andrew， pls download here:
> http://www.sheca.com/download/getdownloadforpdf/191;
> or
> https://www.sheca.com/repository/certs/uca-extended-validation-root.cer.
>
> We updated the address in the request bug one year ago.

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