RE: [wss] Attachment Profile Question/Comment

["Blake Dournaee" <blake@sarvega.com>]

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.