On Sat, 2006-04-01 at 21:56 -0800, Dave Crocker wrote: > > Barry Leiba wrote: > > And I'd like to get us to close on two other discrete parts: > > 1. Whether we want to have a mechanism to let the signature survive > > the reordering of multiple sig headers or not. > ... > > 2. Whether we want to be able to detect the removal of a signature > > header (as perhaps in the case of a "stronger" one and leaving a > > > My question for each is why? > > To do either of these requires additional mechanism.
Yes for 2. Perhaps a simple mechanism added optionally. > So the question is what benefit will accrue... and why that benefit > is essential to a task of the type DKIM is intended to perform? Transitioning algorithms in signed email may take long periods of time. When there are exploits possible with a prior algorithm being phased- out, until it is possible to ensure acceptance with just the newer convention, including both conventions will be required. This period could span a significant amount of time, and depend upon the motivation of all verifiers. Not have a mechanism to detect when the stronger signature is missing means even when the verifier does support a newer convention, the exploit remains possible, even for those verifiers that care about the problem. Selectively sending or verifying adds a greater amount of overhead. A simplest scheme would be to mark keys and signatures either primary or secondary and delete prior signatures. For signatures to be retained with common domains at the MSA, Mediator, or MDA, these roles could be combined with the primary/secondary indication. This differentiation of sources for signatures should safely allow these roles to establish a set of signatures that can be retained without domain conflicts. The greatest difficulty would be establishing an MSA instance that signs in the role of the Mediator, for use with list-server applications, as example. Everything else would be statically defined. Rules for handling signatures could default existing headers to be MSA-Primary without causing a problem. When the role is added to the signature/key, it would be the same for all messages and require just a small amount of fixed text. There is another benefit signature roles provide. This benefit is found when a local trust database are being maintained. These signature roles could minimize user interaction and improve security. This interaction might occur when a conflict otherwise appears to exist. These trust databases would be used for message annotation. A message with a signature with a non-matching role could be silently ignored, as it would not receive the annotation. This annotation might be which folder the message is placed into, for example. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html