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