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
