On Sat, Aug 06, 2016 at 11:55:26AM -0700, Jacob Hoffman-Andrews wrote: > At IETF 96 it was proposed to drop this issue: > https://www.ietf.org/proceedings/96/minutes/minutes-96-acme. > > 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. > > Would someone like to present a specific defense of providing a unique > nonce with every GET?
The example that I and others originally voiced on this list was that you shouldn't have to do a POST that you know will fail (because you don't yet have a valid nonce) to get a valid nonce. But as long as there is some trivial way to GET a fresh nonce (similar to what we are already doing now with a HEAD request to the directory) I don't see a problem with not providing a nonce with _every_ GETable resource. IIRC you objected to using the directory for this, but a separate "get me a new nonce" resource would probably be fine for that too. modulo needing a flag day for the client code to transition to that if Boulder doesn't implement both for some period of time. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
