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

["Ahmed, Zahid" <zahid.ahmed@commerceone.com>]

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
    pbaker@verisign.com)
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