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
