clarification needed with regards to the "allow-certificate-get" field

[thomas-fossati]

From IANA Designated Expert review (Richard Barnes)

The "allow-certificate-get" field is listed as configurable.
It seems like this is a matter of CA policy, so it should either
be non-configurable, or if you allow the client to request a
value for it, there should be a clear specification that the
server is allowed to ignore the client's preference.

[yaronf]

Should be configurable, because it is negotiated with the server, just like all other configurable parameters. The server is free to refuse per its policy, of course. However for Delegation, we need to add an error signal from the IdO to the NDC in such cases, because the NDC would not be able to pull the new certificate.

[yaronf]

cc @bifurcation.

[thomas-fossati]

In general, I don't think have the luxury of a synchronous transaction on which to attach an explicit error response. So I propose we say something along the following lines:

• The IdO should check that the CA supports allow-certificate-get at the required level (i.e., meta.allow-cert-get (!STAR) or meta.auto-renewal.allow-cert-get (STAR));
• If it knows in advance that the CA does not support allow-cert-get for the specific order (STAR or !STAR), then it MUST NOT forward the request to the CA and instead goto: err;
• if the CA replies without reflecting the requested allow-cert-get setting, again goto: err;

err: the IdO MUST set the "allow-certificate-get": false (at the appropriate nesting level, depending on the client's request) and move the order state to invalid.

The combination of "status": "invalid" and "allow-cert-get": false tells (unambiguously) the NDC that the reason why the order failed is because of unsupported allow-cert-get on the CA side.