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