[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Comments on Swa profile interoperability.
Frederick,
Your proposal is OK, except some corrections to the language. See below <SC> items. I hope this contributes to simplification and clarity.
Regards,
Serge Cayron Technical Architect - ACORD +32 10 41 92 58 (Home office phone/fax) +44 207 617 6400 (London office)
From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
Serge
Thank you for taking the time to raise this issue.
I agree with regard to the layering goal and the draft notes this.
In the interest of simplicity I agree with removing the base64 transform material from the draft.
Specifically, I propose the following changes to draft 14, a clarification and slight modification of your recommendation:
1) 4.5.1 (MIME Part Cipher Reference)
Remove text starting at line 435 through end of section (line 445): "The cipher data conveyed ... specified."
<SC> OK for the text removed + suggest finishing the section with the phrase: “One MUST not add any other transform for transfer encoding purpose (e.g. base64). As said in Section 2, transfer encoding is left to the MIME layer.”
2) 4.5.2 (Encryption processing rules)
Add new step 5 at line 473 as follows: (replacing my previous proposal. Note this is related to issue 341 as well) 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. <SC> I would say: “attachment content encoding (i.e. describing the encoding of the data performed at application level)” instead of “attachment MIME part encoding” + suggest finishing with the phrase: “It should be understood that this has no relation with the actual encoding that could be performed independently by the MIME layer later for transfer purposes.” <SC> don’t forget to remove base64 stuff from point 6 as well (478-481). 3) 4.5.3 (Decryption processing rules) 3a) Remove step 2 completely: (text about base64 decoding) <SC> OK 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. <SC> OK 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. <SC> I think this is ambiguous because the application is free to encode the data (see 4.5.2 above) before passing it to the SOAP security layer. Instead, I propose to add at the end of point 4: “One MUST not add any other transform for transfer encoding purpose (e.g. base64). As said in Section 2, transfer encoding is left to the MIME layer.” 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. <SC> OK ---- These are the only proposed changes to draft 14 of the SwA profile at this point. <SC> A last fix: In draft 14 you changed the section numbering to add 4.2. Therefore line 216 should now refer to 4.4.2 and lines 235-236 to 4.4.1 and 4.4.2 The proposed resolution to issue 342 to only allow CID references is already incorporated into draft 14. Comment, correction to the language? regards, Frederick
From: ext
Cayron, Serge [mailto:Scayron@acord.org] 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]