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 Tue, 10 Jan 2012 17:29:31 GMT
> 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 <coheigea@apache.org> 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 <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



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Mime
View raw message