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:]
> Sent: Thursday, June 24, 2004 3:01 PM
> To: 'DeMartini, Thomas'; Hirsch Frederick (Nokia-TP/Boston);
>
> 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.
>
>
