[ietf-dkim] Re: Step 9

[Michael Thomas]

Jim Fenton wrote:
> The key words here are Verifier Acceptable.  The verifier gets to
> specify which signatures are Verifier Acceptable, which gives it
> precisely the liberty you describe.
>   

We're not communicating. What might a receiver do differently with a third
party signature with and without the "all"? I can't think of anything.

Also: there are two orthogonal things going on with "all": the general 
proposition
from the originator that they sign everything, and this third party 
signature thing.
At the very least, they should be decoupled.

       Mike

> -Jim
>
> Michael Thomas wrote:
>   
>> Step 9 of the SSP lookup algorithm sez:
>>
>>   9.   If the value of the SSP "dkim" tag is "all", and one or more
>>        Verifier Acceptable Third-Party Signatures are present on the
>>        message, the message is not Suspicious and the algorithm
>>        terminates.
>>
>> I don't see the motivation for this, and it's definitely not in the
>> requirements. A
>> receiver is always completely at liberty to whitelist, blacklist,
>> greylist,
>> pink-polka-dotted-list a third party signature regardless of what the
>> originating
>> domains says. What unique value does a signer bring to an across the
>> board
>> statement about all third party signatures? I can't think of a single
>> use case that I'd
>> alter processing based on that information.
>>
>>       Mike
>>
>>
>> Jim Fenton wrote:
>>     
>>> The list has been uncharacteristically silent since I submitted an
>>> update to the SSP draft 10 days ago, so I thought I'd point out the new
>>> draft (draft-ietf-dkim-ssp-01) and a few of the highlights (more
>>> complete info on the changes are in section B.1).
>>>
>>> The most significant change is a new tag, called "handling", that
>>> represents what I called the SSP "Strong" Option in my presentation at
>>> IETF 69.  As I mentioned at the time, we needed a better word than
>>> "strong", and this is what Eric and I came up with.  It takes one of two
>>> values:  "process", the default, means to do what you would normally do
>>> with a message that is Suspicious.  "block" is a way for a domain to
>>> express the preference that messages violating SSP be dealt with more
>>> harshly, such as by deleting, bouncing, or rejecting them.
>>>
>>> Section 5, "Third-party Signatures and Mailing Lists", has been removed
>>> since it belongs better in the Overview document(s).  Note to overview
>>> authors:  hint, hint.
>>>
>>> Most of the other changes in the document, which are numerous, are to
>>> tighten up the wording rather than to introduce anything new or
>>> different.  For example, when user-granularity SSP was in the document,
>>> SSP applied to an "entity" which was either a user or a domain.  the
>>> word "domain" is sufficient, and clearer, now.
>>>
>>> Comments appreciated as always!
>>>
>>> -Jim
>>>
>>> _______________________________________________
>>> NOTE WELL: This list operates according to
>>> http://mipassoc.org/dkim/ietf-list-rules.html
>>>   
>>>