- From: Cyrus Daboo <cyrus@daboo.name>
- Date: Tue, 12 May 2015 09:52:02 -0400
- To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mark Nottingham <mnot@mnot.net>, Willy Tarreau <w@1wt.eu>
- cc: Martin Thomson <martin.thomson@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Stephen, --On May 12, 2015 at 1:33:30 PM +0100 Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > So it might be a useful thing here to only try attempt the > general signed header field thing if there are use-cases that > are compelling where someone really treats the request or > response differently in a well defined way when a signature > that includes a header field is bad or cannot be verified. > > By the "general signed header field thing" I mean something > that's like a DKIM-Signature or Dave Crocker's DOSETA proposal > or the Cavage draft above. > > Note that DKIM didn't have to pass the test I'm suggesting > here, which was correct in that case. And again, the above > is a possibly dumb idea so please take it with salt:-) FYI folks in the CalDAV/Calendaring community have had success adopting DKIM for use with HTTP for a server-to-server scheduling protocol (<https://tools.ietf.org/html/draft-desruisseaux-ischedule-05> - draft expired but still a work in progress). In our case we provided a much stricter verification requirement than typically used in email (i.e., we stated that requests must be rejected if the signature fails). The re-use of DKIM in HTTP provided a quick and easy route to implementation and -- Cyrus Daboo
Received on Tuesday, 12 May 2015 13:52:28 UTC