[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Attachment Profile Question/Comment
Thomas, I think we can go by the 80/20 rule here; if the majority of the anticipated scenarios for SwA won't require a decryption transform (e.g. they are sufficiently simple), then we can clearly state that the decryption transform is out of scope for the profile, but note that some scenarios may require such a transform to resolve ambiguities. We should, however, provide an example somewhere of scenario that uses attachments where the ordering cannot be discerned, giving the reader an understanding of when this transform is required. I can't think of such an example. Can anyone describe a scenario involving the signing/encryption of attachments where the order of the security operations cannot be determined using the pre-pend (LIFO stack) rule when a single security header is utilized? Blake Dournaee Senior Security Architect Sarvega, Inc. -----Original Message----- From: DeMartini, Thomas [mailto:Thomas.DeMartini@CONTENTGUARD.COM] Sent: Wednesday, June 30, 2004 4:13 PM To: Frederick.Hirsch@nokia.com; blake@sarvega.com Cc: wss@lists.oasis-open.org Subject: RE: [wss] Attachment Profile Question/Comment I think we had this discussion about signature/encryption and single header vs multiple headers before for quite some time. The outcome of that discussion was finally recorded in section 9.4 in the core document, which basically concludes that, in many of the cases we care about, decryption transform will not be necessary, but that we allow it because there are a few cases where it is necessary. I assume that all the same conclusions will hold for SwA. The only difference is that with SwA we do not have a defined attachment-decryption transform. I think we can take one of two paths: Path 1: (Attachment-decryption transform is in-scope for the profile): Define an attachment-decryption transform and clarify that is optional, and specified for the few cases where it is necessary. Path 2: (Attachment-decryption transform is out-of-scope for the profile): Add a note to the SwA profile similar to the one in section 9.4 of the core document. In that section, point out that no attachment-decryption transform is defined, but if one gets defined (by W3C or whoever) in the future or if the W3C decryption-transform spec gets relaxed to apply to attachments that such a transform MAY be used. Basically, I want to make sure that if we don't have an attachment-decryption transform in our spec it is not because we think everything can be done without it but because we think it is out of scope for the SwA profile. &Thomas. -----Original Message----- From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] Sent: Wednesday, June 30, 2004 1:42 PM To: blake@sarvega.com Cc: wss@lists.oasis-open.org Subject: RE: [wss] Attachment Profile Question/Comment Blake Thanks for the good catch. You are absolutely right regarding the decryption transform. Three facts in combination eliminate the need for the attachment decryption transform: 1. The SOAP Message Security standard requires distinct roles (actors) for <wsse:Security> headers 2. Every signature or encryption adds a distinct XML element to the <wsse:Security> header (either a <ds:Signature> or an <xenc:EncryptedData> element). 3. The pre-pend rule makes ordering clear. I'm removing the attachment decryption transform material, simplifying the profile. Thanks Regards, Frederick Frederick Hirsch Nokia > -----Original Message----- > From: ext Blake Dournaee [mailto:blake@sarvega.com] > Sent: Thursday, June 24, 2004 3:01 PM > To: 'DeMartini, Thomas'; Hirsch Frederick (Nokia-TP/Boston); > wss@lists.oasis-open.org > Subject: [wss] Attachment Profile Question/Comment > > All, > > I had a comment/question regarding the WSS SwA profile. > > In section 2.3, the motivation for the decryption transform > is driven in part by the use of dual <S11:Header> elements. > It seems to me that the order of digital signatures and > encryption can indeed be discerned if the operations are > "stacked" (operations are pre-pended) inside a single > <S11:Header>/<wsse:Security> element, similar to what is done > for pure WSS. > > My concern here is that people reading this specification will assume > (wrongly) that in order to meet the profile for signing and > encryption of attachments they must (a) use a distinct header > block for each operation and > (b) use the decryption transform in all cases. > > Can we make a clarification regarding signing and encryption > of attachments? > I personally would like to see some text that describes the > case where signing and encryption of attachments is done > within a single <wsse:Security> block, with subsequent > operations pre-pended, thus eliminating the need for the > decryption transform. Unless I am missing something the > example given in 2.2.3 may be overly complicated from the > paradigm case. > > Regards, > > Blake Dournaee > Senior Security Architect > Sarvega, Inc. > > > > > > 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]