Re: [apps-discuss] Web Keys and HTTP Signatures

On 04/19/2013 11:33 AM, Cyrus Daboo wrote:
>> https://github.com/joyent/node-http-signature/blob/master/http_signing.md
>
> That draft is very similar to the approach we have used in iSchedule
>  (<https://datatracker.ietf.org/doc/draft-desruisseaux-ischedule/>) -
>  which is an HTTP-based calendar and scheduling messaging protocol.

Thanks for the pointer to the draft. I skimmed it and I agree that there
are a number of very interesting similarities.

> We choose to re-use existing email signing technology - DKIM 
> (<http://tools.ietf.org/html/rfc6376>) - primarily because the 
> security model and key management were a good fit for our 
> application. There is also the benefit of code re-use, and working 
> with a protocol that is already deployed and used heavily in the 
> email environment. Also, DKIM was designed with the prospect of
> being applicable to protocols beyond email technology - and I think
> with iSchedule we have proven it can work with HTTP.

Yes, it seems like a very applicable technology for your use case. The
one thing I missed is whether or not DKIM allows multiple identities per
user in a domain? Does it let users create as many sub-accounts as they
want and associate keys with them? Anything is possible, what I'm asking
is if this is something that is standardized. Access to DNS places a
pretty high bar and we were hoping to lower that by a significant amount
with Web Keys.

>From my understanding, DKIM defines a domain-level digital signature
authentication framework. WebKeys defines a identity-level digital
signature authentication framework.

Where DKIM uses the DNS system to discover key information for a domain.
Web Keys uses the Web and Linked Data formats to discover key
information for a particular identity.

> I would definitely urge you to take a serious look at DKIM. There
> are a number of interesting features there that don't seem to have
> been addressed in the draft you cited. In particular dealing with
> both header and body canonicalization (headers are particular problem
> in HTTP due to intermediaries, caches etc).

Yes, Proxy header modification is a problem for Web Keys and HTTP
Signatures now. We think we have some working solutions, but won't know
for sure until we get some deployment experience with the protocol (or
someone that has already been through that pain point can let us know
what we're doing wrong).

I agree with you. We need to take a serious look at DKIM and your spec
and figure out if we missed something obvious with Web Keys and HTTP
Signatures. Glancing through your spec sparked a few ideas, so I'm
looking forward to a thorough read and review of it wrt. Web Keys and
HTTP Signatures.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Sunday, 21 April 2013 21:18:41 UTC