Revocation Reason Codes for TLS End-Entity Certificates

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

I can understand why the keyCompromise and cACompromise reason codes are of interest, but I'm struggling to see why Mozilla might be interested in differentiating between privilegeWithdrawn, cessationOfOperation, and superseded.  Why are any of these 3 reason codes more useful than having no reason code at all?  What use cases would be enabled if CAs were to use these 3 reason codes as you propose?

FWIW, at the moment my counter-proposal would be roughly along these lines (for leaf certificate revocations):

  - CAs MUST use keyCompromise for (and only for) proven or suspected key compromise.

  - CAs MUST revoke immediately in the case of proven key compromise.

  - CAs SHOULD NOT use other reason codes.

  - Beyond that, follow the BRs.

> "When a certificate revocation is not due to key compromise and 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."

What if the certificate revocation is due to the CA becoming aware that validation (particularly DCV) was not performed correctly?  In such cases, it's possible (perhaps even likely) that the private key is controlled only by an attacker; and since that private key hasn't been obtained by parties that the subscriber (i.e., the attacker) has not authorized, the key is not compromised.

As with key compromise, waiting 24 hours in this scenario only helps the attacker.

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,

 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.

Is the intention that historic revocations (i.e., revocation entries that first appeared on a CRL prior to the policy effective date) must be reviewed and updated, or is this requirement applicable only to those revocations performed after the new policy becomes effective?

Kathleen –

I’m sorry if I missed an earlier  explanation about why this is important, but could you explain why the emphasis on different reason codes for revocation and the requirement to not include a reason code if the revocation doesn’t fall into one of the stated reasons.

 

Are you trying to get CAs to eventually use CRLs segmented by the different reason codes?

Do you expect RP applications to treat certificate validation differently based on the reason code? 

Do you expect RP applications to potentially make the reason code available to end user so they can choose to continue trusting a revoked certificate if they don’t care about the reason? 

Is it just for trust store programs to gather statistics about why certificates get revoked?

 

I would expect the RP application to treat all revoked certificates the same regardless of the reason for the revocation, so I don’t fully understand why this new policy is being developed.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.