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 Thu, 05 Jan 2012 17:18:53 GMT
Hi Chad,

> In addition, given the manner in which the IdResolver currently works, I
> believe it could be done away with entirely. The
> IdResolver.registerElementById method could simply be replaced by the
> appropriate Element.setIdAttribute* method.  Doing so would remove a
> potentially large in-memory data structure as well as various
> synchronization points that currently prevent concurrent ID resolutions.

I took a stab at implementing this to check for any problems (patch
attached). All of the tests on trunk pass with this change. One
potential issue is when you are creating a Signature which is signing
an "Object" contained in the Signature. In this case, the Signature
element must be available via the document element, or else it will
not be able to resolve the Object via "getElementById".

If people are more or less happy with this approach then I don't mind
dumping IdResolver.

I want to think about the duplicate Id thing a bit more before getting
back to you on that.

Colm.

On Wed, Dec 21, 2011 at 12:14 PM, Chad La Joie <lajoie@itumi.biz> wrote:
> So, last night I spent some time digging in to the new code and
> discussing with some things with Scott.  Here's where we ended up.
>
> The IdResolver is not designed in a manner that would allow alternative
> implementations to be used.  Though, given that it is only used by the
> ResourceResolver implementations, those could be replaced by the user of
> the library
>
> The new code does use the Document.getElementById method to look up IDs
> in the general case.  This may be overridden by explicitly placing
> ID-to-Element mappings into the IdResolver, but since doing this is
> neither documented nor shown in the examples it is fairly safe to assume
> this isn't happening out in the wild.
>
> Given the above, this code does not guard against any issues that may
> arise from duplicate IDs.
>
> In the case of signatures, there seems to be nothing that a library can
> do in order to ensure that the "right thing" is covered by the signature
> since the "right thing" is use-case specific.
>
> In the case of encryption, there is no way for the application to know
> whether the dereferenced encrypted encryption key is what the document
> author actually intended.  If it's not, however, the worst that would
> happen is that encrypted data would not decrypt.
>
> Given this, I believe the following things should be done:
> - The use of Document.getElementById and the potential issue caused by
> the lack of a strong guarantee on ID uniqueness should be documented.
> - The documentation for XMLSignature and all the examples should be
> updated to make it clear that the user of the library needs to check
> that what they thought was covered by the signature actually was.
> - Attempting to update the examples in this way will make it clear that
> better APIs need to be provided to expose the content indicated by
> <Reference>s.
>
> In addition, given the manner in which the IdResolver currently works, I
> believe it could be done away with entirely. The
> IdResolver.registerElementById method could simply be replaced by the
> appropriate Element.setIdAttribute* method.  Doing so would remove a
> potentially large in-memory data structure as well as various
> synchronization points that currently prevent concurrent ID resolutions.
>
> --
> Chad La Joie
> www.itumi.biz
> trusted identities, delivered



-- 
Colm O hEigeartaigh

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

Mime
View raw message