logo
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline Степан З  
#1 Оставлено : 1 августа 2018 г. 11:28:42(UTC)
Степан З

Статус: Новичок

Группы: Участники
Зарегистрирован: 31.07.2018(UTC)
Сообщений: 9
Российская Федерация
Откуда: Екб

Добрый день!

Есть три подписанных xml-файла.

В первом файле значения текстовых узлов не содержат символов перевода каретки (CR, 
, \r, 
 и т.д.):
Код:
<?xml version="1.0" encoding="utf-8"?><Root v="2" a="1"><Value>part1part2</Value></Root>


Во втором такой символ встречается:
Код:
<?xml version="1.0" encoding="utf-8"?><Root v="2" a="1"><Value>part1
part2</Value></Root>


В третьем есть он же, но в каноническом виде:
Код:
<?xml version="1.0" encoding="utf-8"?><Root v="2" a="1"><Value>part1&#xD;part2</Value></Root>



Во всех трех случаях алгоритмы канонизации, хеширования и подписи одинаковые:
Код:
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
    <SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001-gostr3411" />
    <Reference URI="">
      <Transforms>
        <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
      </Transforms>
      <DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411" />
      <DigestValue>fzJ2...g8I=</DigestValue>
    </Reference>
  </SignedInfo>
  <SignatureValue>WcHL...Eg==</SignatureValue>
  <KeyInfo>
    <X509Data>
      <X509Certificate>MIIJ...Bmk=</X509Certificate>
    </X509Data>
  </KeyInfo>
</Signature>


Канонизация исходного файла делается средствами .Net-а трансформацией System.Security.Cryptography.Xml.XmlDsigExcC14NTransform.
Код:
var xmlTransform = new XmlDsigExcC14NTransform();
xmlTransform.LoadInput(x);
var output = (MemoryStream) xmlTransform.GetOutput();


После трансформации получаем такие строки (декодированые из UTF-8)

В первом случае:
Код:
<Root a="1" v="2"><Value>part1part2</Value></Root>


Во втором и третьем:
Код:
<Root a="1" v="2"><Value>part1&#xD;part2</Value></Root>


Во всех трех случаях трансформация соответствует стандарту и правилам канонизации xml-exc-c14n# основанной на XML-C14N

Однако при проверке на КриптоПро DSS только первая подпись является математически корректной.
Почему две другие не проходят математическую валидацию?
Такое ощущение, что на стороне сервиса проверки происходит какая-то другая трансформация, которая иначе обрабатывает символ перевода каретки в текстовых узлах.

Первый файл, чья подпись математически корректна:
Код:
<?xml version="1.0" encoding="utf-8"?><Root v="2" a="1"><Value>part1part2</Value><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001-gostr3411" /><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></Transforms><DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411" /><DigestValue>fzJ2YKJyg+HT7l9wyz/coc2Cg02A672DmHGL8lNlg8I=</DigestValue></Reference></SignedInfo><SignatureValue>WcHLnCl+8z9iWJSfYRe0TkjyttIPSvvxwroO+mCvCstluqJr8YQArvAcec6DqhwOorWscsOghgi9cWtcLvxiEg==</SignatureValue><KeyInfo><X509Data><X509Certificate>MIIJrzCCCV6gAwIBAgIKa0sArwAAAAOsaDAIBgYqhQMCAgMwggFbMRgwFgYFKoUDZAESDTAwMDAwMDAwMDAwMDAxGjAYBggqhQMDgQMBARIMMDAwMDAwMDAwMDAwMSQwIgYDVQQJDBvQo9C70YzRj9C90L7QstGB0LrQsNGPIDEz0LAxHjAcBgkqhkiG9w0BCQEWD2NhQHNrYmtvbnR1ci5ydTELMAkGA1UEBhMCUlUxMzAxBgNVBAgMKjY2INCh0LLQtdGA0LTQu9C+0LLRgdC60LDRjyDQvtCx0LvQsNGB0YLRjDEhMB8GA1UEBwwY0JXQutCw0YLQtdGA0LjQvdCx0YPRgNCzMSgwJgYDVQQKDB/Ql9CQ0J4g0J/QpCDQodCa0JEg0JrQvtC90YLRg9GAMTAwLgYDVQQLDCfQo9C00L7RgdGC0L7QstC10YDRj9GO0YnQuNC5INGG0LXQvdGC0YAxHDAaBgNVBAMTE1VDIFRlc3QgKFF1YWxpZmllZCkwHhcNMTYwNDA3MTEzMTAwWhcNMjEwNDA3MTE0MDAwWjCCAlExGDAWBggqhQMDgQ0BARIKMDAwMDAwMDAxMjEaMBgGCCqFAwOBAwEBEgwwMDY2OTkwMDAwMDAxIDAeBgkqhkiG9w0BCQEWEWthdHNAc2tia29udHVyLnJ1MQswCQYDVQQGEwJSVTEzMDEGA1UECAwqNjYg0KHQstC10YDQtNC70L7QstGB0LrQsNGPINC+0LHQu9Cw0YHRgtGMMSEwHwYDVQQHDBjQldC60LDRgtC10YDQuNC90LHRg9GA0LMxKDAmBgNVBAoMH9CX0JDQniDQn9CkINCh0JrQkSDQmtC+0L3RgtGD0YAxGzAZBgNVBAsMEtCU0J/Qny4g0KPQoC4g0J7QoDEtMCsGA1UEAwwk0JrQsNGGINCe0LvQtdCzINCV0LLQs9C10L3RjNC10LLQuNGHMTAwLgYJKoZIhvcNAQkCDCE2Njk5MDAwMDAwLTY2OTkwMTAwMS0wNjUwNDEyMzQ1NTIxVTBTBgNVBAwMTNCe0L/QtdGA0LDRgtC+0YAg0K3QktCcINGBINC90LDQstGL0LrQsNC80Lgg0L/RgNC+0LPRgNCw0LzQvNC40YDQvtCy0LDQvdC40Y8xDzANBgNVBAQMBtCa0LDRhjEmMCQGA1UEKgwd0J7Qu9C10LMg0JXQstCz0LXQvdGM0LXQstC40YcxKDAmBgNVBAkMH9GD0LsuINCd0L7QstCw0Y8sINC0LjIsINC60LIuMzExGDAWBgUqhQNkARINNDc5OTYwMTI0NzY0MDEWMBQGBSqFA2QDEgs2NTA0MTIzNDU1MjBjMBwGBiqFAwICEzASBgcqhQMCAiQABgcqhQMCAh4BA0MABEBi+gUpHga2hULQ3eySF4B2/J6O24anFT6LPCLZEnRCw3eAr3m2Yu7iDxNOMxl+eMuth7bvr1tajeKntZ4ADB/Co4IFBjCCBQIwDgYDVR0PAQH/BAQDAgTwMBMGA1UdIAQMMAowCAYGKoUDZHEBMDcGA1UdJQQwMC4GCCsGAQUFBwMCBgcqhQMCAiIGBgcqhQMDBwgBBggqhQMDBwEBAQYGKoUDAwcBMDsGA1UdEQQ0MDKgMAYJKoUDAwcBAQEBoCMMITY2OTkwMDAwMDAtNjY5OTAxMDAxLTA2NTA0MTIzNDU1MjAdBgNVHQ4EFgQUBpmk9MwOmAPrdOHpsPe8zp86uDcwggGcBgNVHSMEggGTMIIBj4AUwpQH565Pv7nAWWiEiNAsfvAtQHOhggFjpIIBXzCCAVsxGDAWBgUqhQNkARINMDAwMDAwMDAwMDAwMDEaMBgGCCqFAwOBAwEBEgwwMDAwMDAwMDAwMDAxJDAiBgNVBAkMG9Cj0LvRjNGP0L3QvtCy0YHQutCw0Y8gMTPQsDEeMBwGCSqGSIb3DQEJARYPY2FAc2tia29udHVyLnJ1MQswCQYDVQQGEwJSVTEzMDEGA1UECAwqNjYg0KHQstC10YDQtNC70L7QstGB0LrQsNGPINC+0LHQu9Cw0YHRgtGMMSEwHwYDVQQHDBjQldC60LDRgtC10YDQuNC90LHRg9GA0LMxKDAmBgNVBAoMH9CX0JDQniDQn9CkINCh0JrQkSDQmtC+0L3RgtGD0YAxMDAuBgNVBAsMJ9Cj0LTQvtGB0YLQvtCy0LXRgNGP0Y7RidC40Lkg0YbQtdC90YLRgDEcMBoGA1UEAxMTVUMgVGVzdCAoUXVhbGlmaWVkKYIQVJ4AlkGFxItA0uUhz9irCTByBgNVHR8EazBpMDKgMKAuhixodHRwOi8vY2RwLnNrYmtvbnR1ci5ydS9jZHAvdWMtdGVzdC02M2Z6LmNybDAzoDGgL4YtaHR0cDovL2NkcDIuc2tia29udHVyLnJ1L2NkcC91Yy10ZXN0LTYzZnouY3JsMIGXBggrBgEFBQcBAQSBijCBhzBBBggrBgEFBQcwAoY1aHR0cDovL2NkcC5za2Jrb250dXIucnUvY2VydGlmaWNhdGVzL3VjLXRlc3QtNjNmei5jcnQwQgYIKwYBBQUHMAKGNmh0dHA6Ly9jZHAyLnNrYmtvbnR1ci5ydS9jZXJ0aWZpY2F0ZXMvdWMtdGVzdC02M2Z6LmNydDArBgNVHRAEJDAigA8yMDE2MDQwNzExMzEwMFqBDzIwMjEwNDA3MTEzMTAwWjA2BgUqhQNkbwQtDCsi0JrRgNC40L/RgtC+0J/RgNC+IENTUCIgKNCy0LXRgNGB0LjRjyAzLjYpMIIBMQYFKoUDZHAEggEmMIIBIgwrItCa0YDQuNC/0YLQvtCf0YDQviBDU1AiICjQstC10YDRgdC40Y8gMy42KQxTItCj0LTQvtGB0YLQvtCy0LXRgNGP0Y7RidC40Lkg0YbQtdC90YLRgCAi0JrRgNC40L/RgtC+0J/RgNC+INCj0KYiINCy0LXRgNGB0LjQuCAxLjUMTkPQtdGA0YLQuNGE0LjQutCw0YIg0YHQvtC+0YLQstC10YLRgdGC0LLQuNGPIOKEliDQodCkLzEyMS0xODU5INC+0YIgMTcuMDYuMjAxMgxOQ9C10YDRgtC40YTQuNC60LDRgiDRgdC+0L7RgtCy0LXRgtGB0YLQstC40Y8g4oSWINCh0KQvMTI4LTE4MjIg0L7RgiAwMS4wNi4yMDEyMAgGBiqFAwICAwNBAEorSWc+XdBeFxfLgFSYHKYJbjsQKVBP1EThYcbfZh5jfxnR0yTP4P+NEgbidg0J3ys2wLnN5w95HmypClvBBmk=</X509Certificate></X509Data></KeyInfo></Signature></Root>


Второй и третий, которые не проходят математику:
Код:
<?xml version="1.0" encoding="utf-8"?><Root v="2" a="1"><Value>part1
part2</Value><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001-gostr3411" /><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></Transforms><DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411" /><DigestValue>cxuyd7P51Wm1YstYM4EOoBXSWOMl+hOSewq0g+/hoZc=</DigestValue></Reference></SignedInfo><SignatureValue>cPU4B78LtoY+5HdmIxyaCxqxAWVcKzORZKLSjEEx/mwKNcAwoVwnBvv1DVg5khTELbKMRRsxTyNWIIzlsAOXSA==</SignatureValue><KeyInfo><X509Data><X509Certificate>MIIJrzCCCV6gAwIBAgIKa0sArwAAAAOsaDAIBgYqhQMCAgMwggFbMRgwFgYFKoUDZAESDTAwMDAwMDAwMDAwMDAxGjAYBggqhQMDgQMBARIMMDAwMDAwMDAwMDAwMSQwIgYDVQQJDBvQo9C70YzRj9C90L7QstGB0LrQsNGPIDEz0LAxHjAcBgkqhkiG9w0BCQEWD2NhQHNrYmtvbnR1ci5ydTELMAkGA1UEBhMCUlUxMzAxBgNVBAgMKjY2INCh0LLQtdGA0LTQu9C+0LLRgdC60LDRjyDQvtCx0LvQsNGB0YLRjDEhMB8GA1UEBwwY0JXQutCw0YLQtdGA0LjQvdCx0YPRgNCzMSgwJgYDVQQKDB/Ql9CQ0J4g0J/QpCDQodCa0JEg0JrQvtC90YLRg9GAMTAwLgYDVQQLDCfQo9C00L7RgdGC0L7QstC10YDRj9GO0YnQuNC5INGG0LXQvdGC0YAxHDAaBgNVBAMTE1VDIFRlc3QgKFF1YWxpZmllZCkwHhcNMTYwNDA3MTEzMTAwWhcNMjEwNDA3MTE0MDAwWjCCAlExGDAWBggqhQMDgQ0BARIKMDAwMDAwMDAxMjEaMBgGCCqFAwOBAwEBEgwwMDY2OTkwMDAwMDAxIDAeBgkqhkiG9w0BCQEWEWthdHNAc2tia29udHVyLnJ1MQswCQYDVQQGEwJSVTEzMDEGA1UECAwqNjYg0KHQstC10YDQtNC70L7QstGB0LrQsNGPINC+0LHQu9Cw0YHRgtGMMSEwHwYDVQQHDBjQldC60LDRgtC10YDQuNC90LHRg9GA0LMxKDAmBgNVBAoMH9CX0JDQniDQn9CkINCh0JrQkSDQmtC+0L3RgtGD0YAxGzAZBgNVBAsMEtCU0J/Qny4g0KPQoC4g0J7QoDEtMCsGA1UEAwwk0JrQsNGGINCe0LvQtdCzINCV0LLQs9C10L3RjNC10LLQuNGHMTAwLgYJKoZIhvcNAQkCDCE2Njk5MDAwMDAwLTY2OTkwMTAwMS0wNjUwNDEyMzQ1NTIxVTBTBgNVBAwMTNCe0L/QtdGA0LDRgtC+0YAg0K3QktCcINGBINC90LDQstGL0LrQsNC80Lgg0L/RgNC+0LPRgNCw0LzQvNC40YDQvtCy0LDQvdC40Y8xDzANBgNVBAQMBtCa0LDRhjEmMCQGA1UEKgwd0J7Qu9C10LMg0JXQstCz0LXQvdGM0LXQstC40YcxKDAmBgNVBAkMH9GD0LsuINCd0L7QstCw0Y8sINC0LjIsINC60LIuMzExGDAWBgUqhQNkARINNDc5OTYwMTI0NzY0MDEWMBQGBSqFA2QDEgs2NTA0MTIzNDU1MjBjMBwGBiqFAwICEzASBgcqhQMCAiQABgcqhQMCAh4BA0MABEBi+gUpHga2hULQ3eySF4B2/J6O24anFT6LPCLZEnRCw3eAr3m2Yu7iDxNOMxl+eMuth7bvr1tajeKntZ4ADB/Co4IFBjCCBQIwDgYDVR0PAQH/BAQDAgTwMBMGA1UdIAQMMAowCAYGKoUDZHEBMDcGA1UdJQQwMC4GCCsGAQUFBwMCBgcqhQMCAiIGBgcqhQMDBwgBBggqhQMDBwEBAQYGKoUDAwcBMDsGA1UdEQQ0MDKgMAYJKoUDAwcBAQEBoCMMITY2OTkwMDAwMDAtNjY5OTAxMDAxLTA2NTA0MTIzNDU1MjAdBgNVHQ4EFgQUBpmk9MwOmAPrdOHpsPe8zp86uDcwggGcBgNVHSMEggGTMIIBj4AUwpQH565Pv7nAWWiEiNAsfvAtQHOhggFjpIIBXzCCAVsxGDAWBgUqhQNkARINMDAwMDAwMDAwMDAwMDEaMBgGCCqFAwOBAwEBEgwwMDAwMDAwMDAwMDAxJDAiBgNVBAkMG9Cj0LvRjNGP0L3QvtCy0YHQutCw0Y8gMTPQsDEeMBwGCSqGSIb3DQEJARYPY2FAc2tia29udHVyLnJ1MQswCQYDVQQGEwJSVTEzMDEGA1UECAwqNjYg0KHQstC10YDQtNC70L7QstGB0LrQsNGPINC+0LHQu9Cw0YHRgtGMMSEwHwYDVQQHDBjQldC60LDRgtC10YDQuNC90LHRg9GA0LMxKDAmBgNVBAoMH9CX0JDQniDQn9CkINCh0JrQkSDQmtC+0L3RgtGD0YAxMDAuBgNVBAsMJ9Cj0LTQvtGB0YLQvtCy0LXRgNGP0Y7RidC40Lkg0YbQtdC90YLRgDEcMBoGA1UEAxMTVUMgVGVzdCAoUXVhbGlmaWVkKYIQVJ4AlkGFxItA0uUhz9irCTByBgNVHR8EazBpMDKgMKAuhixodHRwOi8vY2RwLnNrYmtvbnR1ci5ydS9jZHAvdWMtdGVzdC02M2Z6LmNybDAzoDGgL4YtaHR0cDovL2NkcDIuc2tia29udHVyLnJ1L2NkcC91Yy10ZXN0LTYzZnouY3JsMIGXBggrBgEFBQcBAQSBijCBhzBBBggrBgEFBQcwAoY1aHR0cDovL2NkcC5za2Jrb250dXIucnUvY2VydGlmaWNhdGVzL3VjLXRlc3QtNjNmei5jcnQwQgYIKwYBBQUHMAKGNmh0dHA6Ly9jZHAyLnNrYmtvbnR1ci5ydS9jZXJ0aWZpY2F0ZXMvdWMtdGVzdC02M2Z6LmNydDArBgNVHRAEJDAigA8yMDE2MDQwNzExMzEwMFqBDzIwMjEwNDA3MTEzMTAwWjA2BgUqhQNkbwQtDCsi0JrRgNC40L/RgtC+0J/RgNC+IENTUCIgKNCy0LXRgNGB0LjRjyAzLjYpMIIBMQYFKoUDZHAEggEmMIIBIgwrItCa0YDQuNC/0YLQvtCf0YDQviBDU1AiICjQstC10YDRgdC40Y8gMy42KQxTItCj0LTQvtGB0YLQvtCy0LXRgNGP0Y7RidC40Lkg0YbQtdC90YLRgCAi0JrRgNC40L/RgtC+0J/RgNC+INCj0KYiINCy0LXRgNGB0LjQuCAxLjUMTkPQtdGA0YLQuNGE0LjQutCw0YIg0YHQvtC+0YLQstC10YLRgdGC0LLQuNGPIOKEliDQodCkLzEyMS0xODU5INC+0YIgMTcuMDYuMjAxMgxOQ9C10YDRgtC40YTQuNC60LDRgiDRgdC+0L7RgtCy0LXRgtGB0YLQstC40Y8g4oSWINCh0KQvMTI4LTE4MjIg0L7RgiAwMS4wNi4yMDEyMAgGBiqFAwICAwNBAEorSWc+XdBeFxfLgFSYHKYJbjsQKVBP1EThYcbfZh5jfxnR0yTP4P+NEgbidg0J3ys2wLnN5w95HmypClvBBmk=</X509Certificate></X509Data></KeyInfo></Signature></Root>


Код:
<?xml version="1.0" encoding="utf-8"?><Root v="2" a="1"><Value>part1&#xD;part2</Value><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001-gostr3411" /><Reference URI=""><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></Transforms><DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411" /><DigestValue>cxuyd7P51Wm1YstYM4EOoBXSWOMl+hOSewq0g+/hoZc=</DigestValue></Reference></SignedInfo><SignatureValue>plZmM+wSeY0OcqSCI7gK+pyoNVGYRoi0MWhspWhFXyLXHTH0+5pRjCksxhtA0yhT1V7g0AsT9NcYMBKaVlKDWg==</SignatureValue><KeyInfo><X509Data><X509Certificate>MIIJrzCCCV6gAwIBAgIKa0sArwAAAAOsaDAIBgYqhQMCAgMwggFbMRgwFgYFKoUDZAESDTAwMDAwMDAwMDAwMDAxGjAYBggqhQMDgQMBARIMMDAwMDAwMDAwMDAwMSQwIgYDVQQJDBvQo9C70YzRj9C90L7QstGB0LrQsNGPIDEz0LAxHjAcBgkqhkiG9w0BCQEWD2NhQHNrYmtvbnR1ci5ydTELMAkGA1UEBhMCUlUxMzAxBgNVBAgMKjY2INCh0LLQtdGA0LTQu9C+0LLRgdC60LDRjyDQvtCx0LvQsNGB0YLRjDEhMB8GA1UEBwwY0JXQutCw0YLQtdGA0LjQvdCx0YPRgNCzMSgwJgYDVQQKDB/Ql9CQ0J4g0J/QpCDQodCa0JEg0JrQvtC90YLRg9GAMTAwLgYDVQQLDCfQo9C00L7RgdGC0L7QstC10YDRj9GO0YnQuNC5INGG0LXQvdGC0YAxHDAaBgNVBAMTE1VDIFRlc3QgKFF1YWxpZmllZCkwHhcNMTYwNDA3MTEzMTAwWhcNMjEwNDA3MTE0MDAwWjCCAlExGDAWBggqhQMDgQ0BARIKMDAwMDAwMDAxMjEaMBgGCCqFAwOBAwEBEgwwMDY2OTkwMDAwMDAxIDAeBgkqhkiG9w0BCQEWEWthdHNAc2tia29udHVyLnJ1MQswCQYDVQQGEwJSVTEzMDEGA1UECAwqNjYg0KHQstC10YDQtNC70L7QstGB0LrQsNGPINC+0LHQu9Cw0YHRgtGMMSEwHwYDVQQHDBjQldC60LDRgtC10YDQuNC90LHRg9GA0LMxKDAmBgNVBAoMH9CX0JDQniDQn9CkINCh0JrQkSDQmtC+0L3RgtGD0YAxGzAZBgNVBAsMEtCU0J/Qny4g0KPQoC4g0J7QoDEtMCsGA1UEAwwk0JrQsNGGINCe0LvQtdCzINCV0LLQs9C10L3RjNC10LLQuNGHMTAwLgYJKoZIhvcNAQkCDCE2Njk5MDAwMDAwLTY2OTkwMTAwMS0wNjUwNDEyMzQ1NTIxVTBTBgNVBAwMTNCe0L/QtdGA0LDRgtC+0YAg0K3QktCcINGBINC90LDQstGL0LrQsNC80Lgg0L/RgNC+0LPRgNCw0LzQvNC40YDQvtCy0LDQvdC40Y8xDzANBgNVBAQMBtCa0LDRhjEmMCQGA1UEKgwd0J7Qu9C10LMg0JXQstCz0LXQvdGM0LXQstC40YcxKDAmBgNVBAkMH9GD0LsuINCd0L7QstCw0Y8sINC0LjIsINC60LIuMzExGDAWBgUqhQNkARINNDc5OTYwMTI0NzY0MDEWMBQGBSqFA2QDEgs2NTA0MTIzNDU1MjBjMBwGBiqFAwICEzASBgcqhQMCAiQABgcqhQMCAh4BA0MABEBi+gUpHga2hULQ3eySF4B2/J6O24anFT6LPCLZEnRCw3eAr3m2Yu7iDxNOMxl+eMuth7bvr1tajeKntZ4ADB/Co4IFBjCCBQIwDgYDVR0PAQH/BAQDAgTwMBMGA1UdIAQMMAowCAYGKoUDZHEBMDcGA1UdJQQwMC4GCCsGAQUFBwMCBgcqhQMCAiIGBgcqhQMDBwgBBggqhQMDBwEBAQYGKoUDAwcBMDsGA1UdEQQ0MDKgMAYJKoUDAwcBAQEBoCMMITY2OTkwMDAwMDAtNjY5OTAxMDAxLTA2NTA0MTIzNDU1MjAdBgNVHQ4EFgQUBpmk9MwOmAPrdOHpsPe8zp86uDcwggGcBgNVHSMEggGTMIIBj4AUwpQH565Pv7nAWWiEiNAsfvAtQHOhggFjpIIBXzCCAVsxGDAWBgUqhQNkARINMDAwMDAwMDAwMDAwMDEaMBgGCCqFAwOBAwEBEgwwMDAwMDAwMDAwMDAxJDAiBgNVBAkMG9Cj0LvRjNGP0L3QvtCy0YHQutCw0Y8gMTPQsDEeMBwGCSqGSIb3DQEJARYPY2FAc2tia29udHVyLnJ1MQswCQYDVQQGEwJSVTEzMDEGA1UECAwqNjYg0KHQstC10YDQtNC70L7QstGB0LrQsNGPINC+0LHQu9Cw0YHRgtGMMSEwHwYDVQQHDBjQldC60LDRgtC10YDQuNC90LHRg9GA0LMxKDAmBgNVBAoMH9CX0JDQniDQn9CkINCh0JrQkSDQmtC+0L3RgtGD0YAxMDAuBgNVBAsMJ9Cj0LTQvtGB0YLQvtCy0LXRgNGP0Y7RidC40Lkg0YbQtdC90YLRgDEcMBoGA1UEAxMTVUMgVGVzdCAoUXVhbGlmaWVkKYIQVJ4AlkGFxItA0uUhz9irCTByBgNVHR8EazBpMDKgMKAuhixodHRwOi8vY2RwLnNrYmtvbnR1ci5ydS9jZHAvdWMtdGVzdC02M2Z6LmNybDAzoDGgL4YtaHR0cDovL2NkcDIuc2tia29udHVyLnJ1L2NkcC91Yy10ZXN0LTYzZnouY3JsMIGXBggrBgEFBQcBAQSBijCBhzBBBggrBgEFBQcwAoY1aHR0cDovL2NkcC5za2Jrb250dXIucnUvY2VydGlmaWNhdGVzL3VjLXRlc3QtNjNmei5jcnQwQgYIKwYBBQUHMAKGNmh0dHA6Ly9jZHAyLnNrYmtvbnR1ci5ydS9jZXJ0aWZpY2F0ZXMvdWMtdGVzdC02M2Z6LmNydDArBgNVHRAEJDAigA8yMDE2MDQwNzExMzEwMFqBDzIwMjEwNDA3MTEzMTAwWjA2BgUqhQNkbwQtDCsi0JrRgNC40L/RgtC+0J/RgNC+IENTUCIgKNCy0LXRgNGB0LjRjyAzLjYpMIIBMQYFKoUDZHAEggEmMIIBIgwrItCa0YDQuNC/0YLQvtCf0YDQviBDU1AiICjQstC10YDRgdC40Y8gMy42KQxTItCj0LTQvtGB0YLQvtCy0LXRgNGP0Y7RidC40Lkg0YbQtdC90YLRgCAi0JrRgNC40L/RgtC+0J/RgNC+INCj0KYiINCy0LXRgNGB0LjQuCAxLjUMTkPQtdGA0YLQuNGE0LjQutCw0YIg0YHQvtC+0YLQstC10YLRgdGC0LLQuNGPIOKEliDQodCkLzEyMS0xODU5INC+0YIgMTcuMDYuMjAxMgxOQ9C10YDRgtC40YTQuNC60LDRgiDRgdC+0L7RgtCy0LXRgtGB0YLQstC40Y8g4oSWINCh0KQvMTI4LTE4MjIg0L7RgiAwMS4wNi4yMDEyMAgGBiqFAwICAwNBAEorSWc+XdBeFxfLgFSYHKYJbjsQKVBP1EThYcbfZh5jfxnR0yTP4P+NEgbidg0J3ys2wLnN5w95HmypClvBBmk=</X509Certificate></X509Data></KeyInfo></Signature></Root>


P.S. То, что они все не проходят по достоверности издателю корневого сертификата — это понятно и неинтересно — вопрос про математику.
Offline Степан З  
#2 Оставлено : 2 августа 2018 г. 5:01:58(UTC)
Степан З

Статус: Новичок

Группы: Участники
Зарегистрирован: 31.07.2018(UTC)
Сообщений: 9
Российская Федерация
Откуда: Екб

Примеры файлов из предыдущего сообщения:

Файл без перевода каретки plane.xml (5kb) загружен 1 раз(а). Подпись математически корректна.
Файл с одним символом '\r' cr.xml (5kb) загружен 1 раз(а). Подпись не проходит математику.
Файл с экранированным символом escapedCr.xml (5kb) загружен 1 раз(а). Подпись опять-таки не проходит математику.
Offline khomenko  
#3 Оставлено : 7 августа 2018 г. 7:32:31(UTC)
Михаил Хоменко

Статус: Активный участник

Группы: Администраторы, Участники
Зарегистрирован: 28.04.2010(UTC)
Сообщений: 128
Мужчина
Откуда: Крипто-Про

Поблагодарили: 11 раз в 10 постах
Добрый день,

На стороне сервера используются трансформы реализованные в .NET.


На вашей стороне средствами .NET (SignedXml) подписи проходят проверку?
Offline Степан З  
#4 Оставлено : 8 августа 2018 г. 5:15:56(UTC)
Степан З

Статус: Новичок

Группы: Участники
Зарегистрирован: 31.07.2018(UTC)
Сообщений: 9
Российская Федерация
Откуда: Екб

Точно такое же поведение:
Для файла без возврата каретки все норм, для файла с ней — не проходит.
Что я делаю не так?
Offline khomenko  
#5 Оставлено : 13 августа 2018 г. 16:28:54(UTC)
Михаил Хоменко

Статус: Активный участник

Группы: Администраторы, Участники
Зарегистрирован: 28.04.2010(UTC)
Сообщений: 128
Мужчина
Откуда: Крипто-Про

Поблагодарили: 11 раз в 10 постах
Можно собственно увидеть полный код того, что выделаете?
Offline Степан З  
#6 Оставлено : 17 августа 2018 г. 15:56:27(UTC)
Степан З

Статус: Новичок

Группы: Участники
Зарегистрирован: 31.07.2018(UTC)
Сообщений: 9
Российская Федерация
Откуда: Екб

Данные, которые будут подписаны формируем таким образом:
Код:

        public static SignedInfo GenerateSignedInfo(XmlDocument xml)
        {
            var xmlTransform = new XmlDsigExcC14NTransform();
            xmlTransform.LoadInput(xml);
            var canonXmlStream = (MemoryStream)xmlTransform.GetOutput();

            var algorithm = HashAlgorithm.Create("GOST3411");
            var digestValue = algorithm.ComputeHash(canonXmlStream);

            var signedInfo = new SignedInfo
            {
                CanonicalizationMethod = SignedXml.XmlDsigExcC14NTransformUrl,
                SignatureMethod = CPSignedXml.XmlDsigGost3410Url
            };

            var reference = new Reference(string.Empty)
            {
                DigestMethod = DigestMethod,
                DigestValue = digestValue
            };

            reference.AddTransform(new XmlDsigEnvelopedSignatureTransform());
            reference.AddTransform(new XmlDsigExcC14NTransform());
            signedInfo.AddReference(reference);
            return signedInfo;
        }

Далее подписываем и формируем окончательно тэг Signature

На самом деле я уже разобрался кто всю малину портит.
В потрохах .Net есть код, который при проверке в методе SignedXml.CheckSignature() подменяет \r на \n, а \r\n на \n — они это называют нормализацией документа. На самом деле, просто прогоняет документ через XmlTextReader. Зачем? Я не понимаю.
В итоге я формируя digestValue считаю хэш от просто канонизированного документа: <Root a="1" v="2"><Value>part1&#xD;part2</Value></Root>, а ребята из MS прежде чем канонизировать делают сначала нормализацию, которая убирает \r и пересчитывают хэш уже от <Root a="1" v="2"><Value>part1\npart2</Value></Root>. Естественно, математика слетает.

Вот выдержки из исходников .Net:
1. Препроцессинг документа в методе подсчета хэш-кода: https://referencesource....phy/xml/reference.cs,357
2. Нормализация в препроцессинге: https://referencesource....ography/xml/utils.cs,508
3. Там дальше кодина TextReader и самые кишочки в методе чтения текстового узла ParseText: https://referencesource....mlTextReaderImpl.cs,5052

Offline Владимир(theone)  
#7 Оставлено : 22 октября 2018 г. 10:22:16(UTC)
Владимир(theone)

Статус: Новичок

Группы: Участники
Зарегистрирован: 22.10.2018(UTC)
Сообщений: 2
Российская Федерация
Откуда: Самара

Автор: Степан З Перейти к цитате

В потрохах .Net есть код, который при проверке в методе SignedXml.CheckSignature() подменяет \r на \n, а \r\n на \n — они это называют нормализацией документа. На самом деле, просто прогоняет документ через XmlTextReader.


А удалось решить эту проблему?
Offline Степан З  
#8 Оставлено : 22 октября 2018 г. 10:48:43(UTC)
Степан З

Статус: Новичок

Группы: Участники
Зарегистрирован: 31.07.2018(UTC)
Сообщений: 9
Российская Федерация
Откуда: Екб

Автор: Владимир(theone) Перейти к цитате
А удалось решить эту проблему?

Нет, не представляю себе, как это можно решить на этапе проверки подписи. Ведь надо для этого переделать библиотеки MS и/или переписать код всех сторонних сервисов, проверяющих подпись.
Но, понимая в чем суть проблемы, можно перед канонизацией делать точно такой же прогон документа через XmlReader, и только потом остальные преобразования.
Соответственно, можно решить проблему «невалидной подписи» еще на этапе ее формирования.
Offline Владимир(theone)  
#9 Оставлено : 22 октября 2018 г. 12:32:46(UTC)
Владимир(theone)

Статус: Новичок

Группы: Участники
Зарегистрирован: 22.10.2018(UTC)
Сообщений: 2
Российская Федерация
Откуда: Самара

Автор: Степан З Перейти к цитате
подменяет \r на \n, а \r\n на \n — они это называют нормализацией документа.


Выдержка из стандарта канонизации XML:

Line breaks normalized to #xA on input, before parsing

Так что возможно ребята из MS все правильно делают. С другой стороны, почему точно такая же нормализация не произошла при подписании.
Offline Степан З  
#10 Оставлено : 22 октября 2018 г. 13:28:53(UTC)
Степан З

Статус: Новичок

Группы: Участники
Зарегистрирован: 31.07.2018(UTC)
Сообщений: 9
Российская Федерация
Откуда: Екб

Автор: Владимир(theone) Перейти к цитате

Выдержка из стандарта канонизации XML:

Line breaks normalized to #xA on input, before parsing


При этом дальше идут примеры, где они в innerText-е меняют \r на &#xD; и не меняют \n, а наоборот &#xA; меняют на \n! В атрибутах все спецсимволы меняют на последовательность &#..;.
Дотнетовский класс трансформации System.Security.Cryptography.Xml.XmlDsigExcC14NTransform ведет себя именно так, как показано в примерах. Никаких преобразований line breaks to #xA на выходе нет. Но вроде и написано, что до парсинга документа это происходит, а не на выходе после канонизации.
Фишка в том, что процессы нормализации и канонизации — это разные вещи. При формировании подписи я нормализацию не делал, делал только канонизацию, а при проверке классом SignedXml происходит еще и нормализация документа перед канонизацией.
Offline Степан З  
#11 Оставлено : 22 октября 2018 г. 13:39:21(UTC)
Степан З

Статус: Новичок

Группы: Участники
Зарегистрирован: 31.07.2018(UTC)
Сообщений: 9
Российская Федерация
Откуда: Екб

Автор: Степан З Перейти к цитате
Никаких преобразований line breaks to #xA на выходе нет.
Это я про innerText

Offline two_oceans  
#12 Оставлено : 23 октября 2018 г. 3:49:14(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 166
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 11 раз
Поблагодарили: 37 раз в 37 постах
Цитата:
Цитата:
Выдержка из стандарта канонизации XML:
Line breaks normalized to #xA on input, before parsing

При этом дальше идут примеры, где они в innerText-е меняют \r на &#xD; и не меняют \n, а наоборот &#xA; меняют на \n! В атрибутах все спецсимволы меняют на последовательность &#..;.
Я так понимаю, когда в стандарте написано #xA это просто одиночный символ с кодом 10, то что Вы называете \n ведь в цитате не написано перед #xA амперсанда и в конце точки с запятой, как могло быть: &#xA; Таким образом, все правильно последовательность &#xA; меняют на одиночный символ #xA (он же \n) и не меняют \n.
Цитата:
https://www.w3.org/TR/2000/WD-xml-2e-20000814
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).

[E86]To simplify the tasks of applications , an XML processor must normalize line breaks in parsed entities to #xA either by translating the two-character sequence #xD #xA and any #xD that is not followed by #xA to #xA on input before parsing, or by using some other method such that the characters passed to the application are the same as if it did this translation.
То есть по основному стандарту XML процессор должен выполнить замену: \r\n заменяется на \n, "одиночные" \r без непосредственно следующего \n заменяются на \n.
Цитата:
Фишка в том, что процессы нормализации и канонизации — это разные вещи.
Верно, а еще дело в том, что при выборе фрагмента xpath может не выбрать ни одного перевода строки вообще - все в одну строку и по идее именно этот вариант должен передаваться на каноникализацию. А мы выбираем фрагмент для подписи непонятно каким образом и у нас во фрагменте оказываются переводы строк которых вообще в принципе быть не должно во фрагменте.

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

Offline Степан З  
#13 Оставлено : 23 октября 2018 г. 6:45:44(UTC)
Степан З

Статус: Новичок

Группы: Участники
Зарегистрирован: 31.07.2018(UTC)
Сообщений: 9
Российская Федерация
Откуда: Екб

Автор: two_oceans Перейти к цитате
Я так понимаю, когда в стандарте написано #xA это просто одиночный символ с кодом 10

Ну, кстати, да. Я сначала за управляющую последовательность это принял.

Автор: two_oceans Перейти к цитате
по основному стандарту XML процессор должен выполнить замену

Но, видимо, не обязан. И в том же .Net-е разные механизмы (XmlDocument, XmlReader и XmlTextReader) ведут себя по-разному.
А вот при формировании подписи, да, надо обязательно в канонизацию передавать данные из нормализирующей читалки (об этом есть в стандарте XMLDSign пункт 7.1). Я же использовал XmlDocument, а надо было использовать, например, XmlReader.

P.S.
Автор: Степан З Перейти к цитате

В потрохах .Net есть код, который при проверке в методе SignedXml.CheckSignature() подменяет \r на \n, а \r\n на \n — они это называют нормализацией документа. На самом деле, просто прогоняет документ через XmlTextReader. Зачем? Я не понимаю.

Кажется, что тот самый пункт 7.1 отвечает на этот вопрос. Но мне не понятно пока, почему они эту функциональность в XmlDsigExcC14NTransform не втащили...
Offline two_oceans  
#14 Оставлено : 23 октября 2018 г. 8:58:13(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 166
Российская Федерация
Откуда: Иркутская область

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

Offline Степан З  
#15 Оставлено : 23 октября 2018 г. 11:29:37(UTC)
Степан З

Статус: Новичок

Группы: Участники
Зарегистрирован: 31.07.2018(UTC)
Сообщений: 9
Российская Федерация
Откуда: Екб

Автор: two_oceans Перейти к цитате
Вероятно, потому что в оригинале exclusive С14N трансформ хоть и разработан с прицелом на стандарт xmldsig, но все же не является его частью.

Видимо, да. Тогда вопрос к наименованию этого класса. Делает только exclusive С14N transform — называли бы соответственно и без лишних префиксов. Но это, похоже, уже другая история )
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.