I agree with both s7r and Lunar here. Just want to add some bits:
I disagree with your approach, for comparison's sake, let's say v2 is IPv4 and v3 is IPv6. When IPV6 was introduced, IPv4 was kept around (and still is to this day, although IPv6 is arguably a much better solution in a lot of areas). Expecting _everyone_ to just switch to IPv6 or get cut off is a bit of a pipe dream.
The main goal of Tor Project is privacy and security _for everyone by default_. If Tor is going to end up like PGP... it's a nightmare. ["Hey, are you using new onion or old onion?", "Hm, I don't know. Maybe it's better to go with normal Internet? At least it works.".] If you don't care much about security/privacy/anonymity and look for a "crypto-identified network" with NAT traversal - Tor is not _the_ network you're looking for. And yes, IPv4 is still around since it's "just technology" and isn't tied to security. One can use outdated technology (I do, a lot) but not use _outdated security_ ["outdated security" hardly can be called security - a white horse is not a horse]. So ISPs can use IPv4 for any reason until the Sun become a supernova and may not care about CGNAT and all this crazy stuff - it doesn't _threat_ anyone* except their budget.
Tor hidden services are a bit "special" because it's hard to poll their owners on their intentions. Some hidden service operators have gone to great lengths to advertise their .onion URLs (v2-style), some have even generated vanity addresses (like Facebook). Forcing a switch to v3 at some point presents a very interesting opportunity for phishing because suddenly a service known and trusted at some address (as opaque as it is) would need to move to an even more opaque address, with no way to determine if the two are really related, run by the same operator, etc. If I were a LE agency, I would immediately grab v3 hidden services, proxy content to existing v2 services and advertise my v3 URL everywhere, then happily monitor traffic.
It's not going to happen. You have v2 private key and your new v3 private key. Now you cross-certify them** and teach your users to use new address. If you've spent zillions of core-hours on generating a nice-looking address on top of RSA1024 (can be factored now[1]) and truncated (!) SHA-1 (someone probably can afford collisions now [2]) - congratulations.
NSA:
Attacks always get better; they never get worse.
Also, one shouldn't rely on secret keys as you've mentioned. It shouldn't be an apocalypse if you lost/compromised your key.
All I'm saying is don't remove the v2 services, even if you choose to no longer support them. Some operators (like my company) may choose to continue to patch the v2 areas if required and release the patches to the community at large. Forcing us out altogether would make us drop Tor and start using an alternative network or expending the additional effort to make our services network-agnostic (so no more good PR for Tor).
No problem, just run your personal Tor network in your corporate environment - Tor is free software. It's not as hard as you may think. And you're always welcome to contribute back. Also it's good since you may find out some edge-cases or complicated bugs that could harm The Tor Network at some point. Just for the record, probably a good choice for your use case here is to stick with cjdns [3]. It provides IPv6 "cryptoaddress" and mesh networking and other cool stuff. You don't have to have authorities and don't have to use OnionCat. It just works. But it's different from Tor in many ways. The major difference - it's not anonymous.
* Yes, it does break end-to-end principle and makes the Internet less fault-resistant etc, etc. Anyway, the Internet is already broken. Deal with it. ** It definitely needs a proposal. :) Maybe I missed one? Something like xxx-rsa1024-rend-id-migration.txt.
[1] https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf
https://media.ccc.de/v/32c3-7288-logjam_diffie-hellman_discrete_logs_the_nsa... [2] https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html [3] https://github.com/cjdelisle/cjdns -- Ivan Markin