For example, the XML spec says the XML parser must map bare carriage returns to 
a new line character.
We had to change our serializer to quote the carriage returns in text values 
(like this &#xD);
This is a constant complain from our users that don't expect this ugly sequence 
in their output
but it avoids a bug similar to what you describe.

>From the XML Spec:

2.11 End-of-Line Handling
XML parsed entities are often stored in computer files which, for editing 
convenience, are organized into lines. These lines are typically separated by 
some combination of the characters CARRIAGE RETURN (#xD) and LINE FEED (#xA).

To simplify the tasks of applications, the XML processor MUST behave as if it 
normalized all line breaks in external parsed entities (including the document 
entity) on input, before parsing, by translating both the two-character 
sequence #xD #xA and any #xD that is not followed by #xA to a single #xA 
character.



-----Original Message-----
From: Cantor, Scott E. [mailto:[email protected]] 
Sent: Wednesday, April 06, 2011 11:30 AM
To: [email protected]
Subject: RE: Issue in Verifying Signing

> True. Once the Xml Document is changed to string data, encoded in Base 64,
> decoded and parsed back into a Xml document, we are unable to validate the
> signature.

Then "changed to string data" is most likely corrupting the XML. Probably a 
whitespace issue.

> Any help in things I should be looking for and/or trying would be greatly
> appreciated.

https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManSigErrors

-- Scott

Reply via email to