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

On 3/28/2011 9:23 PM, Bill Burke wrote:
> 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.

For DKIM's intended email use, some of us believe there needs to be an 
additional canonicalization algorithm that is more extensively tailored to 
modifications that happen during real-world transit.  The more forgiving of the 
existing two (relaxed) breaks too often.  I'm confident we'll write a spec for 
this soon.

But I said email transit, which of course is not the same as web transit.

I would think it likely that the web environment could also benefit from a 
canonicalization algorithm tailored to the kinds of modifications done during 
web page data migration.

Since this is a modular part of the signing service, this is merely a matter of 
developing the algorithm and registering it in the right DKIM-related table (and 
getting signers and verifiers to implement it...)


> 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.

Just to make sure we have a clear base for discussion:  DOSETA is not DKIM.

DKIM is a fully-integrated email identification scheme.

Although DOSETA documents the same core technology, the specification is 
organized very differently and is intended to be easy to adapt to other 
applications.

The DOSETA documents are also is newer and very much subject to changes 
(improvements).  These documents are only a few weeks old, although of course, 
much of the text was taken from the older and more mature DKIM specifications.

To put things baldly:  I made an initial pass at organizing the DOSETA spec in a 
way that would support much better modularization, to support use in other 
application.  But like any writing I do, it needs others to suggest changes.  By 
"needs" I mean /must/ be obtained.  I'm quite happy with the current version... 
as a start.  It needs other eyes and some testing to provide guidance for how to 
make it better, in terms of organization, technical design, and wording.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Received on Tuesday, 29 March 2011 07:48:05 UTC