On Thu, Feb 3, 2022 at 8:50 AM 'Corey Bonnell' via [email protected] <[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]. 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.
