> 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.
I've committed some code that does this: https://issues.apache.org/jira/browse/SANTUARIO-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183384#comment-13183384 Colm. On Fri, Jan 6, 2012 at 6:16 PM, Colm O hEigeartaigh <[email protected]> wrote: > 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 -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
