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, Thank you for your comments. We Secom are now preparing the entire CP and CPS into English and also the answers. Thanks again for your time and consideration. Best regards, Hisashi Kamo _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
