[ietf-dkim] domainkeys for other protocolls/applications

[Jim Fenton]

We have been thinking about this a bit, although the SIP folks have 
mostly been going in a different direction (see 
draft-ietf-sip-identity-06 for details).

If you look at the DKIM draft, draft-allman-dkim-base-01, section 3.7.1, 
the s= tag is intended for just this purpose.  It allows public keys to 
be published in DNS that are valid for specific services only. The idea 
is that an MTA might sign using a key that is only valid for mail, and a 
SIP proxy might sign using a key that is only valid for SIP.  In that 
way, a domain owner could delegate the ability to sign mail to a third 
party, without also delegating the ability to sign SIP INVITEs (for 
example).

As you point out, there are a few different ways that signing policy can 
handle services.  You can make the service name a "selector", or use a 
tag similar to s= in the policy record.  The latter doesn't scale as 
well to large numbers of services, but the SSP records are short to 
begin with, and I can't think of enough services to run out of UDP-space 
for the policy.

-Jim

Klaus Darilion wrote:

> Hi!
>
> 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
>
> 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"
>
> Thanks for any comments
> Klaus
>
> PS: Is the DKP RR already defined?
> _______________________________________________
> ietf-dkim mailing list
> http://dkim.org
>