870185 - Add Renewed Japanese Government Application CA Root certificate

Status: RESOLVED WONTFIX

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

Description

[apca]

User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)

Comment 1

[apca]

CA:Information template 

【CA Details】
 CA Company/Organization Name:
  Japanese Government Public Key Infrastructure (GPKI)
　Ministry of Internal Affairs and Communications

 Website:
  http://www.gpki.go.jp
  http://www.gpki.go.jp/documents/gpki.html -- about GPKI
  (Japanese only)

 One Paragraph Summary of CA Company/Organization, including the following: 
  ・General nature (e.g., commercial, government, academic/research, nonprofit)
     National Government

  ・Primary geographical area(s) served 
     In Japan

  ・Number and type of subordinate CAs
     We will establish 1 SubordinateCA of APCA2root on October, 
     and the SubordinateCA issue cetificates(SSL Validation Type is OV)
     to national government.

 Audit Type (WebTrust, ETSI etc.):
  WebTrust Readiness audits　(before operating of subCA)
  WebTrust for CAs (end of this fiscal year)

 Auditor:
  N/A (now selecting)

 Auditor Website:
  N/A (after selection of auditor, this information is available)

 Audit Document URL(s):
  N/A (after selection of auditor, this information is available)


【Certificate Details】
 Certificate Name:
  Japanese Government ApplicationCA2 Root

 Summary Paragraph, including the following: 
  ・End entity certificate issuance policy, i.e. what you plan to do with the root
     Application CA2 (root) issues subordinate CA certificate for 
     Application CA2 (sub).
     Application CA2 (sub) 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.

 Diagram and/or description of certificate hierarchy:
   APCA2 root
    => subordinate CA (SubCA starts use from November, 2013. )

  ・Number and type of subordinate CAs
     1 SubCA

  ・List or description of subordinate CAs operated internally 
     We will establish a SubordinateCA by the end of this October.

  ・List or description of subordinate CAs operated by third parties 
     Ministry of Internal Affairs and Communications will operate a SubordinateCA.

  ・List root CAs that have issued cross-signing certificates for this root CA
     none

 Certificate HTTP download URL (on CA website): not yet

 Version: V3

 SHA1 Fingerprint:
  ‎f0 0f c3 7d 6a 1c 92 61 fb 6b c1 c2 18 49 8c 5a a4 dc 51 fb

 Public key length (for RSA, modulus length) in bits: RSA(2048Bits)

 Valid From (YYYY-MM-DD): ‎2013‎-3-‎13

 Valid To (YYYY-MM-DD): ‎2033‎-3-‎13

 CRL HTTP URL: http://dir.gpki.go.jp/ApplicationCA2Root.crl

 CRL issuing frequency for end-entity certificates:
  We will show you the URL after established subCA.

 OCSP URL: none

 Class (domain-validated, identity/organisationally-validated or EV):
  domain-validated, organizationally-validated 

 EV policy OID(s) (if applicable): none

 Certificate Policy URL: http://www.gpki.go.jp/apca2/cpcps/index.html
                         (only Japanese)

 CPS URL:
  http://www.gpki.go.jp/apca2/cpcps/index.html
  (only Japanese)

 List one or more Trust Bits to enable, choices are Websites (SSL/TLS), 
 Email (S/MIME), and/or Code (code/document signing): 
  Websites (SSL/TLS)
  Code (code/document signing)

 URL of website whose SSL certificate chains to this root (if applying for SSL):
  N/A (we don't applying for SSL)

Comment 2

[Kathleen Wilson]

I am accepting this bug, and will work on it as soon as possible, but I have a large backlog.
https://wiki.mozilla.org/CA:Schedule#Requests_in_the_Information_Gathering_and_Verification_Phase

I will update this bug when I begin the Information Verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

In the meantime, please update this bug as the following become available:
+ translations for the new CP/CPS 
+ intermediate certificate and test server cert issued, and test website available (provide URL)
+ Audit complete and public-facing audit statement available

Comment 3

[apca]

Attachment: English translation of CP/CPS

Comment 4

[Kathleen Wilson]

Before I can begin evaluation of this request, please provide the following information in this bug:

1) Attach the root cert or provide the URL for downloading the root cert.

2) Provide a URL to a test website whose webserver (SSL) certificate chains up to this new root cert.

3) Provide English translation of the sections of the CP/CPS document that describe the procedures for verifying the identity/authority of the certificate subscriber applying for a code signing certificate in this CA hierarchy. (I was not able to find this in the attached CP/CPS document.)

4) Provide English translation of the sections of the CP/CPS document that describe the procedures for verifying that the domain name to be included in the SSL certificate is owned/controlled by the certificate subscriber. (I was not able to find this in the attached CP/CPS document.)

5) Provide English translation of the section of the CP/CPS document that states that SSL certs are issued in accordance with the CA/Browser's Baseline Requirements; e.g. BR #8.3. (I was not able to find this in the attached CP/CPS document.)

6) Respond to Mozilla's CA Recommended Practices: https://wiki.mozilla.org/CA:Recommended_Practices

7) Respond to Mozilla's list of Potentially Problematic Practices: https://wiki.mozilla.org/CA:Problematic_Practices

Comment 5

[apca]

Attachment: English translation of CP/CPS(Sub)

Comment 6

[apca]

1) Please download the root certififate from the following URL.
   https://www.gpki.go.jp/apcaself/APCA2root.der

2) We will provide you the URL of our test website by the middle of November.
    We want to distribute the Root Certificate within this year.
    Is this time schedule acceptable for you?

3) We have submitted the APCA2(sub)CP/CPS to the bugreport on August 1.
   Please check the APCA2(sub)CP/CPS#3.2.2 and 3.2.3

4) Please check the APCA2(sub)CP/CPS#3.2.2 and 3.2.3, you will find
   our English translation of the section of the CP/CPS document.

5) Please check the APCA2(sub)CP/CPS#7.1, you will find our
   English translation of the section of the CP/CPS document.
   We submitted this on August 1.

6) We are now preparering materials relating "CA Recommended Practices".

7) There are no "Problematic Practice" in our APCA2.
   We are  now doing farther investigation relating this issue.
   At this moment,we found no problems, I believe.

Comment 7

[Kathleen Wilson]

Attachment: Initial CA Information Document

The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 8

[Kathleen Wilson]

(In reply to apca from comment #6)
> 2) We will provide you the URL of our test website by the middle of November.
>     We want to distribute the Root Certificate within this year.
>     Is this time schedule acceptable for you?

We cannot start the public discussion phase until a working test website (with the SSL cert chaining up to this root) has been provided. Please provide this (and the other information per Comment #7) as soon as possible.

After discussion completes and approval happens, it can be several more months before the root cert is included in a version of Firefox.

Comment 10

[Kathleen Wilson]

The following websites appear to be using certs that chain up to this new root. Since this new root is not yet included, Firefox gives the Untrusted Connection error.
https://www.gpki.go.jp/
https://www.hellowork.go.jp/

I also get the Untrusted Connection error when trying to download this new root cert:
https://www.gpki.go.jp/apcaself/APCA2root.der

Please consider using cross-signing with your old root cert for backwards compatibility until this new root cert is approved/included.

Please also provide the information requested in the Initial CA Information Document, as per Comment #7.

Comment 11

[Kosuke Kaizuka]

Now, Firefox can connect to these sites without Untrusted Connection error.

> https://www.hellowork.go.jp/

Server cert has been reverted to old one issued by old root cert (ApplicationCA).
 
> https://www.gpki.go.jp/
> https://www.gpki.go.jp/apcaself/APCA2root.der
> 
> Please consider using cross-signing with your old root cert for backwards
> compatibility until this new root cert is approved/included.

New intermediate cert (ApplicationCA2 (Sub)) can be verified by old root cert (ApplicationCA).
It seems that new root cert (ApplicationCA2 (root)) and old one (ApplicationCA) are cross-signed.

Comment 12

[apca]

<General information about the CA's associated organization>

 CA Contact Information
  CA Email Alias:[e-mail] 
  CA Phone Number:[phone]
  Title/Department:_GPKI of Administrative Management Bureau of the Ministry
                   of Internal Affairs and Communications



<Technical information about each root certificate>

 TestWebsiteURL
  https://www.gpki.go.jp/apca2/apca2_eng.html

 OCSP URL (Required now)
  Currently, our GPKI does not need OCSP function, because of following reasons.
  - Maximum traffic load of GPKI is around 5%
  - Expecting traffic load of near future is same as current level
  - Number of new CRL registrations will be limited
  In the future, if high traffic load of GPKI is expected, we will consider this function.

 Non-sequential serial numbers and entropy incert
  This January, we have replaced our systems and now our APCA & APCA2 are conforming to this requirements.



<CA Hierarchy information for each root certificate>

 Technical Constraints on Third-party Issuers
  No, our LRAs can't issue SSL certificates. Our LRAs accept and review applications for issuance only.
  Our IA issues SSL certificates. In the LRA system, only principle,
  go.jp domain come by publication application. 

  CPS section 1.6:
  -IA (Issuing Authority)
  An agency that carries out those aspects of CA operations that relate to certificate issuance.
  A “general IA operators” are persons whose main task is the issuance of certificates.
  Within the Application CA2(Sub),these peoples are classified into “senior IA operators” and
 “general IA operators” according to the basis of the authority.

  The LRAs confirm that the domain holder of the common name (CN) described in the Server certificate
  application is the organizations of offices or ministries to which the LRA belongs
  by using the database provided by the third-party body and so on.
  Also, the LRAs confirm that the organization name of the common name (CN) described
  in the code-signing application exists and is the organization name of offices 
  or ministries to which the LRA belongs by using the public documents published by offices or ministries.



<Verification Policies and Practices>

 Baseline Requirements (SSL)
  We are striving to be compliant with BR, and audited  WebTrust2.0 with BR17.1,
  APCA2 recived the authorization of WebTrust for Certificate Authority.
  We have published this report audit results.
  <https://cert.webtrust.org/SealFile?seal=1633&file=pdf>

 Organization Verification Procedures
  In the internal regulation of LRA, verification processes of the reality of desriptions
  in certificaes are stipulated clearly.
  As for th cerver certificates, following verification processes are stipulated.
  Verifications are processed according to this process. 

   1. Sever Certificate
    - Verify FQDN of the server which described in the common name (CN) desicrived
      in the server certificate application is "go.jp" domain and is registrating in the name server.
    - Verify the domain owner name of the domain part of FQDN by using "Whois".

   2. Code signing Certificate
   3. Document signing Certificate

  The LRAs confirm that the organization name of the common name (CN) described
  in the code-signing application exists and is the organization name of offices
  or ministries to which the LRA belongs by using the public documents published
  by offices or ministries.

 SSL Verification Procedures
  In the internal regulation of LRA, verification processes of the reality of desriptions
  in certificaes are stipulated clearly.
  As for th cerver certificates, following verification processes are stipulated.
  Verifications are processed according to this process.
  Also the internal audit are schedlued onece a year. So, we think the update of CPS is not necessary.

  Verification Processes
   - Verify FQDN of the server which described in the common name (CN) desicrived
     in the server certificate application is "go.jp" domain and is registrating in the name server.
   - Verify the domain owner name of the domain part of FQDN by using "Whois".

 Multi-factor Authentication
  After the verification of certificate issuance, the LRA Operator(Government officer)
  login to the LRA system by using smart card and password.
  Then operates the LRA system.
　A sever certificate and a code-singning certificate are issued from the LRA system.
  Electronic certificate is stored in the smart card and only LRA Operators have the smart card.
  So, LRA Operators can comunicate with the LRA system on SSL client certification by smart card.

 Network Security
  Network of GPKI is utilizing the closed network which interconnects each LAN of ministiries and agencies.
  Strictly limited personnels are permitted to utilze it.
  Strict registration and permmmiton processes are implemented and followed.
  Also transmittion data are encrypted. Therefore we believe minimum security requirements are satisfied.



<Response to Mozilla's CA Recommended Practices>

 Document Handling of IDNs in CP/CPS
  It does not allow the use of IDN.

 Revocation of Compromised Certificates
  We revoke certificates with private keys that are known to be compromised,
  or for which verification of subscriber information is known to be invalid. 
 
 DNS names go in SAN
  We set Server FQDN to Subject Alternative Names.
  CP/CPS section "7. Certificate and CRL profiles".

 Domain owned by a Natural Person
  We don't issue certificates to "natural person".

 OCSP
  We don't have OCSP.



<Response to Mozilla's list of Potentially Problematic Practices>

 Wildcard DV SSL certificates
  No, wildcard SSL certs cannot be issued.

 Email Address Prefixes for DV Certs
  SSL certs are IV/OV, not DV.

 Certificates referencing hostnames or private IP addresses
  There is no IPaddress in the Certificate which was issued by APCA2.

 Issuing SSL Certificates for Internal Domains
  We don't issue Certificates containing a new gTLD under consideration.

 OCSP Responses signed by a certificate under a different root
  We don't have OCSP.

 CRL with critical CIDP Extension
  We issue "full" CRL, and don't put any CRL Issuing Distribution Point (CIDP) extension in the CRL.

 Lack of Communication With End Users
  We are indicating the contact information in our WebSite.
  Contact ; http://www.gpki.go.jp/sendto.html

Comment 13

[Kathleen Wilson]

(In reply to apca from comment #12)
> 
>  OCSP URL (Required now)
>   Currently, our GPKI does not need OCSP function, because of following
> reasons.
>   - Maximum traffic load of GPKI is around 5%
>   - Expecting traffic load of near future is same as current level
>   - Number of new CRL registrations will be limited
>   In the future, if high traffic load of GPKI is expected, we will consider
> this function.
> 

OCSP is part of the CA/Browser Forum's Baseline Requirements (BR #13.2.2), so it is now required that OCSP be provided before a new root cert may be included. 


> 
> <Verification Policies and Practices>
> 
>  Baseline Requirements (SSL)
>   We are striving to be compliant with BR, and audited  WebTrust2.0 with
> BR17.1,
>   APCA2 recived the authorization of WebTrust for Certificate Authority.
>   We have published this report audit results.
>   <https://cert.webtrust.org/SealFile?seal=1633&file=pdf>

Please see section 8.3 of the CA/Browser Forum's Baseline Requirements, regarding the Commitment to Comply statement that needs to be added to the CPS.

Also see the requirement to have a BR audit.
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Baseline_Requirements


>  Organization Verification Procedures
>   In the internal regulation of LRA, verification processes of the reality
> of desriptions in certificaes are stipulated clearly.
...
>  SSL Verification Procedures
>   In the internal regulation of LRA, verification processes of the reality
> of desriptions in certificaes are stipulated clearly.
...
>  So, we think the update of CPS is not necessary.

We rely on publicly available documentation and audits of those documented processes to ascertain that the CA takes reasonable measures to confirm the identity and authority of the individual and/or organization of the certificate subscriber. Therefore, the CPS documentation does need to be updated, in order to proceed with this request.



In an upcoming Firefox release we are adding the ability to association name constraints to root certificates, so at the root level we will be able to constrain SSL certs within the hierarchy to certain domain names, such as *.go.jp. Please provide the list of such domain constraints that could be used for this new root as well as the ApplicationCA root.

Comment 14

[apca]

>OCSP is part of the CA/Browser Forum's Baseline Requirements (BR #13.2.2), so it is now required that
>OCSP be provided before a new root cert may be included. 

Currently, our GPKI doesn't need OCSP function as mentioned in the last our response.
However, now we are reconsidering the inclusion of OCSP function for high traffic load in the future.
We will implement OCSP in the near future.


>Please see section 8.3 of the CA/Browser Forum's Baseline Requirements, regarding the Commitment to 
>Comply statement that needs to be added to the CPS.
>Also see the requirement to have a BR audit.
>https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Baseline_Requirements

APCA2 add the following sentence to "Introduction" in the CP / CPS.
APCA2(Root) strive to comply with the latest version of AICPA/CICA, WebTrust Program for Certification 
Authorities and CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly.


>In an upcoming Firefox release we are adding the ability to association name constraints to root
>certificates, so at the root level we will be able to constrain SSL certs within the hierarchy to
>certain domain names, such as *.go.jp. Please provide the list of such domain constraints that 
>could be used for this new root as well as the ApplicationCA root.

Thank you for your Suggestions.
In principle, GPKI can issue the certificates of "*..go.jp" domain nemes only.
But it can also issue the certificate for governmental agencies' domain names in addition to  
"*.go.jp" after the review and configuration changes.
I think it is difficult to submit the list, because it needs updates frequently.

Comment 15

[Kathleen Wilson]

(In reply to apca from comment #14)
> >OCSP is part of the CA/Browser Forum's Baseline Requirements (BR #13.2.2), so it is now required that
> >OCSP be provided before a new root cert may be included. 
> 
> Currently, our GPKI doesn't need OCSP function as mentioned in the last our
> response.
> However, now we are reconsidering the inclusion of OCSP function for high
> traffic load in the future.
> We will implement OCSP in the near future.

Please add a comment to this bug when the test site (https://www.gpki.go.jp/apca2/apca2_eng.html) has been updated to use an SSL cert that has an OCSP URI in the AIA, and the OCSP service is compliant with the Baseline Requirements.


> >Please see section 8.3 of the CA/Browser Forum's Baseline Requirements, regarding the Commitment to 
> >Comply statement that needs to be added to the CPS.
> >Also see the requirement to have a BR audit.
> >https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Baseline_Requirements
> 
> APCA2 add the following sentence to "Introduction" in the CP / CPS.
> APCA2(Root) strive to comply with the latest version of AICPA/CICA, WebTrust
> Program for Certification 
> Authorities and CA/Browser Forum, Baseline Requirements for the Issuance and
> Management of Publicly.


I am not finding this in https://www.gpki.go.jp/apca2/cpcps/cpcps_root_eng.pdf 
Am I looking at the wrong document?

Also, please note that an audit statement regarding compliance with the Baseline Requirements is needed, as per 
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Audit_Criteria
and section 11 of
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/

Please also note that we need the CPS document to provide information about the steps that are required to be taken to confirm that the certificate subscriber owns/controls the domain names to be included in the certificate, as per section 7 of
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/


> >In an upcoming Firefox release we are adding the ability to association name constraints to root
> >certificates, so at the root level we will be able to constrain SSL certs within the hierarchy to
> >certain domain names, such as *.go.jp. Please provide the list of such domain constraints that 
> >could be used for this new root as well as the ApplicationCA root.
> 
> Thank you for your Suggestions.
> In principle, GPKI can issue the certificates of "*..go.jp" domain nemes
> only.
> But it can also issue the certificate for governmental agencies' domain
> names in addition to  
> "*.go.jp" after the review and configuration changes.
> I think it is difficult to submit the list, because it needs updates
> frequently.


Please consider this some more. 
Is there any reason why the SSL certs in this CA hierarchy would need to contain domain names outside of *.jp?
Is there a reasonable set of constraints that could be used to encompass all of the domain names that the SSL certs in this CA hierarchy would need? 
We can create a list such as *.go.jp, *.gr.jp, *.co.jp, etc.

Comment 16

[apca]

>Please add a comment to this bug when the test site (https://www.gpki.go.jp/apca2/apca2_eng.html) has 
>been updated to use an SSL cert that has an OCSP URI in the AIA, and the OCSP service is compliant with 
>the Baseline Requirements.

yes, I will do.


>I am not finding this in https://www.gpki.go.jp/apca2/cpcps/cpcps_root_eng.pdf 
>Am I looking at the wrong document?
>
>Also, please note that an audit statement regarding compliance with the Baseline Requirements is
>needed, as per 
>https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Audit_Criteria
>and section 11 of
>http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
>
>Please also note that we need the CPS document to provide information about the steps that are 
>required to be taken to confirm that the certificate subscriber owns/controls the domain names
>to be included in the certificate, as per section 7 of
>http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/


We submitted the comments in CP/CPS.

https://www.gpki.go.jp/apca2/cpcps/cpcps_root_eng.pdf;
 1. Introduction 

https://www.gpki.go.jp/apca2/cpcps/cpcps_sub_eng.pdf;
 1. Introduction
 4.1.2   Enrollment process and responsibilities (1)Server certificate

Please find my comments.


>Please consider this some more. 
>Is there any reason why the SSL certs in this CA hierarchy would need to 
>contain domain names outside of *.jp?
>Is there a reasonable set of constraints that could be used to encompass 
>all of the domain names that the SSL certs in this CA hierarchy would need? 
>We can create a list such as *.go.jp, *.gr.jp, *.co.jp, etc.

We decided that we will accept only *.go.jp domain.

Comment 17

[Kathleen Wilson]

I see the updates in the CP/CPS documents. Thanks.

Comment 18

[apca]

After 5th March, we heard no news from you.
Please teach us which phase our APCA2(Root) is, and when our APCA2 will be Included.

Do you remove the root certificate of APCA from Mozilla products
when the root certificate of APCA2(root) is included in Mozilla's products, immediately?

Comment 19

[Kathleen Wilson]

This request is still in the Information Verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

According to my notes, I'm waiting for:

1) OCSP, as required by the Baseline Requirements, 
https://cabforum.org/baseline-requirements-documents

2) Test website with an SSL cert that has the OCSP URI in the AIA

3) Audit statement regarding BR compliance
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Audit_Criteria
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Baseline_Requirements

Comment 20

[Kathleen Wilson]

(In reply to apca from comment #18)
> Do you remove the root certificate of APCA from Mozilla products
> when the root certificate of APCA2(root) is included in Mozilla's products,
> immediately?

There can be a transition time, when both roots are included.

Comment 21

[Kathleen Wilson]

I have not yet recorded a response for the "ApplicationCA - Japanese Government" root regarding the recent CA Communication: 
https://wiki.mozilla.org/CA:Communications#May_13.2C_2014

Please respond ASAP. Either respond in this bug, or send me email.

Comment 22

[apca]

Attachment: English translation of APCA2Root CP/CPS

Comment 23

[apca]

Attachment: English translation of APCA2(Sub)CP/CPS

Comment 24

[apca]

I show you the testwebsite with an SSL cert that has the OCSP URI in the AIA.
https://www2.gpki.go.jp/apca2/apca2_eng.html

We have revised the CP/CPS to be able to issue a SSL certificate with the OCSP URI.
I attached new CP/CPS at bugzilla, please see.

Comment 25

[Kathleen Wilson]

Attachment: 870185-CAInformation.pdf

I entered the information from this request into SalesForce.

Please check the attached document for accuracy.

Comment 26

[Kathleen Wilson]

When do you expect to have your next WebTrust CA audit statement for this root/hierarchy? 
When do you expect to have a BR audit statement for this root/hierarchy?

Please read: https://wiki.mozilla.org/CA:BaselineRequirements

Comment 27

[apca]

(In reply to Kathleen Wilson from comment #25)
> Created attachment 8552788 [details]
> 870185-CAInformation.pdf
> 
> I entered the information from this request into SalesForce.
> 
> Please check the attached document for accuracy.
　I checked it, could you update the audit information of the 4th page?
　Audit Name             ; KPMG AZSA LLC
　Audit Website          ; http://www.kpmg.com/global/en/pages/default.aspx
　Auditor Qualifications ; ?
　Standard Audit         ; https://cert.webtrust.org/ViewSeal?id=1793
　Standard Audit type    ; webtrust
　Standard Audit
　Statement Date         ; 12/25/2014

Comment 28

[apca]

(In reply to Kathleen Wilson from comment #26)
> When do you expect to have your next WebTrust CA audit statement for this
> root/hierarchy? 
　We ware audited by AZSA LLC last year.
　This is a new WebTrust CA audit statement. <https://cert.webtrust.org/ViewSeal?id=1793>

> When do you expect to have a BR audit statement for this root/hierarchy?
 We will take a readiness assessment of the BR audit this year, and we will take the BR audit next year.

Comment 29

[Kathleen Wilson]

Attachment: 870185-CAInformation.pdf

Comment 30

[Kathleen Wilson]

Please update this bug when you can provide a public-facing auditor's statement regarding the BR readiness assessment.

Comment 31

[apca]

We will submit readiness assessment report of the BR audit in September.

Comment 32

[apca]

Attachment: English translation of APCA2Root CP/CPS

Comment 33

[apca]

Attachment: English translation of APCA2(Sub)CP/CPS

Comment 34

[apca]

Attachment: WTBR_Readiness Assessment Report

Comment 35

[apca]

Attachment: Response to Findings

Comment 36

[apca]

As we had the Readiness Assessment based on “WebTrust Principles and Criteria for Certification Authorituies - SSL Baseline with Network Security”, attached "Readiness Assessment Rport" and "Response to Findings".
And, we attached new CP/CPS, because we revised CP/CPS.

We changed TestWebsiteURL.
  https://www2.gpki.go.jp/apca2/apca2_eng.html

Comment 37

[Kathleen Wilson]

Attachment: APCA2Root.der

Comment 38

[Kathleen Wilson]

Attachment: 870185-CAInformation-Complete.pdf

Comment 39

[Kathleen Wilson]

This request has been added to the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
I will update this bug when I start the discussion.

Comment 40

[Kathleen Wilson]

Please provide the completed BR Audit.

BR section 8.1: "The point-in-time readiness assessment ... and SHALL be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate."

Comment 41

[apca]

Here is the new audit satement information, which is the answer for your request below.

•	ApplicationCA - Japanese Government

Standard Audit: https://cert.webtrust.org/ViewSeal?id=1960
Audit Statement Date: 2015-12-25

----- your request in e-mail ----
As per Mozilla's CA Certificate Maintenance Policy, we require that all CAs whose certificates are distributed with our software products provide us an updated statement annually of attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties.

Comment 42

[Kathleen Wilson]

(In reply to apca from comment #41)
> Here is the new audit satement information, which is the answer for your
> request below.
> 
> •	ApplicationCA - Japanese Government
> 
> Standard Audit: https://cert.webtrust.org/ViewSeal?id=1960
> Audit Statement Date: 2015-12-25

As far as I can tell, this audit statement is the WebTrust for CA audit for the ApplicationCA2 Root.

Regarding the Baseline Requirements Audit, the link I have is:
https://bug870185.bmoattachments.org/attachment.cgi?id=8667814
Which is the Readiness Assessment Report dated September 30. According to the Baseline Requirements, the Readiness Assessment is supposed to be followed by a complete BR audit within 90 days of issuing the first publicly-trusted certificate.

Have an publicly-trusted certificates been issued under the ApplicationCA2 Root?

Comment 43

[Paul Kehrer]

https://www.cryptrec.go.jp is currently using a certificate issued from a subordinate of this root.

Comment 44

[Kathleen Wilson]

I finally got time to work on root inclusion discussions again, and was going to start this one. However, As pointed out in Comment #43, we know of at least one publicly-trusted certificate that chains up the ApplicationCA2 root certificate -- it is valid from June 17, 2015.

Yet, the audit statement that I currently have for the ApplicationCA2 root certificate is a Readiness Assessment, dated September 30, 2015.

So, when will a full BR Audit statement be provided?

Comment 45

[apca]

(In reply to Kathleen Wilson from comment #44)

We will improve the issues that was pointed out in the pre-audit and submit the investigation report by September 2016. 
Then, we will submit the BR audit in March 2017.

> I finally got time to work on root inclusion discussions again, and was
> going to start this one. However, As pointed out in Comment #43, we know of
> at least one publicly-trusted certificate that chains up the ApplicationCA2
> root certificate -- it is valid from June 17, 2015.
> 
> Yet, the audit statement that I currently have for the ApplicationCA2 root
> certificate is a Readiness Assessment, dated September 30, 2015.
> 
> So, when will a full BR Audit statement be provided?

Comment 46

[Kathleen Wilson]

(In reply to apca from comment #45)
> We will improve the issues that was pointed out in the pre-audit and submit
> the investigation report by September 2016. 

I will go ahead and start the discussion now, but a decision about inclusion will have to wait until after the investigation report is received and reviewed.

Comment 47

[Kathleen Wilson]

I am now opening the public discussion period for this request from the Government of Japan to include the GPKI 'ApplicationCA2 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 forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called "Japan GPKI Root Renewal Request".

Please actively review, respond, and contribute to the discussion.

A representative of this CA must promptly respond directly in the discussion thread to all questions that are posted.

Comment 48

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #47)
> I am now opening the public discussion period for this request from the
> Government of Japan to include the GPKI 'ApplicationCA2 Root' certificate
> and enable the Websites trust bit.
> 

The discussion is on hold pending completion of the following action items by the CA:

1) Update the CP/CPS documents with sufficient detail to describe the policies and procedures that apply to this root cert and all certs that chain to it.
Note that I added a new section to the Recommended Practices wiki page to provide pointers to previous reviews of CP/CPS documents, so CAs can see both good and not-so-good examples.
https://wiki.mozilla.org/CA:Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21

2) Provide an updated BR audit statement

Comment 49

[apca]

Currently, we are audited towards the acquisition of BR.
By the end of March of 2017, we will submit the BR audit report.
After submission, please get us quick correspondence.

(In reply to Kathleen Wilson from comment #48)
> (In reply to Kathleen Wilson from comment #47)
> > I am now opening the public discussion period for this request from the
> > Government of Japan to include the GPKI 'ApplicationCA2 Root' certificate
> > and enable the Websites trust bit.
> > 
> 
> The discussion is on hold pending completion of the following action items
> by the CA:
> 
> 1) Update the CP/CPS documents with sufficient detail to describe the
> policies and procedures that apply to this root cert and all certs that
> chain to it.
> Note that I added a new section to the Recommended Practices wiki page to
> provide pointers to previous reviews of CP/CPS documents, so CAs can see
> both good and not-so-good examples.
> https://wiki.mozilla.org/CA:Recommended_Practices#CP.
> 2FCPS_Documents_will_be_Reviewed.21
> 
> 2) Provide an updated BR audit statement

Comment 50

[apca]

The fingerprints of APCA2 are as follows.

SHA-1：F0:0F:C3:7D:6A:1C:92:61:FB:6B:C1:C2:18:49:8C:5A:A4:DC:51:FB
SHA-256：12:6B:F0:1C:10:94:D2:F0:CA:2E:35:23:80:B3:C7:24:29:45:46:CC:C6:55:97:BE:F7:F1:2D:8A:17:1F:19:84

Please confirm the above fingerprints information.

Comment 51

[Kathleen Wilson]

(In reply to apca from comment #50)
> The fingerprints of APCA2 are as follows.
> 
> SHA-1：F0:0F:C3:7D:6A:1C:92:61:FB:6B:C1:C2:18:49:8C:5A:A4:DC:51:FB
> SHA-256：12:6B:F0:1C:10:94:D2:F0:CA:2E:35:23:80:B3:C7:24:29:45:46:CC:C6:55:97:
> BE:F7:F1:2D:8A:17:1F:19:84
> 
> Please confirm the above fingerprints information.

In the attachment called 870185-CAInformation-Complete.pdf. You will see the same SHA-1 and SHA-256 fingerprints.

Comment 52

[apca]

>> The fingerprints of APCA2 are as follows.
>> 
>> SHA-1：F0:0F:C3:7D:6A:1C:92:61:FB:6B:C1:C2:18:49:8C:5A:A4:DC:51:FB
>> SHA-256：12:6B:F0:1C:10:94:D2:F0:CA:2E:35:23:80:B3:C7:24:29:45:46:CC:C6:55:97:
>> BE:F7:F1:2D:8A:17:1F:19:84
>> 
>> Please confirm the above fingerprints information.

> In the attachment called 870185-CAInformation-Complete.pdf. You will see the same SHA-1 and SHA-256 
> fingerprints. 

Thank you for your good advice.

(In reply to Kathleen Wilson from comment #51)
> (In reply to apca from comment #50)
> > The fingerprints of APCA2 are as follows.
> > 
> > SHA-1：F0:0F:C3:7D:6A:1C:92:61:FB:6B:C1:C2:18:49:8C:5A:A4:DC:51:FB
> > SHA-256：12:6B:F0:1C:10:94:D2:F0:CA:2E:35:23:80:B3:C7:24:29:45:46:CC:C6:55:97:
> > BE:F7:F1:2D:8A:17:1F:19:84
> > 
> > Please confirm the above fingerprints information.
> 
> In the attachment called 870185-CAInformation-Complete.pdf. You will see the
> same SHA-1 and SHA-256 fingerprints.

Thank you for your good advice.

Comment 53

[Takanori MATSUURA]

(In reply to apca from comment #49)
Any progress?

There are many websites shown as unsafe on Firefox.
ie.
https://www.gpki.go.jp/
https://www.e-gov.go.jp/
https://www.geps.go.jp/
https://www.e-rad.go.jp/
https://www.knowledge.maff.go.jp/
https://mm-enquete.meti.go.jp/
https://disclosure.edinet-fsa.go.jp/
https://www.jisc.go.jp/
https://www.nsr.go.jp/


And there are many websites using non-GPKI issuer to escape this issue. :-(

Comment 54

[apca]

Attachment: WTBR_report(E).pdf

We performed audits according to comments 46 to 48,  as a result, it became clear that the "Application CA 2" conforms to WTBR, so attach that report.

Comment 55

[apca]

We performed audits according to comments 46 to 48,  as a result, it became clear that the "Application CA 2" conforms to WTBR, so attached that report.
With this, we want to start the discussion on inclusion “Application CA2” to Mozilla.

Comment 56

[Kathleen Wilson]

(In reply to apca from comment #55)
> We performed audits according to comments 46 to 48,  as a result, it became
> clear that the "Application CA 2" conforms to WTBR, so attached that report.
> With this, we want to start the discussion on inclusion “Application CA2” to
> Mozilla.


Please perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug.

Note:
Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

= Background = 

We are adding a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ

Comment 57

[apca]

Attachment: BR_Self_Assessment_20170428.xlsx

We attached the BR Self Assessment accordingg to the comment 56.
Thank you.

Comment 58

[Aaron Wu]

Hi,

Thanks to provide BR Self Assessment! As Comment#48, please update the CP/CPS documents with sufficient detail to describe the policies and procedures that apply to this root cert and all certs that chain to it.

In your BR Self Assessment, you also mentioned below:
" CP / CPS is revised every year even when there is no change."

Here is the one I can find in your document, please make it up-to-date.
https://www2.gpki.go.jp/apca2/apca2_eng.html

Thanks,
Aaron

Comment 59

[apca]

Attachment: GPKI_APCA2Root_CPCPS_English.pdf

We attached the revised CP/CPS of APCA2(Root) according to the comment 58.
You can see the same new version of CP/CPS of APCA2(Root) at https://www2.gpki.go.jp/apca2/apca2_eng.html
Thank you.

Comment 60

[apca]

Attachment: GPKI_APCA2Sub_CPCPS_English.pdf

We attached the revised CP/CPS of APCA2(Sub) according to the comment 58.
You can see the same new version of CP/CPS of APCA2(Sub) at
https://www2.gpki.go.jp/apca2/apca2_eng.html
thank you.

Comment 61

[Aaron Wu]

Hi,

Thanks to provide your updated CP/CPS. I've reviewed and corresponding to BR Self Assessment, one more thing that please provide the 3 URLs to the test websites as described in Section 2.2 of the BRs: "The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired.

Thank you so much!

Regards,
Aaron

Comment 62

[apca]

Attachment: GPKI_APCA2Sub_CPCPS_English.pdf

We attached the revised CP/CPS of APCA2(Sub).
You can see the same new version of CP/CPS of APCA2(Sub) at
https://www2.gpki.go.jp/apca2/apca2_eng.html
Thank you.

Comment 63

[Aaron Wu]

Hi,

Thanks to provide updated CPS, which amended by 2017/9/8. I am doing verification of this CPS and related information, and intend to make this request back to discussion pool.

In the meanwhile, please see Comment#61 and provide the information I listed.

Thank you so much!

Best Regards,
Aaron

Comment 64

[apca]

Hi,

As you pointed out of Comment#61, in addition to the normal certification site, 
we have set up the revoked site and the expired site as follows, 
please confirm.
the revoked site: www3.gpki.go.jp
the expired site: www4.gpki.go.jp

Also, since CP / CPS of APCA2(Sub) was partially revised and attached 
to Bugzilla, already you know, please also check it.

Thank you

Comment 65

[Aaron Wu]

Hi,

Thanks to provide revised CP/CPS of APCA2(Sub) and test websites.

I am working on your updated CP/CPS. In the meanwhile, please kindly provide Valid test website, as you already provided Explored and Revoked ones above. (Please see the Comment#61 in detail)

Thanks,
Aaron

Comment 66

[apca]

Hi,

As you pointed out of Comment#61, in addition to the normal certification site, 
we have set up the revoked site and the expired site as follows, 
please confirm.
the Valid   site: www2.gpki.go.jp
the revoked site: www3.gpki.go.jp
the expired site: www4.gpki.go.jp

Thank you

Comment 67

[Aaron Wu]

Hi,

Thanks for your update!

Now I can not access these three test websites (as Comment#66) and get expected test result, could you kindly double check?

Thank you!

Kind Regards,
Aaron

Comment 68

[apca]

Hi

We are confirmed that we can access 3 test sites.
(i) valid
https://www2.gpki.go.jp/
(ii) revoked
https://www3.gpki.go.jp/
(iii) expired
https://www4.gpki.go.jp/

Thank you

Comment 69

[Aaron Wu]

(In reply to apca from comment #68)
> Hi
> 
> We are confirmed that we can access 3 test sites.
> (i) valid
> https://www2.gpki.go.jp/
> (ii) revoked
> https://www3.gpki.go.jp/
> (iii) expired
> https://www4.gpki.go.jp/
> 
> Thank you

Verified with test websites. Thanks!

By the way, could you provide up-to-date Standard/BR Audit Statements?

And could we know how do you meet the domain validation requirements in the BRs?


Kind Regards,
Aaron

Comment 70

[apca]

Hi,

> Verified with test websites. Thanks!

Thank you for confirmation!

> By the way, could you provide up-to-date Standard/BR Audit Statements?

Our latest report was provided in Comment54 attachment " WTBR_report(E).pdf ".

> And could we know how do you meet the domain validation requirements in the BRs?

We will verify that the owner of the domain name stated as the name (CN) of the server certificate is the Ministry of Councilors or the like responsible for the LRA or its related organization by means of a database (WHOIS etc.) provided by a third party organization confirm.

In addition, we contact the approver of the submitted application and confirm that he/she is the domain administrator.
Approver is the head (manager/administrator) of the organization (department) to which the applicant belongs.


Since there are no confirmation matters anymore, please resume open discussion.

Thank you.

Comment 71

[Kathleen Wilson]

I just looked at the attached BR Self Assessment, and saw that for the Domain Validation it says: 

"Described in the subordinate document"

What does that mean?
Which document is that?

Domain validation is very important, and the CA must take ownership for ensuring that Domain Validation is always performed in a way that satisfies Mozilla's requirements. And this must be documented in a public-facing document.

See item #3 in
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#validation-practices

and see
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#cps-and-cpses

Comment 72

[apca]

We will consider adding domain authentication methods to CP / CPS.
If you have other comments, we would like to consider them together.
Are there any other comments besides domain authentication?

Comment 73

[apca]

Attachment: GPKI_APCA2Sub_CPCPS_English.pdf

The matter you pointed out was added to CP / CPS and stated. Please check.

Comment 74

[Wayne Thayer]

I've reviewed the updated sub-CA CPS and found the domain validation methods documented in section 4.1.2

I was not able to find a current WebTrust for CAs audit report. The report located at https://cert.webtrust.org/SealFile?seal=2172&file=pdf appears to be dated 2016 (Heisei 28) Please provide a translated copy of a current WebTrust for CAs audit report.

Meanwhile, I will go ahead and move this back to 'in discussion' and will post my comments on the CPS to https://groups.google.com/forum/#!forum/mozilla.dev.security.policy Please respond to my comments there.

Comment 75

[apca]

Attachment: GPKI_APCA2Root_CPCPS_English.pdf

Thank you for pointing out for "Good".
As for the point of "Meh", we will examine the contents.
  "Sterling committee" has been changed to "steering committee".
Regarding the indication of "Bad", we will answer as follows.

We have set up CP / CPS version number assignment rules. Based on this, at present CP / CPS Root version is Ver. 1.05 and CP / CPS Sub version is 1.07. We will attach CP / CPS with version number.

Coincidentally, since the audit result formal report was issued from the auditor today (Dec.22), we will attach it. .

In addition to this post, we will post two additional files with each additional post.

Thank you.

Comment 76

[apca]

Attachment: GPKI_APCA2Sub_CPCPS_English.pdf

Comment 77

[apca]

Attachment: WTBR.pdf

Comment 78

[Wayne Thayer]

(In reply to apca from comment #77)
> Created attachment 8938600 [details]
> WTBR.pdf

Thank you for providing a translation of the most recent "SSL Baseline Requirements with Network Security" audit report.

Mozilla policy section 3.1.2.1 requires two audits:
* WebTrust for CAs
* WebTrust for CAs - SSL Baseline with Network Security

The report you provided only references the second audit. Typically two separate reports are provided, one for each audit. Do you have a current "WebTrust for CAs" audit (http://www.webtrust.org/principles-and-criteria/docs/item85228.pdf)? If so, please provide the auditor's report.

Comment 79

[apca]

Attachment: WTCA.pdf

We will attach the audit result on WebTrust for Cas you requested.
Please check this

Comment 80

[Wayne Thayer]

Thank you, this is the audit report I was looking for. I now need to verify these audit reports with Ernst & Young. Can you provide an email address for Masami Asuma?

Comment 81

[apca]

We contacted the auditing company to which Masami Asuma belongs, but the auditing company says they will not accept individual questions, and also cannot open Masami Asuma address.
What do you want to know from Masami Asuma? 
If what you want to know is what we can handle, we will answer.

Comment 82

[Wayne Thayer]

I am looking for a confirmation directly from Enst & Young that they have issued these audit reports. Are the reports posted on the webtrust.org website? If so, please provide a link. If not, is there a general Ernst & Young email address that I can use to ask them to confirm that they did indeed issue these reports?

Comment 83

[apca]

As the auditing company (Ernst & Young Shinnihon) has been requesting the issuance of seals that link the audit results on the WebTrust.org. As soon as they are issued, we will get the link addresses from the auditing company. And we will provide that information to you as soon as they are received.

Comment 84

[Firefox Bug Husbandry Bot]

Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324

Comment 85

[apca]

Since the audit reports were posted on WebTrust's website as follows, we will report those URLs.

WebTrust: https://cert.webtrust.org/ViewSeal?id=2385

SSLBR: https://cert.webtrust.org/ViewSeal?id=2386

Thank you

Comment 86

[apca]

We have already reported that the audit results has been posted on webtrust.org, and the URLs posted on it have already been reported.
With the comments we received earlier, we have already responded for "Bad".
Regarding "Meh", we have dealt with what we can do.
Also, since that time, we have not received any comments.
Based on the above, we would like you to finish the open discussion at the latest within this February.
Thank you.

Comment 87

[Wayne Thayer]

Thank you. I have verified these audit reports.

Please respond to the email I sent to the mozilla.dev.security.policy forum with your answer to each of my "Meh" and "Bad" comments. Please send your response to [e-mail]. Once your responses are posted, I will respond, either by requesting that you provide more information or update your CPS, or by setting a date for the discussion to finish.

Comment 88

[apca]

Just to be sure, content posted on mozilla.dev.security.policy I will post it to Bugzilla. Please check.

---------
Below is the answer to the pointed out earlier.

== Bad ==
* CPS docs are not assigned a version number (Mozilla policy 3.3)

We had set up CP / CPS version number assignment rules. Based on this, at present CP / CPS Root version is Ver. 1.05 and CP / CPS Sub version is 1.07. We attached CP / CPS with version number.


* I can’t find a current WebTrust for CAs audit statement - I've requested a translated copy in the bug. There may be confusion over the fact that two audits are required.

Since the audit reports were posted on WebTrust's website as follows, we will report those URLs.
WebTrust: https://cert.webtrust.org/ViewSeal?id=2385
SSLBR: https://cert.webtrust.org/ViewSeal?id=2386


* The translated WebTrust BR audit report does not include all the information required by Mozilla policy 3.1.4. Based on information in the bug I believe this meant to be a period-of-time audit, but it looks like a point-in time readiness audit.

(Same as the above answer）
Since the audit reports were posted on WebTrust's website as follows, we will report those URLs.
WebTrust: https://cert.webtrust.org/ViewSeal?id=2385
SSLBR: https://cert.webtrust.org/ViewSeal?id=2386


== Meh ==
* Full name of the BRs is cut off in section 1: “CA/Browser  Forum, Baseline Requirements for the Issuance and Management of Publicly.”

At the next revision, we will modify the corresponding part of CP / CPS section 1 of application CA 2 (Root) and application CA 2 (Sub) as follows. 
Application CA 2 (Root / Sub) conforms to the Baseline Requirements of CA / Browser Forum published at https://www.cabforum.org/.


* Revision history doesn’t state what was changed (Mozilla policy 3.3 requires a “dated changelog” but doesn’t explicitly require a description of changes to be included)

At the next revision, we will add a change history of application CA 2 (Root) and application CA 2 (Sub).


* Neither the CPS or the BR Self Assessment explain how GPKI identifies high-risk certificate requests

We have confirmed that the subjects of the server certificates are limited to "go.jp" and that those are the web servers managed by the government. In addition, we check the case of phishing on the websites such as the Council of Anti-Phishing Japan etc. and refer them to the examination work.


* There are separate CPS’s for the root and it’s subordinate CA. Some of the required information (CAA, domain validation methods) is only contained in the sub CA’s CPS.

Confirmation of CAA records, verification of domains, etc. are performed in the operation of application CA 2 (Sub), since it is being carried out in the application, not application CA 2 (Root), but application CA 2 (Sub).


* The CPS doesn’t contain an explicit open-source license statement as encouraged by Mozilla policy 3.3(3)

The CP / CPS document created by us has no special restrictions.


* A minimal description of the methods used by the CA to perform domain authorization was added to section 4.1.2. How is method 3.2.2.4.1 used? I don’t think enough information is provided to comply with Mozilla policy 2. 2(3) that states “The CA's CP/CPS must clearly specify the procedure(s) that the CA employs”. However, the fact that this CA will be name constrained to go.jp reduces my concern over this.

We are confirmed in the WHOIS database of Japan Registry Service that it matches domain owner. If it does not match, I will email the owner of the domain and check if this application is acceptable. Because we are also applicants of the government, we can operate it without problem with this method.


* There are references to the “sterling committee” in the CPS. I believe this is meant to translate to “steering committee”.

We have modified it with CP / CPS Root version Ver. 1.05 and CP / CPS Sub version 1.07.
-----

Thank you
APCA

Comment 89

[apca]

We posted answers to 'dev-security-policy', but we received the following e-mail and it is a situation that it can not be posted according to its contents.
We also posted the same content to Bugzilla, so please confirm with that.

---Recived e-mail---
Your mail to 'dev-security-policy' with the subject

    Re: Japan GPKI Root Renewal Request

Is being held until the list moderator can review it for approval.

The reason it is being held:

    Post by non-member to a members-only list

Either the message will get posted to the list, or you will receive notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:

    https://lists.mozilla.org/confirm/dev-security-policy/885de841305c6d935a65cbb7f5637e702e93807d
------

Thank you
APCA

Comment 90

[Wayne Thayer]

APCA: Are you now able to post messages to 'dev-security-policy'? Would you like to respond to the messages that Ryan and I posted to the list before I end the discussion?

Comment 91

[apca]

Also we post the same contents here as those posted to mozilla.dev.security.policy.

We are a certificate authority controlled by the Government of Japan and issued only for servers operated by the government.

For certificates that you point out concerning, they will expire and will be reissued, so we think that the problem will be solved.

We will continue to take BR audits in the future so we will operate as a secure certification authority and we appreciate your continued support.

Thank you
APCA

Comment 92

[Wayne Thayer]

As discussed [1], the request to include the Japanese Government ApplicationCA2 Root has been denied.

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/Mezqdljjerc/YjPZYFsxAQAJ

Comment 93

[apca]

Also we post the same contents here as those posted to mozilla.dev.security.policy.

"I would like to again point out that simply waiting for misissued certificates to expire is not an acceptable response."

This is a misunderstanding.
We are preparing to revoke certificates immediately, rather than waiting for certificates issued prior to 2017 to expire.
However, even if we revoke those certificates, if your judgment is not affected and our request is rejected, there is no point in doing it.
Please let us know if our request will be accepted by revoking all the certificates we issued prior to 2017.

THank you
APCA

Comment 94

[Wayne Thayer]

My comment was intended to point out that you are violating BR section 4.9.1.1(9) by not revoking these certificates. My comments were not intended to imply that revoking these certificates would change Mozilla's decision to deny this inclusion request.