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
