On Jan 10, 2008, at 3:58 PM, Jim Fenton wrote:
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.
Jim,
Your statement appears to be in error. Please review the "all" and
"strict" definitions:
---
The SSP definition for "all":
All mail from the domain is signed; unsigned email MUST be
considered Suspicious. [Others might modify and sign.]
The SSP definition for "strict":
All mail from the domain is signed; messages lacking a valid
Originator Signature MUST be considered Suspicious. [Others
are not expected to modify and sign.]
---
The additional requirement of a valid "first author" signature for
"strict" makes "all" significantly different. The "first author"
signature definition currently stipulates that a signature is not
compliant unless on-behalf-of the "first author", even when signed by
an unrestricted key of the "first author's" domain. IMHO, this
creates an unnecessary and unreasonable exclusion for unrestricted keys.
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.
No. As currently defined by SSP, signatures are not "strict"
complaint when not seen as on-behalf-of the "first author". However,
as currently defined by SSP, a restricted key is SSP "all" compliant
regardless of who the signature is on-behalf-of provided the signature
is valid. This means the compliance state must be currently tracked,
where the recommended change does not alter the need for this
tracking. There is RFC 4871 valid, and SSP "all" and "strict"
compliant. Any verification process must keep track of a signature
being both valid and SSP "strict" and "all" compliant. The change
being recommended is to minimize the difference between being valid
and "strict" compliant. The change reduces the requirement for
unrestricted key being SSP "strict" complaint where the "on-behalf-of"
would not matter. Only restricted keys must be seen as on-behalf-of
the "first author".
In all other respects, the selector data is only used [for]
verifying the signature itself.
I am unsure what you mean by selector, but a selector does not appear
to play any role here. I assume you are concerned with passing
results from the verification process. The verification process would
need to signal the detection of a restricted key in addition to
validity.
When deciding whether to request an SSP policy, a verifier would first
determine whether the message contains an SSP "strict" complaint
signature per the revised definition. This definition only excludes
"first author" domain signatures that are using a restricted key not
on-behalf-of the "first author". When a SSP "strict" compliant
signature is determined, there would not be any need to query for SSP,
as the message would meet the definition of both "strict" and "all"
compliance.
When the signatures of the "first author" domain are using a
restricted key and are not on-behalf-of the "first author", compliance
therefore depends upon finding either "all" or "unknown" SSP
assertions. Perhaps RFC 4871 should have declared any restricted key
not on-behalf-of the first author to be invalid. A restriction on
what headers a restricted key is allowed to sign would allow combining
together both "valid" and "restricted" results into a single state.
However, AFAIK, restricted signatures are valid for any header and are
compliant with an "all" policy assertion.
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.
There is no justification for having an SSP "strict" assertion require
the use of ambiguous signatures, or signatures falsely identifying who
the signature is on-behalf-of! Your approach greatly reduces the
utility of the i= parameter. It would also represent an unlikely
application of RFC 4871. As currently SSP assertions are currently
defined, compliance MUST BE tracked separately from that of a
signature being valid.
I don't see the advantage of doing it this way, and a couple of
disadvantages.
I hold the opposite view. I don't see any advantage using your
definition other than being able to combine together the "valid"
result with that of a "restricted" key.
Your approach of combining valid with restricted:
1) limits the utility of the i= parameter
2) creates astonishing corner cases
3) increases the likelihood of needing to discover SSP records
4) distorts who a DKIM signature can be on-behalf-of
Our different perspectives appear to result from combining RFC 4871
valid, and SSP "all" or "strict" compliant into a single state. These
truly represent different states. Combining "valid" and "compliant"
is already wrong per the current SSP definitions for "all".
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html