OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

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


Subject: Issue 86 proposed resolution - content encryption policy assertion


This message proposes a solution to Issue 86 for discussion and  
decision by TC.

Issue 86: <http://docs.oasis-open.org/ws-sx/issues/Issues.xml#i086>

The goal of this issue is to enable the use of a simple and clear  
policy assertion specifying element content encryption. This could be  
used, for example, to encrypt the content of SOAP headers when WSS  
1.1 EncryptedHeader is not available (e.g. WSS 1.0 implementations)

Alternative solutions
There is more than one way to approach this issue. The following are  
three possibilities:

1. Define nothing special, use the existing EncryptedElements  
assertion. Specify XPath expression(s) so all content is to be  
encrypted.

2. Add optional attribute to EncryptedElements/XPath element  
indicating whether #Element or #Content encryption is to be performed  
on that item to be encrypted

3. Add additional policy assertion: ContentEncryptedElements, with  
similar schema definition to EncryptedElements, but with semantics  
that #Content encryption is to be performed.

Proposal
I propose we adopt choice #3, define additional policy assertion  
ContentEncryptedElements.
Detailed proposal follows rationale below.

Rationale

1. The first option does not meet the goal of clarity and simplicity  
of use, for example may have the wrong granularity using wildcards.

2. XPath parameter is used in variety of contexts, so introducing an  
optional attribute for it (e.g. EncryptionType) would be inconsistent  
and only applicable in the context of EncryptedElements.

3. Using such an optional attribute would complicate the XML schema  
and introduce changes to existing schema.

4. Defining an additional assertion makes it clear how each item  
specified by the XPath parameters is to be handled - i.e. reduces  
chance for error related to use of an optional attribute and the  
possible differences in semantics among multiple XPath parameters in  
a single assertion.

Two Detailed Changes

Change #1: to WS-SecurityPolicy

Add following new section (and regenerate table of contents):

2.1.3  ContentEncryptedElements Assertion
The ContentEncryptedElements assertion is used to specify arbitrary  
elements in the message that require confidentiality protection of  
their content. This assertion can be satisfied using WSS: SOAP  
Message Security mechanisms or by mechanisms out of scope of SOAP  
message security, for example by sending the message over a secure  
transport protocol like HTTPS.  The binding details the exact  
mechanism by which the protection is provided.

There MAY be multiple ContentEncryptedElements assertions present.  
Multiple ContentEncryptedElements assertions present within a policy  
alternative are equivalent to a single ContentEncryptedElements  
assertion containing the union of all specified XPath expressions.

Syntax
<sp:ContentEncryptedElements XPathVersion="xs:anyURI"? ... >
   <sp:XPath>xs:string</sp:XPath>+
   ...
</sp:ContentEncryptedElements>

The following describes the attributes and elements listed in the  
schema outlined above:
/sp:ContentEncryptedElements
This assertion specifies the parts of the message that need  
confidentiality protection. Any such elements are subject to #Content  
encryption.
/sp:ContentEncryptedElements/@XPathVersion
This optional attribute contains a URI which indicates the version of  
XPath to use.
/sp:ContentEncryptedElements/sp:XPath
This element contains a string specifying an XPath expression that  
identifies the nodes to be confidentiality protected. The XPath  
expression is evaluated against the S:Envelope element node of the  
message. Multiple instances of this element may appear within this  
assertion and should be treated as separate references.

Change #2 -  to XML Schema in ws-securitypolicy-1.2.xsd:

add the following after the  EncryptedElements element definition:
  <xsd:element name="ContentEncryptedElements"  
type="tns:EncElementsType" />


regards, Frederick

Frederick Hirsch
Nokia





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