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(_at_)mipassoc(_dot_)org
Subject: RE: [ietf-dkim] Requirements on where/how SSP stuff
is published...
[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