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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html