[wss] WSS Issue#1: Support for carrying PKCS7 Encryption Payloads inSO AP Message

Title: WSS Issue#1: Support for carrying PKCS7 Encryption Payloads in SOAP Message

Following up on Issue #1 in latest WSS Issues List at:

http://lists.oasis-open.org/archives/wss/200210/msg00039.html

where we capture the issue of supporting alternative mechanism of signature and 

encryption other than XML DSIG and XML Encryption, included here is specific 

problem description and possible options for supporting PKCS7 encrypted payloads 

in SOAP messages.

Parts of the following discussion could be extended for PKCS7 Signatures also. 

However, our primary interests here is standardized support for PKCS7 encryption 

in SOAP messages using WSS extension.

I have on purpose discarded from the discussion below some obvious steps

such as access to public encryption certificate, decryption key, etc.

Problem Scope

SOAP messages need a standardized way to support carrying and processing of PKCS7 

encrypted payloads that may originate from legacy applications and that may be exposed externally 

using EAI-oriented web services solutions. The encrypted payload is generated by the EAI/legacy 

application using PKCS7 Enveloped Data. Alternatively, it may be the case that a SOAP node, 

acting as gateway between the legacy application and external system, may directly apply 

PKCS7 encryption at SOAP message creation/transmision time. 

 

Use Case: EAI/Legacy application sends PKCS7 Content over SOAP 

1. The legacy applications passes the required PKCS7 encrypted content to the sending 

    SOAP node.

2. The SOAP node carries PKCS7 encrypted payload as a SOAP secondary part, e.g., 

    MIME attachment.

3. The intermediary SOAP nodes in SOAP message path do not process PKCS7 

    encrypted payloads in SOAP message.

4. The target SOAP node extracts the required PKCS7 encrypted content and passes

    it to the legacy application.

5. Legacy application decrypts the PKCS7 encrypted content using its decryption key.

Solutions

There are two options that may be considered to support the carrying of PKCS7 encrypted 

contents in SOAP security extensions: 

1. Employ W3C XML Encryption constructs to carry PKCS7 encrypted content (suggested by 

    )

2. Create PKCS7 encrypted element to be carried within SOAP wsse:security header extension 

    element

Option#1: W3C XML Encryption Support for PKCS7 encryption

It may be possible to duplicate PKCS7 encrypted key (i.e., the bytes of the RSA-encrypted session key)

in XML ENC encrypted key such that we define a custom transform (and/or keyInfo's) that extracts the 

ciphertext content of the PKCS7 encrypted data. The transform would be from a PKCS#7 encrypted 

data object, or the ciphertext within it (if you choose to extract it) to XMLENC-format ciphertext. 

However, XMLENC does not use PKCS#1 padding; it uses 'xmlenc' padding. Transformation of the 

ciphertext is required. Alternatively, we can manually convert the data when it is extracted from the p7, 

and then insert it into an EncryptedData structure, in which case no transform would be required. 

For example, 

<EncryptedData>

     <EncryptionMethod ...>

     <KeyInfo>

             <RetrievalMethod URI="encrypted-data.p7" Type="urn:pkcs7:encrypted-key" />

OR

             <EncryptedKey>

                 ... algorithms and ciphertext extracted from p7 ...

            </EncryptedKey>

      </KeyInfo>

      <CipherData>

        <CipherReference URI="encrypted-data.p7">

            <Transforms>

               <Transforms Algorithm="urn:pkcs7:encrypted-payload" />

            </Transforms>

        </CipherReference>

     </CipherData>

</EncryptedData> 

However, realistically, the above approach is not really useful in terms of interoperability

since there is no useful cross-over between PKCS7 encrypted content and W3C XML ENC.

Note: Option#1 approach can not be extended to support PKCS7 signed data conversions

to W3C XML Signature. However, in this e-mail we are restricting discussion to encryption

only.

Option#2: Adding PKCS7Encrypted Element in WSSE/SOAP Security Extension

We can define a PKCS7 encrypted content type such that zero or more instances of it

may be carried in SOAP security header extension. The <pkcs7EncryptedContent> 

element will only be processed by the SOAP sending application and by the target

SOAP receiving application. The <pkcs7EncryptedContent> will not be processed

by a SOAP intermediary node.

The schema subset for such an extension is:

<xsd:element name="pkcs7EncryptedContent">

      <xsd:complexType>

        <xsd:annotation>

              <xsd:documentation>

                     This element may be used to specify the reference to PKCS7 encrypted data, i.e.,

                      (i.e., EnvelopedData content type), is carried in SOAP secondary part, e.g., MIME 

                      attachment. 

                  </xsd:documentation>

             </xsd:annotation>

         <xsd:attribute name="encryptionAttachmentURI" type="xsd:anyURI"/>

         <xsd:attribute name="symmetricEncyptionAlgorithm" type="xsd:string"/>

      </xsd:complexType>

</xsd:element>

 

<xsd:element ref="wsse:pkcs7EncryptedContent" minOccurs="0" maxOccurs="unbounded">

    <xsd:annotation>

                <xsd:documentation>

                            The pkcs7EncryptedContent element provides a reference to

                             PKCS7-based encrypted content carried in SOAP message payloads.

                 </xsd:documentation>

    </xsd:annotation>

</xsd:element>

Analysis of Options

Option#1 seems like a bad option due to limited cross-over between PKCS7 encryption

and W3C XML ENC Specs. Furthermore, using XML ENC is the carrier for PKCS7 encrypted

data would imply usage of data and key encryption algorithms that are mutually supported

by PKCS#7 and W3C XML ENC. Furthermore, option#1 assumes that transformation of

ciphertext between the different ciphertext padding schemes is possible which is a

problem if algorithms used/supported in XML ENC and PKCS#7 diverge. This implies

that Option#1 could theoratically be supported only for a subset of all algorithms. 

Option#2 does not require any transformaiton between PKCS7 encrypted data and W3C

XML ENC. Option#2 also allows end user web services application to use freely all

supported encryption algorithms within PKCS#7. Option#2 is also consistent with

WSS Core specification, Section 1.1.1 that states that web services security must

support a variety of encryption technologies. 

Possible Resolution

1. Refine Option# 1 for inclusion in WSS v. 1.0.

2. Refine Option #2 for inclusion in WSS v. 1.0

3. Postpone support for PKCS7 encryption in WSS

thanks,

Zahid Ahmed