I think that the NS suggestion is a bad one for policy reasons. I am never
going to delegate any part of my DNS. Space to a third party and I don't think
anyone else is likely to either. I think that there are much simpler and easier
ways to skin this cat.
The problem is that there is no way for me to delegate any part of my key space
without allowing the delegatee absolute control and the ability to impersonate
any sender in my domain that they choose.
Lets stop talking about NS records for a moment and consider the semantics that
we actually want in the delegated signing case. In particular to what extent do
we want the fact of delegation to be visible to verifiers?
Lets have some parties:
Party claiming responsibility for content: alice(_at_)example(_dot_)com
Party that has the signature key: remailer.com
1) Completely opaque delegation
Alice does not need to allow the world to know that the messages are actually
going to be signed at remailer.com. All she needs to do to allow this is to
simply insert the relevant key record in her zone:
remailerkey._domainkey.example.com TXT "key=423249671234986u3hf89713ty49y=="
If we are using dynamic DNS update we can automate this process using existing
standards.
2) Transparent delegation
Alice may want the world to know that there is a delgation relationship in
place and in particular she may want to retain control of the delegation
relationship.
This speaks to a need for TWO selector records, one in example.com and one in
remailer.com. The example.com selector needs to state that remailer.com is
allowed to sign for a particular email sender, the remailer.com selector needs
to contain the actual key. The effective selector record is the composite of
the two.
Lets get away from the DKIM ulta compact syntax for a moment and write the
attribute tags out longhand:
remailerkey._domainkey.example.com TXT
"sender=alice(_at_)example(_dot_)com"
"include=examplecomkey._domainkey.remailer.com"
examplecomkey._domainkey.remailer.com TXT "key=423249671234986u3hf89713ty49y=="
The DKIM header contains the selector remailerkey.
What we have here is a delegation mechanism that works but would require us to
rejig base. We can avoid this by putting the reference into the remailer policy
record (this is cleaner for legacy deployments as well):
remailerkey._domainkey.example.com TXT
"sender=alice(_at_)example(_dot_)com"
"delegate=**.remailer.com"
examplecomkey._domainkey.remailer.com TXT
"authority=remailerkey._domainkey.example.com"
"key=423249671234986u3hf89713ty49y=="
In this case we have very explicit statements of the form 'here I am delegating
authority to X' and 'here I am claiming a grant of delegated authority'. The
delegation relationship is transparent. This approach is also more flexible
than the scheme above since we delegate the power to define keys.
We have successfully achieved both types of delegation semantics without
recourse to any additional DNS feature and without doing damage to the DNS
semantics. We are much less likely to face unexpected interactions.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html