> > I definitely agree with Rob that it’s worth exploring the reasons/goals > for this change. I’m skeptical that the proposed notice requirement will do > anything to help other browsers get to a hard-fail situation, >
I see now... If Firefox and other browsers decide to only hard-fail for keyCompromise after the rules for its use are defined, then if a CA decides to revoke a certificate for any other reason it will not cause a DOS for the website, so pre-notification to the website operator is not really necessary. I have deleted the following paragraph from the draft policy <https://docs.google.com/document/d/1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI/edit?usp=sharing>. The first sentence does not help, and the second sentence is redundant. DELETED: "When a certificate revocation reason is not keyCompromise (1) as described below and the revocation is not initiated by the certificate subscriber, the CA MUST make the information regarding its intent to revoke an end-entity SSL certificate available to the certificate subscriber at least 24 hours before revoking the certificate. When the revocation is the result of a Certificate Problem Report as defined in the CA/Browser Forum Baseline Requirements, the CA must communicate with the subscriber as described in section 4.9.5 of the CA/Browser Forum Baseline Requirements." > it may be worth stepping back, both to examine if that is a worthwhile > goal in itself, and look at possible ways to achieve that. > > One serious shortcoming of the revocation methods, in general, is that > they are CA mediated. Both new and long-standing participants on this list > are undoubtedly familiar with just how many CA incidents we regularly see, > and in violations of things that are surprising, if not outright > unconscionable, in the CAs’ explanations for them. That’s not to say any > disagreement or misunderstanding of requirements is an indelible black mark > on CAs, or even that they’re all unreasonable, but there certainly have > been some events, even in the past year, that are egregious in their > misunderstanding that borderline on “willful noncompliance”. > > CA revocation simply exacerbates this asymmetry, in which the goals of the > user agent are misinterpreted, or misimplemented, by CAs that > (understandably and reasonably) have their own motivations and priorities. > We see some CAs callously and knowingly violating the BRs, because they > want to advantage their customers (site operators) at the risk of users, > and revocation is a natural extension of that misalignment. That is, some > CAs want to avoid revocation for mistakes they make, because it annoys > their customers and (rightfully) harms their reputation, but want to > promote revocation for areas where it advantages them (e.g. revoking certs > for a customer if that customer gets any cert from another CA, or if the > customer fails to pay additional balloon fees based on volume, or monthly > “rentals”, etc). > > If the goal of revocation is to protect users, particularly in scenarios > where the site operator is actively interested and supportive of that, such > as key compromise, while discouraging abuse by others, such as CAs, doesn’t > it make sense to have the user agent be the means of accomplishing that? > Equally, when considering government compulsion for revocation, which may > not respect the rule of law or the rights of site operators, doesn’t it > make sense for the user agent to be able to both advocate for and defend > the rights of server operators, such as ensuring such demands are > legitimate and respect the rights of users and site operators? Similarly > too, what about the risk of (other) root stores using contractual > obligations to compel revocation by CAs in their program, which has a > knock-on effect of effectively propagating that policy to all (other) root > stores? > > Concretely, one way to accomplish this would be that, rather than defining > the set of reasons that a CA may use, and trying to filter or special case > that, what if the user agent provided a means (e.g. through some > integration with, or system maintained similarly to, CCADB), which would > allow for site operators to request revocation be propagated through to > browsers, with the logic being that the browser first checks if the CA has > done the revocation. Effectively, a two-phase commit system to allow both > the CA, and the UA, to validate the legitimacy of the revocation request. > > There are undoubtably shortcomings here as well - for example, if a > third-party demonstrated key compromise to the CA, the site operator may > not be interested in having revocation propagated, so it’s by no means a > fully fleshed out proposal, although one can easily imagine possible > solutions, like the CA delivering that proof to this hypothetical system. > But for the scenarios of CA-forced revocation, or things like “someone sent > a government-like looking letter for which the CA has no time, skill, or > interest in actually validating”, this would allow the user agent to act on > their behalf. > > Conceptually, just as CT functions as a form of counter-signing, in which > CAs aren’t trusted to issue certificates unless they have been witnessed by > public logs, thus legitimizing the issuance, this functions as a form of > counter-signing for revocation. Unlike past (somewhat misguided) proposals > for “revocation transparency”, which largely seek to simply make a > commitment to revocation without being able to distinguish, or validate, > the decision making, this tries to add a counter-party (or counter-parties) > to make sure the revocation itself is legitimate and aligned with the needs > and goals for the UA. > > This is, however, further separate from the question of soft-fail vs > hard-fail for revocation. I realize during the earlier discussion of > revocation, as it applies to Mozilla, the technical role of revocation as > it works for Web technologies was explicitly excluded, and I do want to > respect that. However, I do believe that a meaningful discussion of > soft-fail vs hard-fail, for any reason (including key compromise), would > necessarily have to include that, since it may be another area of > philosophical differences that are key to understanding the present > situation. > > I appreciate this philosophical discussion, and we (Mozilla) have considered this and alternative solutions. It would be reasonable to extend the CCADB to provide a mechanism for website operators to specify when they would like browsers to hard-fail for revocations of certificates that they own. However, that in itself would not solve all of the concerns. For example, the website operator may be negligent about their certificate or may not even be aware that their certificate has been compromised. Therefore, a two-pronged approach will most likely be needed long term: 1) Specify the rules for CAs to follow when using certain revocation reasons such as keyCompromise. (This is something that we can tackle now.) and 2) Provide a way for website operators to indicate when their cert's revocations should be hard-fail. CCADB is a reasonable backend for this type of service. (Others may be able to implement this before I will be able to get resources to implement it.) Thanks, Kathleen -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/3685eab2-400f-40db-97a8-0a3b86bed15fn%40mozilla.org.
