OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[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]