Authentication-Results Registration for Differentiating among Cryptographic Results
Extracted elements (12)
It is not necessary to include the entire digital signature in the Authentication-Results field to achieve disambiguation; since signatures will almost always differ substantially, only the first several bytes are anticipated to be sufficient. Requiring a minimum of eight characters balances uniqueness against header field size.
When a message carries multiple DKIM signatures from the same domain, existing 'header.d' or 'header.i' disambiguation properties may not be unique (e.g., a signing agent may affix multiple signatures with identical 'd=' values). This can produce simultaneous 'dkim=pass' and 'dkim=fail' results with no way to associate each result with the correct signature. The actual digital signature value ('b=' tag) is chosen as the unique identifier because SHA1/SHA256 collisions are uncommon and RSA signing rarely produces common substrings.
Multiple DKIM signatures on a single message may share the same 'header.d' or 'header.i' values, making those properties insufficient for disambiguation in Authentication-Results. The 'header.b' property defined here is designed to be the uniqueness backstop when all other properties collide.
If an evaluating agent observes that, despite use of the 'header.b' disambiguating tag, unequal authentication results are offered about the same signature from the same trusted authserv-id, that agent SHOULD ignore all such results.
Matching of the 'header.b' value against the signature itself MUST be case-sensitive.
The value of the 'header.b' property in an Authentication-Results field MUST be at least the first eight characters of the digital signature (the 'b=' tag from a DKIM-Signature) for which a result is being reported, and MUST be long enough to be unique among all results being reported in the same field.
Where the total length of the digital signature is fewer than eight characters, the entire signature MUST be included in the 'header.b' value.
The 'header.b' property is a new reporting item in Authentication-Results fields, used with method 'dkim'. Its value is the full or partial value of the DKIM-Signature 'b=' tag, providing a unique identifier to associate each verification result with the specific signature it describes.
RFC 6008 adds the entry {Method: dkim, Defined: RFC4871, ptype: header, property: b, value: full or partial value of signature 'b' tag} to the IANA 'Email Authentication Methods' registry originally created by RFC 5451.
An attacker could copy a valid signature and attach it to a modified message in transit, potentially causing two results to share the same 'header.b' value even when the full 'b=' string is used. This can generate a false negative ('fail') but cannot realistically create a false positive ('pass'); a cautious implementation may discard the false negative.
If a future signing scheme produces signatures shorter than eight characters, the entire signature must be used per Section 4, but such a scheme would itself be collision-prone, making the 'header.b' value unreliable as a disambiguator. The recommendation to ignore ambiguous results (Section 4 SHOULD) mitigates this risk.
The 'header.b' registration fixes an existing security weakness in RFC 5451: previously ambiguous multi-signature results could be obscured or misinterpreted; this property allows unambiguous association of each result with its specific signature.