[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
I was thinking it might make sense to allow the SSP DOMAIN to
define a policy attribute in its SSP record which exposes the
expectation for body truncations.
I agree that this should be a capability, but I disagree with extending the
policy specification.
The rules of DKIM mean that any information of this type must go into the key
records. If a verifier finds a valid, trusted DKIM signature the policy record
would not normally be read.
The only circumstance in which we expect that the policy record will be read is
when the verifier has not found a signature it trusts, i.e. :
1) There are one or more signatures that do not verify
2) The verifier does support the signature algorithm
3) The verifier does not consider the signature algorithm sufficiently secure
So if the feature is to be supported the only place to put it is in the key
record as a key signing constraint.
I don't see any reason not to extend the key record to support policy
objectives. We defined an extensible framework, our specification has only got
to stage 1 of a three stage process. If people want all the keyrecord stuff to
be in one document we can address this when we refactor the documents during
the DRAFT standard stage. This does not force a recycle at PROPOSED unless we
introduce new MUST criteria that are not in either PROPOSED standard.
At this point the only useful DKIM policy record I can see is 'All documents
from this domain carry a DKIM signature header with a key selector that
conforms to this constraint'.
This indicates to me that we should not be discussing a DKIM policy record
perse but instead a policy record for outbound email that has a simple,
extensible syntax that allows us to make other statements we might want to
make, e.g. 'this email address is a phishing target', 'please report
verification failures here', 'the outbound edge gateway always offers SSL', etc.
In other words the DKIM policy language has the following atomic statements:
DKIM All mail carries a DKIM signature
DKIM=<suffix> All mail carries a DKIM signature with
a selector that ends in .<suffix>
If people want to allow for the case where signatures are applied less than
100% of the time we might define 'TESTING-DKIM' as a tag.
If people want to have a policy but allow some mail to go out effectively
unsigned then we could introduce a NULL key record which has a selector but no
data and is not therefore considered a trustworthy algorithm by any sensible
verifier.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html