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
