On Tue, Nov 29, 2016 at 4:14 PM, Jacob Hoffman-Andrews <[email protected]> wrote:
> Currently we have this text: > > > The elements of the "authorizations" array are immutable once set. If > any change is made to the array after the object is created, the client > MUST consider the application invalid. > > What's the purpose of this clause? I'd like to strike it if possible. > The idea is that the client should get the full list of authorizations to complete in the first shot, so that it doesn't have to keep going back to the order and seeing if it has to do more stuff ad infinitum. (Note to self: Change "application" to "order" in the PR) > Rationale: The most straightforward way to render a pending order object > is going to be by querying a database for the most recent authorizations > applicable to the names in the CSR (preferring valid authzs), and > generating links to those authorizations. In general this should provide > a stable list of URLs, but may produce changes in some edge cases- for > instance, if one authz expires and a newer order is created with an > overlapping identifier. > > Is there a benefit to having the client consider the application invalid > in such a case? > I think so, because it's not distinguishable from the above case. It might seem like it only costs the client a GET (to fetch the authz and see that it's valid), but finding what's new and checking on it requires non-trivial logic. And that logic would still be required even if you said that servers could only change from one valid authz to another. An implementation such as you describe would also violate the semantics of the "authorization" field. The authorizations listed are supposed to be those that the CA used to issue the certificate. Note the past tense there; these are the authorizations that were considered at the time of issuance, not now. So replacing them with updated ones is not helpful. --Richard > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
