Duly noted. Thanks! On Tuesday, November 9, 2021 at 1:03:22 PM UTC-8 aa...@letsencrypt.org wrote:
> 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 > > On Mon, Nov 8, 2021 at 2:38 PM Kathleen Wilson <kwil...@mozilla.com> > wrote: > >> 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 >> <https://groups.google.com/a/mozilla.org/g/dev-security-policy> 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 >> >> <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/t-HeK2qTyeg/m/FZJB0M8sAwAJ>: >> >> 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 >> >> -- >> 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+unsubscr...@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 >> >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/225f9759-c5b2-463e-b273-ec67603d21bfn%40mozilla.org?utm_medium=email&utm_source=footer> >> . >> > -- 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+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/5b5d8c6a-579f-472f-b872-a8e4ff95f9aen%40mozilla.org.
