(I'm just picking a random message from this thread to respond to; this
isn't a specific response to this specific message.)
I see a clear consensus in this discussion, and I think the issue's
actually already handled in the spec. In section 5.3, we say this:
Should the message be submitted to the signer with any local encoding
that will be modified before transmission, such conversion to
canonical form MUST be done before signing. In particular, some
systems use local line separator conventions (such as the Unix
newline character) internally rather than the SMTP-standard CRLF
sequence. All such local conventions MUST be converted to canonical
format before signing.
I think it might be helpful to mention that some messages are formed
with bare-CR, as well as with bare-LF, to clarify this particular
situation, but beyond that we're OK.
In other words, rather than making this a canonicalization issue, I
suggest that we make it an issue in the normalization step of the
message. (For those who aren't sure, the distinction is that the
normalization step is actually permanently changing the message by
putting it into normalized form, which the canonicalization is only
changing the bytes that get signed, but not changing the message itself.
Therefore, the normalization is only ever done once, before doing the
rest of the steps for signing, and the verifier never has to know about it.)
Unless we hear objections to this other than from Mike, we'll call this
finished. So:
Mike: Can you live with this answer, even if it's not what you'd prefer?
Eric: Will you tweak that paragraph in 5.3 to mention that some messages
that are considered compliant with RFC 82x fail complicance with RFC
282x in this regard and MUST be normalized?
Barry
--
Barry Leiba, DKIM working group chair (leiba(_at_)watson(_dot_)ibm(_dot_)com)
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html