Then I realized I harped on CERT not too long ago about not doing things right. =) Granted, my key hasn’t been compromised and I have no established schedule for rotating keys, but 6 years is a long time. So I’ve generated a new key, and revoked the old key. Direct link to the new key/revocation certificate: http://linsec.ca/vdanen.asc”.

It has been signed with my old key and a few others. If anyone out there has signed my old key (0xFEE30AD4), I would surely appreciate you signing the new key as well. I think a trail of trust has been established with the new key. The particulars:

pub   2048R/B86380FC 2010-09-29 [expires: 2013-09-28]
uid                  Vincent Danen 
sig 3        B86380FC 2010-09-29  Vincent Danen 
sig          FEE30AD4 2010-09-29  Vincent Danen 
sig          CA57AD7C 2010-09-29  PGP Global Directory Verification Key
sig          CA57AD7C 2010-09-29  PGP Global Directory Verification Key
uid                  Vincent Danen 
sig 3        B86380FC 2010-09-29  Vincent Danen 
sig          FEE30AD4 2010-09-29  Vincent Danen 
sig          CA57AD7C 2010-09-29  PGP Global Directory Verification Key
uid                  Vincent Danen 
sig 3        B86380FC 2010-09-29  Vincent Danen 
sig          FEE30AD4 2010-09-29  Vincent Danen 
sig          CA57AD7C 2010-09-29  PGP Global Directory Verification Key
sig          CA57AD7C 2010-09-29  PGP Global Directory Verification Key
sub   2048R/729BAAE4 2010-09-29 [expires: 2013-09-28]
sig          B86380FC 2010-09-29  Vincent Danen 

And the fingerprint info:

pub   2048R/B86380FC 2010-09-29 [expires: 2013-09-28]
      Key fingerprint = 786F 8AA3 A608 8CA2 33A3  4D8E 5179 17ED B863 80FC
uid                  Vincent Danen 
uid                  Vincent Danen 
uid                  Vincent Danen 
sub   2048R/729BAAE4 2010-09-29 [expires: 2013-09-28]

Neato… wordpress hides email addresses, so the above output is missing any email addresses listed. I’ve also sent the new key and revocation of the old key to the keyservers.

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 cert@cert.org and generate my own key with the uid cert@cert.org 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:

1. 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
2. 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?
3. 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”
4. 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?

And if you want to get more into the guts and glory of using GPG, you can read the article I wrote quite a few years ago on Using GnuPG. Like a few of the other articles on linsec.ca, that one could probably do with a bit of a refresher, but I don’t think any of it is necessarily out-dated.