GnuPG Key Plan

After much reading and analyzing the issue of re-keying (again!). I've come up with a plan for my GnuPG key security to help put some predictability in my key management.

• ~week - 2011/04/20-2011/04/22 Generate and put in place an RSA 3072-bit primary keypair.
• ~month - 2011/04/20-2011/04/30 Generate ECDSA NIST P-384 and ECDSA NIST P-521 primary keys
• ~19 years - 2030 Migrate to new ECDSA keys and revoke the RSA 3072-bit key marking it superceded.

I will put in active use my 3072-bit keypair for compatibility reasons and the fact that it should be adequate, per NIST SP800-57 Part 1, for beyond 2030. To better future-proof in case of a strong attack against RSA that compromises 3072-bit keys, I will put into practice key-signing where possible my ECDSA P-384 and P-521 keypairs. I have chosen to use 2 additional keypairs in order to better prepare for possible stronger attacks in the future. ECDSA for OpenPGP is currently an IETF draft in its 8th draft (last 7 drafts not touching ECDSA definitions)

Management of Multiple Primary Keys

With regards to key management, I intend to avoid publishing the P-384 and P-521 keys for the fact that I do not know which I will be using in the future and do not want to clutter the keyservers with keys that I will not be using in the near future. I will test key signing with at least the released version of GnuPG (2.0 series) to see if it can sign ECC keys (even though it will not likely be able to do anything with them)... hopefully this will reveal that the key management process is somewhat blind to key contents. Assuming no better mechanism arrives by the year 2030, I will probably transition to either the P-384 or P-521 ECDSA key. I intend to follow the NIST publications to watch for adjustments to the guidelines on RSA key usage for signatures.

Key Signing Policy

I will also write a key signing policy to be attached to signatures issued by my keys. One feature that I hope to be able to write in is a reasonable mechanism to commute the signature to another of their keys with a lesser level of authentication than initial key signing. Given that obtaining key signature authentication is quite a challenge in Indiana, I want to make it practical to walk keys forward instead of an extra "ordeal" to get keys resigned. I intend to read published key signing policies to come up with one that provides good practices with practicality.

Key Publication

All of my keys will be published on my primary web site at http://www.eharning.us/gpg/. My active keys will be published to the key servers through hkp://keys.gnupg.org and also independently to the PGP Global Directory. I intend to keep the naming the same beyond moves to other web page management systems for uniformity. I will also publish the key signing policy underneath that (eventually at http://www.eharning.us/gpg/key-signing-policy/). I will be signing the markdown content generating the key-signing-policy and hopefully publishing it linked directly in the web site for verification. What good is a policy if you can't verify who wrote it!