I would generalize that question to include the java implementation.
Inconsistent c14n has caused us to have validation failures in the past,
and I have found no decent way to finding out what exactly the
canonicalizer output looks like. I've had to use the debugger and set the
"os" stream to a FileOutputStream in DOMReference.transform(Data,
XMLCryptoContext) so the canonicalizer writes to a file, then I can
compare c14n output on the signer and validator components.
Our application first encrypts then signs xml content, and we were having
issues with failed validation due to inconsistent c14n. We resolved them
by doing two things:
a) setting "org.apache.xml.security.ignoreLineBreaks" system property to
true (a hint to the Base64 encoder not to put line breaks in its output)
on the signer and validator components. It was a requirement of our system
that the output must support having no line-breaks.
b) during encryption, set the following on the KeyInfo
keyInfo.setXPathNamespaceContext("xmlns:ds", XMLCipher.XML_DSIG);
The second one was because the signature wasn't correctly canonicalizing
the KeyInfo with a namespace. I'm not sure I even understand whether/why I
absolutely need that last one (i.e. could have been xalan versioning
issues), but there are at least two things wrong here with xml-sec:
1) The system property forces the same encoding behavior for all
encryption on that VM. This should probably be an input parameter to a
canonicalizer, or injectable in some other way.
2) ... and more importantly, there should probably be some logging for
canonicalizer output such that it can be compared easily between
installations. I didn't see an obvious place in CanonicalizerBase where
this would be allowed. This would go a long way in helping understand why
validation of a message failed.
Thoughts?
Eduardo Mourão <eduardo....@gmail.com>
07/24/2009 11:55 AM
Please respond to
security-dev@xml.apache.org
To
security-dev@xml.apache.org
cc
Subject
Re: Canonicalization Validation
Unfortunely I don't have access to change the .NET signature validator.
I beleive the white spaces are, in fact, the problem. The only solution I
have in mind is make my signature validation act as the .NET validation.
How can I validate the canocalization of this document?
Eduardo Mourão
SEFIN/CRE/GEINF
Fone: (69) 3211-6100 ramal 1054
0800647-4700
On Fri, Jul 24, 2009 at 12:00 PM, Jesse Pelton <j...@pkc.com> wrote:
This sounds a lot like an issue that made me nuts a couple of weeks ago.
By default, the .NET framework's XmlDocument.LoadXml() discards
whitespace. Your partner will need to set XmlDocument.PreserveWhitespace =
true before loading the document.
If they're already doing that, I haven't a clue.
From: Eduardo Mourão [mailto:eduardo....@gmail.com]
Sent: Friday, July 24, 2009 10:50 AM
To: security-dev@xml.apache.org
Subject: Canonicalization Validation
Hi,
I'm having problems with .NET interoperability. My software receives
signed XML documents and validates them, but, when I send to one of our
partners (a .NET solution) it returns that the signature is not valid.
I took a look at those XML files and noticed that all the rejected files
and not properly canonicalized. Still, the signature is valid, but the
KeyInfo node is not what .NET expects:
This is a KeyInfo .NET will consider valid (line feeds in the
certificate):
<KeyInfo><X509Data><X509Certificate>MIIFUTCCBDmgAwIBAgIQRLTcfKrDweBHaHZM0lPUHTANBgkqhkiG9w0BAQUFADBuMQswCQYDVQQG
EwJCUjETMBEGA1UEChMKSUNQLUJyYXNpbDEsMCoGA1UECxMjU2VjcmV0YXJpYSBkYSBSZWNlaXRh
IEZlZGVyYWwgLSBTUkYxHDAaBgNVBAMTE0FDIENlcnRpU2lnbiBTUkYgVjMwHhcNMDcxMDI5MDAw
MDAwWhcNMDgxMDI4MjM1OTU5WjCBvjELMAkGA1UEBhMCQlIxCzAJBgNVBAgTAlJKMRcwFQYDVQQH
FA5SSU8gREUgSkFORUlSTzETMBEGA1UEChQKSUNQLUJyYXNpbDEqMCgGA1UECxQhU2VjcmV0YXJp
YSBkYSBSZWNlaXRhIEZlZGVyYWwtU1JGMRMwEQYDVQQLFApTUkYgZS1DTlBKMTMwMQYDVQQDEypQ
RVRST0JSQVMgRElTVFJJQlVJRE9SQSBTIEE6MzQyNzQyMzMwMDAxMDIwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBANbsRkIQMF5ZgXsv7KqIj13OSsotVxgxlbAS0c7DTPIT0Co3Q5pdwyFccJFy
bQC+PXPUjcClDKkItjTUky7fSekGEjcYH+pzpDx2laEcPtwUR4fivca37Eea3EC4SZv79+A0ydrS
UqSk9vINPcO4scpdypwq/qO9ZXNodYQHU/PNAgMBAAGjggIcMIICGDCBxQYDVR0RBIG9MIG6oD0G
BWBMAQMEoDQEMjExMDQxOTU3MzQ3NTg2NDA2MTAwMDAwMDAwMDAwMDAwMDAwMDAwTTY5OTk0M1NT
UE1HoCcGBWBMAQMCoB4EHEpPU0UgRURVQVJETyBERSBCQVJST1MgRFVUUkGgGQYFYEwBAwOgEAQO
MzQyNzQyMzMwMDAxMDKgFwYFYEwBAwegDgQMMDAwMDAwMDAwMDAwgRxncnBzZWdickBici1wZXRy
b2JyYXMuY29tLmJyMAkGA1UdEwQCMAAwYgYDVR0fBFswWTBXoFWgU4ZRaHR0cDovL2ljcC1icmFz
aWwuY2VydGlzaWduLmNvbS5ici9yZXBvc2l0b3Jpby9sY3IvQUNDZXJ0aVNpZ25TUkZWMy9MYXRl
c3RDUkwuY3JsMB8GA1UdIwQYMBaAFPadWV3+v8Vyzd3OxC5mGy7uCM92MA4GA1UdDwEB/wQEAwIF
4DBVBgNVHSAETjBMMEoGBmBMAQIBDDBAMD4GCCsGAQUFBwIBFjJodHRwOi8vaWNwLWJyYXNpbC5j
ZXJ0aXNpZ24uY29tLmJyL3JlcG9zaXRvcmlvL2RwYzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYB
BQUHAwIwOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcC5jZXJ0aXNpZ24u
Y29tLmJyMA0GCSqGSIb3DQEBBQUAA4IBAQAcxZPM8IGZXBUgL7MhWOt8fcKiKwkUyI93+ItI1FRQ
cRXhjV2d+0BICDPPlj0KEiZbwIjPttV+XHhuAHQf9UWkNh/VJhcAg3z6pA7iJ2qdMZ//YGBywpmq
Ys5wxInJ2ywX4QRiUBhsf2mizAhfw+GAU4stTVhYVlt409lETSwWYNEzuI97BItO0Fn04E6REDNh
xxCqGM4fsKlyMKDvhWUjKJ69DZoId5TXS3N/7Slaa1Gtzb/7OLvd2qS2Aon7TGd8HGS9CjKvUk7H
Ecmmgdc9f76cAzdhyfx+EY+eje3KCmdxsdESzpmImWm/OXD47VKZmjvcdpoxrPVRRUwbqH0M</X509Certificate></X509Data></KeyInfo>
And, this is what .NET says is not valid (no line feeds, the XML is just a
single line):
<KeyInfo><X509Data><X509Certificate>MIIGQzCCBSugAwIBAgIIKawin2Dsz20wDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCQlIxEzARBgNVBAoTCklDUC1CcmFzaWwxKDAmBgNVBAMTH1NFUkFTQSBDZXJ0aWZpY2Fkb3JhIERpZ2l0YWwgdjEwHhcNMDkwMzA5MTUwMDAwWhcNMTAwMzA5MTUwMDAwWjCB/TELMAkGA1UEBhMCQlIxEzARBgNVBAoTCklDUC1CcmFzaWwxFDASBgNVBAsTCyhFTSBCUkFOQ08pMRgwFgYDVQQLEw8wMDAwMDEwMDA1NDI4NjAxFDASBgNVBAsTCyhFTSBCUkFOQ08pMRQwEgYDVQQLEwsoRU0gQlJBTkNPKTEUMBIGA1UECxMLKEVNIEJSQU5DTykxFDASBgNVBAsTCyhFTSBCUkFOQ08pMRQwEgYDVQQLEwsoRU0gQlJBTkNPKTE7MDkGA1UEAxMyRElTVFJJQlVJRE9SQSBFUVVBRE9SIERFIFBST0RVVE9TIERFIFBFVFJPTEVPIExUREEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMrSbsECYkq+Vo8roCdGFP4zN/AKKVa592v/wNxwyCXAldNUXi1g5ctNlWalGF7KOumASIKCfe8gvsQftClaHr67FJ842ZpvfZYF1gAKViPUD6WsEWUtjWVuk8mSZwD0WipoFJY2AsJcj2vDQ7iS1LQ5TPRtXh0iJ3Kuk6zAAGORAgMBAAGjggL5MIIC9TAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB8GA1UdIwQYMBaAFLdgqFv5sqauAO1069VKyZZoZvVcMIG8BgNVHREEgbQwgbGBE0hVTUJFUlRPQERJU0xVQi5DT02gPgYFYEwBAwSgNRMzMjkwODE5NjMzNDEwOTk1MTQ1MzAwMDAwMDAwMDAwMDAwMDAwMDAxODg2ODI1U1NQIFBFoCYGBWBMAQMCoB0TG0hVTUJFUlRPIERPIEFNQVJBTCBDQVJSSUxIT6AZBgVgTAEDA6AQEw4wMzEyODk3OTAwMDE3NqAXBgVgTAEDB6AOEwwwMDAwMDAwMDAwMDAwVwYDVR0gBFAwTjBMBgZgTAECAQYwQjBABggrBgEFBQcCARY0aHR0cDovL3d3dy5jZXJ0aWZpY2Fkb2RpZ2l0YWwuY29tLmJyL3JlcG9zaXRvcmlvL2RwYzCB8AYDVR0fBIHoMIHlMEmgR6BFhkNodHRwOi8vd3d3LmNlcnRpZmljYWRvZGlnaXRhbC5jb20uYnIvcmVwb3NpdG9yaW8vbGNyL3NlcmFzYWNkdjEuY3JsMEOgQaA/hj1odHRwOi8vbGNyLmNlcnRpZmljYWRvcy5jb20uYnIvcmVwb3NpdG9yaW8vbGNyL3NlcmFzYWNkdjEuY3JsMFOgUaBPhk1odHRwOi8vcmVwb3NpdG9yaW8uaWNwYnJhc2lsLmdvdi5ici9sY3IvU2VyYXNhL3JlcG9zaXRvcmlvL2xjci9zZXJhc2FjZHYxLmNybDCBlwYIKwYBBQUHAQEEgYowgYcwPAYIKwYBBQUHMAGGMGh0dHA6Ly9vY3NwLmNlcnRpZmljYWRvZGlnaXRhbC5jb20uYnIvc2VyYXNhY2R2MTBHBggrBgEFBQcwAoY7aHR0cDovL3d3dy5jZXJ0aWZpY2Fkb2RpZ2l0YWwuY29tLmJyL2NhZGVpYXMvc2VyYXNhY2R2MS5wN2IwDQYJKoZIhvcNAQEFBQADggEBAC2HSaaX+BT/vEU1hd9wtubY5gwqvJvS4e0+VidiQY7p5qeJfSkpnI4nXfi7MQHpQ1Ev93yl75KPmAQ0pRXnLM+ULg6ZGbg0pTc7rfk+TohPIojdCVGUADtk2JYdJjd0J1p3v2HYl3wHXewHANI/MHfI57OJ7QRKIjYvL5HOeI+MozHIahqfP5R81w/Os+ekvOFri3p2FuoVOG0rBZxVpsAaOjht//xWvsVVTj6p4VhukCSutQ7ksn3nXg1i76W99+T8XyLs2qmMRctrWLwn8uIN7OMrVH4XvSRpbPztc1iDyNKXP/Ol2UdiTfynQ+OAgUOzKXoHa8EEu6St3SNvGgg=</X509Certificate></X509Data></KeyInfo>
How can I validate the canonicalization of an incoming signed XML file?
Thank you very much,
Eduardo Mourão
CONFIDENTIALITY NOTICE
This e-mail message and any attachments are only for the use of the intended
recipient and may contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended
recipient, any disclosure, distribution or other use of this e-mail message or
attachments is prohibited. If you have received this e-mail message in error,
please delete and notify the sender immediately. Thank you.
