best practices for creating keys

[Peter Lebbing]

On 23/11/15 17:20, James wrote:
> If you create a primary key, upload it to a public
> keyserver and later decide: "hrm, my public key should really only
> certify, not sign," it's a bit too late. (although not impossible,
> difficult to change ex post facto).

Okay, so let me answer this one detail:

Separating encryption from signing is a general advice (and done by
default) because there is a range of subtleties that are avoided by this
simple action. This affects how your keys are actually *used*, not *usable*.

However, one who has access to the private part of the primary key can
easily change the capabilities of the primary key to add signing as a
capability, even if you had it removed. There is not enough reason to
separate certifications from data signatures to make it the default.
Whether there is reason at all from a cryptographic standpoint, I do not
know. But it is certainly nothing to be worried about, or it would have
been dealt with in the defaults.

Also, let me quote and answer a part from an earlier mail you wrote:

> My concern is that if my primary key is for certification only, how
> would it sign other people's certificates to expand the web of trust?
> I suspect that if the capabilities are set to _only_ certify, I would
> need to sign other people's keys using my subkey.

No, signing other people's keys is known as certification, and is
something that can *only* be done by the primary key. If you have an
offline primary key, you would use an offline system that has the secret
part available to sign other people's keys, and then transfer the
signature from that offline system.

Or if you only delete the primary key from your laptop but still have it
on your desktop, you'd use the latter. For that setup, you could create
a signing subkey for your laptop to use without removing signing
capability from your primary key.

> It's also worth noting that the suggestion to remove the primary key
> from your laptop isn't thrown up on a few random blogs; instead it is
> something that other projects[1] encourage.

Yes, well, most importantly, maybe their threat model is different. In
this specific case, note that a signature by a Debian developer means
that, by and large, any Debian machine on the planet will trust the
software update that that signature validates and install it on the next
system upgrade. That's quite an important signature.

Normally, a Debian dev can only upload source code, not binaries, but
it's still a significant amount of power.

> If one's primary key is his or her identity, I'd like to be certain
> that I correctly create the key(s). Thus being meticulous and careful
> in creating primary key seems like a reasonable step, IMHO.

Yes, but the defaults are sane, so there's no need to fiddle with things
that are different from the defaults. It's all the other stuff you
should be meticulous about.

Furthermore, all is not lost if you wish to swap your primary key. Many
people will accept a transition statement and issue a signature on your
new key. Also; the Web of Trust is overrated, and you can probably
persuade your friends more easily to recertify.

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>