> 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) Fully agreed on all these points. However, when I say, “the certificate lifecycle is complete”, it is from the standpoint of the RP consuming revocation data. A CA today can merely update the producedAt/thisUpdate/nextUpdate fields of a CRL and OCSP response for a revoked certificate today and issue these artifacts in perpetuity without changing any other fields, and this would be entirely compliant despite potentially new information coming to light that may make additional reasonCodes appropriate for the revocation response. Therefore, any user agents which make assumptions such that all CAs update reasonCodes today do so at their users’ peril; the only reasonable security property that can be drawn about the ecosystem today is that “there’s no assurance reasonCodes in OCSP responses/CRLs accurately reflect their X.509-defined meanings, nor are they updated as the CA becomes aware of additional information after revocation”. > 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". It has already been clarified by Kathleen that this proposal does not affect historical revocations. Additionally, certificate suspension is not a thing in the TLS WebPKI, so the act of “revoking a certificate” is a singular action (you can’t revoke a certificate “again”). Given this, I don’t necessarily agree that “revoke with reasonCode X” also means “update an existing revocation with reasonCode X”. The current proposal does not state any post-revocation obligations to update revocation metadata, especially since as Aaron pointed out, there is no guidance on determining which reasonCode should be used when multiple reasonCodes are appropriate. > 1. Is the CA required to respond with a preliminary report, under 4.9.5? Yes, the CA is obligated to respond, as it is a “Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.” > 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? If the CA obtains sufficient evidence from the Problem Report that the key is compromised, then yes, the key must be treated as compromised and future requests with that key must be rejected. However, there is no requirement today -- and no requirement in the current proposal -- that would obligate the CA to update the reasonCode for the Certificate to “keyCompromise”. While my opinion is that all revocation data regardless of reasonCode should be consumed by user agents such that all Subscriber-initiated revocations are properly acknowledged, I realize that may not be desirable by one or more Root Programs. If the Root Program expectation is that there is a priority assigned to reasonCodes and that the reasonCode should be updated to higher priority considering new information, then: 1. The requirement to update revocation metadata must be made explicit, and 2. Reason codes need to have priorities assigned so that there is universal understanding and consistency across the ecosystem Thanks, Corey From: Ryan Sleevi <r...@sleevi.com> Sent: Monday, February 7, 2022 7:11 PM To: Corey Bonnell <corey.bonn...@digicert.com> Cc: r...@sleevi.com; Doug Beattie <doug.beat...@globalsign.com>; Kathleen Wilson <kwil...@mozilla.com>; dev-security-policy@mozilla.org Subject: Re: Revocation Reason Codes for TLS End-Entity Certificates On Mon, Feb 7, 2022 at 4:40 PM Corey Bonnell <corey.bonn...@digicert.com <mailto:corey.bonn...@digicert.com> > 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 "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/DM6PR14MB2186BD606F13F1F872FB5E30922D9%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
