RE: [wss] Quoting Issues

[Bruce Rich <brich@us.ibm.com>]

Gudge,

According to RFC 2045, a Content-Type
header field is defined as follows:

     content := "Content-Type"
":" type "/" subtype
                *(";"
parameter)
                ; Matching of media
type and subtype
                ; is ALWAYS case-insensitive.

     type := discrete-type / composite-type

     discrete-type := "text" / "image" /
"audio" / "video" /
                    
 "application" / extension-token

     composite-type := "message" / "multipart"
/ extension-token

     extension-token := ietf-token / x-token

     ietf-token := <An extension token defined by a
                    standards-track
RFC and registered
                    with
IANA.>

     x-token := <The two characters "X-" or "x-"
followed, with
                 no intervening
white space, by any token>

     subtype := extension-token / iana-token

     iana-token := <A publicly-defined extension token. Tokens
                    of
this form must be registered with IANA
                    as
specified in RFC
2048.>

     parameter := attribute "=" value

     attribute := token
                  ; Matching
of attributes
                  ; is ALWAYS
case-insensitive.

     value := token / quoted-string

     token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                 or tspecials>

     tspecials :=  "(" / ")" / "<"
/ ">" / "@" /
                   ","
/ ";" / ":" / "\" / <">
                   "/"
/ "[" / "]" / "?" / "="
                   ; Must
be in quoted-string,
                   ; to use
within parameter values

So there are constraints on the allowable
characters, especially in the "parameters".

But you are correct about the missing
semicolon, as RFC 2112 would indicate:

     related-param    :=
[ ";" "start" "=" cid ]
                    
    [ ";" "start-info"  "="
                    
( cid-list / value ) ]
                    
    [ ";" "type"  "=" type
"/" subtype ]
                   ; order
independent

     cid-list        := cid cid-list

     cid             := msg-id
    ; c.f. [822]

     value           := token / quoted-string
   ; c.f. [MIME]
                    ;
value cannot begin with "<"

   Note that the parameter values will usually require quoting.  Msg-id
   contains the special characters "<", ">",
"@", and perhaps other
   special characters.  If msg-id contains quoted-strings, those
quote
   marks must be escaped.  Similarly, the type parameter contains
the
   special character "/".

Bruce A Rich
brich@us.ibm.com

"Martin Gudgin" <mgudgin@microsoft.com>

10/19/2004 07:48 PM

To	"Blake Dournaee" <blake@sarvega.com>, Bruce Rich/Austin/IBM@IBMUS, <Frederick.Hirsch@nokia.com>
cc	<wss@lists.oasis-open.org>
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.
> 
>

S/MIME Cryptographic Signature