The Call of the Open Sidewalk

From a place slightly to the side of the more popular path

User Tools

Site Tools


pgpfan:expire

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
pgpfan:expire [2023/08/24 00:30] – Separate background clearer b.walzerpgpfan:expire [2023/09/20 15:17] (current) – [What does key expiry mean to the user?] good example 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. 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. 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 45: Line 45:
  
 Where the receiver and the sender are the same entity then that entity can choose whatever key they want, whenever they want. So encryption key expiry doesn't make sense for things like file encryption. It would be an inconvenience at best. Where the receiver and the sender are the same entity then that entity can choose whatever key they want, whenever they want. So encryption key expiry doesn't make sense for things like file encryption. It would be an inconvenience at best.
 +
 +So the point of this section is that key expiry only makes sense for encryption keys and then only for very rare circumstances. Default key expiry is likely to cause more trouble than it is worth.
  
 ====How TLS is different==== ====How TLS is different====
Line 69: Line 71:
 //<sub>Selecting the "Encrypt Anyway" option did nothing.</sub>// //<sub>Selecting the "Encrypt Anyway" option did nothing.</sub>//
  
-Instead it turned out that the problem was that the PGP keys had expired. Since this was instant messaging we couldn't lock up the keys with a passphrase so we wanted separate keys for our experiment. When we used GnuPG to generate them we just took the defaults which included a 2 year expiry. Our time was up.+Instead it turned out that the problem was that the PGP keys had expired. 
 + 
 +Since this was instant messaging we couldn't lock up the keys with a passphrase so we wanted separate keys for our experiment. When we used GnuPG to generate them we just took the defaults which included a 2 year expiry. Our time was up.
  
 I wondered how someone not particularly interested in the technical details of key expiry would manage when they encountered it. This is what is what the user needs to be able to do: I wondered how someone not particularly interested in the technical details of key expiry would manage when they encountered it. This is what is what the user needs to be able to do:
Line 139: Line 143:
 I am not all that sure about the idea behind this. It seems that there is some thought that PGP key expiry might help a user keep their cryptography more up to date. When the user updates their key expiry time that might be a good time to also update their cryptography preferences but they might be distracted by, you know, the fact that their key(s) expired. If the implementation is set up to help/remind them then we have to ask the question: why wait for key expiry to do that? The implementation knows what encryption preferences and methods are in use. It could bring up the subject at any time, not some years in the future when the key gets around to expiring. I am not all that sure about the idea behind this. It seems that there is some thought that PGP key expiry might help a user keep their cryptography more up to date. When the user updates their key expiry time that might be a good time to also update their cryptography preferences but they might be distracted by, you know, the fact that their key(s) expired. If the implementation is set up to help/remind them then we have to ask the question: why wait for key expiry to do that? The implementation knows what encryption preferences and methods are in use. It could bring up the subject at any time, not some years in the future when the key gets around to expiring.
  
-How often does this sort of thing need to be updated anyway? My CAST5 encrypted files from 20 years ago are still secure today. Currently there does not seem to be any good reasons for routine key size increases(([[em:20482030|2048 Bit RSA and the Year 2030]])).+How often does this sort of thing need to be updated anyway? My CAST5 encrypted files from 20 years ago are still secure today. Currently there does not seem to be any good reason for routine key size increases(([[em:20482030|2048 Bit RSA and the Year 2030]])). 
 + 
 +[[pgpfan:index|PGP FAN index]]\\ 
 +[[em:index|Encrypted Messaging index]]\\ 
 +[[:|Home]]
  
pgpfan/expire.1692837015.txt.gz · Last modified: 2023/08/24 00:30 by b.walzer