'making this up as I go' is really exactly the problem. multiple
signatures moves from one entity taking responsibility to some
unknown combination of responsibilities, ensuring substantially
greater complexity in the overall system. What are the relationships
among the signers? How much does the validator care and in what
way? etc.
Pardon my candor then: Of course I'm making this up as I go, because
we all know that this case isn't covered by the draft specifications.
Jim, my point was that the scenarios being discussed are frankly too
complex for standardization at this stage. That leaves *each of us* to
make it up as we go. Each of us will be reasonable, but different.
That's a very poor basis for standardizing something.
The bottom line is that it's up to the recipient.
Unless there is clearly defined, common (ie, standardized) semantics,
the recipient won't have any reasonable way of deciding what to do.
ps. the small matter of transitions, such as between different
signing keys, is really the argument that convinced me we needed
multiple signatures. but that is a "find one valid signature" rather
than :"analyze the relationship among multiple".
In that case, I would be more likely to overlap multiple selectors
(key records) than to use multiple signatures.
ok, but not sure i understand how to encode that, except as multiple
signatures.
d/
_______________________________________________
ietf-dkim mailing list
http://dkim.org