On Mar 1, 2008, at 6:55 AM, Jim Fenton wrote: > I'd like to shorten the list of open issues, so I'll start with the > issues that I consider clearly moot in the ASP draft (-ssp-03) or > that are duplicates of other issues. Hopefully these are non- > controversial. > > WG chairs, I'd like to ask that you direct the closure of the > following issues, subject to WG consensus, of course: > > >> 1399 clarify i= vs. SSP > > Duplicate of 1519.
Disagree. Issue 1399 suggests i= might be included within an "all" signed policy, however lacks details. Issue 1519 notes SSP policy requirements conflicts with RFC 4871 and recommends against restrictions on the i= parameter for unrestricted keys. Per the DKIM charter of out-of-scope topics: * Signatures that attempt to make strong assertions about the identity of the message author, and details of user-level signing of messages (as distinguished from domain-level keys that are restricted to specific users). * Duplication of prior work in signed email, including S/MIME and OpenPGP. Despite being out-of-scope, the SSP Author Signature definition dramatically changes i= parameter use in "compliant" signatures. The change in i= parameter's use was made by stipulating "compliant" signatures containing the local-part of an identity must be on behalf of the entity within the From header. RFC4871 never stipulated a valid signature's associated identity contain an email-address found within the message's headers, nor that this identity be specifically within the From header. Compatibility with RFC 4871 is only achieved using identity ambiguous signatures in many cases, leaving verifiers to guess (wrongly in some cases) by looking up the header stack. To retain specificity of non- From header identities, an separate signature is required and it must properly overlap that of an ambiguous signature. There is _no_ reason to assume providers will make assertions regarding the specific identity of the message's author. Providers may wish, or be compelled, to use opaque tokens instead. Whether such identity assertions are made is out of scope for DKIM. Not surprisingly, limitations on identity assertions limited to specific email-addresses within the From header for SSP "compliance" is not compatible with RFC 4871 either, in addition to being out of scope. Use of the i= parameter containing a token representing the user or agent on whose behalf the signature was made offers a significant level of protection for receivers. This protection can help curb abuse from compromised systems, especially when users are permitted to send messages irrespective of identities within From headers. Abuse is normally controlled by identifying abusers, and not by constraining all the domain's users messages. The level of constraint used should remain within the purview of the signing domains. The protection afforded by a valid (even tokenized) on-behalf-of identity is lost as a result of the change imposed by the Author Signature definition. A definition that demands _less_ information be conveyed in the signature. A domain may wish to assert all of their messages are signed to raise the scrutiny given unsigned messages from their domain. Nevertheless, the identity of the Author remains an independent and totally separate issue. Ironically, this definition inhibits use of identities of those introducing the message and on whose behalf the signature was added when not also found within the From header. Any issues related to the spoofing of the Author still remains within the signing domain's purview and can be prevented by not signing spoofed or abusive messages. The only justification to limit "compliant" signatures to those identities found within the From header would be for messages signed with g= restricted keys. Such messages should be flagged "non- compliant" regardless of what policy the domain publishes. Such messages can easily represent abuse beyond the signing domain's purview. Not flagging these messages as being "non-complaint" would impose a significant security risk fully independent of any SSP policy assertions or author identities. SSP should only stipulate that signatures containing identities not found within the From header signed with g= restricted keys are to be considered "non-compliant" with _any_ domain signing policy. In addition, such stipulations SHOULD NOT depend upon whether a policy has been published. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
