On Mon, 26 Feb 2007 18:20:12 -0000, EKR <ekr(_at_)networkresonance(_dot_)com>
wrote:
Hector Santos <hsantos(_at_)santronics(_dot_)com> writes:
if S says I only sign with A, then R should not see signatures with B,
X or Y.
OK, but we're discussing what sorts of policies S should be able to
communicate. In particular, should S be able to say "I sign with
both A and B and any signature you see from me will have both,
not just either."
The problem is that we cannot foresee (remember we are merely discussing
SSP requirements now, not SSP itself) what may be needed for SSP in the
future in order to counter threats we cannot even dream of at the moment.
Therefore, one requirement I would like to see for SSP is that its
notation should be _extensible_. Indeed, using XML for reporting SSP
policies might be a good way to go about it (except that XML is a bit
verbose if it has to be squashed into DNS records somehow).
It seems to me that you're denying a basic premise of the system.
From base S 4.2:
Verifiers SHOULD ignore failed signatures as though they were not
present in the message. Verifiers SHOULD continue to check
signatures until a signature successfully verifies to the
satisfaction of the verifier. To limit potential denial-of-service
attacks, verifiers MAY limit the total number of signatures they will
attempt to verify.
And that SHOULD in base is blatantly WRONG. You cannot instruct verifiers
as to what they SHOULD or SHOULD NOT (or even MUST) do. They are free
agents and can do what they like.
But, in any case, we are not concerned with "failed" signatures (to which
that SHOULD applies) here. We are concerned with signatures that are quite
possibly valid, but where the verifier does not possess the tools needed
to verify them. Base is totally silent on what to do in that situation.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html