Revoking certificates: is it possible/useful to specify the reason of the revocation?

[tdelmas]

https://letsencrypt.org/docs/revoking/ is not talking about it

Certificate revocation list | Reasons for revocation

The ACME protocol seams to implement it: https://tools.ietf.org/html/draft-ietf-acme-acme-04#page-42

[cpu]

Hi @tdelmas,

“Is it possible” - yes As you mention the ACME revocation resource allows specifying a reason code. The important thing to note with respect to Let’s Encrypt is that Boulder only allows a subset of reason codes to be specified by the user.

“Is it useful” - I’m not personally sure what relying parties that check OCSP are likely to do with the revocation reason. I suspect not very much.

[tdelmas]

Thanks @cpu !

And it looks like it’s implemented by certbot, I guess it’s just not documented: https://github.com/certbot/certbot/blob/master/tests/boulder-integration.sh#L276

It’s not documented there: https://certbot.eff.org/docs/using.html?highlight=revoke#revoking-certificates

Edit: It’s documented there: https://github.com/certbot/certbot/blob/master/docs/cli-help.txt#L306

[cpu]

@tdelmas

I guess it’s just not documented:

It looks like while it isn't documented in the usage section, it is documented in the command line flags section:

   --reason {keycompromise,affiliationchanged,superseded,unspecified,cessationofoperation}
                        Specify reason for revoking certificate. (default: 0)

@schoen @swartzcr Do you think the --reason flag should also be documented in the revocation usage part of the manual? I also wonder if the "(default: 0)" in the command line flags documentation should be written as "(default: keycompromise)" - I'm not sure what "0" maps to in this case.

Edit: oops! looks like you edited your answer right at the same time I was posting this Jinx!

[SwartzCr]

I made a PR for this which should change what the listed default is and add a short section to the docs about it: https://github.com/certbot/certbot/pull/4987