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 03:37 PM 12/3/2003 -0500, Frederick.Hirsch@nokia.com wrote:

>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.

It's also applicable where a client has already applied some transforms, 
and then sends the document.  For example, the client sends:

<Document>
   <XMLData>.....</XMLData>
   <ds:Transforms>
      <ds:Transform 
Algorithm="<http://www.w3.org/TR/1999/REC-xslt-19991116>http://www.w3.org/TR/1999/REC-xslt-<http://www.w3.org/TR/1999/REC-xslt-19991116>19991116">
        ...
      </ds:Transform>
   </ds:Transforms>
</Document>

The XSLT transform will produce a node set.  Now suppose the server wants 
to apply an additional transform that takes a node set.  Normally when you 
have 2 such transforms back-to-back, the data object will stay as a node set.

But in DSS, the data object will be canonicalized to an octet stream on the 
client-side, then re-parsed on the server side.

I don't think that will affect the resultant signature.  But I'm not 100% sure.


Trevor 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]