Scott,
I don't know if you have looked at Hector Santos policy document, he
does a very good job of assigning values and tags that define needed
policies.
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.txt
we should all take a look, some good ideas in there.
Thanks,
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Scott Kitterman
Sent: Wednesday, July 26, 2006 5:42 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] requirements
On Wednesday 26 July 2006 16:36, Michael Thomas wrote:
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
operational standpoint.
Agreed.
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.
It would also have to determine if, in fact, a message it was signing
for a
domain was actually from an authorized sender for that domain (a
requirement
no matter how this beast gets killed).
I don't know how detailed the requirements document you are working on
is
intended to be....
At a high level, I think it is a requirement that the DKIM with a sender
policy protocol support the use case of multiple administratively
separate
domains sending signed mail via a shared (e.g. ISP) server.
This has several lower level requirements that I can think of offhand
for the
signer:
- Ensuring that messages that are signed for a domain are from an
authorized
source for that domain.
- Signing the message in a way that allows receivers to know that the
signature is an authorized signature for the sending domain (and this
could
be first party using one or more keys or 3rd party with a policy record
that
indicates that the signer is authorized)
- Public or Public/Private (depending on how the previous requirement
is
satisfied) key exchange and maintenance.
The domain owner will have to publish the key and possibly a policy
record in
their DNS.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html