I need to design a self service portal for renewing, revoking, and unrevoking a certificate and have come up with the following rules*:


  • Certificates have a short term validity and need to renewed quickly, so most renewals will be automatically approved. Zero knowledge proof is sufficient for the CA to issue a renewal.

  • The CA has the option to require a password after X renewals, or excessive renewals within a short period of time.


  • Only the authorized owner of a certificate can revoke a certificate using a password that was previously assigned

  • If a certificate is lost, in the possession of another user, then allow "good samaritan" revocation. If that user presents a zero knowledge proof to the revocation service, the CA revokes the certificate

  • Revocation automatically revokes all certificates with the same public key, (it's possible to renew a key with or without the same public key)


  • If the certificate was revoked by the user, and not a "good samaritan", then it can be unrevoked using the same portal username and password that previously revoked it.

  • "good samaritan" unrevocations will not be permitted.


Are there any other process flows, threats, or risks to this process I should consider for these three aspects of certificate management as described above?

*Note: This is not for an X509-based system, different crypto primitives and features apply; though some concepts are probably transferrable


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.)

  • 1
    Thank you; for your reference I'm using accumulator-based revocations / unrevocations with ABC4Trust (UProve and Idemix), and Pedersen Commitments to handle when a user is permitted to login (time of day/ day of week). If a prover sends a ZKP to the issuer, then the issuer will authenticate the user and authorize the action for "renew", "good Samaritan revoke". – halfbit Jul 21 '14 at 15:11
  • 1
    The password portion is more for the scenario a user can't produce a ZKP. This can happen if they can't find their certificate/smart card or if they lose it at the bottom of the ocean. If they happen to find the smart card, (similar losing their keys and finding them again) I want to permit the user to unrevoke the certificate, but want to prevent a hostile user from doing so. – halfbit Jul 21 '14 at 15:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.