Re: Object tag in Dsig 2.0

Proposed change to modified text #1:

> Modified text
> =============
> ...
> Applications which require normative type and encoding information for signature validation should specify Transforms (in compatibility mode) with well defined resulting types and/or encodings. 2.0 mode signatures should use extensibility points in dsig2:Selection element instead of Transforms.


Modified text
=============
...
Applications that require normative type and encoding information for signature validation should specify the Type and possibly SubType in the Selection element ("2.0 mode") or specify Transforms with well defined resulting types and/or encodings ("compatibility mode"). 

regards, Frederick

Frederick Hirsch
Nokia



On Jun 4, 2010, at 4:11 PM, ext Pratik Datta wrote:

> Scott,
> 
>> Presumably it doesn't have to be by ID? I think you're just saying "we
>> support referencing an Object element or its content in the same manner
>> you'd reference anything else, nothing to see here, move along".
> 
> Yes, that is exactly what I am saying
> 
> 
> Proposed change:
> 
> Orignal text
> ============
> Applications which require normative type and encoding information for signature validation should specify Transforms with well defined resulting types and/or encodings.
> 
> Modified text
> =============
> ...
> Applications which require normative type and encoding information for signature validation should specify Transforms (in compatibility mode) with well defined resulting types and/or encodings. 2.0 mode signatures should use extensibility points in dsig2:Selection element instead of Transforms.
> 
> 
> Orignal text
> ============
> Note, if the application wishes to exclude the <Object> tags from the digest calculation the Reference must identify the actual data object (easy for XML documents) or a transform must be used to remove the Object tags (likely where the data object is non-XML). Exclusion of the object tags may be desired for cases where one wants the signature to remain valid if the data object is moved from inside a signature to outside the signature (or vice versa), or where the content of the Object is an encoding of an original binary document and it is desired to extract and decode so as to sign the original bitwise representation.
> 
> 
> Modified text
> =============
> Note, if the application wishes to exclude the <Object> tags from the digest calculation the Reference must identify the actual data object using standard Referencing mechanisms. E.g.
> * if the data object is a single XML subtree, then use an ID based reference to the data object.
> * if the data object is multiple XML subtrees under the <Object> tag, then use an XPath Transform (compatibility mode) or IncludedXPath (2.0 mode) to refer to these nodes. Note in 2.0 mode it is not possible to refer to non-element nodes.
> * if the data object is base64 text, then use a Base64 transform (compatibility mode) or dsig2:Selection with a Subtype="...fromBase64Node" (2.0 mode)
> * if the data is something else, then use a custom transform (compatibility mode) or a dsig2:Selection with custom type and subtype (2.0 mode)
> 
> Exclusion of the object tags may be desired for cases where one wants the signature to remain valid if the data object is moved from inside a signature to outside the signature (or vice versa), or where the content of the Object is an encoding of an original binary document and it is desired to extract and decode so as to sign the original bitwise representation.
> 
> 
> 
> Pratik
> 
> 
> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu] 
> Sent: Tuesday, June 01, 2010 11:48 AM
> To: Pratik Datta; XMLSec WG Public List
> Subject: RE: Object tag in Dsig 2.0
> 
>> My proposal:
>> 
>> The <Object> tag is meant for Enveloping signatures, where the user wants
> to
>> put the data to be signed inside the <Signature> itself.  There are three
>> subcases for this.
>> 
>> a) The data to be signed is a single XML subtree, and it is present as a
>> child of the <Object>.  The subtree has an ID, and the <Reference> uses
> this
>> ID to look up this subtree, no transforms are used.  This is the simple
> use
>> case, I propose that we only support this one in 2.0.
> 
> Presumably it doesn't have to be by ID? I think you're just saying "we
> support referencing an Object element or its content in the same manner
> you'd reference anything else, nothing to see here, move along".
> 
> -- Scott
> 
> 
> 
> 
>

Received on Friday, 4 June 2010 20:26:59 UTC