This is an excellent proposal for an SSL extension to solve the problem of rogue CAs. It's by Trevor Perrin (a former co-worker and great crypto engineer) and Moxie Marlinspike, from Whisper Systems (now Twitter).
The way it works is simple. The admin for a site signs a message that "pins" a given public key to the domainname. This message is delivered by an SSL extension or appended to the SSL cert chain (a hack, but requires no protocol changes).
The pin message states that the public key won't change for a given period. If it changes, a rogue CA has issued a different cert and you are under attack. The browser will reject the session.
The admin can "break" the pin early by signing another message, distributed the same way. Then they can re-pin a new cert. This allows certificate mobility, fully under the control of each site admin.
This accomplishes the same goal as whole-cert pinning (as practiced in Chrome), but with many advantages. First, when you pin the cert (not public key), you don't allow for CA mobility. So if you keep the same server key but get a new cert, this appears to be an attack. Second, you have to notify Google and wait for them to issue a browser update when you do get a new cert. This is complicated and too costly.
Whole-cert pinning is used extremely rarely (not even all top 500 sites) and will never gain widespread adoption.
TACK is an extremely simple protocol, and the messages are tiny. It is very well-designed, and the site has working code on Github in addition to the Internet draft.
Trevor and Moxie are doing great things, so please do all you can to support them in this. It really is one of the few initiatives in recent times to have a huge impact on your family's actual security, as well as dissidents in countries like Iran.
TACK is not competing with Chrome, but with the Public Key Pinning Extension, currently in draft (see http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01). As the name says, they too are proposing to pin public keys, not certificates. I prefer TACK, because it makes sense to solve this problem on the TLS level, rather than on the HTTP level.
EDIT: It's difficult to find a confirmation online, but I recall that Public Key Pinning is already live in Chrome, starting with version 18.
The criticism of Chrome's pinning is still valid though. The pinned key is allowed to show up anywhere in the cert chain, not just at the leaf certificate. Also, they have to pin several CAs, as well as multiple keys per CA to deal with sub-CAs.