ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

2009-03-21 02:00:12
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

<Prev in Thread] Current Thread [Next in Thread>