RE: [wss] Comments on Swa profile interoperability.

5. Optionally set the <xenc:EncryptedData> Encoding attribute to reflect the attachment MIME part encoding, as visible to the security layer at the time of encryption. This is advisory information to the application receiving the decrypted content.

3) 4.5.3 (Decryption processing rules)

3a) Remove step 2 completely: (text about base64 decoding)

3b) Add new final step (step 5):

If the <xenc:EncryptedData> Encoding attribute is present then the decryption security layer MAY pass this advisory information to the application.

4) 4.4.4 Processing rules for attachment signing

Add the following to the end of the text for item #1:

The MIME content to be MIME canonicalized MUST NOT have any additional transfer-encoding applied before canonicalization and digest creation.

5) 4.4.5 Processing rules for attachment signature verification

Add the following at the end of text for item #2

The MIME content to be MIME canonicalized MUST have had any transfer-encoding processed at the MIME layer before this step is performed.

----

These are the only proposed changes to draft 14 of the SwA profile at this point.

The proposed resolution to issue 342 to only allow CID references is already incorporated into draft 14.

Comment, correction to the language?

regards, Frederick

Frederick Hirsch
Nokia

My understanding of the transfer-encoding problem is the following:

RFC2049 (MIME Conformance Criteria), section 4, defines a canonical encoding model which mandates 4 steps (sending side):

(1) creation of local file form,

(2) conversion to canonical form,

(3) transfer-encoding,

(4) insertion into MIME entity.

For the receiving side, the same RFC 2049 continues:

“Conversion from MIME entity form to local form is accomplished by reversing these steps. Note that reversal of these steps may produce differing results since there is no guarantee that the original and final local forms are the same.”

The question for WSS is: “where should SOAP level encryption and signature be inserted in this model?”

My understanding and proposal is that SOAP level encryption and signature be located between (2) and (3). This means that transfer-encoding can be left completely out of scope from the WSS Swa profile. In other words there would be no notion of transfer-encoding in the SOAP layer, since it is MIME layer’s exclusive business. I guess this is not even my proposal since this is what section 2 of the WSS Swa profile is saying (see extract at the end of the mail). If we agree to that layering, then we should not bother about transfer-encoding at all in the WSS Swa profile.

This has two consequences:

- we should not allow in the WSS Swa profile any kind of encoding transform (e.g. base64) for transfer purpose, to avoid interfering with the MIME layer

- we should clarify that, if the <xenc:EncryptedData> Encoding attribute is used in relation to a MIME part, it is an optional (and only advisory) attribute which describes the encoding of the data (performed at application level) which has been encrypted but has no relation with the actual encoding that is performed independently by the MIME layer for transfer purposes.

Concretely, I propose the following text changes in the WSS Swa profile:

In sections 4.5.1, 4.5.2 and 4.5.3 (encryption rules), remove the ability to use the base64 transform and explicitly forbid any kind of encoding transform (e.g. base64) for transfer purpose.
In 4.5.1 add a warning/note concerning the <xenc:EncryptedData> Encoding attribute to say: “When used, the <xenc:EncryptedData> Encoding attribute is an optional (and only advisory) attribute which describes the encoding of the data (performed at application level) which has been encrypted but has no relation with the actual encoding that is performed independently by the MIME layer for transfer purposes”. This a correction to the text proposed by Frederick Hirsh in http://www.oasis-open.org/archives/wss/200411/msg00061.html .
In section 4.4.4 (signature rules), explicitly forbid any kind of encoding transform (e.g. base64) for transfer purpose.

<< Extract of Section 2 of the Swa profile

In effect this combines two processing layers, a SOAP messaging layer and a MIME wrapping. A SOAP

sender effectively transmits a SOAP message and corresponding attachments by passing them to a

MIME layer that serializes them. A SOAP receiver receives a message and attachments after the MIME

layer processes the MIME serialization. This is important since certain aspects of the MIME processing

may be changed at different intermediary transport nodes, yet remain transparent to the SOAP layer. For

example, a MIME processing node may change the transfer encoding of a MIME part, transparently to the

SOAP nodes. The MIME layer may translate to and from a transfer encoding upon serialization and deserialization.

….

SOAP message security is intended to provide security at the SOAP messaging layer, including support

for SOAP intermediaries. Thus this profile supports securing the attachment content, possibly including

MIME headers that are associated directly with the content (such as Content-Type, Content-Length and

other Content related MIME headers) and not MIME headers associated with MIME serialization. This

simplifies the profile and also delineates the layering.

Serge Cayron

Technical Architect - ACORD

+32 10 41 92 58 (Home office phone/fax)

+44 207 617 6400 (London office)

scayron@acord.org

www.acord.org

From: Maneesh Sahu [mailto:MSahu@actional.com]
Sent: Friday, November 19, 2004 12:58 PM
To: wss@lists.oasis-open.org
Subject: scayron@acord.org - Email found in subject - FW: [wss] Comments on Swa profile interoperability.

From: Cayron, Serge [mailto:Scayron@acord.org]
Sent: Thursday, November 18, 2004 2:24 PM
To: wss@lists.oasis-open.org
Subject: [wss] Comments on Swa profile interoperability.

I also don’t understand the need for the requirement and solution described in http://www.oasis-open.org/archives/wss/200411/msg00061.html (Swa issue 341)

Why would we need to take the Content-Transfer encoding MIME header into account at encryption time? The Do we want to encrypt base64 content? This is what is suggested by the phrase:

a) in section 4.5.2 Encryption processing rules, adding a new rule 4 between original rules 4 and 5.(and renumber the rules). This is a modification of what Maneesh proposed:
4. Optionally set the <xenc:EncryptedData> Encoding attribute to reflect the attachment MIME part Content-Transfer-Encoding header of the MIME part before encryption. Specifically, if the original MIME part had a base64 Content-Transfer-Encoding, the Encoding attribute MAY be set to the corresponding URL for base64 encoding specified in XML Digital Signature: 'http://www.w3.org/2000/09/xmldsig#base64'.

If we accept that base64 encoding is the business of the MIME processor, then encryption should always be done on (canonical) clear text.

[MS] The intent of the EncryptedData Encoding attribute was to preserve the original C-T-E value of the pristine attachment part. It can be used by the decryptor to restore the attachment to its original encoding after decryption. An attachment is usually with a binary C-T-E after decryption. Using the encoding attribute, it can be restored to, say, a base64 encoding.

Maneesh Sahu

Actional Corporation

wss message