Re: Web Keys and HTTP Signatures

[Ken Murchison <[e-mail]>]

On 04/18/2013  10:01 PM, Stephen Farrell wrote:
> And in the "other relevant work" thread, aside from httpauth
> (where I'm a co-author on a similar-ish proposal [1] and be
> happy to chat about it, maybe the http-auth list is better
> though), there's also work to use DKIM-like headers for
> iSchedule [2]. I've not read this though (yet) to see if
> they're all really that different or not.
>
> Cheers,
> S.
>
> [1] http://tools.ietf.org/html/draft-farrell-httpbis-hoba
> [2] http://tools.ietf.org/html/draft-desruisseaux-ischedule

I was also going to suggest folks look at iSchedule, which leverages the 
already proven/scrutinized DKIM technology for signing its HTTP 
requests.  That draft is only concerned about iSchedule and not general 
purpose HTTP requests, but a similar methodology could be used.

A few things to note:

  * Earlier versions of the draft signed both the request-line and Host
    header, but we found in interop testing that intermediaries might
    alter the request-target and/or Host, thus breaking the signature. 
    We punted on both because 1) all iSchedule requests are sent to one
    request target (there is only a single "resource" on an iSchedule
    receiver) therefore the receiver can determine if the request-target
    is valid, and 2) the receiver can deduce from the signed Recipient
    header(s) if it was the intended Host.  My guess is that both of
    these issues would have to be addressed if a DKIM-like method was
    going to be applied to general HTTP requests.  Use of the Forwarded
    header [3] might help in addressing these issues, but I haven't
    thought much about it.
  * Earlier versions of the draft used the standard DKIM "relaxed"
    header canonicalization algorithm, but we found in interop testing
    that intermediaries and/or HTTP libraries might combine multiple
    headers of the same name (#list-type header) into a single header,
    thus breaking the signature.  As a result, we had to define our own
    "ischedule-relaxed" header canonicalization algorithm which
    essentially combines such headers before signing/verifying.
  * iSchedule is only concerned with signing requests at a domain level,
    not on an individual user level.  A new DKIM key query method might
    be able to be designed to handle fetching of user keys.


[3] http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University