On Fri, April 24, 2015 4:45 pm, kwil...@mozilla.com wrote: > > The request is documented in the following bug: > > https://bugzilla.mozilla.org/show_bug.cgi?id=937589
> Does anyone have questions or comments about this root renewal request > from Certinomis? > > If not, I will close this discussion and recommend approval in the bug. Hi Kathleen, I've completed review of the AA Server [1] and TLS server [2] CPSes. Overall, I found these much more detailed then the average CPS I've reviewed, and so I'm appreciative of Certinomis taking the time to provide this information. In the course of reviewing, I found several areas for clarification. I defer to your judgement on whether or not these represent blocking issues. In examining both documents, it seems these issues are shared. As such, I'll only refer to citations from the AA document [1] for ease of discussion. ===== Copyright ===== Page 8 establishes that the CPS is protected by copyright and may not be redistributed, in part or in full, by third parties without prior express written agreement. This does seem potentially problematic, in as much as Mozilla is therefore not authorized to archive or provide a copy of the CPS for future review or discussions. The current Mozilla policy requires only that certificates be unencumbered - namely, part 10 of [3] - which states "All disclosure MUST be made freely available and without additional requirements, including, but not limited to, registration, legal agreements, or restrictions on redistribution of the certificates in whole or in part." I highlight this as a potential issue, but one that may not require remediation pursuant to Mozilla's policies. ===== Usage Restrictions ===== Page 15, Section 1.4.2 establishes a set of restrictions on the use of the certificates it issues. In doing so, it also includes a disclaimer that "Under none of the above hypotheses can the CA be held liable in any way." It is important for Certinomis to be aware that if they issue a certificate that is technically capable of causing further issuance, they will be held liable under the Mozilla policy. This was most recently evidenced in the actions taken against CNNIC. While Certinomis establishes a certificate profile that prohibits the certificates from being technically capable, should those controls fail (e.g. as with TurkTrust), they will be held accountable and liable for that. ===== Trademark Usage ===== Page 22, Section 3.1.6, disclaims liability for the use of trademarked names. Namely, "The CA cannot be held liable in case of the unlawful usage by its customers and beneficiaries of registered trademarks, well-known marks and distinctive signs, or of domain names." However, as with Mozilla policy, if the CA misissues a certificate containing a trademarked domain name to a party not authorized to receive such a certificate, then they will be held liable. That is, it's perfectly reasonable for the CA to disclaim any liability that might occur with issuing a certificate to "fordsucks.com" (as perhaps the most notable example of such a dispute), but they would be liable if they issued a certificate for "facebook.com" to an entity not authorized. ===== Revocation Issues ===== On both Page 28, Section 3.3.2, and Page 36, Section 4.9.2.1, the list of parties authorized to request revocation exclude the public. This creates an issue where the public (or relying party) may detect a certificate that is non-compliant with the CA's policies and practices. This is an issue that I've raised in the past. The revised BRs 1.3.0 failed to account for this in 4.9.2, but 4.9.1.2 establishes the obligation of the CA to revoke when made aware of issues. Under the BRs 1.2.5 (which BRs 1.3.0 is meant to be identical in obligations to), this was made explicit in Section 13.1.2 - which is carried onto 4.9.3 in the BRs 1.3.0. ===== Publication of Certificates ===== While not a blocker, as it is not required by current Mozilla policy, Page 31, Section 4.4.2 seems to prohibit Certinomis from participating in Certificate Transparency unless/until it updates these documents. That may be desired or intentional, but it's just worth noting. [1] http://www.certinomis.fr/publi/rgs/DT-FL-1310-040-PC-AA-1.4-EN.pdf [2] http://www.certinomis.fr/publi/rgs/DT-FL-1310-060-PC-WEBSSL-1.4-EN.pdf [3] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
