[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]