Hi David, I'm just getting my feet wet with xml-sec so bear with me.
Are you trying to avoid having the <file> element copied in three signatures? Or having it transfered back to the central repository? Or are you looking for a group signature. (Saw a presentation at RSA 2004 by Dan Boneh http://robotics.stanford.edu/~xb/crypto04a/ that talked about this, but it might not be what you need). Noah On Mon, 21 Jun 2004 16:25:50 -0700, David Wall @ Yozons, Inc. <[EMAIL PROTECTED]> wrote: > > Perhaps some XML example info would make this more clear. > > Below is a document that contains a "blob" and some meta data about that > blob, in this case, it's a file. All three parties will sign this <file> > element's data and meta data, but each signature will contain some unique > meta data about each signer. > > <doc> > <file fileSizeInBytes="1520324" id="4512352"> > <originalFileName>contract.pdf</originalFileName> > <contentType>text/html</contentType> > <createdDateTime>2004-04-10 11:20:02 GMT</createdDateTime> > <creatorUser>2004-04-10 11:20:02 GMT</creatorUser> > <!-- base64 encoded version of the 1.5MB of PDF data that was in the > file contract.pdf --> > <data>WF0ZWx5I.... > ....pb24gb3IgSVBPL=</data> > </file> > </doc> > > <!-- This contains information about party1's signature of the <file> above > long with some > additional information here to be combined to create a ds:Signature > that can be transmitted > separately to all parties who already have an original copy of the > <file> element above. --> > <signatureTran> > <signerBlock> > <partyId>party1</partyId> > <fileId>4512352</fileId> > <reason>agree</reason> > <name>David Wall</name> > <title>Manager</title> > <date>06/01/2004</date> > <ipAddr>192.168.1.1</ipaddr> > <actualDateTime>2004-06-01 11:20:02 GMT</actualDateTime> > <platformAssertions> > <experianName>David Wall</experianName> > <experianLocality>Kirkland, WA</experianLocality> > <experianPassedDate>2003-12-18 17:45:32 GMT</experianPassedDate> > </platformAssertions> > </signerBlock> > </signatureTran> > > <!-- This contains information about party2's signature of the <file> above > long with some > additional information here to be combined to create a ds:Signature > that can be transmitted > separately to all parties who already have an original copy of the > <file> element above. --> > <signatureTran> > <signerBlock> > <partyId>party2</partyId> > <fileId>4512352</fileId> > <reason>disagree</reason> > <name>Betty Boop</name> > <title>Vixen</title> > <date>06/01/1956</date> > <ipAddr>192.168.1.2</ipaddr> > <actualDateTime>2004-06-04 22:14:31 GMT</actualDateTime> > <platformAssertions> > <emailAddressVerifiedDate>2003-12-18 17:45:32 > GMT</emailAddressVerifiedDate> > </platformAssertions> > <personalAssertions> > <homePhone>888.555.1212</homePhone> > </personalAssertions> > </signerBlock> > </signatureTran> > > <!-- This contains information about party3's signature of the <file> above > long with some > additional information here to be combined to create a ds:Signature > that can be transmitted > separately to all parties who already have an original copy of the > <file> element above. --> > <signatureTran> > <signerBlock> > <partyId>party3</partyId> > <fileId>4512352</fileId> > <reason>initial</reason> > <name>Snoopy</name> > <title>Red Baron</title> > <date>03/12/1972</date> > <ipAddr>192.168.1.3</ipaddr> > <actualDateTime>2004-06-03 07:52:01 GMT</actualDateTime> > <platformAssertions> > <emailAddressVerifiedDate>2004-06-03 07:45:13 > GMT</emailAddressVerifiedDate> > </platformAssertions> > <personalAssertions> > <owner>Charley Brown</owner> > </personalAssertions> > </signerBlock> > </signatureTran> > > So the idea is that party1 would sign the main "file" element along with the > personal meta data described in their "signatureTran" and then could > transmit the signatureTran and ds:Signature created to party2 and party3 so > that they could see party1 had signed and view the related meta data. By > being detached, there would be no overhead in transmitting the potentially > large <file> element. > > Later, party3 would sign the same main "file" element but with his own > personal meta data in the "signatureTran" and that would be sent to party1 > and party2. The same process would occur for party2 when the final > signature was done. > > In the end, all three parties would have the original <file> element, with > three <signatureTran> and three <ds:Signature> elements and could thus > verify all three signatures, but would be able to verify one, or two > signatures if that's all that were present at any given time. > > I hope this helps... > > David > > > > > ----- Original Message ----- > From: "David Wall @ Yozons, Inc." <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, June 21, 2004 11:23 AM > Subject: Re: ThreeSignerContract example -- detached signatures examples? > > > Blake, > > > > I would say that I'd be signing several XML elements, several smaller text > > elements of two varieties and one "big data element." The "big data" > > element would typicallbe be raw binary data since the source is typically > a > > data file like Word, Excel, GIF/JPEG, PDF, text, HTML, XML, audio, > > PowerPoint or project plan. > > > > The first type of smaller meta-data would be the SAME for all parties and > > would contain things like the original name of the file, the origainl file > > size, the content-type of the original data, the date the original file > > entered the system, etc. > > > > The second type of meta-data would be DIFFERENT for each signing party and > > would contain things like like their name, email address, IP address where > > they signed, actual datetime they created their signature and intention of > > the signature (approve, reject, initial, witness, > integrity-assurance-only, > > etc.). > > > > In general, the data to be signed will be in a single XML document and > won't > > be referenced by a URI primarily because the data can move and the data > can > > only be retrieved at a given URI after going through special > authentication. > > I would hazard a guess that using a detached signature (same-document > > detached) is our goal. > > > > I would like to generate a ds:Signature from Party1 (using Party1's copy > of > > an XML document) and transmit it to Party2 and Party3 and they could > simply > > append it to their copies of an original XML document and the signatures > > will compute for all three parties. This would mean the ds:Signature > would > > have to reference a common "big data element", common meta-data about the > > big data, and unique meta-data about the signing party. > > > > Then, if tomorrow, Party3 signed, I could send Party3's ds:Signature to > > Party1 and Party2, and they could append it to their original XML > documents > > and would now see both Party1 and Party3's signatures and all would > compute > > okay. > > > > And finally, when Party2 signs, his ds:Signature would be transmitted to > > Party1 and Party3, and all three would have the original XML document (as > > big as it might be) with three ds:Signature elements appended at the > > bottom(?) such that all three digital signatures could be validated > against > > that same BLOB of data as well as two types of meta-data. > > > > Is this possible? One key attribute is that it is possible that Party1 > and > > Party2 and Party3 would all sign at roughly the same time at independent > > locations, so we want the signatures to be detached enough to allow us to > > simply send each computed ds:Signature to the other parties such that no > > matter what order they are appended to their original data, the signatures > > will all hold true. We do this all today, but we don't use XML > Signatures, > > so that's our new challenge! > > > > Thanks for your interest and help, > > David > > > > > > ----- Original Message ----- > > From: "Blake Dournaee" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, June 21, 2004 10:02 AM > > Subject: RE: ThreeSignerContract example -- detached signatures examples? > > > > > > > Hi David - > > > > > > Is the data you are signing going to be opaque, binary data? That is, > are > > > you going to be interpreting the data to be signed as XML, or are you > > > considering it to be raw binary? > > > > > > Will you be referring to the data to be signed via an external URI (e.g. > > > http://www.some-location/mydata.bin). There is another type of detached > > > signature (same-document detchaed) where the data to be signed is within > > the > > > current XML document, but sibling to the <ds:Signature> element. Is this > > the > > > type of detached signature that you are interested in? > > > > > > I suppose I'm trying to understand your impetus for using XML Signature > if > > > you are going to be signing binary data. > > > > > > Kind Regards, > > > > > > Blake Dournaee > > > Senior Security Architect > > > Sarvega, Inc. > > > > > > -----Original Message----- > > > From: David Wall @ Yozons, Inc. [mailto:[EMAIL PROTECTED] > > > Sent: Saturday, June 19, 2004 9:41 AM > > > To: [EMAIL PROTECTED] > > > Subject: ThreeSignerContract example -- detached signatures examples? > > > > > > In my application, the data being signed can be quite large (1MB and > > more), > > > even though most may only be 100-250k range. The ThreeSignerContract > > > sign/verify examples are quite interesting, but in my case, each of > those > > > parties will be in different locations, signing at different times, and > > we'd > > > like our system to only transmit the new signature when it takes place > and > > > not the entire data wrapped in a signature. > > > > > > I'd like to be able to send the DETACHED ds:Signature elements only and > > thus > > > update the other party's copies to include the new signature so that the > > > next time they review their document, the system will show them the > newly > > > arrived digital signature. > > > > > > Is there a good example of creating a DETACHED signature in the > > > distribution? > > > > > > Thanks, > > > David > >
