WoSign Root Renewal Request

[Kathleen Wilson]

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: webm...@domain.com, hostm...@domain.com,
postm...@domain.com, ad...@domain.com, admini...@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
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

[Kathleen Wilson]

On 6/4/15 10:55 AM, Kathleen Wilson wrote:
> 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.
>

Does anyone have questions, concerns, or feedback on this inclusion
request from WoSign?

Thanks,
Kathleen

[Varga Viktor]

Hi Katleen,
I just checked the published info and it looks okay.
I didn do ocsp or crl access checks.

Regards. Viktor Varga

[Jesus F]

Dear WoSign and Mozilla community,

The CRL downloaded on june 29th from http://crls8.wosign.com/ca8-ssl4.crl (CRL distribution point in https://root5evtest.wosign.com certificate) has a CRL number of "00".
It also applies for the CRL downloaded on the same date from http://crls6.wosign.com/ca6-ssl4.crl (CRL distribution point in https://root4evtest.wosign.com/) which has a CRL number of "00".

According to the Webtrust for CA 2.0 "CAs include a monotonically increasing sequence number for each CRL issued by that CA." (See section 6.8 control 7). Also see section 5.2.3 of the RFC5280 ("The CRL number is a non-critical CRL extension that conveys a monotonically increasing sequence number for a given CRL scope and CRL issuer").

As WoSign has the Webtrust for CA Seal, could WoSign please explain how this control is fullfilled?

Thanks in advance.

Best regards,
J

[Peter Bowen]

On Mon, Jun 29, 2015 at 8:38 AM, Jesus F <jesusfigu...@gmail.com> wrote:
> The CRL downloaded on june 29th from http://crls8.wosign.com/ca8-ssl4.crl (CRL distribution point in https://root5evtest.wosign.com certificate) has a CRL number of "00".
> It also applies for the CRL downloaded on the same date from http://crls6.wosign.com/ca6-ssl4.crl (CRL distribution point in https://root4evtest.wosign.com/) which has a CRL number of "00".
>
> According to the Webtrust for CA 2.0 "CAs include a monotonically increasing sequence number for each CRL issued by that CA." (See section 6.8 control 7). Also see section 5.2.3 of the RFC5280 ("The CRL number is a non-critical CRL extension that conveys a monotonically increasing sequence number for a given CRL scope and CRL issuer").
>
> As WoSign has the Webtrust for CA Seal, could WoSign please explain how this control is fullfilled?

Those are from two different CAs. Under WebTrust definitions, a CA is
not a company, rather it is a signing certificate authority. Many
companies don't just operate one CA, they operate many CAs. This is
what you see from WoSign -- two CAs, each of which has their own
monotonically increasing sequence number.

Thanks,
Peter

[Jesus F]

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

[Martin Rublik]

On 30. 6. 2015 3:00, Richard Wang wrote:
> Very thanks for your question.
> This two root is a new root CA that only issued one test SSL for test site, no certificate is revoked till now, so the CRL number is 0. If we revoked one certificate someday, it will increase to 1, and so on.
> Please check the working root CRL: http://crls1.wosign.com/ca1-server-4.crl, its number is 1E that you can count the revoked certificate is 30.
>
> Best Regards,
>
> Richard

I might be wrong here, but I think this violates RFC 5280. Citing
https://www.ietf.org/rfc/rfc5280.txt section 5.2.3. CRL Number:

If a CRL issuer generates two CRLs (two complete CRLs, two delta
CRLs, or a complete CRL and a delta CRL) for the same scope at
different times, the two CRLs MUST NOT have the same CRL number.
That is, if the this update field (Section 5.1.2.4) in the two CRLs
are not identical, the CRL numbers MUST be different.

Please not that CRL I downloaded today http://crls8.wosign.com/ca8-ssl4.crl has
this update set to june 30th (different from june 29th).

Martin

[Kurt Roeckx]

Hi Richard,

You seem to be saying that the CRL number always matches the amount of
times you've revoked a certificate. This is not the case. Each time
the CRL is updated, even when the list of revoked certificates is the
same, you should update the CRL number. That is, if you generate the
CRL once a day the CRL number should be incremented once a day.


Kurt

On 2015-06-30 09:49, Richard Wang wrote:
> This is two different root CA, issued two different CRL, the two CA don't
> revoke any certificate, so both CRL should be same value to Zero.
>
> Thanks.
>
> Best Regards,
>
> Richard

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

[Eric Mill]

Is there any effort or interest to maintain native translations of the CA/B
Forum's Baseline Requirements, at least in the native languages of
participating CAs?

-- Eric

On Tue, Jun 30, 2015 at 9:11 PM, Richard Wang <ric...@wosign.com> wrote:

> Hi Kurt, Hi Jesus, Hi Martin,
>
> Very thanks for your help.
> I think we misunderstanding the CRL number definition due our engineer bad
> English.
>
> Just confirm with all that the CRL number is the counter of how many CRL
> file
> signed and released, count from 1 once it come out, our nextCRL update
> time is
> 5 day, after the 5 day, the CRL number change to 2, then 3, 4, 5, ... so
> on.
>
> We will update our CRL system within 2 days, thanks a lot.

>
>
> Best Regards,
>
> Richard
>
> -----Original Message-----
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org]
> On
> Behalf Of Kurt Roeckx
> Sent: Tuesday, June 30, 2015 4:06 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: WoSign Root Renewal Request
>

--
konklone.com | @konklone <https://twitter.com/konklone>

[Ryan Sleevi]

This was explored in the past (several Japanese CAs collaborated and
translated the documents), but it ended up working badly when the
translations weren't following the canonical English version, and member
CAs thus weren't adhering to the appropriate standards.

I'll note that the issue being raised here is one not of conformance to
the Baseline Requirements, but of RFC 5280. The BRs are just restating the
technical content of RFC 5280 to try and make sure it's absolutely clear
to participating CAs.

>From RFC 5280, Section 5.2.3

If a CRL issuer generates two CRLs (two complete CRLs, two delta
CRLs, or a complete CRL and a delta CRL) for the same scope at
different times, the two CRLs MUST NOT have the same CRL number.
That is, if the this update field (Section 5.1.2.4) in the two CRLs
are not identical, the CRL numbers MUST be different.

That final sentence should have made clear the technical requirement being
imposed.

[Kathleen Wilson]

On 6/17/15 12:11 PM, Kathleen Wilson wrote:
> On 6/4/15 10:55 AM, Kathleen Wilson wrote:
>> 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.
>>
>

Thanks to all of you who reviewed this request and provided input into
this discussion.

The concern about CRL number that was raised has been resolved.

If there are no further questions or concerns, I will close this
discussion and recommend approval of this request in the bug.

Thanks,
Kathleen

[Kathleen Wilson]

Thanks again to all of you who reviewed and commented on this 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.

I am not aware of any issues that would prevent us from moving forward
with this request. Therefore, I am closing this discussion and will
recommend approval in the bug.

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

Any further follow-up on this request should be added directly to the bug.

Thanks,
Kathleen