> 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: dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> On Behalf Of Ryan Sleevi Sent: Friday, February 4, 2022 11:21 AM To: Corey Bonnell <corey.bonn...@digicert.com> Cc: Doug Beattie <doug.beat...@globalsign.com>; Kathleen Wilson <kwil...@mozilla.com>; dev-security-policy@mozilla.org; r...@sleevi.com Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates On Fri, Feb 4, 2022 at 8:33 AM Corey Bonnell <corey.bonn...@digicert.com <mailto:corey.bonn...@digicert.com> > 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 "dev-security-policy@mozilla.org <mailto:dev-security-policy@mozilla.org> " group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org <mailto:dev-security-policy+unsubscr...@mozilla.org> . 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 "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. 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.
smime.p7s
Description: S/MIME cryptographic signature
