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: WSS editorial questions

In looking at the SOAP Message Security specification for WS-I basic security profile, I realized that the third bullet in the encryption processing rules in section 9.3.1 (lines 1136-1139) isn't clear regarding EncryptedKey usage. (Draft 17, 27 Aug 2003, merged)

Lines 1074-1075  in the xenc:EncryptedKey section suggest that a listing of where each encrypted key is used be included as a ReferenceList sub-element of the EncryptedKey element(1083-1114). Perhaps the example should show this.

The processing rules section that follows can be read as if the ReferenceList is a sibling of the EncryptedKey element (1136-1139). This suggests another use of ReferenceList, for keys that do not have corresponding EncryptedKey elements.

To clarify this, I suggest we revise the SOAP Message security draft processing rule at line 1136 to read:
"When an EncryptedKey is used, create a <xenc:EncryptedKey> sub-element of the <wsse:Security> element. This <xenc:EncryptedKey> sub-element SHOULD contain an <xenc:ReferenceList> sub-element, containing a <xenc:DataReference> to each <xenc:EncryptedData> element that was encrypted using that key.

When an EncryptedKey element is not used, then a <xenc:ReferenceList> sub-element of the <wsse:Security> element SHOULD be created to refer to all EncryptedData elements not associated with EncryptedKey elements."

I believe this is what the specification is saying for when an EncryptedKey element is used, but not sure. If it is, then this is an editorial proposal. If not, I would appreciate clarification.

2.) Editorial note at line 1137-1138 says "(note that if the SOAP "role" and "mustUnderstand" attributes are different, then a new header block may be necessary)"

It might be worth expanding this note a bit, to make it clear to readers. I believe it means that if two headers with different header role and/or mustUnderstand attributes have content that is encrypted, then the encryption data associated with these two headers (e.g. EncryptedKey, ReferenceList) might require use of two Security header blocks with corresponding role and attribute information.

regards, Frederick
Frederick Hirsch
Nokia Mobile Phones

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