Dear All, Thanks Peter for your clarification but I think I haven't explained myself properly. My concern is not about that both CRL has the same CRL number (due they are from different hierarchies). My concern is about how the CRL number is treated by WoSign and how this number is increased. As the WoSign renewal request was posted on june 4th, WoSign had published previous CRLs (as per BR has to publish CRL at least every 7 days). If the actual CRL has a CRL number of 0, which CRL number has the previous ones (-1, -2)? and which CRL number will have the next CRL?
I understood that each CRL has to have a monotonically increasing CRL number (for example 1 the first one, 2 the next one and so on). May I be wrong? (I would appreciate an explanation if I am wrong.) Thanks in advance Best Regards, J El jueves, 4 de junio de 2015, 19:56:16 (UTC+2), Kathleen Wilson escribió: > WoSign has applied to include the "Certification Authority of WoSign G2" > and "CA WoSign ECC Root" root certificates, turn on all three trust bits > for both roots, and enable EV treatment for both roots. WoSign's > previous root certificates were included via Bugzilla Bug #851435. > > WoSign issues certificates to the general public in China. Their SSL > certificates are deployed in top 10 eCommerce websites in China; for > bank, telecom, enterprise etc. > > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1156175 > > And in the pending certificates list: > https://wiki.mozilla.org/CA:PendingCAs > > Summary of Information Gathered and Verified: > https://bugzilla.mozilla.org/attachment.cgi?id=8606022 > > Noteworthy points: > > * Documents are provided in Chinese, and the CPS has been translated > into English. > > Document Repository (Chinese): http://www.wosign.com/policy/cps.htm > CPS (English): http://www.wosign.com/policy/cps_e.htm > > * CA Hierarchy for the "Certification Authority of WoSign G2" root: > The plan is to have 10 internally-operated subCAs for 3 types of > certificates: SSL Certificate, Code Signing Certificate and Client > Certificate. > 1. WoSign Class 4/3/2/1 EV/OV/IV/DV SSL CA G2 > 2. WoSign Class 4/3/2 EV/OV/IV Code Signing CA G2 > 3. WoSign Class 3/2/1 Client CA G2 > Currently, one of the subCAs has been issued: WoSign Class 4 EV SSL CA G2 > > * CA Hierarchy for the " CA WoSign ECC Root" root: > The plan is to have 10 internally-operated subCAs for 3 types of > certificates: SSL Certificate, Code Signing Certificate and Client > Certificate. > 1. WoSign Class 4/3/2/1 EV/OV/IV/DV ECC SSL CA > 2. WoSign Class 4/3/2 EV/OV/IV ECC Code Signing CA > 3. WoSign Class 3/2/1 ECC Client CA > Currently, one of the subCAs has been issued: WoSign Class 4 EV ECC SSL CA > > * This request is to turn on all three trust bits for both roots, and to > enable EV treatment for both roots. > > ** CPS section 3.2.2.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. > *** 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: [email protected], [email protected], > [email protected], [email protected], [email protected] > 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 > an administrative email addresses, they may be offered as additional > choices to the above mentioned electronic mail accounts. > If subscriber can't receive email from the above 6 email account, he/she > can choose to do the website control validation that the subscriber must > upload a website control validation code file to the > website root directory to finish the website control validation. > WoSign performs additional sanity and fraud prevention checks as > outlined in section 3.1.6. Wild card domain names like "*.domain.com" > are not issued in the Class 1 level. > WoSign SSL certificate support IDN domain in Chinese and other > languages, so Wosign makes a reasonable check for similar sounding and > looking names to prevent possible abuse which is applied also to non-IDN > names such as PAYPA1.COM, MICR0S0FT.COM etc. and all IDN domain > also need the domain ownership verification by system same as normal > non-IDN domains > > ** CPS section 3.2.2.2 - Class 2 > The verification process of personal identities of subscribers are > performed manually. The WoSign CA validates without any reasonable > doubt that the following details are correct: First and last name; > Residence, Address; State or Region; Country > .... Email control validation is performed as in Class 1. > > ** CPS section 3.2.2.3 - Class 3 > The verification process of organizations implies same level identity > validation of the subscriber (responsible person) and are performed > manually. WoSign validates without any reasonable doubt that the > following details are correct: Registered organization name; Address; > State or Region; Country > .... Domain and email control validation is performed as in Class 1. > Domain control may also be established through verification of the WHOIS > records and matching subscriber information. > > ** CPS section 3.2.2.4 - Class 4 > for EV SSL Certificate and EV Code Signing Certificate for organizations > are performed according to the validation procedures and requirements of > the for EV SSL Certificate Guidelines and EV Code Signing Certificate > Guidelines, as published by the CA/Browser Forum. > > ** 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. > > * EV Policy OID: 1.3.6.1.4.1.36305.2 > > * Root Cert URLs > http://www.wosign.com/root/WS_CA1_G2.crt > http://www.wosign.com/root/ws_ecc.crt > > * Test Websites > https://root4evtest.wosign.com/ > https://root5evtest.wosign.com/ > > * CRL > http://crls6.wosign.com/ca6.crl > http://crls6.wosign.com/ca6-ssl4.crl > http://crls8.wosign.com/ca8.crl > http://crls8.wosign.com/ca8-ssl4.crl > CPS 7.8: CRL Next Update: 5 days > > * OCSP > http://ocsp6.wosign.com/ca6 > http://ocsp6.wosign.com/ca6/ssl4 > http://ocsp8.wosign.com/ca8 > http://ocsp8.wosign.com/ca8/ssl4 > > * Audit: WoSign is audited annually by Ernst&Young (EY) according to the > WebTrust audit criteria. > WebTrust CA: https://cert.webtrust.org/SealFile?seal=1843&file=pdf > WebTrust BR: https://cert.webtrust.org/SealFile?seal=1860&file=pdf > WebTrust EV: https://cert.webtrust.org/SealFile?seal=1842&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 G2" and "CA WoSign ECC Root" root > certificates, turn on all three trust bits for both roots, and enable EV > treatment for both roots. > > 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
