Hi, while implementing certificate revocation in an ACME client, I noticed that the current ACME draft is very vague about errors to return when revocation fails. The draft says "If the revocation fails, the server returns an error." (https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-7.6), which is followed by an example which returns urn:ietf:params:acme:error:unauthorized with detail "No authorization provided for name example.net".
When trying this out with Boulder (Let's Encrypt staging), I noticed that Boulder returns urn:ietf:params:acme:error:malformed with detail "Certificate already revoked" if the certificate has already been revoked. On the other hand, the Pebble testing server simply returns a 404 error. I think it would make sense to define more specific error codes the server could return for certificate revocation. In particular, there should be an error code for "certificate has already been revoked" (maybe urn:ietf:params:acme:error:alreadyRevoked?). This would make it easier for clients to detect this specific situations. The rationale behind this is that it allows the client to distinguish between errors which require no user interventions (if the certificate has already been revoked, the action the user wanted to perform did fail, but everything is fine since there is no need to still revoke the certificate), and errors which require user intervention (if the certificate was not revoked, and the user has to do something to make sure it is really revoked, like providing the correct account key / private key). Without a well-defined error, a client author has to guess (or simply assume that every server behaves as Boulder and sends the same error detail). Thank you for your considerations, Felix _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
