On Mon, Mar 16, 2020 at 5:06 PM Tim Hollebeek via dev-security-policy <[email protected]> wrote: > > > > Hello, > > > > I'd like to start a discussion about some practices among other commercial > CAs that have recently come to my attention, which I personally find > disturbing. While it's perfectly appropriate to have Terms and Conditions > associated with digital certificates, in some circumstances, those Terms and > Conditions seem explicitly designed to prevent or hinder customers who wish > to switch to a different certificate authority. Some of the most disturbing > practices include the revocation of existing certificates if a customer does > not renew an agreement, which can really hinder a smooth transition to a new > provider of digital certificates, especially since the customer may not have > anticipated the potential impact of such a clause when they first signed the > agreement. I'm particularly concerned about this behavior because it seems > to be an abuse of the revocation system, and imposes costs on everyone who > is trying to generate accurate and efficient lists of revoked certificates > (e.g. Firefox). > > > > I'm wondering what the Mozilla community thinks about such practices.
Thanks for raising this issue! At the core, it seems like the concern being raised is about policies that might limit certificate or ecosystem agility. From discussions around certificate lifetimes, and from CA distrust, we know that agility is one of the most important things to keeping users secure, so it's understandable to be concerned if agility is jeopardized. Such policies have material impact on end-users. As the number of revoked certificates grow, this requires larger CRLs (for systems that use CRLs), or larger databases/updates for browser-provided systems, like Mozilla's CRLLite or Apple's valid. For end-users, because revocation is treated equally, it runs the risk that potential contract or payment disputes become highly visible as revocations, rather than revocations reflecting signals of the site or the CA's trustworthiness. Overall, that seems harmful to users' security and the ecosystem. These policies only seem to matter because of revocation. If user agents did not check revocation, then CAs revoking these certificates would be a non-issue, because there would be no disruption. However, because some user agents check revocation, they end up giving the CA even more control over the end-user experience, and this allows CAs to cause disruptions that the user agents and end-users are harmed by, rather than benefit from. Perhaps it makes sense to take the approach of the Baseline Requirements and Root Store Policies. The BRs disclose a number of situations where the CA MUST NOT issue a certificate, such as not having validated a domain correctly, as well as define a limited subset of what a CA MAY issue, such as particular optional extensions or name fields. Anything not in those lists are also expected as MUST NOT. It may make sense to take the same approach with revocation, such as by describing a set of policies where a CA MUST revoke a certificate (as is done in 4.9.1.1), a set of scenarios where a CA MAY revoke a certificate, and any reason not on those lists are a MUST NOT. One of the challenges with this is that the BRs require the CA MUST revoke if a Subscriber violates their Subscriber Agreement / Terms of Use. It sounds like CAs are bundling such terms of sale into those Agreements / Terms of Use, so an approach like I just described would not be sufficient. It would be indistinguishable to users / relying parties as a Subscriber who posted their private key publicly (also a violation of the Agreement). In order to deal with this, it's probably necessary to go further: to describe the CRL/OCSP reason codes that MUST or MAY be used, and revocations that don't fall into those enumerated lists MUST NOT use those reason codes. This would allow user agents/relying parties to be more selective when they honor CA-indicated revocation data. For example, if it was possible for user agents to distinguish when the Subscriber violated one of the BR-defined portions of the Subscriber Agreement, versus the CA-defined portion of the Subscriber Agreement, they might choose to only respect the BR-defined reasons. This would also provide tools to limit how much data needs to be sent to all of a browser’s users, when using browser-distributed revocation mechanisms, by allowing the browser to focus on the revocations it’s most concerned about. These ideas are far from perfect, but try to address the challenge the same way that many of the PKI problems have been tackled: trying to bring transparency into CAs’ practices, and through that, greater security and accountability. These ideas are intentionally simple, and avoid unnecessarily complex schemes like revocation transparency. Such systems would only be needed if we expect CAs to be intentionally misleading in revocations, and if that was the case, that seems much more serious a matter. Related to the idea of transparency, perhaps there are ideas from CAA that might be useful here. Section 4.9.1 of a CA’s CP/CPS, and of the Baseline Requirements, are meant to describe exactly the situations when revocation can occur. However, these sorts of situations may not be obvious when reading a CA’s CP/CPS, because “The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use” can cover a multitude of things. Perhaps, similar to how CAA was implemented, Section 2.2 of the BRs could be updated to make it clear that CAs MUST also disclose their Subscriber Agreements and/or Terms of Use in their Repository, just as they do their CP/CPS. Many CAs already do this as part of their Repository, but this would make it clear that such documents are also part of the public basis relying parties use to determine when to trust a CA. However, just like how there may be a multitude of CP/CPSes for a single CA, there might be many different Subscriber Agreements / Terms of Use, and so such information still might not be obvious or easily determined. There’s plenty of precedent in having Root Policy or the Baseline Requirements require a CP/CPS explicitly state something; examples such as the CAA domain name, the problem reporting mechanism and contact address, and compliance to the latest version of the BRs. If we apply that idea here, it might make sense to require the CA’s CP/CPS make a clear and unambiguous statement about whether or not they engage in X as a practice. I’m not quite sure what X should say, but the idea is that it would be transparent to Relying Parties wanting to evaluate a CA, as well as to User Agents when evaluating whether or not a given CA's practices provide a service relevant to user's of that software product. While it's conceivable that sites are already having these practices disclosed to them, having a consistent and public disclosure would help bring transparency into what CAs are engaging in this practice, and which have committed not to use revocation in this way, which can help make it easier to compare the trustworthiness of CAs up-front. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
