encrypting to expired certificates
nicholas.cole at gmail.com
Mon Sep 15 10:48:47 CEST 2014
On Monday, 15 September 2014, Hauke Laging <mailinglisten at hauke-laging.de>
> after filing a bug report for my mail client because it does not allow
> me to encrypt to an expired certificate (neither does Enigmail) I was
> surprised to notice that I didn't manage to encrypt to an expired
> certificate with gpg in the console (2.0.22).
> Is this not possible (what about gpgme?) or am I just not aware of how
> to get that done?
> I would consider not being able to encrypt to an expired key a severe
> security flaw because it may force the sender to send the message
> unencrypted. It is OK to warn the user but it must be possible to
> override this warning. Expiration is not a security problem (let alone a
> severe one).
> It does not even work with --encrypt-to. And the man page says about
> this command:
> "No trust checking is performed for these user ids and even disabled
> keys can be used."
> Non-valid keys are OK, disabled keys are OK but the least severe case
> expiration is not OK?
Opportunistic encryption with a fall-back mode to plain text, which seems
to be your model, is dangerous. Yes, it is always dangerous to have a
protocol that sends in plain text if encryption is impossible.
However, I don't think the fault is with GPG. If a key has an expiry date,
GPG can be very very certain that that key should not be used after a
particular date. In fact, I don't think that user interfaces should ever
have encouraged people to encrypt to 'not valid' keys at all, but if they
key itself says that it should not be used, then it really should not be
You can't make assumptions for the reason a key has an expiry date. It
could be that after that date it would be insecure to send encrypted data
to that key. I think that implementations should respect the expiry dates
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnupg-users