The first discussion of this request was here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/DYrrxCsD6CA/9y8a5NnshRgJ
The discussion was closed because one of the root certificates under
consideration had been recently created and not audited. WoSign has
determined that they would like to proceed with the previously created
and audited root certificates as follows.
WoSign has applied to include the “Certification Authority of WoSign”
and “CA 沃通根证书” root certificates, turn on all three trust bits for
both root certs, and enable EV treatment for both root certs. The
“Certification Authority of WoSign” root cert is SHA-1, and the “CA 沃通
根证书” root cert is SHA-256.
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=8361431
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: webmas...@domain.com,
hostmas...@domain.com, postmas...@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: 1.3.6.1.4.1.36305.2
* Root Cert URL
Certification Authority of WoSign: http://www.wosign.com/Root/WS_CA1_NEW.crt
CA 沃通根证书: http://www.wosign.com/Root/ws_ca2_new.crt
* Test Website:
Certification Authority of WoSign: https://root1evtest.wosign.com
CA 沃通根证书: https://root2evtest.wosign.com
* OCSP
Certification Authority of WoSign:
http://ocsp1.wosign.com/ca1
http://ocsp1.wosign.com/class4/server/ca1
http://ocsp1.wosign.com/class3/server/ca1
http://ocsp1.wosign.com/class1/server/ca1
http://ocsp1.wosign.com/class1/client/ca1
http://ocsp1.wosign.com/class2/client/ca1
http://ocsp1.wosign.com/class3/client/ca1
http://ocsp1.wosign.com/class3/code/ca1
CA 沃通根证书:
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
http://ocsp2.wosign.com/class1/client/ca2
http://ocsp2.wosign.com/class2/client/ca2
http://ocsp2.wosign.com/class3/client/ca2
http://ocsp2.wosign.com/class3/code/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=1654&file=pdf
BR Audit Statement: https://bugzilla.mozilla.org/attachment.cgi?id=8399189
EV Audit Report: https://cert.webtrust.org/SealFile?seal=1653&file=pdf
* 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 沃通根证书” 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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
