OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wss] Comments on Swa profile interoperability.


Can you make explicit change proposals against the latest SwA document for each of your comments so that we have an explicit statement of how you want the specifications changed?

 

/paulc

 

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Nepean, Ontario K2E 6A3
Tel: (613) 225-5445 Fax: (425) 936-7329
mailto:pcotton@microsoft.com

 


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

 

I recently joint the WSS group as a monitoring member. I am busy working with the WSS Swa profile for defining interoperability guidelines for ACORD (Insurance vertical standards) and have read the mails exchanged on WSS Swa interoperability trials. I have comments on base64 encoding in relation with encrypted and signed MIME parts.

 

On encrypted MIME parts: I feel that the rules given in 4.5.1 (MIME part CypherReference) about base64 encoding are unnecessarily complex. Why proposing alternate methods and cope with the base64 transform in <CypherReference>? I think this brings confusion on the respective roles of the MIME handler and the SOAP Security processor. Base64 encoding should be left to the MIME handler, which takes this kind of decision for transfer purposes, independently of the SOAP processor. Isn't it what section 2 (MIME processing) says in §1 ("a MIME processing node might change the transfer encoding of a MIME part...")? If you perform base64 encoding in the SOAP layer, then the MIME part might be double-encoded or might be decoded in later MIME nodes.

On signed MIME parts: to be consistent with the above, signature processing rules (4.4.4) should also explicitly forbid the base64 encoding transform from <ds:Reference>, which clarifies the WSI BSP R6103 recommendation ("A MIME Part signed using WSS MUST have a Content-Transfer-Encoding of binary in effect at the time of WSS processing...").

 

I think that this corroborates what is said in http://www.oasis-open.org/archives/wss/200411/msg00004.html , 
1. The SwA Interop Scenarios push Base 64 encoding and decoding to the MIME
layer. That is, encrypted attachments use a Content-Type of "base64". This
means that implementations should not add a base 64 decoding as a

<Transform> in the <CipherReference> element

 

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.

 

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

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]