Earl Hood wrote:
On July 29, 2005 at 13:57, Michael Thomas wrote:
The above example I provided does not provide an i= tag, so it assumes,
according to the DKIM draft, that i= is equivalent to d=. The problem
occurs if the signer wants to set i= to the actual identity of the
entity they are signing for if the signer is acting as a third-party
agent. The DKIM states that i= must be a subdomain of d=, but this
seems restrictive for 3rd-party scenarios where the signer may be in
a different domain.
It's _supposed_ to be restrictive. That is, I don't want earlhood.com
to be able to assert i=mtcc.com without my permission. The way I
grant permission is to create a selector for your signer's key in
mtcc.com's zone and then you just sign as d=mtcc.com even though it's
coming from one of your signers.
First, what is the operations risk of earlhood.com specifying mtcc.com
as a valid 3rd-party signer without explicit permission from mtcc.com.
Although it is not a nice thing to do, it seems to have no security
impact on mtcc.com.
No, it's the other way around that is constrained: you should not be able
to speak for mtcc.com if I don't explicity authorize it. With DKIM, the
way you authorize that relationship is by delegating a selector to a signer.
However, this still does not deal with a malicious domain spoofing
See my other post.
And from another mail:
Ah. BTW, what was the time constraint?
The IETF draft submission cutoff.