I think your position, that "revoke with reason X" is more specific than "revoke", and may compel CA action to update the reasonCode, makes sense. However, I think that interpretation has an unintended consequence that would need to be resolved before that interpretation could be taken as meaningfully enforceable.
Suppose a CA receives a request from a third party to revoke for reason keyCompromise, then later receieves a request from the Subscriber to revoke for reason affiliationChanged. According to the draft rules, *both* of these must be respected. Clearly that is not possible, as OCSP Reponses and CRL Entries only have room for one reason code. Should the CA always respect the most recent request? That's what I believe your interpretation would suggest. But that means that a cert previously revoked for keyCompromise could get updated to instead be revoked for reason affiliationChanged, which seems undesirable, especially in a world where user-agents are treating keyCompromise revocations as more urgent than others. Should the CA always respect the "most dire" request? That makes the most sense from a security perspective, but would require the community to agree on a total ordering of revocation reasons so that the "most dire" can always be chosen between any two competing revocation requests. I'm not fundamentally opposed to verbiage that requires CAs to update revocation reasons well after the cert has been revoked. I am opposed to language that does so without making clear which updates should or should not be made, or which has unintended consequences. Aaron On Mon, Feb 7, 2022 at 4:16 PM Ryan Sleevi <[email protected]> wrote: > > > On Mon, Feb 7, 2022 at 4:40 PM Corey Bonnell <[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. >> > > Aren't we talking about introducing a requirement/obligation for CAs to > ensure a certificate is revoked with a particular reasonCode, and thus, > implies updating the reasonCode? > > I think we might have crossed our messages at some point, so to try to > recapture: > > - In the status quo of today's requirements, I don't think there's > language to support that "So, in terms of the current written requirements > today, the ecosystem baseline is that revocation completes the certificate > lifecycle." > - The closest one can argue would be 5.4.3, which allows the > shorter date of (revocation or expiration), although the record archival > still fully exceeds the validity period of the certificate > - We do have explicit language (e.g. 4.10.1) that make it clear > that revoked certificates still remain operationally in scope for some > requirements > - Nothing prohibits CAs today from updating reasonCodes, and some > actively do update revocation metadata (e.g. for S/MIME) > - In the context of a hypothetical future requirement (e.g. to revoke > a certificate with a particular reasonCode), I understood your argument > being "This doesn't mean you have to update existing revocations" > - If I understood your proposal correctly, you were saying that the > new language would have to explicitly state the need to update the > revocation code, and without that, CAs could ignore existing revocations > - My response was that I didn't see any language that would support > that an already revoked certificate (with reason A) wouldn't need to be > updated to be revoked with Reason B, even in the absence of such an > explicit requirement > > I suspect we're more in alignment than not, particularly that under the > status quo today, there isn't such an explicit requirement. > However, where I think we're disagreeing was what degree of new language > would be needed. I understood you to be arguing that explicit language was > *necessary*, but I was suggesting that it wasn't necessary, even if it > may be useful clarifications. > > Aaron's response, I think, focused on "revoke a certificate", but may have > missed the context of "revoke a certificate with reason X"; if we say > "revoke a certificate with reason X", and it's already revoked, my argument > was that the default reading of that would be "update the reason to X, if > it's already revoked", as the active form of action, not "no action > required". > > As an example for understanding obligations under the current BRs, let's > say that a Subscriber has lapsed in their Subscriber Agreement, such that > the CA revoked it, under 4.9.1.1 paragraph 2, item 3: "The CA is made aware > that a Subscriber has violated one or more of its material obligations > under the Subscriber Agreement or Terms of Use;" > Now the CA receives a Problem Report, under 4.9.5, regarding suspected key > compromise of this certificate. > > 1. Is the CA required to respond with a preliminary report, under 4.9.5? > 2. Is the CA required to take any action, based on that Problem Report, > such as treating it as a known compromised key, as discussed in 6.1.1.3? > > I'm not sure I've got a correct mental model of your position on these two > questions. If the argument is "the lifecycle is complete", then it seems > like the answer is "1. No, 2. No" for those two. But I don't think you'd be > that extreme? So it's unclear if the answer is "1. Yes, to respond it's > already revoked, and 2. No, because the problem report was deemed invalid > because the lifecycle is complete" or "1. Yes, to respond it's already > revoked, and 2. Yes, because it's still knowledge of a key compromise" > > I think that may help me understand a bit more the position about whether > updating a revocation code should be seen as the default action for "Revoke > with reason X", even if the certificate is already revoked. > > -- > 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%3DHERzL8v2Lo%3D7Sk%2B3AVWPDqWoih5dvykwx4qAft9uoR1wg%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHERzL8v2Lo%3D7Sk%2B3AVWPDqWoih5dvykwx4qAft9uoR1wg%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/CAEmnErdbdpQC-HW21Fqq27gLzhChn_BKCzXRs0MzytrNnC%2BFmA%40mail.gmail.com.
