GPG keys for multiple email accounts

[atair]

Thanks for the replies,

On 7/6/13, Hauke Laging <mailinglisten at hauke-laging.de> wrote:
> That's a strange argument for several reasons. The most important being: Why
> should just one key be compromised if they are used on the same system?
> Wouldn't it make more sense to put the saved effort for creating 19
> additional
> keys into securing the system, making it less probable that the key gets
> compromised?
ok, I agree
>
>
> Even with the default settings a 19-digits passphrase (upper and lower case
> ASCII letters and digits) is as hard as AES (without flaws). If the
> passphrase
> is completely random then it is ridiculous to make it longer than 19 chars
> (unless you store it in two halves (with about 18 chars each) in different
> places).
As Heinz Diehl pointed out, it seems not to be that simple.
Additionally, with "20-40 chars" I did not mean a pure random char
sequence but a more memorable sequence of words ("phrase"), e.g. by
using diceware method and the Oxford Advanced Learner's dictionary,
thus, the idea to use a relatively long/up to 40 chars passphrase.
>
> My recommendation:
> Separate keys by email address type:
>
> a) private (one group)
> b) each business separate
> c) each organization separate
>
> Also separate the private addresses by
>
> a) security level (some may not need OpenPGP at all; some may be read via
> webmail others only on systems you control)
> b) seriousness (hauke.laging at example.org maybe should not be grouped with
> superman123 at rpgchat.example.net)
So, following your suggestions, I (c|sh)ould do:
1.1. create one master key for signing on a save environment e.g. live
CD, USB flash disk.
1.2. the expire date is set to several years and
1.3. a backup is placed on an immutable/secure media.
1.4. no user ID is added.
1.5. the passphrase is a word sequence of 40 chars length.
2.1. create sub keys for sign and encryption with an expire date of two years.
2.2. use the same passphrase for all sub keys
2.3. the passphrase has a length of 20 chars (maybe sequence of words,
but nobody knows that it's not pure random). otherwise use a pure
random sequence with smaller length.
2.4. add a fake UID that identifies the domain of the key (business,
private organization,..); other possibility: create a UID without the
'@', such as "my_name__TheOrg01.org" and the people who use the key
know that the first '_' has to be replaced by '-' and the "__"
replaces the  '@'.
2.5. sign those keys by the master key.
2.6. publish/hand out the public sub keys to the respective
sender/recipient group of people.
>
>
>> Does it create problems to attach a fake email
>> address to the key (e.g. @example.com)?
> Problems like not being taken seriously?
Would it be really that grave? If persons know and trust you, they
sign your key (and you may explain, why you use a pseudonym). These
persons may know other persons in person etc.
So, for the NoT I think it doesn't really matter. However, people you
meet for the first (and maybe only time, e.g. on a key signing party)
could refuse to sign the key, since they don't know whether it's
really your key that you want them to sign.

-- atair