A third comes to mind, somewhat similar to Mike's.
If we believe that 1024 RSA is not broken *now* (or at the very least, if it is broken it's too valuable to waste on breaking Tor's Hidden Services...) but that it certainly will be broken in the future - then I can't think of any mechanism that would allow a future system that keeps 1024 bit key-based addresses to be secure...
Without introducing a trusted third party. Imagine if a Hidden Service today were to generate a new identity key, 2048 (or 4096 or whatever) and submit this new key, and its current key to a Directory Server, signed by the 1024 bit key, and received back a signature of the data and a timestamp.
Now, n years down the road when 1024 bit is broken... but 2048 is not - a user enters the 1024 bit address, it goes through all the hoops and connects to the Hidden Service where the HS provides the 2048 bit key and the signed timestamp. The client trusts that the mapping between the broken 1024 and secure 2048 keys is valid because it trusts the directory authorities to only timestamp such mappings accurately, and the timestamp is in 2012 - before the "we're saying 1024 is broken now, don't trust timestamps after this date" flag day.
This isn't about petnames, and from an engineering perspective it's probably much more work than any other system.