[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 105: SC label concatenation rules unclear
Title: SC label concatenation rules unclear
WS-SecureConversation mentions the following on using label while computing deriving keys,
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,
label is the concatenation of the client's label and the service's label. These
labels can be
are processed as UTF-8 encoded octets. If either isn't specified in the policy,
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”.
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.