Blake, Thank you for the detailed response. It was very helpful. A few questions based on your observations:
> A few words of warning at the outset: Specific elements to be signed can be > referenced via Id attribute or XPath. After thinking about your situation, > the preferred simple way of Id attribute references will not really work in > your situation because an Id in document #1 is not going to match, so when > the signatures move, the verification won't work. Why is the Id attribute unworkable? For example, if I use a string GUID for the Id, would that work then? Each element in our system actually has such a unique id already (for primary key), though it's meaningless to people. But the same "file", even if included in lots of different XML docs would all have the same string GUID. Our GUID looks something like a URI but with no protocol prefix. > * You'll have to use an XPath expression to reference the element(s) to > sign. This is usually slower and less efficient, but it may be the only way > to go for your problem domain. I'll give it a try if Id really won't work. In general, signature generation needs to be "fast enough" from a human's perspective since they will be waiting when the signature is applied, and hopefully signature verification wouldn't be too much longer. Of course, when I use a "hard-coded" set of digital signatures, it's quite fast enough, since I'm just signing a series of byte arrays. > <wrapped> > <doc> ... </doc> > <SignerTran> ... </SignerTran> > <ds:Signature> ... </ds:Signature> > </wrapped> Gotcha. I already figured we have some sort of common root for all of our XML documents in this respect since I want to make sure that if someone takes a given 'doc' and its related signatures that they get them all as a single complex element that can be moved and used elsewhere. > The <ds:Reference> will be an expression of the form > "ancestor-or-self::file" and "ancestor-or-self::SignerTran". There will be > two references, one for <file> and one for <SignerTran>. The empty quote > On the URI reference means that the entire node-set must be processed and > the necessary portion "filtered" out. Would it be any faster if it gave a more complete path, like ancestor-or-self:/wrapped/doc/file? Or is the idea that we don't want it to be too specific so that somebody could take a signed document like we have here, and embed it in yet another XML doc, but located elsewhere in the tree (i.e. /someotherdoc/anothertran/wrapped/doc/file)? > <wrapped> > <!-- top portion, file --> > <doc> > <file Id="fileId"> ... </file> > </doc> > <!-- bottom portion, metadata and signature --> > <SignerTran ... </SignerTran> > <ds:Signature> ... > > <ds:Reference URI=""> > <Transforms> > <Transform> > <Xpath> ancestor-or-self::file </XPath> > </Transform> > </Transforms> > </ds:Reference> > > <ds:Reference URI=""> > <Transforms> > <Transform> > <Xpath> ancestor-or-self::Signer1 </XPath> > </Transform> > </Transforms> > </ds:Reference> > > </ds:Reference> > > </ds:Signature> > </wrapped> Is the second Xpath supposed to be ancestor-or-self:SignerTran, or was the 'Signer1' reference to an Id attribute? How would a second signature applied look? Can I have I multiple ds:Signature elements in this document? I presume the difference is that the Xpath for the SignerTran would be have to vary depending on which user's meta data was being included. > Just to summarize: > > 1. Your scenario can be accomplished using XML Signature > 2. Use XPath transforms to identify the elements to be signed, because Id's > won't be consistent from document to document > 3. The type of signature in the XML Signature nomenclature is "same-document > detached signature" > 4. Make sure that you add a wrapped element if you want well-formed XML. Where is the 'same-document detached signature' type specified in the Apache APIs? I don't see anything similiar in the ThreeSignerContract examples. Or is it just figured out because the ds:Signature element doesn't wrap the data when I copy the created ds:Signature element into that area of the DOM before I write it back out? > As for the Apache APIs, you can probably use them to make a prototype, but > depending on your performance requirements, generating the signature may be > slow, it all depends on how fast these must be generated. Well, we don't need a prototype. Is there another API that would be much better at this, or is it just that XML DSigs are not real fast yet because they are fairly new? > Kind Regards, > > Blake Dournaee > Senior Security Architect > Sarvega, Inc. Thanks again, Blake. You have been most helpful and I'll run some prototypes this week if I can figure out those Apache APIs well enough to implement that in code! Best regards, David
