>> Is this accurate? If so, it seems like some version of this explanation
>> should be included in the Security Considerations section.
>>
>> --
>> *From:* Daniel McCarney
>> *Sent:* Wednesday, March 22, 2017 10:30 AM
>> *To:*
rate? If so, it seems like some version of this explanation
> should be included in the Security Considerations section.
>
> --
> *From:* Daniel McCarney
> *Sent:* Wednesday, March 22, 2017 10:30 AM
> *To:* Zach Shepherd
> *Cc:* acme@ietf.org
&g
--
> *From:* Daniel McCarney
> *Sent:* Wednesday, March 22, 2017 10:30 AM
> *To:* Zach Shepherd
> *Cc:* acme@ietf.org
> *Subject:* Re: [Acme] Entropy requirement for challenge token
>
> Hi Zach,
>
> > This
rney
Sent: Wednesday, March 22, 2017 10:30 AM
To: Zach Shepherd
Cc: acme@ietf.org
Subject: Re: [Acme] Entropy requirement for challenge token
Hi Zach,
> This seems incongruous. If the token must be kept secret an attacker, it
> should not be served via an unauthenticated channel.
I agree the
Hi Zach,
> This seems incongruous. If the token must be kept secret an attacker, it
> should not be served via an unauthenticated channel.
I agree the wording makes it incongruous, I was caught up on this the other
week until it was clarified for me by Jacob.
The token is random not to prevent
The following feedback is based on 8010a31 (current HEAD of master).
Section 6.2, Request Authentication, states "Note that authentication via
signed JWS request bodies implies that GET requests are not authenticated.
Servers MUST NOT respond to GET requests for resources that might be considere
