ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Consensus call on d=/i= clarification

2009-02-22 04:12:59
+1

Based on SM's excellent summary review, I change my original A entry 
to D.

Thanks SM.

-- 
Sincerely

Hector Santos
http://www.santronics.com


SM wrote:
At 08:36 16-02-2009, Stephen Farrell wrote:
We've had some recent discussion about d=/i= on the list
and a couple of concrete proposals for clarifications to
make to RFC 4871.
   - The first is Dave's erratum I-D. [1]
   - The second is a proposal from Eliot.[2]

[snip]

So, can you please reply to the list with *one* of the
following opinions, before the end of next Monday, Feb
23rd.

(a) The erratum I-D [1] is ready to go. Process it.
(b) The erratum I-D [1] is the way to go, but needs work.
    (Then specify your changes in "NEW"/"OLD" style.)
(c) Eliot's proposal [2] is ready to go. Process it.
(d) Eliot's proposal [2] is the way to go, but needs work.
    (Then specify your changes in "NEW"/"OLD" style.)
(e) None of the above.

The erratum (draft-ietf-dkim-rfc4871-errata-02 - item a) introduces 
new terms such as the User Agent Identifier, Identity Assessor and 
Signing Domain Identifier.  It then goes into an explanation of how 
they tie into DKIM.  Eliot's proposal (item c) falls within the usual 
boundary for an errata as it tries to provide clarity without 
introducing new terminology.

An errata is generally noncontroversial.  Instead of being a 
clarification of the d= and i= tags in the current specification, 
this one turned into a determination of how DKIM will be used in 
future.  One of the proposal affects the work currently being done on 
ADSP.  I'll quote Section 2.7 of draft-ietf-dkim-ssp-09:

   "Note:   ADSP is incompatible with valid DKIM usage in which a signer
       uses "i=" with values that are not the same as addresses in mail
       headers.  In that case, a possible workaround could be to add a
       second DKIM signature a "d=" value that matches the Author
       Address, but no "i="."

With the change, we may need to sign the message more than once in 
some circumstances if we are using the i= tag.  That's an extra 
overhead both for signers and verifiers.

Quoting part of Jim's proposal:

   "In many cases, the i= tag will not be present in the DKIM-Signature
    header field at all; it is not required unless the signing key
    restricts the signing identity or identities via its g= value."

That is better suited for a document about deployment.

J.D. suggested leaving i= opaque and see what operators (on both ends 
of the transaction) do with it.  That could be discussed in a 
document about deployment.

Given the scope of Dave's proposal, I'm still not comfortable with it 
as an erratum.  I choose Eliot's proposal (d).

Regards,
-sm 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html





_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html