Hi, small note on my changes: I might have changed the meaning of 'fulfilling' and 'responding to' a challenge. I think these terms will be relevant for clarifying other outstanding issues. Therefore, I would like to settle on some terms that will be used throughout the standard.
fulfilling a challenge: e.g. client provisioning a TXT record responding to a challenge: posting to the challenge url (the server can try validation now) Best, Sophie On 02/01/18 20:51, Daniel McCarney wrote: > Thanks for the PR Sophie. I voiced a +1 on the Github thread but will also > echo it here. > > On Wed, Dec 27, 2017 at 8:35 AM, Sophie Herold <[email protected]> > wrote: > >> Hi, >> >> I have posted a PR that implements both changes (not expecting and not >> returning the keyAuthorization) as basis for a discussion. >> >> https://github.com/ietf-wg-acme/acme/pull/375 >> >> Notably, I think this should be backwards compatible for clients as far >> as we want it to be. The redundant keyAuthorization would just be >> ignored by the server. >> >> Best, >> Sophie >> >> On 21/12/17 04:07, Jacob Hoffman-Andrews wrote: >>> On 12/19/2017 03:10 AM, Sophie Herold wrote: >>>> If the client follows the schema >>>> >>>> 1. fulfill challenge >>>> 2. POST challenge URL >>>> >>>> it is unlikely that the keyAuthorization returned by the server would be >>>> used to fulfill the challenge (again). >>>> >>>> However, it should be possible to obtain a working ACME client by >>>> POSTing to the challenge URL first and using the keyAuthorization >>>> returned by the server (and possibly changed by the server) to fulfill >>>> the challenge afterwards. This should work since the servers challenge >>>> checks (DNS, HTTP, ...) are not instantaneous and even retried. In this >>>> case the MitM protection is bypassed by incautious client >> implementation. >>> >>> This is a good point. The other potential issue is reliability: a client >>> the depends on the returned keyAuthorization rather than the one it >>> provided might appear to work for a while, then stop working if the >>> server started validating challenges more quickly. >>> >>> I would support a change so that the server does not echo the >>> keyAuthorization. This brings up another question: Why have the client >>> include the keyAuthorization in the challenge POST at all? Both sides >>> can calculate it from scratch, the POST is essentially just "I'm ready >>> for validation now!" I think we originally included it because we >>> anticipated had other challenges where the client would be expected to >>> provide some secret token in the challenge response, or some proof of >>> control of a key, so including some payload (keyAuthorization) for the >>> other challenge types seemed stylistically consistent with that. >>> However, I don't think it's really necessary. >>> >>> _______________________________________________ >>> Acme mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/acme >>> >> >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
