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
