It seems like the challenge update and validation process should follow natural patterns for checking the key.
For the TLS-SNI and DNS challenges, the only time in the validation when the server checks the key is when the client responds with a keyAuthorization. Further processing is based on the verified keyAuthorization. So if the key change happens before the client responds, then the server will use the new key; if it happens after the response, then it will use the old key. For the HTTP challenge as written right now, there's an additional problem that the server does another key check after it gets a keyAuthorization in the validation query, rather than checking against the keyAuthorization in the challenge resource (updated post-response). If you have the following sequence of events, you'll have a problem: - Client provisions HTTP resource with old account key - Client sends response with keyAuthorization over old account key - Client changes key - Server sends validation HTTP request - Client response with keyAuthorization over the old account key - Server compares to new account key; fails. ISTM that the best way to fix this is simply to align the HTTP challenge to the other challenges, and have the server check the keyAuthorization in the response against the keyAuthorization in the challenge, rather than checking directly for the current account key. === This proposed solution framework will result in the old key being used sometimes. That's a little unfortunate (e.g., if you're rolling due to compromise), but the window of vulnerability is fairly small, and you can always revoke certificates or invalidate authorizations. I have updated the PR. Note that I have not updated the challenge type, since this seems like a minor change with small compatibility risk: https://github.com/ietf-wg-acme/acme/pull/323/files --Richard On Tue, Jun 20, 2017 at 6:07 PM, Dunning, John <[email protected]> wrote: > I would advocate for the new one. IOW, I would (expect to) interpret the > semantics as being > > 1. The challenge token was created with respect to an account > 2. An attribute of the account is the credential (whichever credential is > current) > 3. Therefore the credential authorizes access to anything associated with > the account. > > If the concensus here is that a server needs to associate the credential > which was in force at creation time with a challenge token, in other words > that the token is tied to the credential rather than the account, I believe > my use case would be ok with that, as long as the challenge tokens do not > go invalid after the credential change. > > I would expect that latter semantics would be hairier for server > implementors, because they’d need to keep multiple credentials alive and > associated with the account for the maximum lifetime of any extant tokens. > > > On 6/19/17, 2:44 PM, "Ilari Liusvaara" <[email protected]> wrote: > > On Mon, Jun 19, 2017 at 02:34:45PM -0400, Richard Barnes wrote: > > This seems sensible; rolling keys shouldn't invalidate things in > transit > > any more than changing your Gmail password should delete your drafts > folder. > > > > I would have a little bit of a hard time calling this "purely > editorial", > > since it specifies server behavior. But it seems like you're just > > codifying an expectation that at least I already had (TBH, I would > not have > > thought to build a server otherwise), so I would be inclined to go > ahead > > and merge it if at least one or two other people chime in. > > > > Here's a PR: https://github.com/ietf-wg-acme/acme/pull/323 > > If there is pending validation over key change, which key hash should > the validation use when it is resolved? The old one? The new one? > > > -Ilari > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
