Scott Cantor wrote: > John Keeping wrote on 2009-06-19: >> It seems that just removing a reference from a DSIGSignature object is >> not sufficient to do this, as the XML Reference element is still in the >> document (although it is not updated). > > That seems like a fundamental problem that has to be fixed systemically. I'm > not sure if the library in general supports resigning at all, so that may be > the problem. Is there reason to think that resigning would work if the DOM > manipulation was being done? Did you try that by hand and get it to work?
Yes, this works fine if I remove the reference elements from the DOM. As for resigning in general, isn't that what the templatesign tool does? Interestingly, while checking the source for that tool, I noticed that DSIGSignature::clearKeyInfo() does remove the DOM node in the signature, but then that's not signed so it's a bit easier. >> Am I correct in thinking that there is no way to extract information >> from a DSIGReference to match it back to the document other than walking >> the tree from the signature node looking for it? If so, do you think it >> would be possible to add an accessor to DSIGReference for the >> mp_referenceNode field? > > I don't think that's elegant unless all the DOMs are exposed (which is an > option), but more importantly my question would be what you would do with > it. I don't know that it would be safe to only remove that specific node and > then re-sign. Might be, I guess. I suspect it is as long as a simple check is made for consecutive text nodes after the element is removed. Namespaces shouldn't be a problem since the Reference element shouldn't contain anything not in the xmldsig namespace. > Anyway, I guess my point here is that the fix should be universal across the > APIs, and if mutation is both broken and feasible, that should probably be > fixed. > > I know in my case, I use an abstraction layer that's responsible for > creating the Reference List, and if I make changes, I drop the signature > object entirely and recreate it via that abstraction. That's probably why I > never noticed it. If there's not a better solution, perhaps it would be useful to have something similar in the core library? Maybe just DSIGSignedInfo::regenerateDOM() could remove all children of the signed info node and re-create them from the information in memory. Regards, John -- John Keeping Metanate Ltd www.metanate.com (Software consultancy) www.schemus.com (Data synchronisation) This e-mail and all attachments it may contain is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are those of the author and do not necessarily represent those of Metanate Ltd. If you are not the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, printing, forwarding or copying of this e-mail is strictly prohibited. Please contact the sender if you have received this e-mail in error.
