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. 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…

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.

Some OpenPGP implementations allow the owner of a PGP identity to change the expiry date of the keys to prevent an impending expiry. Some implementations allow the user to reactivate expired keys (e.g. GnuPG) while others do not (e.g. Mailvelope).

Key expiry is mostly about when the user loses their secret key information. In particular, it doesn't help in the case where an attacker gets access to the secret key information. Such an attacker can extend the expiration date to whatever extent they desire. The attacker would generally have the same power over the identity as the user. The only real cure in this case is key revocation.

There are no security weaknesses associated with the loss of the secret key information. In a sense things will be more secure in that the secret key information will be lost to a potential attacker as well.

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.

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.

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.

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.

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²⁾.

The previous comments about signing key expiry apply here. A user would not want their all their certifications to suddenly vanish just because they lost their secret key material. They certainly would not want their ability to issue revocation certificates to vanish even if they eventually could regain that ability.

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.

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.

An expired encryption key could reasonably be presented to the receiver as a key that should not be used to encrypt anything. In other words, an expired key means that the potential receiver does not want that key used past a certain date. The key is truly “expired” and should no longer be used.

If the user is engaging in message burning via encryption then expiring the encryption key makes sense. If the user deliberately deletes their secret key material on a particular date then the encryption key is truly expired and unusable.

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.

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.

As opposed to leaving the user in control of their identity as with PGP, TLS uses a bunch of trusted third parties. This takes the form of a file with TLS identities in it representing those third parties. The file used might come with the operating system or the browser in the case of the web.

Let's construct an equivalent system in PGP. Imagine the ACME email client. This client comes with a bunch of identities already preinstalled. Those identities are certified with the ACME project identity which is preconfigured to be trusted by the client. These certifications are in the form of trust signatures on the identities configured to allow an intermediate level of trust.

You then pop down to Big Bob's PGP Certification Emporium and get your PGP identity certified. As Bob is an intermediate certifier his identity did not come with the ACME email client. Instead his identity, which you will have to distribute along with your now certified identity, is certified by one of the entities represented by the built in identities. Now everyone using the ACME email client knows that you are, in some sense, legitimate without any other work on your part.

Now let's say that Bob turns out to be a bad certifier or that you lied to Bob about your identity. How could the appropriate certification be removed? A revocation certificate would not work, how would you know where to send it? In normal PGP usage you would use whatever channel that was used to originally distribute the keys. In this case no such channel exists. So it is sometimes said that revocation doesn't work for TLS³⁾. So key expiry is the most practical way to revoke a TLS certification.

Since there is a third party in control, TLS certificate expiry is effective against access to the secret key material by an attacker assuming there is a way for a user to prove such a breach to the third party. In normal PGP usage there is no such third party.

Because of this dependency on key expiry, it is reasonably common for TLS certificates to be allowed to expire accidentally. PGP key expiry has this in common with TLS.

One day my friend told me that she could no longer send messages to me. Her client said this when she tried:

_{Selecting the “Encrypt Anyway” option did nothing.}

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:

• Recognize that the problem is an expired key, possibly in the face of a misleading error message.
• Import the PGP identity into a system that can edit the expiry date if the system in use can not do that. This will probably be GnuPG.
• Understand that a single PGP identity is made up of multiple cryptographic keys and that they might all have to have the expiry updated. This is knowledge of internal complexity that a user would normally be better off without.
• Learn how to use the key editor to do the expiry update for the first time or after a period of years since they had to do it last. The GnuPG key editor for example would present a significant challenge here for most people.
• Export the PGP identity.
• Distribute the updated identity to all affected correspondents.
• Distribute the updated identity to all affected devices/systems owned by the user.

In my case, with but the single correspondent, it would actually be easier to generate new keys and verify them than to bother with key editing. That is assuming that we ever bother to restart the experiment. Ironically the key expiry false positive has caused me to respond as if I had actually lost my secret key material.

It occurred to me that by sending my correspondent a PGP identity with an expiry date I was setting them up with a usability time bomb. If I forget to update their copy of my PGP identity in time then I will cause them to have to understand a situation that came out of nowhere through no fault of their own. Even if their system correctly tells them about the key expiry, then what? How are they supposed to know what to do? The correct response depends on how they got my PGP identity in the first place.

It also occurred to me that key expiry might not just be a disaster but a crisis. Encrypted material is often important material. Suddenly losing the ability to use the system that securely transfers such material could be a serious problem.

Let us assume that an ideal situation exists for PGP key expiry. All devices/systems involved regularly update from a key server. Implementations would keep track of upcoming key expiry and would automatically or semiautomatically work with the user to keep the keys updated. Now I lose access to my secret key material. What advantage does PGP key expiry provide to me, the user, in such an ideal environment?

I have still lost my identity and must still interact with each correspondent so they can verify my new identity. The key expiry date is probably years in the future and will have no immediate effect. Even if the keys expire right after I loose my secret key information, how does that help me in any way?

If one of my correspondents sends an encrypted message to me before I have a chance to update the expired keys, then they will experience the usability time bomb and have to figure out what to do on their own. There is a reasonable chance that they will do the wrong thing. On the other hand, if the encryption key had no expiry, then I would receive a message I could no longer decrypt. At that point I would naturally get in contact with my correspondent and we would resolve the issue together. A much better outcome…

The best we can hope for is minimal inconvenience when everything is going right. PGP key expiry provides no real user benefit past that.

When researching this article I came across this rationale for PGP key expiry:

Users are clumsy, they will lose access to their secret key material, they will lose the revocation certificate, and if the keys do not expire, there is no way to get rid of them.

_{GnuPG Issue T2701}

It is hard not to feel offended by the suggestion that I might be clumsy. I did nothing wrong but the system I was using broke itself. Am I, the user, being punished for my potential future clumsiness? I will also take this opportunity to be offended on behalf of all users. The usability of secret key backup methods provided by OpenPGP implementations is, quite frankly, terrible. That is when there is a solution or even a suggested method provided at all. So we are blaming the user for something that is not their fault. This is not just a PGP issue and is true of many other systems as well, but those systems are not expiring the user's keys.

This is where you have separate certification, signing and encryption keys in a PGP identity. The idea is that you can protect the certification key better than the other keys because it does not have to be routinely used. If the signing and/or encryption keys become compromised you then can use the certification key to recover.

This is an interesting case here because it can be arranged to only expire the more at risk signing and encryption keys or at least give them a much shorter period then the better protected certification key.

If the scheme works as intended, then the user will still be able to get access to their identity in the form of the secret key material for their certification key should there be some sort of problem with their other keys in the identity. Then they can can create new signing and encryption keys, certify them, replace the problematic signing and encryption keys in their existing identity and sent out the updated identity. This capability is, after all, the whole point of a master identity scheme. Key expiry provides no value here.

If, against hope, the user loses their secret key material associated with the certification key then the situation reduces to the one where they lose everything. So the arguments previously presented apply.

OK, then, how should we get rid of old keys?

I think that if someone was to consider the problem from first principles, that they would not immediately think about having the users put expiry dates on their keys. Instead, attention would first be drawn to preexisting indications of PGP identity age. The most obvious would be the creation date on the signature that binds a user ID to the identity. That date gets updated for changes in user ID or preferences. This Gnupg example changes the creation time to the current date:

gpg> setpref
Set preference list to:
     Cipher: AES256, AES192, AES, 3DES
     AEAD: 
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, AEAD, Keyserver no-modify
Really update the preferences for the selected user IDs? (y/N) y

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.

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.

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 reason for routine key size increases⁴⁾.

PGP FAN index
Encrypted Messaging index
Home