On Nov 27, 2007, at 12:00 PM, Dave Crocker wrote:
That is only one of SSP's features.
OK, it also allows you to make negative assertions about validly
dkim signed messages where the domain name of the From field and
the signer differ. It's still only capable of making negative
assertions about validity ("the content is not valid"), though.
Which means that it is making statements about validity.
But a DKIM signature does not.
Not exactly.
-------
3.5 The DKIM-Signature Header Field
...
[Regarding i= tag]
INFORMATIVE NOTE: The local-part of the "i=" tag is optional because
in some cases a signer may not be able to establish a verified
individual identity. In such cases, the signer may wish to assert that
although it is willing to go as far as signing for the domain, it is
unable or unwilling to commit to an individual user name within their
domain. It can do so by including the domain part but not the local-
part of the identity.
INFORMATIVE DISCUSSION: This document does not require the value of
the "i=" tag to match the identity in any message header fields. This
is considered to be a verifier policy issue. Constraints between the
value of the "i=" tag and other identities in other header fields seek
to apply basic authentication into the semantics of trust associated
with a role such as content author. Trust is a broad and complex topic
and trust mechanisms are subject to highly creative attacks. The real-
world efficacy of any but the most basic bindings between the "i="
value and other identities is not well established, nor is its
vulnerability to subversion by an attacker. Hence reliance on the use
of these options should be strictly limited. In particular, it is not
at all clear to what extent a typical end-user recipient can rely on
any assurances that might be made by successful use of the "i=" options.
------
While definitely not normative, these issues will become defined by
how these semantics are either used or more likely misused.
SSP could and should clarify what should be construed when a key is
restricted to a specific localpart. Perhaps the localpart is not
authenticated, but is instead used by a class of users. The TPA-SSP
also allows assertions to be more stringent for third-party signatures
than that found on first-party signatures.
By using the TPA-SSP extension, a sub-domain signature could be seen
as valid for a the From domain AND be seen as having authenticated the
use of the email address, whereas a signature at the domain might
assert that no authentication is being made. This mode of operation
would permit different handling without involving any more overhead
than that used for CNAMEs.
http://www.ietf.org/internet-drafts/draft-otis-dkim-tpa-ssp-02.txt
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html