mike at mtcc.com
Wed Jul 26 13:36:52 PDT 2006
Scott Kitterman wrote:
>On Wednesday 26 July 2006 14:14, Michael Thomas wrote:
>>This is a really good instance of what the base level requirements are.
>>On the one hand we can say that the requirement is that an ISP signing
>>on behalf of a customer actually sign on behalf of the customer. That
>>is, the d=customer.com rather than d=isp.com.
>>What I see here is the desire to actually have d=isp.com with the policy
>>saying that that is ok. One downside of this is that you'd require a policy
>>lookup because the From: address would still be customer.com, not
>>isp.com (ie, it looks like a third party). On the other hand, it doesn't
>>seem like it's a very big burden on the signing software to know what
>>domains it signs for, but I'm not as convinced about that from an
>I see it as a complexity tradeoff between managing multiple keys for multiple
>domains versus a single key for the ISP's domain and doing additional policy
>lookups for ISPs that sign 3rd party for their hosted domains.
I think the issue of multiple keys is orthogonal as you could use one
key in either scenario. My code, for example, currently supports either
key scenario: one key for multiple domains, different keys for different
domains, etc. I think the issue is whether the signer needs to keep track
of all the domains it signs for or not. It seems to me that it would though,
and if that's the case I'm not sure if it's worthwhile having indirection at
the policy layer instead of just doing at the signing layer.
>As far as the burden associated with knowing which keys to use on a per-domain
>basis, I think there are two classes of burden:
>1. The back end management and coordination to get and maintain keys from all
>the relevant customers.
>2. The operation of the signing library that signs with a different key
>depending on the sender.
>As far as how hard #2 is, does anyone's implementation support this currently
>(I'm asking, I don't know)?
Mine supports #2, and it wasn't all that complicated. Scaling it up to
thousands of domains would probably take some extra work for a
better data structure, but that's a pretty well understood problem.
More information about the ietf-dkim