Addressing Current Limitations of CRL Revocation Reason Codes

[Kathleen Wilson]

All,

As you know, there are currently many limitations in regards to the revocation reason codes for TLS certificates. I would like to have a few discussions here in MDSP to try to resolve some of the limitations by addressing them with updates to policy, audit criteria, tools, documentation, and code.

I propose that we tackle this by having a series of discussions as follows:

1. Previous discussion: Why we/Mozilla want to improve revocation codes for TLS certificates: https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox#Revocation_Is_Important
2. This discussion: Set expectations about what we want to accomplish in upcoming updates to Mozilla's Root Store Policy by identifying what is in and what is out of scope at this time.
3. Next discussion: Determine which revocation reason codes should/should-not be used for TLS certificates, and define the situations during which certain revocation codes must be used.
4. Future Discussion: Determine which revocation reasons must be made available to subscribers and others by CA tools and documentation.
5. Future Discussion: Identify conditions under which CAs would be required to communicate with the certificate subscriber before revoking the certificate if the revocation request did not originate from the subscriber.
6. Future Discussion: Finalize new text to be added to Mozilla’s Root Store Policy, and determine effective dates.
   

I propose that the following limitations be IN-SCOPE of these discussions and the policy updates:

1. There are no policies specifying when certain revocation codes should or should not be used
2. Some CAs do not use revocation reason code at all for TLS end-entity certificates
3. Some CAs use the same revocation code for every revocation
4. CAs can revoke certificates without informing their certificate subscribers about the revocation beforehand
5. We do not have confidence that revocation codes are being used properly, and there is little incentive for CAs to use correct revocation codes
6. There are no policies specifying the information that CAs should provide to their certificate subscribers about revocation reasons
   

The following limitations are PARTIALLY-IN-SCOPE in regards to determining what information CAs must provide to their customers, that CAs must provide revocation interfaces in which the revocation reasons are clear, and that CAs must ensure customers understand their obligations to protect the private key throughout the certificate validity period.

1. Certificate subscribers do not understand what each revocation reason code means, so they may provide the wrong value
2. It is difficult for certificate subscribers to figure out how to properly add the revocation code, or they have to call the CA’s customer service to get it set correctly
3. The reason for revocation can change over time; e.g. initially be for cessationOfOperation, but later have the private key compromised
   

I propose that the following limitations are NOT-IN-SCOPE of these discussions and policy updates:

1. CAs are dependent on the certificate subscriber to report the correct revocation reason.
   • Policies should be written about CA actions, and have to assume that the certificate subscriber takes the correct action when they are reasonably informed about it.
2. The set of revocation reason codes are insufficient for the web PKI, Reference: https://unmitigatedrisk.com/?p=583
   • Updating RFC 5280 would be difficult and take an indefinite amount of time. On the other hand, we have complete control of Mozilla’s Root Store Policy.
3. CAs can be compelled to revoke (e.g. by a court).
4. Once a certificate has been used with a client, the certificate can persist in the browser even after it has been revoked.This can happen, for example, if the browser end-user has installed a Service Worker, stashed code in Indexed DB, polluted the user's disk cache, exfiltrated cookies that they can still use, etc). So even after a site has revoked a certificate, there is no guarantee of what state the end-users are in.
   • Somehow the website operator would have to use ClearSiteData to force-erase everything for their users, but it's unclear how long the website operator would have to do this, because it could be weeks before each user revisits the site.
   • Our intent is to improve the current ecosystem, and we acknowledge that the potential for situations like this still exists.
     

I will greatly appreciate your thoughtful and constructive feedback on this.

Thanks,

Kathleen

[Aaron Gable]

Hi Kathleen,

I believe that the first item proposed to be not-in-scope should be at least partially-in-scope. In particular, a request to revoke a certificate with reason "keyCompromise" is not necessarily the same as a demonstration of key compromise. I believe that future policies should assume that reasonably-informed subscribers take the correct action, yes, but we should be careful not to mandate that a CA take any additional actions when they receive a keyCompromise revocation request that is not accompanied by a demonstration of said compromise.

Aside from that, I think that the proposed parameters of the discussion are very good, and I look forward to continuing in this vein!

Aaron

--
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.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/225f9759-c5b2-463e-b273-ec67603d21bfn%40mozilla.org.

[Kathleen Wilson]

Duly noted. Thanks!

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