NEW ISSUE: SC label concatenation rules unclear

Title: SC label concatenation rules unclear

Description:

WS-SecureConversation mentions the following on using label while computing deriving keys,

/wsc:DerivedKeyToken/wsc:Label

If specified, this optional element defines a label that is used in the key derivation function for this derived key. If this isn't specified, it is assumed that the recipient knows the label to use. The string content of this element is UTF-8 encoded to obtain the label used in key derivation. Note that once a label is used for a derivation sequence, the same label SHOULD be used for all subsequent derivations.

It also specifies,

The label is the concatenation of the client's label and the service's label. These labels can be
discovered in each party's policy (or specifically within a <wsc:DerivedKeyToken> token).

Labels are processed as UTF-8 encoded octets. If either isn't specified in the policy, then a
default value of "WS-SecureConversation" (represented as UTF-8 octets) is used.

When a label is specified it is not clear if you should simply use it or concatenate your own label together with it. It seems that when a value is specified it makes more sense to simply use it than apply the concatenation rule. There also is nothing in SecurityPolicy that would allow the discovery of the other party’s label if it was not sent in the wsc:DerivedKeyToken. So the concatenation rule doesn’t seem feasible. However, current products do use that rule making the normal default value “WS-SecureConversationWS-SecureConversation”.

Proposal:

Change the text in section 7 on deriving keys from the above in line with current practice for the default value or using the label value when specified as follows:

The label can be specified within a <wsc:DerivedKeyToken> using the wsc:Label element. If the label isn't specified then a default value of "WS-SecureConversationWS-SecureConversation" (represented as UTF-8 octets) is used. Labels are processed as UTF-8 encoded octets.

ws-sx message