Closed Bug 474706 Opened 14 years ago Closed 13 years ago
Add Japanese Government Application CA Root
262.85 KB, application/x-zip-compressed
83.48 KB, application/pdf
35.51 KB, application/pdf
327.94 KB, application/pdf
102.60 KB, application/pdf
22.96 KB, application/pdf
I am creating this bug for Japan GPKI (Government Public Key Infrastructure) as per information that Frank forwarded to me in email. CA Name: Japanese Government Application CA Website URL: http://www.gpki.go.jp/apca/ (Japanese only) CA Summary: Japanese Government Application CA(APCA) is one of the root CAs for the PKI operated by the national government of Japan. The certificates issued by the APCA are used for services of national government agencies. Audit Type: WebTrust for CA Auditor: Deloitte Touche Tohmatsu Auditor Website URL: http://www.deloitte.com/jp Audit Document URL(s):https://cert.webtrust.org/SealFile?seal=812&file=pdf (Japanese only) Certificate Name: Japanese Government Application CA Summary Paragraph: Application CA issues server application certificates (such as SSL server certificates) to servers owned by national government agencies and also issues code signing certificates to national government agencies. ] Root certificate download URL: http://www.gpki.go.jp/apcaself/APCAroot.der Certificate SHA1 Fingerprint: 7F 8A B0 CF D0 51 87 6A 66 F3 36 0F 47 C8 8D 8C D3 35 FC 74 Key size (for RSA, modulus length) in bits: 2048bits Valid From (YYYY-MM-DD): 2007-12-12 Valid To (YYYY-MM-DD): 2017-12-12 CRL HTTP URL: http://dir.gpki.go.jp/ApplicationCA.crl CRL issuing frequency for subordinate EE certificates: 1days OCSP responder URL (if any): none Class: domain-validated, organizationally-validated CP/CPS URL: http://www.gpki.go.jp/apca/cpcps/index.html (Will attach English translation) Requested Trust Indicators: SSL and code signing URL of a sample website using a certificate chained to this root: https://www.gpki.go.jp/selfcert/finger_print.html Hierarchy Info: No subordinate CAs
Assignee: hecker → kathleen95014
Status: NEW → ASSIGNED
The attached document summarizes the information that has been gathered and verified for this request as per https://wiki.mozilla.org/CA:How_to_apply. Within the document the items highlighted in yellow indicate where more information or clarification is needed. I will also summarize here. 1) As per section 7 of http://www.mozilla.org/projects/security/certs/policy/ I need to find text in the CP/CPS that demonstrates that reasonable measures are taken to verify that the domain name is owned/controlled by the subscriber. I was not able to find this. 2) Please review the potentially problematic practices described at http://wiki.mozilla.org/CA:Problematic_Practices. If any of these are relevant, provide further information. This request has been added to the pending list at http://www.mozilla.org/projects/security/certs/pending/#Japanese%20GPKI Please review the entry and let me know if you would like to modify any of the information.
Japan GPKI team join this thread as "email@example.com" in CC list.
Dear Kathleen, (In reply to comment #2) > 1) As per section 7 of http://www.mozilla.org/projects/security/certs/policy/ I > need to find text in the CP/CPS that demonstrates that reasonable measures are > taken to verify that the domain name is owned/controlled by the subscriber. I > was not able to find this. Validation of the domain name is described in the LRA business management and system operation manual(Japanese only). * Validation of contents described in the server certificate application - The server's absolute domain name (FQDN) which described in certificate application is part of go.jp domain and registered in DNS. - The organization of domain holder which is verified with the whois service (http://whois.jprs.jp/) is part of organizations including offices and ministries. > 2) Please review the potentially problematic practices described at > http://wiki.mozilla.org/CA:Problematic_Practices. If any of these are relevant, > provide further information. The reasons why our CA doesn't have subordinate CA is as follows. Our CA issues small amount of certificates(for SSL and code signing) and also issues certificates for government agencies only. Our CA are taking security measures in every way (like facilities, operations). And audit has proven that security measures applied to protect our CA are more than sufficient. Thanks, Yoshikazu OOE
Dear Yoshikazu, Can you provide a link to the LRA business management and system operation manual? Do you want to enable trust bits for both SSL and code signing? Kathleen
Summary: Root Inclusion for Japanese Government Application CA → Add Japanese Government Application CA Root
Dear Kathleen, (In reply to comment #5) > Can you provide a link to the LRA business management and system operation > manual? The LRA business management and system operation manual is disclosed for government agencies only. The reasons not publicly disclosed is below. - That manual is written for the concrete procedures that LRA does. And that manual include the information that should not be disclosed in general. - As mentioned in our CP/CPS, our CA issues certificates for government agencies, not for unspecified majority. > Do you want to enable trust bits for both SSL and code signing? We would like to enable trust bits for both SSL and code signing. The trust bit for SSL is needed for right now and the trust bit for code signing is needed for the future. Thanks, Yoshikazu OOE
I got a request from Kathleen about description of code signing procedure, > To enable the code signing trust bit, the CA must satisfy the >requirement in section 7 of >http://www.mozilla.org/projects/security/certs/policy/ in regards to >code signing. I believe that sections 3.2.2 and 3.2.3 may satisfy this >if more detail were provided. I could not find what "according to a >prescribed procedure" means. Here is Mr. Ooe's response, ----------------------------------------- (1) Validation of existence of the subscriber and approver - The LRA reviewer verify the information (that is, division, title, first and last name, address, telephone number) of subscriber and approver with the list of names. (2) Validation of approver - The LRA viewer confirmed that those who approve are administrative positions of the application organization with the list of names. (3) Validation of willingness of subscribe and approval - The LRA reviewer verify the willingness of subscribe and approval by telephone or face to face. (4) Validation of contents described in the server certificate application - The server's absolute domain name (FQDN) which described in certificate application is part of go.jp domain and registered in DNS. - The organization of domain holder which is verified with the whois service (http://whois.jprs.jp/) is part of organizations including offices and ministries. (5) Validation of contents described in the code signing certificate application - The organization name which described in the certificate application exists in the public documents by organizations including offices and ministries. - The requested organization name is the organization name of most significant of the organization that LRA belongs to. ---------------------------------------------- Kathleen, If you need more information, please file it into this thread. Best regards. -shigeru
I believe that the information provided by Mr. Ooe would satisfy the requirements of section 7 of the Mozilla CA Certificate Policy if it were in a publicly available document such as the CP/CPS. Would it be possible for the GPKI team to add this to their CP/CPS?
Dear Kathleen, Thank you for your comments. We are planning to publish that information on our CA web site. Thanks, Yoshikazu OOE
Dear Mr. Yoshikazu OOE, I have learned that the information to satisfy section 7 of the Mozilla CA Certificate Policy needs to be included in the annual audits, as well as being publicly available. Apparently the best solution is to include this information in the CP/CPS, because the CP/CPS is part of the annual audits. Everything else in your request is complete, so I have added this request to the queue for public discussion at https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion It will take 2 to 3 months to work through the backlog in the queue and get to this request. Will that be sufficient time to update the CP/CPS? Thanks, Kathleen
Dear Kathleen, Along with your suggestion, we are trying to include that information in our CP/CPS. Thanks, Yoshikazu OOE
Dear Kathleen, WebTrust audit report for APCA has been renewed. https://cert.webtrust.org/SealFile?seal=886&file=pdf Thanks, Yoshikazu OOE
Dear Yoshikazu, Thank you for providing the updated audit. Would you please translate it into English? Thanks, Kathleen
English Translation of audit report
Thank you for the English translation of the audit. I have added links to the new audit and to the English translation in the pending page: http://www.mozilla.org/projects/security/certs/pending/#Japanese GPKI
Dear Kathleen, A new version of CP/CPS has been approved and published. http://www.gpki.go.jp/apca/cpcps/index.html -- Japanese only. I will also post English translation of new CP/CPS and changes of CP/CPS. Thanks, Yoshikazu OOE
I am now opening the first public discussion period for this request from the Japanese Government Public Key Infrastructure (GPKI) to add the “ApplicationCA - Japanese Government” root certificate and enable the Websites and Code Signing trust bits. 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 firstname.lastname@example.org 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 “Japanese GPKI Root Inclusion Request” Please actively review, respond, and contribute to the discussion.
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 “ApplicationCA - Japanese Government” root certificate and enable the Websites and Code Signing trust bits. Section 4 [Technical]. I am not aware of any technical issues with certificates issued by the Japanese GPKI, 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]. The Japanese GPKI appears to provide a service relevant to Mozilla users: It is a Japanese national government CA. 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 CP/CPS, which has been translated into English and attached to this bug: https://bug474706.bugzilla.mozilla.org/attachment.cgi?id=379657 Section 7 [Validation]. GPKI appears to meet the minimum requirements for subscriber verification, as follows: * Email: Not applicable -- not requesting the email trust bit. * SSL: Domain Name Verification is described in sections 3.2.3 and 4.1.2 of the CP/CPS. The RA verifies that the server's absolute domain name (FQDN) described in the certificate application is part of the go.jp domain or registered beforehand and registered in DNS. The RA verifies that the domain holder of the common name (CN) described in the certificate application is the organizations of offices and ministries to which the LRA belongs by using the whois service (http://whois.jprs.jp/). * Code: Verification procedures for Code Signing certificates are described in sections 3.2.3 and 4.1.2 of the CP/CPS. The RA confirms the authenticity of the subscriber by collating the information (name, contact address and so on) described in the application with the directory of government officials issued by the National Printing Bureau. Additionally, the RA confirms the intention to subscribe by telephone or face to face. Section 8-10 [Audit]. GPKI was audited within the past year by Deloitte Touche Tohmatsu, using the WebTrust CA criteria. The audit report is posted on cert.webtrust.org. An English translation of the audit report has also been attached to this bug. * Noted in Audit: MIC (Japan’s Ministry of Internal Affairs and Communications) “makes use of external registration authorities for specific subscriber registration activities as disclosed in MIC’s business practice disclosures. Our examination did not extend to the controls of external registration authorities.” * As described in figure 1-1 and section 1.3.3 of CP/CPS, the organization in each office and ministry acts as LRA. Based on section 8 of the CP/CPS, GPKI has been auditing the LRAs every year, and the GPKI external auditor has been auditing their execution of the audits. * The procedures and internal checks performed by the LRAs are documented in the LRA business management and system operation manual, which is issued by the Administrative Management Bureau, Ministry of Internal Affairs and Communications that directs this root. Section 13 [Certificate Hierarchy]. This root does not have subordinate CAs. It issues server certificates and code signing certificates directly to national government agencies. Other: * CRL: GPKI provides CRL, NextUpdate is 48 hours. * OCSP: GPKI does not provide OCSP. Based on this assessment I intend to approve this request to add the "ApplicationCA - Japanese Government" root certificate and enable the Websites and Code Signing trust bits.
To the representatives of the Japanese GPKI: 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 and recommendation in Comment #21, and on behalf of the Mozilla project I approve this request from the Japanese GPKI to include the following root certificate in Mozilla, with trust bits set as indicated: * ApplicationCA - Japanese Government (web sites, code signing) I will file the NSS bug to effect the approved changes.
Whiteboard: In public discussion → Approved - awaiting NSS
I have filed bug #523434 against NSS for the actual changes.
According to Bug 528277, the root has landed to mozilla-central (trunk) and mozilla-1.9.2 (Firefox 3.6, namely Beta 5.)
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Confirmed that this root is a Builtin Object Token in Firefox 3.6.
Whiteboard: Approved - awaiting NSS
You need to log in before you can comment on or make changes to this bug.