RE: [dss] DSS Core comments

[<Frederick.Hirsch@nokia.com>]

Trevor 

I like this level of detail better since it is less ambiguous on how various input choices are processed.
(For example I thought the base64 text would be the input to the hash function, this clarifies that decoding first is intended)

I note you made the change that the <XMLData> element itself  is not included in the hash value, which I prefer.

Regarding same document reference being a node set, isn't that only applicable to verification where a Reference 
of "" is processed, so I don't think this is a problem.

regards,

Frederick

Frederick Hirsch
Nokia Mobile Phones

> -----Original Message-----
> From: ext Trevor Perrin [mailto:trevp@trevp.net]
> Sent: Wednesday, December 03, 2003 3:21 PM
> To: Hirsch Frederick (NMP-MSW/Boston); dss@lists.oasis-open.org
> Subject: RE: [dss] DSS Core comments
> 
> 
> At 09:13 AM 12/3/2003 -0500, Frederick.Hirsch@nokia.com wrote:
> 
> >Trevor
> >
> >I think we are going to have to be meticulously clear about 
> the hashing 
> >processing rules - about what is
> >hashed and what is not.  For example, in the text you propose:
> >
> >1.  The server hashes the contents of each <Document> 
> element:  If the
> ><Document> contains <XMLData>, the server hashes the entire 
> contents of the
> ><XMLData> element, excluding the start and end tags.  If the 
> <Document>
> >contains <Base64Data>, the server base64-decodes the element 
> content and
> >hashes the result.
> >
> >This reads that the elements "<XMLData>" and "</XMLData>" 
> are included in 
> >the hash calculation. I thought not from the previous text, 
> and maybe it 
> >is better if they are not, since these elements wrap the 
> content we care about.
> 
> 
> Here's a more detailed description for steps 1 and 2.  I 
> think this is better -
> 
> """
> 1.  The server hashes the contents of each <Document> 
> element, as follows:
>    1.a)  If the <Document> contains <XMLData>, the server 
> extracts the text 
> content of the <XMLData> element as an octet stream.
>    1.b)  If the <Document> contains <Base64Data>, the server 
> base64-decodes 
> the text content of the <Base64Data> element into an octet stream.
>    1.c)  If the server wishes, it may apply additional 
> XML-DSIG transforms 
> to the octet stream produced in 1.a or 1.b.  These transforms 
> should be 
> applied as per XML-DSIG 4.3.3.2.  If the end-result of these 
> transform is 
> an XML node set, the server must convert the node set back 
> into an octet 
> stream using Canonical XML.
>    1.d)  The server hashes the resultant octet stream.
> 
> 2.  The server forms a <ds:Reference> for each input document.  The 
> elements and attributes of the <ds:Reference> are set as follows:
>    - The URI attribute is set to the input document's RefURI 
> attribute, or 
> omitted if none.
>    - The Type attribute is set to the input document's 
> RefType attribute, 
> or omitted if none.
>    - The DigestValue element is set to the hash value that 
> was calculated 
> in step 1 (for a <Document>) or transmitted to the server (for a 
> <DocumentHash>).
>    - The DigestMethod element is set to the hash method that 
> was used in 
> step 1 (for a <Document>) or transmitted to the server (for a 
> <DocumentHash>).
>    - The Transforms element is set to the transforms that 
> were transmitted 
> to the server.  If any additional transforms were applied by 
> the server in 
> step 1.c., these are appended as well.
> 
> 3.  The server creates an XML Digital Signature using the References 
> created in Step 2, according to the processing rules in the 
> XML Digital 
> Signature recommendation.
> 
> 4.  The server returns the ds:Signature.
> """
> 
> One question: the above step 1 says that the inputs will 
> always start off, 
> on the server, as an octet stream.  XML-DSIG 4.3.3.2 mandates that 
> same-document URI references should start off as node sets.  
> XML-DSIG also 
> says that if the client has already applied some transforms, the data 
> object might be a node set at that point.
> 
> I believe that node sets and octet streams are just different 
> representations of the same bytes, so it's fine for the 
> server to start off 
> treating input documents as octet streams, and parse them if needed.
> 
> But that may be wrong.  Could any XML-DSIG expert shed light on this?
> 
> 
> Trevor 
> 
>