ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Eat all CR/LF - STRIP Canonicalization Method

2006-07-25 13:17:47
Thanks Stephen, I will take your suggestions stated under advisement.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Tuesday, July 25, 2006 12:04 PM
Subject: Re: [ietf-dkim] Eat all CR/LF - STRIP Canonicalization Method



Hi Hector,

Hector Santos wrote:
Look,  I can't help but think if it was anyone else making this
suggestion,
you wouldn't be able to kept up with this thread.    What a shame, it is
more important to push out a faulty spec than to fix the problem to make
DKIM more robust and acceptable.

I don't think that's entirely fair. Your suggestion is really quite
close to nofws, which was found wanting from the security point of
view. In this case, I'm sure you can create messages that'd read
differently to a human under CR/LF manipulations. Signers IMO won't
accept such manipulations.

But if you disagree, that's certainly fine in which case I'd suggest
that the best thing would be to follow John Levine's idea to code it
up and try it out.

You can do this without requiring any change to base by including two
signatures, the first say with simple c14n (so that bh= will be what
you're calling "bo="), and the 2nd with this new c14n. Then you can see
what happens. Your new c14n algorithm can be easily documented in an I-D
of its own, totally compatible with base. Were this c14n to prove a
success, then I'd imagine it'd be likely to be folded into a later
generation of the base RFC.

And since I don't think I've seen this said on the list (though it was
said at the mic in Montreal), there is a history here. Both S/MIME and
even moreso, XML signature had real difficulty with c14n, so this is an
area where a) we (at least I) expect problems, b) there are no silver
bullets (IMO) and so c) we'll only know we've gotten it right or wrong
after the base RFC issues. One consequence is that any new scheme will
be received with a certain amount of skepticism by those who've seen
c14n signing difficulties before.

So, why not write up your new c14n as an I-D and then see if folks
like it enough to write code.

Cheers,
Stephen.







_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html