ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] The mystery of third party signatures

2009-10-06 14:51:35
On 10/5/09 5:38 PM, John Levine wrote:
In light of the comments by Bill Oxley and my belief that the ability of
a domain to designate signing by a specified 3rd party is useful, ...

It would really be helpful if you two could explain WHY you think it's
useful.  Given the way that DKIM works, there's only two possible
benefits from third party signatures.  Say we want to have isp.com
signing for its customer a.com:

A) a.com sends its mail through isp.com's system, a.com is unable to
sign mail before it's relayed to the smarthost, and it's too hard for
isp.com to apply an a.com signature

While it is possible for a.com to implement DKIM signing on their 
servers, they may not able to allow their roaming users access to their 
email server that resides behind a firewall access point.  It is even 
possible that a.com's ISP does not allow them to operate an externally 
accessible server as stipulated in their SLA.

As a result, a.com might wish to utilize the services of isp.com that 
signs with DKIM, and confirms a user's control of an email address 
before signing whenever the From header is not within the isp.com's 
domain.  This works fine until it comes time for policy to be applied.

B) Nobody's heard of a.com, so it wants to benefit from the reputation
of isp.com.

Unfortunately, that too is a valid reason for taking advantage of a 
larger providers size.

Also add-

C) To authorize mailing lists to better ensure their message's handling 
while asserting a policy of "all".

If you can't tell us which of these you have in mind, we're just going
to go around in circles.  I don't think there's any other problem that
DKIM signatures can solve, but if you disagree, please tell us what it
is.

An exchange of keys or selectors via CNAME records represents an 
unnecessary expense when compared to a unilateral 
base32(sha1(authorized-domain)) label published below the _adsp 
subdomain.  To ensure against collision concerns, the name of the 
intended domain can be also included within the resource records as well 
as the domains policies regarding this domain.

Such as:

_HGSSD3SNMI6635J5743VDJHAJKMPMFIF._adsp._domainkey.example.com.
  IN TXT "tpa=isp.com; scope=F;"

This authorization scheme would not require isp.com to change how they 
currently handle their email or sign with DKIM.  Such an authorization 
scheme scales and could better ensure the handling of messages from 
mailing lists, when more stringent policies are being applied.

-Doug


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html