Even with a "default MUST" reading, I cannot see how it could be argued that updating the metadata of an already-revoked certificate falls under the definition of "to revoke", a term which is not defined in BRs 1.6.1 and so instead takes its default English definition of "to put an end to the validity or operation of". If a cert already has published OCSP responses with status "revoked", then by definition it is revoked. It is meaningless to revoke it again; so much so that RFC 8555 specifies a dedicated error code <https://datatracker.ietf.org/doc/html/rfc8555#section-7.6> just for the circumstance that a client requests revocation of an already-revoked cert, and this appears to have never been a point of contention during the standardization of that RFC.
On Mon, Feb 7, 2022 at 1:40 PM 'Corey Bonnell' via [email protected] <[email protected]> wrote: > > 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. > > > > I am unaware of any stated obligation for CAs to update revocation > metadata (in particular, reasonCodes) after initial publication of the > revocation. So, I’m struggling to see how it can be argued this is > currently a requirement unless one subscribes to a “default MUST” reading > of requirements, where all possible requirements are in force unless > explicitly stated otherwise. > > > > Thanks, > > Corey > > > > *From:* [email protected] <[email protected]> *On > Behalf Of *Ryan Sleevi > *Sent:* Friday, February 4, 2022 11:21 AM > *To:* Corey Bonnell <[email protected]> > *Cc:* Doug Beattie <[email protected]>; Kathleen Wilson < > [email protected]>; [email protected]; [email protected] > *Subject:* Re: Revocation Reason Codes for TLS End-Entity Certificates > > > > > > > > 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/DM6PR14MB2186DD4B5F8B9B033C368676922C9%40DM6PR14MB2186.namprd14.prod.outlook.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186DD4B5F8B9B033C368676922C9%40DM6PR14MB2186.namprd14.prod.outlook.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/CAEmnEre%3DAQxr4v_PNo8jp6TnnuWAsu4F%2BxDpS%2BwA26NMAWMjzg%40mail.gmail.com.
