Ahh. Indeed. Yes, having those in the DNS record always struck me as oddly unnecessary.
d/ Jim Fenton wrote: > Dave Crocker wrote: >> >> Jim Fenton wrote: >>> Dave Crocker wrote: >>>> Jim Fenton wrote: >>>>> Dave Crocker wrote: The current utility is that, while extensions >>>>> can be added any time, constraints need to be added up front. So >>>>> if another service besides email wanted to use DKIM and its key >>>>> infrastructure, it wouldn't be possible to cause new keys created >>>>> for that service to not also be used for email unless we define it >>>>> now so that "legacy DKIM implementations" in the future will honor >>>>> the constraint. >>>> Actually, this all touches on the question of trying to recruit >>>> signature verifiers into the task of enforcing a signer's internal >>>> policies. That's what restrictions on authorization to signing are. >>> The same could be said about restrictions on hash and signing >>> algorithms, yet >>> those are essential. >> Because there is no interoperability if the two participants apply >> different >> hash algorithms to the same message. >> >> In other words, conformance to core technical details is rather >> different from >> attempting to direct the other side to apply the origination-side's local >> enforcement policies for who is authorized to use a key and what they are >> authorized to use it form. > > You're referring to the a= tag in the signature (which tells what > algorithms are used to generate the signature) while I'm referring to > the h= and k= tags in the key record. They constrain the signature and > hashing algorithms that may be used to generate signatures with that > key. This is required to prevent the use of weaker algorithms than the > signing domain intends to use. > > -Jim > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
