Weblog entry #97 for dkg

OpenPGP User ID Comments considered harmful
Posted by dkg on Wed 15 May 2013 at 02:40
Tags: ,
Most OpenPGP User IDs look like this:
Jane Q. Public <jane@example.org>
This is clean, clear, and unambiguous.

However, some tools (gpg, enigmail among others) ask the user to provide a "Comment:" field when they are choosing a new User ID (e.g. when making a new key). These UI prompts are evil. The savvy user knows to avoid entering anything in this field, so that they can end up with a User ID like the one above. The user who provides something here (perhaps even something inconsequential like "I like strawberries", due to not being sure what should go in this little box) will instead end up with a User ID like:

Jane Q. Public (I like strawberries) <jane@example.org>
This is bad. This means that Jane is asking the people who certify her key+userid to certify whether she actually likes strawberries (how could they know? what if she changes her mind? should they revoke their certifications?) and anywhere that she is referred to by name will include this mention of strawberries. This is not Jane's identity, and it doesn't belong in an OpenPGP User ID packet.

Furthermore, since User IDs are atomic, if Jane wants to change the comment field (but leave her name and e-mail address the same), she will instead need to create a new User ID, publish it, get everyone who has certified her old key+userid to certify the key+newuserid, and then revoke the old one.

It is difficult already to help people understand and participate in the certification network that forms that backbone of OpenPGP's so-called "web of trust". These bogus comment fields make an already-difficult task harder. And all because of strawberries!

Tools like enigmail and gpg should not expose the "Comment:" field to users who are generating keys or choosing new User IDs. If they feel it absolutely must be present for some weird corner case that 0.1% of their users will have, they could require that the user enters some sort of "expert mode" before prompting the user to do something that is likely to be a mistake.

There is almost no legitimate reason for anyone to use this field. Let's go through some examples of this people use, taken from some examples i have lying around (identifying marks have been changed to protect the innocent who were duped by this bad UI choice, but you can probably find them on the public keyserver network if you want to hunt around):

domain repetition
John Q. Public (Debian) <johnqpublic@debian.org>
We know you're with debian already from the @debian.org address. If this is in contrast to your other address (johnqpublic@example.org) so that people know where to send you debian-related e-mail, this is still not necessary.

Lest you think i'm just calling out debian developers, people with @ubuntu.com addresses and (Ubuntu) comments (as well as @example.edu addresses and (Example University) comments and @example.com addresses and (Example Corp) comments) are out there too.

nicknames already evident
John Q. Public (Johnny) <johnqpublic@example.net>
John Q. Public (wackydude) <wackydude@example.net>
Again, the information these comments are providing offers no clear disambiguation from the info already contained in the name and e-mail address, and just muddies the water about what the people who certify this identity should actually be trying to verify before they make their certification.
John Q. Public (Work) <johnqpublic@example.com>
if John's correspondents know that he works for Example Corp, then "Work" isn't helpful to them, because they already know this as the address that they're writing to him with. If they don't know that, then they probably aren't writing to him at work, so they don't need this comment either. The same problem appears (for example) with literal comments of (School) next to their @example.edu address.
This is my nth try at this crazy system!
John Q. Public (This is my second key) <johnqpublic@example.com>
John Q. Public (This is my primary key) <johnqpublic@example.com>
John Q. Public (No wait really use this one) <johnqpublic@example.com>
OpenPGP is confusing, and it can be tricky to get it right. We all know :) This is still not part of John's identity. If you want to designate a key as your preferred key, keep it up-to-date, get people to certify it, and revoke or expire your old keys. People who care can look at the timestamps on your keys and tell which ones are the most recent ones. You do have a revocation certificate for your key handy just in case you lose it, right?
Don't use this key
John Q. Public (Old key, do not use) <johnqpublic@example.com>
John Q. Public (Please only use this through September 2004) <johnqpublic@example.com>
This kind of sentiment is better expressed by revoking the key in question or setting an expiration time on the key or User ID self-sig directly. This sentiment is not part of John's identity, and shouldn't be included as though it were.
John Q. Public (none) <johnqpublic@example.com>
sigh. This is clearly someone getting mixed up by the UI.
I use strong crypto!
John Q. Public (3092 bits of RSA) <johnqpublic@example.com>
This comment refers to the strength of the key material, or the algorithms preferred by the user. Since the User ID is associated with the key material already, people who care about this information can get it from the key directly. This is also not part of the user's actual identity.
"no comment"
John Q. Public (no comment) <johnqpublic@example.com>
This is actually not uncommon (some keyservers reply "too many matches!"). It shows that the user is witty and can think on their feet (at least once), but it is still not part of the user's identity.
"offline long-term identity key"
This particular comment shows up in alarming numbers on the keyservers:
John Q. Public (offline long-term identity key) <johnqpublic@example.com>
Again, this is not a part of the user's identity -- it's a statement about how the user manages their key. If a third party wants to certify this, presumably they need to verify it. How would they decide whether this is true or not? It seems like it would make it more difficult to get certifications from people who are intent on actually verifying the User ID.

It's also (potentially) wrong: An OpenPGP User ID is bound directly to the primary key, but it is implicitly also bound to any subkeys that are associated with the primary key. if the subkeys are online, but the primary key is offline, is this comment correct? What if the primary key later adds a subkey that is not offline or long-term (e.g. they want to do frequent key rollover for an online subkey)? Do they need to revoke their User ID for this?

And where it's not wrong, it's redundant. An OpenPGP certificate is by definition a statement about long-term identity that is bound to a key in the first place. Why include any of this extra verbiage, which is only likely to add to the confusion?

But wait (i hear you say)! I have a special case that actually is a legitimate use of the comment field that cannot be expressed in OpenPGP in any other way!

I'm sure that such cases exist. I've even seen one or two of them. The fact that one or two cases exist does not excuse the fact that that overwhelming majority of these comments in OpenPGP User IDs are a mistake, caused only by bad UI design that prompts people to put something (anything!) in the empty box (or on the command prompt, depending on your preference).

And this mistake is one of the thousand papercuts that inhibits the robust growth of the OpenPGP certification network that some people call the "web of trust". Let's avoid them so we can focus on the other 999 papercuts.

Please don't use comments in your OpenPGP User ID. And if you make a user interface for OpenPGP that prompts the user to decide on a new User ID, please don't include a prompt for "Comment" unless the user has already certified that they are really and truly a special special snowflake.


UPDATED 2015-02-11: added "descriptions of key use" example, since that appears to be more common.


Comments on this Entry

Posted by dkg (108.58.xx.xx) on Wed 15 May 2013 at 02:50
[ View dkg's Scratchpad | View Weblogs ]
By the way, if you have one of these OpenPGP User IDs, i'm not trying to bust your chops. It's easy to be misled by complex tools with complex user interfaces.

If you have an unnecessary comment in your User ID, i recommend just adding a new User ID with matching name and e-mail address field, and no comment (leave it blank if your tools try to seduce you into it!), and push that new User ID field to the public key servers. You could even poke your friends and ask them to certify that new User ID if you want. Then maybe later you can consider revoking or expiring your old User ID with the useless comment.

[ Parent | Reply to this comment ]

Posted by Anonymous (50.43.xx.xx) on Wed 15 May 2013 at 08:08
Role keys seem like the one legitimate use. If you have a special-purpose key with different properties than others, such as one used specifically for activities with your Foo hat on that should not be used in any other context, that's a legitimate use of the comment field.

[ Parent | Reply to this comment ]

Posted by dkg (108.58.xx.xx) on Wed 15 May 2013 at 08:24
[ View dkg's Scratchpad | View Weblogs ]
As i said, there are very special use cases for a very small number of sophisticated users where the comment field may make sense. Sometimes (many role keys themselves are rarely justified from what i've seen, and could actually be handled fine with individual keys). The users who need these scenarios need to be able to find their way into "expert mode" or just need to decide to claim a different name for the "name" part of the User ID. These corner cases should not cause the level of noise and errors that we see all over the keyservers, which is encouraged by the "comment" UI.

[ Parent | Reply to this comment ]

Posted by Anonymous (94.198.xx.xx) on Wed 15 May 2013 at 08:45
(Update: please fix your blog software to properly handle UTF-8, kthxbye.)

I also have a totally unhelpful one:

“no PGP/MIME please, use Inline OpenPGP instead”

There’s an annotation for that (preferred-email-encoding@pgp.com=partitioned)
which I set on my key. Nobody cares. So I added that. With the effect that,
still, nobody cares and many mutt users still send me messages I have to go
through hoops to decode, but, which broke IIRC the Debian Backports archive
server because it didn’t handle comment fields that long (ouch!). And one of
the tools from caff (don’t remember its name) that’s supposed to let you print
slips of uid+fingerprint.

So this is an argument in your favour.

Just… old uids never go away.

[ Parent | Reply to this comment ]

Posted by dkg (108.58.xx.xx) on Wed 15 May 2013 at 09:11
[ View dkg's Scratchpad | View Weblogs ]
Do you have a link for the documentation for this annotation? I don't only see a handful of web pages that mention it when i search, and none of those pages are an explicit specification.

[ Parent | Reply to this comment ]

Posted by Anonymous (94.198.xx.xx) on Wed 15 May 2013 at 11:13
No, sorry. I don’t remember exactly where I found it, either.

[ Parent | Reply to this comment ]

Posted by Anonymous (78.245.xx.xx) on Wed 15 May 2013 at 11:31
I don't agree this is totally not true or maybe, i'm not sure. anywoo great post thanks for asking!!! I believe we should go back to pgp and not gnupgp much more secure.

[ Parent | Reply to this comment ]

Posted by dkg (108.58.xx.xx) on Mon 20 May 2013 at 03:22
[ View dkg's Scratchpad | View Weblogs ]
I'm perplexed by this comment. in what way is pgp more secure than gpg? Is it related to the use or creation of OpenPGP User ID "Comments" ?

[ Parent | Reply to this comment ]

Posted by Anonymous (136.172.xx.xx) on Wed 15 May 2013 at 12:28
What do you think about comments that an uid is a xmpp uid and not an email address?

On another note. caff should take care about xmpp handles as well.

[ Parent | Reply to this comment ]

Posted by Anonymous (134.3.xx.xx) on Mon 5 Jan 2015 at 14:59
In my opinion this is a really important remark! Considering Jabber-IDs have exactly the same format as e-mail addresses, people might start sending mails to the given address. If the comment-field is removed, there is no good way to tell this important information with the public key! (No, not every jabber-server has 'jabber' or 'xmpp' in its domain.)
In general, I agree with the critical remarks in this post, but the "one or two" of those legitimate uses should be pointed out as well here, as to not lose these features!

[ Parent | Reply to this comment ]

Posted by Anonymous (46.43.xx.xx) on Wed 15 May 2013 at 15:54
Testing UTF-8 updates: Debian is ®. Apparently.

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Wed 15 May 2013 at 18:50
[ View dkg's Scratchpad | View Weblogs ]
Thanks to Steve for fixing it. ? it works for me too ?! No more

[ Parent | Reply to this comment ]

Posted by Anonymous (94.198.xx.xx) on Thu 16 May 2013 at 12:22
¡Wonderful❣ ☻☺

Yeah, looks good at the preview.

[ Parent | Reply to this comment ]

Posted by Anonymous (193.35.xx.xx) on Fri 17 May 2013 at 09:12
I disagree on the work comment. Before I added it, more people mailed my personal mailbox with work stuff. It seems like once they've mastered the oft- fiddly encryption interface, they sometimes fail to check the email address!

[ Parent | Reply to this comment ]

Posted by dkg (108.58.xx.xx) on Mon 20 May 2013 at 06:58
[ View dkg's Scratchpad | View Weblogs ]
And yet, "(Work)" is still not part of your identity, and if you ask folks to sign your key, you're asking people to certify that information somehow.

How many people really sent mail to the wrong address? It seems simple to just write the folks who made a mistake the first time a brief note that says "please use foo@example.com for e-mail relating to Example Corp matters. thanks!"

[ Parent | Reply to this comment ]

Posted by Diti (109.190.xx.xx) on Mon 27 May 2013 at 00:44

I agree with the misuse of that comment field more often than not. But my opinion on this field (you were looking for a legitimate example of use) is that it is actually useful for web of trust certification purposes (aka the key/subkey you use for signing other people’s public keys; you know, the one with the C flag).

Certifying a key means that you sign it, that you say “hey, people, I am pretty sure this key whose uid is John Smith, actually belongs to the actual John Smith.” When you sig 3 a key (= when you are 100% sure the key belongs to the person, and sign it with gpg --ask-cert-level --sign-key <id> and 3), you most likely have checked the other person’s real identity with a government-issued ID (among other verification means).

Well. What does a government-issued identity card tell about me? My birth date and location, among other things. Here you go. That’s exactly what the comment field of my key (31A49121CD42FF00) shows. The same birth date and location that those on my identity card.


A legitimate use of the comment field is to display any piece of information that strengthens the certification process, such as something that appears in a government-issued document.

[ Parent | Reply to this comment ]

Posted by dkg (108.58.xx.xx) on Mon 27 May 2013 at 23:22
[ View dkg's Scratchpad | View Weblogs ]
Perhaps you'd like to read my next blog post, gpg --ask-cert-level considered harmful -- i don't think it's a good idea to "sig 3" at all, since there is no useful way to make use of the information, and there are already ways to misuse them.

another thing you might consider is that if you bundle a bunch of other information in your User ID, and you ask someone to certify that User ID, you're asking them to certify all of the information as a bundle. So if your User ID is "Jane Q. Public (DOB: 1992-12-23) <jane@example.org>" and you want me to certify it, you have to prove your date of birth to me somehow. Why would you want to have that extra burden?

[ Parent | Reply to this comment ]

Posted by Diti (109.190.xx.xx) on Tue 28 May 2013 at 00:35

That other article of yours is interesting! I cannot say I disagree with it (showing more information than needed about yourself may be harmful indeed). But I would also add an interesting point that someone once told me: signing another person’s key is nothing but a hint that you consider everything to be fine, that the person whom you signed the key is the actual key owner.

You other article says that few tools differenciate between the types of certifications (level 1, 2 or 3). But that doesn’t make them anyway useless either, because they may help the persons who actually show interest in those certification levels (they are going to read the signature levels, read the policy URL if there is one, etc.) decide to trust a key or not.

Your key may have all the signatures you want, and my best friend’s only one, or two, or zero, I may decide to not trust your key for whatever reasons. I may, for instance, consider that the signatures on your key show that your key is authentic (it really belongs to you, I can trust it), but I don’t trust you for vouching (aka certifying) other keys. Anyway, I am getting a bit off-topic here.

The difference between no certification level at all (aka sig 0), or a sig 3 certification exists in this case. We are at a keysigning party and you sign my key because I sign mine, but you consider that verifying my identity card is an extra burden so you don’t want to do that, but you nevertheless agree that I am the rightful key owner? When you sign it, say you don’t make any claim about how deep your verification was (sig 0) or say you didn’t completely check (sig 2), it makes little (or no) difference to you, so it’s not much of a burden. But if you want to validate that “identity card” uid of mine, the only way to make the others pretty sure that you checked everything, is a sig 3.

Both certification (signatures) types are correct, you are free to sign at whatever level you wish to. But my point is, for people who care (perhaps too much?) about setting their own trust, having a glance at a “birthday comment field” and seeing a sig 3 may mean, for them, that the person who certified that uid actually certifies everything, birthdate included.

Anyway, don’t worry, this discussion is pretty theoretical; in practice, I never actually cared about signature levels so far (:p), because the main reason I use PGP is by solidarity: in a world of postcard (unencrypted) messages, the more people send letters (“hidden” messages), the less suspicious they become (for good!).

[ Parent | Reply to this comment ]

Posted by Anonymous (87.113.xx.xx) on Sun 30 Jun 2013 at 02:49
I add comments just to screw with you grammar Nazis.

On a more serious note, I have different keys for the same email address and gnupg HATES having two identical user id's and it will change a letter or character in one or othe other. With a comment I can change one letter without it changing either the name or the email. Of course, I add 'mottos' rather than semantic information. =P So I guess it is part of my identity.

[ Parent | Reply to this comment ]

Posted by dkg (69.204.xx.xx) on Sun 30 Jun 2013 at 22:13
[ View dkg's Scratchpad | View Weblogs ]
i have no idea what grammar nazis you're talking about.

if you have a good use case for two keys with the same user ID (i've seen such things, though they're rare), you could try several other approaches that don't clutter up the User ID:

  • you could have two separate $GNUPGHOME directories, with separate keyrings, if you really do keep these two workflows strongly separate.
  • you could try to be clearer about what gnupg "HATES", and report the problems so that they have a chance of getting fixed.
There are probably other approaches too that i'm not thinking of.

[ Parent | Reply to this comment ]

Posted by PaulePanter (5.28.xx.xx) on Thu 11 Jul 2013 at 21:55
[ View Weblogs ]

Daniel, thank you for your post. For Seahorse I created a ticket #703766 in the GNOME Bugzilla and the developer Stef Walter promptly provided a patch.

I did not have time yet to try it, but from reading it, it is exactly what we want.

[ Parent | Reply to this comment ]

Posted by dkg (108.58.xx.xx) on Thu 11 Jul 2013 at 21:59
[ View dkg's Scratchpad | View Weblogs ]
sweet, thanks Paul!

[ Parent | Reply to this comment ]

Posted by Anonymous (212.110.xx.xx) on Tue 17 Jun 2014 at 15:23
Dear dkg,

I'm so sorry for making you write this.


[ Parent | Reply to this comment ]

Posted by dkg (212.110.xx.xx) on Tue 17 Jun 2014 at 15:49
[ View dkg's Scratchpad | View Weblogs ]
Apology accepted, Nick! :)

[ Parent | Reply to this comment ]

Posted by Anonymous (2.136.xx.xx) on Wed 3 Dec 2014 at 22:27
Hello there!!
What is the best way to add a nickname to your gpg key then?

[ Parent | Reply to this comment ]

Posted by dkg (38.109.xx.xx) on Wed 3 Dec 2014 at 23:15
[ View dkg's Scratchpad | View Weblogs ]
You should think long and hard about the nickname that you want to include in your identity. (to be clear here, a nickname is not a pseudonym, right?)

Why does it need to be in your User ID, in particular? Will people search for you by that nickname? If not, what value does it serve to have it there?

Is it already part of your e-mail address (like wackydude above)? if so, it's already in place, and you have nothing else to do.

Is it something that other people can verify? If not, how do you plan to deal with the inevitable questions from people who you ask to sign your key, when they want to know how they should know that this is actually you?

Is it a name that people know you by, but is significantly different from your legal name, like everyone knows you as Hank Smith, but your legal name is Charles Henry Smith? If so, you can make two separate User IDs with the same e-mail address. People who know you for years by the nickname can certify it, and people who check your "official" ID can certify the other one. Some will decide to certify them both.

Again, there may be some particular use cases where a Comment is the only way forward, but they are a vanishingly small percentage of the actually uses of this field.

[ Parent | Reply to this comment ]

Posted by Anonymous (2.136.xx.xx) on Wed 3 Dec 2014 at 23:47
Well, to be more precisely, I use that nickname for everything I do on the web, so if I ever want to publish something on the web as a repository, and I want to let people know it's actually me, I'll want to have my nickname beside my gpg name.
On the other hand, it's true that my nickname it's, part of it, in my e-mail and many sites use your e-mail as a way to identify you (like github).

I definitely like the most how it's written the author of some projects in usenet format like: John 'Random Hacker' Doe <john@example.org>
But it's also true that I can only prove I can login in those websites where my nickname is register on and nobody else has done it before me. Which is sort of unambiguous.

This' why I'm not sure how to proceed; maybe the best way in gpg is to keep it simple and use my name with my e-mail, close to my nickname...

[ Parent | Reply to this comment ]

Posted by dkg (38.109.xx.xx) on Thu 4 Dec 2014 at 00:00
[ View dkg's Scratchpad | View Weblogs ]
When in doubt, keep it simple and use the standard form, especially if your nickname is already part of your e-mail address.

If you find out later that you really do need to explicitly include the nickname somewhere else somehow, maybe whatever weird circumstance requires it separate will make it clear exactly how you need to format it. And you can always add a new User ID that is not the standard form later, after the initial publication.

[ Parent | Reply to this comment ]

Posted by Anonymous (2.136.xx.xx) on Thu 4 Dec 2014 at 07:15
OK, makes sense.
I think I have seen one debian developer with a nickname field somewhere in his gpg key, that's why I was also asking.
Thank you!

[ Parent | Reply to this comment ]

Posted by dkg (38.109.xx.xx) on Wed 11 Feb 2015 at 19:13
[ View dkg's Scratchpad | View Weblogs ]
I just added a note to the post above about the comment "offline long-term identity key", which seems to be showing up with greater frequency on the keyservers these days (and is still a bad idea).

[ Parent | Reply to this comment ]

Posted by Anonymous (23.91.xx.xx) on Sun 24 May 2015 at 01:42

Thank you for the reference to RFC-4880 section 5.11. It is in my opinion WRONG in this day and age to expose plaintext email addresses so publicly. I am positive that email addresses leaked this way have been harvested by spambots. Even worse: making the link between a user identifier and a key can facilitate the investigative work of malevolent agents. For example, a political dissident may want to sign messages to certify their authenticity to the public, but reveal his email address only to a trusted reporter and not to state spooks. Today said activist must fill the UID field with bogus comments or risk being exposed the same way all of us standard-compliant GPG users are exposed to spammers.

The solution: encrypt the plaintext email information with the public key before storage in the UID field. People who know the email address (e.g. the reporter) can easily verify that the key belong to it. Their mail clients may even store the verification result in an internal (secured!) lookup table for future reference. People and spambots who don't and should not know are left guessing.

Kindly forward this suggestion to the appropriate RFC committee.


[ Parent | Reply to this comment ]

Posted by dkg (38.109.xx.xx) on Thu 11 Jun 2015 at 18:53
[ View dkg's Scratchpad | View Weblogs ]
This is not so easy as you make it sound.

First, we can't "encrypt the plaintext email information with the public key", because that would mean that the only people who can figure out the actual e-mail address from the certificate would be those who hold the secret-key. Also, which key would you encrypt to? most primary keys (which are the only keys directly bound to a User ID) are not encryption-capable today -- they're intended only for certification and signing. And even if you could encrypt to them, OpenPGP does not use a deterministic encryption scheme (for good reason -- in general, you don't want an attacker to know that two plaintexts are equivalent). But even setting all that aside, if we were to encrypt to the primary key with a deterministic encryption scheme, with the goal that people could test a guess of what e-mail address to encrypt, to see if it matches, this doesn't make sense because it means users can't look up the keys, or trivially find the key in their local keyring without doing a bunch of asymmetric crypto against every key they know about but don't know the user ID for.

So maybe you mean hashing or digesting the "true" user ID, either in full or in part, before attaching it to the certificate. This retains the searchability that we currently have, but (a) it complicates things, and (b) it doesn't actually protect the User IDs from would-be address-harvesters unless the address itself is so high-entropy that it might as well be a random address anyway. See nsec3walker as an example of how relatively cheap machinery can reverse powerful hashes when the input space is low-entropy.

Anyway, i've looked at this problem before, and even got so far as starting to draft a spec for how to do it, and gave up on it because (a) it was more complicated than i wanted it to be, and (b) it didn't actually solve any of the problems i was hoping to address. If you have a better proposal, i'd be happy to hear about it.

[ Parent | Reply to this comment ]

Posted by Anonymous (24.4.xx.xx) on Sat 26 Dec 2015 at 20:37
This article is a bit bombastic and point-missing, somewhat typical of the majority of contributions on this subject. "Don't use comments cuz they can confuse people". OK, I ain't exactly saying that ain't TRUE, just saying it misses the point that the necessary and sufficient information is the key fingerprint, and everythig else is "unnecessary and confusing". The name is unessential but (we might hope) only used to help find the key on a keyserver with key then verified, otherwise it suffers exactly the same expressed complaint about comments. The email address is even more insideous, I never use them, (rarely use them) but in some automation of email they are USEFUL, even necessary for automated encrypted email, but thats different set of problems which could be solved with better user software, but in NO WAY is email address necessary to encryption or key identification, it suffers the same complaints as the comments, it has some marginal utility binding a key with an email address, but seriously, it raises enormous privacy issues and problems that could be better handled.
So, "comments harmful"? Well sure, OK, I appreciate new folks need some guidance. But I prefer "here's why we use this, and when" to "don't do this or that, or horrors of the kraken will be upon you". People are not children, nor should teachers emulate their students.

[ Parent | Reply to this comment ]