[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comment on Core Spec and Interop Scenario #3 - Decryption Transform
On lines 813-814 of the core spec it says: "Finally, if a sender wishes to sign a message before encryption, they should use the Decryption Transformation for XML Signature." [Note that "should" is not capitalized.] I am still trying to figure out if this correct or not, but it seems to conflict with lines 1140-1146 which say: "The ordering semantics of the <wsse:Security> header are sufficient to determine if signatures are over encrypted or unencrypted data. However, when a signature is included in one <wsse:Security> header and the encryption data is in another <wsse:Security> header, the proper processing order may not be apparent. If the sender wishes to sign a message that MAY subsequently be encrypted by an intermediary then the sender MAY use the Decryption Transform for XML Signature to explicitly specify the order of decryption." This confidence in the ordering semantics seems misplaced, because while lines 953-957 say: "When a sender or an intermediary encrypts portion(s) of a SOAP message using XML Encryption they MUST prepend a sub-element to the <wsse:Security> header block. Furthermore, the encrypting party MUST prepend the sub-element into the <wsse:Security> header block for the targeted recipient that is expected to decrypt these encrypted portions." lines 825-827 say: "To add a signature to a <wsse:Security> header block, a <ds:Signature> element conforming to the XML Signature specification SHOULD be prepended to the existing content of the <wsse:Security> header block." --- In any event, the example message for Interop Scenario #3 does not use the XML Decryption Transform and thus seems to be in the Chapter 9 school rather than the Chapter 8 school. It seems to me that as a general principle relying on element order is a bit risky. (Are intermediaries allowed to reorder elements?) Perhaps we should require use of the Decryption Transform on all signatures or at least in every case when both encryption and signatures are being used. But line 1144 implies that it may be impossible to know if encryption will be added, so perhaps "always" is the right rule. Note that none of this creates any security risk, it just means signatures will incorrectly fail to verify. Hal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]