santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad La Joie <>
Subject Re: Id Resolution Observations and Suggestions
Date Fri, 06 Jan 2012 18:30:08 GMT
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 <> 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
trusted identities, delivered

View raw message