[ietf-dkim] Delegating responsibility: a make vs. buy design decision

[Scott Kitterman]

On Thursday 24 August 2006 13:49, Dave Crocker wrote:
> Stephen Farrell wrote:

> No we don't.  That is why it is important to recognize that the issue is
> *entirely* internal, with respect to the portion of the service that we
> *are* designing.
>
> > IMO, the SSP DSD mechanism is potentially
> > better from this angle since its ok to exchange signer names once and
>
> Yes, path registration is a very appealing concept... except for the
> problems with it, such as completeness and keeping things current.

I don't think anyone is proposing path registration.  If one want path 
registration there are already ways to do that.  In those terms I think DSD 
could be correctly termed origination registration.  

> If I am understanding the DSD concept, it pertains to publication of an
> authorization list.  So I think you are confusing publication of signer
> agent name, with the choice between NS delgation to an outsourced signer
> vs. giving a private key to them.
>
> Stated differently: I believe that publication of domains authorized to do
> signing provides the same functionality as NS delegation of a sub-domain,
> albeit with more mechanism, more complexity, and more risk.  But it has
> nothing to do with the way private keys are exchanged.

The only link is that if we don't do a DSD like function, domains that do not 
have access to NS delegation will have to do some kind of key exchange and 
publication.  Probably just public key, so I don't think it's a security 
issue, but it is a complexity/risk issue.

More mechanism yes, and marginally more complexity.  I guess those add to more 
risk, but I think the difference is in the noise.

> Offhand, I am not seeing why the communication of private keys is all that
> different when the signing group is outsourced than when it is exchanged
> within an organization.
>
The risk and complexity is greater.  That doesn't mean it has to be 
standardized, but it should be recognized as a risk.

Scott K