ietf-dkim
[Top] [All Lists]

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

2006-08-28 14:29:50

[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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(_dot_)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

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