Thanks, merged. On Fri, Dec 2, 2016 at 2:20 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote:
> LGTM > > > On 12/02/2016 11:18 AM, Richard Barnes wrote: > > Here you go: > > https://github.com/ietf-wg-acme/acme/pull/220 > > On Fri, Dec 2, 2016 at 2:14 PM, Richard Barnes <r...@ipv.sx> wrote: > >> >> >> On Fri, Dec 2, 2016 at 1:30 PM, Jacob Hoffman-Andrews < <j...@eff.org> >> j...@eff.org> wrote: >> >>> >>> > Richard Barnes wrote: >>> >> 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. >>> Okay, I'm convinced that the server should take steps to make sure the >>> list is immutable, however: >>> >>> On 11/29/2016 08:25 PM, Fraser Tweedale wrote: >>> > 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. >>> I agree with this. This makes sense as a server requirement rather than >>> a client requirement. >>> >> >> Yep, sounds good to me. I'm going to merge #208, then handle this as a >> follow-on. Expect a PR shortly. >> >> >> > > > _______________________________________________ > Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme > > >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
