Keep in mind, there's always sign(sign(plaintext)), which means that signing can still be a simple operation.
We're still at the point of seeing if there are enough people interested in having the discussion, so it's way to early to assume that there have been any decisions made about what is a common use case or not. On 3/26/11 12:10 PM, "Bryan Geraghty" <[email protected]> wrote: > 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 -- Joe Hildebrand _______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
