On Thursday, January 20, 2022 at 4:48:38 AM UTC-8 [email protected] wrote:
> 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. > Please see: - https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox#Revocation_Is_Important - https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/SIqvgTmKnno/m/UPsTMDGAAwAJ - The “Revocation Reasons” section of the 2009 paper, “Troubleshooting Certificate Status and Revocation <https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc700843(v=technet.10)?redirectedfrom=MSDN>”, by Brian Komar and David B. Cross, Microsoft Corporation. - The first six sections of https://blog.cloudflare.com/high-reliability-ocsp-stapling/ My intention is described here: https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox#Revocation_Is_Important Assuming that most website operators correctly protect the private keys for their TLS certificates for the duration of the time that they own the domain name, limiting the TLS certificate validity period and validation of domain names to one year reduces the risk of potential exposure of the private key of each TLS certificate that is revoked, replaced, or no longer needed by the original certificate subscriber. However, we still need to take into account situations in which the private key of a TLS certificate is obtained by an attacker or otherwise compromised. This can happen at any time during the certificate’s validity period if the website’s servers become compromised. > > > Are you trying to get CAs to eventually use CRLs segmented by the > different reason codes? > That's not my intention, but that is an interesting idea. > Do you expect RP applications to treat certificate validation differently > based on the reason code? > I do not have expectations for other RPs, but RPs may want to treat certificate validation differently based on reason code. For example, an RP may choose to enforce all revocations for which a reason code is provided, and not enforce revocations for which a reason code is not provided. Or an RP may choose to hard-fail on keyCompromise, but allow the user to click-through the error message and proceed to the website for other revocation reasons. > 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? > I do not have expectations for other RPs. I am not aware of any current plans for Firefox to do that. > Is it just for trust store programs to gather statistics about why > certificates get revoked? > That's not my intention. My intention is to protect end users, but there are challenges for browsers <https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox#Challenges> to enforce revocation of end-entity TLS certificates. > > > 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. > > Browsers cannot hard-fail when they are dependent on OCSP or CRL endpoints that are subject to service outages and network errors. So they need to pre-package the data about revoked certificates to distribute to their clients. However, end-entity TLS CRL data is huge, which is why Mozilla has been working on an implementation of CRLite <https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/> that uses complex algorithms to compress revocation data from more than 300 megabytes to on the order of 1 megabyte. However, there are drawbacks to this, so we are in parallel working towards reducing the amount of revocation data that needs to be stored and distributed to clients -- by identifying the revocation reason codes that really need to be enforced by browsers, and putting policy into place so that those reason codes only get used when they are supposed to be used (e.g. currently there is nothing to prevent a CA from using the keyCompromise revocation reason for all of their revocations). Assuming that most website operators correctly protect the private keys for their TLS certificates for the duration of the time that they own the domain name, then revocations for keyCompromise are the most urgent to enforce. 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/5bf85922-0179-4621-9d05-30c25130d959n%40mozilla.org.
