Removing references in xml-security-c

[John Keeping <jo...@metanate.com>]

Hi,

I'm working on a product which needs to resign documents after modifying
them and in some cases this involves removing references from the
signature (for example if the referenced element has been deleted).

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).

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?


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.

RE: Removing references in xml-security-c

[Scott Cantor <ca...@osu.edu>]

John Keeping wrote on 2009-06-20:
> 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?

Literally have no idea.

> 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.

I'll check into it.

> 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.

That's the sort of assumption correct XML code doesn't make, but it isn't
currently part of my scope to totally redo the XML processing in the code.
At some point I either will do that, switch to a different library, or
literally rewrite it all to handle only the use cases I need, at which point
it doesn't help you anyway.

I'm not sure what you mean by checking for text nodes. If you're changing
the document, I don't think whitespace impact is too important.

> 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.

That might be the best solution, but I don't know if it's feasible with the
current design, or if it is the work involved might be similar to other
options.

I do plan to look at this, but I don't know when I'll have that chance. Not
for a little while at any rate.

-- Scott

Re: Removing references in xml-security-c

[John Keeping <jo...@metanate.com>]

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.

RE: Removing references in xml-security-c

[Scott Cantor <ca...@osu.edu>]

John Keeping wrote on 2009-06-19:
> I'm working on a product which needs to resign documents after modifying
> them and in some cases this involves removing references from the
> signature (for example if the referenced element has been deleted).
> 
> 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?

> 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.

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.

-- Scott