[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Quoting Issues
Frederick, Bruce – Now that I’ve got the time to think about the issue with quoting, this brings up an important question regarding when MIME Canonicalization actually applies. For example, Bruce is arguing that certain MIME header parameter values that use the forward should be encased in double quotes. For example, our SOAP message packages should look like this: Content-Type: multipart/related; boundary=”sig-example” type=”text/xml” --sig-example Content-Type: “text/xml” <?xml version="1.0" encoding="utf-8" ?> <foo/> --sig-example Content-Type: “image/jpeg” Content-Id: <signature> Content-Transfer-Encoding: base64 Dcg3AdGFcFs3764fddSArk I have no problem using this rule in the example for the SwA profile scenarios to aid interoperability. One note, however, is if you look at the SwA note (http://www.w3.org/TR/SOAP-attachments), double quotes are not used. I'm not sure if this matters if they are wrong about the use of double quotes. The question here, however, is that in the specific case where the Attachment-Content-Only transform is used, a SwA Profile implementation *should not* touch the headers at all. That is, the Canonicalization rules Frederick has formalized in the profile is a "code path" that should not be followed when the MIME headers are not included in the signing or encryption. In other words, when we're not signing or encrypting the MIME headers, we don't need to canonicalize them. Or do we? In the current SwA profile, the MIME Canonicalization rules only seem to come into play when the Attachment-Complete transform is utilized. To circle back to my conclusion: Given the way the SwA profile is written currently, we can't enforce the double quote rule unless we also enforce MIME header Canonicalization in all cases. Blake ________________________________________ From: Bruce Rich [mailto:brich@us.ibm.com] Sent: Tuesday, October 12, 2004 8:16 AM To: Frederick.Hirsch@nokia.com Cc: blake@sarvega.com Subject: RE: [wss] SwA Interop Scenarios It would fix the problem that I was having, but is a bit draconian. I think that it is only strictly required when the parameters embed MIME special characters, which would be something from this set: ()<>@,;:\\\"\t []/?= Bruce A Rich brich@us.ibm.com <Frederick.Hirsch@nokia.com> 10/12/2004 09:50 AM To <blake@sarvega.com>, Bruce Rich/Austin/IBM@IBMUS cc Subject RE: [wss] SwA Interop Scenarios I've gotten feedback from Dana Kaufman (Forum Systems) on section 4.3.1, header canonicalization, and have added this statement (among others, new draft out later today): "Enclosing double-quotes MUST be added to MIME header parameter values that do not already contain enclosing quotes. Quoted characters other than double-quote and backslash ("\") in MIME header parameter values MUST be unquoted. Double-quote and backslash characters in MIME parameter values MUST be character encoded." I think this would resolve this issue, since the canonicalized "type" value in your example would be quoted. Does this resolve this issue? regards, Frederick Frederick Hirsch Nokia ________________________________ From: ext Blake Dournaee [mailto:blake@sarvega.com] Sent: Monday, October 11, 2004 9:20 PM To: 'Bruce Rich' Cc: Hirsch Frederick (Nokia-TP/Boston) Subject: RE: [wss] SwA Interop Scenarios Hi Bruce, This is a good question, and I'm copying Frederick Hirsch to see if he can make a statement regarding the appropriate MIME version that should apply. Since the scenarios are based around the OASIS WS-Security SwA Profile, we may want to make a statement to this effect that document instead and have the interoperability scenarios inherit this decision. I was under the assumption that the quotes were optional, but I may be wrong. FYI, I should be adding more scenarios (probably 2) that also cover the case where the MIME attachments should be signed/encrypted. Thanks, Blake Dournaee Senior Security Architect Sarvega, Inc. ________________________________ From: Bruce Rich [mailto:brich@us.ibm.com] Sent: Monday, October 11, 2004 1:43 PM To: Blake Dournaee Subject: Re: [wss] SwA Interop Scenarios Blake, I'm OK with the scenarios you proposed. One thing I'm a bit curious about is whether the following line is valid MIME Content-Type: multipart/related; boundary="sig-example" type=text/xml My parser allows the slash on multipart/related, but is nonplussed to find it on type=text/xml without quotes around the text/xml part. Given the multiple RFCs that might apply, which one is most definitive for this case? Bruce A Rich brich@us.ibm.com "Blake Dournaee" <blake@sarvega.com> 09/02/2004 03:41 PM To <wss@lists.oasis-open.org> cc Subject [wss] SwA Interop Scenarios All, Right now I am planning three simple interop scenarios for the SwA profile. Right now I am leaving the headers out of scope until we decide on how to handle them exactly. I am proposing the following three scenarios. Please let me know if you have any comments or concerns about these. These are a good starting point and I anticipate we will add more variables based on demand: Scenario #1: Attachment Signature where the attachment content type is fixed at image/jpeg and the reference mechanism is Content-Id. The signature will be based on an X.509 certificate Scenario #2: Attachment Encryption where the attachment content type is fixed at image/jpeg using a shared secret for encryption, which is wrapped with a public key. Content-Id is used for the reference mechanism. Scenario #3: Attachment Signature + Encryption where the content type is fixed at text/xml. Similar mechanisms as above for keys and algorithms. Regards, Blake To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup .php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]