A few newbie questions, I'am doing this right?

[Roy Sindre Norangshol]

On 12/13/12 at 02:21am, Hauke Laging wrote:
> Am Mi 12.12.2012, 19:28:18 schrieb Roy Sindre Norangshol:
> 
> > I'm trying to setup my gpg setup properly for the first time, and wondering
> > if this setup seems fine:
> 
> "Best practice" is often subjective.

Indeed, fighting between security vs usability.

> 
> > Master keypair with only the «certificate» as it's only role, this master
> > keypair I'll only use for:
> > 
> > * signing someone else's key
> > * creating a new subkey
> > * revoking a subkey
> 
> I would add signing ability at any rate and (depending on the circumstances 
> perhaps) even encryption. This allows you to make very secure signatures. This 
> is very useful for a key policy document (--set-policy-url).

I was orginally only thinking of having 1 main key pair, hence having the main
key with certificate ability.  Signing I will do with my assigned signing
subkey. 

> 
> If you do not have another key another key which is more secure then your 
> mainkey allows you encrypt data more safely which from time to time can be 
> useful.

I don't, my plan was to have the main key to be this most secured item, which
have the ability to create myself a new subkeypair if I've been unlucky and
compromised. 

> Full disk encryption does not make a system secure. Get a safe boot medium. 
> (And store it physically secure... ;-) )

Not a bad idea :-)

> 
> 
> > (planning to buy a cryptostick[2] after new years)
> 
> Security is much better with a card reader which has a PIN pad.

Any recommendations? cryptostick was recommended by fellow friends at the
university as it was open source and fully open. And if using a cryptostick,
even if attaching it to a compromised computer they will never be able to
access the private key, so that's why I'm thinking of ordering one. 

> 
> > So I've created 3 seperate subkeys for each role:
> > 
> > * sign (2y expire)
> > * auth (2y expire)
> > * encryption (never)
> > 
> > I assume two year expire on sign and auth is good and requirements me to
> > redo sign and auth subkeypairs every each year to «show I'am alive and
> > kicking».
> 
> This can be shown by extending the expiration date of existing keys, too. One 
> argument for expiration dates is that they stop others from using your key if 
> you have lost the private (main) key. I use a time limit of one year.
> 
> 
> > Encryption is set to never, if it gets compromised I'll have to
> > reencrypt all my stuff that I want to keep safe anyway and wipe existing
> > old copies.
> 
> This has nothing to do with the expiration date, does it?

It just sounds weird for me having to renew the encryption key, what about old
documents encrypted with the old subkey? Kind of usabilty vs security. 

> 
> 
> > Encryption key I will only have at home, laptop and server
> > stationed at my parents (used for mutt) which are all fully encrypted.
> 
> The real danger should be online attacks. I would not consider a system secure 
> which is used for WWW or email.

Again a usability vs security, if I want to start using GPG actively I don't
want having to write my email at my local pc, encrypt it and send it over to my
private server to attach it.

> 
> 
> > I've attached two identities (roy.sindre at norangshol.no and my current
> > identity at work.)
> 
> Is roy.sindre at norangshol.no a private address? In general I would not mix 
> private and business addresses within a key.

Yes, that's my private address (first name at last name) and I doubt I'll ever
change that in my life time.

Is it that bad? You could simply revoke the identity if you no longer use it.
I'm just afraid if I choose a too complex setup I end up not using it at all. 

> 
> > I thought I could create two additional subkeys (sign and auth) for use at
> > work for my work identity, in case these subkeys gets compromised I can
> > easily revoke these two keys and create new ones to use at work
> 
> One more reason to create different mainkeys. Subkeys are not bound to UIDs. 
> Both subkeys and UIDs are bound to the mainkey. And what if someone wants to 
> send encrypted mail to your work account? I do not see any advantage in mixing 
> the IDs (and environments), just problems.

Not able to generate a own dedicated subkeypair for encryption if the
requirements shows up for using encryption at work? (if I end up using only one
main key pair)

 
> > Kinda want to properly setup this before attending any kind of signing
> > parties. Thank you in advance!
> 
> Further recommendations for a "proper setup":
> 
> • add a UID without email (just your name and a comment; this will be valid 
> "forever")

Still suggesting this even if I doubt I'll ever in my life time swap out my
private email? (see comment above) 

> • configure a preferred keyserver (--default-keyserver-url)
> • configure a policy URL (even if you write the real document later; --set-
> policy-url)
> • configure your cipher and digest preferences (--default-preference-list)

Thanks for info, I'll dig into the manual and set these. 

> • don't make non-local (lsign) certifications before you have finished your 
> certification policy

Thought of fetching 3 local close co-workers signatures before leaving for xmas
vacation, does that affect the --set-policy-url if set later?

> • If you create two keys then create your work key with your personal key as 
> designated revoker

Still thinking about this one. (in regards of the follow up encryption
question). Anyway a good thing to do if I go for two separate main key pairs. 

> • After key creation make small slips of paper with your name, email and 
> fingerprint and always have some with you, like

:-) 

--   
Roy Sindre Norangshol
roy.sindre at norangshol.no