[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] Comments on Swa profile interoperability.
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:
<< 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)
From: Maneesh
Sahu [mailto:MSahu@actional.com] From: Cayron, Serge
[mailto:Scayron@acord.org]
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:
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]