Looking at this further, I don't really see what the benefit is. On the one hand, it's trivial to implement a nonce scheme where it's free to issue as many nonces as you want, and you only have to store nonces that actually get used [1]. The thing that's costly is using nonces, which this proposal doesn't help at all.
On the other hand, you're basically trading off a valid HEAD for a malformed POST. That seems like a bad deal for clients (who have to do a signature operation to get a nonce) and servers (who now can't just fail a malformed POST). And building functionality on malformed requests just seems like bad protocol engineering. On Fri, Jul 8, 2016 at 4:55 PM, Jacob Hoffman-Andrews <[email protected]> wrote: > https://github.com/ietf-wg-acme/acme/pull/156 > > Previously the server was required to provide a nonce on all successful > responses, including GETs. This makes certain nonce-storage techniques > like an > in-memory list impractical, because the size of the list would have to > scale > with GET requests rather than just authenticated POSTs. > > This change reduces the scope of requests where nonces are required. > > It also tweaks the example section for Replay-Nonce to not define the > base64url > character set. > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
