pgpfan:expire
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| pgpfan:expire [2023/08/23 21:55] – created b.walzer | pgpfan:expire [2023/09/20 15:17] (current) – [What does key expiry mean to the user?] good example b.walzer | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ======PGP Key Expiry is a Usability Nightmare====== | ======PGP Key Expiry is a Usability Nightmare====== | ||
| - | I convinced a friend to try out PGP over XMPP. It was an interesting experiment. The lack of system state meant that things just worked when they worked and it was reasonably easy to figure out what was going on when they didn't. Having just one single PGP identity over all my devices reduced the amount of messing around with identity numbers which I found refreshing in an instant messaging system. Then after a couple of years of use everything suddenly broke in a very obscure way. More on that later but first some background discussion... | + | I convinced a friend to try out PGP over XMPP. It was an interesting experiment. The lack of system state meant that things just worked when they worked and it was reasonably easy to figure out what was going on when they didn' |
| - | =====PGP key expiry===== | + | =====Background===== |
| + | ====PGP key expiry==== | ||
| An OpenPGP key can have an expiry date. A PGP identity has 2 or more keys in it, so that each identity can have 2 or more expiry dates. Implementations generally follow the convention that an attempt to use an expired key will cause that implementation to blow up with an error or at least throw a warning. The general idea is to make expired keys more or less unusable. | An OpenPGP key can have an expiry date. A PGP identity has 2 or more keys in it, so that each identity can have 2 or more expiry dates. Implementations generally follow the convention that an attempt to use an expired key will cause that implementation to blow up with an error or at least throw a warning. The general idea is to make expired keys more or less unusable. | ||
| Line 15: | Line 16: | ||
| Normally the loss of secret key information results in the complete loss of the identity for the user. Any reputation associated with that identity is effectively gone. So the user has to start at zero with that identity and will have to work with all their correspondents individually to reverify their identity. | Normally the loss of secret key information results in the complete loss of the identity for the user. Any reputation associated with that identity is effectively gone. So the user has to start at zero with that identity and will have to work with all their correspondents individually to reverify their identity. | ||
| - | =====What does key expiry mean to the user?===== | + | ====What does key expiry mean to the user?==== |
| This section is a discussion of what expiring a key in common PGP contexts actually might mean to the people using the system past the fact that the key is unusable to some extent. | This section is a discussion of what expiring a key in common PGP contexts actually might mean to the people using the system past the fact that the key is unusable to some extent. | ||
| - | ====Signing key expiry==== | + | ===Signing key expiry=== |
| 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:// |
| 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. | ||
| - | ====Certification key expiry==== | + | ===Certification key expiry=== |
| A certification key creates a particular type of signature that allows an entity to vouch for the identity of another entity. A PGP user mostly uses such certification signatures to verify the identity of their correspondents in their own keyring and to bind the parts of their PGP identity together(([[pgpfan: | A certification key creates a particular type of signature that allows an entity to vouch for the identity of another entity. A PGP user mostly uses such certification signatures to verify the identity of their correspondents in their own keyring and to bind the parts of their PGP identity together(([[pgpfan: | ||
| Line 35: | Line 36: | ||
| I suppose we could imagine the existence of some sort of commercial notary service for identity verification. Such a service might use key expiry to encourage the regular payment of fees. Using key expiry would mean that the user would have to provide a key with an appropriate expiry date for the service to certify with a signature each and every time they renewed. It would make more sense for the notary service to add an expiry date to the signature that they are providing instead. | I suppose we could imagine the existence of some sort of commercial notary service for identity verification. Such a service might use key expiry to encourage the regular payment of fees. Using key expiry would mean that the user would have to provide a key with an appropriate expiry date for the service to certify with a signature each and every time they renewed. It would make more sense for the notary service to add an expiry date to the signature that they are providing instead. | ||
| - | ====Encryption key expiry==== | + | ===Encryption key expiry=== |
| The public encryption key is used by a sender to encrypt the material. The secret decryption key is used by the receiver to decrypt the material. | The public encryption key is used by a sender to encrypt the material. The secret decryption key is used by the receiver to decrypt the material. | ||
| Line 45: | Line 46: | ||
| 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' | 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' | ||
| - | =====How TLS is different===== | + | 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==== | ||
| It is well known that TLS certificates expire. It might be good to explore the reasons that they do and see if those reasons are relevant to the world of PGP. | It is well known that TLS certificates expire. It might be good to explore the reasons that they do and see if those reasons are relevant to the world of PGP. | ||
| Line 68: | Line 71: | ||
| //< | //< | ||
| - | Instead it turned out that the problem was that the PGP keys had expired. Since this was instant messaging we couldn' | + | Instead it turned out that the problem was that the PGP keys had expired. |
| + | |||
| + | Since this was instant messaging we couldn' | ||
| 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 138: | 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 | + | 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 |
| + | |||
| + | [[pgpfan: | ||
| + | [[em: | ||
| + | [[:|Home]] | ||
pgpfan/expire.1692827705.txt.gz · Last modified: 2023/08/23 21:55 by b.walzer