Mark Delany wrote: > On Mar 24, 2008, at 10:30 PM, Jim Fenton wrote: > >> The current utility is that, while extensions can be added any time, >> constraints need to be added up front. > > > Okay, I'll bite. Why is this a good idea? By way of contrast, when an > A RR is added to a DNS zone saying what address to use, no constraint > is placed on the sorts of connections that can be made to that > address. When an MX is added to a DNS, nothing is said about using it > or not using it for purposes other than finding a mail server (they > are of course used for anti-spam checking amongst other things).
I don't follow the A or MX examples; I don't see them as defining constraints. > > So I sort of struggle over why we would want to try and constrain the > use of a DKIM RR, particularly when we rely on the good graces of a > verifier to enforce that constraint and whether they do so or not is > entirely unknown to the DKIM RR publisher. Suppose that someone defined a standard for signing SIP INVITEs with DKIM signatures. (I know, SIP Identity uses an entirely different mechanism.) They might define s=sip for that service. A domain using DKIM for both email and sip might (should?) use different keys for the two services, and as you pointed out in your previous message this limits the scope of an internal compromise of a private key. It also limits the ability of an external party that has been delegated a key for a particular service to (mis)use that key for other, unauthorized services. Good graces? It's in the verifier's own interest to accept only valid signatures, so this doesn't seem like much of an imposition. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
