One further thought, we might want to qualify the statement 'sign' with the protocol 'DKIM' and work through how we would cope with PGP, SMIME etc if we were going to support them within the same policy framework.
Not that we would actually put the result in the final document but we might want to go through the thought exercise. I suspect that the main issue we would come to in both cases is the lack of an effective, standardized means for discovering the key distribution mechanism. Working through the examples might well lead us to a syntax of the form: SIGN=DKIM,RR=*._domain.example.com & SIGN=SMIME,KD=XKMS & SIGN=PGP,KS=pgpkeyserve.ai.mit.edu Not that anyone would be likely to do all three signatures. Perhaps Jon could weigh in and explain how this is done in PGP Universal. > -----Original Message----- > From: Hallam-Baker, Phillip > Sent: Friday, July 28, 2006 4:22 PM > To: 'John Levine'; ietf-dkim@mipassoc.org > Subject: RE: [ietf-dkim] Requirements on where/how SSP stuff > is published... > > > > [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
