From the audio part of the talk: Elliptic curves are considerably harder to implement correctly than RSA. DSA has expensive signature verification, and you're far more likely to create one signature and verify it many times than vice versa.

EDIT: Also, elliptic curves are heavily patented. I mentioned this in my talk (the audio portion, not the slides) but forgot when I woke up and started answering questions here this morning. :-)

I'm neither Colin nor a cryptographer, but I think elliptic curve cryptography (1) involves more complicated ideas and code (which might therefore be easier to get wrong), and (2) is subject to more patent claims, than its rivals, without any obvious big benefit to outweigh those facts. [EDIT: oh, and because of 1 and 2 ECC is used less, and therefore your implementation mightn't have had its bugs and design flaws so thoroughly shaken out.]

Certicom has ~130 ECC-related patents. You probably don't want to have to crawl through them all making sure that your code, or someone else's code that you're using, doesn't infringe (and won't be found to infringe by a not-necessarily-infallible jury if you get sued anyway).

[EDIT again: actually, ECC does have a claimed big benefit, namely not needing such long keys. But one might reasonably be worried by the possibility that an algorithmic breakthrough some day might suddenly make longer keys necessary...]

ECC is extremely well studied and implemented almost by default in embedded settings. There are providers of it other than Certicom.

The reality is, you need to consult a cryptographer before you implement any public key system. RSA and vanilla DSA are also spectacularly easy to screw up.

In an embedded environment I would probably use ECC. I believe that I mentioned this in my talk; certainly I mentioned that my advice was for the context of software on general-purpose CPUs.

Unusual environments need special treatment.

ECC vs. RSA is a place where you certainly know better than me; I have that list of things Kaliski said not to do wrong with ECC and very little else. I also think we probably don't disagree very much about ECC.

Where I know we do disagree: public key crypto is a threshold over which I would not be OK implementing a custom cryptosystem. If I need public key, it's GPG or nothing. I am terrified of public key crypto.

I didn't intend for my audience to be implementing everything themeselves. Knowing that OAEP is better than PKCS padding is useful even if you don't write a single line of code, because it helps you select the right library to use.