RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures", May 2007

Note: This RFC has been obsoleted by RFC 6376

Note: This RFC has been updated by RFC 5672

Errata ID: 1381
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Tony Hansen
Date Reported: 2008-03-21
Held for Document Update by: Pasi Eronen

Section 3.5/3.6.1 says:

section 3.5:

   q=  A colon-separated list of query methods used to retrieve the
       public key ... Implementations MUST use the recognized query
       mechanisms in the order presented.

section 3.6.1:

   h=  Acceptable hash algorithms ... Signers and Verifiers MUST
       support the "sha256" hash algorithm.  Verifiers MUST also support
       the "sha1" hash algorithm.

   k=  Key type ... (Note: the "p=" tag further encodes the value using the
       base64 algorithm.)

   s=  Service Type ... Verifiers for a given service type MUST ignore this 
       record if the appropriate type is not listed.  Currently defined 
       service types are as follows:

   t=  Flags, represented as a colon-separated list of names (plain-
       text; OPTIONAL, default is no flags set).  The defined flags are
       as follows:

It should say:

section 3.5:

   q=  A colon-separated list of query methods used to retrieve the
       public key ...  Implementations MUST use the recognized query
       mechanisms in the order presented. Unrecognized query mechanisms
       MUST be ignored.

section 3.6.1:

   h=  Acceptable hash algorithms ... Signers and Verifiers MUST
       support the "sha256" hash algorithm.  Verifiers MUST also support
       the "sha1" hash algorithm. Unrecognized hash algorithms MUST be 
       ignored.

   k=  Key type ...(Note: the "p=" tag further encodes the value using the
       base64 algorithm.) Unrecognized key types MUST be ignored.

   s=  Service Type ... Verifiers for a given service type MUST ignore this 
       record if the appropriate type is not listed. Unrecognized service 
       types MUST be ignored. Currently defined service types are as follows:

   t=  Flags, represented as a colon-separated list of names (plain-
       text; OPTIONAL, default is no flags set).  Unrecognized flags MUST be 
       ignored. The defined flags are as follows:

Notes:

From the October 2008 interop event:

Invalid q=, etc. values

* q=foo/bar:dns/txt:exam/ple
* Nothing in text about unknown values
* But ABNF says unknown values are for “future extension”
* Consensus: ignore unknown values
* Errata: Add statement saying unknown values must be ignored in signature “q=” and key “h=”, “k=”, “s=”, “t=”

Report New Errata