I'm one of these "advocates". The use case has been defined and acknowledged. Having to duplicate a document merely because the engineers of the signing protocol decided that multiple signatures isn't a common enough use case seems ridiculous.
The best security concepts are simple. So requiring the implementor to come up with an external strategy for verifying that the signed documents are identical, and managing the relationships between copies of the document signed *by n* signers sounds like an implementation nightmare. If it were me, I'd be hard-pressed to chose this system. Doesn't a single copy of a document with multiple signatures attached seem like a much simpler and more elegant solution? Bryan On Tue, Mar 22, 2011 at 4:32 PM, Mike Jones <[email protected]>wrote: > That is a potential representation for the concept. I believe that its > advocates would argue that repeating the payload in each message is > redundant and not space-efficient, but I'm not personally taking a position > on this use case either way. > > -- Mike > > -----Original Message----- > From: Dick Hardt [mailto:[email protected]] > Sent: Tuesday, March 22, 2011 2:29 PM > To: Mike Jones > Cc: Joe Hildebrand; Paul Hoffman; [email protected] > Subject: Re: [woes] Preparation for the WOES meeting > > > On 2011-03-22, at 2:19 PM, Mike Jones wrote: > > > The use case for this comes from the OpenID Contract Exchange > specification, where they want multiple parties to have signed the same > plaintext in no particular order. This occurs in real life, for instance, > when both parties have to sign the same business or real estate contract. > > Why not solve this infrequent use case with multiple identical messages > signed separately? > _______________________________________________ > woes mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/woes >
_______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
