Any further thoughts on whether keyAuthorizations should be bound at
challenge creation time vs challenge submission time?
On 07/07/2017 03:09 PM, Jacob Hoffman-Andrews wrote:
> On 07/07/2017 12:35 PM, Richard Barnes wrote:
>> Whether clients will notice depends on how we change the syntax to
>>
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
On Fri, Jul 7, 2017 at 2:06 PM, Jacob Hoffman-Andrews 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
On Wed, Jul 5, 2017 at 6:03 PM, Jacob Hoffman-Andrews 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
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
On 06/20/2017 03:07 PM, Dunning, John 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)
>
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
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",
>
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