John Levine wrote: >> The output of DKIM verification is considerably more than that: >> there are a great many values, such as the list of signed header >> fields, that may be useful to an assessor and that must be made >> available to the assessor if the verifier is to be as interoperable >> with as many assessors as possible. >> > > We seem to have a fairly basic disconnect here. As far as I'm > concerned, an assessor has better things to worry about than the > internal details of the signature. Trying to reverse engineer or guess > what the signer had in mind would be a hopeless swamp even if it were > desirable. >
On the other hand, we definitely don't have enough information about assessors to know what information they need. Saying that the SDID is the only thing they can depend on getting from the verifier is too constraining. > Sure, it's possible to put on a worthless signature that leaves out > crucial headers, but signers who do so won't get a very good > reputation so the problem should be self-limiting. There's no > existing installed base of inept signers we have to work around, and > it would be a poor idea do anything that would allow crummy signatures > to appear to work. > The "worthless signature" may not have been so worthless if one of the header fields in question wasn't present at the time of signing, but was added later. There have been proposals to convey some information relating to assessment (for example, Jon Callas's suggestion at http://mipassoc.org/pipermail/ietf-dkim/2009q1/011104.html ) by putting it in a separate header field and signing it. Are you suggesting that whether that header field is signed or not is irrelevant to the assessor? -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
