W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

Re: Feedback on draft-burke-content-signature-00.txt

From: Bill Burke <bburke@redhat.com>
Date: Mon, 28 Mar 2011 19:24:19 +0000
Message-ID: <4D90E027.4090801@redhat.com>
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 Burke
JBoss, a division of Red Hat
Received on Tuesday, 29 March 2011 11:32:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:56 UTC