RE: [wss] Attachment Profile Question/Comment

[<Frederick.Hirsch@nokia.com>]

If an attachment is destined for more than one role, then multiple
security header blocks are appropriate and it is easy to construct cases
requiring an attachment decryption transform as outlined in the draft.

With the constraint of attachment to single role then I could not create
such a scenario and believe the transform is not needed.

Maybe the right solution is to define the transform, but also clearly
delineate between these two cases and that multiple security header
blocks targeted to one role are not allowed.

Thus the transform is only needed in more complicated use cases.  

Regards, Frederick

Frederick Hirsch
Nokia

> -----Original Message-----
> From: ext Blake Dournaee [mailto:blake@sarvega.com] 
> Sent: Thursday, July 01, 2004 5:53 PM
> To: 'DeMartini, Thomas'; Hirsch Frederick (Nokia-TP/Boston)
> Cc: wss@lists.oasis-open.org
> 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.
> 
> 
>