On Feb 2, 2008, at 7:40 PM, Hector Santos wrote:
Douglas Otis wrote:
RFC 4871 clearly indicates the i= parameter is _intended_ to
identify the user or agent for which the message is being signed.
When a signature is added on-behalf-of an entity whose email-
address is found within the Sender header, and where the message
happens to include a From address within the same domain, the
definition for Author Signature within the SSP makes the signature
specified by RFC 4871 non-compliant with an "all" or "discardable"
policy assertions, however the definition within ASP does not.
Sorry, I don't see it. I am going to ignore ASP/SSP-02 and deal
with SSP-01 because it is well understood and not subject to the
majors security issues in ASP/SSP-02.
DKIM=ALL means ANYONE can sign, but it must be signed.
DKIM=STRICT it must be signed by the AUTHOR (ORIGINATING DOMAIN).
FYI, DKIM=strict is now DKIM=discardable
So much for assertions based upon a perspective of what the signer
does, and not attempting to dictate what an evaluator can do. : (
This would be a 1PS:
From: person(_at_)domain1(_dot_)com
Sender: listadmin(_at_)listdomain(_dot_)com
DKIM-Signature: d=domain1.com i=person(_at_)domain1(_dot_)com
h= may include Sender: binding
For a 1PS scenario, domain1.com SSP policy can be:
DKIM=unknown (weak protection)
DKIM=ALL (protection against non-signed mail)
DKIM=STRICT (protection against non-signed mail and 3PS)
This would be a 3PS:
From: person(_at_)domain1(_dot_)com
Sender: listadmin(_at_)listdomain(_dot_)com
DKIM-Signature: d=listdomain.com i=listadmin(_at_)listdomain(_dot_)com
h= SHOULD (good idea) include Sender: binding
since it was the signer.
Agreed.
But this 3PS type of message signature was the concern.
From: person(_at_)example(_dot_)com
Sender: other-person(_at_)(_dot_)example(_dot_)com
DKIM-Signature: d=expample.com i=other-person(_at_)example(_dot_)com (g=*)
This message is clearly signed by example.com per RFC 4871, but where
a SSP policy assertion of either "all" or "discardable" might cause
this ABSOLUTELY valid message to be dropped as being non-compliant.
(Hard to define compliance with the "discardable" assertion isn't it?
Too bad this was not discussed on the WG list.)
SSP stipulations changes RFC 4871 signature handling to not use the
i= parameter when there might be such a conflict with the From
header.
Per 4871, if i= is used, which is OPTIONAL, the domains of d= and i=
must be the same
Agreed, however the issue was with respect to the local-part other-person(_at_)example(_dot_)com
not meeting the requirements for "Author Signature" in SSP, however
it does meet these requirements in ASP.
Not surprisingly, RFC 4871 never suggested the i= parameter not be
used when there might be a conflict with an address within the From
header.
What conflict?
It is clear in 4871 section 6.3:
If the message is signed on behalf of any address other than that
in the From: header field, the mail system SHOULD take pains to
ensure that the actual signing identity is clear to the reader.
DKIM is silent upon what might be displayed.
The logical association implies for this to be:
([i] == d) != From
which is the fundamental basis for a 3rd party Signing operation.
Like wise, the logical association for a 1st party signature is:
([i] == d) == From
You appear to be describing a comparison stated in ASP, and not the
comparison in SSP.
We need to keep our eye on the prize here and that is DOMAIN
protection,
Agreed.
to assist it in keeping with its new asserted DKIM-BASE "social and
ethical" responsibility. SSP is basically a fraud detection or
protocol consistency checker. If everything is koshser, I believe
no one has ever said SSP allows a message to pass or skip any other
testing.
It would seem better to describe this as a means to evaluate
compliance with Sender assertions pertaining to what the transmitting
indicates as their handling practices. This view makes less sense
when the assertion is "discardable".
Traditionally, by far, the From: is the author of the message. It is
reflective in all mail systems. The author does not mean it has to
be the signer, and I hope no one is claiming a 3rd party signer is
an AUTHOR and/or copyright holder of the message content.
The concern is when the message is signed by the author's domain, but
on-behalf-of someone else with the author's domain. When this domain
applies their signature, their signing policy MUST evaluate whether "other-person(_at_)example(_dot_)com
" is able to include "person(_at_)example(_dot_)com" with the From header. It
would be ridiculous to expect to have this policy applied by a
possible verifier. As you said, DKIM is about establishing
responsibility _at_ the domain. When the domain is held accountable,
as designed in RFC 4871, the local-part introducing the message does
not matter. The local-part might be highlighted by the MUA to
indicate who introduced the message, but as far as signing policy
should be concerned, local-part is immaterial.
The local-part is only material when the key is g= restricted. It
seems reasonable for the the WG to make an exception for restricted
keys. Compliance could be defined as being met by a g= restricted
key only when the associated identity is within the From header. The
use of g= restricted keys implies a signature added by an entity of
limited trust where the domain may not be afforded an opportunity to
establish compliance when the related identity is not within the From
header.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html