santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cantor, Scott" <canto...@osu.edu>
Subject Re: XML Security Java 1.5.0-RC1 available
Date Tue, 20 Dec 2011 16:43:46 GMT
On 12/20/11 11:36 AM, "Colm O hEigeartaigh" <coheigea@apache.org> wrote:

>What we could do is add some functionality that checks that each
>(local) Reference URI in a Signature is in the document tree and is
>unique.

The reference itself is the result of resolution of the ID. If there's a
duplicate, the results could be unique, but still wrong. The key point is
that the app and the library have to resolve to the same reference element
(and check transforms, etc.)

One way is to expose the resolved element (see what was signed). Another
is to enforce a totally app-controlled algorithm over resolution. I'm
saying that DOM calls render the latter pretty difficult to pull off if
the parser is allowed to be broken.

> The retrieved element could be set on IdResolver. This way,
>the tree is only walked once, instead of each time IdResolver is
>called when resolving a reference, as is the case for 1.4.x. This
>behaviour could be controlled by a property, possibly defaulting to
>true.

If you mean that the app tells the library what element a given ID should
map to, I think that's what you're already doing, minus the fact that
you're allowing for DOM lookup also.

>Would this address your concerns?

I think cutting off DOM support is a major step to take, since it's makes
schema validation insufficient to establish IDness and will break existing
apps. But if that's the conclusion (perhaps as an option or by default),
then we need to clearly communicate that change, and I should implement
something similar in C++.

So far, I haven't taken any new steps because I'm waiting to see what the
"right" answer is.

-- Scott


Mime
View raw message