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.
Tony Hansen wrote:
Here's a description of the errata conclusions that were made at today's
meeting. If anyone disagrees, speak now.
Tony Hansen
tony(_at_)att(_dot_)com
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html