Any further thoughts on whether keyAuthorizations should be bound at challenge creation time vs challenge submission time?
On 07/07/2017 03:09 PM, Jacob Hoffman-Andrews wrote: > On 07/07/2017 12:35 PM, Richard Barnes wrote: >> Whether clients will notice depends on how we change the syntax to >> express the "binding". You seem to be assuming that we'll keep the >> syntax the same. That would mean that the server would note the >> keyAuthorization to be used with the challenge at creation time, in a >> way that's invisible to the client > Yep, I am assuming we'll keep the syntax the same. I don't see a > reason to change. >> So you'll break clients in the following scenario: >> >> 1. Server creates challenge bound to keyAuthorization_oldkey, sends >> to client >> 2. Client rolls keys >> 3. Client computes keyAuthorization_newkey >> 4. Client provisions the validation response with keyAuthorization_newkey >> 5. Client sends keyAuthorization_newkey in a response to the >> challenge, signed with newkey > Yep, this was the scenario I was describing when I said: > > > It only makes a different when key rollover and long-term pending > challenges are in > play, which is pretty uncommon. > > Thanks for spelling it out in more detail, that makes it clearer. > Essentially, I am saying that it is very rare for clients to hold onto > pending authorizations while rolling keys. The most common clients > (Cerbot, dehydrated, lego, etc) treat "get authorization; provision > validation response; request validation" as a single automated steps, > taking seconds or minutes. Those clients generally don't keep > authorizations around between runs, and would be rotating keys between > runs. So no problem. > > The only clients that would have to change are those that (a) cannot > be fully automated, and therefore hold onto pending authorizations for > days, and (b) rotate their keys regularly. As far as I'm aware, Akamai > is the only client doing that, and they are the ones asking for "bind > at creation time." I believe that most other clients would not notice > a difference. > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
