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

[Hector Santos]

+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
> 
>