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