On 03/May/10 22:26, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Authentication-Results Registration For Differentiating Among
Cryptographic Results '
<draft-kucherawy-authres-header-b-01.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2010-05-31.
The I-D identifies a possible result forgery (section 6.2). Although I
haven't fully grasped the reasons why such attack would be attempted,
I think that condition is a case where the spoofed signature SHOULD be
removed by the verifier. I'm not sure the latter spec would be an
update of rfc 4871, since it says "/Signers/ SHOULD NOT remove any
DKIM-Signature header field" [emphasis added]. (Other cases where
signatures might be removed --mailing lists-- are currently being
discussed on ietf-dkim.)
For a minor point, the example (A.1) the I-D makes does not illustrate
the reason for introducing header.b. The exemplified signatures can
already be distinguished by their header.i values. By setting that
attribute also in this case, the example conveys the impression that
header.b should not be omitted, even when it is unnecessary. If that's
the intended meaning, it should be stated more explicitly, IMHO.
OTOH, the example shows a case where a signature had been validated
before being broken (discussed on ietf-dkim and [1]). However, that is
apparently the only part of the I-D discussing such topic.
--
[1] http://mipassoc.org/pipermail/mail-vet-discuss/2010q2/000602.html
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf