[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New Issue: Header Encryption
As noted in earlier discussions in the TC there were questions around how headers (including <wsse:Security>) are encrypted. There are two modes of header encryption that have been suggested for SOAP message security: (1) encrypting the header in its entirety and replacing header with an <xenc:EncryptedData> element and (2) encrypting the sub elements of the header only. However, after investigating this further, we think there are potential issues with both approaches which have been raised in TC discussions and at interoperability events. For example, encrypting the header in its entirety has some limitations: a) The SOAP processing model requires that a SOAP processor MUST examine all mandatory headers targeted at the role of the processor and determine that they can be understood before it can commence processing any of the headers. As a result, encrypting the header in its entirety restricts a SOAP processor from checking if it understands all SOAP mandatory headers before processing them. b) Further, one cannot add soap processing attributes to the <xenc:EncryptedData> element because it violates their schema. Now it can, and has been debated, as to whether or not these are really issues, but the general feeling seems to be that it could be an interoperability issue. Encrypting the sub elements of the header has limitations too: a) The attributes on the SOAP header are left in the clear. b) Additionally, this could (and will likely, unless explictly planned for) violate the schema for the header element by replacing the contents with <xenc:EncryptedData> element. So there are concerns that this approach will be problematic as well. Based on these limitations, it appears we need an alternative mechanism for encrypting a header that doesn't violate SOAP processing guidelines, doesn't expose private data in the clear, and doesn't violate schema for a header element. Attached is a proposal we'd like to submit which was pulled together by some members of the TC as a way to encrypt headers while meeting the above requirements. This approach introduces an EncryptedHeader element that allows the addition of other SOAP attributes and wsu:Id attribute. This contains an <xenc:EncryptedData> element which represents the entire encrypted header. We ask that the TC consider addressing this scenario and consider using this input material. <<Header Encryption.doc>> Vijay
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]