Several master keys vs. master key and subkeys

[Martin]

Hi everyone,

really sorry to ask so many stupid questions. I'm planning to write a nice
howto guide when I finally figured everything out, but before I can do that
I need to know what I am talking about :)

I want to have one master key with a super strong passphrase, which will
never expire and will basically never be used except for building my web of
trust. For every day use I would like to have subkeys which will expire
every 2 years.

So far I understand that GPG can create subkeys and I have found the
following two articles to be very good:

https://alexcabal.com/creating-the-perfect-gpg-keypair/
http://wiki.debian.org/subkeys

I have to say that the part about removing the original signing subkey
(whatever that means) seems to be a bit confusing.

After a while I stumbled upon this post:

http://www.davidsoergel.com/gpg.html

This person claims that subkeys are not the best option because:

### QUOTE ###

Disadvantages of subkeys:

* I find them Confusing.
* There are disturbingly many (i.e., any at all) bug reports on the web
about gpg software handling subkeys incorrectly.
* It is possible to export a subkey and attach it to a different primary
key, creating a potential security hole.
* No ability (without a lot of hassle, anyway) to use different passphrases
on primary and subkeys.

### ENDQUOTE ###

Is this really true? Do subkeys have the same passphrase as the master key?
I find this quite hard to believe.

I would like to know if David Soergel's approach has any flaws. As I
understand it, it works the same as using real subkeys, I would create two
normal keys, declare one to be my master key and one to be my first subkey.
Then I would sign the subkey with the master key which would enable me to
create a revocation cert for this subkey later, if needed?

Any reasons why I should stick to GPGs "native" subkey feature?

Many thanks for your help in advance!

Best regards,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130716/f9597476/attachment.html>