I'd be interested to see your simple and elegant approach to having multiple signatures that provides nominal additional complexity for the single signature use case.
-- Dick On 2011-03-26, at 11:10 AM, Bryan Geraghty 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
