On August 25, 2005 at 09:22, Jim Fenton wrote: > I'm confused about this paragraph: "enabling TP signing is bad policy" > but "OA will not care if other entities sign...not claiming a 1st-party > association". A third-party signature doesn't claim a first-party > association, or at least that's my interpretation.
I was making the statement in the context of roles. For example, the OA would not care about transmission signatures, something that DKIM, as it is currently defined, does not directly support. > The intent of > restricting third-party signatures is to prevent messages signed by > mailing lists and the like (and particularly by attackers posing as > such) from being considered verified if there isn't also a valid OA > signature. Exactly. This is why third-party signing should never be enabled. As DKIM is defined now, no OA should ever enable 3rd-party signing. > >Side Note, I think it would be useful if the OA SSP allowed for > >an OA to designate a list of allowable signers. > > > I'm very concerned about the scalability of the allowable signers list. > There are circumstances where it would be very long. The OA domain > could delegate its _domainkey subdomain, or a subdomain of that, to an > allowed signer; since these signers are probably people "in the email > business" (outsourced email services) anyway, they should be able to > deal with that. Subdomain delegation will solve the key management problem. This technique may be worth mentioning somewhere (maybe in a HOWTO-type document),along with an example so OAs, with little DNS knowledge, can do it. > >>For those where this would matter, then > >>making the assertion should be required. > > > >You are assuming that a domain owner is aware of DKIM. When DKIM is > >deployed, you cannot require all domain owners to set up SSP records > >immediately. > > > I'm confused about who's saying what, apparently. I thought you (Earl) > were advocating a default SSP of "I don't sign anything" which would > require the SSP to be set up at the same time as the selectors. My statement refers to the default assumption made in the SSP draft about a non-existent SSP record. The draft states, If the Sender Signing Policy record does not exist, verifier systems MUST assume that some messages from this entity are not signed and the message SHOULD NOT be considered to be Suspicious. Nothing is said about a valid (non-OA) signature when no SSP record exists. Earlier in the draft, Verifiers checking messages that do not have at least one valid signature MUST perform a Sender Signing Policy Check by doing a DNS query to the domain specified by the Originator Address. Should it state, "do not have at least one valid *OA-based* signature..."? Otherwise, if the only signature is a valid third-party signature, no SSP check is required. A later sentence implies that and SSP check should be done if there is no valid OA-based signature, If a message is encountered by a verifier without a valid signature from the Originator Address, the policy results MUST be interpreted as follows... I am trying to get clarification in the various cases where no SSP record is available so I can accurately assess the security implications. --ewh _______________________________________________ ietf-dkim mailing list http://dkim.org
