Я так понимаю, когда в стандарте написано #xA это просто одиночный символ с кодом 10, то что Вы называете \n ведь в цитате не написано перед #xA амперсанда и в конце точки с запятой, как могло быть: 
 Таким образом, все правильно последовательность 
 меняют на одиночный символ #xA (он же \n) и не меняют \n.
То есть по основному стандарту XML процессор должен выполнить замену: \r\n заменяется на \n, "одиночные" \r без непосредственно следующего \n заменяются на \n.Верно, а еще дело в том, что при выборе фрагмента xpath может не выбрать ни одного перевода строки вообще - все в одну строку и по идее именно этот вариант должен передаваться на каноникализацию. А мы выбираем фрагмент для подписи непонятно каким образом и у нас во фрагменте оказываются переводы строк которых вообще в принципе быть не должно во фрагменте.

Отредактировано пользователем 23 октября 2018 г. 7:01:30(UTC)  | Причина: Не указана

"or by using some other method such that the characters passed to the application are the same as if it did this translation" Похоже на то, что он может выполнять это при передаче данных куда-то еще. Фиктивная такая замена, потому и поведение разное. А если мы вырываем у него фрагмент не предусмотренным способом эта замена не срабатывает.Вероятно, потому что в оригинале exclusive С14N трансформ хоть и разработан с прицелом на стандарт xmldsig, но все же не является его частью. Поэтому в трансформе предусмотрена замена символов \r на 
 хотя при нормализации с учетом пункта 7.1 xmldsig их вообще не должно остаться к моменту применения трансформа. По крайней мере, в фрагменте выбранном способом, при котором срабатывает фиктивная замена на \n.