Hello all, I am using CICS web service as a requestor to communicate with
a datapower device that is expecting a soap message with a digital signature
in the following spec. "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 "
I have gotten the hash correctly as the datapower device accepts the hash,
 but rejects the signature. I'm using a custom header program under CICS
that creates the soap security section via a header program in the pipeline.


 The header program:
                                                      
  1. Checks for SEND-REQUEST function, else returns(exits)
            

  2. Creates a digital signature based on the timestamp information   
     put into the SOAP request.
                                                                     
     a. The digital signasgnddis placed into the request header      
        using the following format:                                  
                                                                     
        <wsu:Timestamp xmlns:wsu=" . . . " wsu:Id=". . . >           
        <wsu:Created>2011-12-05T20:45:00Z</wsu:Created>              
        <wsu:Expires>2011-12-05T20:46:05Z</wsu:Expires>              
        </wsu:Timestamp>                                             
                                                                     
         In the above example, the program has defined a timeframe     
         of 1 minute in length between the <wsu:Created> timestamp    
         and the <wsu:Expires> timestamp..                            
         All timestamps are in 24 hour GMT date/time format which     
         is designated with a Z at the end of the timestamp value   
         (2011-12-05T20:45:30Z).                                      
 
 3. Creates the digital signature using the RSA-SHA256 algorithm.    
                                                                      
      a. The digital signature is generated based on the entire value
         within <wsu:Timestamp> XML element and is placed within      
         another XML element named <SignatureValue>.                  
         The xml-exc-c14n# signature canonicalization method is used.
         The xmlenc#sha256 method is used for creating the digest.    
         The digest is a fancy name for the HASH.

    Prior to creating the hash, I had to write the timestamp information
        to a CICS container. Then I read the information in the container
    back using a CCSID of UTF-8 This was the only way the datapower box would
     accept the hash.                       
                                                                      
                                                                     
 4. Create the HASH(Digest)                                          
    The ICSF CSNBOWH API is called to generate the               
    SHA-256 HASH.
                                                    
    The ICSF CSNDDSG API is called to generate the               
    digital signature using an RSA 2048 bit certificate
    and a rule of PKCS-1.1 which is supposed to be the RSA PKCS V1.5.
    I also prepend SHA256BER  DC  XL19'3031300D060960864801650304020105000420'
    this hex value to the hash prior to calling CSNDDSG.


5.  Then the ICSF CSNDDSV API is called to verify the                
    generated signature.

    All API's  recieve a return code of 0.    
                          
                                                                     
 6. Once the ws-security header is build the program                 
    Puts completed WS-Security header into the                       
    DFHHEADER container.                                             

The soap message generated follows:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" >
<SOAP-ENV:Header>
<wsse:Security SOAP-ENV:mustUnderstand="1"
 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">
<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-855C6D91199BE8A78C14084794806591">
MIIE+jCCA+KgAwIBAgIQ The Public Key goes here and I have removed most of it for brevity and legibility.
</wsse:BinarySecurityToken><ds:Signature Id="SIG-2" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="SOAP-ENV" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#TS-1">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="wsse SOAP-ENV" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>82zM7MUqBrFaHpIxIgePjdOT2FxIYL6r75Mzb29/lqw=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
X5eEwJJHW8oJtgX4zC5E0hMXppqoa6jrx0HjTVupVYwHR3x5qA+b8QKFA5xDB+RltwWMBbC3l8Tb6yUWNMHtaV9zOfLYB+GVbC1iq8qYAG6TsbwNChV
hrAGxEapw6vq8Lp6fzqY6hqTxDvAvTceVpNYNEefFoLpQEUcTkfgNWtHtwy+ktq+9wFokbCK/olOHRUzVT8QdnKtxV1h0tYeXA413fKAk9SMd8qB9ls
Az3yUw3b7yOw6PGxOb7BEYCxQEInAXlzdk9Hyl78Mw2U4IhYYncwKl3483th8S/3BQvLYIjBtQ9JfB4vijN+CTlc+8RUe3d4LGHVFkW9Lpg0+n7Q==
</ds:SignatureValue>
<ds:KeyInfo Id="KI-855C6D91199BE8A78C14084794806742">
<wsse:SecurityTokenReference wsu:Id="STR-855C6D91199BE8A78C14084794806743">
<wsse:Reference URI="#X509-855C6D91199BE8A78C14084794806591" 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 xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 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" wsu:Id="TS-1">
<wsu:Created>2015-10-20T15:31:48Z</wsu:Created>
<wsu:Expires>2015-10-20T15:32:48Z</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<ViewAccountSummary xmlns="http://viewaccountsummary.xx.xxxx.com">
<ViewAccountSummaryParameters xmlns="">
<UserDetails xmlns="http://viewaccountsummary.xx.xxxx.com">
<UserId>9999</UserId>
<AuthorizationId>MIKE</AuthorizationId>
</UserDetails>
<accountNumber xmlns="http://viewaccountsummary.xx.xxxx.com">5593476001701295</accountNumber>
<bankId xmlns="http://viewaccountsummary.xx.xxxx.com">AAAA0209</bankId>
</ViewAccountSummaryParameters>
</ViewAccountSummary>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>                            
 

Any help would be appreciated.

Thank you.

Based on the steps you've outlined, it appears you have successfully computed a valid PKCS 1.5 signature from your hash value (https://tools.ietf.org/html/rfc3447). I suspect it might be a case of passing something different from what the server is expecting. I can't really speak to the SOAP-specific aspects.

Here are a few things you might look into:

1. Ensure you're using the right private key to sign the digest.
2. Ensure the Base64 encoded signature in the SOAP message is consistent with the raw signature returned from DSG.
3. If you have access to a known working implementation talking to that server, check to see if the signature parameters you are passing are consistent with that, in particular the signature method and format of the encoded digest prior to signing.

These are more unlikely to be a problem:

1. PKCS v1.5 defined the signature input as the BER-encoding of DigestInfo rather than the DER-encoding. Since all DER-encodings are valid BER-encodings I would expect that you are fine there since you are passing a DER-encoded string to DSG (https://tools.ietf.org/html/rfc3447#page-43).
2. The DigestInfo parameters for SHA-256 should be omitted but may be null. In your case they are null from the string you prepended to the hash. This is something the server MUST handle though according to the spec (https://tools.ietf.org/html/rfc3447#page-59).
    

   0   49: SEQUENCE {
   2   13:   SEQUENCE {
   4    9:     OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
  15    0:     NULL
         :     }
  17   32:   OCTET STRING
         :     ...
         :     ...
         :   }

To omit the null parameters prepend:

SHA-256 X'302F300B 06096086 48016503 04020104 20' || 32-byte hash value

In the ICSF programmers guide it says:  "For PKCS the message digest and the message-digest algorithm identifier are combined into an ASN.1 value of type DigestInfo, which is BER-encoded to give an octet string D (see Table 186). D is the text string supplied in the hash variable.".

Is the ASN.1 the hash prepended with the BER value of X'3031300D060960864801650304020105000420' ?

If this is the case then the length I supply to the CSNDDSG API for the hash is the (hash + BER) which dec 51. Correct? 19 + 32 = 51

Correct on all fronts.

It appeares that the signature generated by ICSF is not compatable with the Algorithm=http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

I can generate a digestinfo that is correct and the datapower device accepts it. When I use CSNDDSG to generate the signature the datapower box does not accept it as a valid signature. Using the distributed soapui utility works correctly. I have verified that the certificate the zbox uses is the correct one. I have verified as much as possible the use of the ICSF API's My conclusion is that the ICSF API's are not compatible with the Algorithm=http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 . To bad, it would have been nice to code the web services on the mainframe rather than turning over to the windows distributed environment. They seem to be able to generate the signature without problems.

Here is the Rexx exec. If you have any further questions feel free to post them.

Thanks. I have a question. In the ICSF application programmers guide for CSNDDSG, it talks about the signature field

"

signature_field

Direction: Output Type: String

The digital signature generated is returned in this field. The digital signature is

in the low-order bits (right-justified) of a string whose length is the minimum

number of bytes that can contain the digital signature. This string is left-justified

within the signature_field. Any unused bytes to the right are undefined."

What does it mean by low-order bits (right Justified)? I thought the signed signature left justified was in the signature field. Can you please shed some light.

Thanks

That statement means that the signature is:

1. left-justified in signature_field
2. may contain high-order bits which are not part of the signature depending on signature_bit_length

For the "PKCS-1.1" rule, the signature is the same length as the modulus so (2) will come into play when the modulus bit length is not a byte multiple eg. (2049 bits). As an example, if signature_bit_length is 2049, signature_field_length would be 257 (just enough bytes to hold 2049 bits). The signature would be in the first 257 bytes of signature_field. The first 7 bits of the 257 bytes would not be part of the signature. The signature would be in the remaining 2049 bits (2049 + 7 = 257 bytes) i.e. low-order bits right justified.

Thanks for the reply after I do the dig signature the bit length returned to me was hex 800, that would be decimal 2048. I guess I don't have to worry about the signature. Oh, I also copied the rexx exec to the z/os V1.13 system where ICSF is installed. I ran it under TSO, but received the following error:

7E0 (2016) The rule_array parameter contents are incorrect. One or more of the rules specified are not

valid for this service OR some of the rules specified together may not be combined.

User action: Refer to the rule_array parameter described in this publication under the

appropriate callable service for the correct value.

I'm looking into it.

Looks like my version of ICSF does not support the "rsa-aesm" rule array keyword.

I looked at RFC4051 and it appears that the algorithm is supposed to be PKCS#1 V1_5, I noticed in your previous post you used PKCS#11 V1_5 I don't know if that's the same as PKCS#1 V1_5.Either way, I believe I'm generating a valid signature. I use CSNDDSV API to verify it and it passes verification. The hash is good, datapower says so. The signature is not, I have to believe that the z12 z/os crypto is not compatible with what the distributed systems use for internet algorithms. RFC 4051              Additional XML Security URIs            April 2005   This prefix is included to facilitate the use of standard   cryptographic libraries.  The FF octet MUST be repeated enough times   that the value of the quantity being CRYPTed is exactly one octet   shorter than the RSA modulus.   Due to increases in computer processor power and advances in   cryptography, use of RSA-MD5 is NOT RECOMMENDED.2.3.2.  RSA-SHA256   Identifier:     http://www.w3.org/2001/04/xmldsig-more#rsa-sha256   This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described   in section 2.3.1, but with the ASN.1 BER SHA-256 algorithm designator   prefix.  An example of use is:   <SignatureMethod      Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />

That's a typo on my part. I suppose I'm used to writing PKCS #11 so often that I did so unconsciously. I am talking about PKCS #1.

You must be running ICSF HCR7790 (Web Deliverable #11) or earlier. I've attached a version of dsgkat.rexx which creates an RSA CRT key. This should work for you.

Assuming that ICSF is generating the right signature according to spec, I'm hoping to determine what signature the server is expecting to see if there is a way to generate it on z/OS.

Thanks, and it's close. We have HCR7780

I tested this out for myself. There is a set of known answer tests (or test vectors) on NIST's website (linked below) for the PKCS#11 v1.5 RSA SHA-256 signature scheme. I believe this is the scheme you intend to use from the information you've provided. I tried one of their tests and the output from CSNDDSG matches the expected signature. Therefore I suspect something else is amiss. I can post the Rexx exec with the test if you like.

Is it possible to run one of NIST's test vectors through the soapui utility? If you get  a different signature then I would say it is not using the PKCS #11 v1.5 RSA SHA-256 signature scheme. At that point you may engage the SOAP folks to determine what exactly it is using.

http://csrc.nist.gov/groups/STM/cavp/

If you could post the rexx exec that would be great. I will see what I can do with the nist vectors and soapui. I believe it is the PKCS V1.15 RSA SHA256 algorithm that is being used unles I'm interpreting Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 this algorithm incorrectly. Thank you for being so kind as to help. I really appreciate it. :)

Hi Mike,

We're taking a look!

Thanks.

The area that concerns me most is: <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> This method tells the datapower box that I am using the PKCS V1.5 signature method, The below digest method works fine and is accepted by the datapower box as a valid digest.

<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

The soapfault I get back from the datapower device is: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>7830992:1350697713</faultstring></soap:Fault></soap:Body></soap:Envelope>

The datapower guy says it's failing at signature verification.