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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html