5

PGP key holders occasionally replace their old PGP master keys with newer PGP master keys (for example, to use securer algorithms).

When doing this, PGP key holders want their new key to be signed by the same people who signed the old key.

There's a few documents that describe how to do this:

They each mention that, amongst other things:

  • (a) your old key should sign your new key

  • (b) write a transition statement, stating that you're moving from an old to a new key, and that you want your new key to be signed

  • (c) sign that transition statement

Isn't the act of signing another key that has the same UID/email address, sufficient to prove that all trust placed in the old key should be inherited by the new key? Therefore, shouldn't a PGP user who has signed my old key be willing to sign my new key?

That is: (a) is sufficient, (b) is perhaps useful (though could be replaced by other unauthenticated channels), and (c) is unnecessary.

Improve this question

1 Answer 1

Reset to default
2 
(a) your old key should sign your new key

(b) write a transition statement, stating that you're moving from
    an old to a new key, and that you want your new key to be signed

(c) sign that transition statement

Isn't the act of signing another key that has the same UID/email
address, sufficient to prove that all trust placed in the old key
should be inherited by the new key?

No. Signing the key only will only provide whatever trust metrics are determined by another user's trust policy once they import that key.

That is: (a) is sufficient, (b) is perhaps useful (though could be
replaced by other unauthenticated channels), and (c) is
unnecessary.

That won't achieve the aim once the information is received by other OpenPGP users and the effectiveness will vary entirely according to their own policies. If you only sign your new key with your old key then the new key will only gain whatever trust values, usually at a somewhat reduced value flow on from that signing. Those trust values, however, are not determined by you, they are determined by each user within their keyring.

An easy demonstration of this, of course, is to compare the trust value of your own secret key to anything else in the public keyring; yours should be "ultimate" and all the others will be less than that. Chances are most of them will be "unknown" or otherwise not specified.

If you only sign your new key with the old one then there is essentially no difference between that and any other key you sign, such as following a key signing event. The purpose of a transition statement is to explicitly confirm that the new key replaces the old key and that anyone who signed your old key should be able to use the statement to confirm the transition and sign the new key. Which is not something they would do for any key you happened to sign that does not belong to you, regardless of UID conflicts (which may or may not always contain email addresses).

In order to provide the necessary assurance and relevant information to people to whom you are essentially sending a request to sign your new key, you really should provide all of the information. I'd say "must" here, but I don't want to confuse people by using RFC-like terminology.

One thing that is normally recommended with transition statements which has not been included in your list above, however, is that (c) sign that transition statement ought to be dual-signing the transition statement. That is, the transition statement document is signed by both the old key and the new key.

A few years ago I transitioned from my old key (0x371AC5BFA04AE313) to my current key (0x321E4E2373590E5D) and used this transition document) which you can see the whole process with. If you import both my old and new keys and then verify the statement you'll see that the signature data contains two signatures rather than one, though with the same timestamp. The transition statement contains all the necessary information to verify a key which would normally be verified in person or via some other trusted channel (i.e. usually at a key signing party or CryptoParty), the dual signature tells recipients that both keys remain under the same person's control and that they do not believe the old key has been compromised at the time the transition statement was made.

You'll also see that I nicked the majority of the wording of my transition document from DKG. ;)

Improve this answer
3
  • "Which is not something they would do for any key you happened to sign that does not belong to you, regardless of UID conflicts (which may or may not always contain email addresses)." Though some UIDs don't contain email addresses, if two keys do have the same UID (incl email addr), and the old has signed the new, this should be sufficient proof for a person who has signed the old key to sign the new key. However, given signing a transition document is easy, and doing so covers cases in which UIDs don't match, requiring a transition statement seems like the better approach. Thanks!
    – user151891
    Commented Jun 27, 2017 at 6:28
  • "the dual signature tells recipients that both keys remain under the same person's control and that they do not believe the old key has been compromised at the time the transition statement was made" Does the transition key need to be signed by the new key? Surely the old key still being unrevoked/unexpired is enough to say the key hasn't been compromised? Transitioning can only occur when the old key is unrevoked/unexpired anyway, since otherwise an attacker with access to a revoked key can fraudulently sign a transition statement with the old key, and with a fraudulent new key.
    – user151891
    Commented Jun 27, 2017 at 6:34
  • 1
    You're assuming that UIDs always contain information that is unique to a single individual, usually one controlling both the key(s) and email address. That isn't always true; it frequently is, but not always (e.g. security addresses for distros). So the transition process factors in that as well as differentiating a key transition from signing any other party's key.
    – Ben
    Commented Jun 27, 2017 at 8:01

You must log in to answer this question.