Hi Russ,
At 10:45 22-08-2011, Russ Housley wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
The specification says:
If an incoming message includes a DKIM [DKIM], PGP [RFC4880],
S/MIME [RFC5751], or other signature, sites SHOULD consider what
effect message modifications will have on the validity of the
signature, and MAY use the presence or absence of a signature as
a criterion when deciding what, if any, modifications to make.
This text is a warning that there are dragons here, but it does not
tell the reader anything about the real consequences. I believe
that the text ought to be saying that portions of the incoming
message that are covered by the signature SHOULD NOT be altered.
The consequences of such alteration should probably be included in
the security considerations.
The YAM WG was asked for feedback about this issue. Dave Crocker
suggested the following text as a replacement for the text you quoted above:
"Message modification can affect the validity of an existing message
signature, such as by DKIM [DKIM], PGP [RFC4880], and can render the
signature invalid. This, in turn, can affect message handling by later
receivers, such as filtering engines that consider the presence or absence
of a signature."
The rationale for having the text is that "awareness of the
possibility of signature-breaking is an important thing when
implementing submit processors, so some text along these lines is
useful advice. The actual consequences are completely context-specific".
Ned Freed pointed out that "first and foremost, since "signature" is
in general completely open-ended thing, recommending that signature
preservation always be a priority over submit message processing is:
(a) Impossible to implement since there's no way to tell the difference
between a new signature scheme and some random collection of header
fields, a new media type, or whatever and
(b) A really bad idea since the use of a signature can (and sometimes does)
conflict with the operational policies associated with a submit agent.
And the latter can be a legal requirement in some venues.
There were several objections to the total removal of the text.
Based on the feedback received, I think the appropriate path is to
have the text replaced. Do you consider the proposed change as acceptable?
Regards,
S. Moonesamy
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
