[ietf-dkim] base-04 //inverting key t= 's'ub-domain flag

[Michael Thomas]

-1

First of all this would break backward compatibility with the existing
DK records. Second, I don't see what the problem is with the current
sense: if you don't like subdomains, by all means set t=s. And I can
tell you from first hand experience as somebody who has deployed
this: the subdomain signing feature is definitely being used, so the
comment on draft standard does not apply.

       Mike

Douglas Otis wrote:

> 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