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: 1385
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Murray S. Kucherawy
Date Reported: 2008-03-23
Rejected by: Pasi Eronen
Date Rejected: 2010-02-11

Section 3.6.1 says:

It is expected that many key servers will choose to present the keys in an
otherwise unstructured text format (for example, an XML form would not be
considered to be unstructured text for this purpose).  The following definition
MUST be used for any DKIM key represented in an otherwise unstructured textual
form.

It should say:

It is expected that many key servers will choose to present the keys in an
otherwise unstructured text format (for example, an XML form would not be
considered to be unstructured text for this purpose).  The following definition
MUST be used for any DKIM key represented in an otherwise unstructured textual
form.

The TXT RDATA format is described in section 3.3.14 of RFC1035.  If the retrieved
TXT record consists of more than one "character-string" (as defined in that
document), the RDATA MUST be preprocessed by concatenating all of the
"character-string"s together in the order in which they appeared in the RDATA
before being interpreted as described below.

Notes:

No guidance is provided about how to handle a single TXT RDATA which is subdivided into multiple character-strings, such as an encoded public key that is too large to fit in such a construct (which is limited by RFC1035 to be each 255 characters or less).
--VERIFIER NOTES--
Section 3.6.2.2 already specifies the necessary details.

Report New Errata