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

Yes, the reason for the new element is due to the schema issue.   Not having the URI attribute present when schema requires it is breaking a normative requirement, and having it but ignoring it could lead to potential errors and  confusion. Pragmatically what you suggest is might be appropriate since those who implement the 2.0 transform can also understand that the URI on the CipherReference element itself is ignored.

Implementations can determine it is 2.0 from the transform algorithm value, the element isn't necessary for that.

Do others agree with simply ignoring the URI attribute on the CipherReference when using the 2.0 transform and not defining a new element?

regards, Frederick

Frederick Hirsch
Nokia



On Jun 10, 2011, at 12:55 PM, ext Pratik Datta wrote:

> Frederick,
> 
> Are you proposing the new "CipherReference2" element only because the URI attribute is required?  
> 
> It would be easier from implementation point of view, if we just say that if CipherReference has a the xmldsig2 transform, then the URI attribute should be ignored, that way we don't have to make a new element.
> 
> Also there are problems in introducing CipherReference2 element, because the parent element "CipherData" can only take a CipherValue or CipherReference, it cannot be extended to also take a CipherReference2.
> 
> Assuming we go with CipherReference, the rest of your proposal looks good to me.
> 
> Pratik
> 
> -----Original Message-----
> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] 
> Sent: Friday, June 10, 2011 9:23 AM
> To: public-xmlsec@w3.org
> Cc: Frederick.Hirsch@nokia.com
> Subject: 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 17:25:14 UTC