I am using CXF 1.6.3 and xmlsec 1.5.2. I posted the following question on the CXF user list and the answer indicated that this could have to do with Santuario.
I am developing a web service client/server, using WS-Security and SSEK, which is a Swedish specification adding some security related information to the message. In our solution, three parts of our client request are supposed to be signed: the timestamp, our SSEK header, and the body. The organization we're communicating with was reporting that the digest of our SSEK header was not correct. This is what our request looked like (formatted for readability and somewhat edited): <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://schema.forsakringskassan.se/tjanstepensionsbolag/1"> <soapenv:Header> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soapenv:mustUnderstand="1"> <wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="X509-643E9C889F7DEEDB6613503933329164">YgXlw+8H3q5O2dvinH7FSY=</wsse:BinarySecurityToken> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="SIG-8"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ns soapenv"/> </ds:CanonicalizationMethod> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#TS-5"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse ns soapenv"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>S+Xd8ANIW02EhOYJYWlKDrWQhgg=</ds:DigestValue> </ds:Reference> <ds:Reference URI="#id-6"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ns"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>BvQw2HBJxbYLaaqI4NLQJxwQFJ8=</ds:DigestValue> </ds:Reference> <ds:Reference URI="#id-7"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ns"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>Djj+z3X+hd3h5cZkePdkIZZg0Zs=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>Qp89XS2pWW8MGLv9w8ZXsXXGJAfkSd1J335qpnYOKdimwXv6dmFWm2UqukKfI/nff+JCuUPLHkraTXEhfNrDzjXoZ4YgOYF11zpsjIW3SLulQWjuzT4Z94FKsV7g6/L7V+K0JcqxU+NvQ9kJrQOG9W6SdlyPH4AIUaz484zifhk=</ds:SignatureValue> <ds:KeyInfo Id="KI-643E9C889F7DEEDB6613503933329175"> <wsse:SecurityTokenReference wsu:Id="STR-643E9C889F7DEEDB6613503933329176"> <wsse:Reference URI="#X509-643E9C889F7DEEDB6613503933329164" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> <wsu:Timestamp wsu:Id="TS-5"><wsu:Created>2012-10-16T13:15:32.916Z</wsu:Created><wsu:Expires>2012-10-16T16:15:32.916Z</wsu:Expires></wsu:Timestamp> </wsse:Security> <ssek:SSEK xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soapenv:mustUnderstand="1" wsu:Id="id-7" xmlns:ssek="http://schemas.ssek.org/ssek/2006-05-10/"><ssek:SenderId Type="CN">SENDER</ssek:SenderId><ssek:ReceiverId Type="CN">RECEIVER</ssek:ReceiverId><ssek:TxId>1</ssek:TxId></ssek:SSEK> </soapenv:Header> <soapenv:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="id-6"> <ns:STPFragaSvar> <ns:svar> <ns:grunduppgifter> <ns:id>1</ns:id> <ns:pnr>197011101234</ns:pnr> </ns:grunduppgifter> <ns:uppgiftKanEjLamnas/> </ns:svar> </ns:STPFragaSvar> </soapenv:Body> </soapenv:Envelope> After quite a few hours of debugging, I found out that after the requested Exclusive Canonicalization, CXF (and its underlying components) creates the following canonicalized SSEK header, that it then makes a digest of: <ssek:SSEK xmlns:ns="http://schema.forsakringskassan.se/tjanstepensionsbolag/1" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="id-83" soapenv:mustUnderstand="1"><ssek:SenderId Type="CN">SENDER</ssek:SenderId><ssek:ReceiverId Type="CN">RECEIVER</ssek:ReceiverId><ssek:TxId>1</ssek:TxId></ssek:SSEK> Notice how the ns namespace declaration has been added (which is correct, since it is on the list of InclusiveNamespaces), as well as the soapenv namespace declaration (which is also correct, since an attribute uses it), but the ssek namespace declaration has disappeared. This was causing our problem with an incorrect digest, and I must say it does look incorrect to me. Surely the ssek namespace declaration should be included, as it is used in the element? Is this a known problem with the c14n code, or have I misunderstood something?
