[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of John Levine
I'm hoping that we can constrain the SSP info to a modest
number of bits, so DNS is is. If SSP bloats up to the point
where it doesn't fit in 512, then it's http.
I think that if we follow the approach that the policy record specifies the
acceptable selector records we can ensure that the policy record fits into a
single line.
I can't see a need for any party to sign a message more than twice (for
purposes of algorithm transition) and I can't see much utility in more than an
end entity signer and a gateway signer for a given domain. So the worst case
policy record would be something like:
"SIGN (ALWAYS (SELECTOR=*._ee_dsa.example.com) & ALWAYS (
SELECTOR=*._ee_rsa.example.com) &
ALWAYS (SELECTOR=*._gs_dsa.example.com) & ALWAYS (
SELECTOR=*._gs_rsa.example.com))"
This can be compressed pretty effectively:
SIGN=ALWAYS (*._ee_dsa.example.com & *._ee_rsa.example.com &
*._gs_dsa.example.com & *._gs_rsa.example.com)
Since the gateway signer can always enforce the policy requirement for the end
entity signature it is more likely that you would have an OR rather than an AND:
SIGN=ALWAYS ((*._ee_dsa.example.com & *._ee_rsa.example.com) |
(*._gs_dsa.example.com & *._gs_rsa.example.com))
This would allow the 'Keith Moore' criteria of allowing an end entity signature
in place of a gateway signature. In practice however OR alternatives can always
be addressed through hierarchy if need be so I won't argue a strong case for
needing the OR construct.
I think that 95% of cases would only require the gateway selectors so the
normal record would be:
"SIGN=ALWAYS"
The record used during an algorithm transition would be:
"SIGN=ALWAYS (*._ee_dsa.example.com & *._ee_rsa.example.com)"
The policy cases I see as being of interest are:
SEND=NEVER
SEND=ALLOWED
SIGN=NEVER
SIGN=ALLOWED
SIGN=ALWAYS
The useful combinations are
SEND=NEVER
SEND=ALLOWED,SIGN=NEVER
SEND=ALLOWED,SIGN=ALLOWED
SEND=ALLOWED,SIGN=ALWAYS
There is not much need for SEND=ALLOWED,SIGN=NEVER except to the extent you
might want to stop a heuristic search for a policy record. One could argue that
we could equally well specify SIGN=ALLOWED and not specify any key records.
I think that the useful keywords are
NEVERSEND
NEVERSIGN
MAYSIGN
ALWAYSSIGN
My preferred syntax would be something like:
**.example.com TXT "ALWAYSSIGN=*._ee_dsa.example.com &
ALWAYSSIGN=*._ee_rsa.example.com"
Note that we do not require the policy record to be within the originating
domain. We could have
**.example.com TXT "ALWAYSSIGN=*.outsourcesign.com"
We then load the rest of the policy into the key record.
If we want exceptions to the signature scheme we can do that with a key record
that specifies the NULL algorithm. In this scheme the key record specifies:
* The mail accounts that the key may be used to sign for
* The public key algorithm (NULL, RSA, DSA), the public key value
* The allowed hash algorithm (SHA1, SHA256, SHA512)
* The allowed canonicalization methods (Relaxed, Simple, whatever)
* Links to any additional information (e.g. a public key certificate) that
relates to the key
In addition we might also specify:
* NotBefore and NotAfter times for use of the key
The only other information I would consider loading into the base policy record
would be some sort of warning flag to indicate the probability that a failed
signature is likely to be a phishing attempt and some sort pf indication for
reporting failures.
**.bizybank.com TXT "ALWAYSSIGN SPOOFTARGET=99 REPORT=PINCH REPORT=YARP"
Always sign, probability a failed signature is a spoof is 99% or greater,
failures may be reported using either PINCH or YARP.
Note that we do not tell anyone how to react to the spoof target data, we
merely provide the information. In practice I think that most people at Paypal
and such would prefer it if we maximized the probability that the phishing
mails end up in the bit bucket rather than the probability that their personal
email is not false positived when the signature is damaged.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html