For 99% percentage of all setups involving tunnels like this, key revocation (ala OCSP) is a security risk, not a solution. If your standard blindly requires o

For 99% percentage of all setups involving tunnels like this, key revocation (ala OCSP) is a security risk, not a solution. If your standard blindly requires or encourages this, what it's in effect encouraging is a much more complex and hard to audit set up that can much more easily include human error. As in, I've actually seen that happen. It's just waaaay to easy to have somebody, somewhere screw it up. Worse, you probably don't have full access to every agent in communication network like that, and if only one party messes it up... So sure, if you're running a public service with all kinds of semi-anonymous users that have no preexisting side-channel, then you may really need all that infrastructure. But guess what? Most problems aren't like that. If you're just setting up a secure channel between a small set of known-in-advance actors then leverage that simplicity! You probably already have some pubkey based channel between them, so you don't need another one! KISS. You should probably be using a shared token, not an asymmetric key, and definitely no revocation... if your system is simple enough to get away with that.