Ryan wrote: > I think that part of this may be resting on a certain statement "that the > certificate lifecycle is completed", and I'm hoping you can expand more. The > certificate lifecycle for a certificate does not necessarily end at > revocation, at least in X.509, and to Doug's earlier question, you can indeed > change reasons (or revocation dates) post-revocation. In the S/MIME case, for > example, you can revoke a certificate with revocation date of Y, and then, > upon later information, change Y to X (an earlier period), indicating that it > had actually been compromised longer.
+1 ________________________________ From: [email protected] <[email protected]> on behalf of Ryan Sleevi <[email protected]> Sent: 03 February 2022 14:43 To: Corey Bonnell <[email protected]> Cc: Doug Beattie <[email protected]>; [email protected] <[email protected]>; Kathleen Wilson <[email protected]> Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Thu, Feb 3, 2022 at 8:50 AM 'Corey Bonnell' via [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> wrote: > Maybe this is where I’m missing an important point. Why is the key > compromise reason more valuable and why will it happen more efficiently and > timely than other reasons in the case where the CA cannot validate POP? Both > can happen “immediately” and the end result is that (just) the requested > certificate is revoked, so does the reason code matter? I’m also very interested in learning the rationale for why keyCompromise revocations are seemingly treated as higher priority, especially if Subscribers can self-attest to such compromise without any verification by the CA. Any RP software that selectively ignores certain revocations based on Subscriber-attested reasonCode has a security flaw in that an attacker who can fraudulently issue a certificate can similarly request revocation for that certificate specifying a reasonCode that RP software doesn’t prioritize. The net result in that scenario is that the certificate lifecycle is completed, but the risk to users of such RP software is still very much present as the certificate may be treated as valid. Corey, Perhaps you could expand on this threat model? It sounds like your model is that rather than the attacker evading revocation, they revoke themselves, and that is somehow opening up a new vector? I think that part of this may be resting on a certain statement "that the certificate lifecycle is completed", and I'm hoping you can expand more. The certificate lifecycle for a certificate does not necessarily end at revocation, at least in X.509, and to Doug's earlier question, you can indeed change reasons (or revocation dates) post-revocation. In the S/MIME case, for example, you can revoke a certificate with revocation date of Y, and then, upon later information, change Y to X (an earlier period), indicating that it had actually been compromised longer. 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? -- 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]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHGOT4n-ZjN%2Bc4bWyzuUibbFytrODDQJxk58A8xP7cwxKA%40mail.gmail.com<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2FCAErg%253DHGOT4n-ZjN%252Bc4bWyzuUibbFytrODDQJxk58A8xP7cwxKA%2540mail.gmail.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=04%7C01%7Crob%40sectigo.com%7C01d2b9c1530c4727cf3908d9e7238ccb%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637794963307816932%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AfRg5tukHuqxcwYcEmGheuE%2BYqS060ZM9Psm9oHXco0%3D&reserved=0>. -- 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/MW4PR17MB4729EDF9D9F116A18D697C45AA299%40MW4PR17MB4729.namprd17.prod.outlook.com.
