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