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 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
