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: 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”
Content-Type: “text/xml”

<?xml version="1.0" encoding="utf-8" ?>

Content-Type: “image/jpeg”
Content-Id: <signature>
Content-Transfer-Encoding: base64


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

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. 


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

10/12/2004 09:50 AM 
<blake@sarvega.com>, Bruce Rich/Austin/IBM@IBMUS 

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


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

FYI, I should be adding more scenarios (probably 2) that also cover the
case where the MIME attachments should be signed/encrypted.


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


I'm OK with the scenarios you proposed. 

One thing I'm a bit curious about is whether the following line is valid

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

"Blake Dournaee" <blake@sarvega.com> 

09/02/2004 03:41 PM 






                [wss] SwA Interop Scenarios





Right now I am planning three simple interop scenarios for the SwA
Right now I am leaving the headers out of scope until we decide on how
handle them exactly.

I am proposing the following three scenarios. Please let me know if you
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
at image/jpeg and the reference mechanism is Content-Id. The signature
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
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.



To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

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