On Fri, Jul 7, 2017 at 2:06 PM, Jacob Hoffman-Andrews <[email protected]> wrote:
> On 07/07/2017 06:42 AM, Richard Barnes wrote: > > C) Instead of using *key* authorizations, use *account* > > authorizations. Instead of the object being of "token.H(key)", make > > it "token.H(account-url)". > I like this in principle, and wish we'd adopted it several months ago. > At this point, I think it's too big a change for too little benefit. The > "bind keyAuthorization at challenge creation" approach has the benefit > that most clients will not even notice the change. It only makes a > different when key rollover and long-term pending challenges are in > play, which is pretty uncommon. > 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, and the client would still compute and send back a keyAuthorization. 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 ... since now the client's keyAuthorization doesn't match the one the server bound. You only avoid the race condition if you express the keyAuthorization in the challenge. And that entails changing the "token" field to a "key-authorization" field, which will break clients. If clients are going to have to change either way, then option (C) seems like a marginally smaller change: Option (A): Pull the keyAuthorization from the challenge; delete keyAuthorization computation code Option (B): Put the account URL in the keyAuthorization instead of the account key; delete JWK thumbprint code
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
