Next in thread →
Next in month →
RE: [wss] Quoting Issues
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
"Martin Gudgin"
<>
10/19/2004 07:48 PM
To
"Blake Dournaee"
<>, Bruce Rich/Austin/IBM@IBMUS, <>
cc
<>
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:]
> Sent: 18 October 2004 13:37
> To: 'Bruce Rich';
> Cc:
> 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:]
> Sent: Tuesday, October 12, 2004 8:16 AM
> To:
> Cc:
> 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
> To
> <>, 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:]
> 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:]
> 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
>
>
>
>
>
> "Blake Dournaee" <>
>
> 09/02/2004 03:41 PM
>
> To
>
> <>
>
>
> 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
Next in thread →
Next in month →