ietf-dkim
[Top] [All Lists]

[ietf-dkim] errata conclusions

2008-11-20 19:36:56
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

<Prev in Thread] Current Thread [Next in Thread>