10

Following best practices I'm now at the point where I have a non-expiring secret key stored in a save location and a set of sub-keys with an expiration date stored together with the public key on my local machine. However, what I want to do is to set an expiration date on the public key as well, while keeping the secret key non-expiring. How can I do this?

I'd also be interested in the exact relationship between the sub-keys and the public key. Looking at the some keys provided by the key server, I noticed that those will also include (the public part) of the sub-keys. This should be necessary to either validate messages that I signed using a sub-key and also to encrypt data in case an encryption sub-key is found for the recipient. What I don't understand at this point is what happens in case my sub-key expired, but the public key is still present and valid. Will gpg fall back to use the public key to encrypt and validate data? Does it still make sense to use an expiration date for the public key in case all sub-keys have an expiration date set?

I'm also not really sure about the exact role of the public key in case of the existence of sub-keys. My guess is that it's only used to validate the sub-keys before they are used to actually encrypt/validate, is that correct?

8

The Primary Key

The OpenPGP primary key holds your trust. If your key gets certified, those certifications will be issued on tuples of primary key and user ID. Outgoing certifications (on other keys) are also exclusively issued by your primary key. User IDs and subkeys are all coupled to a primary key. All in all, your primary key is the entity the glues everything together.

What capabilities your primary key has depends on the algorithm chosen and what capabilities are actually enabled (you can change this when running GnuPG in the --expert mode). All primary keys must have the certification capability C, but can have signature capability S (which must always be supported, as certifications are also signatures) and finally encryption capability E (which is not supported by all algorithms that fit a primary key, for example DSA can only be used for certifications/signatures, not for encryption).

Subkeys

What I don't understand at this point is what happens in case my sub-key expired, but the public key is still present and valid. Will gpg fall back to use the public key to encrypt and validate data?

Which subkey is chosen is implementation dependent, usually they will choose the newest non-revoked key capable of what you want to perform. If you add another subkey, this will be chosen. If you remove all subkeys, the primary key will be used -- given it has the necessary capability bits set. If the primary key does not support the required capability, the key cannot be used at all!

In GnuPG, you can enforce a specific subkey: by specifying the key ID followed by !. For example, if you want to enforce usage of subkey DEADBEEFDEADBEEF as a recipient, use the option --recipient DEADBEEFDEAEDBEEF!.

Subkeys can be arbitrarily revoked and regenerated without losing reputation in the web of trust.

I'm also not really sure about the exact role of the public key in case of the existence of sub-keys. My guess is that it's only used to validate the sub-keys before they are used to actually encrypt/validate, is that correct?

This is not necessary, but considered best practice. Lots of people even keep the primary (secret) key offline.

Expiration Dates

Does it still make sense to use an expiration date for the public key in case all sub-keys have an expiration date set?

Expiration dates are a reasonable thing to use on subkeys, as they require the sending party to update your key after a given time. They can be changed arbitrarily, though. This is also the reason why expiration dates on primary keys are not a reasonable thing to use; if the attacker gets hold of your primary key, he can simply change or even completely remove it, even if your key already expired! See "Does OpenPGP key expiration add to security?" for a more in-depth discussion.

Instead, have a pre-generated revocation certificate at hand (and in your backup).

However, what I want to do is to set an expiration date on the public key as well, while keeping the secret key non-expiring. How can I do this?

I think you're confusing public and primary here. The expiration date is always set on a public, special "configuration" signature on your primary public key, but issued by your primary secret key (so it can be verified through the public primary key). If you really want to specify an expiration date on your primary key, you can still change it at any time anyway, the old expiration date is simply overwritten.

But as discussed above, an expiration date on primary keys is providing false security, anyway.

  • Thanks a lot! I think I'm going to follow your advise to keep a revocation certificate instead of using a expiration date. – Stefan Podkowinski Nov 2 '15 at 10:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.