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(_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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html