This is mixing together two issues. The question of what constitutes an Originator (now Author) Signature applies to all SSP practices because it's the basis for deciding whether to look up SSP at all. For that reason, I'd suggest leaving "strict" out of it.
So the question then is whether the local-part of i= should be part of the match against the From address to determine whether it's an Author Signature. If I understand your proposal, you're suggesting that we only match the local-part if the g= of the key is constrained (the key isn't valid for all addresses in the domain). If this were done, the input to SSP would be not just the message itself, the SSP record, and information about validity of signatures in the message. It would also be necessary to have information from the selector records about the g= value of each. In all other respects, the selector data is only used foe verifying the signature itself. Signers that have a key that is unconstrained always have the option to sign with an empty local-part. Basing the decision on the presence of g= in the key means that signers necessarily apply Author Signatures whenever they're signing for their domain, or they need to have use appropriately restricted keys whenever they don't want to do that. I don't see the advantage of doing it this way, and a couple of disadvantages. -Jim Douglas Otis wrote: > Signature compliance changes when a From domain's SSP indicates "strict". > > When a message has a valid unconstrained signature of the From domain, > verifiers should consider this domain's signature authoritative for > the domain's policies. The only instance where the i= parameter > should play a role in "strict" policy compliance would be when the key > restricts local-parts via the g= parameter. > > As SSP's "strict" is currently defined, although a message might be > signed by the From domain using an unrestricted key, when the i= > parameter is not "on-behalf-of" the From header, it will not provide > compliance with a "strict" policy. The From domain should validate > sources within their domain prior to signing. Hopefully this > signature will also indicate the validated source. A "strict" policy > should not interfere in a signature's ability to indicate which source > had been validated. > > SSP's "strict" creates an unnecessary i= parameter requirement that > will cause: > > - unexpected corner cases such as when - > > a) office administrators send "on-behalf-of" their boss (Sender)/From > ... > > > Mitigating corner cases will require: > > - use of ambiguous signatures where the i= parameter is excluded > > - use of multiple signatures > > SSP policy should strive to minimize disruption. There is no > justification for "strict" policy compliance to invalidate any > unrestricted signature of the From domain. After all, unrestricted > keys are able to sign any header and _must_ be utilized by trustworthy > systems. When unrestricted keys are used, it is also reasonable to > assume that the domain's signing policies were applied prior to > signing. SSP's "strict" definition unreasonably constrains how the i= > parameter might be utilized for unrestricted keys. It is not > reasonable to assume domains will have mitigated the exceptions > created by the SSP definition for "strict" and its additional i= > parameter requirements. It is only reasonable to assume DKIM > practices are based upon RFC 4871. As currently defined, SSP is not > compliant with RFC 4871. > > -Doug > _______________________________________________ > 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
