You are using the expression "zero-knowledge proof" but it does not mean what you believe it to mean.
A ZKP proof is a kind of cryptographic protocol by which a Prover demonstrates to a Verifier a given property on a secret value. The proof is "zero-knowledge" if it does not divulge any extra information to the verifier. For instance, suppose that there is some secret integer x, and a publicly known value gx mod p for known integers p (a big prime) and g. The prover wants to demonstrate his knowledge of x; he could do that by simply showing x to the verifier, but that would divulge x to the verifier, and this would not be "zero-knowledge". The protocol described in the Wikipedia page is a ZK protocol which achieves the desired result.
Thus, a "zero-knowledge proof" is not some weaker kind of proof. It is actually stronger (or at least "better" in that it resists verifier impersonations). You seem to oppose ZKP with a simpler "show-the-password" kind of authentication which you sort of assume to be "stronger" or "more authenticating" in some way. In that you are sorely mistaken. I thus assume that when you are talking about "zero-knowledge", you are in fact thinking about something else which has no actual similarity with what is normally designated by "zero-knowledge".
Certificate renewals may use the same public key than the previous certificate, or a new one. If the same key and name are used, then the operation can be done from the CA side without actually talking to the certificate owner: this is just automatically extending the association between the user's name and his public key.
The revocation system as used in X.509 is in fact equivalent to very short-lived certificates which are automatically renewed on the CA side. In "true X.509" formalism, a user's certificate is really the combination of the certificate itself and a fresh enough CRL or OCSP response, and the CA "renews" the latter on its own accord.
If you renew a certificate with a new, distinct public key, then you need to make sure that the new public key is indeed owned by the user. Some authentication, explicit or implicit, is then required. This can be a show-the-password protocol; this can be a renewal request signed with the previous certificate; there are many possibilities. Risks attached to such a procedure are the same as usual: impersonation by an attacker.
Issuing the new certificate based on a request signed with the previous one makes people nervous, because this means that if an attacker steals the previous private key, he can use it to obtain a new certificate with his own key pair, thus extending arbitrarily his illegal access. This really begs the question of why you are "renewing" and what you really expect out of such an action. In general, a user should want to change his key pair because he no longer has access to the previous one, or it has become too weak with regards to cryptanalytic advances; in that case, the user should be, by definition, authenticated again with something else than his knowledge of the previous private key.
Revocation is an emergency mechanism meant to contain the damage resulting from a potential private key theft. As explained above, revocation and renewal are two facets of the same thing; revocation is equivalent to a refusal to renew. As such, it is supposed to be a rare occurrence, triggered by an abnormal situation. You don't want to make it complex for the user, otherwise they won't report key theft. In particular, don't say or even let it be assumed that revocation is expensive and/or will result in some black mark or otherwise negative reputation attached to the user. Otherwise, nobody will ever report potential key theft, and things will be worse.
The main risk in revocation is thus underreporting. However, overreporting can also be an issue if anybody can trigger the revocation of anybody else's certificate; there is a potential for DoS. The usual trick is to make reporters responsible and to handle massive attacks heuristically:
- When a private key theft is reported, make it signed by whoever does the reporting, and keep an audit trail.
- If too many thefts are reported in a short time, trigger alarms, wake up sysadmin, and enter crisis management mode.
In any case, if the private key is (potentially) stolen, then all certificates which are still valid at the current date and contain the corresponding public key must be revoked. Expired certificates need not be revoked. That's indeed the point of expiring: to keep revocation information small.
Unrevocations: well, don't do that. It does not work reliably, or at all. You can renew: just do it. You can renew with the same public key if you can come to the conclusion that the private key was not, in fact, stolen. In any case, revocation is an emergency mechanism and we are in inquest mode.
(From your description it seems that you are trying to use revocation as a kind of authorization mechanism. This rarely ends well.)