Hi Ryan, > 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.
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. Relevant to this discussion are some recent changes to the Code Signing Baseline Requirements [1], which do clarify expectations for CAs regarding setting revocationDates and invalidityDates, as well as clarifying that updating the revocationDate for a CRL entry and OCSP response is encouraged, taking in consideration any new information that the CA may become aware of post initial revocation of the Code Signing certificate. If Root Programs are expecting that CAs update revocation information after the initial publication, then that expectation should be made more explicit with a treatment similar to the Code Signing BRs. > 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. Thanks, Corey [1] https://lists.cabforum.org/pipermail/cscwg-public/2021-October/000616.html From: Ryan Sleevi <[email protected]> Sent: Thursday, February 3, 2022 9:43 AM To: Corey Bonnell <[email protected]> Cc: Doug Beattie <[email protected]>; [email protected]; Kathleen Wilson <[email protected]> Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates 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]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/BN7PR14MB217808833969C6B515C08AFF92299%40BN7PR14MB2178.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
