Zitat von Martijn Brinkers <[email protected]>:
On 10/09/2013 10:58 AM, [email protected] wrote:Zitat von Martijn Brinkers <[email protected]>:On 10/08/2013 05:57 PM, [email protected] wrote:Hello, today we had a problem that one customer send us encrypted mail with a certificate/key pair which was already expired. Therefore the encrypted data passed the Djigzo gateway to the clients not able to handle it. As the certificate/key pair is still present it would be nice to get the mail decrypted without manually whitelist the certificate/key pair. Thinking about it, this also might be a side effect of using strict-mode, no?I'm 99.9% certain that this is a side-effect of strict-mode. In strict mode, a check is done to see whether the key belongs to the user and is valid. If the key expired, than the key is no longer valid for the user and therefore the message is not decrypted for the user. I'll need to check this to be 100% certain.Is this intended or even useful behaviour and the only fix to add it to the CTL with expired allowed?Good question whether this is expected behaviour or not. I'm not sure whether it is easy to add an "allow expired" cert just for strict mode. Let me think about this. Currently the only work around is I think to add it to the CTL with expired allowed (or disable strict mode) Kind regards, MartijnAs it is allowed by RFC for a mail to be 5 days in transit it would be useful to consider expired certificates/key-pair for decryption. This would be compatibel to what MUA already do.Yes in principle it might happen that between sending and decryption the certificate just expired. I'll look into it how hard it is to change this. Changing this might impact code which validates certificates used for encryption as well so I need some time to really take a good look at it. Since this problem should normally only occur just when a certificate expired (normally you should never encrypt with an already expired cert) and only in strict mode, I do not consider this for now a critical problem. Agree? This gives me some time to think about it.
As i have a work-around it is not that critical regarding time to fix, but it would be more trouble free to get it working to automatically decrypt if a matching key/cert is available even if expired. I also agree that this should not be the case for signing and encryption. For this it should be a manual decision to use a expired cert like it is today.
If a key should not get used anymore for decryption it can be deleted without problem. The only downside i see is that invalid behaviour of remote sites (sender) will not be detected that easy ;-)Yes I think that in this case it's a big downside since now you immediately knew that the sender was encrypting with an expired certificate. Otherwise you wouldn't have known :) ... so strict mode does what it's name implies :) so not decrypting with an expired cert has it's pros and cons :)
I have no answer from remote why this happend until now. From what i can see they have ClearSwift as gateway, but i have no idea if this is policy decision on their side or a default setting.
Regards Andreas
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Users mailing list [email protected] https://lists.djigzo.com/lists/listinfo/users
