[ietf-dkim] domainkeys for other protocolls/applications

[Steve Atkins]

On Wed, Dec 07, 2005 at 10:59:19AM +0100, Klaus Darilion wrote:

> I wonder if it was ever considered to use the Domainkeys technology also 
> for other applications than email. For example I've implemented a 
> proof-of-concept implementation of Domainkeys for SIP:
> http://openser.org/pipermail/devel/2005-November/001222.html
> 
> IMO domainkeys is a smart technology and can be used for more than 
> email. Of course, the signing/validation algorithm has to be adopted, 
> e.g. there is no Sender: header in SIP.
> 
> One important aspect of using domainkeys for other applications is the 
> coexistence of the several domainkeys applications without interference, 
> e.g. multiple domainkeys application can overlap in the DNS. Publishing 
> public keys under different domains should be no problem using different 
> selectors for each application. But I wonder about the policy record. 
> E.g. the policy record for DKIM is at:
>   _policy._domainkey.domain

There would be no need to prefix the policy with an underscore. One
misplaced underscore is enough to avoid stepping on other parts of the
DNS tree.

> When an other application uses domainkeys, should the published policy 
> use another policy selector, e.g.
>   _sippolicy._domainkey.domain
>
> or should the policies all be put in the same domain, but using a 
> certain tag-value pair to identify the service, e.g.:
> 
>   _policy._domainkey.domain TXT "o=-;a=email"
>   _policy._domainkey.domain TXT "o=~;t=y;a=sip"

Without commenting on the rest, this approach is not as good as the
multiple selector approach as it is likely to lead to bloating the
response beyond the size of a UDP packet. Depending on the software
involved you may end up with some semi-random subset of the responses
or escalation to TCP access.  Neither is a good thing.

Cheers,
  Steve