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-security-policy@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: > > On Thursday, August 25, 2016 at 8:07:05 PM UTC, Kathleen Wilson wrote: > > > > 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 > > > > 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 > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
