When encrypting a file to send to a collaborator, I see this message:
gpg: using subkey XXXX instead of primary key YYYY
Why would that be? I've noticed that when they send me an encrypted file, it also appears to be encrypted towards my subkey instead of my primary key. For me, this doesn't appear to be a problem; gpg (1.4.x, macosx) just handles it & moves on. But for them, with their automated tool setup, this seems to be an issue, and they've requested that I be sure to use their primary key.
I've tried to do some reading, and I have the Michael Lucas's "GPG & PGP" book on order, but I'm not seeing why there's this distinction. I have read that the key used for signing and the key used for encryption would be different, but I assumed that was about public vs private keys at first.
In case it was a trust/validation issue, I went through the process of comparing fingerprints and verifying, yes, I trust this key. While I was doing that, I noticed the primary & subkeys had different "usage" notes:
primary: usage: SCA
subkey: usage: E
"E" seems likely to mean "Encryption". But, I haven't been able to find any documentation on this. Moreover, my collaborator has been using these tools & techniques for some years now, so why would this only be a problem for me?
Update
While the original post below correctly explains why you might want to use separate encryption and signing keys, it does not do a great job answering the question of why you use subkeys instead of the primary key. The Debian Wiki provides a much more thorough answer.
To summarize, your primary key is your online identity, and your identity and reputation are built up by having other people vouch for that key being yours by signing it themselves. (You might think of it like being your Twitter handle, and your reputation being your Twitter followers, or you might object to that analogy, but I hope it gives you some sense of why you want to protect it.) So, since your primary key is super important and is built up over years, you want to protect it very much. In particular, you do not want to store it on a computer that might get stolen or hacked into; you want to keep your primary key off-line in a safe place.
This, of course, makes your primary key very inconvenient to use. So for day-to-day operations you want to use a key that is not such a big problem to replace if it gets compromised. This is why subkeys were invented.
A subkey is still a public/private key pair and is secure as long as only you have the private key. It is, cryptographically, just as secure as your primary key. The difference is that your reputation is only attached to it by your own signature, the signature from your private key. To use the Twitter analogy, the world trusts that you are your Twitter handle because all your followers say so (I know, it doesn't always really work that way, but analogies are hard!), and then with that trust established you can then much more easily convince the world you own your Instagram handle by just tweeting it and people will believe you because the tweet came from your account, which they trust.
You still want to keep your subkey safe, but now if it is compromised it is not the huge problem it would be if your primary key were compromised (or, in the analogy, someone hijacked your Twitter account). Now you can just revoke the subkey and issue a new one by signing a revocation certificate and a new subkey and posting them both on your public keyring (like tweeting "hey, my Instagram handle changed, don't use the old one, use this one instead"). This makes keeping your subkey on your laptop computer a more acceptable risk than keeping your primary key on it.
TL;DR Subkeys make key management much easier by separating the cryptographic functions of public keys from the trust and identity functions of (primary) public keys.
Original post
If you look into the details of the math of public-key encryption, you will discover that signing and decrypting are actually identical operations. Thus in a naïve implementation it is possible to trick somebody into decrypting a message by asking them to sign it.
Several things are done in practice to guard against this. The most obvious is that you never sign an actual message, instead you sign a secure hash of the message. Less obviously, but just to be extra safe, you use different keys for signing and encrypting. Also, keeping the encryption key separate allows you to keep the other arguably more important and definitely less frequently used keys off-line and more secure. That is the case with the keys you have inspected. By the way the flags mean:
Note that in all cases, "key", means a public & private key pair.
This should not be a problem for your friend if he has everything set up correctly, but setting up everything correctly can be more complex than it should be. So it may be that the best solution is for your friend to generate a new public-key that he uses for both signing and encrypting. Like I said, because the primary defense against attack is to only sign a cryptographically secure hash of a message, it is not a serious weakness to have such a key.
Reference for the flags
Alternate reference
Beyond that, I'm not likely to be much help. I've always found PGP/GPG to be overly complex for what little it accomplishes. Good luck.