[Fwd: Re: [ietf-dkim] canonicalized null body and dkim]

[Tony Hansen]

I left off a sentence in Point 7.

Tony Hansen wrote:
> Michael Thomas wrote:
>> Dave Crocker wrote:
>>>
>>> : there are things in the
>>>>  real world which will cause more message signature to fail if we
>>>> make this change. You're not in favor of that are you?
>>> Two lines of argument.  You were invoking the 'installed base'
>>> argument and I was noting that it is not valid to use that, at this
>>> stage, for this type of issue.
>> No I was not. My code up until very recently was making the same
>> mistake. What is strongly implied in the current draft offers
>> *superior* robustness in the real world. That is, it is immune to
>> additions *and* deletions of trailing CRLF's. That is not an appeal
>> to installed base, it's an appeal to a more robust spec. As it
>> happens, the spec merely needs to make more obvious what the
>> normative text already says and we will have an improved spec.
> 
> Michael, I don't see where you see the "new and improved algorithm" is
> more robust in the face of deleted CRLFs than the proposed fix to the
> dkim-base text?
> 
> Point 1:
> 	The original dkim-allman-base and dkim-ietf-base text called for
> 	trailing CRLFs to be deleted.
> 
> Point 2:
> 	The change to the text introduced in base-04 called for a
> 	CRLF to be added to a message that doesn't have a CRLF on its
> 	last line of text. In the process, it changed what happens when
> 	there is a message that only has trailing CRLFs. That base-04
> 	included a change to the existing behavior for handling such
> 	messages was missed by many people, myself included, until now.
> 
> Point 3:
> 	The discussions that led to the change in base-04 did not
> 	include any intent to change the default behavior when there
> 	are only CRLFs in the message body. Those discussions were only
> 	about what should happen with a message whose last line didn't
> 	end in CRLF. (Such messages are only possible when you are using
> 	a binary MIME content-transfer-encoding and a binary transport
> 	protocol.)
> 
> Point 4:
> 	The proposed text changes restore the behavior for when you have
> 	blank messages, as well as maintaining the change in semantics
> 	necessary to handle messages whose last line doesn't end in
> 	CRLF. (This includes the messages that have lost a trailing CRLF
> 	in transport.)
> 
> Point 5:
> 	No matter which option we choose, someone's going to have to
> 	change their implementation.
> 
> Point 6:
> 	My preference is to use the algorithm that's compatible with
> 	what was in dkim-allman-base-* and dkim-ietf-base-00 thru 03,
> 	while maintaining the change to handle messages with no final
> 	CRLF.
> 
> Point 7:
> 	Another way of expressing this algorithm that people may find
> 	easier to understand is:
> 
> 	"If the last line of the message does not end with CRLF, CRLF is
> 	added. Then, CRLF 0*CRLF is reduced to a single CRLF."

	"If the body only consists of a CRLF after this reduction, that
	too is removed."

Tony Hansen
tony at att.com