Subject: [ietf-dkim] errata conclusions

From: Tony Hansen <[email-masked]>
Date: Thu, 20 Nov 2008 18:31:14 -0500

Here's a description of the errata conclusions that were made at today's
meeting. If anyone disagrees, speak now.

	Tony Hansen
	[email-masked]

Errata 1383	show g= example with * in middle

	Add to the example list for g= the example of "foo*bar":

	Section 3.6.1 should say:

	g= Granularity of the key (plain-text; OPTIONAL, default is
	"*"). .... Wildcarding allows matching for addresses such as
	"user+*", "*-offer" or "foo*bar". An empty "g=" value never
	matches any addresses.

Errata 1378	"a=" is required

	I was to check if the messages I captured at the interop last year if
there were any that did not have a= in them. I still have 834 of the
messages I received back then. *All of them have a= in them.* Given
that, here is the conclusion:

	Section 3.3 should remove the sentence saying:

	The rsa-sha256 algorithm is the default if no algorithm is
	specified.

Errata 1532	DomainKeys key record compatibility

	Add a section, probably after 6.1.3, with this text:

	6.1.4 Compatibility Note for DomainKeys

	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=*".

Errata 1596	Ambiguity regarding whitespace and b= value

	Add text "(including all surrounding whitespace)" to the
	description of deleting the b= value.

	3.7. Computing the Message Hashes

	2. The DKIM-Signature header field that exists (verifying) or
	will be inserted (signing) in the message, with the value of the
	"b=" tag (including all surrounding whitespace) deleted (i.e.,
	treated as the empty string), canonicalized using the header
	canonicalization algorithm specified in the "c=" tag, and
	without a trailing CRLF.

	Fix the ambiguity in the base64string grammar to remove leading
	and trailing FWS. Replace the existing base64 production with:

	ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/")
	base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS)
				[ [FWS] "=" [ [FWS] "=" ] ]
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 22 Nov 2008 22:20:11 +0000

Thanks Tony,

If there are no objections, we'll forward these to Pasi to
take action (i.e. update the errata pages) in one week from
now,

Stephen.