Add on-card key generation

[trishankatdatadog]

Thanks for the PR, @hush-hush! Hahaha, looks like merging is blocked until all commits are signed. I'll sign the merge, should be good then.

Also, the issue is more complicated than I thought. With the default gpg key generation, the master key is set for both [S]igning and [C]ertification, and there is a subkey each for [E]ncryption and [A]uthentication.

Note that is no separate [S] subkey. This means that the master key has to be stored on the Yubikey itself for signing. If your Yubikey is stolen, and attackers know your PIN, they can thus do more damage than the case where the master key is not stored on your Yubikey, IIUC.

I think a hybrid solution is needed: combine the usability of on-card key generation, and the security of manually adding an [S] subkey. This should not only still save a lot of time overhead, but also prevent the master key from being stored on the Yubikey.

I'll try this hybrid approach out later to see if it works. Someone also please correct me if I misunderstood the security of the default gpg key generation procedure.

[trishankatdatadog]

The default gpg key generation procedure also sets the same expiration timestamp for the master key and all subkeys in the public key, but I think this is acceptable.

[trishankatdatadog]

Using the master key for signing might also have a usability headache: you might also need to use your passphrase, beside the Yubikey change / user PIN. @hush-hush, would you mind testing this?

[trishankatdatadog]

Sorry, @hush-hush, but after long discussion with some security folks who have been burned by this, I have decided to forgo on-card key generation. This is because they say it does not actually export a backup of the private keys themselves (otherwise, the whole point of on-card keygen would be lost, they say). As painful as it is, by-hand keygen seems to the most secure long-term approach.