On 10/10/2013 09:32 PM, Hauke Laging wrote: > Am Fr 11.10.2013, 01:25:50 schrieb Robin Kipp: > >> Invoked addkey to generate a 2048 bit RSA sub key, with >> encryption and signing capabilities. > > It seems to me that the more accepted recommendation here is to have separate > subkeys for signing and encryption.
This is absolutely correct. You should not be re-using the same RSA key for two different usages if at all possible. See, for example https://www.schneier.com/paper-chosen-protocol.html You can fix this by simply revoking this subkey and adding two new subkeys, one for encryption and one for signing. GnuPG will automatically select the right one to use for whichever purpose. > I know of no good reason for creating a mainkey without expiration date. I also agree with this. An expiration date of 3 years is reasonable. If you're using the key actively and you do not believe it has been compromised two years later, it should not be much extra work to extend your expiration date for another two years. The expiration date on your primary key gives you a failsafe endpoint in the event that you lose all copies of your secret key material and your revocation certificate. (you do have a revocation certificate generated and stored someplace safe, right? i didn't notice that in your list of steps) You can resolve the lack of expiry on your primary key just by setting an expiration date directly with: gpg --edit-key 0x22581BA6DC329876 expire You can make your revocation certification with: gpg --gen-revoke 0x22581BA6DC329876 store it in a safe place! > Furthermore it would be nice to have a UID without email address but with a > comment which explains the security of the key. Something like > > "Robin Kipp (normal security level subkeys with offline mainkey)" > > This should be explained in more detail in a key policy which you should make > publicly available and put its URL into the self signatures (see --set-policy- > url) for the UIDs (and maybe even the subkeys). You should also set your > preferred key server in the selfsigs (--default-keyserver-url). I disagree with these last recommendations from hauke. Take that as you will. I don't think such policy information in the User ID is particularly useful to other people (i'd be interested to hear of a situation where that communication actually changes peoples actions and where it can only be made through the User ID as opposed to, say, on a web page, a blog post, in-person communication during keysigning, etc), and adding comments like this to the User ID makes it more difficult for others to decide whether to certify your key (since they may not be able to verify the claim you're asking them to assert). Implementing and abiding by nuanced policy documents that you set forward in your policy-url also doesn't seem worth the labor, complexity and maintenance involved, since the advantages it provides (either for yourself or for others) are not clear. Questions to ask yourself: Have you ever checked someone else's policy URLs? what would you do differently if you could check them? have you ever audited the claims of someone's policy URL in any way? Lastly, do you even have a preferred keyserver? if not, setting --default-keyserver-url doesn't make any sense in the first place, and you should just use the global pool. Even if you do have a preferred keyserver, including such a keyserver URL in your self-sig is in some senses equivalent to a "web bug": you're asking the user of the key to make a call to your preferred server when they access your key. People who do not want to have their activity tracked will probably set no-honor-keyserver-url in their ~/.gnupg/gpg.conf, and will expect to get updates from arbitrary members of the public keyserver network, or from their own preferred private, non-logging or otherwise privacy-preserving server that is peered to the public keyserver network. i hope this analysis is helpful, --dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
