2015年8月26日水曜日 4時29分37秒 UTC+9 Ryan Sleevi: > On Wed, August 5, 2015 2:51 pm, Kathleen Wilson wrote: > > SECOM has applied to enable EV treatment for the "Security Communication > > RootCA2" root certificate that was included in NSS via Bugzilla Bug > > #527419. > > > > SECOM is a Japanese commercial CA that provides SSL and client > > certificates for e-Government and participates in several projects for > > financial institutions to ensure the secured on-line transactions. > > This begins the discussion of the request from SECOM to enable EV > > treatment for the "Security Communication RootCA2" root certificate that > > is currently included in NSS. > > > > At the conclusion of this discussion I will provide a summary of issues > > noted and action items. If there are outstanding issues, then an > > additional discussion may be needed as follow-up. If there are no > > outstanding issues, then I will recommend approval of this request in > > the bug. > > Hi Kathleen, > > I've attempted to separately review this inclusion request and examine the > CP and CPS. > > Overall, this was the most difficult review, given the lack of > availability of the policy documentation in English. While I attempted to > use Google Translate for most of it, I think it may be noteworthy to > consider requiring CAs to provide translated versions of their documents > in a future update of the Mozilla inclusion policy. > > The most recent audit information for SECOM that I can find is not the > 1717 seal you indicated, but Seal #1907, > https://cert.webtrust.org/SealFile?seal=1907&file=pdf > > In examining that seal, we see that there are a variety of CP/CPSes > provided as part of in scope for the audit. Relevant to this discussion, > it appears, is the "Security Communications Root CA2 Certification > Practice Statement" [1], the "Security Communications Root CA2 CA > Certificate Policy" [2], and the "SECOM Passport for Web EV 2.0 CA" CP [3] > and [4]. > > Given that the SECOM Root CA2 is already included in Mozilla's Root > Program, I attempted to focus my efforts on reviewing documents [3] and > [4], as they were deemed most relevant for EV enablement. > > While there are a several positive things noted within the CP/CPS, > overall, I'm concerned about the lack of information provided that makes > it difficult to impossible for the community to reliably inspect SECOM's > conformance to the relative policies, and leaves ambiguity with respect to > Mozilla's own ability to ensure that SECOM is operating in the public > interest. > > Given that [3] largely defers to [4] for most sections, I will focus my > primary comments on [4], and then circle back. > > https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf > > Good things: > - Section 1.5.2 provides contact information for the public in the event > of the need to revoke a certificate immediately. This is quite useful for > relying parties and members of the public to raise concern, and many CAs > make this difficult to find. > - Section 7.1 provides an exhaustive list of the certificate profile, > fields, and values. This sort of documentation is what ideally all members > of the Mozilla Root Store would provide, and provides ways for the public > to detect non-conformance to the profile specified. > > Mixed things: > - While Section 4.1 indicates that SECOM will examine CAA records, as > required by version 1.2.0 of the Baseline Requirements (as adopted by > Ballot 125), SECOM does not list which CAA records it will process or what > it would do if they mismatch. This may be seen as an incomplete adherence > to the Baseline Requirements, but I would rather see it as a reasonable > confusion related to expectations. An ideal resolution for this would be > for SECOM to indicate what CAA records it will expect to find (if CAA is > present) in order to issue, and what SECOM's process and procedures will > be for CAA records that fail to meet that (e.g. to deny the request, to > treat it as a High-Value request, to require some form of extended > validation, to allow a notarized letter on company letterhead to override, > etc) > > Bad things: > - Section 2.2 of the CP fails to provide information in the repository for > testing certificates issued by these roots. While SECOM's audit was > conducted against the WebTrust SSL BRs 1.1 (themselves based on the CA/B > Forum's SSL BRs 1.1), this was required in Appendix C (normatively) of the > BRs, and has been incorporated in Section 2.2 of the BRs 1.3.0 (providing > a model policy for CAs to adopt). I consider this a major issue of > non-conformance, although it may be remediated relatively easily. > - Section 3.2.2 fails to comprehensively explain how domain name > validation works. This is unquestionably the most important part of a CAs > operation, and I had difficulty finding any such information provided in > any of the attested-to documents by the auditors. While Auditors are, > unfortunately, not required to examine the CP/CPS of CAs for conformance > to the BRs, this makes it difficult for the public to independently > verify. > > Your own efforts in the tracking bug appear to have lead to documents > [5] and [6], which were translated in brief in your original email. > However, I could not find any reference to these documents being > incorporated into the CP/CPS. This is quite concerning, because changes > may be made to these documents inconsistent with respect to the > requirements of [7], notably that CAs update Mozilla when policies and > business practices change. It also suggests that these documents may be > exempted from the change control procedures required by the Baseline > Requirements. > > To me personally, this represents a significant risk to the community, > and thus represents a major issue. Remediation for this should be to > comprehensively document the name validation and issuance verification > steps within the CA's CP/CPS, without reference to external > documentation, so that it may be validated by members of the public and > so that expectations regarding changes are clear. We've already seen one > CA be confused by such expectations (CNNIC, with respect to issuing > subordinate CAs), and I would be loathe to see another. This will > require a CP/CPS update, and I believe it's best to defer acceptance > until that's been completed and reviewed again during a public comment > period. > - Section 4.4.3 would potentially prohibit SECOM from publishing > information about certificates they issue using Certificate Transparency, > although I applaud them for clarifying in [3] that all information > presented in certificates is treated as non-confidential. I consider this > a minor issue worth noting, but not requiring remediation. > - Section 4.9.7 fails to clearly document the frequency of OCSP > publications or of the validity periods of the OCSP responses. I consider > this a major issue, but which may be easily remediated. > - Section 6.1.7 indicates the keyEncipherment usage, but that may be > inconsistent with the usage of EC keys. This is likely a minor issue, and > easily remediated, but may highlight some confusion on SECOM's part about > RFC 5280. > - Section 7.1.1 is somewhat inconsistent with respect to the SHA-1 > signatures. While the other policy documentation indicates support for > SHA-2 signatures, it would seem non-conforming to their stated policies > for them to issue such certificates. I consider this a major issue that > the auditor should have flagged (as to inconsistent documentation). > - Section 7.3 fails to document an OCSP profile, as required. Other > documentation refers back to this section, so it's clearly insufficient. > > > https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CPS.pdf > > Good things: > - As noted before, the CPS notes that the information contained within a > certificate is non-confidential, which is a positive step for CAs to note. > > Bad things: > - The CPS was last updated in 2012. This suggests that SECOM may not be > following the changes in the Baseline Requirements. There is also > ambiguity with respect to the expectations of the BRs and annual > publications of such documents, and whether or not annual updates are > required. > > > Overall, I'm quite concerned about the inability to find (public) > documentation as to the practices of this CA. I recognize that the > information gathering process can be difficult, especially when language > barriers exist, but this also makes it difficult for members of the public > to independently evaluate the trustworthiness and conformance to Mozilla's > policies. > > The inconsistencies within the documents, and the absence of information, > also represents a concern. While I can understand that the WebTrust Audit > Criteria do not require an auditor to independently examine the CP/CPS > (unfortunately), this does raise concern about the thoroughness and > attentiveness of the audit. > > I would like to recommend that the inclusion request be deferred until > sufficient information is incorporated into the CP and CPS, as Mozilla has > demonstrated in the past the expectation of CAs to adhere to those stated > policies (c.f. CNNIC) and has documented requirements related to the > update, notification, and change of those policies (c.f. [7]). After > completing their updated documentation, I think it's reasonable to have > another public review phase related to these updates. > > For SECOM's benefit, it may help to examine the CA/Browser Forum SSL > Baseline Requirements 1.3.0 [8], which provides a model RFC > 3647-compatible enumeration of the Baseline Requirements expectations. By > examining their CP/CPS in this light, it would assist SECOM's management > that they have implemented and documented conformance to the SSL Baseline > Requirements. > > While I would not request a new audit to the updated policies, I also > think it would be important to ensure that the next audit (eta June 2016) > would ensure SECOM's adherance to the updated policies. > > > [1] https://repository.secomtrust.net/SC-Root/SCRootCPS.pdf > [2] https://repository.secomtrust.net/SC-Root/SCRootCP1.pdf > [3] https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CPS.pdf > [4] https://repo1.secomtrust.net/spcpp/pfw/pfwevca/PfWEVCA-CP.pdf > [5] https://www.secomtrust.net/service/pfw/apply/ev/1_3.html > [6] https://www.secomtrust.net/service/pfw/apply/ev/sts_1.html > [7] > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ > [8] https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.pdf
Dear Ryan-san, The SECOM CP and CPS have been translated into English and attached to https://bugzilla.mozilla.org/show_bug.cgi?id=1096205 CP (English): https://bugzilla.mozilla.org/attachment.cgi?id=8674034 CPS (English): https://bugzilla.mozilla.org/attachment.cgi?id=8674035 The answers for Ryan-san questions are as follows. > - While Section 4.1 indicates that SECOM will examine CAA records, as > required by version 1.2.0 of the Baseline Requirements (as adopted by Ballot > 125), SECOM does not list which CAA records it will process or what it would > do if they mismatch. > This may be seen as an incomplete adherence to the Baseline > Requirements, but I would rather see it as a reasonable confusion > related to expectations. Secom ignores CAA at this moment. > - Section 2.2 of the CP fails to provide information in the repository > for testing certificates issued by these roots. We will provide test web pages for revoked and expired in addition to the valid page. > - Section 3.2.2 fails to comprehensively explain how domain name > validation works. This is explained at the URL below. https://www.secomtrust.net/service/pfw/apply/ev/1_3.html https://www.secomtrust.net/service/pfw/apply/ev/sts_1.html In order to clarify, we will add it in the CP how domain name validation works. > - Section 4.9.7 fails to clearly document the frequency of OCSP publications > > or of the validity periods of the OCSP responses. We will add it in the CP. > - Section 6.1.7 indicates the keyEncipherment usage, but that may be > inconsistent with the usage of EC keys. Because in section 6.1.5 subscriber's key algorithm is RSA but nothing else, it cannot be EC. So there is no inconsistency. > - Section 7.1.1 is somewhat inconsistent with respect to the SHA-1 > signatures. While the other policy documentation indicates support for > SHA-2 signatures, "Table 7.1-3 SECOM Passport for Web EV 2.0 CA Server Certificate Profile" is described for SHA-2 signature. "Table 7.1-1 SECOM Passport for Web EV CA Server Certificate Profile" is described for SHA-1 signature. > - Section 7.3 fails to document an OCSP profile, as required. Other > documentation refers back to this section, so it's clearly insufficient. "Table 7.1-4 SECOM Passport for Web EV 2.0 CA OCSP Server Certificate Profile" is described for SHA-2 signature. "Table 7.1-2 SECOM Passport for Web EV CA OCSP Server Certificate Profile" is described for SHA-1 signature. Thank you for your time and consideration. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
