OK, that makes sense. I've spent some time today reviewing my code and my test cases and have successfully managed to update everything to work the way I intended it to. I will have to reinforce the code to verify the warnings you've outlined.
I have one more extremely minor question. How does pretty-printing affect a signature? If I sign something, then run it through a pretty printer, will that break the signature? I haven't done it before because I didn't want to introduce any unnecessary issues into my signing code, but when my application saves data, I'd like to format it first. Michael Bishop On Mon, Aug 20, 2012 at 10:31 PM, Cantor, Scott <[email protected]> wrote: > On 8/20/12 10:26 PM, "Michael Bishop" <[email protected]> wrote: > > > >Which goes back to your original statement in that you have to "identify" > >ID attributes via a custom resolver, schema constraint, or DOM3 APIs > >calls? > > Yes, that's correct. Assuming ID based on attribute name alone opens you > up to wrapping attacks. Unfortunately, because Xerces is broken and > refuses to enforce ID uniqueness within the DOM itself (when you tell it > what the IDs are), you're still open to wrapping attacks even if you do > the right things superficially. > > In other words, be very, very careful. Never process signed content unless > you rely on an API that gives you only what was verified (fed into the > digest), or unless you "redo" the same ID lookup logic that the xmlsec > library does/did before passing anything that was supposedly verified into > application layer code. > > -- Scott > >
