Yeah, sorry I meant to look at your patch last night but got sidetracked. The patch you have looks like what I expected to see. And yes, what you stated below sounds correct.
On Fri, Jan 6, 2012 at 13:16, 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. -- Chad La Joie www.itumi.biz trusted identities, delivered
