You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Code Signing certificates, CAs are required to keep the time encoded in the InvalidityDate extension and revocationDate field the same. Additionally, if a CA deems that a historic date should be set, for example due to a key compromise having occurred a while ago, CAs are required to backdate the value.
For TLS Certificates, CAs should set the revocationDate value for the date and time when revocation occurred, however, CAs are allowed to backdate if deemed appropriate.
Both of these documents state that this is a deviation/exception to best practices described in RFC5280.
However when we look at the SBRs, we could not find any such language that would clarify if and when backdating is allowed. I’m wondering if there’s been any discussion in the past around this, if this was left out on purpose, or if we missed this?
Likewise, I’m wondering how other issuers and consumers look at this, and if we want to add some clarifying language in the SBRs. I’m inclined to say that backdating revocation is something we should be supporting.
The text was updated successfully, but these errors were encountered:
See https://lists.cabforum.org/pipermail/smcwg-public/2023-September/000773.html from Martijn
Code Signing certificates, CAs are required to keep the time encoded in the InvalidityDate extension and revocationDate field the same. Additionally, if a CA deems that a historic date should be set, for example due to a key compromise having occurred a while ago, CAs are required to backdate the value.
For TLS Certificates, CAs should set the revocationDate value for the date and time when revocation occurred, however, CAs are allowed to backdate if deemed appropriate.
Both of these documents state that this is a deviation/exception to best practices described in RFC5280.
However when we look at the SBRs, we could not find any such language that would clarify if and when backdating is allowed. I’m wondering if there’s been any discussion in the past around this, if this was left out on purpose, or if we missed this?
Likewise, I’m wondering how other issuers and consumers look at this, and if we want to add some clarifying language in the SBRs. I’m inclined to say that backdating revocation is something we should be supporting.
The text was updated successfully, but these errors were encountered: