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