Subject: [Acme] More specific error codes for certificate revocation, at least for some cases?

From: Felix Fontein <[email-masked]>
Date: Tue, 12 Jun 2018 23:04:18 +0200

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

---

From: Daniel McCarney <[email-masked]>
Date: Thu, 14 Jun 2018 09:49:33 -0400

> revoked. On the other hand, the Pebble testing server simply returns a

Pebble also returns a malformed problem for this case as of
https://github.com/letsencrypt/pebble/commit/c0cc64314be427c6d39679e95a7794c89a293912
- Thanks again for flagging that!

On Tue, Jun 12, 2018 at 5:04 PM, Felix Fontein <
felix=[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>