ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

2006-08-18 12:06:32
At 2:15 PM -0400 8/18/06, Damon wrote:
But this takes away my control over who can sign for me.
In my opinion there _must not_ be a way for someone to sign for _me_
without my approval. In this example you are showing what (1) might do
if they receive email from (2) which has nothing to do with the (1)
and has everything to do with (2). Having said that, there should be
no relationship between (1) and (2) in this example. Trusted or not
trusted... You are mixing the receiver and the sender policies.

From a security protocol perspective, there is no way to prevent someone from wrapping a message in a signature. This was debated at nauseam by the OpenPGP and S/MIME Working Groups; it was the same rathole.

From a security policy perspective, the message protocol can have a mark that says "only entity XYZ is authorized to sign this message". If another entity wraps that message in a signature, and does not remove that mark, the verifier can decide that the mark trumps the signature and consider the signature invalid. However, if another entity wraps that message in a signature and *does* remove that mark, there is nothing that the creator of the message can do. Also note that if another entity wraps that message in a signature and *replaces* that mark with one that says it is authorized, there is nothing that the creator of the message can do.

It sounds like what you and few other people want is an SSP policy that says "if you receive a message that is supposedly from this site (for some definition of "from") and it doesn't have the mark that says that XYZ is authorized to sign the message, assume the message is forged". Is that a correct summary of the requirement you see?
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>