- From: Bill Burke <bburke@redhat.com>
- Date: Mon, 28 Mar 2011 19:24:19 +0000
- To: dcrocker@bbiw.net
- CC: Dave CROCKER <dhc2@dcrocker.net>, Eran Hammer-Lahav <eran@hueniverse.com>, Cyrus Daboo <cyrus@daboo.name>, Mark Nottingham <mnot@mnot.net>, "Thomson, Martin" <Martin.Thomson@commscope.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 3/27/11 9:48 AM, Dave CROCKER wrote: > > > On 3/25/2011 8:34 PM, Bill Burke wrote: >> The only thing it doesn't seem to support is composing >> signatures from other signatures. I see this being a very useful >> feature in >> workflows where somebody needs to verify that more than one party saw >> the same >> representation. > > Can you clarify the details of the added functionality you are > interested in? > > By way of guessing, I'm thinking of two possibilities of what you might > have in mind: > > 1. A new signature covers an existing signature. I think the DOSETA > model can cover this by specifying the existing signature's header field > in the list of covered fields. > > 2. Re-using calculations from a first signature for forming a second > one. This would be the two hashes (content and content+header). > Something related to this idea has occurred to be, but only vaguely and > I haven't done any work on it. > The header canonicalization algorithm seems a little fragile, but I don't have experience deploying the protocol. Its probably sufficient enough for the perceived needs I envision. > >> The only thing I worry about DKIM is that it imposes a key management >> structure >> and infrastructure? The users I deal with will probably want to >> integrate with >> existing mechanisms to manage keys and look them up and to verify >> identity >> (which will probably be different per user). > > Officially, the DKIM/DOSETA specs permit referring to a different key > retrieval mechanism. In practice I haven't heard of that being used. > > More generally, it is certainly fundamental to gain clarity and > agreement on the key management and certification model that is required. > I just wish DKIM was a tiny bit more layered into additional RFCs. Specifically keeping key management separate from the canonicalization algorithms and header format. While I do so far like the key management structure specified, I do worry about it being accepted when I start selling this as a solution other than just for managing email integrity. Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
Received on Tuesday, 29 March 2011 11:32:13 UTC