Signatures on UIDs is what you do with:
gpg --edit-key <a [newly imported] primary key or corresponding UID>
gpg> fpr
gpg> sign
Or with the shortcut gpg --sign-key <key ID>. The command creates a "validation/certification signature" message that has your (private/secret key's) crypto signature and validates the connection between the UID and the public key of the other person. GPG attaches these "validation signatures" to the public keys. They are used to (publicly) acknowledge your trust in other people's identity. If you sign another key's UID, you acknowledge you're sure that this UID belongs to that public key.
With a recent version GPG, you can also indicate to the public how sure you are, with the cert-level options in gpg. For example, you can set it to level 1:
--ask-cert-level
--default-cert-level n
...
1 means you believe the key is owned by the person who claims to own it but you could not, or did not verify the key at all. This is useful for a "persona" verification, where you sign the key of a pseudonymous user.
Notice, the UID is just a string of text: <name> (<comment>) <email@example>. I.e. it can be random and multiple people can have the same UID. The idea is that the "audience" of your validation signature for that UID & public key (most likely your friends), will just get it, who is that UID. In any case, your signature is attached to that UID and public key pair, not only the public key. And the signatures of your friends are attached to your UID. It means that you cannot modify your UID (e.g. update the email address or the comment) without loosing the validations from your friends.
So, it seems smart to have the main UID as something simple, stable and permanent that indicates your person, not some temporary email or affiliation. Then you gather the signatures to this main UID, and add secondary UIDs with adduid to your key, if you want to advertise some of your current email addresses in the key. Later, you can revoke the secondary UIDs if needed.
Signatures on keys are used to bind subkeys and UIDs to your primary key. They are done automatically when you create a subkey or UID with addkey or adduid in gpg --edit-key <key ID>. They're not issued to other keys.
Local signatures are signatures that will not get exported. For example, when syncing a key with keyservers or exporting using gpg --export. They're helpful if
- You want to put validate a key and its UID for your own use, but not tell anybody about it (eg. you're afraid of government knowing about some relation)
- You want to validate a key & UID, but aren't too sure about it (eg. for private package repositories -- you will realize when a key changes, but haven't been able to verify it in a secure manner)
OpenPGP/GnuPG web of trust model: If you want to make use of the web of trust (thus also have GnuPG trust the identities that are validated/certified by the "friends of your friends"), you can tune how much GPG trusts in your friends: the trust in their ability and reliability for verifying other's identities when they issue the gpg> sign command. This can be changed by using the trust command in gpg --edit-key. It is the opposite and separate to the indication from the --ask-cert-level options that your friends give to you.
