Re: [wss] WSS Issue#1: Support for carrying PKCS7 Encryption Payloadsin SOAP Message

["Phillip H. Griffin" <phil.griffin@asn-1.com>]

               Zahid,
  
  There is another more simple option that you omitted.  And I think that
it should 
 be considered. It is simply to do what we're doing in XCBF :  Use the ASN.1 
 schema for PKCS #7 types such as SignedData and EncryptedData.  In XCBF
 we embed these in wrappers encoded as XML markup and we only use XML
 markup in our cryptographic processing.  But we rely on the ASN.1 schema
for
 XML markup defined in X9.84:2002.
 
 In the revised X9.84:2002, which now includes XCBF signature and encryption
 processing for XML markup, both DER (binary) and XER (markup) of these
 PKCS #7 values are supported. The descriptions of cryptographic processing 
 in these two cases is almost identical.  The differences are found in describing 
the
 likes of "ContentInfo" for DER content and "<ContentInfo>"
for XER.
 
 The US national standard X9.84 Biometric Information Management and Security
 was listed as a primary input for a new work item proposing an international 
security
 standard introduced into the ISO/IEC JTC1/SC27 Security Techniques group 
last
 week.  X9.84 is a NIST CBEFF "patron format" which appears in the requirements
 documents for much of the biometrics activity in the US, including DOD,
GSA and
 Treasury.  And X9.84 will be the basis for a proposed NWI into the SC2 security
 group in ISO TC68 Financial Services later this year.
 
 A complete XML only version of CMS is being progressed in X9, X9.96 XML
 Cryptographic Message Syntax (XCMS). This work should be completed by end
 of first quarter next year. It will adopt the same XML cryptographic processing
 defined in XCBF, though X9.96 will extend these descriptions to the more 
general
 CMS cases. And the XML markup used in X9.96 will be the same tags that are
 specified in XCBF and X9.84.
 
 None of these works require W3C schema, namespaces, canonicalization, XPath,
 XPointer, etc. All of these works completely support legacy deployments
and 
 provide users of these deployed systems a means of exchanging their values 
 using XML markup.
 
 All that seems to be required in the current WSS token is a slight change 
to provide
 a means of using attributes to identify the payload schema, encoding and 
type. These
attributes could default to the more narrow set of assumptions that are currently
assumed.

In XCBF we already know the schema is ASN.1 and the encoding is XML markup, 
 and we identify types using the dotted form of ASN.1 object identifiers
such as 
 <contentType>1.2.840.113549.1.7.6</contentType>. This 
gives us the same 
 abstract values for type identifiers whether we're using DER or XER.
 
 This is the way forward that supports XCBF requirements and provides a means 
of
 supporting general CMS types whether they are encoded in binary and base64 
 armored or encoded in XML markup based on the same ASN.1 schema used to
 encode the binary equivalents.
 
 Phil
 
 Here is a clip from an XCBF example that uses the PKCS #7 ASN.1 type 
EncryptedData. We support both a fixed key (known by the sender and 
receiver, and a named key choice alternative for this type. Here, the 
"<fixedKey>" choice alternative of EncryptedData is shown:
<fixedKey>
   <version>84</version>
   <encryptedContentInfo>
      <contentType>1.2.840.113549.1.7.6</contentType>
      <contentEncryptionAlgorithm>
         <algorithm>1.2.840.113549.3.7</algorithm>
         <parameters>
            <IV>7EA13D6E143CB5C9</IV>
         </parameters>
      </contentEncryptionAlgorithm>
      <encryptedContent>
         F9C32CC99FA8CEA043B88D7A4981C32836A0D04444FECA6B
         0B8CC83622CF4112F04B24710498D82996183196809FA353
                   ... and so forth ...
         27875EE54C22CD489BFDD89F7020BD59C8AD15D403DE2E78
         75B5571A5EBF80C78B8990448F5B71144FFEBE4B5726BCD1
      </encryptedContent>
   </encryptedContentInfo>
</fixedKey>
The input to the content encryption process is simply an encoding of type
BiometricObjects,
a sequence of one or more values of type BiometricObject:

<BiometricObjects>

   <BiometricObject>
      <biometricHeader>
         <version> 0 </version>
         <recordType> <id> 4 </id> </recordType>
         <dataType> <processed/> </dataType>
         <purpose> <audit/> </purpose>
         <quality> <notSet/> </quality>
         <validityPeriod>
            <notBefore> 1998.10.1 </notBefore>
            <notAfter>  2008.10.1 </notAfter>
         </validityPeriod>
         <format>
            <formatOwner>
               <oid> 2.23.42.9.10.4.2 </oid>
            </formatOwner>
         </format>
      </biometricHeader>
      <biometricData>
         0102030405060708090A0B0C0D0E0F11
      </biometricData>
   </BiometricObject>

</BiometricObjects>



  
  Ahmed, Zahid wrote:

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