SMCXX: Backdating revocations #217
Conversation
| @@ -2360,6 +2364,10 @@ The Repository MAY include CRL entries that have a `CRLreason` of certificateHol | |||
|
|
|||
| If a `reasonCode` CRL entry extension is present, the `CRLReason` SHALL indicate the most appropriate reason for revocation of the Certificate, as defined by the CA within its CP/CPS. | |||
|
|
|||
| ### 7.2.3 CRL entry revocationDate field | |||
|
|
|||
| The CA SHOULD update the revocation date in a CRL entry when it is determined that the Private Key of the Certificate was compromised prior to the revocation date that is indicated in the CRL entry for that Certificate. Backdating the revocationDate field is an exception to best practice described in RFC 5280 (Section 5.3.2); however, these Requirements specify the use of the revocationDate field to support S/MIME implementations that process the revocationDate field as the date when the Certificate is first considered to be compromised. | |||
There was a problem hiding this comment.
I think we need a bit of clarity on whether or not it's acceptable to backdate revocations for reasons other than Key Compromise. For example, if it is discovered that a Subscriber violated their obligations under the Subscriber Agreement several months ago, is it appropriate or allowed for the CA to set the revocationDate several months in the past?
There was a problem hiding this comment.
I think we need a bit of clarity on whether or not it's acceptable to backdate revocations for reasons other than Key Compromise. For example, if it is discovered that a Subscriber violated their obligations under the Subscriber Agreement several months ago, is it appropriate or allowed for the CA to set the
revocationDateseveral months in the past?
For example... It was discovered that the identity validation was not done properly, could it be appropriate to backdate to the same issuance time, so any digital signature is deemed invalid for that certificate?
BTW, could it be that certificate consumers aren't currently checking the revocation date when opening an email, but just that the certificate is revoked?
There was a problem hiding this comment.
@CBonnell and @pfuentes69 both good points, I had not even considered that scenario, thank you.
Lets discuss tomorrow during the S/MIME call
There was a problem hiding this comment.
In my opinion, alignment with RFC 5280 is better. This might get S/MIME UAs to process the CRL entry to give better information to the user. I would prefer to say:
### Invalidity Date CRL Entry Extension
The CA SHOULD provide the Invalidity Date CRL entry extension when it is determined that the Private Key associated with the Certificate was compromised prior to the revocation date that is indicated in the CRL entry for that Certificate.
|
I can understand backdating for Code signing where there is a timestamp in the signed object, but I'm not clear on the value of backdating an S/MIME certificate. What value does this have to relying parties and how would certificate consumers do something different here vs. revocation time set to the date when it's revoked (not back dated)? I probably missed the background for this request. |
The value here is to be able to discriminate if the digital signature in a mail can be trusted "at the moment the mail was sent" vs "the time the mail is opened". |
|
For background, there's been quite a bit of discussion about invalidityDate in the CSWG at https://lists.cabforum.org/pipermail/cscwg-public/2021-September/000525.html or https://lists.cabforum.org/pipermail/cscwg-public/2021-August/000515.html. This is one of those items that needs involvement from both Certificate Issuers and Certificate Consumers to improve the situation. |
|
I'm not in favour of backdating. Imagine you get a signed email and the signature checkous (certificate valid). You buy something based on the - at that time correct - signature. Then, maybe days or weeks later. You check that signature again and it suddenly is invalid... I think that would destroy any confidence in such signatures. |
This is honestly the moment where S/MIME is lacking, especially compared to eIDAS containers - it's not specified how a letter could be validity-stapled. Ideally we'd have S/MIME OCSP-stapling to address the common reasons for failing checks (the certificate just expired or was superseded), it doesn't address the "it should have never been valid" and it actually shouldn't. Allowing backdating revocations will not change much in terms of (bad) user experience with current S/MIME implementations in MUAs. But I agree with @romanf that it shouldn't be done. It causes a misalignment between the expectations people have about (physical) signatures and how these checks would make S/MIME ones function. If a thing is physically signed, even if it shouldn't have been signed or the signature was forged, the signature is not going to magically turn to say "invalid" - what's there is there and must remain so for consistency. If not for that, for being able to say "it was valid when I acted on this information." |
|
At the CMS level, there is support for including an OCSP response with a message. See RFC 5940. I do not know of any MUAs that use this capability. The OCSP response will get stale sitting in a mail folder, so some more complicated processing is needed to tell the human user the difference between the revocation state at the time the message was sent and the revocation state at the time the message is viewed. |
No description provided.