santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Mullan <sean.mul...@oracle.com>
Subject Re: XML Security Java 1.5.0-RC1 available
Date Tue, 20 Dec 2011 18:45:58 GMT
On 12/20/2011 11:06 AM, Chad La Joie wrote:
> On Tue, Dec 20, 2011 at 10:55, Sean Mullan<sean.mullan@oracle.com>  wrote:
>> It no longer searches. All IDs have to be pre-registered. It knows about IDs
>> in the XML signature namespace so pre-registers those itself.
>
> I guess I'm missing something.  How is this done?  After a parse
> (without schema validation) no attributes would be marked as ID
> attributes.  So how does the library "pre-register" anything?

It has builtin knowledge of the XML Signature schema, so it is able to 
register all elements with ID attributes in the dsig namespace as it is 
parsing the XML Signature. If there are any duplicates, as of 1.5 it 
throws an exception.

> And are
> you saying that prior to signature validation (or encrypted key
> resolution), that the app must go through and register every
> ID/element mapping itself?

Just the ones that aren't in the dsig namespace. We don't have any 
knowledge of other schemas. I'm not sure about the enc namespace, will 
need to check that.

>> We could search the entire document every time for duplicate IDs but then
>> nobody would use the library because it would be too slow.
>
> Not to be flippant, but do you actually have anything to back that up?
>   Relatively speaking, a treewalk is pretty fast (when compared to
> things like canonicalization and various crypto functions).

We used to do a recursive walk of the tree every time to fix namespace 
attributes when canonicalizing to workaround bug 2560 in Xerces - the 
code is actually still in there - search for circumventBug2560.

I remember that when we removed the dependency on this method, there was 
a performance improvement, how much I don't recall but it was somewhat 
significant if I remember - these numbers could be in the archives 
somewhere, when I have some more time I'll check.

I would want to do some performance testing before we added something 
like this.

>> This is an issue that we can solve partially, but in my opinion higher level
>> APIs need to also do their job and register the IDs in their own namespaces
>> (or use a validating schema). Then wrapping attacks are not possible.
>
> Sure, and everyone should always completely bug free code.  They
> don't.  All I'm trying to say is that we could provide a real fix for
> this that protects people against an attack that is known to be in the
> wild and which all tested users of Santuario were vulnerable to.

Ok, I can see how this could make things easier and help screen out 
potentially dangerous documents. Would you have some time to writeup a 
patch that we could then do some more testing on?

--Sean

Mime
View raw message