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.
