Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

SHECA Root Inclusion Request

154 views
Skip to first unread message

Kathleen Wilson

unread,
Aug 2, 2011, 7:14:17 PM8/2/11
to mozilla-dev-s...@lists.mozilla.org
SHECA has applied to add the �UCA Root� and �UCA Global Root� root
certificates. For the �UCA Root� the request is to enable all three
trust bits. For the �UCA Global Root� the request is to enable the
websites and code signing trust bits.

Shanghai Electronic Certification Authority Co., Ltd. (SHECA) is a
Shanghai-based commercial company and is one of the biggest
Certification Authorities in China. SHECA is a national recognized CA
and operates under China�s Electronic Signature Law. SHECA�s customers
include individuals and companies from mainland China, Taiwan and Hong
Kong. Four of SHECA�s major shareholders are government established
investment vehicles and government-owned enterprises.

Mozilla Comment: Being affiliated with a government is not a reason that
Mozilla would reject a CA (there are several others already in the root
store for Japan, Taiwan, and others). We have not found evidence of
SHECA being compelled by another entity to issue an illegitimate
certificate (e.g. for a domain that it shouldn�t).

In past discussions regarding Chinese CAs, concerns have been raised
about whether discussions in the mozilla.dev.security.policy forum are
accessible to participants in China. Based on recent testing we believe
that this forum is currently accessible to people in China. Testing
found that Google Groups is blocked when https is used. However, the
mozilla.dev.security.policy forum is in plain http, so it is accessible
to participants in China. Anyone with information to the contrary should
contact us immediately.

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

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

Information Gathering Document:
https://bugzilla.mozilla.org/attachment.cgi?id=541405

Noteworthy points:

* Cert Download URL
** UCA Root: http://ldap2.sheca.com/root/ucaroot.der
** UCA Global Root: http://ldap2.sheca.com/root/ucaglobalroot.der

* UCA is the acronym of UniTrust Certification Authority. UniTrust is a
registered trademark owned by SHECA.

* The CP/CPS documents are provided in Chinese, and English translations
of certain sections are provided in the Information Gathering Document.

Certificate Policy Documents: http://www.sheca.com/policy/

CP (copy-enabled): https://bugzilla.mozilla.org/attachment.cgi?id=447948

CPS (copy-enabled):
https://bugzilla.mozilla.org/attachment.cgi?id=447947

* UCA Root has one internally-operated intermediate CA which signs
end-entity certificates for web servers, e-mail, and personal ID. UCA
Global Root has one internally-operated intermediate CA which signs web
server certificates. The intermediate CAs sign end-entity certificates
to the general public, government, enterprise, organizations,
institutes, and individuals.

* For the �UCA Root� the request is to enable all three trust bits. For
the �UCA Global Root� the request is to enable the websites and code
signing trust bits. EV-treatment is not requested at this time.

** SHECA Comment: When applying a certificate for business organization,
the applicant should appoint and authorize some represent, once he/she
signs that means he/she accepts relevant terms, and also takes the
responsibility. SHECA would checkup all the materials applied, the
applicant should submit the evidence to prove that the organization or
server exists actually, and there into, Industry and commerce business
license and Organizations and agencies code card issued by government
are necessary; The applicant has the obligation to ensure the material
is real and needs to take relevant responsibility. If necessary, SHECA
may get phone number and other ways of contact through the third-part,
to confirm some information by contacting the organization (for example,
to validate the position of deputy or whether someone on the table is
the applicant). If SHECA have confirmed the identity of the
organization, SHECA would trust the proof submitted by the applicant.
This kind of authentication of identity is by face to face generally.

** Translation from pages 46 and 47 of CPS
Applicants for organization certificate are required to submit the
following material:
*** a written application form filled out and signed by applicant
*** Certificate of Organization Code of the applicant (original and copy)
*** Business license of the applicant (original and copy). If there is
no business license, the applicant could submit some other optional
valid documents (original and copy) in application form. Present valid
documents recognized as follows: Business license, Corporate
registration certificate and institutions, Tax registration certificate,
organization code certificate, social groups, and other national
registration valid proof of legal recognition.
If SHECA or receiving point has confirmed specific identity of the
applicant by phone, mail, third-party verification or other means, the
applicant could submit copies of documents by fax and mail instead of
original.
*** identity card or military officer, student cards, passport and other
valid documents (original and copy) of applicant's trustee.
*** Written power of attorney to trustee (with official seal). When
submitting the application form, the applicant stamp the official seal
after the trustee signed the application form, it means a written
delegation of authority entrusted to the trustee.

** SHECA Comment: The original business license document issued by the
government agency is made of paper with specific texture and chopped by
a specific stamp. Our staff, who normally check a hundred of business
license documents each month, can easily identify fake evidence
documents. If our staff has any doubt, he/she will consult with his/her
supervisor and take necessary procedures (e.g., checking with the public
database).

** Translation from pages 49 and 50 of CPS
Applicants for domain name certificate are required to submit the
following material:
Applicants for organization certificate are required to submit the
following material:
*** A written application form filled out and signed (or sealed) by
applicant
*** identification materials (original and copy) of the applicant
(individual or organization)
*** Applicant must submit a written commitment documents of the domain
name (or Internet IP address), including the ownership information of
domain and the use assurances as to show that the domain name (or IP
address) belongs to the applicant and the certificate will be used
legally. SHECA will take appropriate manner of examine to the
applicant's ownership of the domain name, including obtaining
registration information from domain name registration authority and
visiting the domain name (or Internet IP address) so on.
*** If it is entrusted to handle, the applicant and the trustee need to
submit identification materials and copies, and written authorization
autographed by applicant.

SHECA Comment: Reference to the provisions of CPS 4.1.1.2, we usually
verify follow the following steps: Firstly, applicants fill out the
application form, and bring relevant original and copies evidence of
identity of the domain controller (usually organizational) to SHECA;
secondly, SHECA check the identity of the applicant face to face;
thirdly, SHECA compare the original and copies to confirm the
authenticity; fourthly, through inquiring the domain name registration
agency, SHECA verify the identity of domain name�s holder and compare
with the information in Application materials; Fifthly, if the material
has no problem, SHECA will issue certificates for subscriber and keep a
copy of materials of organization�s identity.

** Translation from pages 46 and 47 of CPS
(a) Individual email certificate
Applicants for individual email certificate are required to submit the
following material:
*** SHECA send email to the email address submitted by applicant to
confirm whether it is controlled by the applicant, and decide whether
sign the certificate. But this does not mean SHECA can guarantee that
the applicant does have the E-mail legally. SHECA have no obligation to
confirm whether the email belongs the the applicant or not, only to
guarantee the information of the applicant only for the email
application for certificate, and such information has correspondence
with certificate information of the E-mail. If it is disputed for email
ownership, SHECA do not and should not be resolved, SHECA would provide
the help in accordance with the requirements of the relevant
departments, but this is not an obligation of commitment.
*** a written application form filled out and signed by applicants (in
triplicate)
*** personal ID (or military officer, student ID, passport, etc.) original
*** personal ID (or military officer, student ID, passport, etc.) copy
*** If it is entrusted to handle, SHECA require the applicant and the
trustee to submit above-mentioned documents and copies, and written
authorization autographed by applicant.

(b) Organization email certificate
Applicants for organization email certificate are required to submit the
following material:
*** SHECA send email to the email address submitted by applicant to
confirm whether it is controlled by the applicant, and decide whether
sign the certificate. But this does not mean SHECA can guarantee that
the applicant does have the E-mail legally. SHECA have no obligation to
confirm whether the email belongs the the applicant or not, only to
guarantee the information of the applicant only for the email
application for certificate, and such information has correspondence
with certificate information of the E-mail. If it is disputed for email
ownership, SHECA do not and should not be resolved, SHECA would provide
the help in accordance with the requirements of the relevant
departments, but this is not an obligation of commitment.
*** Certificate of Organization Code of the applicant (original and copy)
*** Business license of the applicant (original and copy). If there is
no business license, the applicant could submit some other optional
valid documents (original and copy) in application form. Present valid
documents recognized as follows: Business license, Corporate
registration certificate and institutions, Tax registration certificate,
organization code certificate, social groups, and other national
registration valid proof of legal recognition. If SHECA or receiving
point has confirmed specific identity of the applicant by phone, mail,
third-party verification or other means, the applicant could submit
copies of documents by fax and mail instead of original.
*** identity card or military officer, student cards, passport and other
valid documents (original and copy) of applicant's trustee.
*** Written power of attorney to trustee (with official seal). When
submitting the application form, the applicant stamp the official seal
after the trustee signed the application form, it means a written
delegation of authority entrusted to the trustee.

** Translations from pages 50 and 51 of CPS
(a) Individual Code Signing certificate
Applicants for individual Code Signing certificate are required to
submit the following material:
*** a written application form filled out and signed by applicants
*** personal ID (or military officer, student ID, passport, etc.)
(original and copy) . If SHECA or receiving point has confirmed specific
identity of the applicant by phone, mail, third-party verification or
other means, the applicant could submit copies of documents by fax and
mail instead of original.
*** Applicants must give a written commitment to the code certificate
that it is not used for any malicious or illegal purposes.
*** If it is entrusted to handle, SHECA require the applicant and the
trustee to submit above-mentioned documents and copies, and written
authorization autographed by applicant.

(b) Organization Code Signing certificate
Applicants for organization Code Signing certificate are required to
submit the following material:
*** a written application form filled out and signed by applicants
*** Certificate of Organization Code of the applicant (original and copy)
*** Business license of the applicant (original and copy). If there is
no business license, the applicant could submit some other optional
valid documents (original and copy) in application form. Present valid
documents recognized as follows: Business license, Corporate
registration certificate and institutions, Tax registration certificate,
organization code certificate, social groups, and other national
registration valid proof of legal recognition. If SHECA or receiving
point has confirmed specific identity of the applicant by phone, mail,
third-party verification or other means, the applicant could submit
copies of documents by fax and mail instead of original.
*** Applicants must give a written commitment to the code certificate
that it is not used for any malicious or illegal purposes.
*** identity card or military officer, student cards, passport and other
valid documents (original and copy) of applicant's trustee.
*** Written power of attorney to trustee (with official seal). When
submitting the application form, the applicant stamp the official seal
after the trustee signed the application form, it means a written
delegation of authority entrusted to the trustee.

* EV Policy OID: Not requesting EV at this time

* Test Websites
** UCA Root: https://eds.myliving.cn/
** UCA Global Root: https://www.sheca.com

* CRL
UCA Root ARL: http://ldap2.sheca.com/root/ucasub.crl
CRL: http://ldap2.sheca.com/CA11/RA9020100/CRL18.crl
UCA Global Root ARL: http://ldap2.sheca.com/root/ucaglobalsub.crl
CRL: http://ldap2.sheca.com/CA12/RA9020100/CRL5.crl
CRL issuing frequency for end-entity certificates: 12 hours

* OCSP
UCA Root: http://ocsp3.sheca.com/Sheca/sheca.ocsp
UCA Global Root: http://ocsp3.sheca.com/Global/global.ocsp

* Audit: The annual audit is performed by PricewaterhouseCoopers Aarata
according to the WebTrust CA criteria, and is posted on the webtrust.org
website,
https://cert.webtrust.org/ViewSeal?id=755 (2011.04.30)

Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices):

* None noted.

This begins the discussion of the request from SHECA to add the �UCA
Root� and �UCA Global Root� root certificates. For the �UCA Root� the
request is to enable all three trust bits. For the �UCA Global Root� the
request is to enable the websites and code signing trust bits. At the
conclusion of this discussion, I will provide a summary of issues noted
and action items. If there are no outstanding issues, then this request
can be approved. If there are outstanding issues or action items, then
an additional discussion may be needed as follow-up.

Kathleen

David E. Ross

unread,
Aug 7, 2011, 12:14:58 PM8/7/11
to mozilla-dev-s...@lists.mozilla.org
On 8/2/11 4:14 PM, Kathleen Wilson wrote [in part]:
> SHECA has applied to add the “UCA Root” and “UCA Global Root” root
> certificates. For the “UCA Root” the request is to enable all three
> trust bits. For the “UCA Global Root” the request is to enable the
> websites and code signing trust bits.
>
> Shanghai Electronic Certification Authority Co., Ltd. (SHECA) is a
> Shanghai-based commercial company and is one of the biggest
> Certification Authorities in China. SHECA is a national recognized CA
> and operates under China’s Electronic Signature Law. SHECA’s customers
> include individuals and companies from mainland China, Taiwan and Hong
> Kong. Four of SHECA’s major shareholders are government established
> investment vehicles and government-owned enterprises.
>
> Mozilla Comment: Being affiliated with a government is not a reason that
> Mozilla would reject a CA (there are several others already in the root
> store for Japan, Taiwan, and others). We have not found evidence of
> SHECA being compelled by another entity to issue an illegitimate
> certificate (e.g. for a domain that it shouldn’t).

>
> In past discussions regarding Chinese CAs, concerns have been raised
> about whether discussions in the mozilla.dev.security.policy forum are
> accessible to participants in China. Based on recent testing we believe
> that this forum is currently accessible to people in China. Testing
> found that Google Groups is blocked when https is used. However, the
> mozilla.dev.security.policy forum is in plain http, so it is accessible
> to participants in China. Anyone with information to the contrary should
> contact us immediately.

[snipped]

It appears that Google Groups stopped updating from all NNTP servers on
1 August 2011. This was noted by a member of the Big8 Management Board
regarding discussions on Usenet servers in the news.groups.proposals
newsgroup. He communicated this via E-mail to the other members of the
Big8 Management Board (which includes me). I then started checking
various newsgroups, both Usenet and news.mozilla.org and confirmed that
there are no Google Groups messages after 1 August.

I also made the above paragraph a comment in the bug report.

NOTE: Kathleen's message posted 2 August in this
mozilla.dev.security.policy newsgroup does NOT appear in Google Groups
as of today, 7 August 2011. No messages from the unmoderated
mozilla.support.seamonkey dated in the past 6 days appears in Google
Groups despite the fact that Google's description of Google Groups
claims that messages for unmoderated newsgroups should appear within
seconds.

--

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

On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.

Kathleen Wilson

unread,
Aug 8, 2011, 12:24:32 PM8/8/11
to mozilla-dev-s...@lists.mozilla.org
On 8/7/11 9:14 AM, David E. Ross wrote:
>
> It appears that Google Groups stopped updating from all NNTP servers on
> 1 August 2011. This was noted by a member of the Big8 Management Board
> regarding discussions on Usenet servers in the news.groups.proposals
> newsgroup. He communicated this via E-mail to the other members of the
> Big8 Management Board (which includes me). I then started checking
> various newsgroups, both Usenet and news.mozilla.org and confirmed that
> there are no Google Groups messages after 1 August.
>
> I also made the above paragraph a comment in the bug report.
>
> NOTE: Kathleen's message posted 2 August in this
> mozilla.dev.security.policy newsgroup does NOT appear in Google Groups
> as of today, 7 August 2011. No messages from the unmoderated
> mozilla.support.seamonkey dated in the past 6 days appears in Google
> Groups despite the fact that Google's description of Google Groups
> claims that messages for unmoderated newsgroups should appear within
> seconds.
>


I have filed bug #677270 for this.
https://bugzilla.mozilla.org/show_bug.cgi?id=677270

Thanks,
Kathleen

Gen Kanai

unread,
Aug 9, 2011, 2:47:24 AM8/9/11
to dev-secur...@lists.mozilla.org, Johnathan Nightingale

On 8/9/11 1:24 AM, Kathleen Wilson wrote:
> On 8/7/11 9:14 AM, David E. Ross wrote:

>> It appears that Google Groups stopped updating from all NNTP servers on
>> 1 August 2011. This was noted by a member of the Big8 Management Board
>> regarding discussions on Usenet servers in the news.groups.proposals
>> newsgroup. He communicated this via E-mail to the other members of the
>> Big8 Management Board (which includes me). I then started checking
>> various newsgroups, both Usenet and news.mozilla.org and confirmed that
>> there are no Google Groups messages after 1 August.
>>
>> I also made the above paragraph a comment in the bug report.
>>
>> NOTE: Kathleen's message posted 2 August in this
>> mozilla.dev.security.policy newsgroup does NOT appear in Google Groups
>> as of today, 7 August 2011. No messages from the unmoderated
>> mozilla.support.seamonkey dated in the past 6 days appears in Google
>> Groups despite the fact that Google's description of Google Groups
>> claims that messages for unmoderated newsgroups should appear within
>> seconds.
>>
>

> I have filed bug #677270 for this.
> https://bugzilla.mozilla.org/show_bug.cgi?id=677270

A few other things to consider:

We might ask Johnath to check the spam/filter at mailman to see if posts
coming in from the mailing list were stopped there. I am admin on
another list and I get more than a few spam emails there that I have to
moderate. There may be a backlog of moderation to be done.

https://lists.mozilla.org/listinfo/dev-security-policy

Gen


--
Gen Kanai

Erwann Abalea

unread,
Aug 9, 2011, 6:34:30 AM8/9/11
to mozilla-dev-s...@lists.mozilla.org
Bonjour,

Le 03/08/2011 01:14, Kathleen Wilson a écrit :

> In past discussions regarding Chinese CAs, concerns have been raised
> about whether discussions in the mozilla.dev.security.policy forum are
> accessible to participants in China. Based on recent testing we believe
> that this forum is currently accessible to people in China. Testing
> found that Google Groups is blocked when https is used. However, the
> mozilla.dev.security.policy forum is in plain http, so it is accessible
> to participants in China. Anyone with information to the contrary should
> contact us immediately.

Google Groups doesn't show any message more recent than August 1st. At
least on my interface. I just configured a Thunderbird to read the
messages since then.

Being in plain HTTP also means it is more easily filtered, though.

--
Erwann.

Kathleen Wilson

unread,
Aug 9, 2011, 11:55:41 AM8/9/11
to mozilla-dev-s...@lists.mozilla.org


Unless I'm misunderstanding, I don't think it's the spam/filter.
I review the postings that get stuck here:
https://lists.mozilla.org/admindb/dev-security-policy
I check this and clear out the queue regularly. There is quite a bit of
spam that gets caught. For the postings that get caught there that are
not spam, I add them to the "always approve" list, so they won't get
stuck again.

Thanks,
Kathleen

Kathleen Wilson

unread,
Aug 9, 2011, 1:47:39 PM8/9/11
to mozilla-dev-s...@lists.mozilla.org
On 8/2/11 4:14 PM, Kathleen Wilson wrote:
> SHECA has applied to add the “UCA Root” and “UCA Global Root” root
> certificates. For the “UCA Root” the request is to enable all three
> trust bits. For the “UCA Global Root” the request is to enable the

> websites and code signing trust bits.
>


I will re-start this discussion after the issues with Google Groups has
been resolved.

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

Kathleen


Jean-Marc Desperrier

unread,
Aug 10, 2011, 7:57:40 AM8/10/11
to mozilla-dev-s...@lists.mozilla.org
Kathleen Wilson wrote:
>
> I will re-start this discussion after the issues with Google Groups has
> been resolved.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=677270

Kathleen, this message as well as all the other recent ones is now
visible on Google Groups :
http://groups.google.com/group/mozilla.dev.security.policy/msg/e98329be380a6457

Kathleen Wilson

unread,
Aug 10, 2011, 12:14:11 PM8/10/11
to mozilla-dev-s...@lists.mozilla.org


Yes, the problem has been fixed, and the messages have shown up in
Google Groups.

https://bugzilla.mozilla.org/show_bug.cgi?id=677270#c3
"it was a general Google Groups issue that was resolved globally yesterday"


Since all of the messages have shown up, we can continue with this
discussion thread. (I won't re-start the discussion.)

Thanks,
Kathleen

Kathleen Wilson

unread,
Aug 12, 2011, 1:09:44 PM8/12/11
to mozilla-dev-s...@lists.mozilla.org
On 8/2/11 4:14 PM, Kathleen Wilson wrote:
> SHECA has applied to add the “UCA Root” and “UCA Global Root” root
> certificates. For the “UCA Root” the request is to enable all three
> trust bits. For the “UCA Global Root” the request is to enable the

> websites and code signing trust bits.
>
> Shanghai Electronic Certification Authority Co., Ltd. (SHECA) is a
> Shanghai-based commercial company and is one of the biggest
> Certification Authorities in China. SHECA is a national recognized CA
> and operates under China’s Electronic Signature Law. SHECA’s customers

> include individuals and companies from mainland China, Taiwan and Hong
> Kong. Four of SHECA’s major shareholders are government established

> investment vehicles and government-owned enterprises.
>
> Mozilla Comment: Being affiliated with a government is not a reason that
> Mozilla would reject a CA (there are several others already in the root
> store for Japan, Taiwan, and others). We have not found evidence of
> SHECA being compelled by another entity to issue an illegitimate
> certificate (e.g. for a domain that it shouldn’t).
> * For the “UCA Root” the request is to enable all three trust bits. For
> the “UCA Global Root” the request is to enable the websites and code

> signing trust bits. EV-treatment is not requested at this time.
>


Would at least two people please review and comment on this request?

Also, please encourage our colleagues in China to review and comment on
this request.

Kathleen


Kathleen Wilson

unread,
Aug 22, 2011, 12:55:09 PM8/22/11
to mozilla-dev-s...@lists.mozilla.org


Restating my request... Please review and comment on this root inclusion
request from SHECA.

Your constructive input will be greatly appreciated.

Kathleen

Stephen Schultze

unread,
Aug 24, 2011, 10:26:28 AM8/24/11
to mozilla-dev-s...@lists.mozilla.org
These questions do not constitute a review of the documents
themselves, but I believe that they should be preliminary to more
detailed review of the CPS etc.

- Can SHECA provide copies of the MIIT supervisory inspection results?
(MIIT Order of Feb 28 2009, Article 32)
- Can SHECA provide a copy of their license for electronic
certification services?
- Does SHECA have an "Operation License for Value-Added
Telecommunication Services"?
- Is SHECA subject to the "Computer Information Network and Internet
Security, Protection and Management Regulations" promulgated by the
Ministry of Public Security on December 30, 1997? If so, how do
Articles 8 and 21(4) apply to them in particular?

References for the 1997 regulations:
http://newmedia.cityu.edu.hk/cyberlaw/gp3/pdf/law_security.pdf
http://www.ichrdd.ca/english/commdoc/publications/globalization/legislationInternetChinaEng.pdf

0 new messages