WoSign Root Inclusion Request

[Kathleen Wilson]

WoSign has applied to include the “Certification Authority of WoSign”
and “CA WoSign” root certificates, turn on all three trust bits for both
root certs, and enable EV treatment for both root certs.

WoSign is a privately-owned CA in China which issues certificates to the
general public. WoSign started their CA business in 2006 as a SubCA of
Comodo. WoSign setup its own root CA in 2009 and started to issue
certificates in 2011 under this root CA that cross-signed with a
Startcom CA. WoSign has issued thousands of certificates to customers in
China. WoSign SSL certificates are deployed in top 10 eCommerce websites
in China; for bank, telecom, enterprise etc., and most software
developers in China choose WoSign certificate since it supports Chinese.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=851435

And in the pending certificates list:
http://www.mozilla.org/projects/security/certs/pending/

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

Noteworthy points:

* The primary documents are as follows:
Document Repository: http://www.wosign.com/policy/cps_e.htm
CPS (English): http://www.wosign.com/policy/WoSign-Policy-1_2_2.pdf

* CA Hierarchy: Each root has 7 internally-operated subordinate CAs
according to certificate usages and subscriber verification: EV Server
CA, OV Server CA, DV Server CA, Class 3 Code Signing CA, Class 1 Client
CA, Class 2 Client CA, Class 3 Client CA.

* The request is to turn on all three trust bits, and enable EV treatment.

* CPS section 1.6.2:
Class 1: Email address or domain name ownership/control verified. No
identity checking.
Class 2: Some identity checking.
Class 3: Organization verified, phone call, trusted database checked.
Class 4: EV

* CPS section 3.2.2.3.1 (Class 3): Organization verification

* CPS section 3.2.4: Validation of authority: WoSign confirms and
verifies that the subscriber is duly authorized to represent the
organization and obtain the certificate on their behalf by obtaining an
authorization statement and by contacting the authorizer.

* CPS section 3.2.2.1.2 (Class 1, DV): Fully qualified domain names,
typically www.domain.com or “domain.com” are validated by sending an
electronic mail message with a verification code to one of the following
administrative electronic mail accounts: webm...@domain.com,
hostm...@domain.com, postm...@domain.com
The subscriber has to return and submit the verification code as prove
of ownership of the domain name within a limited period sufficient
enough to receive an electronic mail message. Additionally the existence
of the domain name is verified by checking the WHOIS records provided by
the domain name registrar. If the WHOIS data contain additional email
addresses, they may be offered as additional choices to the above
mentioned electronic mail accounts.

* CPS section 3.2.2.3.1 (Class 3, OV): Domain and email control
validation is performed as in Class 1. Domain control may be also
established through verification of the WHOIS records and matching
subscriber information.

* CPS section 3.2.2.4 (Class 4, EV): Extended Validation for
organizations are preformed according to the validation procedures and
requirements of the Extended Validation Guidelines as published by the
CA/Browser Forum. Applicants for EV must be at least Class 2 Identity
validated prior to engagement for Extended validation.

* CPS section 3.2.2.1.1 (Class 1): Email accounts are validated by
sending an electronic mail message with a verification code to the
requested email account. The subscriber has to return and submit the
verification code as prove of ownership of the email account within a
limited period sufficient enough to receive an electronic mail message.

* CPS section 3.2.2.2.1 (Class 2): Email control validation is performed
as in Class 1.

* EV Policy OID
Certification Authority of WoSign: 1.3.6.1.4.1.36305.2
CA WoSign: 1.3.6.1.4.1.36305.6

* Root Cert URL
Certification Authority of WoSign: http://www.wosign.com/Root/WS_CA1_NEW.crt
CA WoSign: http://www.wosign.com/Root/ws_ca2_new.crt

* Test Website:
Certification Authority of WoSign: https://root1evtest.wosign.com
CA WoSign: https://root2evtest.wosign.com

* CRL
Certification Authority of WoSign:
http://ocsp1.wosign.com/ca1
http://ocsp1.wosign.com/class4/server/ca1
http://ocsp.wosign.com/class3/server/ca
http://ocsp.wosign.com/class1/server/ca
CA WoSign:
http://crls1.wosign.com/ca2.crl
http://crls1.wosign.com/ca2-server-4.crl
http://crls.wosign.com/ca2-server-3.crl
http://crls.wosign.com/ca2-server-1.crl
CPS section 7.8: CRL Next Update: 48 hours

* OCSP
Certification Authority of WoSign:
http://ocsp1.wosign.com/ca1
http://ocsp1.wosign.com/class4/server/ca1
http://ocsp.wosign.com/class3/server/ca
http://ocsp.wosign.com/class1/server/ca
CA WoSign:
http://ocsp2.wosign.com/ca2
http://ocsp2.wosign.com/class4/server/ca2
http://ocsp2.wosign.com/class3/server/ca2
http://ocsp2.wosign.com/class1/server/ca2
CPS section 4.9.9, OCSP: The current CRLs are reloaded at least every 60
minutes.

* Audit: Annual audits are performed by Ernst & Young according to the
WebTrust criteria.
Audit Report: https://cert.webtrust.org/SealFile?seal=1443&file=pdf
EV Readiness Audit Report:
https://bugzilla.mozilla.org/attachment.cgi?id=725294

* Potentially Problematic Practices – none noted
(http://wiki.mozilla.org/CA:Problematic_Practices)

This begins the discussion of the request from WoSign to include the
“Certification Authority of WoSign” and “CA WoSign” root certificates,
turn on all three trust bits for both root certs, and enable EV
treatment for both root certs. At the conclusion of this discussion I
will provide a summary of issues noted and action items. If there are
outstanding issues, then an additional discussion may be needed as
follow-up. If there are no outstanding issues, then I will recommend
approval of this request in the bug.

Kathleen

[Erwann Abalea]

Le vendredi 1 novembre 2013 23:58:59 UTC+1, Kathleen Wilson a écrit :
> WoSign has applied to include the “Certification Authority of WoSign”
> and “CA WoSign” root certificates, turn on all three trust bits for both
> root certs, and enable EV treatment for both root certs.

[...]

> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=851435

[...]

> * The primary documents are as follows:
> Document Repository: http://www.wosign.com/policy/cps_e.htm
> CPS (English): http://www.wosign.com/policy/WoSign-Policy-1_2_2.pdf

[...]

> * The request is to turn on all three trust bits, and enable EV treatment.

[...]

> * EV Policy OID
> Certification Authority of WoSign: 1.3.6.1.4.1.36305.2
> CA WoSign: 1.3.6.1.4.1.36305.6

Why are there 2 different OIDs for EV, under the same arc belonging to the same company?
Your policy only defines the .2 one.

> * Root Cert URL
> Certification Authority of WoSign: http://www.wosign.com/Root/WS_CA1_NEW.crt
> CA WoSign: http://www.wosign.com/Root/ws_ca2_new.crt

All the tested certificates have the countryName element encoded as UTF8, which is invalid (only PrintableString is allowed, see X.520/6.3.1). This mistake is repeated from the roots down to the subscriber certificates, and extends to OCSP responder certificates.

> * Test Website:
> Certification Authority of WoSign: https://root1evtest.wosign.com
> CA WoSign: https://root2evtest.wosign.com

The jurisdictionOfIncorporationCountryName is also declared as an UTF8String, it MUST be a PrintableString.

Non blocking: do you think it is really necessary to add Microsoft and Netscape SGC OIDs in the EKU? It's useless unless your customers have very old software versions *and* you alter their trust settings to grant this use to your root.

> * CRL
> Certification Authority of WoSign:
> http://ocsp1.wosign.com/ca1
> http://ocsp1.wosign.com/class4/server/ca1
> http://ocsp.wosign.com/class3/server/ca
> http://ocsp.wosign.com/class1/server/ca

I guess this was a mistake in cut/paste operation, the right URLs seem to be
http://crls1.wosign.com/ca1.crl
http://crls1.wosign.com/ca1-server-4.crl
http://crls.wosign.com/server-3.crl
http://crls.wosign.com/server-1.crl
Those 4 URLs (and the 4 ones declared below under the second root CA) return a CRL with a MIME type "text/plain". This must be "application/pkix-crl".

The AIA:CAIssuers URLs return objects with a MIME type equal to "text/plain" instead of "application/pkix-cert" or "application/pkcs7-mime" (depending on the real object).

> CA WoSign:
> http://crls1.wosign.com/ca2.crl
> http://crls1.wosign.com/ca2-server-4.crl
> http://crls.wosign.com/ca2-server-3.crl
> http://crls.wosign.com/ca2-server-1.crl
> CPS section 7.8: CRL Next Update: 48 hours
>
> * OCSP
> Certification Authority of WoSign:
> http://ocsp1.wosign.com/ca1
> http://ocsp1.wosign.com/class4/server/ca1
> http://ocsp.wosign.com/class3/server/ca
> http://ocsp.wosign.com/class1/server/ca
> CA WoSign:
> http://ocsp2.wosign.com/ca2
> http://ocsp2.wosign.com/class4/server/ca2
> http://ocsp2.wosign.com/class3/server/ca2
> http://ocsp2.wosign.com/class1/server/ca2

OCSP responders don't have the OcspNoCheck extension, but include this OID in the EKU extension. This isn't BR compliant.
Non blocking: the OCSP service doesn't react well with non URL-encoded GET requests (seems to close the socket with no answer).

> CPS section 4.9.9, OCSP: The current CRLs are reloaded at least every 60
> minutes.

Does that mean that OCSP responders don't perform a database lookup and don't comply with BR 13.2.6 rule on non-issued certificates?

> * Audit: Annual audits are performed by Ernst & Young according to the
> WebTrust criteria.
> Audit Report: https://cert.webtrust.org/SealFile?seal=1443&file=pdf

This audit doesn't cover the second root CA, despite the fact that is was conducted in January 2013 and the second root CA seems to exist since 2009.

> EV Readiness Audit Report:
> https://bugzilla.mozilla.org/attachment.cgi?id=725294

This audit doesn't limit to the first root CA, has been performed by the same auditor at the same moment.

[wos...@gmail.com]

Very thanks to Mr Erwann Abalea’s comments.
I am very sorry that we don’t update the related document in Mozilla bugzilla in time. My company changed the company name from “WoSign eCommerce Services Limited” to “WoSign CA Limited” at Sept 10th, so we resigned CA1 and CA2 at Sep.14th and setup the test website at Sept. 16th that have the reported problem.
But our auditor advised us that they should be onsite as a witness for root resigning. So we resigned two roots at Oct. 22 and reissued the EV test cert. But many internal reason, we don’t update the new resigned root CA and test cert to test site.
Now, we upload the new resigned two root CA cert file and the key resigning ceremony document signed by Ernst & Young Auditor as witness. And update the test site certificates.
CA1: https://bugzilla.mozilla.org/attachment.cgi?id=831452
CA2: https://bugzilla.mozilla.org/attachment.cgi?id=831454
Witness document: https://bugzilla.mozilla.org/attachment.cgi?id=831456

For summary to response Mr Erwann Abalea’s comments as following:
1. For EV Policy OID, we decided to use one EV OID for all roots: 1.3.6.1.4.1.36305.2;
2. For countryName element encoded as UTF8, we solved that all are PrintableString now;
3. For SGC EKU, we removed;
4. For CRL/AIA MIME type, we corrected;
5. For OCSP responders certificate don't have the OcspNoCheck extension: we added;
6. For WebTrust audit cover, we will change to apply the another covered root CA “CA 沃通根证书” for inclusion instead of root CA2 -“CA WoSign”. So we appointed Ernst & Young auditor to be onsite as a witness to resign this root CA to change subject organization name at this week Thursday. After resigning, we will setup the test site.
7. For CRL/AIA/OCSP URL: we will correct all in the update Bugzilla Summary after resign the CA3 -- “CA 沃通根证书”.
8. We still need some time to solve other left problems, thanks for your patient.

[Kathleen Wilson]

Given the changes at WoSign and the updated roots, I am closing this
discussion now with the action items listed above, and another action
item to get a full new audit covering the root certs WoSign now wishes
to include in NSS.

Tracking of these action items will be done in the bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=851435

I will start a second round of discussion after these have been completed.

Thanks,
Kathleen