On Dec 24, 2007, at 2:12 PM, Jim Fenton wrote:
The cases where this might be beneficial are when there is an
invalid Author signature or when there's another signature, valid or
invalid, in the Author's domain, in all cases referencing a valid
selector.
Presence of a public key at a selector plays an insignificant role in
a signature's validity. While the SSP draft currently attempts to use
"on-behalf-of" the author to distinguish when SSP records are to be
retrieved, the resulting added criteria for when a signature is valid
is likely to be unnecessarily disruptive.
A message can be assumed to comply with either "all" or "strict" when
the message has:
1) A valid unrestricted signature at or above any Author's domain
2) A valid restricted signature on-behalf-of the From header
This two part definition ensures legitimate messages with valid
signatures are not unnecessarily classified as having invalid
signatures. Signing domains should not assume SSP will be applied.
When a signing domain does not want messages to be accepted based upon
which header their signature was on-behalf-of, the domain should not
permit such message to be emitted.
A message sent by an office administrator on behalf of a From author
and then signed with an unrestricted key should be seen as within the
signing domain control and therefore compliant with any of their
policies. Without modifying message handling defined in DKIM base,
signing is done by applying a signature on behalf of the Sender
header. This mode of handling is important, especially when only a
Sender header is associated with an identity authenticated by the
signing domain. The logic of your first sentence requires an SSP
"compliant" signature change DKIM base handling to:
1) remain ambiguous about which header is being signed on-behalf-of
2) lie about which header contains an authenticated identity
3) apply two signatures, where one lies or remains ambiguous
The invalid Author signature case will probably be relatively
common, but signatures from other addresses in the domain less so.
Agreed. Why not presume when signed with an unrestricted key of the
same domain as found in the From header, the message is to be
considered compliant with any this domains SSP policies?
It does seem that this might reduce the number of SSP lookups a bit,
however it would be necessary for a domain using this extension to
ensure that the SSP information in all key records is consistent
with that of the domain's SSP record.
You are describing a "scope" parameter added to Key records that
restricts which headers are valid for the signature to be on-behalf-
of. When private keys are deployed beyond the direct control of the
signing domain, not only a restriction on the local-part is needed,
but that of the scope of headers signed as well. Thus a restricted
key (g=<local-part>) might represent an "assumed" scope parameter, as
even a valid signature might not be compliant with a domain's desired
policy. An explicit scope placed within a key record could clarify
which headers are valid for a particular key, but this would be
unnecessary.
While appropriate for SSP compliance to limit the scope of
"restricted" key's to being on-behalf-of just the From header, it is
inappropriate for unrestricted key's scope to be limited in either
which header or which local-part is signed. In other words, SSP
should not attempt to dictate how the i= parameter is to be used. An
unrestricted key should be assumed to be within the direct control of
the signing domain, where the signing domain _MUST_ ensure their
messages are _NEVER_ in conflict with any of their own policies.
Policy enforcement of valid signatures by unrestricted keys is the
sole job of the signing domain, and never something the receiving
domain should be expected to implement. The signing domain _MUST_
enforce their own on-behalf-of policies when using unrestricted keys.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html