Dave CROCKER wrote:
The current RFC 4871 does not specify what its payload is, versus what is
internal to the protocol operations. The DKIM-Signature: header field
contains
both DKIM internals and DKIM payload. Which is which?
This is a fair point, but is much broader than the d=/i= question that
is the subject of this erratum. I believe that this should be
considered as a separate erratum.
The way in which draft-ietf-dkim-rfc4871-errata-02 is written, the d=
value is payload, i= MAY be payload if present. How can the i= value
only sometimes be payload?
But -rfc4871-errata-02 defines this backwards. The erratum makes
everything else internals, which eliminates a lot of information that
might be useful to a downstream assessor. For example:
- h= is needed by assessors that might want to know whether a given
header field is signed by the signature. This is needed to support John
Callas's suggestion that additional assertions might be contained in a
header field signed by the signature. Without the h= value, the
assessor has no way of knowing what's signed.
- l= would be needed by an assessor that wants to present only signed
portions of the body to the user.
- as-yet undefined DKIM-Signature tags are likely to be payload, such as
additional identifier tags described by Jon Callas.
There are a few values (b=, bh= and s=, for example) that don't seem
useful to downstream assessors, but many others are.
The notion that DKIM has a single output (presumably d=) is flawed,
unless that single output is a vector (list of tag/value pairs) or a
pointer to a DKIM-Signature header field that verified successfully.
Back to the errata question: An erratum is supposed to be about a
single topic. This is different from the question of d= vs. i=
confusion, and that's why it's not part of Eliot's erratum proposal (or
my amendment).
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html