Details on revocation about pebble HOT 3 CLOSED

Hi @felixfontein, thanks for opening an issue!

ACME defines no behavior if one tries to revoke a certificate which has already been revoked. Boulder returns error type urn:ietf:params:acme:error:malformed (or urn:acme:error:malformed for ACME v1) with detail Certificate already revoked, while Pebble simply returns a 404.

Hmm. I think we should probably try to match what Boulder does and return a problem rather than simply an HTTP status code. Thanks for pointing that out! (Addressing with #135 and #136)

Are there plans to define a common behavior in the ACME protocol, or will this be left for implementations to handle as they want?

There aren't any active plans to define a common behaviour. You could start a discussion on the ACME working group mailing list about the topic if you would like. I do see that ACME draft-12 Section 7.6 says "If the revocation fails, the server returns an error." with an example urn:ietf:params:acme:error:unauthorized problem response. Is more specificity about the potential errors needed?

When trying to revoke a certificate with its private key, Boulder does not require the Key ID field, while Pebble does: {'type': 'urn:ietf:params:acme:error:malformedRequest', 'detail': 'Key ID (kid) in JWS header missing expected URL prefix', 'status': 400} Which of these behaviors is correct? Or is revocation by certificate's private key simply not supported yet in Pebble?

Apologies for the confusion, it looks like in 185968a when we added revocation support I read the code as if the only supported authentication method was embedding a JWK with the certificate to be revoked's public key and signing the JWS with the certificate to be revoked's private key. The README and the comments in the code reflect that:

In reality we're using lookupJWK unconditionally, not extractJWK :

That will only allow authenticating the revocation by signing the JWS with the account key and using the standard keyID to identify the account. That's why you are seeing the missing key ID error.

I think for the short-term I'll fix the existing implementation to suport the certificate key/JWK method we described in the comment/README and will re-add the issuing-account/KeyID revocation authentication method afterwards. See #137

from pebble.

Is more specificity about the potential errors needed?

Well, for me personally, I'd like to know why revocation failed: is it because authentication didn't work, is it because the certificate is from another CA (or else unknown to the CA), or is it because it has already been revoked?

I'm currently trying to detect this by looking out for the precise error message returned by Boulder, which isn't a very good idea(tm). I need this to correctly implement idempotency for a Ansible module for ACME certificate revocation (see ansible/ansible#40995), which should do nothing (i.e. return "no change") if the certificate has already been revoked. Currently, the main check I'm using is asking the OCSP, which of course doesn't work for Pebble, and in general has the problem that OCSP response update could be delayed. If there's no OCSP response, or if it returns valid, I'm trying to revoke the certificate, and if that fails I'm looking at the error. If it is the Boulder error message, I ignore it and return "no change". If there would be a well-defined error message for the case "already revoked", I could simply look out for that one and feel better that I didn't have to use a hack which might stop working at any point in time, or will never work (with other ACME implementations) :)

I'll start a discussion on the ML.

from pebble.

I'll start a discussion on the ML.

Sounds good 👍 Thanks for explaining your use case here. I agree that specific error codes for some of the revocation error conditions sound like they might help your use case. Starting a ML thread is the best way to get that ball rolling.

from pebble.