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

Japan GPKI Root Renewal Request

6,788 views
Skip to first unread message

Kathleen Wilson

unread,
Apr 27, 2016, 5:25:08 PM4/27/16
to mozilla-dev-s...@lists.mozilla.org
This request by the Government of Japan, Ministry of Internal Affairs and Communications, is to include the GPKI 'ApplicationCA2 Root' certificate and enable the Websites trust bit. This new root certificate has been created in order to comply with the Baseline Requirements, and will eventually replace the 'ApplicationCA - Japanese Government' root certificate that was included via Bugzilla Bug #474706. Note that their currently-included root certificate expires in 2017, and will be removed via Bugzilla Bug #1268219.

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

And in the pending certificates list:
https://wiki.mozilla.org/CA:PendingCAs

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8673399

Noteworthy points:

* The primary documents are the Root and SubCA CP/CPS, provided in Japanese and English.

Document Repository (Japanese):
http://www.gpki.go.jp/apca/cpcps/index.html
Document Repository (English):
https://www2.gpki.go.jp/apca2/apca2_eng.html
Root CP/CPS:
https://www2.gpki.go.jp/apca2/cpcps/cpcps_root_eng.pdf
SubCA CP/CPS:
https://www2.gpki.go.jp/apca2/cpcps/cpcps_sub_eng.pdf

* CA Hierarchy: This root certificate has one internally-operated subordinate CA that issues end-entity certificates for SSL and code signing.

* This request is to turn on the Websites trust bit.

SubCA CP/CPS section 3.2.2, Authentication of organization identity
As for the application procedure of a server certificate, ... the LRA shall verify the authenticity of the organization to which the subscriber belongs according to comparing with organizations which were written in the application by directory of government officials that the Independent Administrative Agency National Printing Bureau issued.

SubCA CP/CPS section 3.2.3, Authentication of individual identity
As for the application procedure of a server certificate, ... the LRA shall verify the authenticity of the subscriber according to comparing with name, contact, etc. which were written in the application by directory of government officials that the Independent Administrative Agency National Printing Bureau issued.
The LRA also check the intention of an application by a telephone or meeting.

SubCA CP/CPS section 4.1.2, Enrollment process and responsibilities
(1) Server certificate
The subscriber shall apply accurate information on their certificate applications to the LRA.
The LRA shall confirm that the owner of the domain name written as a name(cn) of a server certificate in the application form belongs to Ministries and Agencies who have jurisdiction over LRA, or its related organization with the thirdparty databases and apply accurate information to the Application CA2(Sub).

* Mozilla Applied Constraints: This CA has indicated that the CA hierarchy may be constrained to the *.go.jp domain.

* Root Certificate Download URL:
https://bugzilla.mozilla.org/attachment.cgi?id=8673392
https://www.gpki.go.jp/apca2/APCA2Root.der

* EV Policy OID: Not requesting EV treatment

* Test Website:
https://www2.gpki.go.jp/apca2/apca2_eng.html

* CRL URLs:
http://dir.gpki.go.jp/ApplicationCA.crl
http://dir2.gpki.go.jp/ApplicationCA2Root.crl
http://dir2.gpki.go.jp/ApplicationCA2Sub.crl
SubCA CPS section 4.9.7: The CRL of 48-hour validity period is issued at intervals of 24 hours.

* OCSP URL:
http://ocsp-sub.gpki.go.jp
http://ocsp-root.gpki.go.jp

* Audit: Annual audits are performed by KPMG AZSA LLC according to the WebTrust criteria.
WebTrust Audit (Japanese and English in same document):
https://cert.webtrust.org/SealFile?seal=1793&file=pdf
BR Readiness Assessment: https://bugzilla.mozilla.org/attachment.cgi?id=8667814
Response to Audit Findings: https://bugzilla.mozilla.org/attachment.cgi?id=8667815
We will improve the issues that was pointed out in the pre-audit and submit the investigation report by September 2016.

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

This begins the discussion of the request from the Government of Japan to include the GPKI 'ApplicationCA2 Root' certificate and enable the Websites trust bit.

Please review this CA's request and provide feedback now, so that this CA may address any concerns while awaiting the results of their investigation report that is expected to show that the issues found during their BR audit have been addressed. A decision about inclusion will wait until after the investigation report has been provided.

Kathleen

Kathleen Wilson

unread,
May 20, 2016, 6:33:56 PM5/20/16
to mozilla-dev-s...@lists.mozilla.org
Does anyone have questions, concerns, or feedback on this request from the Government of Japan, Ministry of Internal Affairs and Communications, to include the GPKI 'ApplicationCA2 Root' certificate and enable the Websites trust bit?

Kathleen


Kathleen Wilson

unread,
Jul 20, 2016, 7:58:34 PM7/20/16
to mozilla-dev-s...@lists.mozilla.org
On Friday, May 20, 2016 at 3:33:56 PM UTC-7, Kathleen Wilson wrote:
> Does anyone have questions, concerns, or feedback on this request from the Government of Japan, Ministry of Internal Affairs and Communications, to include the GPKI 'ApplicationCA2 Root' certificate and enable the Websites trust bit?
>
> Kathleen

I will greatly appreciate it if someone will review and comment on this request.

As always, I appreciate your thoughtful and constructive feedback.

Kathleen

Eric Mill

unread,
Jul 20, 2016, 9:15:54 PM7/20/16
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
For some reason, Gmail split up this thread into two for me. In case anyone
else is having similar issues, here's the original detail for this request:

On Wed, Apr 27, 2016 at 4:56 PM, Kathleen Wilson <kwi...@mozilla.com>
wrote:
> This begins the discussion of the request from the Government of Japan to
> include the GPKI 'ApplicationCA2 Root' certificate and enable the Websites
> trust bit.
>
> Please review this CA's request and provide feedback now, so that this CA
> may address any concerns while awaiting the results of their investigation
> report that is expected to show that the issues found during their BR audit
> have been addressed. A decision about inclusion will wait until after the
> investigation report has been provided.
>
> Kathleen
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

On Wed, Jul 20, 2016 at 7:58 PM, Kathleen Wilson <kwi...@mozilla.com>
wrote:

> On Friday, May 20, 2016 at 3:33:56 PM UTC-7, Kathleen Wilson wrote:
> I will greatly appreciate it if someone will review and comment on this
> request.
>
> As always, I appreciate your thoughtful and constructive feedback.
>
> Kathleen
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

Peter Kurrasch

unread,
Aug 5, 2016, 8:39:39 AM8/5/16
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
Kathleen--

As I understand it, the request is for only CA2(Root) to be included in the trust store. Is that correct? 

The CP/CPS document submitted for the CA2(Root) hardly seems sufficient to satisfy anyone for one simple reason: there is no detail! I'm surprised the auditors (KPMG in this case) found this to be acceptable. If the CA2(Sub) ‎is not to be included in the Mozilla trust store then I don't see how it's CP/CPS can be reviewed for consideration here.

My recommendation is to reject this request and ask that the root's documentation be rewritten to reflect the policies and procedures that apply to all certs that chain to this root.


From: Eric Mill
Sent: Wednesday, July 20, 2016 8:15 PM‎

For some reason, Gmail split up this thread into two for me. In case anyone
else is having similar issues, here's the original detail for this request:

On Wed, Apr 27, 2016 at 4:56 PM, Kathleen Wilson <kwi...@mozilla.com>
wrote:

> This request by the Government of Japan, Ministry of Internal Affairs and
> Communications, is to include the GPKI 'ApplicationCA2 Root' certificate
> This begins the discussion of the request from the Government of Japan to

> include the GPKI 'ApplicationCA2 Root' certificate and enable the Websites
> trust bit.
>
> Please review this CA's request and provide feedback now, so that this CA
> may address any concerns while awaiting the results of their investigation
> report that is expected to show that the issues found during their BR audit
> have been addressed. A decision about inclusion will wait until after the
> investigation report has been provided.
>
> Kathleen
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

On Wed, Jul 20, 2016 at 7:58 PM, Kathleen Wilson <kwi...@mozilla.com>
wrote:

> On Friday, May 20, 2016 at 3:33:56 PM UTC-7, Kathleen Wilson wrote:
> I will greatly appreciate it if someone will review and comment on this
> request.
>
> As always, I appreciate your thoughtful and constructive feedback.
>
> Kathleen
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

Andrew R. Whalley

unread,
Aug 10, 2016, 6:20:16 PM8/10/16
to Peter Kurrasch, mozilla-dev-s...@lists.mozilla.org, Kathleen Wilson
On Fri, Aug 5, 2016 at 5:39 AM, Peter Kurrasch <fhw...@gmail.com> wrote:

> Kathleen--
>
> As I understand it, the request is for only CA2(Root) to be included in
> the trust store. Is that correct?
>
> The CP/CPS document submitted for the CA2(Root) hardly seems sufficient to
> satisfy anyone for one simple reason: there is no detail! I'm surprised the
> auditors (KPMG in this case) found this to be acceptable. If the CA2(Sub)
> ‎is not to be included in the Mozilla trust store then I don't see how it's
> CP/CPS can be reviewed for consideration here.
>

I've been mulling over this too. While it does say it complies with the
BRs and they take priority, it is indeed very under specified.

I would refer the Government of Japan, Ministry of Internal Affairs and
Communications to the Amazon Trust Services CP/CPS as an example of how to
adhere closely to the BRs while still providing sufficient detail.

Andrew


> My recommendation is to reject this request and ask that the root's
> documentation be rewritten to reflect the policies and procedures that
> apply to all certs that chain to this root.
>
>
> *From: *Eric Mill
> *Sent: *Wednesday, July 20, 2016 8:15 PM‎
>
> For some reason, Gmail split up this thread into two for me. In case anyone
> else is having similar issues, here's the original detail for this request:
>
> On Wed, Apr 27, 2016 at 4:56 PM, Kathleen Wilson <kwi...@mozilla.com>
> wrote:
>
> > This begins the discussion of the request from the Government of Japan to
> > include the GPKI 'ApplicationCA2 Root' certificate and enable the
> Websites
> > trust bit.
> >
> > Please review this CA's request and provide feedback now, so that this CA
> > may address any concerns while awaiting the results of their
> investigation
> > report that is expected to show that the issues found during their BR
> audit
> > have been addressed. A decision about inclusion will wait until after the
> > investigation report has been provided.
> >
> > Kathleen
> >
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
>
>
>
> --
> konklone.com | @konklone <https://twitter.com/konklone>
>
> On Wed, Jul 20, 2016 at 7:58 PM, Kathleen Wilson <kwi...@mozilla.com>
> wrote:
>
> > On Friday, May 20, 2016 at 3:33:56 PM UTC-7, Kathleen Wilson wrote:
> > I will greatly appreciate it if someone will review and comment on this
> > request.
> >
> > As always, I appreciate your thoughtful and constructive feedback.
> >
> > Kathleen
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
>
>
>
> --
> konklone.com | @konklone <https://twitter.com/konklone>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Kathleen Wilson

unread,
Aug 25, 2016, 4:07:05 PM8/25/16
to mozilla-dev-s...@lists.mozilla.org
> This request by the Government of Japan, Ministry of Internal
> Affairs and Communications, is to include the GPKI 'ApplicationCA2 Root'
> certificate and enable the Websites trust bit. This new root certificate
> has been created in order to comply with the Baseline Requirements, and
> will eventually replace the 'ApplicationCA - Japanese Government' root
> certificate that was included via Bugzilla Bug #474706. Note that their
> currently-included root certificate expires in 2017, and will be removed
> via Bugzilla Bug #1268219.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=870185

Thank you to those of you who reviewed and commented on this request from Japan GPKI to include the GPKI 'ApplicationCA2 Root' certificate and enable the Websites trust bit.

This 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

Thanks,
Kathleen

wth...@mozilla.com

unread,
Dec 21, 2017, 4:38:14 PM12/21/17
to mozilla-dev-s...@lists.mozilla.org
GPKI recently provided an updated CPS and also has provided a BR audit statement. I've reviewed the information provided and have the following comments:

== Good ==
* GPKI is requesting a name constraint to go.jp
* Section 1 states that the BRs take precedence over the CPS
* Problem reporting information is published at http://www.gpki.go.jp/apca2/index.html

== Meh ==
* Full name of the BRs is cut off in section 1: “CA/Browser Forum, Baseline
Requirements for the Issuance and Management of Publicly.”
* 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)
* Neither the CPS or the BR Self Assessment explain how GPKI identifies high-risk certificate requests
* 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.
* The CPS doesn’t contain an explicit open-source license statement as encouraged by Mozilla policy 3.3(3)
* 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.
* There are references to the “sterling committee” in the CPS. I believe this is meant to translate to “steering committee”.

== Bad ==
* CPS docs are not assigned a version number (Mozilla policy 3.3)
* 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.
* 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.

Wayne

apca2...@gmail.com

unread,
Feb 6, 2018, 12:39:34 PM2/6/18
to mozilla-dev-s...@lists.mozilla.org
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



2017年12月22日金曜日 6時38分14秒 UTC+9 wth...@mozilla.com:

Wayne Thayer

unread,
Feb 12, 2018, 6:31:43 PM2/12/18
to apca2...@gmail.com, mozilla-dev-security-policy
All of my questions regarding the CP/CPS and audits have been answered to
my satisfaction. I am left with two concerns:

1. This root was signed on 12-March 2013. The first end-entity certificate
that I'm aware of was signed later in 2013. Mozilla began requiring BR
audits in 2014, but the first BR assessment for this root was on
30-September 2015. [1] The assessment shows 22 issues. [2] A PITRA was
finally performed on January 31, 2017 [3] and no qualifications were noted.
This was followed by a clean period-of-time audit. It is clear that
hundreds of certificates were issued in this certificate hierarchy while it
was not BR compliant, some of which have not yet expired.

2. A number of misissued certificates under this hierarchy have been logged
[4], some of which are still valid. Some of these contain significant
compatibility problems such as the lack of a SAN and the lack of an OCSP
URL. The good news is that all of the bad certificates were issued prior to
2017.

At a minimum, the unexpired misissued certificates should be revoked, just
as has been done by other CAs in the Mozilla program. However, given the
demonstrated lack of BR compliance from 2013-2016, we should consider
rejecting this request and requiring that a new root using a new key pair
be generated and submitted for inclusion.

Please be aware that trust in this root will be constrained to .go.jp
domains, significantly reducing the risk it presents to Mozilla users.

I would appreciate everyone's constructive feedback on these issues, and
any others that are relevant to this inclusion request.

- Wayne

[1] https://bug870185.bmoattachments.org/attachment.cgi?id=8667814
[2] https://bug870185.bmoattachments.org/attachment.cgi?id=8667815
[3] https://bug870185.bmoattachments.org/attachment.cgi?id=8852738
[4]
https://crt.sh/?caid=1419&opt=cablint,zlint,x509lint&minNotBefore=2013-01-01

On Mon, Feb 5, 2018 at 10:05 PM, apca2.2013--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> 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
>
>
>
> 2017年12月22日金曜日 6時38分14秒 UTC+9 wth...@mozilla.com:

Ryan Sleevi

unread,
Feb 13, 2018, 10:43:43 PM2/13/18
to Wayne Thayer, apca2...@gmail.com, mozilla-dev-security-policy
On Mon, Feb 12, 2018 at 6:31 PM Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> All of my questions regarding the CP/CPS and audits have been answered to
> my satisfaction. I am left with two concerns:
>
> 1. This root was signed on 12-March 2013. The first end-entity certificate
> that I'm aware of was signed later in 2013. Mozilla began requiring BR
> audits in 2014, but the first BR assessment for this root was on
> 30-September 2015. [1] The assessment shows 22 issues. [2] A PITRA was
> finally performed on January 31, 2017 [3] and no qualifications were noted.
> This was followed by a clean period-of-time audit. It is clear that
> hundreds of certificates were issued in this certificate hierarchy while it
> was not BR compliant, some of which have not yet expired.
>
> 2. A number of misissued certificates under this hierarchy have been logged
> [4], some of which are still valid. Some of these contain significant
> compatibility problems such as the lack of a SAN and the lack of an OCSP
> URL. The good news is that all of the bad certificates were issued prior to
> 2017.
>
> At a minimum, the unexpired misissued certificates should be revoked, just
> as has been done by other CAs in the Mozilla program. However, given the
> demonstrated lack of BR compliance from 2013-2016, we should consider
> rejecting this request and requiring that a new root using a new key pair
> be generated and submitted for inclusion.


Given the situations with the audits - which effectively prevent the
community from having any assurances of its operation from 2013 until 2017
- I wholly support rejecting the request to include this root.

To avoid ambiguity, I mean rejecting the request completely, and requiring
that any future request for inclusion be done as a new request, with new
key material, and with unblemished audits, as it would any other new CA.

Despite the proposed set of constraints, I do not think it is in the
interests of the Internet community to knowingly support some domains being
intentionally “less secure” than others, which is what the effect of the
proposed constraints would mean.


>
> Please be aware that trust in this root will be constrained to .go.jp
> domains, significantly reducing the risk it presents to Mozilla users.
>
> I would appreciate everyone's constructive feedback on these issues, and
> any others that are relevant to this inclusion request.
>
> - Wayne
>
> [1] https://bug870185.bmoattachments.org/attachment.cgi?id=8667814
> [2] https://bug870185.bmoattachments.org/attachment.cgi?id=8667815
> [3] https://bug870185.bmoattachments.org/attachment.cgi?id=8852738
> [4]
>
> https://crt.sh/?caid=1419&opt=cablint,zlint,x509lint&minNotBefore=2013-01-01
>
> On Mon, Feb 5, 2018 at 10:05 PM, apca2.2013--- via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > 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
> >
> >
> >
> > 2017年12月22日金曜日 6時38分14秒 UTC+9 wth...@mozilla.com:

apca2...@gmail.com

unread,
Feb 23, 2018, 1:57:38 AM2/23/18
to mozilla-dev-s...@lists.mozilla.org
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.

Wayne Thayer

unread,
Feb 27, 2018, 5:51:23 PM2/27/18
to gpki apca, mozilla-dev-security-policy
To conclude this discussion, Mozilla is denying the Japanese Government
ApplicationCA2 Root inclusion request. I'd like to thank everyone for your
constructive input into the discussion, and I'd like to thank the Japanese
Government representatives for their patience and work to address issues as
they have been discovered. I will be resolving the bug as "WONTFIX".

The Japanese Government PKI may submit a newly generated root and key-pair
for inclusion, and this submission can be made using the existing bug (
https://bugzilla.mozilla.org/show_bug.cgi?id=870185).

On Thu, Feb 22, 2018 at 11:57 PM, apca2.2013--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> 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.
>
> I would like to again point out that simply waiting for misissued
certificates to expire is not an acceptable response.


> 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.
>
> - Wayne

apca2...@gmail.com

unread,
Feb 28, 2018, 12:58:50 AM2/28/18
to mozilla-dev-s...@lists.mozilla.org
"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


2018年2月28日水曜日 7時51分23秒 UTC+9 Wayne Thayer:

Eric Mill

unread,
Feb 28, 2018, 11:15:06 AM2/28/18
to apca2...@gmail.com, mozilla-dev-s...@lists.mozilla.org
On Wed, Feb 28, 2018 at 12:58 AM, apca2.2013--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> "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.
>

So, to be clear, you would only revoke misissued certificates if required
to do so by Mozilla -- not because they represent control failures, or in
order to demonstrate to other root programs your CA's responsiveness and
the seriousness with which you take control failures.


> Please let us know if our request will be accepted by revoking all the
> certificates we issued prior to 2017.


> Thank you
> APCA
>
>
> 2018年2月28日水曜日 7時51分23秒 UTC+9 Wayne Thayer:
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



Wayne Thayer

unread,
Feb 28, 2018, 11:26:58 AM2/28/18
to Eric Mill, gpki apca, mozilla-dev-s...@lists.mozilla.org
On Wed, Feb 28, 2018 at 9:13 AM, Eric Mill via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Wed, Feb 28, 2018 at 12:58 AM, apca2.2013--- via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > "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.
> >
>
> So, to be clear, you would only revoke misissued certificates if required
> to do so by Mozilla -- not because they represent control failures, or in
> order to demonstrate to other root programs your CA's responsiveness and
> the seriousness with which you take control failures.
>
>
> > Please let us know if our request will be accepted by revoking all the
> > certificates we issued prior to 2017.
>
> 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.

>
> > Thank you
> > APCA
> >
>
0 new messages