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.
> > == 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.
> >
> > * 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
> > == 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: