Advice to clients: Can the same "clear predecessor certificate" be identified in multiple New Order requests?

[robstradling]

In #57 we seem to be in agreement that it should be left to server policy to decide whether or not the identifier list in a New Order request and its claimed predecessor certificate "share identifiers". Similarly, the current language that affects client behaviour ("Clients SHOULD include this field in New Order requests if there is a clear predecessor certificate") implies that it's left to client policy when a client is deciding if/how to populate the replaces field in a New Order request.

Consider this scenario: A client has a soon-to-expire certificate (X) that has SAN:dNSName entries for a.com and b.com. Instead of getting a like-for-like replacement, the client wishes to "renew" that certificate by ordering two new single-domain certificates - one cert for a.com, and another cert for b.com. That client's policy is (quoting one of the suggested example policies in #57) "The replacement must share at least one identifier (as long as any name is being renewed, it counts)". For both New Order requests, the client indicates certificate X in the replaces field, because it considers X to be the "clear predecessor certificate" in both cases.

Given that "Servers SHOULD check...that the identified certificate has not already been marked as replaced by a different finalized Order", ISTM that it would be worth providing more advice to clients regarding how to determine what is or isn't a "clear predecessor certificate".

Since "Servers MAY ignore the replaces field in New Order requests which do not pass such checks" implies that servers are free to choose to regard multiple New Order requests as renewals of the same predecessor certificate, ISTM that the advice to clients should be: Be aware that some servers may reject a replaces value that has already been specified in a previous New Order request.

I realise this is closely related to #56, although that issue is about server behaviour.

[aarongable]

Since "Servers MAY ignore the replaces field in New Order requests which do not pass such checks" implies that servers are free to choose to regard multiple New Order requests as renewals of the same predecessor certificate

I don't think this interpretation is supported by the draft text. Saying that a server MAY ignore the "replaces" field means that the server can choose to process the new-order request ignoring the replaces field -- i.e. the Order object it returns will have an empty replaces field. Therefore the server does not regard this order as a renewal of the same predecessor certificate, even though the client requested it. This is in contrast to the server's other option, which is to reject this second request as invalid (see the thread about 409 Conflict).

I'm going to ignore this issue for the moment, because we have a bunch of other issues circulating about server behavior and it's not worth clarifying client behavior until we know exactly what the server's options are in this case.

[robstradling]

I now understand your intended meaning, but I disagree that my interpretation is unsupported by the current text. +1 on returning to this later though.

[aarongable]

I've now rephrased the whole block of text under the sample new-order request, and I think this is much clearer. Servers are now told that they SHOULD reject new-order requests whose identified predecessor certificate does not match their server-policy-based checks. I think client behavior is now clear: don't submit a value that the server will reject; if the server does reject, you can retry without it. I don't think that it's necessary to spell this out.

There's still some question here of whether or when a server should specifically return a 409, and whether there should be a new acme error type for this case, but that can be handled in #56