On Friday 18 August 2006 20:04, Michael Thomas wrote:
Scott Kitterman wrote:
On Friday 18 August 2006 16:32, Jim Fenton wrote:
Scott Kitterman wrote:
What security problems are there with a list of authorized signing
domains that are not equally applicable to the the NS
delegation/operator signs with the author's domain approach? I'm
unclear about that. Maybe we can help each other out.
With key delegation (either with NS, or by publishing a TXT record with
a public key that the signing operator uses), the operator signs using
the author's (or more generally the delegator's) domain name, and can
use i= to specify that the signature corresponds to the author's
address. So it's possible to see that it's an author signature. With
authorized signing domains, the operator signs using its own domain
name, and no association with the specific signing address (either the
local-part, or specification of which delegated domain) is possible.
OK. I got that. Where I'm getting confused I guess is the process for
deciding which domain the operator should sign with....
For reference, I'll differentiate between the two approaches by calling
them the delegator approach (you describe above) and the authorized list
approach.
If you know the source that authenticated with the submission -- which I
think
we all agree is needed in the outsourced model -- then you only sign for
that source's
domain. If it happens to correspond to one of the outside headers such
as From:
or Sender: then you set i= to that address and everything works fine.
You never
get into this cross-domain signature ambiguity that Jim brought up.
Yes, but the fundamental operational problem will be to pick the correct
domain to sign with. You have to make that decision either way. The basis
upon which you make the decision is the same. I agree that the result LOOKS
less ambiguous with the NS delegation approach, but the fundamental security
issue is don't pick the wrong domain to sign with and that's no different.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html