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