Thanks Stephen, I will take your suggestions stated under advisement.

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


----- Original Message -----
From: "Stephen Farrell" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
Cc: <ietf-dkim@mipassoc.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

Reply via email to