best practices for creating keys

[Robert J. Hansen]

> The same can be said for almost any complex system, software or not.

Absolutely.  Please don't misinterpret what I said as trying to dissuade
you from curiosity.  I'm just urging you to not let your curiosity lead
you into making poor decisions from the get-go.

The following anecdote is meandering, but if you'll bear with me for two
paragraphs it'll make sense:

I live in the United States, in a state which allows private citizens,
under incredibly close regulation, to own military firearms.  When I
visit the rifle range, sometimes I'll spend some time with a suppressed
German-made MP5SD3 submachinegun.  (It's not mine: a friend owns one and
we sometimes hit the range together.)  It's a nice piece of kit; I like
it.  And quite often, other people who are at the range want to talk
shop about it.  We get into discussions about roller-locked firearms
like the Cz52 and MG42 versus roller-delayed firearms like the MP5, how
annoying it is when people get the terminology wrong, whether it's a
good thing or a bad thing the MP5 uses a fluted chamber, how anyone who
thinks it's okay to fire subsonic 9mm from the MP5 needs their head
examined, and so on and so on.  And it's fun, as far as it goes, and
it's often educational for the people who've never seen an MP5 before
and are fascinated to learn more about its inner workings.

It's great -- up until they think they know enough to use an MP5 on the
range, despite the fact they've never fired a weapon before.  At that
point we have to explain to them that look, yes, they know a lot more
about the MP5 than most people do, but really, they need to start off
with something small, like a nice .22 Ruger Mk II, develop the basic
skills, learn trigger discipline and proper usage of safeties, learn how
the range operates and what the various calls by the Range Safety
Officers mean, etcetera.  There's a huge amount to learn: they don't
need to make things worse by leaping straight over this stuff straight
to firing fully-automatic military hardware.  That's just imprudent, and
we'd be awful human beings if we permitted them to do that.

That's what we're talking about here.  The knobs and dials on GnuPG are
great fun to learn about: you're in good company!  But there's a big
reason why we're urging you to not do what you want to do, and that's
because you're not yet competent to do what you want to do.  We'd rather
see you start off with small steps, and from there move on to the big
ones, than have you start off big.

Admittedly, it's highly unlikely that screwing up with GnuPG will lead
to a magazine of 9mm being sprayed around the room.  But it's the
principle of the thing.  :)

So: for now, please stick with the defaults.

> It seems to me that, perhaps, making these sorts of decisions up front
> is of some value.

Not really.  It's probably not worth worrying about.

> 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.

No.

One of the important skills to learn early on is about how to migrate a
certificate.  You're going to make mistakes.  You'll forget passphrases,
you'll compromise your keys, you'll realize you made a hash of it and
need to start over again.  How do you recover from this?  How do you
communicate a change-of-certificate with your correspondents?  Etc.

The only reason to think "it's a bit too late" is if

	a) you're not allowed to change your certificate -- you
	   *must* keep the same one for the next X years
	b) you don't know how to migrate to a new certificate

There are almost certainly people and groups for whom (a) applies.  If
you're one of them, please let me know.  But if (b) applies, then I
suggest learning the skill, because it's important.  :)

> 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.

That wiki page is guidance *for Debian*.  Debian has some very specific
operating restrictions which are unlikely to apply to you.  The
guidelines Debian put together apply to them, in their environment,
facing their threat model, which they defend with their particular set
of resources.

It is not guidance for you, unless you're part of Debian.

By all means, study it!  It's a well-written policy.  Learn what goes
into their policy and why they make the decisions they do.  But don't
think that what they recommend will automatically apply to you.  Some of
it will be applicable; a lot of it won't be.

> If one's primary key is his or her identity, I'd like to be certain
> that I correctly create the key(s).

Yes.  And, as several people here have told you, you correctly create it
by running "gpg --gen-key" and accepting the defaults.