New Issue: Header Encryption

["Vijay Gajjala" <vijayg@microsoft.com>]

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

Header Encryption.doc