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

[Douglas Otis]

On Jul 19, 2006, at 5:06 PM, Michael Thomas wrote:

> Douglas Otis wrote:
>>
>> On Jul 19, 2006, at 3:42 PM, Michael Thomas wrote:
>>
>> It depends upon what default is desired when the "s" flag is not   
>> specified.
>
> Wrong. DK records sign for all subdomains. That is the current  
> semantic. Changing that semantic is not backward compatible. Your  
> desire does not get around that basic fact.

Introduction of the "s" flag changes semantics in the handling of  
subdomain identities one way or the other.  Depending upon the sense,  
the flag will be introduced within the key when either there is a  
desire to constrain the signing of subdomain identities, or when  
there is a desire to not constrain them.  A change in the key record  
is needed in one case or the other.  The key record is not the only  
element affected; the DKIM signature header field version MUST also  
change.  The signature version defines the semantics of the tags.  An  
older verifier ignoring the "s" flag and the signature version gets  
the semantics wrong in either case and can not be seen as backward  
compatible.

The desired default and the recommended mode should prevail.  This is  
not an issue of retaining backward compatibility.  Imposing the  
constraint may become the norm, and the recommendation should be that  
the constraint be removed only when required.  Removal of this  
constraint is never required however.  A lack of constraint  
facilitates fabricating signing identities while eliminating the  
means to ascertain the signing domain's administrative control.  This  
mode seems highly prone to abuse.  This lack of constraint imposes  
both administrative and security concerns that may result in  
subdomain identities being commonly found unacceptable.  Just as with  
the l= tag, ignoring questionable parameters should provide correct  
behavior.  Currently the "s" flag has the wrong sense to follow this  
paradigm and defaults to an insecure mode.

While understanding the desire not to revisit the key record during  
an upgrade when signing subdomain identities, making the choice based  
upon convenience seems to provide poor results.

-Doug