474706 - Add Japanese Government Application CA Root

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Kathleen Wilson]

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

Comment 1

[Kathleen Wilson]

Attachment: English Translation of CP/CPS

Comment 2

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

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.

Comment 3

[Shigeru Yoshitake]

Japan GPKI team join this thread as "[e-mail]" in CC list.

Comment 4

[apca]

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

Comment 5

[Kathleen Wilson]

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

Comment 6

[apca]

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

Comment 7

[Shigeru Yoshitake]

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

Comment 8

[Kathleen Wilson]

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?

Comment 9

[apca]

Dear Kathleen,

Thank you for your comments.
We are planning to publish that information on our CA web site.

Thanks,
Yoshikazu OOE

Comment 10

[Kathleen Wilson]

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

Comment 11

[apca]

Dear Kathleen,

Along with your suggestion, we are trying to include that information in our CP/CPS.

Thanks,
Yoshikazu OOE

Comment 12

[apca]

Dear Kathleen,

WebTrust audit report for APCA has been renewed.
https://cert.webtrust.org/SealFile?seal=886&file=pdf

Thanks,
Yoshikazu OOE

Comment 13

[Kathleen Wilson]

Dear Yoshikazu,

Thank you for providing the updated audit.

Would you please translate it into English?

Thanks,
Kathleen

Comment 14

[apca]

Attachment: English Translation of audit report

English Translation of audit report

Comment 15

[Kathleen Wilson]

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

Comment 16

[apca]

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

Comment 17

[apca]

Attachment: English translation of CP/CPS

Comment 18

[apca]

Attachment: Changes of CP/CPS (Japanese/English)

Comment 19

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 20

[Kathleen Wilson]

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 [e-mail] 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.

Comment 21

[Kathleen Wilson]

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.

Comment 22

[Kathleen Wilson]

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.

Comment 23

[Kathleen Wilson]

I have filed bug #523434 against NSS for the actual changes.

Comment 24

[Kohei Yoshino]

According to Bug 528277, the root has landed to mozilla-central (trunk) and mozilla-1.9.2 (Firefox 3.6, namely Beta 5.)

Comment 25

[Kathleen Wilson]

Confirmed that this root is a Builtin Object Token in Firefox 3.6.