Newbie: Choosing a user ID questions

[Neil Williams]

On Saturday 31 Jan 2004 10:05 pm, Peter Valdemar Mørch wrote:
> A couple of newbie questions regarding chosing a user ID:
>
> 1) Avoiding spam _and_ including the email address in user ID

Generally there are far easier ways of harvesting email addresses than 
trawling through keyservers - the list of UID's may be clearly visible when 
you inspect a key via a keyserver www interface but using it to collect 
millions of addresses just doesn't seem practical when there is no list of 
all known key ID's. If spammers can't get a few million addresses, there 
wouldn't seem much point. (There are also quite a few dead keys on keyservers 
- people sometimes just stop using them or usually just forget the passphrase 
without generating a revocation certificate beforehand.)

> I get too much spam, so I'd like to use a userID such as:

Use a spam filter instead?

(Have you considered that this list is publicly archived - your email address 
is scrambled in a similar way by mailman but it is still retrievable. It all 
depends on the amount of effort required.)
http://lists.gnupg.org/pipermail/gnupg-users/2004-January/021192.html

> Peter Valdemar Mørch <peterRemoveThis at domain.no.spam.com>

This kind of thing is quite common on Usenet - that hasn't stopped usenet 
being a source of data for spammers.

> But obviously that is not my correct  email address. Is this "A Good
> Thing"? Should I rather omit email address altogether? (Especially if I
> later will ask others to sign it?)

Many of the more frequent signers use scripts to make verification easier and 
most are hand-crafted. It wouldn't help if your UID email address needs 
manual hacking.

> The email address is optional when generating a key pair, but almost all
> the entries on e.g. the MIT PGP Public Key Server have email addresses.
> Can I safely omit it? Are there any consequences of that? Don't the

Personally, I'd say the email address is expected if the key is going to 
become public. You can do what you like with a key only used locally but if 
you want others to sign it and trust it, I'd expect at least some people to 
be upset at such constructs.

When you ask someone to sign your key, you are asking them to verify the UID 
and the person. If the UID cannot be verified because it lacks a valid email 
address, I can see some people simply not signing the key. I probably 
wouldn't. After all, I would usually sign someone's key to enable encrypted 
communication via email - it adds another hurdle to have to verify an address 
that is not contained in the UID. Some email clients use the To: email 
address to find the best key to use for the encryption. 

> spam email address harvesters come to key servers for some reason?

Others will know for definite but I suspect it's just too much like hard work.

>
> 2) Why is the user ID "hidden"/embedded with --export --armor?
>         and
>     How to extract the user ID from such an armored key without changing
>     my keyring?

View it in a keyserver?

> I'm just wondering why the ASCII armored output from --export --armor
> doesn't contain the userID in clear text, so it is human readable.

The export block itself isn't usually of human interest. Under what 
circumstances would you want to read it? If you've got the block, it's 
usually from a keyserver or website that would declare the full key details, 
including fingerprint, if requested.

> I did get this to work:
> $ gpg --no-default-keyring --keyring ./bogus --import a_foreign_key
> $ gpg --no-default-keyring --keyring ./bogus --list-keys
> $ rm bogus bogus~
> will show the userID, but isn't there an easier way?

If you want to store exported keys in text files (for some unknown reason), 
just use the name of the text file to identify the key(s) inside. (I do this 
sometimes for users whose keys keep getting mangled by keyservers.)

-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : /pipermail/attachments/20040201/5884390d/attachment.bin