User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:22.214.171.124) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729) Build Identifier: We - Japan Certification Services, Inc. - would like you to include our root certificate to the default certificate store. Our certification authority named "SecureSign Root CA11" ... 1. issues SSL enabled web server certificates to public end entities from subordinate issuing CA, 2. is publishing its CP/CPS at "https://www2.jcsinc.co.jp/repository/SSAD-CPS-en.pdf" , 3. is publishing its self-signed certificate at "https://www2.jcsinc.co.jp/repository/certs/SSAD-rca.der" , 4. and subordinate CA certificate at "https://www2.jcsinc.co.jp/repository/certs/SSAD-sca1.der" , 5. has passed WebTrust for CA audit ( Seal is at http://www.jcsinc.co.jp/ ). Our certification authority named "SecureSign Root CA11" and its subordiante issuing CA ... 6. never knowingly issue certificates without the knowledge of the entities whose information is referenced in the certificates, nor knowingly issue certificates that appear to be intended for fraudulent use. 7. is technically interoperable with Firefox 2.x, 3.0.x and works when local trust operation of Firefox is done. 8. operates registration check ( as stated in our CP/CPS document ) to verify the ownership of the domain certified within our certificate. We have detailed procedure documents written in Japanese, and can send them to you. Regards, Akira Machida ( firstname.lastname@example.org ) Japan Certificatin Services, Inc. Reproducible: Always Expected Results: Our root certificate be included to the NSS default certificate store. We hope to be notified ASAP when this enrollment info is inadequate or insufficient.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: Request for inclusion of our certificates to the default certificate store → Add JCSI SecureSign RootCA11 root certificate
Created attachment 382546 [details] Initial Information Gathering Document Attaching the initial information gathering and verification document which summarizes the information that has been gathered and verified as per https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification Please review the document for accuracy and completeness. Within the document the items highlighted in yellow indicate where more information or clarification is needed. Please add the requested information to this bug.
Thank you for Initial Information Gathering Document. Requested information for yellow items are described below. General Information: ~~~~~~~~~~~~~~~~~~~~ (1) Primary market / customer base: Our market is primarily domestic. The CA's under this root issue certificates to the public. Subscribers are almost inside Japan, but some of them require communication with relying parties outside Japan, such as US/Canada, European countries, and Asia. The CA's under other root issue certificates for international business S/MIME e-mails. Root CA Info table: ~~~~~~~~~~~~~~~~~~~ (1) Test Website: https://ssad0406_2.jcsinc.co.jp/ (2) CRL URL: http://ssignadcrl01.jcsinc.co.jp/repository/crl/rca.crl ( Root CA primary CRLDP : Subordinate CA cert R.L. ) http://ssignadcrl02.jcsinc.co.jp/repository/crl/rca.crl ( Root CA secondary CRLDP : Subordinate CA cert R.L. ) http://ssignadcrl01.jcsinc.co.jp/repository/crl/sca1.crl ( Subordinate CA primary CRLDP : E/E cert R.L. ) http://ssignadcrl02.jcsinc.co.jp/repository/crl/sca1.crl ( Subordinate CA secondary CRLDP : E/E cert R.L. ) The "nextUpdate" for end-entity certificates is +36 hours from "thisUpdate". (3) List or description of subordinate CA's operated by the CA organization associated with the root CA: The SecureSign RootCA11 root has one internally-operated subordinate CA named SecureSign Public CA11, cert of which can be downloaded from: https://www2.jcsinc.co.jp/repository/certs/SSAD-sca1.der Currently there is no other internally operated subordinate CA's for this root. Additional subordinate CA's are under planning for S/MIME, TSA(Time Stamp Authority) and other certificates. (4) Subordinate CA's operated by third parties: Currently there is no plan for this root to have subordinate CA's that is operated by external third parties. (5) List any other root CA's that have issued cross-signing certificates for this root CA: Currently there is no plan for this root to cross certify, or to have cross certified by, any other root CA's. (6) If SSL certificates are issued within the hierarchy rooted at this root CA certificate: DV, OV, and/or EV: We perform identity/organization verification (OV) for SSL server certificates. The customer’s ownership/control of the FQDN, and the existence and the identity of the organization, whose name and address are included in the certificate, are verified. (7) CP/CPS: Repository: http://www.jcsinc.co.jp/english/repository/index.html CP/CPS in English: https://www2.jcsinc.co.jp/repository/SSAD-CPS-en.pdf Notes: The service under SecureSign RootCA11 root is governed by the CPS above. There are other CPS's listed in the web site for currently operated other services, whose root is not requested for the inclusion to Mozilla software. Flag Problematic Practices: ~~~~~~~~~~~~~~~~~~~~~~~~~~~ (1) Long-lived DV certificates: * Subscriber Web server certificates are valid for 1 year * Subscriber Long-term certificates for limited Time Stamp Authority and other type of certificates such as S/MIME are currently issued from under the other root, governed by another CPS. The migration of them to the SecureSign RootCA11 root is under planning. (2) Wildcard DV SSL certificates: Wildcard SSL certificates are not issued. (3) Delegation of Domain / Email validation to third parties: Currently RA operation is not delegated to the third party. We may do it after establishing the suitable control and audit procedure rules onto the external RA's. (4) Issuing end entity certificates directly from roots: End-entity certs are issued from the subordinate CA's. Root CA is normally inactive. (5) Allowing external entities to operate unconstrained subordinate CA's: Currently there is no plan to sign external subordinate CA's. (6) Distributing generated private keys in PKCS#12 files: The subscriber generates the private keys for web server certificates. Though JCSI has enough experience of securely transferring PKCS#12 files to the subscribers. (7) Certificates referencing hostnames or private IP addresses: Web server certificates are not issued to hostnames or IP addresses. (8) OCSP Responses signed by a certificate under a different root: No OCSP. (9) CRL with critical CIDP Extension: No CIDP. (10) Generic names for CAs: "SecureSign" is the product trademark owned by JCSI, registered in Japan. Best Regards, Akira Machida
This request has been added to the queue for public discussion at https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion The status column indicates where we are in the queue, which is the request whose status is “In First Discussion”. Most first discussions take one to two weeks. Since the discussions are dependent on volunteers reviewing and commenting on the requests, I try to limit the first discussions to one active discussion at a time. A description of the public discussion process is available at https://wiki.mozilla.org/CA:How_to_apply#Public_discussion An entry for this request has also been added to the pending page: http://www.mozilla.org/projects/security/certs/pending/#JCSI
Whiteboard: Information confirmed complete
In preparation for the upcoming public discussion, I have re-reviewed the information pertaining to this request. I have no further questions. When I start the public discussion, I will post information about it here in this bug.
I am now opening the first public discussion period for this request from Japan Certification Services, Inc. (JCSI) to add the “SecureSign RootCA11” root certificate and enable the Websites trust bit. For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding email@example.com mailing list. http://www.mozilla.org/community/developer-forums.html https://lists.mozilla.org/listinfo/dev-security-policy news://news.mozilla.org/mozilla.dev.security.policy The discussion thread is called “JCSI Root Inclusion Request” Please actively review, respond, and contribute to the discussion. A representative of the CA should promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: Information confirmed complete → In public discussion
The public comment period for this request is now over. This request has been evaluated as per sections 1, 5 and 15 of the official CA policy at http://www.mozilla.org/projects/security/certs/policy/ Here follows a summary of the assessment. If anyone sees any factual errors, please point them out. To summarize, this assessment is for the request to add the “SecureSign RootCA11” root certificate and enable the Websites trust bit. Section 4 [Technical]. I am not aware of any technical issues with certificates issued by JCSI, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report. Section 6 [Relevancy and Policy]. JCSI appears to provide a service relevant to Mozilla users: It is a commercial CA whose primary market is Japan, with relying parties also in US, Canada, European countries, and Asia. Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main document of interest is the CPS, which is provided in English: https://www2.jcsinc.co.jp/repository/SSAD-CPS-en.pdf Section 7 [Validation]. JCSI appears to meet the minimum requirements for subscriber verification, as follows: * Email: Not applicable. Not requesting the Email trust bit. * SSL: Verification of domain ownership/control is specified in the CPS section 3. The RAO verifies that the certificate being applied for represents an authentic Web site; performs a DNS lookup to verify existence; uses Whois to verify that the certificate subscriber is the domain owner; uses Whois to verify the accuracy of the organization name and address of the subscriber; and verifies correspondence between registration information in the certificate application form and the information in the CSR. * Code: Not applicable. Not requesting the Code Signing trust bit. Section 8-10 [Audit]. JCSI’s service is audited by Ernst & Young using the WebTrust CA criteria, and the most recent audit was completed in May of 2009. The Audit Report and Management’s Assertion are posted on the WebTrust website. The document contains the audit statement in both Japanese and English. https://cert.webtrust.org/SealFile?seal=908&file=pdf Section 13 [Certificate Hierarchy]. This root has one internally-operated subordinate CA for issuing SSL certificates to the public. In the future, JCSI plans to add other internally-operated subordinate CAs for S/MIME, Time Stamping, and other certificate types. Other: * The NextUpdate for the CRL for end-entity certs is 36 hours. * OCSP is not provided. Based on this assessment I intend to approve this request to add the “SecureSign RootCA11” root certificate and enable the Websites trust bit.
To the representatives of JCSI: Thank you for your cooperation and your patience. To all others who have commented on this bug or participated in the public discussion: Thank you for volunteering your time to assist in reviewing this CA request. As per the summary in Comment #7, and on behalf of the Mozilla project I approve this request from JCSI to include the following root certificate in Mozilla, with trust bits set as indicated: * SecureSign RootCA11 (web sites) I will file the NSS bug to effect the approved changes.
Whiteboard: In public discussion → Approved - awaiting NSS
I have filed bug 542798 against NSS for the actual changes.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: Approved - awaiting NSS → In NSS 3.12.6 and Firefox 3.6.2
You need to log in before you can comment on or make changes to this bug.