Subject: [Acme] "Slide 21" follow-up (textual encoding question) PART 3: post-issuance client error feedback

From: Sean Leonard <[email-masked]>
Date: Fri, 31 Mar 2017 17:27:27 -0500

Hi ACME:

I see ways in this protocol for the ACME server to issue error messages to the ACME client. How come there is no way for the ACME client to issue error messages back to the ACME server, particularly post-issuance?

The ACME server can send over a certificate that the server *thinks* is valid, but doesn’t meet production requirements. Maybe the key usage is wrong, or there is something wrong with the chain certs or the roots because the web server is talking to clients that don’t support that particular CA root.

It would save a lot of headache for the ACME client to validate that the certificates (including chain) that it got are acceptable, *before* putting the certificates into production and having millions of certificate validation errors from around the world on its hands. If the client finds a validation problem, then it can communicate that immediately to the ACME server (or elsewhere) so that operators can collaboratively deal with it.

I thought of this workflow as part of Part 1, since the error feedback from ACME client to ACME server would be after the order status turns “valid” and the certificate (and chain) is available. This bolsters the proposal that the certificates should be incorporated directly into the ACME order object.

That’s it, thanks all for a nice IETF 98.

Sean