A possible use of DKIM is to validate email-addresses through a
comparison against a "signing identity". An extension to this
feature allows simple inclusion of subdomains within the signing
identity that are independent of the signing domain from where the
key is referenced. This extension could be seen as having problems
analogous to that of validating cookies within sub-domains. The
related issue with cookies is discussed within dns-ops.
See:
http://www.ietf.org/internet-drafts/draft-pettersen-dns-cookie-
validate-00.txt
In addition to changing the default to being a "safe" mode of
operation, a safety or administrative concern may prompt for this
feature to be removed in the final draft version. By not recognizing
the "s" flag through removal of its description, this extension could
be disabled only when the meaning of the "s" flag and associated
default is inverted.
To gracefully allow removal of this feature, should that become
required, the sense of the "s" flag and the corresponding defaults
should be inverted as follows:
,---
|3.8 Signing by Parent Domains
|
|In some circumstances, it is desirable for a domain to apply a
|signature on behalf of any of its subdomains without the need to
|maintain separate selectors (key records) in each subdomain. By
|default, private keys corresponding to key records can be used to
|sign messages for any subdomain of the domain in which they reside,
|e.g., a key record for the domain example.com can be used to verify
|messages where the signing identity (i= tag of the signature) is
|sub.example.com, or even sub1.sub2.example.com. In order to limit
|the capability of such keys when this is not intended, the "s" flag
|may be set in the t= tag of the key record to constrain the validity
|of the record to exactly the domain of the signing identity. If the
|referenced key record contains the "s" flag as part of the t= tag,
|the domain of the signing identity (i= flag) MUST be the same as that
|of the d= domain. If this flag is absent, the domain of the signing
|identity MUST be the same as, or a subdomain of, the d= domain. Key
|records which are not intended for use with subdomains SHOULD specify
|the "s" flag in the t= tag.
'---
change to:
: In some circumstances, it is desirable for a domain to apply a
: signature on behalf of signing identities (i= tag in the DKIM
: signature field) within subdomains of the signing domain (d=
: tag in the DKIM signature field) without the need to maintain
: separate key records referenced from each subdomain. Without the
: referenced key record containing the "s" flag as part of the t=
: tag, the domain of the signing identity MUST be the same as that
: of signing domain. By default, private keys corresponding to key
: records will not provide valid signatures for messages having a
: signing identity within a subdomain of the signing domain. When
: required, the "s" flag may be set in the t= tag of the key record
: to enable such keys to provide valid signatures for signing
: identities within subdomains of the signing domain, e.g., a key
: record would permit a valid signature for the signing domain
: example.com when the signing identity is sub.example.com, or even
: sub1.sub2.example.com. If this "s" flag is present, the domain of
: the signing identity MUST be the same as, or a subdomain of, the
: signing domain. Key records which are not intended for signing
: identities within subdomains of the signing domain SHOULD NOT
: specify the "s" flag in the t= tag.
,---
| 3.6.1 Textual Representation
|...
| s Any DKIM-Signature header fields using the "i=" tag MUST have
| the same domain value on the right hand side of the "@" in
| the "i=" tag and the value of the "d=" tag. That is, the
| "i=" domain MUST NOT be a subdomain of "d=". Use of this
| flag is RECOMMENDED unless subdomaining is required.
'---
change to:
: s Without this flag being asserted, any DKIM-Signature header
: field using the "i=" tag MUST have the same domain value on
: the right hand side of the "@" in the "i=" tag as the value
: of the "d=" tag. Without this flag, the "i=" domain MUST NOT
: be a subdomain of "d=". This flag should only be asserted
: when subdomains are required within the DKIM signature field
: "i=" value that do not appear within the "d=" value.
Also note that section 3.8 incorrectly uses (i= flag) instead of (i=
tag).
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html