On Wed, Jul 5, 2017 at 6:03 PM, Jacob Hoffman-Andrews <[email protected]> wrote:
> On 06/30/2017 09:54 AM, Dunning, John wrote: > > Based on your description below, I think door A makes more sense to me. > My paraphrase of it is that key authorizations get bound at creation time, > and thus get “grandfathered” in after a credential rotation. > > This is a good paraphrase. What do other folks on this list think about > binding key authorization objects at creation time? I can't immediately see > a security issue with it, but as a reminder, an earlier version of the > protocol was subject to a vulnerability (https://www.ietf.org/mail- > archive/web/acme/current/msg00484.html) related to changing the account > key after creating an authorization object, so I think tweaks in this area > deserve extra scrutiny. > Note that the solution I implemented in -07 was to bind not at challenge creation time, but at the time that a client responds to a challenge. I think I probably agree that it's simpler to bind at creation time, in the sense that it avoids more race conditions. It does move us more in the direction of the server just providing an opaque value to the client, but at least the client can still validate that the value makes sense. I'm tempted to propose an option (C), but I'm not sure it's actually a good idea: C) Instead of using *key* authorizations, use *account* authorizations. Instead of the object being of "token.H(key)", make it "token.H(account-url)". This would remove any question of roll-over interactions, and kind of match the pattern we established when we moved from using "jwk" in JWS to using "kid" with the account URL. In fact, I think that would remove the last reference we have to account keys outside of account management. However, I have the usual worries about the indirection caused by using account URLs, and the potential ambiguity of treating a URL as an octet string. --Richard
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
