santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Keeping <>
Subject Re: Removing references in xml-security-c
Date Sat, 20 Jun 2009 11:27:49 GMT
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.



John Keeping
Metanate Ltd (Software consultancy) (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.

View raw message