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

Reply via email to