Mailing-List: contact dev-help@santuario.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@santuario.apache.org
Received-SPF: pass (athena.apache.org: domain of jesper.nygards@gmail.com
 designates 209.85.223.182 as permitted sender)
MIME-Version: 1.0
Date: Thu, 18 Oct 2012 08:22:22 +0200
Message-ID: 
 <CABZhJg_94S-rdQZstb1Zp6GpgKdupnB+WH9MPBcWOf=rKm5zFg@mail.gmail.com>
Subject: Problem with c14n
From: =?ISO-8859-1?Q?Jesper_Nyg=E5rds?= <jesper.nygards@gmail.com>
To: dev@santuario.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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?