encrypting to expired certificates

Hauke Laging mailinglisten at hauke-laging.de
Mon Sep 15 21:06:17 CEST 2014


Am Mo 15.09.2014, 09:47:21 schrieb David Shaw:

> I disagree with this.  Expiration is the way the key owner (the person
> who knows best whether the key should be used or not) tells the
> world, "Do not use this key after this date".

Where do you take that from? Neither the RfC uses this description nor 
GnuPG nor any GUI I know. It is OK (not meaning: being safe from getting 
criticized by the key owner for sending clear text instead) if you treat 
the expiration date this way. But it is absolutely not OK to enforce 
this really not obvious interpretation on others.


>  If someone encrypts to
> the key anyway, they are going against the key owner's statement.

No. As nearly everything in the OpenPGP environment the definition of 
this statement is much too vague to justify this assessment.

Even if you get a contrary statement in person ("No problem, I just 
forgot to extend the validity period in time, use this key") you CANNOT 
do that. This behaviour makes using offline mainkeys (which should be 
strongly encouraged) more difficult.


> either way, the key owner gave a date.  Who are we to disregard that?

a) It seems that nobody wants it disregarded. Regarding this information 
means: Tell the user about it. Narrowing "regard" to "prevent" is the 
second non-obvious interpretation.

b) As I have explained above there is no reason to assume that the 
average user understands "expire" the way you do. Indeed, he gave a 
"date", not a prohibition.

c) Because "we" disregard it everywhere else. GnuPG (and other very 
important parts of the OpenPGP environment) does not care about the key 
owner's statements in any other point in this absolute way.

"In general, you do not want to use this option as it allows you to 
violate the OpenPGP standard." Quote from the man page.

--cipher-algo
--digest-algo
--compress-algo
--force-mdc

All made to override a key owner's statements (clearly RfC-backed 
statements in these cases). And, of course, the keyserver no-modify 
flag. Not GnuPG's fault, of course.

In other words: OpenPGP users are used to their statements being 
(easily) ignored.

d) It does not make any sense to "forbid" someone the use of a key if 
you cannot forbid him to send the information without any encryption 
instead. But it often makes sense to use an expired key for encryption. 
It does not make sense to assume that a key owner would prefer a clear 
text message over one encrypted for an expired key. It is a strange 
decision (to say it politely) to enforce a non-obvious interpretation 
which has a clear alternative (revocation) and does not make sense.

e) Today those users who want to make a strong statement can do that: 
They can revoke their certificate. They cannot do that in advance but 
that is not a problem (I would support future revocations in the next 
OpenPGP version though). In your interpretation those who just want to 
give a hint cannot do that. There are two distinct features. Why should 
they not be treated differently though they are obviously used 
differently and understood differently?

f) There is no change in security by reaching the expiration date. If 
there was one then nobody should encrypt information to a key if he 
wants this information to be secure after the expiration date, too. This 
is a pure formality which makes more sense with signatures than with 
encryption. Formality does not have priority over security.

g) I can show real-world damage. Can you show (similar) real-world 
advantage? (I.e. not just some unclear formality.)


The probably greatest point about OpenPGP is that it is so flexible. You 
can use it on the one side with users who hardly understand what they 
are doing using opportunistic encryption and on the other side you can 
use it for highly secure communication. The difference is about how to 
use GnuPG (and, as Rob just explained, policy which is not GnuPG's 
business). Due to this flexibility OpenPGP usually does not prevent 
users from doing stupid and dangerous things. If it does so in just one 
point and this point is even harder to justify than many things which 
are not done then this is a bug. You cannot explain the behaviour of 
GnuPG with a single rule. You need an exception for this case. And that 
is taste not logic.


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/c8fcf5eb/attachment.sig>


More information about the Gnupg-users mailing list