[ietf-dkim] Reputation trusted layers is out of scope

[Stephen Farrell]

Hi Phill,

Is that "exceptions" stuff a requirement that's been discussed
before? I don't recall it anyway.

It sounds a bit of an edge case, though, so I wonder if there's
broad support for that feature?

Stephen.

Hallam-Baker, Phillip wrote:
>> [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Michael Thomas
> 
>>   10.  [PROVISIONAL] A domain holder MUST be able to publish 
>> a Practice
>>         which enumerates the acceptable cryptographic algorithms for
>>         signatures purportedly from that domain.
>>
>>            [INFORMATIVE NOTE: this is to counter a bid down 
>> attack; some
>>            comments indicated that this need only be done if the
>>            algorithm was considered suspect by the receiver; I'm not
>>            sure that I've captured that nuance correctly]
>>
>> I'm sure that I have no clue as to what nefarious intentions 
>> um, we, had in mind here. As always, it would be helpful to 
>> be specific about actual wording changes and/or showing wide 
>> support for new requirements.
> 
> I think that the above goal is useful but stating the goal should not commit us to realizing it in the SSP record.
> 
> 
> The discovery process we have for policy records appears to be:
> 
> 1) Does the email contain a signature that verifies and uses an acceptable cryptographic algorithm?
> 	IF YES return VERIFIED
> 
> 2) Is there a policy record that states that the message should have been signed?
> 
> 
> It is not possible to support strong policy using the SSP record alone unless we change the discovery algorithm. I don't think that is desirable or necessary. I want to have very detailed policy descriptions, descriptions that are far too complex to fit into a policy record.
> 
> But I can fit my policy statements into key records and this matches the idea that each key record you publish specifies an acceptable authentication mechanism. 
> 
> I would meet Hector's requirement by stating 'the set of all cryptographic algorithms acceptable to the sender equals the set of algorithms for which key records are specified'.
> 
> 
> The only 'strong policy' statement that cannot be supported in this scheme is one where you want to allow messages from selected senders to have no DKIM header whatsoever. We could for example specify a scheme such as:
> 
> _dkim.**.example.com  TXT "SSP (DKIM or AUTH=%sender%._exceptions.example.com)"
> 
> Where AUTH is a mechanism that allows us to declare specific authentication criteria for specified email messages. We could define a set of macro expansions for %sender%, %to% as we see fit.
> 
> For example the sender is marketting at example.com, the receiver pulls the policy record, then reads marketting.example.com._exceptions.example.com to get a policy record that says 'this one does not have signature records.
> 
> We could do the macro card thing, but I do not recommend we do. Too many moving parts for the return.
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>