Subject: Re: [ietf-dkim] another 4871 Errata filed

From: Jim Fenton <[email-masked]>
Date: Mon, 20 Oct 2008 15:12:45 -0700

Getting a little caught up...

I don't think this is the right direction to go with this.  Even though
it shows up in many of the DomainKeys examples, there isn't any reason I
can think of to include an empty g= tag in a DomainKeys key record. 
This proposal adds additional logic to the verifier to handle this case,
and will need to be included in order to be standards-compliant long
after DomainKeys is, practically as well as formally, historical.

Also, this proposal would immediately make nearly all existing DKIM
verifiers non-compliant until they incorporate the additional logic 
(the "should be interpreted" would really need to be a "MUST be
interpreted" in order to make the spec appropriately normative.)

Unless someone can suggest a reason that DomainKeys records need to
include g=;, I suggest that instead there be a Compatibility Note for
DomainKeys that recommends against the use of the g= tag in key records
except when the intent is to match the local-part by using a non-null value.

-Jim

Tony Hansen wrote:
> I just filed another errata against 4871. It reads as follows.
>
> 	Tony
>
> Section 3.6.1 says:
>
> N/A (see Notes below)
>
> It should say:
>
> Add text similar to the following:
>
> Compatibility Note for DomainKeys
>
> If a v= value is not found at the beginning of the DKIM key record,
> the key record should be interpreted as for DomainKeys [4870]. The
> definition given here is upwardly compatible with what is used for
> DomainKeys, with the exception of the "g=" value. In a DomainKeys
> key record, an empty "g=" value should be interpreted as being
> equivalent to DKIM's "g=*".
>
> Notes:
>
> There should be a note added somewhere to section 3.6.1 saying
> that if a v= is not found at the beginning of the DKIM key
> record, the DNS key record should be interpreted as for DomainKeys
> and described in RFC 4870. In addition, a note should be added
> about the difference in the interpretation of an empty "g=",
> which is the only incompatible tag.
> _______________________________________________
> 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

---

From: SM <[email-masked]>
Date: Mon, 20 Oct 2008 22:02:46 -0700

>after DomainKeys is, practically as well as formally, historical.

DomainKeys would take less time to be operationally historical if a 
mail provider stops specifying it as a requirement.

>except when the intent is to match the local-part by using a non-null value.

As RFC 4870 is published as Historic, it is better to leave it as it 
is.  If the mail provider does the change, the problem will go away quietly.

Regards,
-sm

---

From: Tony Hansen <[email-masked]>
Date: Tue, 21 Oct 2008 08:25:25 -0400

Well, this is something we were forced to do in our implementation
because of the number of sites that still have legacy DomainKeys key
records, are now deploying DKIM, and have not updated their key records
to cover both cases. The number of such sites was sufficiently large
that we felt we had to do it.

It seems that the knowledge about the g=; difference needs to be out
there somewhere. And since, face it, DomainKeys was out there first, I
felt that DKIM implementations need to be able to handle the situation.

It does not need to be a MUST, because failing the signatures is a
viable alternative.

I think we're actually quibbling about wording. Here's a suggested
alternative:

====

The definition given here for the key record is upwardly compatible with
what is used for DomainKeys, with the exception of the "g=" value. In
DomainKeys, a key record empty "g=" value is equivalent to "g=*", while
DKIM treats that value as matching nothing. The value "g=*" means the
same in both DomainKeys and DKIM.

DomainKeys deployers are encouraged to at least switch their key records
to using the equivalent "g=*" value, which works equivalently for both
DomainKeys and DKIM.

A DKIM implementation MAY choose to use the lack of a v= value at the
beginning of the key record as an indicator that the key record is a
DomainKeys key record, and interpret an empty "g=" value as if it were
written "g=*".
====

This wording reinforces your recommendation to use "g=*", and provides a
mechanism for DKIM implementors to use if they choose to deal with the
situation.

	Tony Hansen
	[email-masked]