On 25/Aug/11 00:23, John C Klensin wrote:
> And that is why the IETF versions of the PGP and S/MIME approaches
> do just that, rather than trying to sign outer headers and, fwiw,
> why we didn't feel a need to mention this issue (any more than
> other things a Submission server could mess up) in earlier versions
> of the Submission server RFCs. In order to accomplish a different
> objective, DKIM signs headers. For that reason, I think it would
> be entirely reasonable to require that the DKIM specs say something
> like "If an MUA is going to use a Submission server that modifies,
> fixes, or otherwise diddles with headers that need to be signed,
> the DKIM signature better be applied by that Submission server and
> not the MUA or originating machine". But that is a DKIM problem
> and not a 4409bis one.
While I agree with the above, I'd like to make explicit that the
concept of "submission" (and that of author domain signature) may
change due to the adoption of smart-hosts, possibly imposed by
deliverability reasons. Personally, I dislike such tendency, because
smaller ADMDs can potentially identify their users with better
accuracy and behave more humanly than 1984ish giant providers.
However, this feeling is not a good reason to try and hinder that
tendency by introducing a rigid concept of submission in 4409bis.
> Implementers of MSAs and those who submit messages to
> them should be aware that MUAs (or other submission
> system components) may apply digital signatures or other
> types of message integrity checks (MICs) to messages and
> that, in the most general case, the MSA may not be able
> to detect the fact that MIC arrangements have been used
> by inspection of the message. Some of the
> transformations permitted by this specification will
> invalidate such MICs. Although the risk is less
> if MICs protect only internal body parts (i.e., that the
> main header fields are not signed) that restriction does
> not completely eliminate the risk. Consequently,
> operators of message originating systems that apply such
> signatures should ensure that the relevant MSAs are
> aware that signatures may be present (or external MICs
> used) and that they are properly configured to avoid
> making changes, remove signatures, or accept that
> signatures may become invalid as appropriate.
+1, far better than the other options listed by SM.
> Still no normative language, but I think that addresses the
> concerns we have been trying to raise while, at the same time,
> actually saying something (and not implying that three
> IETF-defined protocols are the only options). It can probably
> be improved by editing
I'd propose to slightly alter the last sentence so that it reads
something like
Consequently,
operators of message originating systems that apply such
signatures should either ensure that the relevant MSAs are
aware that signatures may be present (or external MICs
used) and that their site policy provides for avoiding
to make changes and remove signatures, or accept that
signatures may become invalid as appropriate.
The intent is to clarify that the normative standing of this paragraph
is still within the MAY in the first paragraph, where the site policy
is evoked. (And an attempt to ease the reading of "or accept", please
improve my English...)
jm2c
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
