Re: [Ietf-dkim] Question about lone CR / LF

[Dave Crocker <[e-mail]>]

On 2/3/2024 12:11 PM, John Levine wrote:
> It appears that Dave Crocker<[e-mail]>  said:
>>> Any DKIM signer or verifier already has a state machine looking for CR
>>> and LF to do header or body canonicalization.  When the state machine
>>> runs into a bare CR or LF, it has to do something. The only options
>>> are to produce a wrong result, since there is no correct result, or no
>>> result. (As I said in a recent note to Murray, which wrong result is
>>> likely to vary depending on local file details.)  You seem to be
>>> saying that as a matter of principle it should produce a wrong
>>> result.  I'd rather not.
>> The state machine has to process /every/ character.  You are focusing on
>> two that have special DKIM meaning, when occurring together, but that's
>> too narrow.  In practical terms, the state engine is evaluating every
>> character.
> Sorry, I thought it would be obvious that it already has to treat CR
> and LF differently, and it already has special cases for what follows
> CR and (on systems that don't turn CRLF to LF on the way in) what
> precedes LF.

It has to treat CRLF differently.  What is the reason it has to treat 
isolated occurrences of one or the other differently, beyond what I 
noted in my previous message?  What is the DKIM-specific reason?

I keep asking and you keep not responding.

>> In focusing down so narrowly, you've missed the basic point I made:
>> DKIM has no inherent reason to care about these characters' occurring in
>> isolation. ...
> Sigh. Except that it already does. You've made it clear that you
> believe there is a principled reason to produce invalid signatures
> from invalid input. Whatever.

"It already does" is not a reason it needs to.

As for what I believe, please stop distorting what I've said.

d/

ps. You seem to have missed that, in fact, bare CR and bare LF are legal 
in messages.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@[e-mail]