[ietf-dkim] domainkeys for other protocolls/applications
fenton at cisco.com
Wed Dec 7 10:28:53 PST 2005
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
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.
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:
> 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:
> When an other application uses domainkeys, should the published policy
> use another policy selector, e.g.
> 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
> PS: Is the DKP RR already defined?
> ietf-dkim mailing list
More information about the ietf-dkim