Yes, I am using xmlsec 1.5.2. So, do I understand you correctly that this better be reported to the Apache Santuario project's Issue Tracking?
Jesper On Wed, Oct 17, 2012 at 9:38 PM, Daniel Kulp <[email protected]> wrote: > > This definitely looks like a bug to me. That's likely all the way down in > santuario though. I believe that's where the c14n stuff is done. > > Can you at least double check that the xmlsec jar is 1.5.2? > > Dan > > > > On Oct 17, 2012, at 8:24 AM, Jesper Nygårds <[email protected]> wrote: > >> I am using CXF 2.6.3 >> >> 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? > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
