santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Id Resolution Observations and Suggestions
Date Fri, 06 Jan 2012 18:16:39 GMT
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 <cantor.2@osu.edu> wrote:
> On 1/5/12 12:18 PM, "Colm O hEigeartaigh" <coheigea@apache.org> 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

Mime
View raw message