On Tue, Nov 29, 2016 at 04:32:33PM -0500, Richard Barnes wrote:
> On Tue, Nov 29, 2016 at 4:14 PM, Jacob Hoffman-Andrews <j...@eff.org> 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
> 
There are (presumably) going to be many more client implementations
than server implementations.  With the current language, the client
must check that authorizations have not changed.

The language for the server should be ``MUST NOT change the elements
of the "authorizations" array once set.'', unambiguously putting the
responsibility where it squarely belongs - with the server.  The
spec could further elaborate that clients ``SHOULD consider the
application invalid'' if a change is detected.

I see no reason why clients should be burdened (by way of ``MUST'')
with detecting a condition that will not arise with compliant
servers, and is unlikely to cause practical issues if it does occur
after a certificate has been issued.

Thanks,
Fraser

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Reply via email to