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
