On Sun, 7 Aug 2016 18:55:15 -0700 Richard Barnes <[email protected]> wrote:
> As Ron notes, there's a need for some way to prime the nonce pump. > Because POSTs require nonces, that means that we need either use a > non-POST method or modify POST behavior. Let me propose a few > options for people to opine on... > > Option 1: HEAD to some existing resource that admits a GET (e.g., > directory) Pro: Aligns with HTTP's requirement for GET == HEAD if you > also send Replay-Nonce for the GET > Con: ... but sending Replay-Nonce for the GET makes the affected > resource non-cacheable > > Option 2: GET/HEAD to a new-nonce resource > Pro: Clean separation of the nonce-priming function > Con: One more resource to specify / provision / remember > > Option 3: HEAD to the resource you would be POSTing to > Pro: Simple client logic; no need to use a separate resource > Con: Contrary to a SHOULD in RFC 7231, especially when the resource > doesn't respond to GET > > Option 4: POST an empty body to the resource you would be POSTing to; > get nonce in error response > Pro: Client can use the same resource; priming POST can't be mistaken > for a real POST > Con: Client and server need a special case in their POST logic What about option 5: make the protocol resilient to replays and remove nonces, as I suggested a few weeks ago: https://www.ietf.org/mail-archive/web/acme/current/msg01158.html Regards, Andrew _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
