> Clarifying question: What does "this situation" (in the last paragraph)
> refer to: the use of an empty "g=" value, or an empty "g=" value absent
> a "v=" tag?
The latter, the "can't tell" situation. We can tweak the text to make
that clearer, if the WG wants this change.
Barry
On Wed, Oct 13, 2010 at 5:34 PM, Jim Fenton <fen...@cisco.com> wrote:
> On 10/13/10 1:03 PM, Barry Leiba wrote:
>> I thought we'd had this discussion before, and what's there was what
>> we decided to do. Search facilities are inadequate for easy checking.
>> I certainly think that pointing out the ambiguity issue is important,
>> so I, as a participant, wouldn't want to remove it entirely. Allow me
>> to suggest the following alternative text, and ask other participants
>> to weigh in on which you prefer:
>>
>>
>> 3.6.1.1. Compatibility Note for DomainKeys
>>
>> Key records for DKIM are backward-compatible with key records
>> for the now-obsolete DomainKeys [RFC4870], except in one
>> circumstance: DomainKeys interpreted an empty "g=" value to
>> match any signing address ("i=" in the signature). In DKIM, that
>> matching is done by "g=*", or by omitting "g=" and taking the
>> default behaviour. An empty "g=" value in DKIM will match only
>> empty "i=" values.
>>
>> If a key record uses an empty "g=" value and also uses "v=",
>> the key record can be identified as belonging to DKIM, and the
>> DKIM interpretation will be used. Absent a "v=" tag, though,
>> the verifier cannot tell whether the signer intended the
>> DomainKeys interpretation or the DKIM one.
>>
>> To avoid second-guessing in a security context, and because
>> DomainKeys is an obsolete protocol, DKIM verifiers MUST
>> interpret this situation in DKIM terms, matching only
>> empty "i=" values.
>
>
> Clarifying question: What does "this situation" (in the last paragraph)
> refer to: the use of an empty "g=" value, or an empty "g=" value absent
> a "v=" tag?
>
> -Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
