I've recently been taking careful notice of the revocation information that CAs are publishing, because what little life I did have is currently under lockdown. I've come across a rather curious behaviour that seems fairly endemic: declarations of revocation that are effectively in the future. I'm not sure what to make of this, from many perspectives: standards compliance, interoperability, as well as "what the heck does that even *mean*?"
Take, for example, these revocations: firstcheck | producedat | thisupdate | revocationtime ----------------------------+---------------------+---------------------+--------------------- 2020-04-04 21:34:02.65324 | 2020-04-04 21:33:00 | 2020-04-04 21:00:00 | 2020-04-04 21:33:06 2020-04-04 21:20:56.018248 | 2020-04-04 21:19:00 | 2020-04-04 21:00:00 | 2020-04-04 21:19:54 firstcheck is the earliest timestamp at which the revokinator got a "revoked" response from the OCSP responder; the other timestamps are all taken from the validated OCSP response. In each case, while the OCSP response was received by the revokinator after the revocation time (which is good), the revocation time is later than both the producedAt and thisUpdate times in the OCSP responses. This behaviour doesn't appear to match the semantics of these fields, as defined in RFC6960: thisUpdate The most recent time at which the status being indicated is known by the responder to have been correct. producedAt The time at which the OCSP responder signed this response. revocationTime The time at which the certificate was revoked or placed on hold. (Just in case anyone wants to object with "but RFC5019!", I'll save you the effort and just note that the definitions in RFC5019 are substantively similar to those above.) Working from the bottom, the use of the word "was" in the definition of revocationTime suggests that revocation is not supposed to happen in the future. It seems quite clearly past tense. producedAt seems fairly straightforward -- time of the signature. Not a lot of nuance there. Except... how can you sign something saying that a certificate "***was*** revoked" before the time at which the revocation took place? The same logic, only more so, exists for thisUpdate -- how can the responder *know* that the status of a certificate is "revoked at $time", twenty minutes (or more) before that revocation took place? Now, what I *think* is happening is simply that OCSP responders are backdating producedAt and thisUpdate in OCSP responses. For time skew reasons, moving back the timestamps might indeed be a good idea, much as Mozilla permits for certificates' notBefore ("Minor tweaking for technical compatibility reasons is accepted"). The only problem with this sort of "compatibility backdating" is that (a) the definitions for the timestamps in OCSP responses are more precise than that of notBefore, and (b) there is no exception that I can find in Mozilla Policy or the BRs that allow this practice -- and as such, regardless of whether it's a good idea or not, it would appear to be something that CAs are not supposed to be doing. As a result of all this, I have a great many questions: 1. Does my analysis and reasoning above appear correct? Does anyone have a differing interpretation of the various documents and requirements, and/or have I failed to find something that could bear upon the reasoning or conclusions I've come to? 2. What could a revocationTime "in the future" even mean, within the context of the RFC definitions as they currently exist? 3. What do common user agents do, in the real world, if they encounter a revocation time which appears to be in the future? Do common user agents even check the revocationTime, or do they just look at cert_status and move on? I assume that user agents are at most only checking revocationTime against their local clock, because if they were doing these "logic checks" between revocationTime and thisUpdate/producedAt, they'd be rejecting these backdated OCSP responses. 4. The horse has probably well and truly bolted on the client interoperability front, but could a revocation date in the future, if defined, help with, say, the problem of signalling to subscriber issuance automation that a certificate is "pending revocation"? 5. (for CAs) why do you produce OCSP responses with these sorts of timestamps? Do you have a different interpretation of the definitions in RFC6960, such that this behaviour is compliant? If so, what is this alternate interpretation? If not, what was the reason for failing to abide by the RFC? Did you bring this conflict between the RFCs and your practice to the attention of Mozilla or another body, such as your auditor or the CA/B Forum? If not, why not? 6. (for everyone) should Mozilla (or the BRs) make an explicit allowance for a certain amount of "backdating" in thisUpdate and producedAt timestamps in OCSP responses (assuming that CAs provide reasonable explanations for why they do this)? What is a reasonable maximum permitted "skew"? Let the discussion begin! - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy