> [mailto:[EMAIL PROTECTED] 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