Douglas Otis wrote:
dkim-ssp-01 edits to avoid unnecessary constraint on i=
====
Was:
1. Introduction
...
In the absence of a valid DKIM signature on behalf of the "From"
address [RFC2822],..
Change to:
In the absence of a valid DKIM signature on behalf of the "From"
address [RFC2822] domain,..
It has been pointed out that the Introduction is not the place for
normative language, but wherever this sentence ends up, it would tell
the verifier to skip the SSP check on the basis of a domain match
alone. This means that someone signing with a key that has a g=
constraint could tell the verifier to bypass the SSP check for any
message in the domain, not just the From address[es] that the signer is
authorized to sign for. This would create a new security vulnerability.
====
Was:
2.8. Originator Signature
An "Originator Signature" is any Valid Signature where the signing
address (listed in the "i=" tag if present, otherwise its default
value, consisting of the null address, representing an unknown user,
followed by "@", followed by the value of the "d=" tag) matches the
Originator Address. If the signing address does not include a local-
part, then only the domains must match; otherwise, the two addresses
must be identical.
Change to:
2.8. Originator Signature
An "Originator Signature" is any Valid Signature where the d= tag
matches or is within the Originator Domain (the domain of the first
From email-address). In addition, when a key is restricted by its
g= tag, the signature MUST BE valid for the Originator Address (the
first From email-address).
As far as I can tell, the only difference between these statements
occurs when the signer has an unrestricted key and decides to apply a
local-part to the i= tag even though it is not required. I don't think
this is an important case to consider; they could easily apply the From
address's local-part if they want.
-Jim
====
_______________________________________________
NOTE WELL: This list operates according
tohttp://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html