It is generally the case that a request to revoke a certificate also means "and don't issue any others exactly like it". Especially in the case where one ACME client is revoking a cert originally issued by a different ACME client, by virtue of demonstrating control of the identifiers in that cert, the revoking client probably doesn't want the other client to be able to simply reissue the cert via authorization reuse.
We should consider treating all revocation requests as also requests to deactivate or revoke the corresponding authorizations that allowed that cert to be issued.
Details to work out:
- Do we use status "deactivated" or status "revoked"? Choose a different one depending on whether the revoker is the original issuer or not?
- Given our current database schema, what's the easiest way to map a certificate back to the order which resulted in its issuance, and therefore to the authzs which need to be deactivated?
- Should we do a wider search for other potential authzs for the same identifier, and deactivate/revoke those as well?
It is generally the case that a request to revoke a certificate also means "and don't issue any others exactly like it". Especially in the case where one ACME client is revoking a cert originally issued by a different ACME client, by virtue of demonstrating control of the identifiers in that cert, the revoking client probably doesn't want the other client to be able to simply reissue the cert via authorization reuse.
We should consider treating all revocation requests as also requests to deactivate or revoke the corresponding authorizations that allowed that cert to be issued.
Details to work out: