ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Reading the entrails, was Moving to consensus

2009-03-24 06:57:34
On Mon, 23 Mar 2009 00:42:22 -0000, John R. Levine <johnl(_at_)iecc(_dot_)com> 
wrote:

I'd do it by writing up an I-D and specifically saying what to pass to  
the
assessor.  Unless you expect the assessor to make an end run around the
verifier, you're going to have to change the verifier anyway to expand  
the
set of stuff it exports.

Here's a list of things that a verifier might pass to the assessor:

* The number of fields in the DKIM-Signature header
* The order of the header names in h= field
* The number of headers in the message which are out of order relative to
   their order in h=
* Whether the signature includes q=dns/txt or defaults it
* The number of characters in the DKIM-Signature header, mod 17

I hope you'll agree that it would be pretty stupid for the assessor to
depend on any of those.

Not necessarily. Basically an Assessor could usefully be made aware of the
fields that have NOT been signed.

But what I don't understand is why we are discussing the interface between
the Verifier and the Assessor at all. They are both part of the setup at
the site where the Signature is being examined (usually at the incoming
boundary of some target domain). And the IETF has always kept clear of
specifying protocols to be used within one site. For example, that is why
the IETF has never tried to specify an interface between whatever MTA
receives the incoming stuff over Port 25 and the storage agent (Pop3,
IMAP, Mbox format, procmail, whatever) it is to be sent to (in spite of
the fact that a standard interface at that point might be quite a useful
thing to have).

Which fields of the message header get signed is a choice to be made by
the signing domain, and should be based on its perception of what the Bad
Guys might try to gain by altering or inserting unsigned fields. Clearly,
there are some fields that it would be stupid to sign (Received obviously,
and any List-* unless you are signing in behalf of a list expander).
Clearly there are fields which is would be stupid NOT to sign (From, which
would be so stupid to omit there is a MUST to cover it, but also Sender,
To, Cc, Reply-To unless there is a good reason not to). But that is a
matter for some BCP Document, not for the Standards track. And the
interface to the Assessor is the same.



-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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