First steps with GPG, am I off to a good start?

[Daniel Kahn Gillmor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20131010/aa357e36/attachment.sig>