This seems to be an ongoing saga so now I’m going to vent about it. It is ridiculous that an organization supposedly as secure as CERT can have such poor distribution mechanisms for alerting users of their new GPG keys. It is really important that, when you update GPG keys and distribute the public key that you can easily establish trust of the new key. There are a few ways this can be done: sign the new key with the old (known and/or trusted) key, sign any distribution mails with the old key (to ensure authenticity), include a revocation in the new key to import, and have a secure place where that information can be obtained.
CERT changes keys often — way more often than their once-a-year policy on their web site indicates; well, this year they have anyways. Previous years were one key a year. However, they don’t follow any of these “best practices”. And they know it, because I’ve told them in the past. And yet, even now, they still can’t get it right. What’s more amusing is that on their Sending Sensitive Information to CERT page, which is SSL encrypted, shows two different fingerprints. For posterity, I took the following screenshot:
The wrong fingerprint listed in section #2 belongs to the old key. The key released today is:
pub 2048R/72C33BD5 2010-09-13 [expires: 2011-09-30]
Key fingerprint = 79DA 4C07 0AE5 EB20 D641 3F80 67B1 5F29 72C3 3BD5
uid CERT Coordination Center
sig 3 72C33BD5 2010-09-13 CERT Coordination Center
While the previous key is:
pub 2048R/9A478CA0 2010-03-03 [revoked: 2010-09-13]
Key fingerprint = E9EA E7FB D8AF E5AE FD36 41DE 5146 432C 9A47 8CA0
rev 9A478CA0 2010-09-13 CERT Coordination Center
uid CERT Coordination Center
sig 3 9A478CA0 2010-03-03 CERT Coordination Center
To see how things are getting sloppy, we need to go back a bit further to see what had been done in the past:
pub 2048R/B7FBBBC1 2010-01-20 [revoked: 2010-03-03]
Key fingerprint = 66A6 DAC9 3014 21CB DCA6 A6F6 3389 F064 B7FB BBC1
rev B7FBBBC1 2010-03-03 CERT Coordination Center
uid CERT Coordination Center
sig 3 B7FBBBC1 2010-01-20 CERT Coordination Center
sig AF30D800 2010-01-20 CERT Coordination Center
Notice the difference here? This third-latest key was signed by another CERT-owned key (AF30D800), which was the previous-to-that key used. Trust is then established to the new key, from the old (known) key. The most current and previous keys were not signed by their predecessors, which makes them harder to trust. So in the last three keys, two are self-signed, one is properly signed to establish trust (by the previous key). What’s even more sad is that key AF30D800 was nicely signed: not only by the previous key, but also by a “master key” which also establishes more authenticity of the key:
pub 2048R/AF30D800 2009-06-15 [revoked: 2010-01-20]
Key fingerprint = 943C 0A2E 4CB8 4C8F CA53 22F8 680D 4DC1 AF30 D800
rev AF30D800 2010-01-20 CERT Coordination Center
uid CERT Coordination Center
sig 3 AF30D800 2009-06-15 CERT Coordination Center
sig 18DEBE70 2009-06-15 Networked Systems Survivability Master Key
sig 14C33F57 2009-06-15 CERT Coordination Center
Now this one is a good key, a trustable key. The last two keys are not.
Couple that with the half-updated web page and you’re left scratching your head — or, at least, I was. Not so much this time because, sadly, I’m no longer surprised. But last time I actually phoned CERT to verify the new key’s fingerprint because I had nothing to trust it with. In fact, when the mail came out to notify of the new key, it was signed with the new key, not the old key.
Ummm… excuse me, but I can spoof sending a mail from [email protected] and generate my own key with the uid [email protected] and bloody well sign it with the spoofed key I just generated! The only thing I couldn’t do is update their web page but, honestly, I wonder how many people check. And of those that do, have they done it in the past and noticed prior inconsistencies and just chalked it up to… incompetence? Negligence? Key distribution malpractice?
Again, there is nothing for me to trust that this new key is legit.
It’s sad that an organization built around security has no clue about this. What’s worse, is they’ve been told (twice!) about a better way to distribute new keys. I know. I told them. Both times.
So, to recap, these are things you should do when distributing a new GPG key:
- Sign the email sending out the new key with the old key. Seriously, it establishes trust and proves you are who you say you are
- Fully and completely update your web site. It’s nice you have one, and it’s nice that it’s semi-updated, and even better that you can get to it via SSL. But if it lists the new key in section 1 and section 2 is about verifying the fingerprint but lists the old key’s fingerprint, how do you trust any of it?
- Sign the new key with the old key. It proves that the person/organization who has the old key trusts the new one enough to sign it. Like giving it a seal of approval or just saying “hey, this is legit”
- For Pete’s sake, revoke the old key! It doesn’t have to necessarily be in the same message, but it should be revoked. Heck, send out a mail signed with the old key, containing the new key, and then send out another message signed with the new key, revoking the old key. Or have one email message sending two different GPG-signed sections so one email does it all.
None of this is difficult to do, and it makes trusting these new keys so much easier. I’ve not paid attention to see if other people/organizations fail so badly here, but I don’t get what makes this so hard to do. It’s not rocket science, just common sense. I can see Joe Average maybe not thinking about it, but for an organization like CERT? Come on. How are we supposed to trust what you send out when you can’t even get Simple Key Management 101 right?