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
_______________________________________________
ietf-dkim mailing list
http://dkim.org