OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[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

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]