Ну вот сбылась мечта идиота...
В Microsoft.Xades добавил класс Prefix, а в нем три префикса:
prefixXmldsig = "ds";
prefixXades = "xades";
prefixXSD = "xsd";
Пробежался по всем текстам.
Теперь префиксы можно задавать "на ходу"
даже prefixXmldsig = "UraBorke";
Подпись с таким префиксом и формируется и стандартной SignedXml проверяется.

Вопрос 1: Кто бы мне объяснил глубокий смысл наличия префикса "xsd" и множеству выборов узлов с ним?
Кстати насколько я понимаю стандарт не требует
prefixXmldsig = "ds" и префикс может быть любым.

Далее TimeStamp - сформировал, запросил, получил, вырезал, вставил.
Проверку пока не делал, ибо не знаю точно что и как.
Проверил с помощью tsputil.exe, и мне ответили:
Смущает Policy ID, это так и надо?
Радует "Verification of time-stamp: succeed"
Вопрос 2: Если succeed, то все нормально?

Дополнительно: Если посмотреть на внутренности System.Xml.dll и поискать "ds",
то найдется и не одно вхождение. С моей точки зрения это бардак

Отредактировано пользователем 1 августа 2015 г. 18:45:11(UTC)  | Причина: Добавил про SignedXml

Решил поделиться с теми кому интересно.
Microsoft.Xades.Prefix.cs Используется примерно так:
xmlNamespaceManager.AddNamespace(Prefix.PrefixXSD, XadesSignedXml.XadesNamespaceUri);
и
NodeList = XmlElement.SelectNodes(Prefix.xsd("QualifyingProperties"), xmlNamespaceManager);

Остается только сожалеть что нет реализации поиска узла по локальному имени.
Сколько бы проблем снялось...
Это я очень мягко выразился
Для особо любопытных могу отдать и перелопаченный текст Microsoft.Xades
Все. Московское время 00:58 спать пора.

Ну да, ну да. Теперь я после проверки пришедшего добавляю в первый узел атрибуты проверено="дата" и пробелы="ага". так и храню. А девочкам отдаю форматированный БОДИ.

Рэзал и буду Рэзать.
При передаче для авто обработки отдаю OuterXml, бэз пробелов, или по почте раром
А вот если в письме CtrlC CtrlV, то indent=ON и примечание "пробелов нет"

А это, кстати, часто попадается. Многие сервисы вообще не заморачиваются с header переменными ответа. Я встречал сервисы, где вообще не было Content-Length. В результате приходидось читать из стрима до тех пор, пока не получал таймаут на операцию чтения, и после этого проверял ответ на целостность.
Поскольку диктовать правила конторам типа Казначейства и прочим федеральным министерствам - дело тухлое, приходится подстаиваться под их рукожопных программеров.

А по поводу PreserveWhitespace и преобразований в dom парсере: представьте, что подпись поставили на документ с внутренним тегом <data/>. Если подпись ставили не на MS .NET, а в какой-нибудь linux java, где такого преобразования не предусмотрено, вы подпись не проверите. За те годы, что я занимаюсь всяческой криптографией (а это уже лет 15, если не 20) у меня выработалось железное правило: после подписи документ не меняется до момента проверки этой подписи. Подпись проверил - дальше загружай документ куда хочешь, до этого документ - просто набор байт.

И кстати, насчет алиасов пространств имен: алиас может быть любым, поэтому при разборе xml-документов с namespace-ами я всегда задаю свой список для namespacemanager, что позволяет указывать алиасы не из документа, а из моего списка.

И да, при вложенных документах пространства имен могут содержать элементы из любых других пространств, если такое предусмотрено схемой документов. Пространство имен - это просто область ответсвенности определенного разработчика схем документов. В СМЭВе это буквально на каждом шагу.

Не, позволю себе не согласиться. Трансформатор "с14" перед подписью, проверкой переведет <data/> и <data /> в форму <data></data>. Другое дело "LF"(\n) все заморочки из за него.
Какая интересная мысль
Я в эту сторону даже не думал. Замечательно.
Получается что ежели в документе есть <votvam:money>, то при соответственном расширении namespace-ов я могу поискать как <figvam:money>, так и <votvam:money>