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
