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
