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 <[email protected]> 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 " > [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/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 "[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/CAEmnErepoAYXTGxhLWebei2N%3DjfVrfJE6yXAX1FJKxGHsXWtsw%40mail.gmail.com.
