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

[Hauke Laging]

Am Do 13.12.2012, 11:03:07 schrieb Roy Sindre Norangshol:

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

Sure you will. But that has nothing to do with my argument. There are 
arguments against giving the main key decryption capability (because you do 
not control what is encrypted for this key). But as you completely control 
which signatures you make I don't think there is any serious argument against 
signing capability.


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

OK but you unnecessarily limit your benifit of this higher security to 
certifications. Why?


> > Security is much better with a card reader which has a PIN pad.
> 
> Any recommendations?

I have a SCM Microsystems, Inc. SPR532 PinPad SmartCard Reader. I have never 
had problems with it. It seems to me that this is a popular product among 
GnuPG users. This is the only card reader I have used so I cannot compare it 
to others.


> cryptostick was recommended by fellow friends at the
> university as it was open source and fully open.

Doesn't replace a PIN pad...


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

They will not be able to steal the key from the stick, that's correct. But the 
attacker is capable of using the stick without limit.

Unfortunately (I don't know the reason for this policy difference) the same is 
true for PIN pads and encryption. But for signatures the damage can be 
limited.


> It just sounds weird for me having to renew the encryption key, what about
> old documents encrypted with the old subkey?

I don't understand the question. The expiration date is relevant for the 
public keys only. OpenPGP applications refuse to encrypt for an expired key. 
But you can always use it for decryption.


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

Of course. That's why you create a key with subkeys which have limited 
security. That is perfectly OK. The key security has to meet the key usage and 
it should be well known to anyone who is affected. The aim of keys is not to 
increase the security requirements for the respective application.


> Is it that bad? You could simply revoke the identity if you no longer use
> it.

You lose the certifications for this UID which may damage your position in the 
Web of Trust.


> I'm just afraid if I choose a too complex setup I end up not using it
> at all.

I don't see that risk. Why should you not use OpenPGP or use it less just 
because you have an additional UID? Or because your key has a policy URL, 
preference settings and a mainky with signing ability? The only possible 
problem I can imagine is that you fail in creating such a key (which is very 
improbable IMHO). But after creation all that does not make a relevant 
difference in everyday use.


> Not able to generate a own dedicated subkeypair for encryption if the
> requirements shows up for using encryption at work?

No. You are capable of generating a new subkey for encryption but you cannot 
generate one which is dedicated to work. Usually the newest subkey (the one 
with the newest self signature) will be chosen by all senders (both to your 
private and work account). The UID bound preferences don't cover the subkey to 
be used, just the symmetric cipher.


> > • 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)

I still suggest that because I promote all keys to have this structure. So 
even if especially you don't have to be afraid of problems you can still be an 
example for others.


> > • 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?

I am not sure what you mean by "fetch signatures". You can have them verify 
and publicly certify your key, that's not a problem. And you can verify their 
keys and even certify them: either locally or regularly as long as you don't 
export your signature to anyone.

My general advice is to create a dedicated key for local signatures because it 
is quite unconvenient to always have to use the real mainkey in a secure 
environment. My strategy is: Use the lsign key for making other keys valid 
quickly (just for yourself) and use the safe mainkey for active participation 
in the Web of Trust.


> > • If you create two keys then create your work key with your personal key
> > as designated revoker
> 
> Still thinking about this one.

I would guess that your thinking has not brought up a single good reason for 
sharing one key with personal use and work.


Hauke
-- 
☺
PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 572 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20121213/a890ce3f/attachment.pgp>