--On Friday, May 06, 2011 12:59 -0700 SM <[email protected]>
wrote:
> Hi John,
> At 05:41 06-05-2011, John C Klensin wrote:
>> Generally, wfm. Noting that the text is (deliberately) broad
>> enough to cover body part encoding modifications as well as
>> those that do integrity checks on headers, so it seems unwise,
>> and possibly misleading, to single out DKIM. Unless someone
>> objects, I'll make that "DKIM, PGP, S/MIME or other..." and
>> add the appropriate citations.
>
> Quoting Section 8:
>
> "Sites MAY modify submissions to ensure compliance with
> standards and
> site policy. This section describes a number of such
> modifications
> that are often considered useful.
>
> NOTE: As a matter of guidance for local decisions to
> implement
> message modification, a paramount rule is to limit such
> actions to
> remedies for specific problems that have clear solutions."
>
> I would like to emphasize the last sentence. It would be
> helpful if we can keep the discussion short and sweet. :-)
>
> I would like to avoid a down-ref unless there is a good
> explanation for it.
The references (DKIM, PGP, S/MIME) are all downward but
distinctly informative. I don't know how to add the text John
Leslie suggested (modified or not) without putting in references
of some sort -- if we don't do it and the IESG doesn't notice,
the RFC Editor is likely to do so, resulting in an AUTH48
battle. By talking about signatures or the even more generic
"message integrity checks", my original suggestion is better
from a referencing standpoint but probably worse from every
other one.
So I see three possible reasonable solutions:
(1) Stay more or less with the text that now appears in
4409bis-00 and tolerate the downward reference.
(2) Drop the new text and say nothing. The piece of
Section 8 that you quote is fairly clear, there wasn't a
request to add specific signature text during the
pre-evaluation work, and the new clarification, while
motivated by EAI, adds nothing new: while address and
header coding changes could cause issues for DKIM
signatures, 4409 (especially in the presence of the 4141
extensions explicitly authorized for Submit by the 4409
pre-evaluation document) could rather thoroughly mess up
PGP or S/MIME signatures over body parts. So, if our
theory is that if something isn't seriously broken,
isn't causing demonstrable problems or confusion, and
isn't reflected in the pre-evaluation document, we don't
change it, then we should drop this.
(3) Really explain the issues with signed messages and,
in particular, define the rules under which MSAs can
process various sorts of messages that come to them
already signed. Those rules would change several things
in Sections 4, 5, 6, and 8 into "MUST NOT unless you
have the private key and are ready to reconstruct the
signature". Note that this is a relatively large piece
of work that arguably imposes new requirements, i.e., it
would immediately take the document out of YAM's scope.
I have no personal preference between (1) and (2) other than
that we quickly make a decision and move on. I'm strongly
opposed to (3) for reasons that I hope are obvious.
best,
john
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
