[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Quoting Issues
AFAICT you only have to quote parameters in MIME headers when those parameters might contain a semicolon. This is so that the MIME header parser can figure out where the parameter boundaries are. The Content-Type: "text/xml" and Content-Type: "image/jpeg" example below do not need to be quoted. Text based types are often quoted because they may carry a charset parameter. e.g. Content-Type: "text/xml; charset=UTF-8"
Gudge
P.S. Your example below is missing a semicolon after the boundary parameter.
> -----Original Message-----
> From: Blake Dournaee [mailto:blake@sarvega.com]
> Sent: 18 October 2004 13:37
> To: 'Bruce Rich'; Frederick.Hirsch@nokia.com
> Cc: wss@lists.oasis-open.org
> Subject: [wss] 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.
>
>
>
>
>
> 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]