encrypting to expired certificates

Hauke Laging mailinglisten at hauke-laging.de
Mon Sep 15 14:10:32 CEST 2014


Am Mo 15.09.2014, 09:48:47 schrieb Nicholas Cole:

> 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.

This is not about opportunistic encryption (which I do not use BTW). It 
is about being capable at all to encrypt in a certain situation.


[quote order changed]

> If a key has an expiry
> date, GPG can be very very certain that that key should not be used

> You can't make assumptions for the reason a key has an expiry date.

Do you think these two statements are consistent?

I don't object to "a key should not be used", BTW. I object to "a key 
must not be used" / "a key cannot be used". Those are very strong 
assumptions which are hardly ever justified.

In particular this is not a decision for a low level tool like GnuPG. A 
low level tool (usually directly used by experts) shall give the GUIs 
the information they need (in this case: the key is invalid because it 
is expired) and let them decide what to do.

There is a whole section

"Doing things one usually doesn't want to do."

in gpg's man page...


> It could be that after that date it would be insecure to send
> encrypted data to that key.

How is that possible without anything encrypted to this key before the 
expiration date becoming insecure, too? If a key has become insecure 
then it is to be revoked.


> I think that implementations should respect the expiry dates on keys.

I agree with that. I just disagree with translating "respect" to "not 
allow any override at all" (for this problem only, allowing overrides 
for all other kinds of worse problems...).


> In fact, I don't think that user interfaces
> should ever have encouraged people to encrypt to 'not valid' keys at
> all, 

I don't think that any UI (I know) encourages people to do that. 
Allowing (after a warning and confirmation) is not encouraging.


> but if they key itself says that it should not be used, then it
> really should not be used.

I agree. But expiration does not necessarily mean "don't use at all". 
Expiration is not the same as revocation. This is not affected by the 
fact that revocation may be impossible (private key lost and 
compromised).

The RfC is quite clear about revocations. It is not about expirations.

http://tools.ietf.org/html/rfc4880#section-5.2.3.3


Expiration is a good feature. Handling expired keys in this way 
discourages using expiration dates, though.


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20140915/a8492b5a/attachment.sig>


More information about the Gnupg-users mailing list