All relevant language in the Baseline Requirements (for example, "The CA SHALL revoke a certificate within 24 hours if...") is related to when and how quickly a CA must revoke a certificate. I am not aware of any language in any root program requirements that requires a CA to update the reason code on an already-revoked certificate if or when additional information is obtained.
Thus it seems that yes, if it is widely known that certain user agents are routinely ignoring revocations with certain reason codes, it seems to open up the described attack vector: 1) Compromise someone's key 2) Use that key to issue a cert for a malicious domain 3) Immediately revoke that cert using a reason code that is ignored by user agents 4) Now when the original keyholder revokes for reason keyCompromise, your malicious cert will remain untouched I wouldn't claim that the certificate lifecycle is done -- obviously, the CA must continue to publish new OCSP responses for the certificate until after it expires. And there is a requirement that CAs process and evaluate all incoming revocation requests. But there is no requirement that processing multiple revocation requests for a single cert happen in any particular way: first request wins, last request wins, "most dire" request wins, or any other method. Aaron On Fri, Feb 4, 2022 at 8:21 AM Ryan Sleevi <[email protected]> wrote: > > > On Fri, Feb 4, 2022 at 8:33 AM Corey Bonnell <[email protected]> > wrote: > >> Fully agreed that X.509/PKIX provides the tools to update revocation >> information after the initial revocation is published via CRL or OCSP. >> However, from a TLS BR and Mozilla Policy standpoint, there is no >> requirement for CAs to update reasonCodes, invalidityDates, etc. after >> initial publication of the revocation. While some CAs may do this, it is >> not reasonable to assume that all CAs currently do so today. So, in terms >> of the current written requirements today, the ecosystem baseline is that >> revocation completes the certificate lifecycle. >> > > I think I follow your argument, but I think we may disagree. > > If I understand correctly, you’re pointing out that unless there’s an > explicit mandate, the lifecycle is done, while I’m trying to highlight that > without an explicit dispensation, the lifecycle isn’t done. > > I suppose this is a variation of “default allow” vs “default deny”, or > half empty/half full: we may disagree based on perspective, even when > looking at the same thing. > > > If I understand your attack, although I'm hoping you can more precisely >> explain it, it sounds like the assumption is that if the attacker >> self-immolates their cert, then it's impossible to change to keyCompromise >> later (e.g. as a result of the victim demonstration). Is that the implicit >> assumption? >> >> >> >> I think you understood the attack: the attacker gets a certificate >> issued, then summarily revokes it with reasonCode that is ignored by a user >> agent. Since revocation is complete, the CA is relieved of any obligation >> to update this information after the initial publication. And users of that >> user agent are still exposed to the risk. >> > Can you point to what language supports the co Claus ion that “the CA is > relieved of any obligation to update this information”? I’m not familiar > with any language explicitly supporting this, and that may be why I don’t > see this attack as practical? > >> -- > 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/CAErg%3DHEOSJD9aLfh78iDAN0027guJ2jfEPN%3D00q7x4JrHzQpbw%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHEOSJD9aLfh78iDAN0027guJ2jfEPN%3D00q7x4JrHzQpbw%40mail.gmail.com?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/CAEmnErc9X5hbQkvn%2BhFyjnyG%3DYa-Uz5UuZqemAOaPeZDp8M%3DVA%40mail.gmail.com.
