Proposal for using xmldsig2:Selection with XML Encryption CipherReference (ACTION-805/ISSUE-132)

The XML Signature 2.0 Referencing model offers simplification to the XML Encryption CipherReference transform processing model. The example in XML Encryption 1.1 can be revised to use 2.0 mechanisms as follows.

The current model in XML Encryption is that a CipherReference element specifies a URI attribute for content and MAY apply further transforms. The example in XML Encryption shows use of XPath to select a specific element within an XML document and a base64 transform to decode the base64 to octets (two 1.1 transforms are applied).

This may be changed as follows

1. omit the URI from the CipherReference element, to be consistent with 2.0 practice of defining all information within the transform

2. Provide single transform (as child of Transforms) within CipherReference element , identified as xmldsig2 transform as defined in XML Signature 2.0

3. Use  Selection element with Selection URI attribute for the specific fragment within the source document (e.g. http://www.example.com/#example1 ) and Algorithm attribute of http://www.w3.org/2010/xmldsig2#binaryfromBase64 .
This implies base64 decoding.

Thus we now have a single fixed Transform with a single Selection element rather than two 1.1 transforms, and potentially fewer potentially problematical transform choices.

The 2.0 selection mechanism offers other methods such as binary only that may also be useful.

Revising XML Encryption 1.1 to produce XML Encryption 2.0 sounds like a confusing exercise to the stakeholders. 

Cleanest might be to define a new CipherReference2 element. This would make it easy for an implementation to recognize whether it supports this, rather than relying on recognition of the 2.0 transform identifier. I think it is also necessary, as the URI attribute on the CipherReference is required, and with 2.0 we would like to omit it.

I suggest we create a new 2.0 specification

"Use of XML Security 2.0 Selection Transform for XML Encryption 1.1" 

1. Introduction and example based on above material.

2. Normatively define the schema and element for CipherReference2 in the xmldsig2 namespace.

Schema:

  <element name='CipherReference2' type='xmldsig2:CipherReference2Type'/>

   <complexType name='CipherReferenceType2'>

       <sequence>

         <element name='Transforms' type='xmldsig2:TransformsType2' minOccurs='0' maxOccurs='1'/>

       </sequence>

   </complexType>


    <complexType name='TransformsType2'>

       <sequence>

         <element ref='ds:Transform' minOccurs='1' maxOccurs='1'/> 

       </sequence>

     </complexType>

3. Normative Processing Rules:

The single Transform child of the CipherReference2/Transforms element MUST have an algorithm attribute value consistent with 2.0 processing. The only current such value is "http://www.w3.org/2010/xmldsig2#transform"

The dsig2:Selection element MUST be present as a child of this Transform element and be used to obtain the cipher data. The URI attribute of the dsig2:Selection element MUST specify the source for the cipher data (and for content from within XML should specify the fragment if necessary, see 10.6.1 Selection of XML Documents or Fragments of XML Signature 2.0 for details)

If the cipher data is base64 encoded content within an XML source, the http://www.w3.org/2010/xmldsig2#binaryfromBase64 algorithm identifier MUST be specified as the dsig2:Selection Algorithm attribute value.

If the cipher data is binary (and not base64 encoded) content from the URI source, the http://www.w3.org/2010/xmldsig2#binaryExternal algorithm identifier MUST be specified as the dsig2:Selection Algorithm attribute value.

No other Algorithm value should be used.

Please comment.  If this proposal sounds reasonable I can create an initial draft document for this.

regards, Frederick

Frederick Hirsch
Nokia

For Tracker, this should complete and go beyond ACTION-805 to review ISSUE-132

Received on Friday, 10 June 2011 16:23:56 UTC