[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Quoting Issues
I'm confused. The Transform in the CipherReference refers how to get the cipher data from the attachment containing the cipher data, and is required to always be Content-Only. This is what 4.4.1 says.
The xenc:EncryptedData Type attribute specifies what was encrypted (content or content and headers) using an independent URI, distinct from the transform, as noted in 4.4.2 item #3.
Thus I don't see a requirement in the text to canonicalize headers for encryption and would expect that it not be done.
Is this a mistake, or should the example you give be modified?
regards, Frederick
Frederick Hirsch
Nokia
-----Original Message-----
From: ext Blake Dournaee [mailto:blake@sarvega.com]
Sent: Wednesday, October 20, 2004 9:18 AM
To: Hirsch Frederick (Nokia-TP/Boston); mgudgin@microsoft.com; brich@us.ibm.com
Cc: wss@lists.oasis-open.org
Subject: RE: [wss] Quoting Issues
Frederick -
I believe that the MIME Canonicalization is definitely required for encryption. Even though the transform element is used as a ds:Reference transform, this is also used as a child to the xenc:CipherReference element as well.
<xenc:CipherReference URI=cid:bar";>
<xenc:Transforms>
<ds:Transform
Algorithm="http://docs.oasisopen.org/wss/2004/XX/oasis-2004XX-wss-swa-
profile-1.0#Attachment-Complete-Transform"/>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
< /xenc:Transforms>
</xenc:CipherRefence>
Blake Dournaee
-----Original Message-----
From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
Sent: Wednesday, October 20, 2004 5:59 AM
To: mgudgin@microsoft.com; blake@sarvega.com; brich@us.ibm.com
Cc: wss@lists.oasis-open.org
Subject: RE: [wss] Quoting Issues
The way the profile is drafted, the MIME header canonicalization only applies when signing the headers, and actually does not change the message, but is used to produce transform output that can lead to the digest for the signature.
Thus true, header canonicalization is not required when not signing the attachment headers. Moreover I did not think it was required for encryption either since the transform that specifies the canonicalization is used as a ds:Reference transform.
regards, Frederick
Frederick Hirsch
Nokia
-----Original Message-----
From: ext Martin Gudgin [mailto:mgudgin@microsoft.com]
Sent: Tuesday, October 19, 2004 8:49 PM
To: Blake Dournaee; Bruce Rich; Hirsch Frederick (Nokia-TP/Boston)
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.
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]