Best practices for GPG user ids

Question

What is the best practice for choosing GPG user id(s)?

I've read various bits of advice, which sometimes even contradict each other. For instance, I've read that one should not use comments, because they are not part of your identity. But strictly speaking, neither is your email address (as it likely will change, and might even be owned by another person later). I've also read a suggestion on this site that one can avoid using an email address and use only a comment to provide some personally-identifiable information, such as DOB*.

Also, an address-less ID is of less use in a mail client situation.

So given that I want a master key to last a life time (or as close as possible), how should I choose my user ID(s)?

At this point I'm leaning toward:

• Primary ID with my full name (First, middle, and last)*
• A JPEG ID with a passport-style photo
• Additional IDs (First Name, Last Name) for each email address I intend to use

The idea is that the primary ID will never change, while email addresses and appearance (for the JPEG id) likely will change over time.

As I acquire signatures, assuming the signors sign all of my currently active IDs, the Primary address-less id will continue to accrue signatures, while the others may come and go.

*I'm intrigued by the idea of including one's place and date of birth in their primary ID, but I'm concerned about the possible breech of privacy. While it may not be difficult to find someone's DOB, it's not the kind of information I generally publicize to the world. Is there any reason that something more than just my full name ought to be included? For that matter, is my middle name or initial going to add anything?

Answer 1

An alternate approach and a legitimate one is to simply use a random Class 4 UUID¹.

This way you detach your keys from any changes in material circumstances and any shifts in your privacy attitude in your personal or professional life.

If you intend to use key servers so that people may contact you securely from the onset (instead of sending a signed "hello, we should have a private conversation" email and harvesting the public key in the reply) then put in the least amount of information necessary to locate you in a directory. This information has become public and may of course change.

Using a random ID approach has several advantages:

• You are not disclosing information in advance of communication. Information disclosure occurs progressively as you know the other person better. Which reflects real life.
• You needn't rely on public key servers if you don't want to.
• Verification that a key is controlled by a specific real person or organisation can be kept separate from otherwise pseudonymous communication. For instance you could disclose at your discretion a named photo signed by a classical key signing party or disclose a CA-signed x509 identity certificate with your GPG UUID in a custom field and cross-signed by your GPG key.
• It encourages people to recognise just how weak the verification process underlying secure emails is² and adjust their expectations of confidential communication accordingly.

To be honest, most email communication is not and will not be encrypted due to a lack of popular interest and support for it (the network effect). Asymmetric key pairs for unsolicited yet secure contact with people you don't know is a nice to have feature most people will never use; and your friendly neighbourhood shadow agency will simply break into your house or mobile phone instead. So don't put a lot of effort or personal information into one of these keys.

---

1. Although some OpenPGP tool-belts have implemented presumptive de facto behaviour that may choke on keys missing certain metadata; despite said tools not being seamless in the first place.
2. Public keys are not inherently linked to a real individual or organisation. The verification kludge that Netscape concocted in the early 90s has proven quite inadequate from a security standpoint. GnuPG/PGP's optional web of trust is both less prevalent and more honest than S/MIME certificates. For both x509 and OpenPGP-compatible keys, underlying trust is being automagically bootstrapped from the void; PGP is simply more honest that this is happening.

Answer 2

When I started using PGP, it seemed reasonable to me that my email address had changed over the years and would likely change again. Having keys tied to old email addresses seemed ridiculous, so I thought if I use my full legal name and my DOB, my PGP key would be tied to my real life identity.

Others encouraged me to set up my PGP this way.

This was bad advice.

My name is uncommon, which means it's easy to use my name to find my ID. It also means that it is very difficult to present my real name without somebody being able to very easily see my DOB, city of residence at the time signatures were made, etc.

This is most certainly a privacy violation. It opens me up to fraud, age discrimination, and other possible problems in the future.

PGP key signing parties are a concept which was very important in the days when the the web of trust seemed essential to protect communication, but since social networking has grown, the concept of 'privacy' has shifted.

As one example of the shift, be careful about who you encourage to sign your key. There are people who I've met over the years who've run afoul of the law who I'm glad never signed my PGP key.

Another aspect is that these signatures reveal additional information about your social network. It means that people will know roughly when, where and who you spent time with during a key signing party. This information could be used by malicious people to build fraudulent online identities.

If I had to do it again, I would probably just use my email address. That address would not contain my name.

When somebody is verifying a key which is not linked to government issued identity cards, a person who is signing my key is merely verifying that the person who was in front of them, speaking with them, was claiming that the key fingerprint and email address they presented was a secure way to continue a private conversation with them. If they're not going to accept that as "proof" of "identity" then I challenge them to define what those two words mean.

Publicly posting my legal name and DOB to a keyserver so that people could add their names and DOB's next to it with digital signatures was a mistake.

Answer 3

There is no real best practice here, only conventional usage.

As with all types of digital IDs, the defining element when setting one up is knowing what you want to authenticate. The identity of an email user is pretty different from the one of a server and this will reflect in the properties of the certificate you generate.

One common mistake (one you seem to fall for) is to mistake the map and the land: the certificate is NOT the user: you're not trying to reflect the whole person with your certificate, only some aspects of it.

Given the above, it's pretty common to use the email field when you want to protect an email account and if you want to link a specific person's legal ID to that email, you fill in the relevant details too (in this case, you should fill it in completely: name, surname, country of residence, etc.) Changes in these elements should be handled with revocation of the old certificate and issuing of a new one (if necessary).