Differences

This shows you the differences between two versions of the page.

--- pgpfan:expire [2023/09/19 13:02] – [Cryptography expiry] Slightly better grammar b.walzer
+++ pgpfan:expire [2026/03/10 19:06] (current) – [Cleaning up old keys] Shouldn't assume that reader shares my assumptions. b.walzer
@@ Line 24: / Line 24: @@
 A signing key allows a user to produce a signature that authenticates a message or document or a software archive in some context dependent way.
-I am not really sure what expiry could mean for the case of loss of the secret part of the key. In a paper context, a signature or seal is still considered valid even if the technical means to create such marks no longer exists. Even if you lose your pen or stamp, signatures made with the pen or stamp are still binding and relevant. In a PGP context, only the public part of the key is required to verify a signature. Expiring that public part seems arbitrary and pointless. It would just be confusing if all the already received email from a particular correspondent suddenly started showing up as anonymous (unsigned). It would make no sense for a signed software archive to suddenly be not signed. Signing key expiry goes against normal cultural assumption.
+I am not really sure what expiry could mean for the case of loss of the secret part of the key. In a paper context, a signature or seal is still considered valid even if the technical means to create such marks no longer exists. Even if you lose your pen or stamp, signatures made with the pen or stamp are still binding and relevant. In a PGP context, only the public part of the key is required to verify a signature. Expiring that public part seems arbitrary and pointless. It would just be confusing if all the already received email from a particular correspondent suddenly started showing up as anonymous (unsigned). It would make no sense for a signed software archive to suddenly be not signed((Here a user asks if signing key expiry is a problem and receives no definite answer: [[https://lists.gnupg.org/pipermail/gnupg-users/2023-August/066668.html|nPth signature]])). Signing key expiry goes against normal cultural assumption.
 It might make sense for implementations to ignore expiry dates on keys used for verifying a signature and thus avoid the question of meaning in the first place.
@@ Line 135: / Line 135: @@
 This is easier than key expiry and could be made into a one shot command with no required parameters.
-So the operators of a PGP key server could announce that they would delete older PGP identities based on this creation date. They could even send out reminder messages based on the embedded email address. If an identity ended up being deleted, the user's system would continue to operate based on the keys that existed at the end points. The result would be less surprising.
+So the operators of a PGP key server could announce that they would delete older PGP identities based on this creation date. They might be able to send out reminder messages based on the embedded email address in some cases. If an identity ended up being deleted, the user's system would continue to operate based on the keys that existed at the end points. The result would be less surprising.
+My suggested scheme would require that key servers reject submitted keys with creation dates in the future. In the same sort of way, a scheme based on key expiry would have to reject keys with expiry dates too far in the future. That would create an awkward and not very transparent requirement for the user.
+If there were multiple key IDs then obviously the newest would be used.
 Doing things in terms of the age of the identity allows the entity that actually cares about old identities to decide on the retention period as opposed to the owner of the identity who has no reason to care. The concept of bringing the identity up to date is more straightforward for the user than getting them involved in deciding on an expiry date.