On 7 August 2016 at 04:55, Jacob Hoffman-Andrews <j...@eff.org> wrote: > The rationale from the notes is that nonces are not a scarce resource. > However, cachability and idempotence of GETs were not addressed. I think > it's worth not requiring nonces on GETs purely for those reasons. In > practical terms, this difference has caused real bugs for Let's Encrypt.
The hazard here is that you generate a cacheable response that contains a nonce. That means that clients could see the same nonce twice if they pull from cache. But the downside there is that you could end up with a rejection when the nonce is used the second time. The upside is that the rejection will contain a new nonce. (If you aren't retrying requests when you get a 4xx, then you will have a bad day anyway). Not sure about your question regarding idempotence. Maybe you are concerned about GET being safe (in the RFC7231 sense) and the side-effects of the request. To that, I'd suggest that if generating a nonce is not safe in your server implementation, you have bought yourself a lot of pain for nought. Generating a nonce safely (e.g., without committing state) is fairly trivial. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
