[ietf-dkim] Delegating responsibility: a make vs. buy design
ietf-dkim at kitterman.com
Thu Aug 24 11:15:15 PDT 2006
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.
More information about the ietf-dkim