I'd like to summarise my current understanding of this issue. The patch I attached previously simplifies how same-document References are retrieved by using the Document.getElementById() call, whereas previously a static cache was also searched. The new behaviour is fully pluggable, as you can just plug in a different ResourceResolver implementation if you want to retrieve same document Elements in a different way. The only downside is that it will break existing applications that sign an Object that is not already in the document tree, but I'm ok with that as this is a new major release.
The next issue is that the element returned by Document.getElementById() is not guaranteed to be unique, thus potentially facilitating wrapping attacks. I've added a "secure validation" switch which sets some security constraints on signature validation (defaults to false). I propose to add a tree search when this switch is enabled, which will check that each Reference URI that is a fragment or XPointer reference is unique in the document. Finally, the application must check that the dereferenced Elements that were signed are in the location in the document that it expects them to be signed. The JSR-105 API facilitates this by caching the references (this must be configured by setting a property to true). The "old" API does not return the Reference Elements. I will look into adding some functionality for this. Does this sound like a reasonable course of action? Colm. On Thu, Jan 5, 2012 at 8:11 PM, Cantor, Scott <[email protected]> wrote: > On 1/5/12 12:18 PM, "Colm O hEigeartaigh" <[email protected]> wrote: >> >>If people are more or less happy with this approach then I don't mind >>dumping IdResolver. > > My position is just that it should be one or the other, and not both (or > making the whole ting fully pluggable so the application just decides), > and that obviously a change that involved removing the DOM call by default > would have to be phased in. > > I'm supportive of making changes to the C++ in that vein (I think it's > pluggable now, but I need to do some checking). > > You're correct that in addition to the DOM3 requirement, using the DOM > means that all content has to be reachable from the document element. But > I'd note that the ability to not require that is most likely a nice gaping > hole to more security weirdness, esp. on the verifier end. > > -- Scott > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
