shibd unable to verify signature when metadata is cached

Cantor, Scott cantor.2 at osu.edu
Mon Mar 21 10:36:46 EDT 2016


> Part of c14n is to normalize linefeeds (to LF), and other part is to expand
> character references.

That's actually in the base XML spec. It's XML 1.1, but that hasn't changed, see section 2.11 of [1].

You'll note that single 0D characters have to be converted to 0A. That's what happens here, so 0D 0D 0A ends up as 0A 0A (I'm guessing).

The original source document has entity references in it, so if there's a bug, it may be that Xerces isn't actually converting the 0D that's in the entity reference. It's not immediately clear to me if it should be or not, but whatever it does do is apparently "correct" and consistent with the Java parser.

The round trip to the backup file loses the entity references and at that point the extra 0D characters are clearly linefeed separators and are being normalized out. So they clearly aren't being normalized out during the initial parse. I'm guessing the IdP and Java code create the backup file by copying the bytes directly but I don't know for sure.

I think the basic answer here is that my SP may not allow certain things to be done, more or less as a consequence of the design of the backup creation. It may be that you could use CDATA here and get it to work, but it really depends on the DOM, and I'm not sure that I preserve CDATA nodes either.

It's certainly a bad idea to try and slip in extra CRs whether it's a bug or not.

-- Scott

[1] https://www.w3.org/TR/2004/REC-xml11-20040204/#sec-white-space



More information about the users mailing list