(Note: the reply will come in separate emails mostly on per issue basis,
this is part1 of the reply)
On Wed, 13 Jul 2005, Jim Fenton wrote:
William, thanks for your comments. Responses inline.
william(at)elan.net wrote:
1. Selector
v>> It is not clear what subdomain is used for public key. In 3.7.2.1
it says that "DKIM keys are stred in a _domainkey subdomain" where
as example in B.3 uses "brisbane._dkim.example.com".
_domainkey is correct; it was chosen in order to allow existing DomainKeys
keys to be reused for DKIM.
I think you should stay away from terms that are known to have unresolved
trademark issues (this in in fact IETF policy for its documents if I'm
not mistaken). This is especially the issue if the term is going to be
part of the record name (if its just used in RFC or draft, IETF can always
publish new draft and replace questionable term, but with deployed base
using such record name this is very big issue).
As far as existing _domainkey users, clearly they will have to install
new software anyway and if they want to use both _domainkey and _dkim,
its not terribly hard - just use CNAME or NS pointing to the same zone
(far less of a problem then publishing new record).
So I'm quite strongly against using _domainkey and would prefer to see
_dkim in your draft's next version (if any prefix is there at all).
Personally I think you should drop specifying some particular subdomain
(I did even in first META draft) as requirement and make it part of the
selector itself - you alread allow it to include "." so its not much of a
difference. The change would be from:
DKIM-Signature: a=rsa-sha1; s=brisbane; d=example.com;
to:
DKIM-Signature: a=rsa-sha1; s=brisbane._dkim; d=example.com;
Note: you can also probably integrate "d" with "s" too but them
being separate might be useful, more discussions are needed.
One concern with making the prefix (_domainkey) explicit is that it might
v> allow too much flexibility; if for some reason unrelated to message
signing
one needs to delegate _foo.example.com, it may not be intended that the
delegatee have the ability to create selectors and start signing mail.
If you left out the underscope on the prefix, it might be possible to use
s=brisbane.example; d=com and suddenly example.com would be able to sign
for .com, which is clearly unacceptable.
In META-Signatures I was dealing with this issue and came up with the
following scenario:
1. If there is no subdomain (i.e. record directly in domain root like SPF),
then its properly authorized
2. If underscore is present, assume its properly authorized by parent zone
(based on the fact that its well known policy of ISPs and domain
registrars to not assign _subdomain to its users) but optionally allow
those who way do special SRV record (if not present then authorized)
3. If underscore is not present then require special SRV records to indicate
authorized use of subdomain for parent domain cryptographic data
With above s=record._domainkey and s=record._dkim would both be considered
authorized as is if its "s=;" but s="brisbane.example" would not be
proper record for .com.
We need to keep "d" and "s" separate in order to know where to insert
the _domainkey in the query and to enforce the parent domain rule
("d" must be the same as, or a superdomain, of the "i" address).
Since you already have "i", I do not see as much reason for "d".
If you had something like i=(_at_)example(_dot_)com;
s=brisbane._dkim.example.com;"
then you could fairly easily find based on "i" that brisbane._dkim
is proper host in the domain to be authorized and then check if its
first subdomain "_dkim" starts with underscore.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net